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

From: "Ben Campbell" <[email-masked]>
Date: Mon, 26 Sep 2016 16:13:35 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-gre-in-udp-encap-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting no objection, but I have a few comments that may be worth
considering:

- general: The draft has a structure where you mention requirements in
one section, then go into more detail in later sections. While this is a
perfectly reasonable structure, it has resulted in a fair bit of
redundant 2119 language. In general it's better to avoid that because it
can make future updates more error prone. In this case, most of the
language is consistent, so it's probably not worth changing. But there
are a few cases where the language appears inconsistent, or is restated
in sufficiently different ways to be potentially confusing. I've tried to
call out specifics, but may have missed some.

-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.

-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?

- 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.

-6.2, paragraph 2: Does the allowance to use the zero-checksum in some
cases violate the MUST for UDP checksums over IPv6?

-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?

-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.

-8, last paragraph:
Do circuit-breakers really keep non congestion-controlled traffic from
“escaping”, or does it mitigate the damage if it does escape?

-11, 2nd paragraph: Previous sections just said DTLS can be used if there
are security concerns. This is not consistent with that. (I prefer the
SHOULD to a "can")

-11, last paragraph: Is SHOULD sufficient for this case?

---

From: Lucy yong <[email-masked]>
Date: Tue, 27 Sep 2016 18:53:47 +0000

Hi Ben,

Thank you for the comments. Please see inline below for proposed solutions.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, September 26, 2016 6:14 PM
To: The IESG
Cc: [email-masked]; David L. Black; [email-masked]; [email-masked]; [email-masked]
Subject: Ben Campbell's No Objection on draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

- general: The draft has a structure where you mention requirements in one section, then go into more detail in later sections. While this is a perfectly reasonable structure, it has resulted in a fair bit of redundant 2119 language. In general it's better to avoid that because it can make future updates more error prone. In this case, most of the language is consistent, so it's probably not worth changing. But there are a few cases where the language appears inconsistent, or is restated in sufficiently different ways to be potentially confusing. I've tried to call out specifics, but may have missed some.
[Lucy] thank you for this comment and support. We come a long way to result this structure to serve its purposes. Be happy to fix the inconsistent issues without a restructure.

-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: 

-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.

- 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.
	
-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.

-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.

-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.

-8, last paragraph:
Do circuit-breakers really keep non congestion-controlled traffic from “escaping”, or does it mitigate the damage if it does escape?
[Lucy] good catch. CB is used for traffic rate control, not for preventing traffic from "escaping". CB can be used at a gre-in-udp tunnel if original traffic is not congestion controlled. This can apply both default and TMCE tunnels. Since this draft does not intend to specify a congestion control solution at GRE-in-UDP tunnel, I prefer to not mention CB.

-11, 2nd paragraph: Previous sections just said DTLS can be used if there are security concerns. This is not consistent with that. (I prefer the SHOULD to a "can")
[Lucy] To make consistent in Section 5 and 11, we will use "SHOULD" in Sections. See the thread from Kathleen's comment.

-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.

Thanks/Regards,
Lucy

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 28 Sep 2016 21:32:22 -0500

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:

[...]

> 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.

> [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.
> 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.

> 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.
> [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.

[...]

> [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?