[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

N/A                                                            T. Keiser
Internet-Draft                                            A. Deason, Ed.
Intended status: Informational                               Sine Nomine
Expires: March 14, 2013                               September 10, 2012


           Extensible XDR Discriminated Union Primitive Type
                     draft-keiser-afs3-xdr-union-06

Abstract

   AFS-3 relies upon XDR to carry Rx RPC call payloads.  XDR
   discriminated unions are ill-suited to cases where the protocol needs
   to evolve without inventing new RPCs, i.e., unknown discriminant
   values cause the entire XDR payload to fail the decoding step.  While
   this can be circumvented through the use of opaque payloads (and
   recursive XDR invocations), such solutions are inelegant and
   difficult to implement.  This memo defines a new XDR primitive type,
   "ext-union", which is derived from the XDR discriminated union
   primitive type, but with two key variations: 1) each leg contains a
   length field, and 2) no default leg is supported.

Internet Draft Comments

   Comments regarding this draft are solicited.  Please include the
   AFS-3 protocol standardization mailing list
   (afs3-standardization@openafs.org) as a recipient of any comments.

AFS-3 Document State

   This document is in state "draft", as per the document state
   definitions set forth in [I-D.wilkinson-afs3-standardisation].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Keiser & Deason          Expires March 14, 2013                 [Page 1]


Internet-Draft            Extensible XDR Union            September 2012


   This Internet-Draft will expire on March 14, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Use Case . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Extensible Discriminated Union . . . . . . . . . . . . . . . .  4
     3.1.  Extensible Union Type  . . . . . . . . . . . . . . . . . .  4
     3.2.  RPC-L Changes  . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Decoding . . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.4.1.  Error Handling . . . . . . . . . . . . . . . . . . . .  8
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  AFS Assigned Numbers Registrar Considerations  . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
















Keiser & Deason          Expires March 14, 2013                 [Page 2]


Internet-Draft            Extensible XDR Union            September 2012


1.  Introduction

   AFS-3 [CMU-ITC-88-062] [CMU-ITC-87-068] is a distributed file system
   that has its origins in the VICE project [CMU-ITC-84-020]
   [CMU-ITC-85-039] at the Carnegie Mellon University Information
   Technology Center [CMU-ITC-83-025], a joint venture between CMU and
   IBM.  VICE later became AFS when CMU moved development to a new
   commercial venture called Transarc Corporation, which later became
   IBM Pittsburgh Labs.  AFS-3 is a suite of un-standardized network
   protocols based on a remote procedure call (RPC) suite known as Rx
   [AFS3-RX].  While de jure standards for AFS-3 fail to exist, the
   various AFS-3 implementations have agreed upon certain de facto
   standards, largely helped by the existence of an open source fork
   called OpenAFS that has served the role of reference implementation.
   In addition to using OpenAFS as a reference, IBM wrote and donated
   developer documentation that contains somewhat outdated
   specifications for the Rx protocol and all AFS-3 remote procedure
   calls, as well as a detailed description of the AFS-3 system
   architecture.

   The Rx RPC protocol utilizes XDR [RFC4506] as its means of encoding
   RPC call and response payloads.  XDR provides a discriminated union
   type.  However, the semantics of the discriminated union base type do
   not lend themselves to evolution of the discriminant namespace:
   introduction of new discriminants--when there is no default leg--
   cause the remainder of the XDR octet stream to be un-parseable (due
   to the lack of a length field in the encoding) by older peers.  This
   memo introduces a new XDR primitive type that is identical to the XDR
   discriminated union, except that:

   1.  each leg contains a length field, and

   2.  the default leg is disallowed.

1.1.  Use Case

   Given that this design doubles the overhead from 4 to 8 octets
   (relative to the XDR discriminated union primitive type), it is ill-
   suited for use with small implied legs.  Within the AFS-3 protocol
   suite, the primary use case for the extensible union type is to wrap
   large data structures, rather than small primitive types.

1.2.  Abbreviations








Keiser & Deason          Expires March 14, 2013                 [Page 3]


