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

"Ben Campbell" <ben@nostrum.com> Mon, 03 October 2016 21:22 UTC

Return-Path: <ben@nostrum.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 CF6D3129578; Mon, 3 Oct 2016 14:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 qjgtahceEZE8; Mon, 3 Oct 2016 14:22:01 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0549129589; Mon, 3 Oct 2016 14:21:30 -0700 (PDT)
Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u93LLK6E060573 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 3 Oct 2016 16:21:21 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21]
From: Ben Campbell <ben@nostrum.com>
To: Lucy yong <lucy.yong@huawei.com>
Date: Mon, 03 Oct 2016 16:21:20 -0500
Message-ID: <4F80B1F1-93E8-4B46-B515-334044379A89@nostrum.com>
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572DBA2D@dfweml501-mbb>
References: <2691CE0099834E4A9C5044EEC662BB9D572DBA2D@dfweml501-mbb>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/zp98QI1IpnKXn_VrDaAvVjZULXY>
Cc: "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "david.black@emc.com" <david.black@emc.com>, The IESG <iesg@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "draft-ietf-tsvwg-gre-in-udp-encap@ietf.org" <draft-ietf-tsvwg-gre-in-udp-encap@ietf.org>
Subject: Re: [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: Mon, 03 Oct 2016 21:22:03 -0000

Hi,

More comments inline. I removed parts that do not seem to need further 
discussion.

Thanks!

Ben.

On 29 Sep 2016, at 9:01, Lucy yong wrote:

[...]

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

That would help. Am I correct to assume that the implementation 
simularly does not know if traffic is congestion-controlled?

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

Would it make sense to say that DTLS MUST be used when security is a 
concern, unless other mechanisms that provide the same level of 
protection are used instead?

[...]

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

"known not to be" or "not known to be"?  That is, what if you don't know 
one way or the other?

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

I suggest "MUST NOT be used outside the network". (Constructs of the 
form of "MUST ... ONLY..." can be ambiguous. It usually work better to 
use "MUST NOT...")

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

I think that's better (other than a couple of minor suggestions imbedded 
above).

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

Yes, thanks.

[...]