Re: [Int-area] Questions about INT Area Tunnels draft: aft-ietf-intarea-tunnels-09

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 17 April 2019 06:58 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F088120052 for <int-area@ietfa.amsl.com>; Tue, 16 Apr 2019 23:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 ccz8iENL_v57 for <int-area@ietfa.amsl.com>; Tue, 16 Apr 2019 23:58:42 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 567FD120044 for <int-area@ietf.org>; Tue, 16 Apr 2019 23:58:42 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BF8131B00210; Wed, 17 Apr 2019 07:58:36 +0100 (BST)
Message-ID: <5CB6CE9B.80508@erg.abdn.ac.uk>
Date: Wed, 17 Apr 2019 07:58:35 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Joe Touch <touch@strayalpha.com>
CC: int-area <int-area@ietf.org>, Mark Towsley <townsley@cisco.com>
References: <5CB5BC5E.7000806@erg.abdn.ac.uk> <7FCE9447-1B38-4C14-AEB4-79289CDCB0C8@strayalpha.com>
In-Reply-To: <7FCE9447-1B38-4C14-AEB4-79289CDCB0C8@strayalpha.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/GAmC6TiAGxj8HOJn1dhRgUoK1fM>
Subject: Re: [Int-area] Questions about INT Area Tunnels draft: aft-ietf-intarea-tunnels-09
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2019 06:58:46 -0000

Please see below.