Internet-Draft            Extensible XDR Union            September 2012


   AFS      -  Historically, AFS stood for the Andrew File System; AFS
             no longer stands for anything

   RPC      -  Remote Procedure Call

   RPC-L    -  Rx RPC Interface Definition Language (fork of ONC RPC
             [RFC5531] .x file format)

   Rx       -  The Remote Procedure Call mechanism utilized by AFS-3
             [AFS3-RX]

   XDR      -  eXternal Data Representation [RFC4506]


2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


3.  Extensible Discriminated Union

   The extensible discriminated union will contain a length field in
   every leg so that decoding peers can compute the offset of the next
   object in the XDR octet stream, regardless of whether the
   discriminant is recognized.  For small legs, this will result in
   significant encoding inefficiency, but it is necessary to permit the
   union to evolve over time (without peers failing to decode the entire
   XDR octet stream).

3.1.  Extensible Union Type

   The definition of the extensible discriminated union is derived from
   the XDR union defined in section 4.15 of the XDR specification
   [RFC4506].  Unlike XDR discriminated unions, the XDR types mapped to
   each arm of the union need not be defined a priori.  Instead, the
   length of the arm is always included in the wire encoding along with
   the discriminant value, thus permitting the decoder to continue
   decoding past an unknown discriminant in an XDR octet stream.

   How undefined discriminants are handled by the decoder is
   deliberately left unspecified by this document.  Rather, this memo
   merely specifies which error conditions must be flagged to the caller
   (see Section 3.4.1).  The error handling semantics--for both length
   mismatches and unknown discriminants--are left up to the definition
   of any type built upon the ext-union primitive type.  While this
   lends significant flexibility to the design, it also permits XDR



Keiser & Deason          Expires March 14, 2013                 [Page 4]


Internet-Draft            Extensible XDR Union            September 2012


   decoding to continue when the expected implied arm length doesn't
   match the length on the wire.  It is RECOMMENDED that implementations
   fail to decode the entire XDR stream when such a length mismatch is
   encountered, as such a length mismatch is indicative of either:

   1.  a significant divergence in RPC-L definitions across the peers,
       or

   2.  an undetected bit error in the XDR octet stream.

   Extensible discriminated unions are defined in RPC-L as follows:

       ext-union [ max-unknown-leg-length=X ]
          switch (discriminant-definition) {
       case discriminant-value-A:
          arm-declaration-A;
       case discriminant-value-B:
          arm-declaration-B;
       ...
       } identifier;

                                 Figure 1

   Because the discriminant namespace of an extensible union must be
   capable of evolving over time, it is not possible to support a
   default leg.

   The max-unknown-leg-length optional parameter specifies the maximum
   permissible leg length for any union leg whose discriminant value is
   not known to the decoder.  This is necessary to limit the scope of
   denial of service attacks: by permitting the decoder to detect
   inordinately large payloads--after only receiving the first few
   octets of the extensible union.

   The extensible discriminated union is encoded on the wire as: a
   4-octet discriminant, followed by a 4-octet arm length, and finally
   the variable-length implied arm.  The arm length field SHALL count
   the length of the implied arm in octets, and only the implied arm.
   In other words, the 8 octets occupied by the discriminant and arm
   length fields SHALL NOT be counted as part of the arm length value.

               0   1   2   3
             +---+---+---+---+---+---+---+---+---+---+---+---+
             |  discriminant |   arm length  |  implied arm  |
             +---+---+---+---+---+---+---+---+---+---+---+---+
             |<---4 octets-->|<---4 octets-->|

                                 Figure 2



Keiser & Deason          Expires March 14, 2013                 [Page 5]


Internet-Draft            Extensible XDR Union            September 2012


   It should be noted that this design makes it convenient to implement
   extensible discriminated unions on top of existing XDR primitive
   types.  Thus, in terms of the existing XDR primitives [RFC4506], we
   can describe an extensible discriminated union as follows:

       struct ext_union {
           unsigned int discriminant;
           opaque implied_leg<>;
       };

                                 Figure 3

