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

[<[e-mail]>]

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/