Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt

[Joe Touch <[e-mail]>]

Hi, Med,

I have not yet updated that draft. I also intended to post your comments
to the group for discussion. Both are on my pending items list...

Joe


On 12/6/2017 5:48 AM, [e-mail] wrote:
>
> Hi Joe,
>
>  
>
> Unless I’m mistaken I didn’t see any update of the draft to address
> some of the comments raised in my review.
>
>  
>
> FWIW, a copy of my comments are available at:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-tsvwg-udp-options-01-rev%20Med.pdf
>
>  
>
> Cheers,
>
> Med
>
>  
>
> *De :*Joe Touch [mailto:[e-mail]]
> *Envoyé :* mardi 4 juillet 2017 23:27
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* [e-mail]
> *Objet :* Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt
>
>  
>
> Will do, but note that I'm on vacation now through July 16. I'll post
> this and pick the thread up when I return.
>
> Joe
>
>  
>
> On 6/30/2017 5:25 AM, [e-mail]
> <mailto:[e-mail]> wrote:
>
>     Hi Joe,
>
>      
>
>     The discussion can be on-list.
>
>      
>
>     Please feel free to forward the initial review and this one to the
>     list.
>
>      
>
>     Thank you.
>
>      
>
>     Cheers,
>
>     Med
>
>      
>
>     *De :*Joe Touch [mailto:[e-mail]]
>     *Envoyé :* jeudi 29 juin 2017 15:58
>     *À :* BOUCADAIR Mohamed IMT/OLN
>     *Cc :* [e-mail] <mailto:[e-mail]>
>     *Objet :* Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt
>
>      
>
>     Hi, Med,
>
>     First, is there a reason we're discussing this off-list? This
>     thread really should be on-list - I can forward these messages and
>     we can continue there if it's OK.
>
>     Joe
>
>      
>
>     On 6/28/2017 11:52 PM, [e-mail]
>     <mailto:[e-mail]> wrote:
>
>         Hi Joe,
>
>          
>
>         Thank you for the answers.
>
>          
>
>         Please see inline.
>
>          
>
>         Cheers,
>
>         Med
>
>          
>
>         *De :*Joe Touch [mailto:[e-mail]]
>         *Envoyé :* mercredi 28 juin 2017 20:28
>         *À :* BOUCADAIR Mohamed IMT/OLN
>         *Cc :* [e-mail] <mailto:[e-mail]>
>         *Objet :* Re: [tsvwg] I-D Action:
>         draft-ietf-tsvwg-udp-options-01.txt
>
>          
>
>         Hi, Mohammed,
>
>         Thanks for the detailed comments - most of the editorial
>         suggestions and requests for clarification will be addressed
>         in the next update, except as noted below. For future
>         reference, I would be glad to provide the Word source if
>         that's easier for feedback.
>
>         [Med] Ok, thanks. I can review any updated version you will
>         prepare.
>
>         Some comments:
>
>         - as to whether the list of options should complete; I'll let
>         the RFC Editor and/or IANA decide whether to remove the
>         RESERVED entries or the explicit indication of the IANA
>         assignable region; I'm not sure what their convention is.
>
>         [Med] The point is that your text says “The following UDP
>         options are currently …“. Obviously, “RESERVED” is not an option.
>
>         - ACS and AE are defined as the only options that depend on
>         the contents of the option are for a reason. That's the
>         simplest way to handle the circularity that would otherwise
>         arise. E.g., if ACS covered the contents of AE, then ACS must
>         be processed last. But if AE covered the contents of ACS, the
>         AE must be processed last. Right now, we define that AE covers
>         everything EXCEPT ONLY the contents of ACS and that ACS covers
>         everything. But we can never know how ACS and AE would need to
>         handle options that aren't yet defined - if they also depend
>         on the contents of the option area, we can end up with a
>         circularity again. I'm open to other solutions to this issue,
>         but not sure we want to burn bits in the option header to
>         indicate which options have "dependent contents that need to
>         be zeroed for inclusion in other options" - besides, that sets
>         us up for covert channels that AE might be used to prevent.
>         I.e., there's no way to leave this as a decision for future
>         options without creating a tangled mess of "I come first"
>         declarations, such as we have already for TCP options.
>
>         [Med] I hear you, but I still don’t get this:  
>
>         Future options MUST NOT be defined as having a value
>         independent of the
>
>            contents of the option area
>
>         - the FRAG option is one of the most important and a required
>         option (i.e., if UDP options are supported, FRAG must be
>         supported), which is why it needs to remain in this doc.
>         Whether fragments are delivered to the user when UDP options
>         are not supported depends on how the FRAG option is used - if
>         used without LITE, the fragments would be delivered, but if
>         used with LITE they would not be. That's why we left both
>         variants available.
>
>         [Med] IMHO, this one need more evaluation/validation before
>         being included in a standard track document. I can live with
>         it in an experimental RFC. Actually, my proposal is to scope
>         the udp-options document to the base mechanism and required
>         options. Options that require more experiments are easy to be
>         progressed in dedicated documents. This approach will allow us
>         to finalize quickly the base udp-options.
>
>         - the extension to the UDP API needs to be in the core of the
>         doc because the API is a key part of this (and any) protocol.
>
>         [Med] Joe, we do all agree that API are important. Almost all
>         APIs defined in IETF I’m aware of are defined as Informational
>         RFCs (I can provide an exhaustive list, if needed). This is
>         why I suggested that you move this section into an appendix.
>
>         - as to the other sections you suggest moving to an appendix,
>         I'll wait for other feedback on that point. I'm not fond of
>         appendices except for code examples or truly optional
>         material; the other points you're suggesting to move (other
>         than UDP API, addressed above), e.g., sections don't have that
>         property (sec 7 on whose options are these and sec 8 on LITE
>         vs UDP Lite).
>
>         [Med] Those sections are not normative + some of the content
>         is redundant (Sec. 7 and Sec 8) with other statements earlier
>         in the document. These sections do not bring new elements to
>         the discussion.  
>
>         - Sec 11 has a typo; it's really two sections.
>
>         [Med] OK.
>
>         The part about the changes to 768 should be its own section
>
>         [Med] We don’t need a section for this. This text can be
>         inserted in the Introduction.  
>
>         . I've left that in right now because UDP option "negotiation"
>         is already a soft-state persistence mechanism similar to TCP
>         control block sharing.
>
>         - I don't quite understand your comment:
>
>         UDP options can be used a cover channels. Inspecting those
>         options may be required to protect some networks.
>
>         I think you mean "used as a covert channel",
>
>         [Med] Yes.
>
>          but that's true for nearly every field in any header.
>
>         [Med] Yes, but this is exacerbated when there is no
>         specification about the handling of the surplus area. It is
>         legitimate that network administrators would suspects those
>         packets.
>
>         I disagree that inspection may be required to protect a network
>
>         [Med] Some inspection may be needed to detect/protect against
>         a variety of attacks and to protect networks. Firewalls are
>         the norm in enterprise networks, for example.
>
>         - these are transport values in the transport payload of a
>         network packet.
>
>         [Med] This document defines them as transport values, but
>         legacy devices cannot handle them as transport values.   
>
>          By your logic, the entire transport contents are potentially
>         a covert channel, and we have no recommendation elsewhere to
>         require DPI to protect a *network* (vs. the endpoints, which
>         of course could require checking any part of a message).
>
>         [Med] I don’t understand the reference to DPI. I think you
>         understood “inspection” as if I’m asking for “DPI”. Please see
>         above.
>
>         - as to which refs are normative, AFAICT only RFC768  and 2460
>         would be
>
>         [Med] Please fix those.
>
>         , and *maybe* 1122 (e.g., by extending the extent of the UDP
>         API). Nothing in this doc relies on the standards nature of
>         other documents AFAICT. My "acid test" for whether to include
>         something as normative is "would my doc need to change if the
>         other RFC changed"? AFAICT, that's not true for 768, but I'd
>         like to hear what others think of that set before moving them.
>
>         [Med] For other RFCs you didn’t cite, my rationale for
>         including them as normative is as follows:
>
>         ·         793 : MSS and other features are cloned from that
>         document.
>
>         ·         5925: the udp option clones the TCP option. An
>         implementer need to refer to this document to have an idea
>         about the format: “It uses the same format as specified for
>         TCP-AO, except that it uses a Kind of 8.”
>
>         ·         6994: ExIDs are defined in this RFC. An implementer
>         need to read this RFC to understand/implement how the shared
>         experiment IDs work.
>
>         Joe
>
>          
>
>         On 6/28/2017 12:49 AM, [e-mail]
>         <mailto:[e-mail]> wrote:
>
>             Hi Joe, 
>
>              
>
>             Please find attached an initial review of this version of the document (both doc and pdf files are attached). 
>
>              
>
>             Cheers,
>
>             Med
>
>              
>
>                 -----Message d'origine-----
>
>                 De : tsvwg [mailto:[e-mail]] De la part de Joe Touch
>
>                 Envoyé : mardi 27 juin 2017 22:58
>
>                 À : [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>
>                 Cc : [e-mail] <mailto:[e-mail]>
>
>                 Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt
>
>                  
>
>                 Hi, all,
>
>                  
>
>                 This update adds some clarification on how to handle options whose
>
>                 values depend on other options (e.g., ACS and AE).
>
>                  
>
>                 Joe
>
>                  
>
>                  
>
>                 On 6/27/2017 1:52 PM, [e-mail] <mailto:[e-mail]> wrote:
>
>                     A New Internet-Draft is available from the on-line Internet-Drafts
>
>                 directories.
>
>                     This draft is a work item of the Transport Area Working Group of the
>
>                 IETF.
>
>                      
>
>                             Title           : Transport Options for UDP
>
>                             Author          : Joe Touch
>
>                         Filename        : draft-ietf-tsvwg-udp-options-01.txt
>
>                         Pages           : 27
>
>                         Date            : 2017-06-27
>
>                      
>
>                     Abstract:
>
>                        Transport protocols are extended through the use of transport header
>
>                        options. This document experimentally extends UDP by indicating the
>
>                        location, syntax, and semantics for UDP transport layer options.
>
>                      
>
>                      
>
>                     The IETF datatracker status page for this draft is:
>
>                     https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
>
>                      
>
>                     There are also htmlized versions available at:
>
>                     https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-01
>
>                     https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-01
>
>                      
>
>                     A diff from the previous version is available at:
>
>                     https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-01
>
>                      
>
>                      
>
>                     Please note that it may take a couple of minutes from the time of
>
>                 submission
>
>                     until the htmlized version and diff are available at tools.ietf.org.
>
>                      
>
>                     Internet-Drafts are also available by anonymous FTP at:
>
>                     ftp://ftp.ietf.org/internet-drafts/
>
>              
>
>          
>
>      
>
>  
>