Subject: [tsvwg] Update to UDP Guidelines (rev -08) --- RTG area input

From: [email-masked]
Date: Wed, 16 Mar 2016 15:46:33 -0000

This email is strictly as a TSVWG author (no chair hat!)

It provides some commentary to explain the changes we made in the latest
review to the UDP Guidelines draft.

David Black helpfully provided some review comments on this topic,
included below together with the author comments on what was introduced in
revision -08. The  received comments mainly related to the Routing Area
work on tunnel protocols and the related WG activities on this topic.

WE think this resolves the issues raised in WGLC - Is it now OK to proceed?

Best wishes,

Gorry, Greg and Lars

 --------------------------------------------------

David Black:

 Not having seen any response from Erik on this on this, and with the
RTGWG  encap draft having expired, I've attempted to outline material in
that  draft that looks like it could use attention in the UDP guidelines
draft.

 Draft links: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-dt-encap/
 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ This email
is written in some combination of my roles as an individual and as the
 draft shepherd who wants to move the 5405bis draft along. Please consider
these comments in that light (e.g., and not as instructions from a TSVWG
WG-co-chair).

 -- RTGWG encap Section 7. Entropy.

Section 5.1 of the 5405bis draft has a single sentence on use of the UDP
source port to inject entropy - it doesn't say much: The UDP source port
number field has been used as a basis to design load-balancing solutions
for IPv4. The first four paragraphs of Section 7 of the RTGWG draft
contain additional material on this topic (for both IPv4 and IPv6) that
ought to be discussed in the 5405bis draft in some fashion.

GF: The new draft has been a little reorganised to make it a more useful
reference to tunnel developers using UDP. We also incorporated material
from recent related IETF work UDP-in-MPLS, UDP-in-GRE, and of course the
RTG encaps work.

 In addition, the approach to discussion of the IPv6 flow label needs to
be decided, as the two drafts differ here: - the 5405bis draft recommends
 use of and transition to the flow label, but - the RTGWG encap draft
effectively dismisses use of the flow label for entropy on the basis that
current "running code" in routers doesn't support that.

GF: I checked the tunnel draft and other discussions and didn’t feel there
was a need to change the recommendation, although I did update the working
to see if this clarifies the difference between short-term and long-term
perspectives. In particular, I added text from UDP-in-GRE that comments on
these issues.

 In connection with the latter, I observe that "running code" limitations
are a major motivation for UDP encap for ECMP load balancing (as well as
for NAT/Firewall traversal).

GF: When I made the text on tunnel applications more evident, I
highlighted this and some other related topics.

 Something also needs to be said in the 5405bis draft about the conflict
between use of a random changing source port to inject entropy and use
 of a random fixed source port as countermeasure to off-pack attacks. I
would think that the Controlled Environment concept from section 3.6
would
 show up in this discussion.

GF: I added text to the above section.

GF: I also increased the clarity of the “applicability” subsection.

 -- RTGWG encap Section 9.
 MTU and fragmentation I think the 5405bis draft is ok on this topic,
primarily because the detailed specification of MTU behavior in tunnel
implementations has been (correctly, IMHO) fobbed off to the INTAREA
tunnels draft.

 GF: No change, but I fixed NiTs.

 -- RTGWG encap Section 12. QoS

This basically references RFC 2983 for applicable discussion. It would be
useful to add a sentence or two to Section 3.1.9 of the 5405bis draft to
do likewise.

GF: Updated applicability subsection - and made more sections point to this.

 [RFC2983] describes how the DSCP of an inner tunnelled packet is used  to
set the DSCP value in an outer IP header.

GF: Added to tunnel section.

 -- RTGWG encap Section 13. Congestion Considerations The current 5405bis 
draft discussion of this topic should be sufficient.

 GF: No change.

 -- RTGWG encap Section 14.
Header Protection This feels like a gap in the 5405bis draft. Every UDP
encapsulation designer wants to turn off the UDP checksum for
implementation efficiency reasons. The result exposes  headers to
integrity concerns.

 Section 3.4 of the 5405bis draft should be enhanced to better discuss
this concern and what to do about it (there is language recommending a
header checksum, but more could be said about why).

 GF: I tried, is this sufficient?

 -- RTGWG encap Section 19. Middlebox Considerations The middlebox
traversal material in Section 3.5 of the 5405bis draft is considerably
more comprehensive on this topic. Nothing to do here.

 GF: No change.

 GF: We also added a sentence to say endpoints are allowed to drop any
packet with zero checksum, pointing to RFC host requirements.

 GF: I replaced /controlled network environment/ with /controlled
environment/ to be consistent in use of this term.

 GF: Added new items to the summary table.

---

From: "Black, David" <[email-masked]>
Date: Wed, 16 Mar 2016 16:22:22 +0000

Looks very good, one last concern - I see this addition to the Section 7 summary table:

   | Applications specifyied for use in limited use (or      |         |
   | controlled environments) SHOULD identify equivalent     |         |
   | mechanisms and describe their use-case.    

That would be "equivalent mechanisms" for what, please?  A section reference would be helpful ;-).

Thanks, --David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 16, 2016 11:47 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Update to UDP Guidelines (rev -08) --- RTG area input
> 
> 
> GF: I checked the tunnel draft and other discussions and didn't feel there
> GF: I also increased the clarity of the "applicability" subsection.
>