Re: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)

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

Hi, thanks for the response. Comments also inline, with sections removed 
that do not seem to need further discussion.

Thanks!

Ben.

On 27 Sep 2016, at 13:53, Lucy yong wrote:

[...]



>
>
> -1, paragraph 5, first sentence: I found the sentence structure 
> confusing. I think you mean to say that GRE-in-UDP tunnels are not 
> safe to carry arbitrary traffic over the Internet, but it can be read 
> to mean to say that since the internet is an arbitrary traffic 
> environment, it's not safe to use GRE-in-UDP on it.
> [Lucy] OLD: In full generality with the capability to carry arbitrary 
> traffic, GRE-in-UDP tunnels are not safe for general deployment in the 
> public Internet. Therefore GRE-in-UDP tunnel deployments are limited 
> to two applicability scenarios for which requirements are specified in 
> this document:
> NEW: A GRE-in-UDP tunnel is capable of carrying arbitrary traffic and 
> behaves as a general UDP application on an IP network. However a 
> GRE-in-UDP tunnel carrying a type of traffic may not meet the UDP 
> application requirements on the Internet [RFC5405bis], such GRE-in-UDP 
> tunnels MUST NOT run over Internet. For this reason, the document 
> specifies two deployment scenarios for GRE-in-UDP tunnels and 
> specifies the GRE-in-UDP tunnel requirements for each of them, 
> respectively. The two scenarios are:

That helps. I suggest a slight tweak:

OLD (your-new):
     However a GRE-in-UDP tunnel carrying a type of traffic may not meet 
the UDP application
     requirements on the Internet [RFC5405bis], such GRE-in-UDP tunnels 
MUST NOT run over Internet.

NEW (newer-new):
     However a GRE-in-UDP tunnel carrying certain types of traffic may 
not meet the UDP application
     requirements on the Internet [RFC5405bis]. GRE-in-UDP tunnels MUST 
NOT cary such traffic
     over the Internet.


Now, that brings a question to mind. Is the tunnel implementation 
expected to police this? Or is an application expected to know whether a 
tunnel crosses an unsafe network? I suspect the answer is that we expect 
administrators to configure things so that this doesn't happen. But 
whatever the answer, it would be helpful to mention it in the text.





>
> -1, paragraph 6: When might security not be a concern? Would it make 
> sense to start with an assumption that security _is_ a concern, then 
> consider situations for which it might not be?
> [Lucy] OLD:  The document also specifies Datagram Transport Layer 
> Security (DTLS) for GRE-in-UDP tunnels to be used where/when security 
> is a concern.
> NEW: To provide origin traffic privacy and security, the document 
> specifies Datagram Transport Layer Security (DTLS) for GRE-in-UDP 
> tunnels. A GRE-in-UDP tunnel with DTLS SHOULD be used where/when 
> origin traffic security is a concern.

Would it be fair to say it MUST be used when security is a concern? 
Otherwise, can you suggest circumstances where security is a concern 
where it might reasonable not to use it?

>
> - 6.1, paragraph 1: Previous sections said UDP checksums SHOULD be 
> used for IPv4. Should this section be interpreted to mean that _if_ 
> the checksum is used, it MUST be processes this way? If so, that could 
> use clarification.
> [Lucy] Yes, this interpretation is right. Will this change avoids a 
> mis-interpreation?
> OLD: For UDP in IPv4, the UDP checksum MUST be processed as specified 
> in [RFC768] and [RFC1122] for both transmit and receive.
> NEW: For UDP in IPv4, when UDP checksum is used, the UDP checksum 
> process MUST follow the procedures specified in [RFC768] and [RFC1122] 
> for both transmit and receive.

Yes, that helps.

> 	
> -6.2, paragraph 2: Does the allowance to use the zero-checksum in some 
> cases violate the MUST for UDP checksums over IPv6?
> [Lucy] suggest the following change to clear this ambiguity.
> OLD: For UDP in IPv6, the UDP checksum MUST be processed as specified 
> in [RFC768] and [RFC2460] for both transmit and receive.
> NEW: For UDP in IPv6, when UDP checksum is used, the UDP checksum 
> process MUST follow the procedures specified in [RFC768] and [RFC2460] 
> for both transmit and receive.

Actually, I was referring to a previous statement that checksums MUST be 
used for IPv6. But now when I look back at that, I realize it was for 
"generic" tunnels, not TMCE tunnels. I think your proposal is a slight 
improvement, but no change is really necessary.
>
> -8, third paragraph:
> Isn’t this just a restatement of the previous requirement that all 
> traffic carried over default gre-in-udp tunnels must be congestion 
> controlled?
> [Lucy] yes. Congestion considerations in this section considers two 
> deployment scenarios. This statement is for Internet scenario. 
> Although it is a repeat from previous requirement, IMO: it is 
> necessary to state it here for a default-GRE-in-UDP tunnel use case.

My concern is not that it the concept is restated here, it's that both 
use 2119 keywords, but in different ways that people may find confusing. 
My suggestion is to simply state this version without the upper case MAY 
(that is, make the "MAY" a "may"). If yo really want to have both 
versions use 2119 language, then it would better to use the same 
language (i.e. MUST NOT carry non-congestion-controlled traffic.)

>
> -8, paragraph 5:
> This also seems a restatement of the requirement that traffic on 
> generic tunnels MUST be congestion controlled. Given that you probably 
> don’t select your network path based on the nature of the data, I 
> think it’s better stated in the original terms.
> [Lucy] this paragraph considers a TMCP GRE-in-UDP tunnel, which means 
> a gre-in-udp tunnel used in TMCE network. For this case, traffic on 
> the tunnel is not required to be congestion controlled. The text is 
> clearly stated. In addition, it states operation needs to consider how 
> to avoid gre-in-udp encapsulated traffic in escaping to the Internet. 
> Sorry, not clear what to change to make it clearer.

Let me simplify my. The text seems to say that TMCE tunnels MUST be TMCE 
tunnels. The MUST doesn't add anything that hasn't already been 
normatively said.

[...]

>
> -11, last paragraph: Is SHOULD sufficient for this case?
> [Lucy] IMO: for the header corruption reason, the mechanism stated in 
> paragraph is sufficient to avoid the original traffic to be 
> mis-delivered to another application. That addresses a privacy and 
> security concern.

Let me restate the question: Why SHOULD and not MUST? Can you imagine a 
circumstance when the GRE header _is_ used for privacy or security where 
it might be a reasonable choice to _not_ use a UDP or GRE checksum?