3.2.  RPC-L Changes

   In order to implement the above, the XDR grammar, as specified in
   Section 6.3 of [RFC4506], will need to be modified in the following
   ways:

   o  "type-specifier" will require a new production rule mapping to
      "ext-union-type-spec", and

   o  an "ext-union-type-spec" production rule will need to be defined.

   The "type-specifier" grammar will now include a new production rule
   for "ext-union-type-spec":

       type-specifier:
            [ "unsigned" ] "int"
          | [ "unsigned" ] "hyper"
          | "float"
          | "double"
          | "quadruple"
          | "bool"
          | enum-type-spec
          | struct-type-spec
          | union-type-spec
          | identifier
          | ext-union-type-spec

                                 Figure 4

   The new "ext-union-type-spec" production rule, and the production
   rule for its nonterminal symbol dependency "ext-union-body", are
   defined as follows:







Keiser & Deason          Expires March 14, 2013                 [Page 6]


Internet-Draft            Extensible XDR Union            September 2012


       ext-union-type-spec:
          "ext-union" ext-union-body
        | "ext-union" ext-union-options ext-union-body

       ext-union-options:
          "[" ext-union-options-body "]"

       ext-union-options-body:
          ext-union-option
        | ext-union-option "," ext-union-options-body

       ext-union-option:
          "max-unknown-leg-length" "=" value

       ext-union-body:
          "switch" "(" declaration ")" "{"
             case-spec
             case-spec *
          "}"

                                 Figure 5

3.3.  Encoding

   It is RECOMMENDED that encoding of an AFS-3 extensible union proceed
   using the following algorithm:

   1.  encode an XDR unsigned 32-bit integer (see Section 4.2 of
       [RFC4506]) containing the discrimant,

   2.  XDR encode into temporary storage the implied leg (according to
       the type definition of the type specified for this discriminant
       value in the ext-union definition), and

   3.  encode the implied leg using the XDR variable-length opaque
       specification (see Section 4.10 of [RFC4506]).

3.4.  Decoding

   It is RECOMMENDED that decoding of an AFS-3 extensible union proceed
   using the following algorithm:

   1.  XDR decode the 32-bit unsigned integer containing the
       discriminant;

   2.  XDR decode the variable-length opaque blob into temporary
       storage;




Keiser & Deason          Expires March 14, 2013                 [Page 7]


Internet-Draft            Extensible XDR Union            September 2012


   3.  If this is a known discriminant:

       1.  XDR decode the implied leg payload using the appropriate
           decoder for the discriminant value;

       2.  Compare the length of the decoded XDR payload against the
           previously-decoded extensible union implied leg length.  If
           the lengths do not match, then mark the union as failed to
           decode due to a length mismatch;

   4.  However, if this is an unknown discriminant, then mark the union
       as failed to decode due to an unknown discriminant;

   5.  XDR decoding continues at the current offset plus the length of
       the previously-decoded XDR variable-length opaque.

3.4.1.  Error Handling

   While the specific decoding algorithm used is left up to the
   implementor, error handling MUST be implemented as described in this
   section.

   Unknown Discriminant:

       When a decoder encounters an unknown discriminant, it MUST mark
       the discriminant as unknown, and SHOULD proceed to decoding the
       next element in the XDR stream by seeking past the length and
       implied leg fields.

   Unexpected Length for Discriminant:

       When a decoder encounters a length field that doesn't agree with
       the length expected for this discriminant, it MUST mark the
       discriminant as failed to decode due to a length mismatch, and
       SHOULD fail to decode the rest of the XDR octet stream.

   Excessively Long Payload:

       When the following conditions are satisfied:

       1.  the max-unknown-leg-length value is specified in the
           extensible union type definition, and

       2.  the discriminant value is unknown, and

       3.  the implied leg length exceeds the max-unknown-leg-length
           specified in the type definition,




Keiser & Deason          Expires March 14, 2013                 [Page 8]


Internet-Draft            Extensible XDR Union            September 2012


       then the decoder MUST mark the discriminant as failed to decode
       due to excessive length, and SHOULD fail to decode the rest of
       the XDR octet stream.  In addition, an implementation MAY choose
       to mark a discriminant as failed to decode--and MAY fail to
       decode the rest of the XDR octet stream--when a known implied
       leg's length exceeds the max-unknown-leg-length in the extensible
       union type specification.


