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

Lucy yong <lucy.yong@huawei.com> Thu, 29 September 2016 14:02 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C12D12B54F; Thu, 29 Sep 2016 07:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.537
X-Spam-Level:
X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KOI62uxyLii; Thu, 29 Sep 2016 07:02:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF8212B54E; Thu, 29 Sep 2016 07:02:03 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXD14691; Thu, 29 Sep 2016 14:02:01 +0000 (GMT)
Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 29 Sep 2016 15:02:00 +0100
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 29 Sep 2016 07:01:56 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: Ben Campbell <ben@nostrum.com>
Thread-Topic: Ben Campbell's No Objection on draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)
Thread-Index: AQHSGfnCQ1E/FQ9jQUit1/aRY1BFH6CQQIwggAA9l0A=
Date: Thu, 29 Sep 2016 14:01:55 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572DBA2D@dfweml501-mbb>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.156.72]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.57ED1ED9.021D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 198dab043e3efa85a27bca9d70e2e448
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ZSi1Nyo4C0lljAXHLO-j9n1slUU>
Cc: "david.black@emc.com" <david.black@emc.com>, "draft-ietf-tsvwg-gre-in-udp-encap@ietf.org" <draft-ietf-tsvwg-gre-in-udp-encap@ietf.org>, The IESG <iesg@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
Subject: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2016 14:02:14 -0000

Hi Ben,

Thank you for the further suggestions. Please see inline to the resolution.

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Wednesday, September 28, 2016 9:32 PM
To: Lucy yong
Cc: The IESG; david.black@emc.com; tsvwg-chairs@ietf.org; tsvwg@ietf.org; draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: Re: Ben Campbell's No Objection on draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)

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.
[Lucy] A great improvement. I like it. (carry)


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] Today tunnel implementation itself does not have the ability to detect if it is running over the Internet or off-Internet. (for future tech?) It is the user responsibility to determine which type of the tunnels to use based on the type of delivery network. This is similar to a rule for a vehicle on the road.  

[Lucy] how about adding the following in the last of Section 2?

Note: although the document specifies two types of GRE-in-UDP tunnel according to the usage environment. The tunnel implementation itself has no ability to detect where it is used. Therefore it is user responsibility to govern 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?
> [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?
[Lucy] For example, for a reason, IPsec may be preferred to use.

>
> - 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.
[Lucy] OK, will keep the original.
>
> -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.) 

[Lucy] Proposed the new text for Section 8 to address all your concerns. 
 
NEW: 8. Congestion Considerations
Section 3.1.9 of [RFC5405bis] discusses the congestion considerations for design and use of UDP tunnels; this is important because other flows could share the path with one or more UDP tunnels, necessitating congestion control [RFC2914] to avoid distractive interference.

Congestion has potential impacts both on the rest of the network containing a UDP tunnel, and on the traffic flows using the UDP tunnels. These impacts depend upon what sort of traffic is carried over the tunnel, as well as the path of the tunnel. The GRE-in-UDP tunnel protocol does not provide a congestion control mechanism and runs as a general UDP application. Therefore, a GRE-in-UDP tunnel MUST NOT carry non-congestion controlled traffic over the Internet.  

A GRE-in-UDP tunnel can be used to carry traffic that is known not to be congestion controlled in a TMCE network. For example, a GRE-in-UDP tunnel may be used to carry Multiprotocol Label Switching (MPLS) that carries pseudowire or VPN traffic where specific bandwidth guarantees are provided to each pseudowire or to each VPN. In such cases, network operators may avoid congestion by careful provisioning of their networks, by rate limiting of user data traffic, and traffic engineering according to path capacity.

When a GRE-in-UDP tunnel carries traffic that is not known to be congestion controlled in a TMCE network, the tunnel MUST be used within the network only, measures SHOULD be taken to prevent the GRE-in-UDP traffic from "escaping" the network to the general Internet, e.g.:
o	Physical or logical isolation of the links carrying GRE-in-UDP from the general Internet.
o	Deployment of packet filters that block the UDP ports assigned for GRE-in-UDP.
o	Imposition of restrictions on GRE-in-UDP traffic by software tools used to set up GRE-in-UDP tunnels between specific end systems (as might be used within a single data center) or by tunnel ingress nodes for tunnels that don’t terminate at end systems. 

>
> -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] please let me know if the new text of Section 8 above is acceptable?

>
> -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?
[Lucy] Get it. How about: either UDP checksum or GRE checksum MUST be used for GRE-in-UDP with both IPv4 and IPv6.

Lucy