[tsvwg] UDP Options Implementation Update

["[e-mail]" <[e-mail]>]

Here is a brief update on the implementation work in FreeBSD.
 
Current UDP Options (as of draft-ietf-tsvwg-udp-options-05) and their
implementation status:
 
 0*      -         End of Options List (EOL)             - Implemented
 1*      -         No operation (NOP)                    - Implemented
 2*      2         Option checksum (OCS)                 - Implemented (replace with CCO?)
 5*      4         Maximum segment size (MSS)            - Implemented
 7       10        Timestamps (TIME)                     - Implememented
 ...     (varies)  UNASSIGNED/RESERVED                   - as in spec.
 
 3*      4         Alternate checksum (ACS)              - OK (but not yet implemented)
 
In September, Joe said he would add the REQ and RES options (described in
draft-ietf-tsvwg-datagram-plpmtud-05) to the next rev of the document.
 
 9       6         Request (REQ)                         - Also implemented
 10      6         Response (RES)                        - Also implemented
 
At IETF-103 we are presenting the CCO
(draft-fairhurst-udp-options-cco, see maprg and tsvwg second meeting).
We think use of the CCO is required on the internet and an checksum
using the CCO pseudo header should replace the OCS.
 
 xx      4         Checksum Compensation Option (CCO)    - An alternative approach to OCS
 
All of the above has been tested and is being used in experiments with UDP-Options.
 
---
   
We are left with questions about FRAG, LITE and AE - all currently not implemented.
 
 4*      4         Lite (LITE)                           - See below
 
LITE - The specification for LITE is complicated, but we think implementation
        is possible.

        The way in which LITE is processed in the current specification, means
        that if there is a mistake in the implemenation or a change to this in
        future, then it will mangle everything in the option space.

        At this time our University does not have a use case that
        needs this, so we don't expect to be adding this anytime soon,
        how does the WG wish to handle this?
 
 6*      8/10      Fragmentation (FRAG)                  - See below
 
FRAG - Support for fragments in transport and network protocols are difficult
       to handle, partly because of need to consider attack vectors and
       partly because of need to manage reassembly buffers. That isn't
       something an endpoint would enable as default.

       The current spec puts data in the UDP payload, which does not seem
       correct.

       We don't have any current plans to add this ourselves. Are others
       implementing?
 
 8       (varies)  Authentication and Encryption (AE)    - See below
 
AE   - I think this is underspecified. An option in this space does make
        sense, but it should probably be could be specified in a seperate document
        where the security details are described - doing this later does not
        appear to be an issue.
 
 - Tom