Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'
Hi, all,
On 8/30/2018 8:29 AM, Templin (US), Fred L wrote:
>>> Section 3.2.1:
>>> Final paragraph beginning: "IP protocol number 59 ("No next header") can be
>>> set
>>> to indicate that the GUE payload does not begin with the header of an IP
>>> protocol."
>>> The example given was GUE fragmentation, but would that not represent a
>>> departure from the way things are done for IP fragmentation? I believe in
>>> IP fragmentation the protocol field contains the same value for both initial
>>> and non-initial fragments. Is there a reason for the departure here?
>> Yes. GUE allows a node to skip over the GUE header to inspect the
>> encapsulated payload, For instance, a firewall may be looking for an
>> inner IP destination in an encapsulated packet. The GUE payload is
>> interpreted based on the protocol in the Proto/ctype field. So if the
>> payload is not a parseable IP protocol (like it would be for a
>> non-first GUE fragment), then 59 is used to avoid devices trying to
>> parse it.
> I am OK with ipproto-59. In hindsight, maybe IP fragmentation should have
> adopted a similar convention when it was specified so many decades ago.
FWIW, IP fragmentation copies the IP header in each fragment because
that field is part of the context for the ID field; i.e., ID MUST be
unique within src/dst/proto. If fragments had a different proto field,
it would undermine that context.
Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
[Int-area] I-D Action: draft-ietf-intarea-gue-extensions-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group WG of the IETF. Title : Extensions for Generic UDP Encapsulation Authors : Tom Herbert Lucy Yong Fred L. Templin Filename: draft-ietf-intarea-gue-extensions-05.txt Pages : 40 Date: 2018-08-31 Abstract: This specification defines a set of the initial optional extensions for Generic UDP Encapsulation (GUE). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gue-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-gue-extensions-05 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-extensions-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-extensions-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] I-D Action: draft-ietf-intarea-gue-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group WG of the IETF. Title : Generic UDP Encapsulation Authors : Tom Herbert Lucy Yong Osama Zia Filename: draft-ietf-intarea-gue-06.txt Pages : 38 Date: 2018-08-31 Abstract: This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of different IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such as tunnels and overlay networks for network virtualization, can be constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gue/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-gue-06 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
> On Aug 31, 2018, at 9:38 AM, Tom Herbert wrote: > >> On Fri, Aug 31, 2018 at 8:56 AM, Joe Touch wrote: >> >> >> On Aug 31, 2018, at 8:44 AM, Tom Herbert wrote: >> >> >> Joe, >> >> There is an alternative: don't use NAT! >> >> >> Agreed - that should also be part of the observations of this doc. >> >> Yes, something needs to be done, but I argue that *until we have a worked >> alternative*, we need to keep restating the fact - NATs/firewalls MUST >> reassemble to work properly; where they don’t, the error is on them - not >> the rest of the Internet for using fragments. >> >> >> Reassembly could only be a MUST for NAT, not firewalls. >> >> >> “or its equivalent" >> >> NAT might be >> required because of the identifier space issue, however we already >> shown how a firewall can achieve proper functionality without >> reassembly and to be stateless by forwarding fragments and potentially >> dropping the first one that contains port information being filtered. >> >> >> First, firewalls that port-filter need to do the same thing as a NAT in >> terms of keeping state. >> >> The fact that this might forward fragments that are never reassembled >> is at best an optimization with unproven benefit. >> >> >> ATM proved otherwise in numerous published studies in the late 1980s. Those >> fragments compete for bandwidth further along the path; anytime they “win”, >> that decision is not work-conserving. >> > ATM from the 1980s? Is there any evidence that this is a real problem > impacting users in this century? Not until we instrument and measure these boxes. But that doesn’t mean a 30yr old KNOWN problem won’t repeat. > >> Note that keeping some state is already needed (if port-filtering) and that >> - as you note - the state filtering need not be “perfect”. However, it >> really ought to be SHOULD at least. >> >> >> There is another case where in-network reassembly could be required >> which is load balancing to a virtual IP address. >> >> >> Any middlebox that uses state not available in all fragments MUST reassemble >> or keep equivalent storage/state to process fragments appropriately. >> > That requirement would include pretty much be applicable to every > router on the planet that does ECMP based on hashing transport ports. > Good luck fixing all of those to do reassembly :-) They need to either reassemble or keep state that equivalently let’s fragments share paths - or the don’t do their job as advertised. Fortunately if they’re just picking among paths that all work it won’t blackhole the traffic. > > >> Like NAT though, in the long run I believe IPv6 offers a better >> solution that would eliminate the need for VIPs. >> >> >> That’s true right up until we end up in a world where (mostly) nobody >> correctly uses flow IDs. Oh, wait - we’re already there… >> > Huh? Who is not correctly flow labels? Lots of endpoints don’t bother using them. > Besides, in IPv6 there's plenty > of address space to that address sharing should be not needed and > routing is sufficient without looking beyond IP header. Address sharing is one reason NATs are used. Others are stateful firewalls (which also exist without NAT) and stateful forwarding (also exists without NAT). All require some level of work beyond the ‘cheap and dirty’ to actually get things correct. Joe > > Tom > >> Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On Fri, Aug 31, 2018 at 8:56 AM, Joe Touch wrote: > > > On Aug 31, 2018, at 8:44 AM, Tom Herbert wrote: > > > Joe, > > There is an alternative: don't use NAT! > > > Agreed - that should also be part of the observations of this doc. > > Yes, something needs to be done, but I argue that *until we have a worked > alternative*, we need to keep restating the fact - NATs/firewalls MUST > reassemble to work properly; where they don’t, the error is on them - not > the rest of the Internet for using fragments. > > > Reassembly could only be a MUST for NAT, not firewalls. > > > “or its equivalent" > > NAT might be > required because of the identifier space issue, however we already > shown how a firewall can achieve proper functionality without > reassembly and to be stateless by forwarding fragments and potentially > dropping the first one that contains port information being filtered. > > > First, firewalls that port-filter need to do the same thing as a NAT in > terms of keeping state. > > The fact that this might forward fragments that are never reassembled > is at best an optimization with unproven benefit. > > > ATM proved otherwise in numerous published studies in the late 1980s. Those > fragments compete for bandwidth further along the path; anytime they “win”, > that decision is not work-conserving. > ATM from the 1980s? Is there any evidence that this is a real problem impacting users in this century? > Note that keeping some state is already needed (if port-filtering) and that > - as you note - the state filtering need not be “perfect”. However, it > really ought to be SHOULD at least. > > > There is another case where in-network reassembly could be required > which is load balancing to a virtual IP address. > > > Any middlebox that uses state not available in all fragments MUST reassemble > or keep equivalent storage/state to process fragments appropriately. > That requirement would include pretty much be applicable to every router on the planet that does ECMP based on hashing transport ports. Good luck fixing all of those to do reassembly :-) > Like NAT though, in the long run I believe IPv6 offers a better > solution that would eliminate the need for VIPs. > > > That’s true right up until we end up in a world where (mostly) nobody > correctly uses flow IDs. Oh, wait - we’re already there… > Huh? Who is not correctly flow labels? Besides, in IPv6 there's plenty of address space to that address sharing should be not needed and routing is sufficient without looking beyond IP header. Tom > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
>> Any middlebox that uses state not available in all fragments MUST reassemble >> or keep equivalent storage/state to process fragments appropriately. This statement is true without question, so the only question is what applications would produce IP fragments that need to be forwarded by a middlebox. We have already seen that ‘iperf3’ produces IP fragments by default on some systems. And, intarea-tunnels makes the case for tunnels. I will also make the case for NAT66. With RFC4193 ULAs, NAT66 will be inevitable, but a middlebox may be able to translate based only on the IPv6 addresses and not transport-layer port numbers. Such a middlebox could forward fragments without having to reassemble or otherwise hold them until all fragments have arrived. Thanks - Fred From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Joe Touch Sent: Friday, August 31, 2018 8:57 AM To: Tom Herbert Cc: int-area ; Toerless Eckert ; intarea-cha...@ietf.org Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile On Aug 31, 2018, at 8:44 AM, Tom Herbert mailto:t...@herbertland.com>> wrote: Joe, There is an alternative: don't use NAT! Agreed - that should also be part of the observations of this doc. Yes, something needs to be done, but I argue that *until we have a worked alternative*, we need to keep restating the fact - NATs/firewalls MUST reassemble to work properly; where they don’t, the error is on them - not the rest of the Internet for using fragments. Reassembly could only be a MUST for NAT, not firewalls. “or its equivalent" NAT might be required because of the identifier space issue, however we already shown how a firewall can achieve proper functionality without reassembly and to be stateless by forwarding fragments and potentially dropping the first one that contains port information being filtered. First, firewalls that port-filter need to do the same thing as a NAT in terms of keeping state. The fact that this might forward fragments that are never reassembled is at best an optimization with unproven benefit. ATM proved otherwise in numerous published studies in the late 1980s. Those fragments compete for bandwidth further along the path; anytime they “win”, that decision is not work-conserving. Note that keeping some state is already needed (if port-filtering) and that - as you note - the state filtering need not be “perfect”. However, it really ought to be SHOULD at least. There is another case where in-network reassembly could be required which is load balancing to a virtual IP address. Any middlebox that uses state not available in all fragments MUST reassemble or keep equivalent storage/state to process fragments appropriately. Like NAT though, in the long run I believe IPv6 offers a better solution that would eliminate the need for VIPs. That’s true right up until we end up in a world where (mostly) nobody correctly uses flow IDs. Oh, wait - we’re already there… Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
> On Aug 31, 2018, at 8:44 AM, Tom Herbert wrote: >> > Joe, > > There is an alternative: don't use NAT! Agreed - that should also be part of the observations of this doc. >> Yes, something needs to be done, but I argue that *until we have a worked >> alternative*, we need to keep restating the fact - NATs/firewalls MUST >> reassemble to work properly; where they don’t, the error is on them - not >> the rest of the Internet for using fragments. > > Reassembly could only be a MUST for NAT, not firewalls. “or its equivalent" > NAT might be > required because of the identifier space issue, however we already > shown how a firewall can achieve proper functionality without > reassembly and to be stateless by forwarding fragments and potentially > dropping the first one that contains port information being filtered. First, firewalls that port-filter need to do the same thing as a NAT in terms of keeping state. > The fact that this might forward fragments that are never reassembled > is at best an optimization with unproven benefit. ATM proved otherwise in numerous published studies in the late 1980s. Those fragments compete for bandwidth further along the path; anytime they “win”, that decision is not work-conserving. Note that keeping some state is already needed (if port-filtering) and that - as you note - the state filtering need not be “perfect”. However, it really ought to be SHOULD at least. > > There is another case where in-network reassembly could be required > which is load balancing to a virtual IP address. Any middlebox that uses state not available in all fragments MUST reassemble or keep equivalent storage/state to process fragments appropriately. > Like NAT though, in the long run I believe IPv6 offers a better > solution that would eliminate the need for VIPs. That’s true right up until we end up in a world where (mostly) nobody correctly uses flow IDs. Oh, wait - we’re already there… Joe___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On Thu, Aug 30, 2018 at 5:26 PM, Joe Touch wrote: > > > On Aug 29, 2018, at 11:19 PM, Christian Huitema wrote: > > Regardless, middleboxes shouldn't be avoiding their own effort by creating > work for others. A corollary to the Postal Principle should be "you make the > mess, you clean it up". > > > Joe's stubborn adherence to the letter of the RFC would be very nice if the > protocol police could somehow punish the merchants of NATs… > > > My concerns are pragmatic - merely not supporting something does not make it > unnecessary. > > There was a time when Internet service in hotels would regularly block all > except basically DNS and HTTP/HTTPS; that’s becoming much less the case. > There was a time when devices didn’t support IPv6 at all because it was > considered merely an unnecessary expense; that’s becoming much less the case > too. > > In this case, we have two problems > 1) NATs/firewalls as currently implemented do not support fragments > 2) our current protocols, in many cases, require fragments (IPsec tunnel > mode) and in other cases (tunnels in general) would benefit from IP > fragmentation support > 3) we DO NOT HAVE an alternative (there are some piece-wise proposals for > various aspects, but none support IPsec tunnel mode and none are otherwise > universal > Joe, There is an alternative: don't use NAT! In a draft that is recommending against using a core IP protocol feature like fragmentation, I think it is entirely appropriate to recommend against using the very features that are breaking it in the first place. IMO, this draft should recommend people use of IPv6 without NAT to resolve the problems with fragmentation caused by NAT. > Yes, something needs to be done, but I argue that *until we have a worked > alternative*, we need to keep restating the fact - NATs/firewalls MUST > reassemble to work properly; where they don’t, the error is on them - not > the rest of the Internet for using fragments. Reassembly could only be a MUST for NAT, not firewalls. NAT might be required because of the identifier space issue, however we already shown how a firewall can achieve proper functionality without reassembly and to be stateless by forwarding fragments and potentially dropping the first one that contains port information being filtered. The fact that this might forward fragments that are never reassembled is at best an optimization with unproven benefit. There is another case where in-network reassembly could be required which is load balancing to a virtual IP address. This is handled in the Maglev load balancer (https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44824.pdf) without employing a synchronization protocol. It is rather complex though and not a solution easily generalized for simple environments. Like NAT though, in the long run I believe IPv6 offers a better solution that would eliminate the need for VIPs. Tom > > The whole discussion reminds me of Martin Thomson's draft, "use it or lose > it" (draft-thomson-use-it-or-lose-it-02). Martin is describing how extension > mechanisms that are not actually used get ossified away by the deployment of > middle-boxes. The same happened long ago with IP segmentation. With NATs, > applications cannot assume that reassembly will work. With Firewalls, > transports cannot assume that ICMP will work. > > > Yes, that’s the tension: > a) identify bugs and fix them > b) accept bugs as de-facto protocol evolution > > The problem with (b) is that it is not guided by what Internet users need; > it’s guided by what is profitable for individual vendors. That path is > hazardous - there’s no reason to believe that the result will be a useful > Internet. So until we know it’s safe to do (b), we need to stick with (a). > > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
