draft-ietf-nfsv4-rfc1832bis-05.txt   draft-ietf-nfsv4-rfc1832bis-06.txt 
Network Working Group M. Eisler Network Working Group M. Eisler
Internet-Draft Editor Internet-Draft Editor
Document: draft-ietf-nfsv4-rfc1832bis-05.txt Network Appliance, Inc. Document: draft-ietf-nfsv4-rfc1832bis-06.txt Network Appliance, Inc.
February 2005 May 2005
XDR: External Data Representation Standard XDR: External Data Representation Standard
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
skipping to change at page 2, line 26 skipping to change at page 2, line 26
4.19. Optional-data . . . . . . . . . . . . . . . . . . . . . . 14 4.19. Optional-data . . . . . . . . . . . . . . . . . . . . . . 14
4.20. Areas for Future Enhancement . . . . . . . . . . . . . . 15 4.20. Areas for Future Enhancement . . . . . . . . . . . . . . 15
5. DISCUSSION . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. DISCUSSION . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. THE XDR LANGUAGE SPECIFICATION . . . . . . . . . . . . . . . 17 6. THE XDR LANGUAGE SPECIFICATION . . . . . . . . . . . . . . . 17
6.1. Notational Conventions . . . . . . . . . . . . . . . . . . 17 6.1. Notational Conventions . . . . . . . . . . . . . . . . . . 17
6.2. Lexical Notes . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Lexical Notes . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Syntax Information . . . . . . . . . . . . . . . . . . . . 18 6.3. Syntax Information . . . . . . . . . . . . . . . . . . . . 18
6.4. Syntax Notes . . . . . . . . . . . . . . . . . . . . . . . 20 6.4. Syntax Notes . . . . . . . . . . . . . . . . . . . . . . . 20
7. AN EXAMPLE OF AN XDR DATA DESCRIPTION . . . . . . . . . . . 20 7. AN EXAMPLE OF AN XDR DATA DESCRIPTION . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
10. TRADEMARKS AND OWNERS . . . . . . . . . . . . . . . . . . . 22 10. TRADEMARKS AND OWNERS . . . . . . . . . . . . . . . . . . . 23
11. ANSI/IEEE Standard 754-1985 . . . . . . . . . . . . . . . . 22 11. ANSI/IEEE Standard 754-1985 . . . . . . . . . . . . . . . . 23
12. NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . 24 12. NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . 25
13. INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . 24 13. INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . 25
14. Editor's Address . . . . . . . . . . . . . . . . . . . . . 24 14. Editor's Address . . . . . . . . . . . . . . . . . . . . . 25
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 24 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 25
16. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 25 16. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 26
17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 25 17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 26
1. Changes from RFC1832 1. Changes from RFC1832
This document makes no technical changes to RFC1832 and is published This document makes no technical changes to RFC1832 and is published
for the purpose of noting IANA considerations and distinguishing for the purpose of noting IANA considerations, augmenting security
normative from informative references. considerations, and distinguishing normative from informative
references.
2. INTRODUCTION 2. INTRODUCTION
XDR is a standard for the description and encoding of data. It is XDR is a standard for the description and encoding of data. It is
useful for transferring data between different computer useful for transferring data between different computer
architectures, and has been used to communicate data between such architectures, and has been used to communicate data between such
diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*. diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*.
XDR fits into the ISO presentation layer, and is roughly analogous in XDR fits into the ISO presentation layer, and is roughly analogous in
purpose to X.409, ISO Abstract Syntax Notation. The major difference purpose to X.409, ISO Abstract Syntax Notation. The major difference
between these two is that XDR uses implicit typing, while X.409 uses between these two is that XDR uses implicit typing, while X.409 uses
skipping to change at page 21, line 47 skipping to change at page 21, line 47
20 00 00 00 04 .... -- length of interpretor = 4 20 00 00 00 04 .... -- length of interpretor = 4
24 6c 69 73 70 lisp -- interpretor characters 24 6c 69 73 70 lisp -- interpretor characters
28 00 00 00 04 .... -- length of owner = 4 28 00 00 00 04 .... -- length of owner = 4
32 6a 6f 68 6e john -- owner characters 32 6a 6f 68 6e john -- owner characters
36 00 00 00 06 .... -- length of file data = 6 36 00 00 00 06 .... -- length of file data = 6
40 28 71 75 69 (qui -- file data bytes ... 40 28 71 75 69 (qui -- file data bytes ...
44 74 29 00 00 t).. -- ... and 2 zero-bytes of fill 44 74 29 00 00 t).. -- ... and 2 zero-bytes of fill
8. Security Considerations 8. Security Considerations
Security issues are not discussed in this memo. XDR is a data description language, not a protocol, and hence it does
not inherently give rise to any particular security considerations.
Protocols that carry XDR-formatted data, such as NFSv4, are
responsible for providing any necessary security services to secure
the data they transport.
Care must be take to properly encode and decode data to avoid
attacks. Known and avoidable risks include:
* Buffer overflow attacks. Where feasible, protocols should be
defined with explicit limits (via the "<" [ value ] ">" notation
instead of "<" ">") on elements with variable length data types.
Regardless of the feasibility of an explicit limit on the
variable length of an element of a given protocol, decoders need
to ensure the incoming size does not exceed the length of any
provisioned receiver buffers.
* Nul octets embedded in an encoded value of type string. If the
decoder's native string format uses nul terminated strings, then
the apparent size of the decoded object will be less than the
amount of memory allocated for the string. Some memory
deallocation interfaces take a size argument. The caller of the
deallocation interface would likely determine the size of the
string by counting to the location of the nul octet, and adding
one. This discrepancy can cause memory leakage (because less
memory is actually returned to the free pool than allocated),
leading to system failure and a denial of service attack.
* Decoding of characters in strings that are legal ASCII
characters but nonetheless are illegal for the intended
application. For example some operating systems treat the '/'
character as a component separator in path names. For a protocol
that encodes a string in the argument to a file creation
operation, the decoder needs to ensure sure '/' is not inside
the component name. Otherwise, a file with an illegal '/' in
its name will be created, making it difficult to remove, and is
therefore a denial of service attack.
* Denial of service caused by recursive decoder or encoder
subroutines. A recursive decoder or encoder might process data
that has a structured type with a member of type optional data
that directly or indirectly refers to the structured type (i.e.
a linked list). For example,
struct m {
int x;
struct m *next;
};
An encoder or decoder subroutine might be written to recursively
call itself each time another element of type "struct m" is
found. An attacker could construct a long linked list of "struct
m" elements in the request or response which then causes a stack
overflow on the decoder or encoder. Decoders and encoders
should be written non-recursively, or impose a limit on list
length.
9. IANA Considerations 9. IANA Considerations
It is possible, if not likely, that new data types will It is possible, if not likely, that new data types will be added to
be added to XDR in the future. The process for adding XDR in the future. The process for adding new types is via a
new types is via a standards track RFC and not standards track RFC and not registration of new types with IANA.
registration of new types with IANA. Standards track RFCs Standards track RFCs that update or replace this document should be
that update or replace this document should be documented as such in the RFC Editor's database of RFCs.
documented as such in the RFC Editor's database of
RFCs.
10. TRADEMARKS AND OWNERS 10. TRADEMARKS AND OWNERS
SUN WORKSTATION Sun Microsystems, Inc. SUN WORKSTATION Sun Microsystems, Inc.
VAX Hewlett-Packard Company VAX Hewlett-Packard Company
IBM-PC International Business Machines Corporation IBM-PC International Business Machines Corporation
Cray Cray Inc. Cray Cray Inc.
NFS Sun Microsystems, Inc. NFS Sun Microsystems, Inc.
Ethernet Xerox Corporation. Ethernet Xerox Corporation.
Motorola 68000 Motorola, Inc. Motorola 68000 Motorola, Inc.
skipping to change at page 24, line 35 skipping to change at page 25, line 35
[HPRE] "HP Precision Architecture Handbook", June 1987, 5954-9906. [HPRE] "HP Precision Architecture Handbook", June 1987, 5954-9906.
14. Editor's Address 14. Editor's Address
Mike Eisler Mike Eisler
5765 Chase Point Circle 5765 Chase Point Circle
Colorado Springs, CO 80919 Colorado Springs, CO 80919
USA USA
Phone: 719-599-9026 Phone: 719-599-9026
EMail: mike@eisler.com EMail: mike.ietf.xdr@eisler.com
Please address comments to: nfsv4@ietf.org Please address comments to: nfsv4@ietf.org
15. Acknowledgements 15. Acknowledgements
Bob Lyon was Sun's visible force behind ONC RPC in the 1980s. Sun Bob Lyon was Sun's visible force behind ONC RPC in the 1980s. Sun
Microsystems, Inc. is listed as the author of RFC1014, which RFC1832 Microsystems, Inc. is listed as the author of RFC1014, which RFC1832
was heavily derived from. Raj Srinivasan in turn edited RFC1014 into was heavily derived from. Raj Srinivasan in turn edited RFC1014 into
RFC1832. Raj and the rest of the old ONC RPC working group produced RFC1832. Raj and the rest of the old ONC RPC working group produced
RFC1832 from which this document is derived. Mike Eisler and Bill RFC1832 from which this document is derived. Mike Eisler and Bill
Janssen submitted the implementation reports for this standard. Kevin Janssen submitted the implementation reports for this standard. Kevin
Coffman and Benny Halevy reviewed this document and gave feedback. Coffman, Benny Halevy, and Jon Peterson reviewed this document and
Peter Astrand and Bryan Olson pointed out several errors in RFC1832 gave feedback. Peter Astrand and Bryan Olson pointed out several
which are corrected in this document. errors in RFC1832 which are corrected in this document.
16. IPR Notices 16. IPR Notices
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/