On 16/04/2019, 16:28, Joe Touch wrote:
> Hi, Gorry,
>
> Again, thanks for the detailed comments. We welcome them!
>
> Responses below...
I'll comment a little more on some of these.
>> On Apr 16, 2019, at 4:28 AM, Gorry Fairhurst<gf@erg.abdn.ac.uk>  wrote:
>>
>>
>> I have read draft-ietf-intarea-tunnels-09, because it is cited from another document that I am reviewing. I have a number of technical questions that I’d like to pass to the WG/editors for consideration.
>>
>> Best wishes,
>>
>> Gorry
>>
>> (I also earlier posted some editorial comments.)
>>
>>
>> *** Technical questions:
>>
>> In section 4.1.1:
>> “Similarly, the DF field of the
>> transit packet is not related to that field in the tunnel link packet
>> header (presuming both are IPv4) “
>> - Why is this not true when IPv4 and IPv6 are used in combination to tunnel one over the other?
> Because IPv6 has no DF field. DF on DF matters only when both headers have DF ;-)
>
> IPv6 is always DF, so there are cases to explain, though.
>
> I can make that more clear.
Yes, that makes sense ;-)
>> ---
>> In section4.2.1:
>> “The high cost of
>> fragmentation and reassembly is why it is useful for applications to
>> avoid sending messages too close to the size of the tunnel path MTU
>> [Ke95], although there is no signaling mechanism that can achieve
>> this (see Section 4.2.3).”
>> - This sentence seems like teh cost is just segmentation/reassembly costs. It's more complex we you wish to defend from attack and need to keep state in devices. So the original paper cited is just one part of the whole problem space. This ID seems to help clarify some of these issues: [I-D.ietf-intarea-frag-fragile-09].
> As an aside, IMO, that document is a thinly veiled attempt to deprecate fragmentation that I continue to have concerns over.
I just sent my transport review of that draft to the list. It looks like 
both will be reaching maturity about the same time. It would be really 
nice if they could in some way be aligned - e.g., I think there is a 
possibility that the IETF could both discourage application designs 
using fragmentation and encourage appropriate endpoint sizing, while 
acknowledging the need for fragments for tunnels. Whatever the INT Area 
concludes, the recommendation is going to impact transport and network, 
and there needs to be consistent advice to be useful. (I suggested there 
is an opportunity that these could be published as a document pair in 
the RFC-series, that was my own thought, but it would require some work 
now to get to that place.)
> That said, this sentence describes the problem of trying to tune closely to the tunnel path MTU; the attack and state issues in frag-fragile aren’t affected by whether a 2000B packet is split into 1280 and 720 or 1000 and 1000. It basically implies (though it could be more clear) that 1280 and 720 is a bad choice because the 1280 could later end up being fragmented into 1200, 80, and 720 (as a set) vs 1000 and 1000 if then going over a tunnel that needs to fragment to support 1280.
I agree, headroom in the size that is actually used is important: The 
maximum packet size used doesn't have to be the currently measured PMTU.
>
> This can happen when you do PMTUD one hop at a time or even if you do the entire path with PMTUD if path properties change even a little (see below).
Yes.
>> - If you probed with context, as in (D)PLPMTUD you could achieve this signal?
> You could but see above - the issue is trying to over-tune, not whether you can tune or not.
>> Some further context on how to build more robust solutions is in [I-D.ietf-tsvwg-datagram-plpmtud].Using that approach I don’t see why that is the case - maybe my question is because section 4.2.3 is exclusively about PMTUD, and not PLPMTUD?
> It wasn’t intended that way - it doesn’t matter how you find out, if you tune too close you end up running risks due to path changes, tunnel overhead changes, etc. too - even if you do it for the full path (PLPMTUD) vs each hop one at a time (PMTUD).
OK -  if you wish to focus on the need to be more resillient to changes 
in the path, that would be reasonable argument to make.
>> ---
>> In section 4.2.2:
>> “Although many of these issues with tunnel fragmentation and MTU
>> handling were discussed in [RFC4459]”
>> - What is the relationship to the ID on Fragmentation Fragile [I-D.ietf-intarea-frag-fragile-09]?
> Well, to start with I’m not trying to deprecate fragmentation — in fact, this document is a good reason why that can’t happen...
>> - The present document in 5.3.1. states: “Always include frag support for at least two frags; do NOT try to deprecate fragmentation.“, which seems to be slightly incompatible with the other WG document?
> Yes, IMO it is if you interpret frag-fragile as deprecating fragmentation (as I do, though the authors continue to claim isn’t really true - they’re just trying to get fragmentation to not be used, rather than to outlaw it).
>
My reading of ietf-intarea-frag-fragile suggests this doesn't deperacate 
fragementation, but advises strongly against - but you should read and 
form your own opinion.
>> ---
>> In section 4.3.2:
>> - I think the following is open to misinterpretation and that concerns me, itdoes not seem strong enough::
>> “ Tunnels carrying IP traffic (i.e., the focus of this document) need
>> not react directly to congestion any more than would any other link
>> layer [RFC8085].”
>> - This refers to the UDP-Guidelines as BCP, which is OK, but if that is a reference then please more precisely quote the text in that RFC that says:
>> “Two factors determine whether a UDP tunnel needs to employ specific
>> congestion control mechanisms: first, whether the payload traffic is
>> IP-based; and second, whether the tunneling scheme generates UDP
>> traffic at a volume that corresponds to the volume of payload traffic
>> carried within the tunnel.”
>> - Is it posisble to also add a cition the detailed guidance in section 3.1.11 of RFC8085?
> Yes.
>
>> - It would be good to say [RFC2914] describes the best current practice for congestion control. Would that be OK?
> Sure.
>
>> - Please also consider citing [RFC8084] as a way to provide network tunnels and applications when using non-congestion-controlled traffic, to illustrate what can be done to realise some form of protection.
> Absolutely - again, many of these docs didn’t exist when I started, so it’s very helpful to catch up this way…
>
>> ---
>> In section 4.3.3:
>> - The section in Multipoint Tunnels and Multicast has no statement about unicast tunnels carrying multicast. I think this is a common deployment scenario. Is it possible to add something explicit, like:
>> “Tunnels that carry IP multicast traffic with a unicast destination address, such as Automatic Multicast Tunneling [RFC7450] need to follow the same requirements as a tunnel carrying unicast data”
>> - Do you think this is a fair recommendation? or have some other idea?
> I’d have to think about this a little more, but yes, a recommendation in this area would be useful.
If you want an example, I looked back at RFC8085, and it more or less 
says that
>> ---
>> In section 8:
>> There are some references that I think need to be checked and referenced more:
>> [I-D.ietf-tsvwg-ecn-encap-guidelines]
>> [I-D.ietf-tsvwg-rfc6040update-shim]
>> [I-D.ietf-tsvwg-datagram-plpmtud]
>> [I-D.ietf-intarea-frag-fragile-09]?
> Thanks again - these are helpful.
>
>> ---
>> In section 8.1:
>> - I think there needs to be more normative references, especially on the documents where this recommends a change, or RFC2119 usage.
> Agreed - I also think it’s likely this doc will end up UPDATING a lot of these docs where there are such explicit errors.
>
> That may create a WG problem though - I don’t know if a BCP can update a STANDARD, but that’s for the WG and IESG to figure out, IMO…
>
> ---

I have thoughts on the best process, but I'll let others comment. That's 
indeed an INTAREA WG/IESG issue - if they are updates to transport area 
RFCs/IDs then I do have opinions on best to approach this!

Gorry