4.  Acknowledgements

   The author would like to thank Jeffrey Hutzelman for proposing
   standardization of a new XDR primitive type; and Matt Benjamin,
   Derrick Brashear, Andrew Deason, Steven Jenkins, Michael Meffie, Mark
   Vitale, and Simon Wilkinson for helping to refine the design of this
   extensible union type.  Finally, the author would like to thank the
   attendees of the 2011 Pittsburgh AFS Hackathon for their review and
   comments regarding the -01 draft.


5.  IANA Considerations

   This memo includes no request to IANA.


6.  AFS Assigned Numbers Registrar Considerations

   This memo includes no request to the AFS Assigned Numbers Registrar.


7.  Security Considerations

   Users of this extensible type should understand that any Rx XDR
   payload is only as secure as the security class bound to the Rx
   connection in question.  This document merely standardizes a
   primitive type; it is up to the authors of standards defining new
   types (upon the "ext-union" primitive type) to ensure that the
   contents of their types are only marshalled over sufficiently-secure
   security classes.

   Decoders should take special care when encountering unexpected
   implied arm lengths.  This could be indicative of serious errors,
   such as octet stream bit errors that were undetected by lower-layer
   checksums.  At the very least, this error condition implies that the
   peers do not agree upon their ext-union type-to-discriminant
   mappings.  It is RECOMMENDED that decoders treat this as a hard error
   and fail to decode the remainder of the XDR octet stream.




Keiser & Deason          Expires March 14, 2013                 [Page 9]


Internet-Draft            Extensible XDR Union            September 2012


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4506]  Eisler, M., "XDR: External Data Representation Standard",
              STD 67, RFC 4506, May 2006.

8.2.  Informative References

   [AFS3-RX]  Zayas, E., "AFS-3 Programmer's Reference: Specification
              for the Rx Remote Procedure Call Facility", Transarc Corp.
              Tech. Rep. FS-00-D164, August 1991.

   [CMU-ITC-83-025]
              Morris, J., Van Houweling, D., and K. Slack, "The
              Information Technology Center", CMU ITC Tech. Rep. CMU-
              ITC-83-025, 1983.

   [CMU-ITC-84-020]
              West, M., "VICE File System Services", CMU ITC Tech.
              Rep. CMU-ITC-84-020, August 1984.

   [CMU-ITC-85-039]
              Satyanarayanan, M., Howard, J., Nichols, D., Sidebotham,
              R., Spector, A., and M. West, "The ITC Distributed File
              System: Principles and Design", Proc. 10th ACM Symp.
              Operating Sys. Princ. Vol. 19, No. 5, December 1985.

   [CMU-ITC-87-068]
              Howard, J., Kazar, M., Menees, S., Nichols, D.,
              Satyanarayanan, M., Sidebotham, R., and M. West, "Scale
              and Performance in a Distributed File System", ACM Trans.
              Comp. Sys. Vol. 6, No. 1, pp. 51-81, February 1988.

   [CMU-ITC-88-062]
              Howard, J., "An Overview of the Andrew File System"",
              Proc. 1988 USENIX Winter Tech. Conf. pp. 23-26,
              February 1988.

   [I-D.wilkinson-afs3-standardisation]
              Wilkinson, S., "Options for AFS Standardisation",
              draft-wilkinson-afs3-standardisation-00 (work in
              progress), June 2010.

   [RFC5531]  Thurlow, R., "RPC: Remote Procedure Call Protocol



Keiser & Deason          Expires March 14, 2013                [Page 10]


Internet-Draft            Extensible XDR Union            September 2012


              Specification Version 2", RFC 5531, May 2009.


Authors' Addresses

   Thomas Keiser
   Sine Nomine Associates
   43596 Blacksmith Square
   Ashburn, VA  20147
   USA

   Email: tkeiser@gmail.com


   Andrew Deason (editor)
   Sine Nomine Associates
   43596 Blacksmith Square
   Ashburn, Virginia  20147-4606
   USA

   Phone: +1 703 723 6673
   Email: adeason@sinenomine.net





























Keiser & Deason          Expires March 14, 2013                [Page 11]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/