Re: [Int-area] draft-bonica-intarea-frag-fragile-01
On Fri, Jun 1, 2018, 2:54 AM Mikael Abrahamsson wrote: > On Thu, 31 May 2018, Joe Touch wrote: > > > I disagree. > > > > UDP fragmentation has its benefits and uses, but should not be required > when a transport layer isn’t needed - e.g., for IP tunneling. > > > > Fundamentally, IP fragmentation is fragile for only a few reasons: > > 1) the ID space is small (which shouldn’t matter unless there is a very > large amount of reordering) > > 2) loss of fragments creates inefficiencies (true, but routers can > fate-share fragments they drop sometimes, just as was eventually done for > ATM AAL5) > > 3) in-network devices can’t find transport ports in some fragments, > causing problems for NATs, policy filters and firewalls, etc. > > > > Of these, my view is that #3 is the only reason actually driving a claim > of fragility - and all it tells me is that “the Internet is fragile when > devices don’t follow the rules”. > > > > I do not think it is appropriate to validate that conclusion. > > You're fundamentally right, unfortunately operational reality adds lots of > more points to your list, meaning the end outcome is that IP fragmentation > doesn't work well in real life. > > I am as opposed to letting bad practices win as you probably are, but I > also don't think this is fixable. This means applications need to have a > mode where they do not rely on IP fragments for basic operation. > I agree with Joe. Would also note that #3 is not a problem with fragmentation itself, but with middle boxes attempting to parse transport layer information. That problem potentially exists any time a "non-standard" IP protocol number is used (ie something other than UDP it TCP). It would be best if the solution is to use generic mechanisms to provide functionality, as opposed to discouraging use of protocols or fragmentation. Using flow label for ECMP is s good example, this eliminates need for DPI and works with fragmentation or any IP protocol. I think this draft should distinguish problems inherent in IP fragmentation and those that have be created by middle boxes that can't deal with fragments Tom > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello wrote: > More on the mobility use case which also makes deployment options easier to > digest > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ > >From the draft: "The goal of hICN is to ease ICN insertion in existing IP infrastructure by: 3. minor modification to existing IP routers/endpoints;" Can you elaborate on this "minor modification"? Especially for endpoints, which I assume means hosts, what is the scope, the necessary modifications, and deployment model. Also, will applications have to change or use a new API for hICN? If the implication of hICN is that all Internet hosts need to change to support a new consumer/producer communications model, a new transport protocol, and a new application API-- there's nothing minor about that! Tom > > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) > wrote: >> >> This draft is about hICN and discusses various deployment options with >> associated pros and cons, without supporting one specifically. Clearly, >> depending on application requirements, on network constraints, on phase of >> deployment/transition etc. one option may be preferrable over another one >> (and different ones may coexist). >> >> >> One of the described deployment options also discusses combination of hICN >> and SRv6, without opposing one approach to the other, rather exploiting in >> the combination the advantages of both ones. >> >> >> Giovanna >> >> >> From: Int-area on behalf of Behcet Sarikaya >> >> Sent: Wednesday, June 20, 2018 4:18 PM >> To: Luca Muscariello >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> management through hICN (hICN-AMM): Deployment options >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello >> wrote: >>> >>> I wonder whether this conversation should happen in the intarea wg >>> mailing list >>> as the main draft was posted there in the first place. I don't know if >>> cross posting is welcome >>> but I take the risk. >>> >>> Going back to the question, the transport changes are related to the >>> request/reply semantic >>> of the architecture. The two distinct forwarding paths described in the >>> draft take care >>> of forwarding requests or replies.This ends up in the transport layer as >>> a unidirectional >>> channel to recv data or snd data. The replies carry data originating from >>> a transport end-point (snd buffer) >>> that binds to an identifier which is location independent, an IPv6 number >>> which is not a locator. >>> >>> The forwarding path of the requests is very close to unmodified IPv6 with >>> the DST address carrying the identifier. >>> If you check in the draft an hICN node does one additional lookup in a >>> local cache though. But you can ignore that >>> for now for sake of clarity. What is important is the address rewrite >>> operation made on the SRC address >>> of the request. A copy of the request is stored in the local cache and >>> the locator of the output interface is written in the >>> SRC address before transmission. This is used by an upstream hICN or the >>> final end-point to know the locator that >>> will be used to reply. >>> >>> Replies coming from the snd end-point are label swapped but not like >>> MPLS. >>> The label is the identifier itself that is stored in the SRC address of >>> the reply, >>> whereas the DST address is a locator. In this forwarding path a lookup is >>> made in the local cache to >>> find a request (one or many) and the associated locator (one or many) >>> that matches the identifier. >>> The DST addr field of the replies is rewritten with the locator(s) just >>> obtained from the lookup. >>> This is how the reply is forwarded to the end-points that issued requests >>> for this identifier. >>> >>> For the replies there is no FIB lookup on the identifier (as it is in the >>> SRC addr field). >>> There can be a lookup in the FIB on the locator stored in the DST of the >>> reply to >>> reach back the previous hICN node or eventually the original end-point. >>> >>> >>> >> >> >> Hi, >> >> My humble question is: are you supporting SRv6 or hICN? >> >> Regar
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
ket. > The video player can sequentially switch protocol to retrieve the segment. > Not that it make any sense but it's just > to explain that they live in the same end-host. If the app considers that > one transport service can provide > features that are advantageous it can optionally switch to it. > There is no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any other > transport protocol with the consumer/producer > sockets. Okay, but these protocols still need to work in mobile networks, which means in hICN enabled network you still need a mobile infrastructure to handle these "legacy" protocols. That means there are two distinct mobility models needed-- hICN is not simplifying matters in this regard. To me, the hICN story would be a lot more compelling if the transport and network layer are decoupled so there was one solution that provided seamless mobility for everyone in the network regardless of type of transport protocol they use or application that they wish to run. Beyond that, there might be opportunities to improve communications by some coordinated interaction with the network (like we propose in FAST), but these are strictly optimization and not requirements to make basic communications work. Tom > > Luca > > > > On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert wrote: >> >> On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello >> wrote: >> > More on the mobility use case which also makes deployment options easier >> > to >> > digest >> > >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ >> > >> >> From the draft: >> >> "The goal of hICN is to ease ICN insertion in existing IP infrastructure >> by: >> ... >> 3. minor modification to existing IP routers/endpoints;" >> >> Can you elaborate on this "minor modification"? Especially for >> endpoints, which I assume means hosts, what is the scope, the >> necessary modifications, and deployment model. Also, will applications >> have to change or use a new API for hICN? >> >> If the implication of hICN is that all Internet hosts need to change >> to support a new consumer/producer communications model, a new >> transport protocol, and a new application API-- there's nothing minor >> about that! >> >> Tom >> >> > >> > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) >> > wrote: >> >> >> >> This draft is about hICN and discusses various deployment options with >> >> associated pros and cons, without supporting one specifically. Clearly, >> >> depending on application requirements, on network constraints, on >> >> phase of >> >> deployment/transition etc. one option may be preferrable over another >> >> one >> >> (and different ones may coexist). >> >> >> >> >> >> One of the described deployment options also discusses combination of >> >> hICN >> >> and SRv6, without opposing one approach to the other, rather exploiting >> >> in >> >> the combination the advantages of both ones. >> >> >> >> >> >> Giovanna >> >> >> >> >> >> From: Int-area on behalf of Behcet Sarikaya >> >> >> >> Sent: Wednesday, June 20, 2018 4:18 PM >> >> To: Luca Muscariello >> >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> >> management through hICN (hICN-AMM): Deployment options >> >> >> >> >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello >> >> wrote: >> >>> >> >>> I wonder whether this conversation should happen in the intarea wg >> >>> mailing list >> >>> as the main draft was posted there in the first place. I don't know if >> >>> cross posting is welcome >> >>> but I take the risk. >> >>> >> >>> Going back to the question, the transport changes are related to the >> >>> request/reply semantic >> >>> of the architecture. The two distinct forwarding paths described in >> >>> the >> >>> draft take care >> >>> of forwarding requests or replies.This ends up in the transport layer >> >>> as >> >>> a unidirectional >> >>> channel to recv data or snd data. The replies carry data originating >>
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Fri, Jun 22, 2018 at 8:06 AM, Luca Muscariello < luca.muscarie...@gmail.com> wrote: > I answered to 3. Please dig into the reply for the full answer. In short > it is no, it does not. > And BTW, I am aware I'm not providing any analysis and that I'm not trying > to resolve any big thing > in an email thread discussion, I never said I was. > The objective is to answer to clarification questions from list members > about recently posted drafts. > Luca > > #3 is the wrong question to ask. The right question is "Does the new transport protocol disrupt TCP?". Of particular interest, how does the protocol interact with TCP on wire? What is the congestion control of the new transport protocol? How is it "TCP friendly"? As Behcet mentioned, these are not things that can be answered in a few sentences on an email thread. The draft posted seems bereft of any details about the new transport protocol; will another draft be coming that specifies the transport protocol and answers questions like this? Tom > > >> > >> > Back to your questions that I understand this way: >> > 1) What is the hICN socket API? >> > 2) Does hICN imply that all hosts have to change transport stack? >> > 3) Does hICN disrupt the TCP/IP stack in an end host? >>> >> What about 3) here, I don't see any answer to that in the mail. >> >> Also let me state that the analysis you are giving here involves so many >> things like CCN/NDN, Id-Loc, transport layer, network layer >> and so on, let me state that you can not resolve anything about such big >> things within a few sentences. >> >> Behcet >> >>> >> > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Fri, Jun 22, 2018 at 9:15 AM, Luca Muscariello < luca.muscarie...@gmail.com> wrote: > IMHO, there's no such a thing as a wrong question. But you can always ask > another one. > And BTW, I answered already to one of the questions you redo. Yes, there > will be another draft on transport. > It is not ready but I can have a technical report right before the IETF > week and I might give a presentation > at the next ICNRG meeting. That is out of scope for this list I think. > > Yes, it is out of scope for this list. If the intent is to standardize a new transport protocol then that obviously needs to be done in transport area. Honestly, given the immense scope and novelty of what hICN is attempting to do, I have to wonder if this work is better to be done in IRTF. Tom > On the other hand, the draft provides information about how a transport > service sits on top of this > forwarding machinery. There might be several transport protocols of > course, > likewise today there are multiple transport protocols using IPv6, > providing different kind of services. > They can be TCP friendly, they can be lower than best effort such as > LEDBAT vs TCP etc. > > Without loss of generality, I can say that we have one specific > implementation of a transport protocol > that provides reliable transport services. We have used several flow > control laws and algorithms > including AIMD, MIMD, and more recently BBR. > It has been demoed in different venues for some applications > such as MPEG-DASH at SIGCOMM last year and also MWC last year. > Some analysis about that can be found in the following paper. > > J. Samain, et. al > Dynamic Adaptive Video Streaming: Towards a Systematic Comparison of ICN > and TCP/IP. > IEEE Trans. Multimedia 19(10): 2166-2181 (2017) > https://doi.org/10.1109/TMM.2017.2733340 > > Another transport service that we have implemented and that I might demo > during the IETF week > is one used for a scalable RTC system based on WebRTC, Chrome and > Simulcast. > Nothing to do with TCP friendliness of course for this protocol. > > > > On Fri, Jun 22, 2018 at 5:39 PM Tom Herbert wrote: > >> >>> >>> #3 is the wrong question to ask. The right question is "Does the new >> transport protocol disrupt TCP?". Of particular interest, how does the >> protocol interact with TCP on wire? What is the congestion control of the >> new transport protocol? How is it "TCP friendly"? As Behcet mentioned, >> these are not things that can be answered in a few sentences on an email >> thread. The draft posted seems bereft of any details about the new >> transport protocol; will another draft be coming that specifies the >> transport protocol and answers questions like this? >> >> Tom >> > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Fri, Jun 22, 2018 at 2:22 PM, Luca Muscariello wrote: > As of now, we do not intend to standardise anything. > The intended status for this draft is informational as indicated. > > The system described in the draft has actually been around for quite a > while at the IRTF. > It might appear of immense scope and novelty to you as you might not be > aware about the > work done at the IRTF on this topic. > > https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxsemantics/ > https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxmessages/ > https://datatracker.ietf.org/rg/icnrg/documents/ > > ccnx draft are going to IRSG for final approval poll soon and is good > starting point if you're interested. > > On the other hand hICN is an IPv6 forwarding pipeline that realises CCN > semantics in IPv6 > and that is how it is indented to be analysed in this scope. > > When I read the charter of this WG it seems it couldn't be a better fit. > And BTW I have been invited by other list members to share this > information about the topic > in this list. So I did. > > The Internet Area Working Group (INTAREA WG) acts primarily as a forum for > discussing far-ranging topics that affect the entire area. Such topics > include, for instance, address space issues, basic IP layer functionality, > and architectural questions. The group also serves as a forum to distribute > information about ongoing activities in the area, create a shared > understanding of the challenges and goals for the area, and to enable > coordination. [...] > Luca, No where in the int-area charter do I see that transport protocols are in scope. Transport protocols are the domain of transport area. Architectural questions, like whether intermediate devices should be participating in the transport layer protocols or even parsing E2E transport protocols, or whether it's acceptable to create new IP protocol that only works with select transport protocols, might be reasonable questions to pose in int-area I would think. Tom > > Luca > > On Fri, Jun 22, 2018 at 7:38 PM Tom Herbert wrote: > >> >> >> On Fri, Jun 22, 2018 at 9:15 AM, Luca Muscariello < >> luca.muscarie...@gmail.com> wrote: >> >>> IMHO, there's no such a thing as a wrong question. But you can always >>> ask another one. >>> And BTW, I answered already to one of the questions you redo. Yes, >>> there will be another draft on transport. >>> It is not ready but I can have a technical report right before the IETF >>> week and I might give a presentation >>> at the next ICNRG meeting. That is out of scope for this list I think. >>> >>> Yes, it is out of scope for this list. If the intent is to standardize a >> new transport protocol then that obviously needs to be done in transport >> area. Honestly, given the immense scope and novelty of what hICN is >> attempting to do, I have to wonder if this work is better to be done in >> IRTF. >> >> Tom >> >> > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt
On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky wrote: > Dear All, > I hope that this new draft (yes, that's what I wanted to send the first > time) will be of interest to those working on overlay encapsulations. > Appreciate your comments, questions, and suggestions. > Regarding OAM in GUE, the C bit can be set to indicate a control packet which could be OAM (draft-ietf-intarea-gue-05). I imagine that OAM could be implement in one or more ctypes. This is considered an alternative to GUE carrying a data protocol payload, it's not considered part of the GUE header and isn't limited by GUE header len. The statement in Geneve description "transit devices MUST NOT attempt to interpret or process it" is true for all UDP encapsulation protocols. The problem is that encapsulation is determined by destination port number. As described in RFC7605, UDP port numbers only have meaning at the endpoints, so transit devices may incorrectly interpret packets as being an encapsulation. Incorrectly reading a packet as encapsulation might be innocuous, but an intermediate node modifying such a packet that it incorrectly believes is an encapsulation would be systematic data corruption. Because of this, probably the only robust method for in-situ OAM is Hop-by-Hop options. Tom > Regards, > Greg > > -- Forwarded message -- > From: > Date: Thu, Jun 28, 2018 at 9:51 AM > Subject: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt > To: Gregory Mirsky > > > > A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name: draft-mirsky-rtgwg-oam-identify > Revision: 00 > Title: Identification of Overlay Operations, Administration, and > Maintenance (OAM) > Document date: 2018-06-28 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-mirsky-rtgwg-oam-identify-00.txt > Status: > https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam-identify/ > Htmlized: > https://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg-oam-identify > > > Abstract: >This document analyzes how the presence of Operations, >Administration, and Maintenance (OAM) control command and/or special >data is identified in some overlay networks, and an impact on the >choice of identification may have on OAM functionality. > > > > > 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. > > The IETF Secretariat > > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ 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 Tue, Jul 24, 2018 at 3:54 PM, Templin (US), Fred L wrote: > I have an observation that I would like to see addressed in the document. > Some applications > (e.g., 'iperf3' and others) actually leverage IP fragmentation to achieve > higher data rates than > are possible using smaller (but unfragmented) whole packets. > > Try it - by default, iperf3 sets an 8KB UDP packet size and allows packets to > fragment across > paths that support only smaller MTUs. I have seen iperf3 exercise IP > reassembly at line rates > on high-speed links, i.e., it shows that reassembly at high rates is feasible. > > We know from RFC4963 that there are dangers for reassembly at high rates, but > there are > applications such as iperf3 that ignore the "SHOULD NOT" and leverage IP > fragmentation > anyway. So, should the "SHOULD NOT" have an asterisk? > Fred, My reading of the draft is that IP fragmentation is fragile on the open Internet and should be avoided for applications that run over the Internet. That doesn't mean that fragmentation should be avoided in all use cases. In particular, if fragmentation is used in a closed network with low loss and has appropriate security measures in place, then it can be beneficial. I suspect that describes the network that your're running iperf in. If this interpretation of the draft's intent is correct, maybe there could be some words to clarify that. Tom > Thanks - Fred > >> -Original Message- >> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Wassim Haddad >> Sent: Tuesday, July 24, 2018 12:43 PM >> To: internet-a...@ietf.org >> Cc: intarea-cha...@ietf.org >> Subject: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile >> >> Dear all, >> >> We would like to start a WG adoption call for >> draft-bonica-intarea-frag-fragile (“IP Fragmentation Considered Fragile”). >> >> https://www.ietf.org/id/draft-bonica-intarea-frag-fragile-03.txt >> >> >> Please indicate your preferences on the mailling list. The deadline is >> August 10th. >> >> >> Thanks, >> >> Juan & Wassim >> ___ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ 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, Jul 26, 2018 at 12:01 AM, Mikael Abrahamsson wrote: > On Tue, 24 Jul 2018, Templin (US), Fred L wrote: > >> Try it - by default, iperf3 sets an 8KB UDP packet size and allows packets >> to fragment across paths that support only smaller MTUs. I have seen iperf3 >> exercise IP reassembly at line rates on high-speed links, i.e., it shows >> that reassembly at high rates is feasible. >> >> We know from RFC4963 that there are dangers for reassembly at high rates, >> but there are applications such as iperf3 that ignore the "SHOULD NOT" and >> leverage IP fragmentation anyway. So, should the "SHOULD NOT" have an >> asterisk? > > > The iperf3 usage of fragments for UDP testing seems to be platform specific, > at least that's what I've seen. Behaviour has been different on MacOS > compared to Linux. > Mikael, I don't understand what would be platform specific. Can you elaborate? iperf3 is sending UDP packets that are exceeding MTU and packets are being fragmented. For IPv4, this means that DF is not set and packets are being fragmented somewhere in the network, for IPv6 they are being fragmented at the source. I don't believe path MTU discovery is in use by iperf3, so if packets do exceed MTU then the only way they can can be delivered is if fragmented. > Anyhow, I believe we should keep the "SHOULD NOT". This allows applications > that feel they have a good reason to do fragmentation to do so, but doesn't > disallow it. > The text is "Application developers SHOULD NOT develop applications that rely on IPv6 fragmentation.". As Brian said, this requirement does not describe the algorithm, nor is it obvious what it even means for an application developer to knowingly develop an application that relies on IPv6 fragmentation. Besides that, RFC8085, which is referenced in section 5.2, already provides the recommendations that applications should avoid fragmentation by limiting packer size or doing PMTU discovery. I don't see how 7.1 of this draft adds anything to that or is clarifying those recommendations. Tom > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ 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 Wed, Jul 25, 2018 at 7:14 PM, Joe Touch wrote: > Hi, all, > > I still think it would be useful for this doc to describe how tunnels > interact with fragmentation (per draft-ietf-intarea-tunnels), which seems to > be something I’ve noted several times before. > > I’m also still not thrilled with the title I’d be happier with “IP > fragmentation still not supported per requirements”, and I’d have to see > where this goes with final recommendations. > > But I agree *some* statement is worthwhile here. My primary concern is that > if we’re not careful, endorsing the status quo will only ensure nothing > changes. > > So I sincerely hope that some of the strongest recommendations here are that > both direct IP devices and tunnel ingress/egress devices need to do a better > job of supporting fragmentation, and that protocol/device designers SHOULD > avoid mechanisms that are not compatible with fragmentation (e.g., NAT or DPI > without doing reassembly first). > I agree. Specifically, I think there should be a requrement that intermediate devices don't rely on doing DPI into transport layer, or if they need it then they should do some sort of pseudo reassmbly as Joe alludes to. Note that section 4.4 describes the problem of of fragmentation going through a load balancing (e.g. ECMP) where transport ports are used in the algorithm. This is solved in IPv6 by using flow label in the hash instead of transport layer ports, so I think that use of flow label for this purpose should be recommended somewhere in section 7. Tom > Joe > >> On Jul 24, 2018, at 12:42 PM, Wassim Haddad >> wrote: >> >> Dear all, >> >> We would like to start a WG adoption call for >> draft-bonica-intarea-frag-fragile (“IP Fragmentation Considered Fragile”). >> >> https://www.ietf.org/id/draft-bonica-intarea-frag-fragile-03.txt >> >> >> Please indicate your preferences on the mailling list. The deadline is >> August 10th. >> >> >> Thanks, >> >> Juan & Wassim >> ___ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ 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, Jul 27, 2018 at 6:32 AM, Mikael Abrahamsson wrote: > On Fri, 27 Jul 2018, Ole Troan wrote: > >> There's nothing intrinsic in tunnels that require network layer >> fragmentation. The current IP in IP / GRE etc tunnel implementations do, but >> in principle we could design tunnel fragmentation/reassembly above the >> network layer. GUE defines that. Fragementation is done within the encapsulation layer so that it is transparent to the network. > > > This is what I do with OpenVPN for instance. I tell it to application layer > fragment at ~1400 bytes, so the resulting packets always are significantly > below 1500 bytes. So even as the inside of the tunnel is 9000 MTU clean, it > never results in IP fragments to be transported. > I don't think that can be called a general approach. Setting MTU to 1400 bytes only avoids fragmentation if all the tunnel headers being inserted are less than 100 bytes. If you start using more tunnel options or the tunnel ingress inserts extension headers then that 100 byte budget may be exceeded may be exceeded. So a requirement to avoid fragmentation in this manner would have to be that the MTU needs to be low enough to account for all possible encapsulation overhead that may be applied to a packet-- the emerging use of in-situ OAM, segment routing, and even just switching from IPv4 to IPv6 for the underlay puts downward pressure on MTUs. Lowering the MTU increase ratio of overhead to user data thus making communications less efficient. Fragmentation for tunneling is a special case since tunnels are often used within a controlled network and precisley two fragments are always generated. I know of at least one very large data center that relies on fragmentation for tunneling. It seems to work fine in such an environment and is preferable to lowering the MTU for everyone (even non-tunnels) or turning on jumbo frames (complex to do at large scale). Tom > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ 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, Jul 27, 2018 at 5:38 AM, Fernando Gont wrote: > Hi, Joe, > > On 07/26/2018 04:14 AM, Joe Touch wrote: >> Hi, all, >> >> I still think it would be useful for this doc to describe how tunnels >> interact with fragmentation (per draft-ietf-intarea-tunnels), which seems to >> be something I’ve noted several times before. >> >> I’m also still not thrilled with the title I’d be happier with “IP >> fragmentation still not supported per requirements”, and I’d have to see >> where this goes with final recommendations. >> >> But I agree *some* statement is worthwhile here. My primary concern is that >> if we’re not careful, endorsing the status quo will only ensure nothing >> changes. > > FWIW, I see and understand your point. However, based on the operational > implications of fragmentation, it believe it is *extremely* unlikely > that the situation improves (if at all possible). > > So my take is that this I-D rather than endorsing the status quo, is > essentially warning possible users of what it may happen with their > fragmented traffic. > > Side coments: > > It would all seem that there are two operating environments: > * Controlled environments, where you can somehow make all this work > * Public internet, which is more of a "fingers crossed" thing (if anything). > > I'm not saying that I'm happy with the outcome, but rather that I think > that from an engenering point of view, it all looks like this ship has > sailed, and we should probably figure out how to deal with those cases > where fragmentation is actually needed. > Fernado, Couldn't that same line of thinking be applied to several other protocol features? So has the ship sailed for out ability to ever use extension headers or any protocol other than TCP (and sometimes UDP)? Maybe documents that recommend operational workarounds should distinguish problems that inherent in the protocol from those that have arisen because of non-conformant implementation. It's true that calling implementations that probably won't help to fix what is out there, but maybe this could help prevent new instances of non-conformance. Tom > Thanks! > > Cheers, > -- > Fernando Gont > e-mail: ferna...@gont.com.ar || fg...@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ 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, Jul 27, 2018 at 9:25 AM, Fernando Gont wrote: > On 07/27/2018 05:15 PM, Tom Herbert wrote: >> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont wrote: >>> Hi, Joe, >>> >>> On 07/26/2018 04:14 AM, Joe Touch wrote: >>>> Hi, all, > [] >>> >>> Side coments: >>> >>> It would all seem that there are two operating environments: >>> * Controlled environments, where you can somehow make all this work >>> * Public internet, which is more of a "fingers crossed" thing (if anything). >>> >>> I'm not saying that I'm happy with the outcome, but rather that I think >>> that from an engenering point of view, it all looks like this ship has >>> sailed, and we should probably figure out how to deal with those cases >>> where fragmentation is actually needed. >>> >> Fernado, >> >> Couldn't that same line of thinking be applied to several other >> protocol features? > > Yes, indeed. > > >> So has the ship sailed for out ability to ever use >> extension headers or any protocol other than TCP (and sometimes UDP)? > > It would seem that that's the case, yes. > > >> Maybe documents that recommend operational workarounds should >> distinguish problems that inherent in the protocol from those that >> have arisen because of non-conformant implementation. It's true that >> calling implementations that probably won't help to fix what is out >> there, but maybe this could help prevent new instances of >> non-conformance. > > I kind of agree with you. That path from spec to implementation is what > you'd call engineering (or what others might call "taking shortcuts", etc.). > > For example, what happens with EHs has a lot to do with engineering: > they could be made to work (e.g., remove performance impact), but > devices would probably be more expensive. Folks buying gear wouldn't pay > for something that its not used in practice, and vendors wouldn't just > "improve" the boxes for free. -- yeah, you could argue that "hey, there > shouldn't be penalties for EHs, since they are part of the core IPv6 > spec" -- but, while probably correct, that will not change reality. > Fernando, The irony is thatxtension headers (and alternative protocols as well), including fragmentation, aren't supposed to have to "be made to work" in intermediate devices. With the exception of Hop-by-Hop options they are supposed to be ignored by design, and even in the case of Hop-by-Hop options RFC8200 relaxed the requirements so that they can be ignored. Extension headers are considered problematic only because of ad hoc assumptions made for "value add", non-standard features implemented in intermediate devices. > Not that I like the situation, but... I think the least we can do is to > do a reality check wrt how things are supposed to work vs. how they > actually work. > > For this particular case, this I-D makes that point for fragmentation: I > I think we all agree that fragmentation is fragile -- making that point > clear at least raises awareness of the problem, and might trigger some > action on the topic (whether to correct the issue, or to circumvent it). > Right, but I still think that we should be more clear about the root origin of problems and blunt in requesting that non-conformant implementations get fixed. For instance, as I mentioned the ECMP hasing problem with fragmentation is entriely solvable if only intermediate devices will use flow label instead of trying to find ports for a hash. Fixing devices to support this reasonable and should be low cost. IMO, use of flow label for ECMP should be a strong recommendation made in this draft. Tom > Thanks, > -- > Fernando Gont > e-mail: ferna...@gont.com.ar || fg...@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > ___ 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, Jul 27, 2018 at 11:54 AM, Fernando Gont wrote: > Tom, > > On 07/27/2018 07:20 PM, Tom Herbert wrote: > [] >>> >>> For example, what happens with EHs has a lot to do with engineering: >>> they could be made to work (e.g., remove performance impact), but >>> devices would probably be more expensive. Folks buying gear wouldn't pay >>> for something that its not used in practice, and vendors wouldn't just >>> "improve" the boxes for free. -- yeah, you could argue that "hey, there >>> shouldn't be penalties for EHs, since they are part of the core IPv6 >>> spec" -- but, while probably correct, that will not change reality. >>> >> Fernando, >> >> The irony is thatxtension headers (and alternative protocols as well), >> including fragmentation, aren't supposed to have to "be made to work" >> in intermediate devices. With the exception of Hop-by-Hop options they >> are supposed to be ignored by design, and even in the case of >> Hop-by-Hop options RFC8200 relaxed the requirements so that they can >> be ignored. Extension headers are considered problematic only because >> of ad hoc assumptions made for "value add", non-standard features >> implemented in intermediate devices. > > Please see: > <https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03> > > theory != practice. And no matter how right you might be, that doesn't > make the theory a reality. > > > >>> Not that I like the situation, but... I think the least we can do is to >>> do a reality check wrt how things are supposed to work vs. how they >>> actually work. >>> >>> For this particular case, this I-D makes that point for fragmentation: I >>> I think we all agree that fragmentation is fragile -- making that point >>> clear at least raises awareness of the problem, and might trigger some >>> action on the topic (whether to correct the issue, or to circumvent it). >>> >> Right, but I still think that we should be more clear about the root >> origin of problems and blunt in requesting that non-conformant >> implementations get fixed. > > That is certainly not going to happen. From the pov of the folks > operating the networks, there's nothing broken. > > >> For instance, as I mentioned the ECMP >> hasing problem with fragmentation is entriely solvable if only >> intermediate devices will use flow label instead of trying to find >> ports for a hash. > > Yes and no. There was at least a time in which the flow label wasn't set > at all, or even was mistaenly set (e value during 3WHS, a different > value afterwards). That means that you cannot really rely on it. If you > cannot rely on it, you need a back-up mechanism. And that mechanism is > inspecting the trasnport port numbers -- from that point of view, > there's not much sense in dong ECMP with the FL if you cannot rely on it > and somehow you'd have to be prepared to do it based on addresses and > port numbers. The fallback is to only hash over addresses. Hashing over ports is not reliable and can be problematic in itself. For instance, wrt fragmentation, some middleboxes will use ports in the first fragment but fall back to hashing over addresses for rest of fragments. This mean the first fragment almost always takes a different path which can wreak havoc on down stream devices that aren't expecting that. So maybe it's another recommendation in this draft that middleboxes don't use port information from first fragment to do load balancing. This is another relatively easy fix. Tom > > >> Fixing devices to support this reasonable and should >> be low cost. IMO, use of flow label for ECMP should be a strong >> recommendation made in this draft. > > I wouldn't mind. However, that doesn't change the fact that > fragmentation is fragile. > > That said, if you look at RFC7872, t all looks like anything that is EHs > is dropped to some extent (while not included in the RFC, I also mesured > IPsec, and you get similar numbers). So besides the issues that are > specific to fragmentation, anything that is EHs gets dropped here an > there. -- and ding ECMP with the FL will not change that. > > (Again: not that I'm happy with the situation... but being unhappy will > not change reality anyway :-) ) > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > ___ 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 Sat, Jul 28, 2018 at 11:24 AM, Ole Troan wrote: >> Here’s the thing about fragmentation: >> >> 1. all links have a maximum packet size >> 2. all tunneling/encapsulation/layering increases payload size >> >> 1+2 implies there is always the need for fragmentation at some layer: > > 1 implies that. > There is enough head room designed in 1 to accommodate 2. > Ole, I'm not sure I follow what you're saying here. Ethernet MTU, the most common value, is 1500 bytes. There's no reference to headroom for that. If you're referring to the idea of artificially lowering MTUs to account for potential overhead introduced in encapsulation that can be done. However to avoid fragmentation _entirely_ one would need to determine the maximum possible overhead ever added in encapsulation(s) (plural in case of nested encapsulations). In a sprawling and dynamic network that has different sub-domains and simultaneously uses different encapsulation protocols, determining that specific magic number might be infeasible. There is also the problem that some 0.01% corner case of encapsulation might need extra large 100s of bytes of overhead. Lowering the MTU for everyone just to avoid fragmentation for that case is a poor tradeoff-- it's better to fragment for that case. Tom >> >> 3. fragmentation always splits info across packets >> >> And there’s something important about layering: >> >> 4. layering intends to isolate the behavior of one layer from another, >> such that >> it will always be impossible for an upper layer to know exactly what >> is going on below, >> i.e., to determine that limiting size across an entire path of >> possibly virtual tunnels >> >> The next two are where we get into trouble: >> >> 5. network devices increasingly WANT to inspect contents beyond the >> layer at which they are intended to operate > > not that network devices have an intent in themselves, but yes, it seems like > network operators want to inspect content or are forced into it because of > the necessity of IPv4 address sharing. > >> 6. inspecting contents ultimately means reassembly, at some level > > _some_ content inspection would require that, but I don't think you can make > that the general rule. > e.g. a NAT or an L4 ACL only needs access to the L4 header. > >> Which brings us to the punchline: >> >> 7. but network device vendors want to save money, so they don’t want >> to reassemble at any layer > > We'd all wish it to be that simple. Can you substantiate that claim? > You can easily make the speculation that customers don't want to pay what it > costs to be able to do reassembly at terabit speeds... > Or accept that it's technically hard. > > The implementations of e.g. NATs, IPv4 address sharing implementations I'm > aware of do flavours of network layer reassembly. > However much money you throw at it, you can't reassemble fragments travelling > on different paths, nor can you trivially make network layer reassembly not > be an attack vector on those boxes. > >> >> So I agree, IP fragmentation has its flaws - but those flaws are created not >> only because it leaves out the transport port numbers, but also because DPI >> and NAT devices don’t reassemble. And they don’t because it’s cheaper to >> sell devices that say they run at 1 Gbps (e.g.) that don’t bother to >> reassemble. > > I don't agree with your conclusion. > NATs extend the network layer to include the L4 ports. NAT implementations of > course do reassemble. > >> I.e., it will never matter what layering we add to fix this - GRE, GUE, >> Aero, etc. - ultimately, we’re doomed to need fragmentation support down to >> IP exactly because: >> >> a. #1-4 mean we need frag/reassembly at any tunnel ingress >> b. vendors want to sell #5 at a price that is too low for them to >> support #6 (i.e., point #7) > >> >> So pushing this to another layer will never solve it. What will solve it >> will only be a compliance requirement for #6 - which could be done right >> now, and has to be done for ANY solution to work. > > For IPv4 address sharing specifically removing network layer fragmentation > would be a solution. > >> NOTE: even rewriting EVERY application won’t fix this, nor will deploying a >> new layer at any level. > > For some type of content inspection that would require reassembling the whole > application context. > But that's quite different from IPv4 address sharing, which we have > unfortunately made an integral part of the Internet architecture. > >> And yes, I do intend to add this to draft-ietf-tunnels, so it can be >> referred to elsewhere. > > Ole > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ 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 Sun, Jul 29, 2018 at 8:38 AM, Joe Touch wrote: > > > On Jul 28, 2018, at 11:24 AM, Ole Troan wrote: > > Here’s the thing about fragmentation: > > 1. all links have a maximum packet size > 2. all tunneling/encapsulation/layering increases payload size > > 1+2 implies there is always the need for fragmentation at some layer: > > > 1 implies that. > There is enough head room designed in 1 to accommodate 2. > > > As was noted, there’s never enough headroom because you can’t control (or > even know) how many layers of tunnels your traffic experiences. > > > > 3. fragmentation always splits info across packets > > And there’s something important about layering: > > 4. layering intends to isolate the behavior of one layer from another, such > that > it will always be impossible for an upper layer to know exactly what is > going on below, > i.e., to determine that limiting size across an entire path of possibly > virtual tunnels > > The next two are where we get into trouble: > > 5. network devices increasingly WANT to inspect contents beyond the layer at > which they are intended to operate > > > not that network devices have an intent in themselves, but yes, it seems > like network operators want to inspect content or are forced into it because > of the necessity of IPv4 address sharing. > > > They were “forced” into differentiating commercial from home customer > pricing. NATs didn’t need to exist when they were first deployed. > > That said, there’s no real problem with a NAT *IF* it acts as a host on the > Internet > (see ouch, J: Middlebox Models Compatible with the Internet. USC/ISI > (ISI-TR-711), 2016.) Joe, It's still a problem though. A NAT (or any stateful device in the network) forces the requirement in network architecture that all packets of a flow are routed through the same device. This has killed our ability to use multi-homing and multi-path. The best way for an intermediate devices to deal with transport layer state is to be an L4 proxy. The intermediate is a host endpoint for the proxy connections, but then that has its own problems since it breaks E2E functionality (like TCP auth). So the only real solution is to eliminate transport state from the network. I'm still holding out hope that IPv6 will start to obsolete use of NAT! FAST (draft-herbert-fast-02) is intended to provide a viable alternative to stateful firewalls. Tom > > 6. inspecting contents ultimately means reassembly, at some level > > > _some_ content inspection would require that, but I don't think you can make > that the general rule. > e.g. a NAT or an L4 ACL only needs access to the L4 header. > > > It’s a general rule; you merely refer to an instance that is relevant ONLY > when the L3 header at which a router operates is followed (or expected to be > followed) by an L4 header. > > That may have been the Internet of 10 years ago, but it is less and less the > Internet moving forward. > > > Which brings us to the punchline: > > 7. but network device vendors want to save money, so they don’t want to > reassemble at any layer > > > We'd all wish it to be that simple. Can you substantiate that claim? > You can easily make the speculation that customers don't want to pay what it > costs to be able to do reassembly at terabit speeds... > Or accept that it's technically hard. > > > I’m not claiming it isn’t hard; I’m claiming that it’s always cheaper to > *not* do something. > > My concern isn’t that reassembly isn’t being done; it’s that vendors sell > devices that don’t make this clear - AND that they don’t pass on packets > they don’t/can’t reassemble. > > The implementations of e.g. NATs, IPv4 address sharing implementations I'm > aware of do flavours of network layer reassembly. > > > If they did so, we would not be here talking about considering IP > fragmentation fragile. > > However much money you throw at it, you can't reassemble fragments > travelling on different paths, nor can you trivially make network layer > reassembly not be an attack vector on those boxes. > > > Agreed, but here’s the other point: > > Any device that inspects L4 content can do so ONLY as a proxy for the > destination endpoint. > > I.e., I know vendors WANT to sell devices they say can be deployed anywhere > in the network, and operators believe that, but it’s wrong. > > Basically, if you’re not at a place in the network where you represent that > endpoint, you have no business acting as that endpoint - “full stop”. > > > > So I agree, IP fragmentation has its flaws - but those flaws are created not > only because it leaves out the transport port numbers, but also because DPI > and NAT devices don’t reassemble. And they don’t because it’s cheaper to > sell devices that say they run at 1 Gbps (e.g.) that don’t bother to > reassemble. > > > I don't agree with your conclusion. > NATs extend the network layer to include the L4 ports. NAT implementations > of course do reassemble. > > > See Touch, J: Middlebox Models Compatible with the Internet
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch wrote: > > > On Jul 29, 2018, at 9:11 AM, Tom Herbert wrote: > > ... > > That said, there’s no real problem with a NAT *IF* it acts as a host on the > Internet > (see ouch, J: Middlebox Models Compatible with the Internet. USC/ISI > (ISI-TR-711), 2016.) > > > Joe, > > It's still a problem though. A NAT (or any stateful device in the > network) forces the requirement in network architecture that all > packets of a flow are routed through the same device. > > > I didn’t make that requirement. The Internet does - it’s what it *means* to > have an IP address. > > A NAT *has* the address of the packets it sources; if it isn’t the sink of > that address, then it’s being used incorrectly. If it doesn’t reassemble > those packets before translating them (i.e., by translating only > unfragmented packets and dropping fragmented ones), then it is broken and > ought to be returned for a refund. > > This has killed > our ability to use multi-homing and multi-path. > > > No, the Internet supports multi path between two IP endpoints and allows > multihoming for a single address when managed by a single endpoint (physical > or virtual). > > The disconnect is a failure to understand that a NAT *is* an IP endpoint. > The term “middlebox” is wrong in that sense, at least it’s not a middle box > to the Internet (it is to the device behind the NAT). > > The best way for an > intermediate devices to deal with transport layer state is to be an L4 > proxy. The intermediate is a host endpoint for the proxy connections, > > but then that has its own problems since it breaks E2E functionality > (like TCP auth). So the only real solution is to eliminate transport > state from the network. > > > That would work only if the network didn’t look at or modify transport > information - and it did work when that was the case. > > I'm still holding out hope that IPv6 will > start to obsolete use of NAT! FAST (draft-herbert-fast-02) is intended > to provide a viable alternative to stateful firewalls. > > > Getting rid of NATs is only part of the problem. Anything that does DPI is a > problem when it discards messages it can’t parse because they’re fragmented. > Right, that implies that we need to eliminate the motivation to do DPI by providing a better way to get the same functionality. This is what FAST proposes. Transport related information of interest to a firewall is in Hop-by-Hop options. So middleboxes will look at HBH options which come before fragment EH. No DPI needed, no issues with fragmentation at middleboxes, and, as a bonus, HBH options are the only mechanism defined in IP protocol that allows data to be changed in flight (this will be important property as in-situ OAM starts to get traction). 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 Sun, Jul 29, 2018 at 9:22 AM, Joe Touch wrote: > > > On Jul 29, 2018, at 9:11 AM, Tom Herbert wrote: > > ... > > That said, there’s no real problem with a NAT *IF* it acts as a host on the > Internet > (see ouch, J: Middlebox Models Compatible with the Internet. USC/ISI > (ISI-TR-711), 2016.) > > > Joe, > > It's still a problem though. A NAT (or any stateful device in the > network) forces the requirement in network architecture that all > packets of a flow are routed through the same device. > > > I didn’t make that requirement. The Internet does - it’s what it *means* to > have an IP address. > It's not a requirement of the Internet and certainly not a core IETF requirement that packets always follow the same path. It's an ad hoc requirement imposed by _some_ solutions that have been deployed. > A NAT *has* the address of the packets it sources; if it isn’t the sink of > that address, then it’s being used incorrectly. If it doesn’t reassemble > those packets before translating them (i.e., by translating only > unfragmented packets and dropping fragmented ones), then it is broken and > ought to be returned for a refund. > You are only considering the return path. Packets sent from the client origin to the remote server need to always follow the same path to hit the same device that has the NAT state for the flow. The destination address is not the address of the NAT device, so the only way this works is if the routing in the internal network consistently routes packets through the right device. If routing changes, packets could be sent to a different NAT device that doesn't have the state to handle the packet so it will just drop it. This is a fundamental problem. Vendors have mostly gotten away with it because NAT and firewalls are often used in very simple networks, like home networks, that only have one default router. But in a more complex network with multiple egress points, including increasing use of multi-homing in home networks and personal devices, getting consistent routing to satisfy the requirements of stateful network devices is a major issue. Fragmentation exacerbates the problem because fragments must be routed precisely the same way that non-fragments are in order to hit the same egress device. ECMP routing non-fragments using ports and fragments without using ports means that they take different paths. Using flow label instead of ports for ECMP is the best way to ensure all packets (fragments and non-fragments) of a flow follow the same route (or at least will produce the same hash for load balancing and packet steering algorithms). > This has killed > our ability to use multi-homing and multi-path. > > > No, the Internet supports multi path between two IP endpoints and allows > multihoming for a single address when managed by a single endpoint (physical > or virtual). > See above explanation. Tom > The disconnect is a failure to understand that a NAT *is* an IP endpoint. > The term “middlebox” is wrong in that sense, at least it’s not a middle box > to the Internet (it is to the device behind the NAT). > > The best way for an > intermediate devices to deal with transport layer state is to be an L4 > proxy. The intermediate is a host endpoint for the proxy connections, > > but then that has its own problems since it breaks E2E functionality > (like TCP auth). So the only real solution is to eliminate transport > state from the network. > > > That would work only if the network didn’t look at or modify transport > information - and it did work when that was the case. > > I'm still holding out hope that IPv6 will > start to obsolete use of NAT! FAST (draft-herbert-fast-02) is intended > to provide a viable alternative to stateful firewalls. > > > Getting rid of NATs is only part of the problem. Anything that does DPI is a > problem when it discards messages it can’t parse because they’re fragmented. > > 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 Mon, Jul 30, 2018 at 10:34 AM, Joe Touch wrote: > > > > > On 2018-07-30 08:11, Tom Herbert wrote: > > On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch wrote: > > > > On Jul 29, 2018, at 9:11 AM, Tom Herbert wrote: > > ... > > That said, there's no real problem with a NAT *IF* it acts as a host on the > Internet > (see ouch, J: Middlebox Models Compatible with the Internet. USC/ISI > (ISI-TR-711), 2016.) > > > Joe, > > It's still a problem though. A NAT (or any stateful device in the > network) forces the requirement in network architecture that all > packets of a flow are routed through the same device. > > > I didn't make that requirement. The Internet does - it's what it *means* to > have an IP address. > > It's not a requirement of the Internet and certainly not a core IETF > requirement that packets always follow the same path. It's an ad hoc > requirement imposed by _some_ solutions that have been deployed. > > > 1122 requires that devices shouldn't be sourcing IP addresses they don't > own. > > And any device behind a NAT would have a similar requirement - that the > private side is setup such that any translation appears as a single device > -- which means either that each host on the private side forwards all its > traffic to one egress (as a stub net) or that the multiple egresses > coordinate state to look like one egress on the private side and one host on > the public side. > > I.e., the Internet architecture imposes exactly the restrictions you note - > these aren't ad-hoc, they're derived from the Internet requirements. > IP is packet switched not circuit switched. Other than the source and destination nodes, no two packets sent on a flow are required to traverse the same nodes, nor does there need to be any symmetry in the path between two directions of communication. If this is an incorrect interpretation of the requirements then please reference the RFC that states otherwise. > > > > A NAT *has* the address of the packets it sources; if it isn't the sink of > that address, then it's being used incorrectly. If it doesn't reassemble > those packets before translating them (i.e., by translating only > unfragmented packets and dropping fragmented ones), then it is broken and > ought to be returned for a refund. > > You are only considering the return path. > > > Only for that rule; for the private side, the rule is that the network is a > stub behind the translator (or emulates that). > > ... > > This has killed > our ability to use multi-homing and multi-path. > > > It didn't kill it. It never existed *for this sort of mechanism* - exactly > because of requirements of the Internet architecture. > The mechanism (specifically the requirement that packets traverse intermediate nodes that are not addressed) breaks multi-homing. All the hacks and hoops we've had to jump through over the years to make NAT, stateful firewalls, and L4 load balancers work attest to this being a real problem. Tom > > If there is only one device that represents a private node on the public > net, it can work (using the model I describe). If there isn't, then it's the > Internet architecture that makes the device inherently broken - we shouldn't > go around believing we can patch the protocols to "make it work again". > > 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 Mon, Jul 30, 2018 at 11:50 AM, Joe Touch wrote: > > > > > On 2018-07-30 11:16, Tom Herbert wrote: > > On Mon, Jul 30, 2018 at 10:34 AM, Joe Touch wrote: > > > > > > On 2018-07-30 08:11, Tom Herbert wrote: > > On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch wrote: > > > > On Jul 29, 2018, at 9:11 AM, Tom Herbert wrote: > > ... > > That said, there's no real problem with a NAT *IF* it acts as a host on the > Internet > (see ouch, J: Middlebox Models Compatible with the Internet. USC/ISI > (ISI-TR-711), 2016.) > > > Joe, > > It's still a problem though. A NAT (or any stateful device in the > network) forces the requirement in network architecture that all > packets of a flow are routed through the same device. > > > I didn't make that requirement. The Internet does - it's what it *means* to > have an IP address. > > It's not a requirement of the Internet and certainly not a core IETF > requirement that packets always follow the same path. It's an ad hoc > requirement imposed by _some_ solutions that have been deployed. > > > 1122 requires that devices shouldn't be sourcing IP addresses they don't > own. > > And any device behind a NAT would have a similar requirement - that the > private side is setup such that any translation appears as a single device > -- which means either that each host on the private side forwards all its > traffic to one egress (as a stub net) or that the multiple egresses > coordinate state to look like one egress on the private side and one host on > the public side. > > I.e., the Internet architecture imposes exactly the restrictions you note - > these aren't ad-hoc, they're derived from the Internet requirements. > > IP is packet switched not circuit switched. Other than the source and > destination nodes, no two packets sent on a flow are required to > traverse the same nodes, nor does there need to be any symmetry in the > path between two directions of communication. If this is an incorrect > interpretation of the requirements then please reference the RFC that > states otherwise. > > > > RFC1122 says that an address belongs to one interface. > > So if you have a system that treats internet addresses as belonging to more > than one device, that's on you to make sure they ACT like one device. > > You can have a host on the private side use multiple egress NATs for > different connections, but the reverse traffic has to treat the two as if > they were one device. If putting those devices in the middle of the network > means you can't see the traffic to make that happen, then you've deployed > the devices incorrectly or insufficiently configured them to act as a single > unit. > > > ... > The mechanism (specifically the requirement that packets traverse > intermediate nodes that are not addressed) breaks multi-homing. All > the hacks and hoops we've had to jump through over the years to make > NAT, stateful firewalls, and L4 load balancers work attest to this > being a real problem. > > > *traversing* intermediate nodes is not an issue. It's changing addresses and > ports that is. > > Once you do either thing, you're a host - ONE logical host for every IP > address you do this with. If you deploy a device that intends to act this > way that can't see all the traffic it should be receiving - or deploy a > device behind it that isn't represented by exactly one such device - then it > is your device and/or its deployment that is broken. > > Oh, and I have no debate that people deploying badly designed devices and/or > doing so in incorrect ways is a real problem. It's just not MY problem, nor > do I think it should be the IETF's. Joe, I agree, except that a BCP like this is making practical (and current) recommendations that take into account the protocols have been commonly implemented regardless of whether they are conformant. From that perspective, it does seem to be IETF's problem. I think this is reasonable assuming that it's clear why such recommendations are being made. If they're being made in order to workaround non-confomant implementations then that should be highlighted as such. In no way should such recommendations be interpreted as acceptance of non-conformance. The need for fragmentation cannot be completely eliminated and we do need it to work. Devices that do things to prevent correct operation still need to be fixed, and it would be productive for the draft to include statements on how some of the sub-problems problems can be fixed (like using flow label for ECMP instead of ports). 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 Tue, Jul 31, 2018, 5:28 AM Ole Troan wrote: > Joe, > > >> The need for fragmentation cannot be completely > >> eliminated and we do need it to work. Devices that do things to > >> prevent correct operation still need to be fixed, and it would be > >> productive for the draft to include statements on how some of the > >> sub-problems problems can be fixed (like using flow label for ECMP > >> instead of ports). > > > > On that we agree. That’s my key concern - how to do this in a way that > doesn’t effectively kill off IP fragmentation for the rest of us. > > For IPv4 it’s an unfortunate side-effect of the fact that we are out of > IPv4 addresses. As we continue to increase the ratio of users per IPv4 > address, IPv4 fragmentation, or any protocol that isn’t TCP or UDP are not > going to work well in the public IPv4 Internet. > IPv4 Internet Architecture is evolving as a consequence of address > run-out. I think we’ve pretty much explored the solution space for IPv4 > sharing mechanisms, so I think you just have to accept this new and > unimproved (sic) IPv4 Internet architecture. > Ole, How is this story going to be different for IPv6? How do we ensure that non-conformant implementation for IPv4 isn't just carried over so that fragmentation, alternative protocols, and extension headers are viable on the IPv6 Internet? Tom > Cheers, > Ole ___ 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 Tue, Jul 31, 2018 at 2:21 PM, Ole Troan wrote: > Tom, > >> How is this story going to be different for IPv6? How do we ensure that >> non-conformant implementation for IPv4 isn't just carried over so that >> fragmentation, alternative protocols, and extension headers are viable on >> the IPv6 Internet? > > I don’t think the IPv4 implementations are non-conformant. > (With regards to the implications of A+P on the IPv4 architecture). > > For IPv6 one would fear that the same pressures that has led to IPv4 > ossification applies. > Well, what can we do? Apart from crypto, ensure that popular applications use > the features, so they cannot be shut down? > Ole, That's the "use it or lose it" model of protocol features. TCP options are firmly established as a required part of TCP protocol so there is no way they could be obsoleted by external implemenation; IP options on the other were never really required for IP operation so they are considered expendable. The problem is that protocol features are often defined before the application that would use them is built, so the motivation to support all the features from the start isn't there. This seems to be the case with extension headers, since only now does there seem to be some serious proposals to use that functionality long after the mechanism was first defined and IPv6 was deployed. In reality, support of protocol features in the Internet is hardly ever binary. Plain TCP/IPv4 packets are probably the only combination of protocols that is guaranteed to work with probability approaching 100%, however pretty much anything else works with some varying of probability greater than 0% but less than 100% (like EH success rates in RFC7872). To that end, I am wondering if the idea of Happy Eyeballs could somehow be generalized to work with these other "non-standard" features. Tom > Cheers, > Ole > ___ 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 2, 2018 at 8:50 AM, Mikael Abrahamsson wrote: > On Thu, 2 Aug 2018, Joe Touch wrote: > >> So you want us to redesign the Internet to run over port 443. > > > Nope. > >> The again, IP has fragmentation. That too is reality, even if we don’t >> like it. > > > IP have lots of things. Hop-by-hop-headers for instance. Really bad idea. > Mikael, Definition of hop-by-hop options might have been flawed in that they were required to be processed by every node in the path. But with that restriction relaxed, this now is the only feasible mechanism that provides inband host to network or network to host signaling. IMO, this is far better idea than all the approaches that have being do ad hoc DPI into transport layers or even transport payload. Fortunately this is one area that might progress. QUIC seems to have enough traction and encrypts header to render DPI ineffective. If the QUIC application wants to tell something to the network it can do that by HBH (this is a premise of FAST). >> Again, something broken needs fixing. You can chase the symptoms forever >> or you can deal with the cause. It’s simply not tenable to ‘fix’ the >> internet to accommodate broken devices. > > > The thing here is that you haven't proposed a realistic way to deal with the > problem. We do not have any enforcement mechanism. > > Applications need to work when faced with adverse conditions. They can work > less well, that's fine, but they still need to work. > This leads to driving everything down to only support the least common denominator. Problem is that we can never move things forward if everyone is bound to LCD. Tom > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ 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 3, 2018 at 12:48 AM, Mikael Abrahamsson wrote: > On Thu, 2 Aug 2018, Tom Herbert wrote: > >> This leads to driving everything down to only support the least common >> denominator. Problem is that we can never move things forward if everyone is >> bound to LCD. > > > I don't understand why people think this is what I am saying. > > Car engines have "limp mode" when things go wrong. This is a restricted mode > that gets you home, works much worse, but at least doesn't leave you > stranded. I am saying applications should have the same. > > I've kept saying "Networks must support ip fragmentation properly. > Applications should still work somewhat when it doesn't". > > Så relying on fragmentation and falling over when it doesn't work is not a > good strategy to recommend to application developers. > You could say the same the thing about extension headers, SCTP and DCCP, and even IPv6 itself since it still doesn't work everywhere. The only protocols an application can _rely_ on working is TCP over plain IPv4. That is current LCD. If the advice is that applications only use protocols they can rely on, then Internet is stuck in time. IMO, there should be a way for applications to use "alternative" features and protocols with a fallback mechanism if necessary. For instance, if the application had a priori knowledge that all nodes in a path supported fragmentation, then there should be no issue with it using fragmentation when sending on that path. Applying the car analogy, if I look at a map and don't see any unpaved roads on the route to my destination, then I can leave my four wheel drive all terrain vehicle at home and take my Ferrari instead. I think that a generalization of "Happy Eyeballs" might be a solution that discovers and maps what features and protocols work on what paths. Per the draft at hand, I think the advice to try to avoid fragmentation is practical under the current circumstances. However, I think that recommendation needs to be heavily qualified and scoped appropriately. A general statement that applications shouldn't rely on fragmentation cannot be interpreted as acceptance of non-conformant implementation or as a free pass that middleboxes don't need to fix there stuff. Tom > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt
On Mon, Aug 13, 2018 at 7:07 PM, Brian E Carpenter wrote: > Updated following comments received at IETF102. > > Forwarded Message > Subject: I-D Action: draft-carpenter-limited-domains-02.txt > Date: Mon, 13 Aug 2018 18:42:27 -0700 > From: internet-dra...@ietf.org > Reply-To: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Limited Domains and Internet Protocols > Authors : Brian Carpenter > Bing Liu > Filename: draft-carpenter-limited-domains-02.txt > Pages : 15 > Date: 2018-08-13 > > Abstract: >There is a noticeable trend towards network requirements, behaviours >and semantics that are specific to a limited region of the Internet >and a particular set of requirements. Policies, default parameters, >the options supported, the style of network management and security >requirements may vary. This document reviews examples of such >limited domains and emerging solutions. It shows the needs for a >precise definition of a limited domain boundary and for a >corresponding protocol to allow nodes to discover where such a >boundary exists. > Hi Brian, thanks for the draft. A couple general points: * It's unclear to me what it means for a protocol to only work in a limited domain. I think there is a big difference between describing how a standard protocol _could_ be deployed in a limited domain for good effect, versus defining a standard protocol that can _only_ operate correctly in a limited domain. Most of the examples in section 4 are describing deployment of protocols seem to fall in the first category where protocol deployment might only be feasible in limited domain, but the definition of the protocol does not require a limited domain. For instance, the fact that extension headers is not deployable by the Internet, but may work in a limited domain, is happenstance on how things evolved. It was never the intent of extension headers to only be used in limited domains, neither do I believe there is value in respecifying extension headers as such (I still believe problems that prevent use on the Internet should be fixed). On the other hand, something like extension header insertion would require a protocol to be specified to only work in a limited domain since that would otherwise break some fundamental requirements of IPv6. * If we accept that protocols can be defined for use only limited domains, what becomes of the priniciple of interoperability? Does this open up the possibility that "limited domain" could mean that any possible variant of a protocol is allowed per the "local policy" of the domain? A limited domain would make anything possible in protocols. For instance, someone could decide to switch the soure and destination addresses in IP headers in a limited domain as a local policy. As long as the requirements of a limited domain is enforced this is completely feasible (note a limited domain could be defined by an island in the network having only one vendor solution). So then does a limited domain become a vehicle for vendors to define and deploy their own value-add protocol extensions without regard to interoperability? The open endedness of "local policy" alluded to in the SR protocol draft as well as some statement concerning the use of network slices by mobile operators that are run by a single hardware vendor are noteworthy., Tom > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-carpenter-limited-domains-02 > https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-02 > > > 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/ > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt
On Tue, Aug 14, 2018 at 10:26 PM, Brian E Carpenter wrote: > Tom, > > Thanks for the comments. See in-line: > > On 15/08/2018 12:00, Tom Herbert wrote: >> On Mon, Aug 13, 2018 at 7:07 PM, Brian E Carpenter > ... >>> >> Hi Brian, thanks for the draft. >> >> A couple general points: >> >> * It's unclear to me what it means for a protocol to only work in a >> limited domain. I think there is a big difference between describing >> how a standard protocol _could_ be deployed in a limited domain for >> good effect, versus defining a standard protocol that can _only_ >> operate correctly in a limited domain. > > Agreed. This is exactly why our next step is planned to be > a taxonomy of the various aspects, to try and separate > these issues. > >> Most of the examples in section >> 4 are describing deployment of protocols seem to fall in the first >> category where protocol deployment might only be feasible in limited >> domain, but the definition of the protocol does not require a limited >> domain. For instance, the fact that extension headers is not >> deployable by the Internet, but may work in a limited domain, is >> happenstance on how things evolved. It was never the intent of >> extension headers to only be used in limited domains, > > Correct. > >> neither do I >> believe there is value in respecifying extension headers as such (I > > I'd be very unlikely to do that, personally. But there might be > *semantics* that only apply within a domain. (That is how we > designed diffserv, whereas the original IPv4 TOS design was > supposed to be universal, I believe.) > >> still believe problems that prevent use on the Internet should be >> fixed). > > I wish that I had confidence that this could be achieved, but > there is an ongoing tension between innovation and firewall rules. > I am hopeful that mapping the capabilities of the Internet (like maybe work from MAPRG?) will resolve that. Applications can use "advanced" protocol features like extension headers in a type of happy eyeballs approach. Also, applications should give feedback to users when their in a degraded service mode because of non conforming devices in the path. >> On the other hand, something like extension header insertion >> would require a protocol to be specified to only work in a limited >> domain since that would otherwise break some fundamental requirements >> of IPv6. > > Exactly. > >> * If we accept that protocols can be defined for use only limited >> domains, what becomes of the priniciple of interoperability? Does this >> open up the possibility that "limited domain" could mean that any >> possible variant of a protocol is allowed per the "local policy" of >> the domain? > > That's a central question. I think the other way of looking at > it is: is it better to recognise that local semantics exist, and > figure out how to contain them, or is it better to simply > say "don't do that"? > >> A limited domain would make anything possible in >> protocols. For instance, someone could decide to switch the soure and >> destination addresses in IP headers in a limited domain as a local >> policy. As long as the requirements of a limited domain is enforced >> this is completely feasible (note a limited domain could be defined by >> an island in the network having only one vendor solution). So then >> does a limited domain become a vehicle for vendors to define and >> deploy their own value-add protocol extensions without regard to >> interoperability? The open endedness of "local policy" alluded to in >> the SR protocol draft as well as some statement concerning the use of >> network slices by mobile operators that are run by a single hardware >> vendor are noteworthy., > > Absent protocol police, we can't actually stop people doing such > things, can we? So the question is how can we best deal with the > reality of local semantics without (further) damaging global > interop? > Right, such things happen already and it's probably much more common than we'd like to admit. I've seen this deployed first hand (you should see how we overloaded the GRE sequence number and checksum fields to hold our own stuff at Google!). There is no interoperability problem here either, for a large datacenter operator it's just a phone call to a vendor to get what they want. But in the end, relying on "local semantics", especially when that means proprietary protocols or non-interoperability, is self defeating. It's better to use open standard protocols or at least have a p
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt
On Thu, Aug 16, 2018 at 10:02 AM, Ole Troan wrote: > Joe, > > On 16 Aug 2018, at 15:58, Joe Touch wrote: > > > > On Aug 16, 2018, at 5:47 AM, Ole Troan wrote: > > Joe, > > IPv4 fragments do have a higher drop probability than other packets. Just > from the fact that multiple end-users are sharing a 16 bit identifier space. > > > It’s really the fact that NATs that process fragments don’t reassemble > before translating and/or don’t rate limit fragments they generate as > already required by 791 (as explained in 6884). > > > That’s incorrect. > See https://tools.ietf.org/html/rfc7597#section-8.3.3 > > > You should re-read that RFC. It correctly points out that this is a flaw in > current devices. > > There is a solution - reassemble before NATing, and when issuing the new > packets, issue then with IDs generated at the NAT. > > > These are not NATs. They are specifically designed to be stateless. Sure you > can argue that the A+P solutions break the Internet, our answer to that oh > well, move to IPv6. > > The correct behavior is already indicated in RFC 6864, Sec 5.3.1 > Ole, The requirement that "Protocols/applications SHOULD avoid IP level fragmentation." already acknowledges and provides advice on the realities of the current state of fragmentation support in the network. IMO, the statement that "Networks MUST support IP level fragmented packets." is appropriate. It is simply restating the existing requirement that nodes conform to Internet standards. If we downgrade this to be "Networks SHOULD support IP level fragmented packets." then I fear this is the start of making a a bunch of core protocol requirements optional. I suspect we'll have softening of other requirements like "Networks SHOULD support extension headers", or "Networks SHOULD support protocols other than TCP". That would be accepting and codifying non-conformance as well as the protocol ossification that entails. Tom > > A NAT that is broken isn’t helping users share addresses. It’s just broken. > > > I wish it was that simple. > > > It’s not simple, but saying that “fragmentation is broken” does not make it > more simple either. > > > True. > Regardless, I fear we aren’t going to agree on this, but at least I think we > have understood each other’s points. > > Cheers > Ole > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ 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 24, 2018 at 8:24 PM, Toerless Eckert wrote: > On Fri, Aug 03, 2018 at 09:48:25AM +0200, Mikael Abrahamsson wrote: >> I've kept saying "Networks must support ip fragmentation properly. > > Why ? Wheren't you also saying that you've got (like probably many > else on this thread) all the experience that only TCP MSS gets you > working connectivity in many case (like hotels) ? > > IMHO, we (network layer) should accept defeat on network layer > fragmentation and agree that we should make it easier for the > transport layer to resolve the problem. > > Aka: I would lvoe to see a new ICMPv4/ICMPv6 reply and/or PTB reply option > indicating "Fragmented Packets Not Permitted". Any network device which > for whatever reason does not like Fragemnts would simply drop > fragmented packets and send this as a reply. Allows then the > transport layer to automatically use packetization (such as TCP MSS) > to get packets through. > > Of course. Will take a decade to get ubiquitously deployed, but > neither IPv4 nor IPv6 will go away, only the problems with fragmentation > will become worse and work if we do not have an exit strategy like this. > Toeless, I'm curious why you think the problems with fragmentation will become worse. The draft and much of this thread has already highlighted the problems with fragmentation that happen because of non-conformant implementation. While there's a lot of legacy implementation that might hard to fix completely, I don't think we've seen a good argument that these problems are infeasible to fix in new deployments and products. I think this draft is an opportunity not only highlight the problems, but to suggest some practical fixes to improve the situation as a way forward. Tom > If we don't try an exit strategy like this, we will just get what > Joe said, the complete segmentation of the Internet with more and > more L4 or even higher layer proxies. > > Btw: +1 for adopting the doc as a WG item, but primarily because everything > before section 7 is on a way to become a good read of reality. Section > 7 recommendations is only a faith based exercise (praying) as long as it > tries to > get the job done primarily by appealing to application developers. > > Cheers > Toerless > > > ___ 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 Sun, Aug 26, 2018 at 10:31 AM, Christian Huitema wrote: > It seems that the biggest obstacle to fragmentation are NAT and Firewall. > They need the port numbers in order to find and enforce context. NAT might be > going away with IPv6, maybe, but firewalls are not. > > Have considered strategies that move the port number inside the IP header? > For example, have an UDP replacement for IPv6 that does not have any port > number in the new UDP header, and relies instead on unique IPv6 addresses per > context? Christian, That's sort of along the lines for what Firewall and Service Tickets (FAST) does. But instead of just putting a port number in the IP header, FAST employs a generic ticket containing the state information needed by the firewall. Tickets are encoded in Hop-by-Hop options, so the firewall only needs to inspect the Hop-by-Hop options to do its work eliminating the need for DPI at the middlebox (protocol compliant with RFC8200). This works on any packet regardless of whether it's a fragment (no reassembly at firewall is ever necessary), any combination of extension headers, and any transport protocol even those that don't have a concept of ports. Tom > > -- Christian Huitema > >> On Aug 26, 2018, at 10:08 AM, Tom Herbert wrote: >> >>> On Fri, Aug 24, 2018 at 8:24 PM, Toerless Eckert wrote: >>>> On Fri, Aug 03, 2018 at 09:48:25AM +0200, Mikael Abrahamsson wrote: >>>> I've kept saying "Networks must support ip fragmentation properly. >>> >>> Why ? Wheren't you also saying that you've got (like probably many >>> else on this thread) all the experience that only TCP MSS gets you >>> working connectivity in many case (like hotels) ? >>> >>> IMHO, we (network layer) should accept defeat on network layer >>> fragmentation and agree that we should make it easier for the >>> transport layer to resolve the problem. >>> >>> Aka: I would lvoe to see a new ICMPv4/ICMPv6 reply and/or PTB reply option >>> indicating "Fragmented Packets Not Permitted". Any network device which >>> for whatever reason does not like Fragemnts would simply drop >>> fragmented packets and send this as a reply. Allows then the >>> transport layer to automatically use packetization (such as TCP MSS) >>> to get packets through. >>> >>> Of course. Will take a decade to get ubiquitously deployed, but >>> neither IPv4 nor IPv6 will go away, only the problems with fragmentation >>> will become worse and work if we do not have an exit strategy like this. >>> >> Toeless, >> >> I'm curious why you think the problems with fragmentation will become >> worse. The draft and much of this thread has already highlighted the >> problems with fragmentation that happen because of non-conformant >> implementation. While there's a lot of legacy implementation that >> might hard to fix completely, I don't think we've seen a good argument >> that these problems are infeasible to fix in new deployments and >> products. I think this draft is an opportunity not only highlight the >> problems, but to suggest some practical fixes to improve the situation >> as a way forward. >> >> Tom >> >>> If we don't try an exit strategy like this, we will just get what >>> Joe said, the complete segmentation of the Internet with more and >>> more L4 or even higher layer proxies. >>> >>> Btw: +1 for adopting the doc as a WG item, but primarily because everything >>> before section 7 is on a way to become a good read of reality. Section >>> 7 recommendations is only a faith based exercise (praying) as long as it >>> tries to >>> get the job done primarily by appealing to application developers. >>> >>> Cheers >>>Toerless >>> >>> >>> >> >> ___ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > ___ 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 Sun, Aug 26, 2018 at 11:38 AM, Joe Touch wrote: > > >> On Aug 26, 2018, at 10:31 AM, Christian Huitema wrote: >> >> It seems that the biggest obstacle to fragmentation are NAT and Firewall. >> They need the port numbers in order to find and enforce context. NAT might >> be going away with IPv6, maybe, but firewalls are not. >> >> Have considered strategies that move the port number inside the IP header? >> For example, have an UDP replacement for IPv6 that does not have any port >> number in the new UDP header, and relies instead on unique IPv6 addresses >> per context? > > NATs already have what they need to do the proper job - they need to > reassemble and defragment using unique IDs (or cache the first fragment when > it arrives and use it as context for later - or earlier cached - fragments). > There’s no rule that IP packets that are fragmented MUST have a transport > header both visible (not encrypted) and immediately following the IP header. > > Firewalls are just delusions; the context they think they’re enforcing has no > meaning except at the endpoints; it never did. > > Using part of the IPv6 space for this solution would then break per-address > network management (different UDP ports would use different IPv6 addresses, > presumably). > > The “disease" is that NATs don’t reassemble (or emulate it). It’s not useful > to try to address the symptoms of that disease individually. > Joe, That is only a better solution, not a complete or robust one. For reassembly to work all fragments of a packet must traverse the same NAT device. There is no rule that IP packets going to the same destination (fragments or not) ever MUST follow the same path. So in a multi-homed environment this will eventually break someone. For IPv6, this is also a clear violation of RFC8200 since intermediate nodes are processing a non-HBH extension header in a packet not addressed to the them. The only robust solution to NAT and its fragmentation problems, as well as a bunch of other problems NAT brings, is to not use NAT! (i.e. switch to IPv6) 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 Sun, Aug 26, 2018 at 2:12 PM, Joe Touch wrote: > > > On Aug 26, 2018, at 12:58 PM, Tom Herbert wrote: > > On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch wrote: > > > > On Aug 26, 2018, at 10:31 AM, Christian Huitema wrote: > > It seems that the biggest obstacle to fragmentation are NAT and Firewall. > They need the port numbers in order to find and enforce context. NAT might > be going away with IPv6, maybe, but firewalls are not. > > Have considered strategies that move the port number inside the IP header? > For example, have an UDP replacement for IPv6 that does not have any port > number in the new UDP header, and relies instead on unique IPv6 addresses > per context? > > > NATs already have what they need to do the proper job - they need to > reassemble and defragment using unique IDs (or cache the first fragment when > it arrives and use it as context for later - or earlier cached - fragments). > There’s no rule that IP packets that are fragmented MUST have a transport > header both visible (not encrypted) and immediately following the IP header. > > Firewalls are just delusions; the context they think they’re enforcing has > no meaning except at the endpoints; it never did. > > Using part of the IPv6 space for this solution would then break per-address > network management (different UDP ports would use different IPv6 addresses, > presumably). > > The “disease" is that NATs don’t reassemble (or emulate it). It’s not useful > to try to address the symptoms of that disease individually. > > Joe, > > That is only a better solution, not a complete or robust one. > > > It is complete and robust... > > For > reassembly to work all fragments of a packet must traverse the same > NAT device. There is no rule that IP packets going to the same > destination (fragments or not) ever MUST follow the same path. > > > Correct, but there has to be a rule that all packets in a NAT’d flow go > through the same NAT or multiple devices that emulate a single NAT. > Again, there is no such rule in IP. Multiple devices could emulate a NAT, but the overhead of doing this down to the granularity of fragmented packets would be extraordinary. The way implementations have handled dynamic transport state in the network is to assume consistent per flow routing, or only one egress point. > So in a > multi-homed environment this will eventually break someone. For IPv6, > this is also a clear violation of RFC8200 since intermediate nodes are > processing a non-HBH extension header in a packet not addressed to the > them. > > > A NAT is not a router. A router is not allowed to modify the IP addresses or > port numbers. > Maybe so, but a NAT is not a host either. NAT is one example of intermediate nodes attempting participate in transport level protocols and thereby breaking the end-to-end model. But, unlike a host, there is no guarantee that it will be given all the necessary information to produce the same behavior as a host. A set of assumptions external to the protocols are required to achieve something close to correctness. Best way to fix that is eliminate the need for dynamic state. Accordingly, I think a recommendation in this draft should recommend use IPv6 without NAT in order to address the NAT-fragmentation problem. Tom > When a NAT does these changes, it is acting as a proxy endpoint in the > public Internet; as such, it is *required* to do whatever is necessary to > ensure that its behavior follows that of a host. > > The only robust solution to NAT and its fragmentation problems, > as well as a bunch of other problems NAT brings, is to not use NAT! > (i.e. switch to IPv6) > > > As I’ve mentioned, there are rules under which a NAT is a valid Internet > device, but it is simply not just a router. > If it's not a router, then I don't believe it could could a host or > 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 Sun, Aug 26, 2018 at 2:55 PM, Toerless Eckert wrote: > On Sun, Aug 26, 2018 at 11:38:57AM -0700, Joe Touch wrote: >> NATs already have what they need to do the proper job - they need to >> reassemble and defragment using unique IDs (or cache the first fragment when >> it arrives and use it as context for later - or earlier cached - fragments). >> There???s no rule that IP packets that are fragmented MUST have a transport >> header both visible (not encrypted) and immediately following the IP header. > > Reassmbly/refragment and MTU discovery puts NAT out of the realm of many > cost effective HW acceleration methods. Simple address rewrite does not. > >> Firewalls are just delusions; [1] >> the context they think they???re enforcing has no meaning except at the >> endpoints; it never did. [2] > > I completely agree with [2], but my conclusion is not [1], but > rathat its highly valuable and necessary. > > The ability of firewalls to open 5-tuple bidirectional pinholes because > of trigger traffic from the inside is IMHO the most important feature > to keep Internet hosts protected. I wish host stacks would be built securely, > but after a few decdaces i have given up on that for most hosts. Which is > why its so irritating when host stack pundits continue telling network device > stack builders what they should and should not do. > When the host stack pundits are asking network device stack builders to conform to the standard protocols then I believe that is reasonable. If firewalls were standard and ubiquitous, and standards were adhered to, then host stacks would have no problem. But alas they're not, so we're forced to implement the host stack per the least common denominator functionality of network devices. > Firewalls inspecting unencrypted higher layer message elements where a fairly > well working security model based on having a separate security administration > from the application administration. Now the applications promise to > provide all the security themselves, but they primarily just prohibit > visibility > of what they do, so its a lot harder to figure out when they are insecure. > > Would you ever put all type of in-home "iot" gear thats not a Windows/MacOS > system with a GUI you can control on the Internet without a firewall ? > Conversely, do you allow your smartphone to connect to a network before you've verified that a firewall is being run in the network, what vendor provided it, and what the configured rules are? Tom > Cheers > Toerless > >> Using part of the IPv6 space for this solution would then break per-address >> network management (different UDP ports would use different IPv6 addresses, >> presumably). >> >> The ???disease" is that NATs don???t reassemble (or emulate it). It???s not >> useful to try to address the symptoms of that disease individually. >> >> 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 Sun, Aug 26, 2018 at 7:35 PM, Toerless Eckert wrote: > On Sun, Aug 26, 2018 at 05:10:00PM -0700, Joe Touch wrote: >> Agreed, but reassembly is clearly possible (hosts do it). The issue is cost. >> >> We are not in the business of defending a vendor's idea of profit margin >> WHEN it gets in the way of a required mechanism. I've described why it's >> required; you've indicated that it's expensive. So? > > Cost that is too high translates into "not going to happen". Else > we'd all be commuting in helicopters. > >> > You can always prove the existance of wishfull thinking by >> > assuming all type of stupid advertisements or misunderstanding of >> > achievable functionality. But that does not disprove the >> > existance of useful or necessary functions. > >> A function whose basic existence defies our current standards? > > I thought we where discussing evolution of our standards. > >> You admitted that devices that NAT in the middle of the net wouldn't >> work because of a requirement of IP routing. So why aren't you trying to >> change IP routing to fix the path and not vary - if you want to defend >> the existence of mid-net NATs, then you have to change that requirement too. > > I think we're jumping a bit across various cases. Not that they are not > interesting. My main point was that we should separarte out > fragementation as something useful purely in device types without > necessary a full highler layer transport stack (like routers doing > tunneling at IP layer), and host stacks that should rather do > fragementation at transport stack or higher. And yes, that would enable > me to make NAT and firewalls (for the firewall functions i think make sense) > for host stack traffic something that does not require to bother about > fragmentation and could therefore be done easier at higher speed > and architecturally as something only in the network layer. > >> I'm describing the rules for working within the existing requirements. >> Changing fragmentation alone will not fix what's wrong with NATs or >> firewalls in those cases. > > The draft in question argues to limit what future work should do > within the existing requirements, which is fine. I was merely > pointing out that we could move more into what i think would be > a useful evolution if we also went beyond our current arch > and evolved it. > > It's not really as if IPv6 itself did do a good job in trying to > figure out what network devices can and can not do within sellable > costs. And we're continuing to suffer from it. > >> > If we think fragmentation is only something that needs to happen >> > for tunneling within the network stack then maybe not so much. >> Because you think tunneling happens somewhere else? Tunneling happens at >> host - BY DEFINITION. A device that adds a header with addresses *IS A >> HOST* on the side where it emits those packets. > > Sure. But lets not get stuck on current terminology of "host". Lets just > figure out > what we think are the best rules where to apply fragmentation and why. > I think fragmentation is best pushed up on the stack. Packetization > fragmentation in the "higher layer" is IMHO better than fragments in > the lower layer. Even if the higher layer is a network layer > protocol itself. > >> > If i wouldn't have to worry about such proxy forwarding plane capabilities, >> > i definitely would prefer models like SOCKS. If i have to think about them >> > it becomes certainly difficult to even model this well. >> When you find a complete model better than the Internet, propose it. >> Until then... > > HTTPs over DWDM with application layer proxies on every hop. > You didn't define how to measure "better" ;-) > > The example of SOCKS should have shown that i wasn't trying to replace > the internet architecture, but rather seeing what could be added on the > edge that is both as (IMHO) as useful as SOCKS but more lightweight. > >> No. NATs are hosts because the emit packets with new headers with >> addresses they own. That's the very definition of a host on the side >> where those packets are emitted. > > The architecture misses good terms to better characterize better the > type of nodes sitting in betweenwhat users would perceive to be hosts > (HTTPs/TCP stack and the like) and pure routers. > >> > Aka: yes, logically today, NAT need to go up to >> > transport layer, which is bad. See Christians suggestion. >> His suggestion is to make IP the one header where everything happens - >> but then we don't have layering flexibility. > > Please explain what you think you would loose ? > I see only benefits of moving demux identifiers one layer down. > >> > Transport layer can do PLMTUD/transport layer >> > segmentation. No need for hosts to do IP layer fragementation. >> Please describe how to implement IPsec tunnel mode in that case. > > See terminology discuss. In my text you question, i was referring > to host' as something that can effficiently run TCP/HTTPs stacks, > not as hosts per TCP/IPv6
Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'
On Tue, Aug 28, 2018 at 8:24 AM, Joe Touch wrote: > Some comments below, hopefully constructive/additive... > > Joe > > > > > On 2018-08-24 12:34, Templin (US), Fred L wrote: > > Hello, > > As document shepherd, I am required to perform a review. Please see below > for initial comments, and respond on the list. > > Fred > > --- > > ... > > Section by Section comments: > > ... > > Section 5.4.1: > Second paragraph, "set 94 for IPIP", I was under the impression that the > common > values for IPIP encapsulation are '4' for IPv4 and '41' for IPv6. I have not > seen '94' > appear elsewhere. Is this a common use? If not, would it be better to use > '4' or '41'? > > > 94 is defined here: > >[IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-based > protocols for mobile internetworking", Proceedings of > SIGCOMM '91, ACM, September 1991. > > See RFC 1853 for a list of other "non-4" and "non-6" IP tunnels, but these > are not IP-in-IP -- that should cite RFC2003 (though, as noted in > draft-ietf-tunnels, there are some issues with the details in that RFC). I think it's probably better to use 4 and show the example as IPv4/IP encapsulation since that's probably more common. Thanks, Tom > > Joe > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ 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 Tue, Aug 28, 2018 at 3:09 PM, Toerless Eckert wrote: > Thanks, Joe > > This has gotten pretty long. Let me sumarize my suggestions upfront: > > For the draft itself, how about it also consideres recommendations not only > for IPv6 but IPv4. Such as simply also only do what we've accepted to be > feasible for IPv6. Like: do never rely on in-network fragmentation but > only use DF packets. > > The remaining considerations are more generic, and i wonder if this draft > wants to have the guts to even mention them. Probably not. But IMHO > we will continue to be architecturally stuck in the hole we are if we do not > tackle them for poor middleboxes: > > The IETF may think they are bad and not needed, but reality does need > middleboxes > that function at linerate of only per-packet inspection and not at the lower > speed achievable with "virtual reassembly based inspection". Therefore we > need options to have in every fragment all the same context that middleboxes > reasonably should be able to inspect. > > Its IMHO a clean pragmatic solution to say that this additional context can > be in the higher-layer protocol and that layer willingly exposes it to > middleboxes - > and encrypts everthing else. This view then requires that higher-layer > protocol to perform packet layer fragmentation. Like we can do with > TCP. Thats why that approach is IMHO a good recommendation to use. If > other transport protocols want to support the same degree of interaction > with middleboxes. Fine. If not, fine too. > > Given how we do have TCP PLMTUD, i think it would be nice to suggest the use > of it instead of relying on IP layer fragmentation to make TCP flows more > middlebox friendly. In this draft. AFAIK, its the only option that does not > require new spec work, thats why it could make the cut for this draft. > > For longer term architectural evolution of middlebox friendly IP > fragmentation, > we could indeed have a new IP option carrying that context, and fragmentation > would put this option into every fragment. The definition of this context > could > be per-transport proto. > Toerless, I think it's the opposite-- the definition of the context should be protocol agnostic. We need to get middleboxes out of doing DPI and to stop worrying only about select transport protocols. So we need a mechanism that works equally well with with TCP, UDP, SCTP, ICMP, IPsec, fragments, etc. It definitely needs to be secure though. > I think there could be better middlebox contexts better than port numbers, > but to make fragments work better for existing TCP/UDP middlebox > functions, those 32 bits are it. But given how we can expect exposure of > information only from willing higher layers, they will have a much easier > way to get what they want to support by packet layer fragmentation. A > simple generic packet layer fragmentation for UDP would therefore be nice IMHO > so that UDP applications wanting to be friendly would not have to > reinvent that wheel. That's already in UDP options and some UDP encapsulations like GUE. It's a good idea, but doesn't completely obsolete the use of IP fragmentation. > > If we actually ever do such an IP option, it MUST be a destination option, > because the insufficient RFCs defining the treatment of hop-by-hop options > burned any ability to deploy those. > In PANRG when I suggested that FAST could be done in a Destination Option there was a lot of push back. I think it was for good reason. Hop-by-Hop were designed precisely for inspection and potential modification at intermediate nodes, and the requirement that all nodes in the path process HBH has been relaxed in RFC8200. Destination Options (as well as Fragment EH) aren't supposed to even be inspected at intermediate nodes. The rationale for using DestOpts is of course that they're less likely to be dropped by intermediate nodes. That's true, they are more likely to be dropped; per RFC7872 it's about 15-17% drop rate for DestOpts and 40-43% for HBH. However, given the update in RFC8200 and if some useful HBH options are defined, I would expect that new deployments and replacements might start to lower the HBH drop rate. In any case, the drop rates for DestOpts are still no where close to zero, so regardless of which option is used used some backoff is needed when the options are dropped to continue to work but in a potentially degraded service mode relative to what a working option could provide. Tom > For IPsec, IP in IP or similar higher layer protocols, i would either > use them as the key beneficiary of generic UDP fragmentation (IPsec/IP-UDP-IP) > for pragmatic short term solutions, or else the IP option would equally > be applicable to them (interesting discussionw aht the best context for > them would be, but the two port numbers would make them be most compatible > with those typcialyl very TCP/UDP centric middlebox functions). > > Specific answers to your points below > > Cheers > Toerless > > On Sun, Aug 26, 2
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On Tue, Aug 28, 2018 at 5:24 PM, Toerless Eckert wrote: > On Tue, Aug 28, 2018 at 03:51:58PM -0700, Tom Herbert wrote: >> I think it's the opposite-- the definition of the context should be >> protocol agnostic. We need to get middleboxes out of doing DPI and to >> stop worrying only about select transport protocols. So we need a >> mechanism that works equally well with with TCP, UDP, SCTP, ICMP, >> IPsec, fragments, etc. It definitely needs to be secure though. > > Sure, i meant to imply that port-numbers are useful pragmatically, > but other context identifiers would long term be better. > Demux-Identifiers at the granualarity of a subscriber or > application wold be a lot more scalable than flow identifiers. > > Security is a wide topic. The firewall function of permitting return > traffic on a flow for internally initiated flows for example is a > wonderful simple function that in most deployment does a fine job > without additional security. And in a lot of embedded/walled-garden > networks, additionals ecurity throgh e.g.: ACLs (like through MUD) > is a more appropriate solution than cryptographic security. So > a bit more exploration of viable options would be useful. The least > i want to do is to force Internet PKI and complex out-of-band > middlebox discovery on all solutions where it's not needed. > >> > I think there could be better middlebox contexts better than port numbers, >> > but to make fragments work better for existing TCP/UDP middlebox >> > functions, those 32 bits are it. But given how we can expect exposure of >> > information only from willing higher layers, they will have a much easier >> > way to get what they want to support by packet layer fragmentation. A >> > simple generic packet layer fragmentation for UDP would therefore be nice >> > IMHO >> > so that UDP applications wanting to be friendly would not have to >> > reinvent that wheel. >> >> That's already in UDP options and some UDP encapsulations like GUE. > > Pointers ? > https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options https://tools.ietf.org/html/draft-ietf-intarea-gue-extensions >> It's a good idea, but doesn't completely obsolete the use of IP >> fragmentation. > > Nothing pragmatic will. Just a possible part of recommendations. > >> > If we actually ever do such an IP option, it MUST be a destination option, >> > because the insufficient RFCs defining the treatment of hop-by-hop options >> > burned any ability to deploy those. >> > >> In PANRG when I suggested that FAST could be done in a Destination >> Option there was a lot of push back. I think it was for good reason. > > WHat was for good reason ? Your proposal or the pushback ? > The pushback was reasonable. Using Destination Options in this way would be a hack and non-conformant with the standard. >> Hop-by-Hop were designed precisely for inspection and potential >> modification at intermediate nodes, and the requirement that all nodes >> in the path process HBH has been relaxed in RFC8200. > > Hop-by-hop options have been burned as i said through bad > implementations that for example punt them. Thats why operators often > configure to drop packets with those options to avoid them > burning their bad routers. > > Lets say we come up with some good new solution that depends on > new code written. I would hope we can document/standardize this > in such a way that new code would not be subject to this > legacy problem. But we can not get the benefit of that new code when > we use the existing burned code point for hop-by-hop because > we can not expect to get EXISTING code fixed and we will always > have paths with such old code. > > Aka: if the religious architecture faction makes a fuzz out of > not using destination options for onpath functions, then lets > consider that we could simply rev the codepoint for hop-by-hop > options, but to make that solution stick, we would have to > show that we can write up correct processing RFCs for that > gen2 code-point such that it will not again get burned like > the first odepoint through bad new code. > > I FOR ONCE WOULD SUGGEST TO WRITE THAT RFC STANDARDIZING THAT > REV2 HOP-BY-HOP CODEPOINT LIKE A VERY OLD RFC IN ONLY > CAPITAL LETTER TO GET IT INTO THE HEAD OF EVERY LAST > IMPLEMENTOR OF THAT GEN2 HOP-BY-HOP OPTION CODE POINT TO > NOT REPEAT THE STUPIC CODE THEY WROTE IN ROUND 1. > > Sorry for the soapbox, it's just been a frustration of > mine since the early 2000 when the IPv6 specs did not > well enough improve on this point vs. IPv4 and i had > to rant about a lack of focus on reality of implementati
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On Wed, Aug 29, 2018 at 10:10 AM, Joe Touch wrote: > Tom, > > > > > On 2018-08-29 09:53, tom wrote: > > On Wed, Aug 29, 2018 at 8:11 AM, Joe Touch wrote: > > > > > > On 2018-08-28 17:24, Toerless Eckert wrote: > > ...Sure, i meant to imply that port-numbers are useful pragmatically, > but other context identifiers would long term be better. > Demux-Identifiers at the granualarity of a subscriber or > application wold be a lot more scalable than flow identifiers. > > > There are many problems with this issue. > > First, the reason that port numbers would be needed is that they are > *currently* how NATs demux, firewalls enforce policy, and routers manage > > > There is no requirement in IP that all packets have a transport layer > header that with port numbers. ... > > > Yes, we agree. It's not the only way they SHOULD or COULD work, but it is > how they DO work. > > > > > > Ultimately, we have to admit that a device that acts on behalf of a host IS > a host and costs what a host costs. > > > That in turn breaks the the end-to-end model. > > > > Acting like what you are doesn't break anything; it lets you act to the > fullest extent possible. > > Relaying info through hosts inside a network path is what breaks the E2E > model - agreed. > > All I am saying is that: > - IF you deploy a middle box, THEN it MUST act as a host and reassemble (or > do the equivalent) > > I wasn't endorsing the IF. I don't think you need the part about acting as a host, that would have other implications. Also, the reassembly requirement might be specific to NAT and not other middlebox functionality. For instance, it would be sufficient for a firewall that is dropping UDP packets to some port to only drop the first fragment that has UDP port numbers and let the other fragments pass. Without the first fragment reassembly at the destination will simply timeout and the whole packet is dropped. > > > > > Middleboxes that attempt > to participate transport protocols, like a host, inevitably break > things and hence is another source of ossification. This is readily > evident apparent in that they can't participate in end-to-end crypto. > > > They can* participate in crypto, but then the definition of E2E ends where > it should - at the middlebox. > > * = only if they somehow are given the key, of course > > > > Of course they have tried to insert themselves into that realm, but > then we get abominations such as the forced MITM attacks of SSL > inspection. IMO, real end-to-end security is a core requirement that > outweighs any tradeoffs we might make for the security benefits of > firewalls. > > > I would argue that it is OK to give a middlebox the key if that's OK for a > given trust model, e.g., it would make sense inside an enterprise to offload > security to the ingress of that enterprise. But not elsewhere; > Sure enterprises can do that. But I'm more worried about the five billion mobile devices that may connect to random WIFI or mobile networks over the course of a day. For them there is simply no concept that the network will provide any level of security. Tom > > > > > We can't keep believing there is magic dust that can establish a solution > otherwise. > > As they say, the answer to ossification is encryption. > > > It's not an answer; it renders the question irrelevant, as it should. > > Not all questions necessarily have answers. As Rocket will tell you (ref: > end scenes, Guardians of the Galaxy), wanting something does not make it so. > > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'
On Fri, Aug 24, 2018 at 12:34 PM, Templin (US), Fred L
wrote:
> Hello,
>
> As document shepherd, I am required to perform a review. Please see below
> for initial comments, and respond on the list.
>
Hi Fred,
Thanks for shepherd review and comments! Some response inline.
Tom
> Fred
>
> ---
>
> Overall:
>
> The document is well written and clear. The only thing I wonder is whether
> this
> document needs to be progressed in conjunction with GUEEXTEN or whether it
> can go forward independently. In particular, this draft defines a flags
> registry
> under IANA Considerations but with no initial assignments. Instead, initial
> assignments are assumed to be requested in GUEEXTEN. TBD is whether the
> two documents can be progressed together.
>
The flags field is defined as part of the core GUE header, but the
actual extensions are defined elsewhere. I would like them separate
since that highlights the fact that GUE is exensible. We can move the
IANA request to GUEEXTEN if that makes more sense.
> Section by Section comments:
>
> 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.
>
> Section 3.2.2:
> Final sentence: "This document does not specify any standard control message
> types other than type 0." If this document defines type 0, then the format and
> use of that message type should be specified here. Also, IANA considerations
> simply says: "Need Further Interpretation" - I think that interpretation
> should
> appear in this document.
It's the control message equivalent of IP protocol 59 as discussed
above. The payload is a control message (or at least part of one) but
cannot be parsed with addition context (like a reassembled packet,
after a GUE transform, etc.).
>
> Section 3.3:
> The use of "flags" and "paired flags" is discussed but with no actual flags
> assignments appearing in this document. Instead, it quotes from "GUEEXTEN".
> Is that OK?
>
The reference to GUEEXTEN is not material and can be removed.
> Section 4:
> Misspelled "varinant". Check rest of document for spelling.
>
Okay.
> Section 5:
> Final sentence of first paragraph, suggest changing: "Packet flow in the
> reverse
> direction need not be symmetric; GUE encapsulation is not required in the
> reverse path." to: "Packet flow in the reverse direction need not be
> symmetric;
> for example, the reverse path might not use GUE and/or any other form of
> encapsulation."
>
Okay.
> Section 5.4:
> The sentence "No error message is returned back to the encapsulator." Suggest
> removing this sentence and remain silent. Reason is that future variants may
> well indicate the use of some form of error messaging.
>
Okay.
> Section 5.4.1:
> Second paragraph, "set 94 for IPIP", I was under the impression that the
> common
> values for IPIP encapsulation are '4' for IPv4 and '41' for IPv6. I have not
> seen '94'
> appear elsewhere. Is this a common use? If not, would it be better to use '4'
> or '41'?
>
Correct, 4 should be used for IPv4 and 41 should be used for IPv6
encapsualtion in examples.
> Section 5.5:
> The sentence including: "there are no provisions to automatically GUE copy
> flags"
> appears to have a wording issue that I could not parse.
Okay, will fix.
>
> Section 5.11:
> Is "flow entropy" mandatory or optional? For example, shouldn't it be OK for
> the
> encapsulator to set the UDP source port to anything of its own choosing if it
> does
> not want to get involved with flow entropy determination?
>From section 5.6.1:
"The selection of whether to make the UDP source port fixed or set to
a flow entropy value for each packet sent SHOULD be configurable for a
tunnel. The default MUST be to set the flow entropy value in the UDP
source port."
Is more clarificaiton needed?
>
> Section 6.2:
> "Generic UDP Encapsulation for IP Tunneling (GRE over UDP)" - the correct
> title
> of this RFC is "GRE-in-UDP Encapsulation".
>
Okay, will fix.
> Section 6.2:
> "Generic UDP tunneling [GUT]" expired in 2010. Can we either drop this or
> refer
> to it in the past tense?
>
Okay, can delete it.
> Section 8.3:
> Control type 0 defined as: "Need further interpretation". I think this
> doc
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On Wed, Aug 29, 2018 at 5:32 PM, Joe Touch wrote: > > > > > On 2018-08-29 10:38, Tom Herbert wrote: > > > I don't think you need the part about acting as a host, that would > have other implications. > > > It does, and that's exactly why you do. In particular, this includes ICMP > processing. > > > Also, the reassembly requirement might be > specific to NAT and not other middlebox functionality. For instance, > it would be sufficient for a firewall that is dropping UDP packets to > some port to only drop the first fragment that has UDP port numbers > and let the other fragments pass. Without the first fragment > reassembly at the destination will simply timeout and the whole packet > is dropped. > > > And that's a great example of why not reassembling (or equivalent) isn't the > appropriate behavior. > > Yes, the packet will still not be delivered, but the receiver will end up > doing a lot of work that isn't necessary. I.e., the middlebox has ignored > work it was responsible for and caused work elsewhere. Joe, End hosts are already quite capable of dealing with reassembly, I think you'll find the average middlebox is not prepared to handle it. In truth, for this case it really doesn't save the hosts much at all. A DOS attack on fragmentation is still possible by the attacker sending all but the last fragment to a port that is allowed by the firewall. Also, a destination host will receive all the fragments for reassembly by virtue of it being the having destination address in the packets. As discussed previously, there's no guarantee that a firewall will see all the packets in a fragment train in a mulithomed environment-- routing may take packets along different paths so they hit hit different firewalls for a site. The answer to that seems to be to somehow coordinate across all the firewalls for a site to act as single host-- I suppose that's possible, but it would be nice to see the interoperable protocol that makes that generally feasible at any scale. > > Further, acting as a host is always the right thing for any node that > sources packets with its own IP address -- that includes NATs and regular > proxies. The behavior of transparent proxies is more complex, but can be > similarly reasoned from the appropriate equivalence model. Proxies aren't quite the same though. An explicit proxy at least is both receiving and sourcing packet based on it's own address. NAT only sources or receive packets with their own address half the time. Firewalls, never do and don't even need a host address. Tom ___ 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 Wed, Aug 29, 2018 at 7:58 PM, Joe Touch wrote: > > > > > On 2018-08-29 18:34, Tom Herbert wrote: > > > Joe, > > End hosts are already quite capable of dealing with reassembly, > > > 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". > > FWIW, the idea of dumping just the first fragment and letting the receiver > clean it up was tried in ATM in the late 1980s and it failed badly. It turns > out that congestion isn't always a point problem - when multiple routers in > a path are overloaded (which can and does happen), not dropping the rest of > the fragments can cause downstream congestion that wouldn't have happened > otherwise and then drops to other "real" packets. > > > I > think you'll find the average middlebox is not prepared to handle it. > > > Sure, but that's a problem I'm hoping we can fix rather than encourage > continued bad behavior. > > > In truth, for this case it really doesn't save the hosts much at all. > > > It won't prevent endpoint attacks, but it does mitigate the effect of > useless fragment processing. And, as per above, it avoids drops to other > packets that could/should have made it through. > > > A DOS attack on fragmentation is still possible by the attacker > sending all but the last fragment to a port that is allowed by the > firewall. Also, a destination host will receive all the fragments for > reassembly by virtue of it being the having destination address in the > packets. As discussed previously, there's no guarantee that a firewall > will see all the packets in a fragment train in a mulithomed > environment-- routing may take packets along different paths so they > hit hit different firewalls for a site. The answer to that seems to be > to somehow coordinate across all the firewalls for a site to act as > single host-- I suppose that's possible, but it would be nice to see > the interoperable protocol that makes that generally feasible at any > scale. > > > Compared to other solutions proposed in this thread, that one is nearly > trivial to design. The issue is having operators - who deploy these devices > in ways that they should know need this feature - enable it properly (i.e., > point them all at each other). > Joe, I would be amazed if firewall vendors consider this "nearly trivial to design". Reassembly requires memory to hold packets, a non-work conserving datapath, requires state to be maintained, and the aforementioned problems of consistent routing of fragments needs to be resolved. A middlebox would be performing reassembly on behalf of some number of backend hosts, so the memory requirement for reassembly is some multiplier of that needed by an individual host. Non-work conserving means packets need to be queued at the device which requires cache management and introduces delay. Requiring state in _stateless_ devices is a problem, it's likely they have neither the mechanisms nor the memory to support reassembly. And then there's the Denial Of Service considerations... the middlebox is now an obvious target for DOS attack on reassembly. We need to deal with this on hosts, but the attacks are going to be worse on middleboxes. Consider that a middlebox wouldn't normally know all possible hosts in the network, so it may very well end up reassembling packets for destinations that don't even exist! And on top of all of this, applications are still motivated to avoid fragmentation for other reasons, so I suspect vendors will view as a lot of work for very little benefit. > > Further, acting as a host is always the right thing for any node that > sources packets with its own IP address -- that includes NATs and regular > proxies. The behavior of transparent proxies is more complex, but can be > similarly reasoned from the appropriate equivalence model. > > > Proxies aren't quite the same though. > > > They are three different things, as noted in the paper I posted earlier, but > they all are variants of requiring host behavior of some sort. > > > > An explicit proxy at least is > both receiving and sourcing packet based on it's own address. NAT only > sources or receive packets with their own address half the time. > > > Sure, but there's more to it than just using the address...(see next note) > > > > Firewalls, never do and don't even need a host address. > > > Transport protocols are endpoint demultiplexers and state managers; anything > that uses that info and/or state is also acting as a host and needs to > follow at least some host requirements too
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
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] Document shepherd comments on 'draft-ietf-intarea-gue-05'
On Fri, Aug 31, 2018 at 7:16 PM, Joe Touch wrote:
> 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.
>
Hi Joe,
The GUE fragmentation option includes a orig-proto field to hold the
protocol of the reassembled packet. That needs to be matched in all
fragments along with srd/dst and ID, Also the protocol field in the
GUE header of the first fragment must also match. So the ID space is
basically defined the same way as IP fragmentation.
Tom
> Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt
Hi Brian, Thanks for the draft! I am still concerned about the implications and perceptions this draft might entail. Particularly, I wonder whether this will fracture the Internet (even more) and encourage (even more) protocol ossification by allowing developers and protocol designers to take short cuts that skimp on interoperability and use proprietary solutions instead of investing in open ones (with the vendor lock-in that goes with that). Consider this from the draft: "This section suggests that protocols or protocol extensions should, when appropriate, be standardised to interoperate only within a Limited Domain Boundary. Such protocols are not required to operate across the Internet as a whole." I'm not sure what "not required to operate across the Internet as a whole" means. Specifically, what does it mean for a protocol to not have to "operate" on the whole Internet. I think there are three possible meanings here: 1) using the protocol across the whole Internet isn't useful because it depends on localized information 2) using the protocol on the Internet isn't feasible because there is a lack of global support for it in the Internet 3) using the protocol on the whole Internet isn't correct and leads to bad behaviors. Example of #1 is segment routing, example of #2 is IPv6 extension headers, and example of #3 is extension header insertion. Of the three possibilities, an incorrect protocol is the most problematic. As a litmus test, consider that a Limited Domain implies a security perimeter exists around the domain that would contain the Limited Domain protocol. We know that such perimeters can and will break down at some point so that some day a limited domain protocol will leak into the Internet. That cannot lead to incorrect behavior, this cannot break the Internet! I submit that if a protocol cannot operate *correctly* in the Internet, or would break correct operation of other protocols on the Internet, then it is _not_ an Internet protocol. The part about "interoperate only within a Limited Domain Boundary" is also interesting. I worry vendors make take a lot of license with this. For instance, I have heard one suggestion that mobile operators might "give" each hardware vendor there own slice. So a Limited Domain is defined to contain only one vendor's equipment. Interoperability within a single implementation is rarely an issue! While I don't think it's our business to prevent things like this (network operators can do what they want within their domain), neither do I think we should be encouraging or facilitating it. IETF is fundamentally about standardizing open, interoperable Internet protocols. I guess the consequences of this is that if someone defines a protocol that only operates in a limited domain, then the limited domain itself needs to be clearly defined in normative language. Tom On Tue, Sep 11, 2018 at 8:30 PM, Brian E Carpenter wrote: > New version, with a first draft of a taxonomy added. > > Discussion welcome. > >Brian + Bing > > Forwarded Message > Subject: I-D Action: draft-carpenter-limited-domains-03.txt > Date: Tue, 11 Sep 2018 20:18:56 -0700 > From: internet-dra...@ietf.org > Reply-To: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Limited Domains and Internet Protocols > Authors : Brian Carpenter > Bing Liu > Filename: draft-carpenter-limited-domains-03.txt > Pages : 19 > Date: 2018-09-11 > > Abstract: >There is a noticeable trend towards network requirements, behaviours >and semantics that are specific to a limited region of the Internet >and a particular set of requirements. Policies, default parameters, >the options supported, the style of network management and security >requirements may vary. This document reviews examples of such >limited domains and emerging solutions, and develops a related >taxonomy. It shows the needs for a precise definition of a limited >domain boundary and for a corresponding protocol to allow nodes to >discover where such a boundary exists. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-carpenter-limited-domains-03 > https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-03 > > > 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/ > >
Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt
On Wed, Sep 12, 2018 at 1:53 PM, Brian E Carpenter wrote: > Tom, > > On 2018-09-13 04:10, Tom Herbert wrote: >> Hi Brian, >> >> Thanks for the draft! >> >> I am still concerned about the implications and perceptions this draft >> might entail. Particularly, I wonder whether this will fracture the >> Internet (even more) and encourage (even more) protocol ossification >> by allowing developers and protocol designers to take short cuts that >> skimp on interoperability and use proprietary solutions instead of >> investing in open ones (with the vendor lock-in that goes with that). > > Of course that's a concern. My personal opinion is since it's going to > happen anyway (in fact, has been happening for many years in reality), > we are better off to bite the bullet and face reality. If the IoT is > anything real, it means we're going to make the Internet 100 times bigger > and that seems inconceivable without limited domains at the edges. > Yes, but it's not yet clear that a formal concept of Limited Domains is required to scale the Internet, or at least is required as an entity that defines or drives requirements in protocols. Consider the world of mobile. Every mobile provider runs their network as a Limited Domain already in order to manage the mobile devices in their network. But everyone runs their domain differently. For example, some have firewalls, some have proxies, some provide no security. At the end of the day, a device can't assume that all networks provide anything but connectivity. Knowing that a device is connected to some standard "Limited Domain" that might imply a set of available services isn't much consolation. Instead of talking about network devices be non-conformant to the protocols, we'll be talking about whether networks conform to the definition of a limited domain. Note also, that some other SDOs already define standards for limited domains. 3GPP in particular, specifies both the network architecture and protocols for a mobile network (e.g. 5G specification). While it one sense it's good to have a common model and architecture for mobile networks, I believe that is at the expense of having a very complex protocol that is extremely hard to change. IMO, IETF's strength and advantage is that it focuses on standardizing protocols without standardizing network architecture. This provides all the necessary freedom for to build networks as appropriate and encourage innovation on many fronts. For the most part this model seems to haved worked well. The same TCP/IP protocol suite that works over the Internet also works in the largest data center down to the smallest home network. Sure, to make things work, use of protocols and configurations need to be adapted for different use, but we haven't yet had to radically change the protocol because it needs to run in a new environment (I suppose one might consider NAT as a radical change, but that is supposed to be obsoleted by IPv6 anyway :-) ). Tom >> Consider this from the draft: >> >> "This section suggests that protocols or protocol extensions should, >> when appropriate, be standardised to interoperate only within a >> Limited Domain Boundary. Such protocols are not required to operate >> across the Internet as a whole." >> >> I'm not sure what "not required to operate across the Internet as a >> whole" means. Specifically, what does it mean for a protocol to not >> have to "operate" on the whole Internet. > > Yes, this area needs more work. Our idea was to do that next, after > getting the taxonomy into shape. Your comments below are very insightful > and help a lot. Just one specific comment below at this point. > >> I think there are three >> possible meanings here: 1) using the protocol across the whole >> Internet isn't useful because it depends on localized information 2) >> using the protocol on the Internet isn't feasible because there is a >> lack of global support for it in the Internet 3) using the protocol on >> the whole Internet isn't correct and leads to bad behaviors. Example >> of #1 is segment routing, example of #2 is IPv6 extension headers, and >> example of #3 is extension header insertion. Of the three >> possibilities, an incorrect protocol is the most problematic. As a >> litmus test, consider that a Limited Domain implies a security >> perimeter exists around the domain that would contain the Limited >> Domain protocol. We know that such perimeters can and will break down >> at some point so that some day a limited domain protocol will leak >> into the Internet. That cannot lead to incorrect behavior, this cannot >> break the Internet! I subm
Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt
On Wed, Sep 12, 2018 at 5:39 PM, Amelia Andersdotter wrote: > Dear all, > > Thanks Brian for going through all this work, and Tom and Alexandre for > providing interesting feedback. > > In section 3, it may be more interesting to divide Examples of Limited > Domain Requirements into networks containing human end-users and > networks that don't contain human end-users (such as industrial systems, > sensor networks, IoT, etc, merging the home network and small office > network use-cases). It would make the taxonomy a more useful tool for > assessing the limited domain requirements, and is better adjusted to how > demands for (or requirements/expectations on) these limited domains > arise in the real world. That could serve as a basis for elaboration of > section 7. > Hi Amelia, I'm curious why you think discriminating networks containing end-users and those that don't would be helpful here. Until the rise of the machines happens, isn't it true that all communication networks exist to serve humans in some fashion? For instance, if someone deploys radiation sensors in a nuclear power planet and connects them as IoT to their network, doesn't that make the workers in the power plant effectively end-users of those devices? Or to put a darker spin on it, if such devices are breached then couldn't bring harm to people just as easily as if a normal "end-user device" is compromised? Tom > More broadly, I share Tom's concerns that this justifies using the IETF > as a platform for standardising intRAnets, rather than an intERnet. But > > On 2018-09-12 22:53, Brian E Carpenter wrote: >> I'd go a bit further - I think we need to standardize the mechanisms >> for identifying and defining the boundary, so that what happens inside >> can be effectively contained. That helps everybody. > > This makes sense, and could perhaps even help constructively with some > issues (such as privacy/security issues discussed in SUIT) that arise > when specific limitations on node privacy or security as described > RFC6973 or RFC8280 aren't relevant, because no human is technically > impacted. > > best regards, > > Amelia > > -- > Amelia Andersdotter > Technical Consultant, Digital Programme > > ARTICLE19 > www.article19.org > > PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt
On Wed, Sep 12, 2018 at 7:42 PM, Brian E Carpenter wrote: > Just picking on one part of Tom's excellent note: > > On 2018-09-13 11:14, Tom Herbert wrote: > ... >> IMO, IETF's strength and advantage is that it focuses on standardizing >> protocols without standardizing network architecture. This provides >> all the necessary freedom for to build networks as appropriate and >> encourage innovation on many fronts. For the most part this model >> seems to haved worked well. > > Well, I think we have counter-examples. PMTUD failure for one. Opaqueness > of the Internet to new IPv6 extension headers for another. The strong > desire from some operators to deploy locally-significant extensions > in a standardized way for another. Okay, some operators want such things. However, the specifics of what they're requesting are pertinent as to whether these should be undertaken in IETF. In particular, each request should be evaluated against the "necessary and sufficient" test. It might be good to discuss in some detail a few specific locally-significant extensions in the draft, particularly those that fall into the category of "not correct" when used on the Internet. I will give one example. The draft mentions extension header insertion (I-D.voyer-6man-extension-header-insertion). Some operators want it as unabashedly indicated by the first line of the abstract in that draft: "The network operator and vendor community has clearly indicated that IPv6 header insertion is useful and required.". There was quite a bit of discussion of this draft on 6man list. I believe the (current) consensus is that it's neither necessary nor sufficient protocol. It's not necessary because IP/IP encapsulation can be used to achieve the same effect. It's not sufficient because it makes several requirements on the network that are outside the specification of the protocol. Tom > And we've developed solutions > already, dating back at least to SOCKS. So haven't we been implicitly > pretending that this elephant wasn't in the room? > > Brian ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Fwd: New Version Notification for draft-herbert-intarea-gue-ctrl-messages-00.txt
Hello, I have posted a draft defining some control messages for GUE. These are for capabilties query/response and echo request/reply. There are another two defined in https://tools.ietf.org/html/draft-herbert-tsvwg-gte. Comments are appreciated! Thanks, Tom -- Forwarded message -- From: Date: Mon, Oct 1, 2018 at 2:54 PM Subject: New Version Notification for draft-herbert-intarea-gue-ctrl-messages-00.txt To: Tom Herbert A new version of I-D, draft-herbert-intarea-gue-ctrl-messages-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-intarea-gue-ctrl-messages Revision: 00 Title: Control Messages for Generic UDP Encapsulation Document date: 2018-10-01 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-herbert-intarea-gue-ctrl-messages-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-intarea-gue-ctrl-messages/ Htmlized: https://tools.ietf.org/html/draft-herbert-intarea-gue-ctrl-messages-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-intarea-gue-ctrl-messages Abstract: This specification defines a set of basic control messages for Generic UDP Encapsulation (GUE). One pair of messages provides a means to query the GUE capabilities of a peer, another pair defines an echo request and response exchange for testing reachability. 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. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Fwd: New Version Notification for draft-herbert-route-fast-00.txt
Hello, This draft describes how to encoded routing information in Firewall and Service Tickets (draft-herbert-fast-00). The basic idea is that packets carry instructions on how they are routed in a network. An important feature of FAST is that tickets can be reflected by a peer in communication so that the routing can be applied in the return path. This can be exploited to set the locator of a mobile node, or to indicate the backend server for a flow when doing layer 4 load balancing. Comments are appreciated! Thanks, Tom -- Forwarded message -- From: Date: Wed, Oct 10, 2018 at 11:18 AM Subject: New Version Notification for draft-herbert-route-fast-00.txt To: Tom Herbert A new version of I-D, draft-herbert-route-fast-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-route-fast Revision: 00 Title: Encoding Routing in Firewall and Service Tickets Document date: 2018-10-10 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-herbert-route-fast-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-route-fast/ Htmlized: https://tools.ietf.org/html/draft-herbert-route-fast-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-route-fast Abstract: This document describes a method to encode routing information in Firewall and Service Tickets (FAST). Encoded routing information provides the local routing for packets sent in either the forward or return paths of a flow. FAST ticket reflection at peer hosts ensures that the routing information is attached to packets being sent in the return path. When a packet with a FAST ticket containing routing information enters the network in which the ticket was issued, the ticket is parsed to extract the routing information and is forwarded per the information. Routing in Firewall and Service Tickets has a number of use cases. It can be used as a type of source routing, used with identifier-locator protocols to provide a locator in the return path, and can be used to specify a backend instance in Layer 4 load balancing for processing connections to a virtual IP address. 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. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
Thanks for the updated draft. Here are a few comments: "While this document identifies issues associated with IP fragmentation, it does not recommend deprecation. Some applications (e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation." I would add that use of fragmentation is also expected to work and be common in limited domains where issues in security and interoperability in intermediate nodes can be addressed, >From the draft: "This section explains how IP fragmentation reduces the reliability of Internet communication." In reality, for most of the examples in this section it's really implementations (NAT, firewall, etc.) that are breaking IP fragmentation (and other things as well). Sections 4.1-4.4 could be summarized to say that some intermediate devices perform functions based on inspecting transport layer headers, and these fail when fragments are presented that don't contain the transport layer information. This could be further subdivided into stateful and stateless mechanisms. Policy routing, firewalls, NAT are just examples of functions that break with fragmentation. For section 4.5 I'm not sure that being insecure makes fragmentation unreliable. Similarly 4.6 isn't really a problem with fragmentation but a process to avoid fragmentation. Maybe section 4 should be "Problems related to the use of IP fragmentation". "It is difficult to determine why network operators drop fragments." In what sense is this "difficult"? Difficult because there are no ICMP errors for dropped fragments, difficult because network operators don't share their policy on fragmentation, or other meaning? Tom On Wed, Oct 10, 2018 at 7:38 AM, wrote: > > 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 : IP Fragmentation Considered Fragile > Authors : Ron Bonica > Fred Baker > Geoff Huston > Robert M. Hinden > Ole Troan > Fernando Gont > Filename: draft-ietf-intarea-frag-fragile-01.txt > Pages : 24 > Date: 2018-10-10 > > Abstract: >This document describes IP fragmentation and explains how it reduces >the reliability of Internet communication. > >This document also proposes alternatives to IP fragmentation and >provides recommendations for developers and network operators. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-01 > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-frag-fragile-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-frag-fragile-01 > > > 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 mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018, 8:14 AM Ron Bonica wrote: > Hi Fred, > > Thanks for reviewing yet another version of the draft. But I would like to > push back ever-so-gently on your proposed edit. > > We agree that the draft does not and should not propose the deprecation of > IP Fragmentation. We also agree that IP tunnels require fragmentation. And > because one critical application requires fragmentation, we cannot > deprecate it. > > Yes, there may be other applications that require fragmentation. IPERF may > be one of them. But we don't need to mention it because we have already > made our case against deprecation. Mentioning every application that > requires fragmentation is over-kill. > Iperf is just a test application so it shouldn't be mentioned here anyway. It does illustrate another problem of fragmentation. That is if just one fragment of a packet is lost then the whole packet is lost. So with a 1% drop rate, a packet with two fragments has a drop rate of 2%, 10 fragments has drop rate of 10% 64K packet makes 43 fragments of 1500 bytes so drop rate of those packets is 35%. I believe this amplified drop rate is a problem inherent of fragmentation and good reason why not to use fragmentation over the Internet. This probably should be mentioned in the draft. Tom > Ron > > > > Message: 2 > > Date: Wed, 10 Oct 2018 16:22:47 + > > From: "Templin (US), Fred L" > > To: "int-area@ietf.org" > > Subject: Re: [Int-area] I-D Action: > > draft-ietf-intarea-frag-fragile-01.txt > > Message-ID: > > <554d668a29934ecf9fdf95d77d1cca52@XCH15-06- > > 08.nw.nos.boeing.com> > > Content-Type: text/plain; charset="us-ascii" > > > > I made this comment earlier, but it does not appear to have made it into > this > > version. > > Some applications invoke IP fragmentation as a performance optimization, > > and that should be mentioned here. But, it also needs to say that RFC4963 > > warns against reassembly errors at high data rates. > > > > Suggestion is to add the following to the introduction: > > > >"While this document identifies issues associated with IP > >fragmentation, it does not recommend deprecation. Some applications > >(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. Others > (e.g., > >[IPERF3]) invoke IP fragmentation as a performance optimization, but > >can incur reassembly errors at high data rates [RFC4963]." > > > > Thanks - Fred > > fred.l.temp...@boeing.com > > > * > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018 at 9:46 AM, Joe Touch wrote: > Two points I'd like to make: > > 1) it is very important to list at least one other application besides > tunneling that relies on fragmentation. Frankly, unless the list is > prohibitively long, it should absolutely be included to help avoid this > document laying the foundation for future arguments to deprecate > fragmentation "except for tunnels". Iperf is more than just a test > application; it speaks to the issue of network monitoring using active > injection using that tool, so it's more than 'just a test application'. > > 2) The statistics below assume independent drop probabilities. A smarter way > to handle fragment drops was realized in the ATM/AAL5 days, i.e., when you > drop a fragment at a queue, then drop all other associated fragments (if > possible, if nearby, etc.). Note that tail drop would already potentially do > this at least partly and other drop mechanisms might be extended to have > similar properties without actually scanning the queue. > Joe, That doesn't improve the drop rate. At best it's just providing early drop to save some resources. I don't think there's any argument that fragmentation has higher goodput than equivalent unfragmented stream of packets. Tom > Joe > > > > On 2018-10-15 08:32, Tom Herbert wrote: > > > > On Mon, Oct 15, 2018, 8:14 AM Ron Bonica wrote: >> >> Hi Fred, >> >> Thanks for reviewing yet another version of the draft. But I would like to >> push back ever-so-gently on your proposed edit. >> >> We agree that the draft does not and should not propose the deprecation of >> IP Fragmentation. We also agree that IP tunnels require fragmentation. And >> because one critical application requires fragmentation, we cannot deprecate >> it. >> >> Yes, there may be other applications that require fragmentation. IPERF may >> be one of them. But we don't need to mention it because we have already made >> our case against deprecation. Mentioning every application that requires >> fragmentation is over-kill. > > > Iperf is just a test application so it shouldn't be mentioned here anyway. > It does illustrate another problem of fragmentation. That is if just one > fragment of a packet is lost then the whole packet is lost. So with a 1% > drop rate, a packet with two fragments has a drop rate of 2%, 10 fragments > has drop rate of 10% 64K packet makes 43 fragments of 1500 bytes so drop > rate of those packets is 35%. > > I believe this amplified drop rate is a problem inherent of fragmentation > and good reason why not to use fragmentation over the Internet. This > probably should be mentioned in the draft.. > > Tom > >> >> >> Ron >> >> >> > Message: 2 >> > Date: Wed, 10 Oct 2018 16:22:47 + >> > From: "Templin (US), Fred L" >> > To: "int-area@ietf.org" >> > Subject: Re: [Int-area] I-D Action: >> > draft-ietf-intarea-frag-fragile-01.txt >> > Message-ID: >> > <554d668a29934ecf9fdf95d77d1cca52@XCH15-06- >> > 08.nw.nos.boeing.com> >> > Content-Type: text/plain; charset="us-ascii" >> > >> > I made this comment earlier, but it does not appear to have made it into >> > this >> > version. >> > Some applications invoke IP fragmentation as a performance optimization, >> > and that should be mentioned here. But, it also needs to say that >> > RFC4963 >> > warns against reassembly errors at high data rates. >> > >> > Suggestion is to add the following to the introduction: >> > >> >"While this document identifies issues associated with IP >> >fragmentation, it does not recommend deprecation. Some applications >> >(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. Others >> > (e.g., >> >[IPERF3]) invoke IP fragmentation as a performance optimization, but >> >can incur reassembly errors at high data rates [RFC4963]." >> > >> > Thanks - Fred >> > fred.l.temp...@boeing.com >> > >> * >> >> ___ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Fwd: New Version Notification for draft-herbert-tsvwg-gte-00.txt
Hello, Here is the draft for Generic TCP Encapsulation. This is for encapsulating packets within a TCP stream (to get packets through a firewall for instance). This is pretty much a straightforward mapping of GUE message format over TCP. Since TCP gives connection context there are some optimizations that could be done such as compressing out a GUE header that is common in every message. Comments are appreciated! Thanks, Tom -- Forwarded message -- From: Date: Fri, Sep 28, 2018 at 3:14 PM Subject: New Version Notification for draft-herbert-tsvwg-gte-00.txt To: Tom Herbert A new version of I-D, draft-herbert-tsvwg-gte-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-tsvwg-gte Revision: 00 Title: Generic TCP Encapsulation Document date: 2018-09-27 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-herbert-tsvwg-gte-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-tsvwg-gte/ Htmlized: https://tools.ietf.org/html/draft-herbert-tsvwg-gte-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-tsvwg-gte Abstract: This specification describes Generic TCP Encapsulation (GTE) which is a method to encapsulate packets of different IP protocols within TCP data streams. Encapsulating packets in TCP facilitates communications across networks that block or sub-optimally handle non-TCP traffic. GTE is an adaptation of Generic UDP Encapsulation (GUE) to work in the context of TCP. GTE employs the GUE encapsulation format and optional extensions. 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. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018 at 11:00 AM, Joe Touch wrote: > > > > > On 2018-10-15 09:59, Tom Herbert wrote: > > On Mon, Oct 15, 2018 at 9:46 AM, Joe Touch wrote: > > Two points I'd like to make: > > 1) it is very important to list at least one other application besides > tunneling that relies on fragmentation. Frankly, unless the list is > prohibitively long, it should absolutely be included to help avoid this > document laying the foundation for future arguments to deprecate > fragmentation "except for tunnels". Iperf is more than just a test > application; it speaks to the issue of network monitoring using active > injection using that tool, so it's more than 'just a test application'. > > 2) The statistics below assume independent drop probabilities. A smarter way > to handle fragment drops was realized in the ATM/AAL5 days, i.e., when you > drop a fragment at a queue, then drop all other associated fragments (if > possible, if nearby, etc.). Note that tail drop would already potentially do > this at least partly and other drop mechanisms might be extended to have > similar properties without actually scanning the queue. > > Joe, > > That doesn't improve the drop rate. > > > I'm proposing dropping associated fragments instead of other (new) > fragments. > > This would result in the same number of bytes and packets dropped (thus > freeing up the same resources both per packet and per byte), but would > clearly reduce the number of impacted reassembled packets. > Why is that clear? Of course when dropping a fragment then it makes to drop all related fragments of the train. But there's no guarantee that the node even sees any of the other fragments. Something like RED might help with locality of fragments arriving is true, but only offers heuristics to mitigate the problem. > Please explain why you think this would not improve the drop rate, just as > *did* for ATM/AAL5. > > > > At best it's just providing early > drop to save some resources. > > > Which frees those resources up for other packets/fragments... > > > I don't think there's any argument that > fragmentation has higher goodput than equivalent unfragmented stream > of packets. > > > Agreed. But your math is incorrect unless drops are uncorrelated; correlated > losses could result in nearly the same impact on fragmented packets as non > fragmented packets. Dropping at oversubscribed queue isn't the only source of drops, a lossy radio link could produce uncorrelated losses for instance. Besides that, if you want to consider correlated drops then the math is very different. For instance, suppose someone sends 10 TCP segments which could alternatively be sent as one TCP segment and 10 fragments. Now suppose last 5 packets are dropped in each case. Goodput in TCP is 5 packets worth of data, goodput in fragmentation is zero. > > Yes, it won't get better for fragments but it doesn't have to get worse, or > at least as linearly worse as you claim. It would be interesting to see the reall world case where fragmentation can do better or as good (either in goodput or performance), but I'm doubtful that exists. > > Joe > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018 at 11:41 AM, Templin (US), Fred L wrote: >> It would be interesting to see the reall world case where >> fragmentation can do better or as good (either in goodput or >> performance), but I'm doubtful that exists. > > One of the applications I am referring to works over space links where there > are long delays, but no congestion and hence little/no IP packet/fragment > loss. > This is a case of a long, fat network (LFN) and because there is significant > delay > (reliable) UDP is used instead of TCP. Okay, that could be one use case. But then I have to ask: why not just crank up MTUs to a high number to eliminate fragmentation overhead? Tom > > Thanks - Fred ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018 at 12:06 PM, Templin (US), Fred L wrote: > Hi Tom, > >> -Original Message----- >> From: Tom Herbert [mailto:t...@herbertland.com] >> Sent: Monday, October 15, 2018 11:52 AM >> To: Templin (US), Fred L >> Cc: Joe Touch ; Ronald Bonica ; >> int-area >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt >> >> On Mon, Oct 15, 2018 at 11:41 AM, Templin (US), Fred L >> wrote: >> >> It would be interesting to see the reall world case where >> >> fragmentation can do better or as good (either in goodput or >> >> performance), but I'm doubtful that exists. >> > >> > One of the applications I am referring to works over space links where >> > there >> > are long delays, but no congestion and hence little/no IP packet/fragment >> > loss. >> > This is a case of a long, fat network (LFN) and because there is >> > significant delay >> > (reliable) UDP is used instead of TCP. >> >> Okay, that could be one use case. But then I have to ask: why not just >> crank up MTUs to a high number to eliminate fragmentation overhead? > > It is a good question, but it is not always possible to lay hands on the > media to > set a larger MTU. And some link types (e.g., legacy Ethernet) don't support > larger MTUs anyway. Of course, modern Ethernet with 9K jumbos can do > more but some applications may want to push the UDP datagram size all > the way to 64K. > > From what I saw when I was working with iperf3. By default, it uses 8KB > UDP datagram sizes when it runs on Ubuntu. By setting the UDP datagram > size to a smaller value (i.e., one that needs less IP fragmentation) it shows > a performance decrease. By setting the UDP datagram size to a larger value > (i.e., one that needs more IP fragmentation) it shows a performance increase. > Yes, this because it's better to wake application once than mutiple times for smaller packets. Can you provide any more information about the L2 protocols for the space link? Do they do their own packetization implementing reliability and I'm guessing a bunch of FEC? Tom > Fred > >> Tom >> >> > >> > Thanks - Fred ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018 at 12:11 PM, Ron Bonica wrote: > Hi Tom, > > Hope you are feeling better. Comments inline. > > Ron > > >> Message: 1 >> Date: Wed, 10 Oct 2018 13:55:16 -0700 >> From: Tom Herbert >> To: int-area >> Subject: Re: [Int-area] I-D Action: >> draft-ietf-intarea-frag-fragile-01.txt >> Message-ID: >> > il.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> Thanks for the updated draft. Here are a few comments: >> >> "While this document identifies issues associated with IP fragmentation, it >> does not recommend deprecation. Some applications (e.g., [I-D.ietf-intarea- >> tunnels]) require IP fragmentation." >> >> I would add that use of fragmentation is also expected to work and be >> common in limited domains where issues in security and interoperability in >> intermediate nodes can be addressed, > > Fair enough. Does the following edit work for you > > OLD> >While this document identifies issues associated with IP >fragmentation, it does not recommend deprecation. Some applications >(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. > > NEW> >While this document identifies issues associated with IP >fragmentation, it does not recommend deprecation. Some applications >(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. Furthermore, >fragmentation is expected to work in limited domains where security and > interoperability >issues can be addressed. > > >> >> >From the draft: "This section explains how IP fragmentation reduces >> the reliability of Internet communication." In reality, for most of the >> examples >> in this section it's really implementations (NAT, firewall, etc.) that are >> breaking >> IP fragmentation (and other things as well). >> >> Sections 4.1-4.4 could be summarized to say that some intermediate devices >> perform functions based on inspecting transport layer headers, and these fail >> when fragments are presented that don't contain the transport layer >> information. This could be further subdivided into stateful and stateless >> mechanisms. Policy routing, firewalls, NAT are just examples of functions >> that >> break with fragmentation. > > This is insightful! > > The draft can be summarized as follows: > > - IP fragmentation is a stateful procedure in an otherwise stateless protocol. > - When the end-to-end principle was in force, fragmentation worked well. The > stateful process was relegated to the endpoints and everything just worked. > - As years went by, vendors built stateless middle boxes. Being stateless, > they offer good performance at an attractive price. However, being stateless, > they are oblivious to fragmentation and behave badly in the presence of > fragments. I don't follow. Isn't the problem with _stateful_ devices, or at least intermediate devices that choose to parse transport layer. > - These stateless middle boxes are very widely deployed. Because they are > economically attractive, even more of them are likely to be deployed in the > future. A stateless middlebox that doesn't parse transport layer should work perfectly well with fragmentation. This would describe a device adhering to end to end model. > > So, the spirit of the robustness principle, all parties should be > conservative in what they do and liberal in what they accept. > > - Application developers should avoid reliance on IP Fragmentation. (Don't > trip on the bad behavior or middle boxes if you can avoid it). IMO, this argument might make sense if the problem was only fragmentation since there are inherent problems of fragmentation. But there are a whole bunch of things with similar characteristics like IPv6 extension headers or non-TCP protocols. We need a path where those can be prductively used on the Internet. > - Middle box developers should produce devices that don't behave badly in the > presence of fragmentation. This may mean that middle boxes should become more > stateful to support fragmentation. > >> >> For section 4.5 I'm not sure that being insecure makes fragmentation >> unreliable. Similarly 4.6 isn't really a problem with fragmentation but a >> process to avoid fragmentation. Maybe section 4 should be "Problems related >> to the use of IP fragmentation". > > This may be a semantic argument. We agree that security issues exist. We > agree that many operators filter fragments because of these security issues. > > The only thing that we are ar
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018 at 12:28 PM, Joe Touch wrote: > > > > > On 2018-10-15 12:13, Tom Herbert wrote: > > On Mon, Oct 15, 2018 at 12:06 PM, Templin (US), Fred L > wrote: > > Hi Tom, > > ... > From what I saw when I was working with iperf3. By default, it uses 8KB > UDP datagram sizes when it runs on Ubuntu. By setting the UDP datagram > size to a smaller value (i.e., one that needs less IP fragmentation) it > shows > a performance decrease. By setting the UDP datagram size to a larger value > (i.e., one that needs more IP fragmentation) it shows a performance > increase. > > Yes, this because it's better to wake application once than mutiple > times for smaller packets. > > > Smaller packets have lower throughput because of many other per-packet > overheads which include the header length overhead relative to the payload > and setup costs for DMA and IP checksum, etc. > UDP is eight bytes overhead, IP fragmentation header is eight bytes. So fragmenting one UDP packet versus sending the equivalent packets as UDP datagrams have similar wire overhead (I belive the net difference is eight extra bytes for fragmentation). Stack procesing of UDP versus a fragment also should not particularly different. Both require a table lookup, but it's also true that much more effort will go into optimizing UDP than fragmentation because of much higher usage. > The issue of waking the app matters less if using polling, which is more > typical than relying on interrupts for high-speed networking. There's still overhead, for instance each UDP message needs to be separately read, but then we also have recvmmsg that could address that. It's unlikely iperf uses that. I don't believe that host processing of the two scenarios should be particularly different if all the best API is used. I still intend on testing this soon. Tom > > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018 at 12:50 PM, Ron Bonica wrote: > Hi Tom, > > > > This is reminiscent of loss amplification in IP-over-ATM. In IP-over-AM, if > you lose one cell, you have to retransmit every cell belonging to the > packet. In reality, you have to retransmit every cell belonging to the TCP > window. > > > > This was a real problem in ATM, because many, many packets were broken into > multiple ATM cells. So, the likelihood of dropping a cell that belonged to a > large packet was very high. > > > > It isn’t so much a problem in IP, because very few packets are fragmented. > So, the odds of dropping a fragment are pretty slim. Right, but my claim is that very few IP packets are fragmented because of this problem. Even if all the middleboxes in the world were instantly fixed, the loss amplification problem of fragmentation is still present and still a reason to avoid fragmentation. This problem is inherent to IP fragmentation. Tom > > > > If you feel strongly about this, we can craft a new section. What do you > think? > > > > > Ron > > > > From: Tom Herbert > Sent: Monday, October 15, 2018 11:33 AM > To: Ron Bonica > Cc: int-area > > > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt > > > > > > On Mon, Oct 15, 2018, 8:14 AM Ron Bonica wrote: > > Hi Fred, > > Thanks for reviewing yet another version of the draft. But I would like to > push back ever-so-gently on your proposed edit. > > We agree that the draft does not and should not propose the deprecation of > IP Fragmentation. We also agree that IP tunnels require fragmentation. And > because one critical application requires fragmentation, we cannot deprecate > it. > > Yes, there may be other applications that require fragmentation. IPERF may > be one of them. But we don't need to mention it because we have already made > our case against deprecation. Mentioning every application that requires > fragmentation is over-kill. > > > > Iperf is just a test application so it shouldn't be mentioned here anyway. > It does illustrate another problem of fragmentation. That is if just one > fragment of a packet is lost then the whole packet is lost. So with a 1% > drop rate, a packet with two fragments has a drop rate of 2%, 10 fragments > has drop rate of 10% 64K packet makes 43 fragments of 1500 bytes so drop > rate of those packets is 35%. > > > > I believe this amplified drop rate is a problem inherent of fragmentation > and good reason why not to use fragmentation over the Internet. This > probably should be mentioned in the draft. > > > > Tom > > > > > Ron > > >> Message: 2 >> Date: Wed, 10 Oct 2018 16:22:47 + >> From: "Templin (US), Fred L" >> To: "int-area@ietf.org" >> Subject: Re: [Int-area] I-D Action: >> draft-ietf-intarea-frag-fragile-01.txt >> Message-ID: >> <554d668a29934ecf9fdf95d77d1cca52@XCH15-06- >> 08.nw.nos.boeing.com> >> Content-Type: text/plain; charset="us-ascii" >> >> I made this comment earlier, but it does not appear to have made it into >> this >> version. >> Some applications invoke IP fragmentation as a performance optimization, >> and that should be mentioned here. But, it also needs to say that RFC4963 >> warns against reassembly errors at high data rates. >> >> Suggestion is to add the following to the introduction: >> >>"While this document identifies issues associated with IP >>fragmentation, it does not recommend deprecation. Some applications >>(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. Others >> (e.g., >>[IPERF3]) invoke IP fragmentation as a performance optimization, but >>can incur reassembly errors at high data rates [RFC4963]." >> >> Thanks - Fred >> fred.l.temp...@boeing.com >> > * > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018 at 1:35 PM, Ron Bonica wrote: > Hi Tom, > > The examples in Sections 4.1-4.4 all refer to stateless devices. The problem > could be solved by making them all stateful. However, that may not be > practical because of: > Ron, I think you're referring to statefull in this context as meaning reassembly in the network. That could be done, but really doesn't solve the problem because now the problems of being stateful are raised (like every fragment MUST be forwarded through some intermediate device). I'm not sure that the distinction between stateful and stateless in any of these cases is so relevant (state here being more generic to include transport layer state). For instance, IP fragmentation will break stateful firewalls and stateful NAT, which are very common, just as easily as the stateless variants. In any case I don't think that's really relevant, the common problem across all of these is that some intermediate devices want to inspect transport layer headers in packets and non-first fragments don't carry transport headers. Tom > - price/performance concerns > - size of the installed base. > > Years back, Tom Taylor and others speculated on why operators drop fragmented > packets. This work was never complete. > > Ron > > >> -Original Message- >> From: Tom Herbert >> Sent: Monday, October 15, 2018 3:31 PM >> To: Ron Bonica >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt >> >> On Mon, Oct 15, 2018 at 12:11 PM, Ron Bonica >> wrote: >> > Hi Tom, >> > >> > Hope you are feeling better. Comments inline. >> > >> > Ron >> > >> > >> >> Message: 1 >> >> Date: Wed, 10 Oct 2018 13:55:16 -0700 >> >> From: Tom Herbert >> >> To: int-area >> >> Subject: Re: [Int-area] I-D Action: >> >> draft-ietf-intarea-frag-fragile-01.txt >> >> Message-ID: >> >> > >> il.gmail.com> >> >> Content-Type: text/plain; charset="UTF-8" >> >> >> >> Thanks for the updated draft. Here are a few comments: >> >> >> >> "While this document identifies issues associated with IP >> >> fragmentation, it does not recommend deprecation. Some applications >> >> (e.g., [I-D.ietf-intarea- >> >> tunnels]) require IP fragmentation." >> >> >> >> I would add that use of fragmentation is also expected to work and be >> >> common in limited domains where issues in security and >> >> interoperability in intermediate nodes can be addressed, >> > >> > Fair enough. Does the following edit work for you >> > >> > OLD> >> >While this document identifies issues associated with IP >> >fragmentation, it does not recommend deprecation. Some applications >> >(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. >> > > > >> > NEW> >> >While this document identifies issues associated with IP >> >fragmentation, it does not recommend deprecation. Some applications >> >(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. >> > Furthermore, >> >fragmentation is expected to work in limited domains where security and >> interoperability >> >issues can be addressed. >> > > >> It's good. >> >> > >> > >> >> >> >> >From the draft: "This section explains how IP fragmentation reduces >> >> the reliability of Internet communication." In reality, for most of >> >> the examples in this section it's really implementations (NAT, >> >> firewall, etc.) that are breaking IP fragmentation (and other things as >> >> well). >> >> >> >> Sections 4.1-4.4 could be summarized to say that some intermediate >> >> devices perform functions based on inspecting transport layer >> >> headers, and these fail when fragments are presented that don't >> >> contain the transport layer information. This could be further >> >> subdivided into stateful and stateless mechanisms. Policy routing, >> >> firewalls, NAT are just examples of functions that break with >> fragmentation. >> > >> > This is insightful! >> > >> > The draft can be summarized as follows: >> > >> > - IP fragmentation is a stateful procedure in an otherw
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018, 3:11 PM Fred Baker wrote: > > > > On Oct 15, 2018, at 1:50 PM, Ron Bonica wrote: > > > > Exactly, but I didn't want to introduce and define the term "Virtual > Fragment Reassembly". So, I just described the output. The middle box: > > > > - makes a decision on that first fragment > > The one at offset 0 (and therefore containing the transport header), or > the first one it receives (which might be at the final offset or any > other)? What if they're not the same? > For instance, a while back Linux always sent the first fragment last when fragmenting. This wreaked havoc on middle boxes trying to reassemble. That was changed to send first fragment first. But even so, I think there might be some ECMP implementations that could route first fragment (off=0) differently to create ooo packets relative to fragment train. Tom > > - applies that decision to the first fragment and all subsequent > fragments > > > > Ron > > > > > >> -Original Message- > >> From: Templin (US), Fred L > >> Sent: Monday, October 15, 2018 4:46 PM > >> To: Ron Bonica ; Fred Baker > >> > >> Cc: int-area@ietf.org > >> Subject: RE: [Int-area] I-D Action: > draft-ietf-intarea-frag-fragile-01.txt > >> > >> Hi Ron, > >> > >> There is a technique known as "Virtual Fragmentation Reassembly" where > the > >> middlebox gathers all fragments of a datagram, performs any necessary > >> checks and then releases the fragments without reassembling them so > that the > >> destination host still has to reassemble. Is this one of the techniques > you are > >> referring to? > >> > >> Thanks - Fred > >> > >>> -Original Message- > >>> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Ron > >>> Bonica > >>> Sent: Monday, October 15, 2018 1:39 PM > >>> To: Fred Baker > >>> Cc: int-area@ietf.org > >>> Subject: Re: [Int-area] I-D Action: > >>> draft-ietf-intarea-frag-fragile-01.txt > >>> > >>> Hi Fred, > >>> > >>> The first iteration of Section 7.3 actually included the word > "reassemble". > >> That is one possible implementation. > >>> > >>> I dropped the word when I realized that there may be other ways to get > >>> the desired behavior. While they don't all require reassembly, that > all require > >> the maintenance of a little more state. > >>> > >>> > >>> Ron > >>> > >>> > -Original Message- > From: Fred Baker > Sent: Monday, October 15, 2018 3:50 PM > To: Ron Bonica > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: > draft-ietf-intarea-frag-fragile-01.txt > > > > > On Oct 15, 2018, at 12:11 PM, Ron Bonica > >> wrote: > > > > So, the spirit of the robustness principle, all parties should be > > conservative in > what they do and liberal in what they accept. > > > > - Application developers should avoid reliance on IP > > Fragmentation. (Don't > trip on the bad behavior or middle boxes if you can avoid it). > > - Middle box developers should produce devices that don't behave > > badly in > the presence of fragmentation. This may mean that middle boxes > should become more stateful to support fragmentation. > > I might add one thought to 7.3: recommend that middle boxen > reassemble a datagram before operating on it. The attacks that > happen with fragmentation result in issues with reassembly, and the > obvious solution is to detect the situation and drop the datagram in > >> question. > > I would also comment that the first fragment created (the one at > offset zero) might not be the first fragment received. The second > bullet in 7.3, the one about selecting a next-hop, assumes that the > first fragment is also the first one received. However, if the > datagram were reassembled before operating on it, that wouldn't be an > >> issue. > >>> > >>> ___ > >>> Int-area mailing list > >>> Int-area@ietf.org > >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > >>> man_listinfo_int-2Darea&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > >> ndb3voD > >>> TXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- > >> AWF2EfpHcAwrDThKP8&m=9LgfnIl19MFJu > >>> > >> utKdbF3K8gh03dGa8ysrFnSrEVkXoE&s=mLM6w6j83V7i_S2wdo_SdtsOfd6Td > >> b_XiWnb_ > >>> HigsBQ&e= > > > > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
On Mon, Oct 15, 2018, 5:48 PM Brian E Carpenter wrote: > On 2018-10-16 11:26, Tom Herbert wrote: > > > > > > On Mon, Oct 15, 2018, 3:11 PM Fred Baker <mailto:fredbaker.i...@gmail.com>> wrote: > > > > > > > > > On Oct 15, 2018, at 1:50 PM, Ron Bonica <mailto:rbon...@juniper.net>> wrote: > > > > > > Exactly, but I didn't want to introduce and define the term > "Virtual Fragment Reassembly". So, I just described the output. The middle > box: > > > > > > - makes a decision on that first fragment > > > > The one at offset 0 (and therefore containing the transport header), > or the first one it receives (which might be at the final offset or any > other)? What if they're not the same? > > > > > > For instance, a while back Linux always sent the first fragment last > when fragmenting. This wreaked havoc on middle boxes trying to reassemble. > That was changed to send first fragment first. But even so, I think there > might be some ECMP implementations that could route first fragment (off=0) > differently to create ooo packets relative to fragment train. > > Clearly, at some stage we had the hope that the flow label would be useful > to mitigate this sort of problem. It's intentionally included in every IPv6 > fragment. > Brian, Agreed, flow label fixes ECMP problem in fragmentation. The problems with flow label depoyment in ECMP have been more about whether it's consistent for every packet in connection (to satisfy ad hoc requirements that stateful devices see every packet for a connection). That is something that has been addressed more recently. Tom >Brian > > > > > Tom > > > > > > > - applies that decision to the first fragment and all subsequent > fragments > > > > > > Ron > > > > > > > > >> -Original Message- > > >> From: Templin (US), Fred L fred.l.temp...@boeing.com>> > > >> Sent: Monday, October 15, 2018 4:46 PM > > >> To: Ron Bonica mailto:rbon...@juniper.net>>; > Fred Baker > > >> mailto:fredbaker.i...@gmail.com>> > > >> Cc: int-area@ietf.org <mailto:int-area@ietf.org> > > >> Subject: RE: [Int-area] I-D Action: > draft-ietf-intarea-frag-fragile-01.txt > > >> > > >> Hi Ron, > > >> > > >> There is a technique known as "Virtual Fragmentation Reassembly" > where the > > >> middlebox gathers all fragments of a datagram, performs any > necessary > > >> checks and then releases the fragments without reassembling them > so that the > > >> destination host still has to reassemble. Is this one of the > techniques you are > > >> referring to? > > >> > > >> Thanks - Fred > > >> > > >>> -Original Message- > > >>> From: Int-area [mailto:int-area-boun...@ietf.org int-area-boun...@ietf..org>] On Behalf Of Ron > > >>> Bonica > > >>> Sent: Monday, October 15, 2018 1:39 PM > > >>> To: Fred Baker fredbaker.i...@gmail.com>> > > >>> Cc: int-area@ietf.org <mailto:int-area@ietf.org> > > >>> Subject: Re: [Int-area] I-D Action: > > >>> draft-ietf-intarea-frag-fragile-01.txt > > >>> > > >>> Hi Fred, > > >>> > > >>> The first iteration of Section 7.3 actually included the word > "reassemble". > > >> That is one possible implementation. > > >>> > > >>> I dropped the word when I realized that there may be other ways > to get > > >>> the desired behavior. While they don't all require reassembly, > that all require > > >> the maintenance of a little more state. > > >>> > > >>> > > >>> Ron > > >>> > > >>> > > >>>> -Original Message- > > >>>> From: Fred Baker fredbaker.i...@gmail.com>> > > >>>> Sent: Monday, October 15, 2018 3:50 PM > > >>>> To: Ron Bonica mailto:rbon...@juniper.net > >> > > >>>> Cc: int-area@ietf.org <mailto:int-area@ietf.org> > > >>>> Subject: Re: [Int-area] I-D Action: > >
[Int-area] Stateless devices and IP fragmentation
Hi Ron, In the int-area meeting you mentioned that the proposed solution to stateless middleboxes and fragmentation is to performing some reassembly at the device thereby making it "a little" stateful. I doubt this is a feasible solution. This would force devices that were previously work conserving to be non-work conserving which entails significant complexity. They will need memory to hold fragments, timers, and additional logic. I would expect that the appeal of stateless devices is that they can be low end and low cost, and I believe it's going to be a hard sell to vendors to do this. This also brings in the problems of stateful devices. Reassembly in the network must assume that all fragments hit the same middlebox device, there is no guarantee for that. Additionally, this introduces the possibility of DOS attacks on reassembly at the middlebox. Since the middlebox is likely a front end to many hosts, a DOS attack would potentially block the service for all the hosts. Tom ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Wed, Nov 7, 2018 at 8:28 AM, Joe Touch wrote: > The current “solution” of ignoring this need isn’t tenable either, though. It > isn’t “work conserving” to simply drop traffic that is deemed too expensive > to handle. > The device can choose to drop the first fragment, but allow non-first fragments to pass. This retains the work conserving nature of the stateless device, and provides the required functionality of the firewall since the packet cannot be reassembled at the destination. > It’s always appealing - and profitable - for vendors to shortchange customers. I don't believe customers will have much interest in paying premium for a device just because it deals with fragmentation. Tom > > Joe > >> On Nov 7, 2018, at 8:07 AM, Tom Herbert wrote: >> >> Hi Ron, >> >> In the int-area meeting you mentioned that the proposed solution to >> stateless middleboxes and fragmentation is to performing some >> reassembly at the device thereby making it "a little" stateful. I >> doubt this is a feasible solution. This would force devices that were >> previously work conserving to be non-work conserving which entails >> significant complexity. They will need memory to hold fragments, >> timers, and additional logic. I would expect that the appeal of >> stateless devices is that they can be low end and low cost, and I >> believe it's going to be a hard sell to vendors to do this. >> >> This also brings in the problems of stateful devices. Reassembly in >> the network must assume that all fragments hit the same middlebox >> device, there is no guarantee for that. Additionally, this introduces >> the possibility of DOS attacks on reassembly at the middlebox. Since >> the middlebox is likely a front end to many hosts, a DOS attack would >> potentially block the service for all the hosts. >> >> Tom >> >> ___ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Wed, Nov 7, 2018 at 9:24 AM, Joe Touch wrote: > It conserves no work to pass fragments that will be dropped later. > > Customers want devices that work. This is a tragedy of the commons issue. > Nobody wants other people’s devices to drop their fragments. But nobody wants > to pay to not drop fragments of others. But reassembly in the network doesn't work. As I said, it requires that all fragments go through the intermediate device performing reassembly, there is no requirement in IP that that has to be true. This is a known problem of stateful devices, they implicitly place strict requirements on routing in the network in order to "work". Stateless devices do not have this problem. > > We need compliance checks to fix this, or to find another way to put more > pain where the problem lies. I would like to hear from the vendors of the stateless devices whether they think this is feasible solution. Tom > > Joe > >> On Nov 7, 2018, at 8:45 AM, Tom Herbert wrote: >> >>> On Wed, Nov 7, 2018 at 8:28 AM, Joe Touch wrote: >>> The current “solution” of ignoring this need isn’t tenable either, though. >>> It isn’t “work conserving” to simply drop traffic that is deemed too >>> expensive to handle. >>> >> >> The device can choose to drop the first fragment, but allow non-first >> fragments to pass. This retains the work conserving nature of the >> stateless device, and provides the required functionality of the >> firewall since the packet cannot be reassembled at the destination. >> >>> It’s always appealing - and profitable - for vendors to shortchange >>> customers. >> >> I don't believe customers will have much interest in paying premium >> for a device just because it deals with fragmentation. >> >> Tom >> >>> >>> Joe >>> >>>> On Nov 7, 2018, at 8:07 AM, Tom Herbert wrote: >>>> >>>> Hi Ron, >>>> >>>> In the int-area meeting you mentioned that the proposed solution to >>>> stateless middleboxes and fragmentation is to performing some >>>> reassembly at the device thereby making it "a little" stateful. I >>>> doubt this is a feasible solution. This would force devices that were >>>> previously work conserving to be non-work conserving which entails >>>> significant complexity. They will need memory to hold fragments, >>>> timers, and additional logic. I would expect that the appeal of >>>> stateless devices is that they can be low end and low cost, and I >>>> believe it's going to be a hard sell to vendors to do this. >>>> >>>> This also brings in the problems of stateful devices. Reassembly in >>>> the network must assume that all fragments hit the same middlebox >>>> device, there is no guarantee for that. Additionally, this introduces >>>> the possibility of DOS attacks on reassembly at the middlebox. Since >>>> the middlebox is likely a front end to many hosts, a DOS attack would >>>> potentially block the service for all the hosts. >>>> >>>> Tom >>>> >>>> ___ >>>> Int-area mailing list >>>> Int-area@ietf.org >>>> https://www.ietf.org/mailman/listinfo/int-area >>> > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Wed, Nov 7, 2018 at 10:32 AM, Joe Touch wrote: > Sorry - previous response got cut off. Let's try again... > > > > > On 2018-11-07 10:08, Tom Herbert wrote: > > On Wed, Nov 7, 2018 at 9:24 AM, Joe Touch wrote: > > It conserves no work to pass fragments that will be dropped later. > > Customers want devices that work. This is a tragedy of the commons issue. > Nobody wants other people's devices to drop their fragments. But nobody > wants to pay to not drop fragments of others. > > > But reassembly in the network doesn't work. > > > First, I'm talking about virtual reassembly, i.e., keeping state to let > fragments follow their leader. That assumes that the first fragment is received first. IP does not guarantee that. If a non-first fragment is received before a first fragment then it needs to be queued pending the arrival of the first fragment. Once the first fragment is received then the decision can be made whether to forward the queued fragments. This is a non work conserving algorithm and creates a new memory requirement on otherwise stateless devices to hold queued packets. Tom > > > As I said, it requires > that all fragments go through the intermediate device performing > reassembly, there is no requirement in IP that that has to be true. > > > Agreed, but that's a problem for exactly because devices like this forward > and/or modify packets based on information beyond the IP header, which are > incorrectly deployed if they don't know all fragments will be seen. > > > > This is a known problem of stateful devices, they implicitly place > strict requirements on routing in the network in order to "work". > > > > It's a known problem due to layer violation. Just because you WANT to do > something doesn't mean it works. > > The bigger problem is the tragedy of the commons - these devices create a > mess that affects others. In the case of not seeing all the fragments, the > issue is coming back to bite them - i.e., it's devices LIKE THEM that make > problems for devices LIKE THEM. > > > > Stateless devices do not have this problem. > > > > It's not just stateless; it's layer-following. > > > > > > We need compliance checks to fix this, or to find another way to put more > pain where the problem lies. > > > I would like to hear from the vendors of the stateless devices whether > they think this is feasible solution. > > > > They will answer as to what is economically in their individual interest. > That's how we got IPv6 NATs, etc. > > Joe > > > > > > > Tom > > > Joe > > On Nov 7, 2018, at 8:45 AM, Tom Herbert wrote: > > On Wed, Nov 7, 2018 at 8:28 AM, Joe Touch wrote: > The current "solution" of ignoring this need isn't tenable either, though. > It isn't "work conserving" to simply drop traffic that is deemed too > expensive to handle. > > > The device can choose to drop the first fragment, but allow non-first > fragments to pass. This retains the work conserving nature of the > stateless device, and provides the required functionality of the > firewall since the packet cannot be reassembled at the destination. > > It's always appealing - and profitable - for vendors to shortchange > customers. > > > I don't believe customers will have much interest in paying premium > for a device just because it deals with fragmentation. > > Tom > > > Joe > > On Nov 7, 2018, at 8:07 AM, Tom Herbert wrote: > > Hi Ron, > > In the int-area meeting you mentioned that the proposed solution to > stateless middleboxes and fragmentation is to performing some > reassembly at the device thereby making it "a little" stateful. I > doubt this is a feasible solution. This would force devices that were > previously work conserving to be non-work conserving which entails > significant complexity. They will need memory to hold fragments, > timers, and additional logic. I would expect that the appeal of > stateless devices is that they can be low end and low cost, and I > believe it's going to be a hard sell to vendors to do this. > > This also brings in the problems of stateful devices. Reassembly in > the network must assume that all fragments hit the same middlebox > device, there is no guarantee for that. Additionally, this introduces > the possibility of DOS attacks on reassembly at the middlebox. Since > the middlebox is likely a front end to many hosts, a DOS attack would > potentially block the service for all the hosts. > > Tom > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Thu, Nov 8, 2018 at 8:15 AM, Joe Touch wrote: > Dropping those non initial fragments isn’t work conserving either. > > The point is that work conservation needs to consider the impact of the > forwarded or dropped messages, not merely whether info is passed on an > outgoing wire. > > And to be clear, the only party that puts the onus of keeping state on this > device is THIS DEVICE. > > It always can forward based on IP info alone. It is only the desire to alter > packets in transit or forward based on transport info that gets in the way. Exactly my point. For fragmented packets a stateless devices can simply forward non-first fragments and inspect first fragments. This is stateless and the allows the device to provide the functionality that requires DPI. Sure, this means the destination may try to reassemble a packet when the first fragment is dropped, but that's not much of an issue. Unlike intermediate devices, hosts are built to properly reassemble packets and to deal with reassembly failures and other edge conditions. If you're worried about this being used for DOS, then I claim it's about as easy to DOS virtual reassembly by sending a bunch of non-first fragments towards the device doing virtual reassembly. Alternatively, one could send fragmented packets that are likely to be accepted by the stateless firewall (like DNS maybe) where the last fragment is withheld; in this case the DOS attack is "two for one" since both the destination and the intermediate device maintain state for reassmbly that is the target of the attack. Tom > > You make the mess, you clean it up, IMO. > > Joe > >> On Nov 8, 2018, at 8:09 AM, Tom Herbert wrote: >> >>> On Wed, Nov 7, 2018 at 10:32 AM, Joe Touch wrote: >>> Sorry - previous response got cut off. Let's try again... >>> >>> >>> >>> >>> On 2018-11-07 10:08, Tom Herbert wrote: >>> >>> On Wed, Nov 7, 2018 at 9:24 AM, Joe Touch wrote: >>> >>> It conserves no work to pass fragments that will be dropped later. >>> >>> Customers want devices that work. This is a tragedy of the commons issue. >>> Nobody wants other people's devices to drop their fragments. But nobody >>> wants to pay to not drop fragments of others. >>> >>> >>> But reassembly in the network doesn't work. >>> >>> >>> First, I'm talking about virtual reassembly, i.e., keeping state to let >>> fragments follow their leader. >> >> That assumes that the first fragment is received first. IP does not >> guarantee that. If a non-first fragment is received before a first >> fragment then it needs to be queued pending the arrival of the first >> fragment. Once the first fragment is received then the decision can be >> made whether to forward the queued fragments. This is a non work >> conserving algorithm and creates a new memory requirement on otherwise >> stateless devices to hold queued packets. >> >> Tom >> >>> >>> >>> As I said, it requires >>> that all fragments go through the intermediate device performing >>> reassembly, there is no requirement in IP that that has to be true. >>> >>> >>> Agreed, but that's a problem for exactly because devices like this forward >>> and/or modify packets based on information beyond the IP header, which are >>> incorrectly deployed if they don't know all fragments will be seen. >>> >>> >>> >>> This is a known problem of stateful devices, they implicitly place >>> strict requirements on routing in the network in order to "work". >>> >>> >>> >>> It's a known problem due to layer violation. Just because you WANT to do >>> something doesn't mean it works. >>> >>> The bigger problem is the tragedy of the commons - these devices create a >>> mess that affects others. In the case of not seeing all the fragments, the >>> issue is coming back to bite them - i.e., it's devices LIKE THEM that make >>> problems for devices LIKE THEM. >>> >>> >>> >>> Stateless devices do not have this problem. >>> >>> >>> >>> It's not just stateless; it's layer-following. >>> >>> >>> >>> >>> >>> We need compliance checks to fix this, or to find another way to put more >>> pain where the problem lies. >>> >>> >>> I would like to hear from the vendors of the stateless devices whether >>> they think t
Re: [Int-area] Stateless devices and IP fragmentation
On Thu, Nov 8, 2018 at 9:07 AM, Joe Touch wrote: > Boxes that do DPI ***are*** edge devices, regardless of where they > are(mid)placed. > I don't know what "edge devices" are in the context of IP protocols. I do know these devices are NOT hosts-- the destination address of packets is not their address. They cannot do the equivalent work of hosts since they don't have all required information. I've already pointed out the reassembly in the network doesn't work because there's no guarantee that an intermediate node will see all the packets. > That’s why they should be required to do the equivalent work. They can't do the equivalent work of hosts for the reasons above. I don't see how we can require something that is impossible to do correctly. Tom > > Just because they ‘don’t want to’ doesn’t make it so. > > Joe > >> On Nov 8, 2018, at 8:48 AM, Tom Herbert wrote: >> >> Unlike intermediate devices, hosts are built to >> properly reassemble packets and to deal with reassembly failures and >> other edge conditions > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Mon, Nov 12, 2018 at 10:35 AM, Ron Bonica wrote: > Folks, > > It warms my heart to see old friends share a spirited debate ;-) > > But what does this mean for draft-ietf-intarea-frag-fragile? The draft > observes that some stateless middle boxes behave poorly in the presence of IP > fragments. In order to avoid this situation, the draft makes the following > recommendations: > > 1) Application developers SHOULD NOT develop new applications that rely on IP > fragmentation. > 2) Application-layer protocols that depend upon IPv6 fragmentation SHOULD be > updated to break that dependency. > 3) Middle box developers SHOULD implement devices that support IP > fragmentation. These boxes SHOULD not fail or cause failures when processing > fragmented IP packets. > Ron, I'm not sure what "SHOULD implement devices that support IP fragmentation" means. By specification, intermediate devices are supposed to ignore fragments and hence implicitly support them. But, I think the implication of this discussion is that there are middleboxes that do process fragments somehow leading to detrimental or at least non-compliant behavior. If the intent is to address those implementations, they will need guidance on how to fix things. IMO, it wouldn't be correct or feasible to recommend they do virtual reassembly. Tom > Note the generous application of the word "SHOULD". These are > recommendations, not iron-fisted dictates. If developers heed these > recommendations, they will avoid some amount of pain. However, it is > understood that these recommendations will not be heeded by all. Hence the > word "SHOULD". > > > Ron >> -Original Message- >> From: Ole Troan >> Sent: Monday, November 12, 2018 5:23 AM >> To: Joe Touch >> Cc: Tom Herbert ; Ron Bonica >> ; int-area >> Subject: Re: [Int-area] Stateless devices and IP fragmentation >> >> >> >> > On 12 Nov 2018, at 11:11, Joe Touch wrote: >> > >> > >> > >> > On Nov 12, 2018, at 1:36 AM, Ole Troan wrote: >> > >> >>> And none of these update RFC1812. >> >>> >> >>> These things can be rolled out in any numbers you like - they are >> >>> creating >> the problem that only they can clean up. Killing capability in the rest of >> the >> Internet to make these mechanisms work isn’t a viable solution and never has >> been. >> >> >> >> And if that makes the IPv4 Internet die quicker, I’ll take that as a >> >> feature. >> > >> > Sure, as long as your goal is to kill IPv6 too. >> > >> > Joe >> >> And that’s probably as good an end to this thread as any… >> >> Ole ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Mon, Nov 12, 2018 at 1:08 PM, Ron Bonica wrote: > Joe, Tom, > > Does the following text work for you? > > Ron > > === > > > 7.1. For Protocol Developers > >Protocol developers SHOULD NOT develop new protocols that rely >on IP fragmentation. However, they MAY develop new protocols that >rely on IP fragmentation when no viable alternative exists. > >Legacy protocols that depend upon IPv6 fragmentation SHOULD be updated >to break that dependency. However, in some cases, there may be no viable >alternative to IPv6 fragmentation (e.g., IPSec tunnel mode, IP-in-IP > encapsulation). >In these cases, the protocol MAY continue to rely on IPv6 fragmentation. > >A protocol can break its dependency upon IP fragmentation by >using a sufficiently small MTU (e.g. the protocol minimum link MTU), >disabling IP fragmentation, and ensuring that the transport protocol in >use adapts its segment size to the MTU. Another approach is to deploy >a sufficiently reliable PMTU discovery mechanism (e.g., PLMPTUD). > > 7.3. For Middle Box Developers > >Middle box developers SHOULD implement devices that do not fail or cause >failures when processing fragmented IP packets. > >For example, in order to support IP fragmentation, a load balancer >might execute the following procedure: > >o Receive a fragmented packet > >o Identify a next-hop using information drawn from the first > fragment (i.e., the fragment containing offset 0) > >o Forward the first fragment and all subsequent fragments through > the above-mentioned next-hop Ron, I think that algorithm describes virtual reassmbly. Based on the first packet a virtual state for the fragment train is created and used to route the non-first fragments. Problems with this are: 1) the device is no longer stateless 2) it assumes the first fragement is received first 3) it requires that all fragments are forwarded through the same intermediate node. If the goal is to implement a stateless device, then all packets including fragments need to be processed independently. For a stateless firewall, just inspecting and potentially dropping the first fragment should yield the correct behavior. For an L4 load balancer, it is a hard problem to get consistent stateless forwarding between fragments and non-fragments. I believe that is best solved by routing based on flow label instead of ports. The flow label is available in all packets and doesn't require DPI, it should be the suggested solution for IPv6 at least. Tom > >In some cases, given price and performance constraints, it may be > impossible to design a middle box that processes IP fragments correctly. In > these cases, the vendor MUST document the issue and propose work-arounds. > >> -Original Message- >> From: Joe Touch >> Sent: Monday, November 12, 2018 2:02 PM >> To: Ron Bonica >> Cc: Ole Troan ; Tom Herbert >> ; int-area >> Subject: Re: [Int-area] Stateless devices and IP fragmentation >> >> Ron >> >> As I noted, SHOULDs always need to explain why they are not MUSTs and >> under what conditions they should be excepted... see below... >> >> Joe >> >> > On Nov 12, 2018, at 10:35 AM, Ron Bonica wrote: >> > >> > Folks, >> > >> > It warms my heart to see old friends share a spirited debate ;-) >> > >> > But what does this mean for draft-ietf-intarea-frag-fragile? The draft >> observes that some stateless middle boxes behave poorly in the presence of IP >> fragments. In order to avoid this situation, the draft makes the following >> recommendations: >> > >> > 1) Application developers SHOULD NOT develop new applications that rely >> on IP fragmentation. >> >> I’d call this protocol developers, not just application developers (to cover >> tunnel and security designs too), I.e., anything that goes as payload in >> IP... >> >> They CAN rely on IP *source* fragmentation when needing to support direct >> IP-in-IP tunnels, as for existing protocols such as IPsec tunnel mode and >> IP-in- >> IP encapsulation. >> >> > 2) Application-layer protocols that depend upon IPv6 fragmentation >> SHOULD be updated to break that dependency. >> >> Same issue... >> >> > 3) Middle box developers SHOULD implement devices that support IP >> fragmentation. >> >> Here’s the problem - under what cases is an exception warranted? >> >> AFAICT, Middlebox developers SHOULD support processing of IP
Re: [Int-area] Stateless devices and IP fragmentation
On Mon, Nov 12, 2018 at 3:56 PM, Ron Bonica wrote: > Tom, > > OK. Let's see if the following text works any better for you. > > Ron > > 7.1. For Protocol Developers > >Protocol developers SHOULD NOT develop new protocols that rely >on IP fragmentation. However, they MAY develop new protocols that >rely on IP fragmentation when no viable alternative exists. > >Legacy protocols that depend upon IPv6 fragmentation SHOULD be updated >to break that dependency. However, in some cases, there may be no viable >alternative to IPv6 fragmentation (e.g., IPSec tunnel mode, IP-in-IP > encapsulation). >In these cases, the protocol MAY continue to rely on IPv6 fragmentation. > >A protocol can break its dependency upon IP fragmentation by >using a sufficiently small MTU (e.g. the protocol minimum link MTU), >disabling IP fragmentation, and ensuring that the transport protocol in >use adapts its segment size to the MTU. Another approach is to deploy >a sufficiently reliable PMTU discovery mechanism (e.g., PLMPTUD). > Hi Ron. > 7.3. For Middle Box Developers > > Middle box developers SHOULD implement devices that process IP fragments in > a predictable manner. > For example, a stateless load balancer might exhibit one of the following > behaviors: > Seems like you're offering middle box developers a choice amonst different behaviors. May this "consistent" as opposed to "pedictable" behavior. > - Balance load based on L3 information only > Probably want to be more specific here, presumably this means hash over pair of addresses. Load balance over 3-tuple of IP address and flow label should have its own recommendation. This is effectively operating on L4 information. > - Balance load based upon both L3 and L4 information, but discard all IP > fragments > Which pretty much makes fragmentation useless, so it's not a great recommendation. There's another problem here in that L4 information might not be available in other types of packets. When we say L4, what that probably means is just plain TCP or UDP packets. > - For non-fragmented packets, balance load upon both L3 and L4 information. > For fragmented packets, balance load based upon L3 information only. > Therefore, packets belonging to a single flow can be assigned to two > different interfaces. (See Section 4.4 for details). It depends on what the backend of the load balancer is doing. If it is an L4 load balancer to VIPs, then fragments and non-fragments for a flow have to go to the same node. > > - Balance load based upon both L3 and L4 information, but maintain enough > state so that all packets and packet fragments belonging to a flow are > assigned to the same interface. Sure, but then the device can no longer be called stateless. AFAICT using the flow label in the hash is the only way that a stateless L4 load balancer could get a consistent hash between fragments and non-fragments. Tom > > Undesirable outcomes can be attributed to each of the above mentioned > behaviors. Therefore, middle box vendors MUST document the behaviors that > their devices exhibit. > > > > >> -Original Message- >> From: Tom Herbert >> Sent: Monday, November 12, 2018 4:25 PM >> To: Ron Bonica >> Cc: Joe Touch ; Ole Troan >> ; int-area >> Subject: Re: [Int-area] Stateless devices and IP fragmentation >> >> On Mon, Nov 12, 2018 at 1:08 PM, Ron Bonica wrote: >> > Joe, Tom, >> > >> > Does the following text work for you? >> > >> > Ron >> > >> > === >> > >> > >> > 7.1. For Protocol Developers >> > >> >Protocol developers SHOULD NOT develop new protocols that rely >> >on IP fragmentation. However, they MAY develop new protocols that >> >rely on IP fragmentation when no viable alternative exists. >> > >> >Legacy protocols that depend upon IPv6 fragmentation SHOULD be >> updated >> >to break that dependency. However, in some cases, there may be no >> viable >> >alternative to IPv6 fragmentation (e.g., IPSec tunnel mode, IP-in-IP >> encapsulation). >> >In these cases, the protocol MAY continue to rely on IPv6 fragmentation. >> > >> >A protocol can break its dependency upon IP fragmentation by >> >using a sufficiently small MTU (e.g. the protocol minimum link MTU), >> >disabling IP fragmentation, and ensuring that the transport protocol in >> >
Re: [Int-area] Stateless devices and IP fragmentation
On Wed, Nov 14, 2018 at 11:33 AM, Ole Troan wrote: > Joe, > Again, this does nothing for middleboxes that can handle IPv6 fragments. Flow labels don’t fix DPI or NAT devices. >>> >>> It wasn’t meant to. If you read my post, I clearly stated the IPv4 Internet. >>> >>> There is much less justification to “encourage deprecation” of IPv6 >>> fragments. >>> I think that if so has to be a much more archirectural view of the >>> layering, and that network layer fragments problematic for the end host, >>> because it can’t do any validation checks on them before reassembly. >> >> Overlap checks can be done. >> >> What other kind of check do you think would be meaningful or helpful on >> fragments alone? > > Exactly, and that’s the problem with fragmentation at the network layer. The > end host must do reassembly before deciding to throw the packet or not. > >>> From an IETF perspective middleboxes do not exist in IPv6 (sic). >> >> And *I’m* the one in denial?? > > ;-) > >>> And if we really want to punt fragmentation to the transport layer, I think >>> the argument should not be made using middleboxes for justification. >> >> You might consider that middleboxes are not IP-only devices; they depend on >> and modify transport layer headers and even content sometimes. >> >>> >>> Do you see why I insist on making a distinction between IPv4 and IPv6? >> >> Except for the flow ID for IPv6 - which helps only when used properly AND >> for load distribution - no. > > For IPv4 part of the transport headers are now part of the network layer. > Forwarding is done one address and port. Ole, I don't believe this can be true. Not all protocols even have port numbers (e.g. ICMP, ESP) and yet we still expect them to be deliverable. Maybe your referring to ECMP, which does route based on flow (e.g. port information)? But, ECMP is not required to make IP work either. Forwarding solely based on destination IPv4 address for unicast packets needs to work. > I.e it’s now part of ‘normal’ routing/forwarding. That’s absolutely not the > case. In IPv6 packets are delivered to hosts based on longest match on > destination addresses, while for IPv4 it’s a match IPv4 DA and DP. ECMP is also done for IPv6. I don't see how routing is fundamentally different in IPv6 except that the flow label could be a good substitute for ports in ECMP. Tom > > So no, we can’t treat the protocols the same. > > Cheers, > Ole ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica wrote: > Folks, > > Since we seem to have reached consensus on Section 7.1, let's take another > stab at Section 7.3. I am looking particularly to Tom Herbert and Joe Touch > for feedback, since they objected to the previous formulation. > > Proposed text follows > >Ron > > 7.3. For Middle Box Developers > > Middle boxes SHOULD process IP fragments in a manner that is compliant with > RFC 791 and RFC 8200. In many cases, middle boxes must maintain state in > order to achieve this goal. > > Price and performance considerations frequently motivate network operators to > deploy stateless middle boxes. These stateless middle boxes may perform > sub-optimally or process IP fragments in a manner that is not compliant with > RFC 791 or RFC 8200. Providers of such middle boxes MUST document product's > their behavior. Hi Ron, Maybe s/may/sometimes/ to avoid any hint that we're advocating non-compliant behavior. > > For example, a network operator may be motivated to deploy a stateless load > balancer. Because the load balancer is stateless, it is likely to exhibit on > of the following behaviors: > > - For all packets, implement a load balancing algorithm whose inputs are > drawn from the IP header. This algorithm facilitates RFC compliant behavior. > However, it may distribute load unevenly. I don't think I would phrase it this way. It might be more along the lines that if load balancer takes into account transport layer information then it usually performs better. Also, in the case of IPv6 the flowlabel is part of IP header and could be used to achieve similar load balancing characteristics as the case that the transport ports are considered. So this statement might only be applicable to IPv4. > > - For fragmented packets, implement a load balancing algorithm whose inputs > are drawn from the IP header. For non-fragmented packets, implement a load > balancing algorithm whose inputs are drawn from the IP header and the Layer 4 > header. This algorithm facilitates RFC compliant behavior. It also improves > load distribution for flows that do not included fragmented packets. However, > if a flow contains fragmented packets, packets belonging to that flow can be > distributed between two different outgoing interfaces. Again, this would only be relevant in IPv4, for IPv6 flow label solves the problem. For IPv4, I think this algorithm is about a best as could be done. It might be worth mentioning that all fragments of a packet, including the first that does contain L4 info, need to be forwarded the in the same manner. > > - For all packets, implement a load balancing algorithm whose inputs are > drawn from the IP header and the Layer 4 header. Discard all IP fragments. > This algorithm does not facilitate RFC compliant behavior and can cause black > holes. > If it's non-compliant, why include it as a valid alternative? > All of the above-mentioned behaviors are sub-optimal. However, one behavior > may be acceptable to one network operator while another behavior is > acceptable to another network operator. Middle box vendors MUST provide > network operators with all of the information required to make intelligent > middle box deployment decisions. > > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Wed, Nov 14, 2018 at 12:50 PM, Ron Bonica wrote: > Tom, > > Please look inline for a little compromise and a little pushback. I hope that > we can reach consensus in this round. > > Ron > > >> -Original Message- >> From: Tom Herbert >> Sent: Wednesday, November 14, 2018 3:02 PM >> To: Ron Bonica >> Cc: int-area ; Joe Touch >> Subject: Re: [Int-area] Stateless devices and IP fragmentation >> >> On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica >> wrote: >> > Folks, >> > >> > Since we seem to have reached consensus on Section 7.1, let's take another >> stab at Section 7.3. I am looking particularly to Tom Herbert and Joe Touch >> for >> feedback, since they objected to the previous formulation. >> > >> > Proposed text follows >> > >> >Ron >> > >> > 7.3. For Middle Box Developers >> > >> > Middle boxes SHOULD process IP fragments in a manner that is compliant >> with RFC 791 and RFC 8200. In many cases, middle boxes must maintain state >> in order to achieve this goal. >> > >> > Price and performance considerations frequently motivate network >> operators to deploy stateless middle boxes. These stateless middle boxes may >> perform sub-optimally or process IP fragments in a manner that is not >> compliant with RFC 791 or RFC 8200. Providers of such middle boxes MUST >> document product's their behavior. >> >> Hi Ron, >> >> Maybe s/may/sometimes/ to avoid any hint that we're advocating non- >> compliant behavior. >> > > Fair enough, change accepted. > >> > >> > For example, a network operator may be motivated to deploy a stateless >> load balancer. Because the load balancer is stateless, it is likely to >> exhibit on of >> the following behaviors: >> > >> > - For all packets, implement a load balancing algorithm whose inputs are >> drawn from the IP header. This algorithm facilitates RFC compliant behavior. >> However, it may distribute load unevenly. >> >> I don't think I would phrase it this way. It might be more along the lines >> that if >> load balancer takes into account transport layer information then it usually >> performs better. Also, in the case of IPv6 the flowlabel is part of IP >> header and >> could be used to achieve similar load balancing characteristics as the case >> that >> the transport ports are considered. So this statement might only be >> applicable >> to IPv4. > > > How does the following text strike you.. > > - For all packets, implement a load balancing algorithm whose inputs are > drawn from the IP header. This algorithm facilitates RFC compliant behavior. > However, this algorithm may not distribute load as evenly as another > algorithm whose inputs are drawn from the IP and transport layer headers. > > I am going to push back on the flow label part because a) it is not available > in IPv4 and b) In IPv6, we have no guarantee that it will be set. So, I > weasel around the issue by saying that the algorithm *may* not distribute > load as evenly. I never say that it *will* not distribute load as evenly. I believe flow label is now being set by all major OSes. Even if it's not set, the algorithm just falls back to hashing over IP addresses. Flow label was a good addition to IPv6 exactly for the purposes of things like load balancing and it solves the problem in this case. It's use should be encouraged here. > > >> > >> > - For fragmented packets, implement a load balancing algorithm whose >> inputs are drawn from the IP header. For non-fragmented packets, implement >> a load balancing algorithm whose inputs are drawn from the IP header and >> the Layer 4 header. This algorithm facilitates RFC compliant behavior. It >> also >> improves load distribution for flows that do not included fragmented packets. >> However, if a flow contains fragmented packets, packets belonging to that >> flow can be distributed between two different outgoing interfaces. >> >> Again, this would only be relevant in IPv4, for IPv6 flow label solves the >> problem. For IPv4, I think this algorithm is about a best as could be done. >> It >> might be worth mentioning that all fragments of a packet, including the first >> that does contain L4 info, need to be forwarded the in the same manner. >> > > > I would like to push back on the flow label arguments for the same reasons as > stat
Re: [Int-area] Stateless devices and IP fragmentation
On Wed, Nov 14, 2018 at 1:25 PM, Brian E Carpenter
wrote:
> On 2018-11-15 10:02, Tom Herbert wrote:
>> On Wed, Nov 14, 2018 at 12:50 PM, Ron Bonica wrote:
>>> Tom,
>>>
>>> Please look inline for a little compromise and a little pushback. I hope
>>> that we can reach consensus in this round.
>>>
>>> Ron
>>>
>>>
>>>> -Original Message-
>>>> From: Tom Herbert
>>>> Sent: Wednesday, November 14, 2018 3:02 PM
>>>> To: Ron Bonica
>>>> Cc: int-area ; Joe Touch
>>>> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>>>>
>>>> On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica
>>>> wrote:
>>>>> Folks,
>>>>>
>>>>> Since we seem to have reached consensus on Section 7.1, let's take another
>>>> stab at Section 7.3. I am looking particularly to Tom Herbert and Joe
>>>> Touch for
>>>> feedback, since they objected to the previous formulation.
>>>>>
>>>>> Proposed text follows
>>>>>
>>>>>Ron
>>>>>
>>>>> 7.3. For Middle Box Developers
>>>>>
>>>>> Middle boxes SHOULD process IP fragments in a manner that is compliant
>>>> with RFC 791 and RFC 8200. In many cases, middle boxes must maintain state
>>>> in order to achieve this goal.
>>>>>
>>>>> Price and performance considerations frequently motivate network
>>>> operators to deploy stateless middle boxes. These stateless middle boxes
>>>> may
>>>> perform sub-optimally or process IP fragments in a manner that is not
>>>> compliant with RFC 791 or RFC 8200. Providers of such middle boxes MUST
>>>> document product's their behavior.
>>>>
>>>> Hi Ron,
>>>>
>>>> Maybe s/may/sometimes/ to avoid any hint that we're advocating non-
>>>> compliant behavior.
>>>>
>>>
>>> Fair enough, change accepted.
>>>
>>>>>
>>>>> For example, a network operator may be motivated to deploy a stateless
>>>> load balancer. Because the load balancer is stateless, it is likely to
>>>> exhibit on of
>>>> the following behaviors:
>>>>>
>>>>> - For all packets, implement a load balancing algorithm whose inputs are
>>>> drawn from the IP header. This algorithm facilitates RFC compliant
>>>> behavior.
>>>> However, it may distribute load unevenly.
>>>>
>>>> I don't think I would phrase it this way. It might be more along the lines
>>>> that if
>>>> load balancer takes into account transport layer information then it
>>>> usually
>>>> performs better. Also, in the case of IPv6 the flowlabel is part of IP
>>>> header and
>>>> could be used to achieve similar load balancing characteristics as the
>>>> case that
>>>> the transport ports are considered. So this statement might only be
>>>> applicable
>>>> to IPv4.
>>>
>>>
>>> How does the following text strike you..
>>>
>>> - For all packets, implement a load balancing algorithm whose inputs are
>>> drawn from the IP header. This algorithm facilitates RFC compliant
>>> behavior. However, this algorithm may not distribute load as evenly as
>>> another algorithm whose inputs are drawn from the IP and transport layer
>>> headers.
>>>
>>> I am going to push back on the flow label part because a) it is not
>>> available in IPv4 and b) In IPv6, we have no guarantee that it will be set.
>>> So, I weasel around the issue by saying that the algorithm *may* not
>>> distribute load as evenly. I never say that it *will* not distribute load
>>> as evenly.
>>
>> I believe flow label is now being set by all major OSes. Even if it's
>> not set, the algorithm just falls back to hashing over IP addresses.
>> Flow label was a good addition to IPv6 exactly for the purposes of
>> things like load balancing and it solves the problem in this case.
>> It's use should be encouraged here.
>
> To be clear, if you do ECMP or LAG based entirely on the 3-tuple
> {dest_addr, source_addr, flow_label} then fragments will all follow
> exactly the same path as unfragmented packets. So, perfecti
Re: [Int-area] Stateless devices and IP fragmentation
On Wed, Nov 14, 2018 at 2:21 PM, Brian E Carpenter wrote: > On 2018-11-15 10:54, Tom Herbert wrote: >> On Wed, Nov 14, 2018 at 1:25 PM, Brian E Carpenter >> wrote: >>> On 2018-11-15 10:02, Tom Herbert wrote: >>>> On Wed, Nov 14, 2018 at 12:50 PM, Ron Bonica wrote: >>>>> Tom, >>>>> >>>>> Please look inline for a little compromise and a little pushback. I hope >>>>> that we can reach consensus in this round. >>>>> >>>>> Ron >>>>> >>>>> >>>>>> -Original Message- >>>>>> From: Tom Herbert >>>>>> Sent: Wednesday, November 14, 2018 3:02 PM >>>>>> To: Ron Bonica >>>>>> Cc: int-area ; Joe Touch >>>>>> Subject: Re: [Int-area] Stateless devices and IP fragmentation >>>>>> >>>>>> On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica >>>>>> wrote: >>>>>>> Folks, >>>>>>> >>>>>>> Since we seem to have reached consensus on Section 7.1, let's take >>>>>>> another >>>>>> stab at Section 7.3. I am looking particularly to Tom Herbert and Joe >>>>>> Touch for >>>>>> feedback, since they objected to the previous formulation. >>>>>>> >>>>>>> Proposed text follows >>>>>>> >>>>>>>Ron >>>>>>> >>>>>>> 7.3. For Middle Box Developers >>>>>>> >>>>>>> Middle boxes SHOULD process IP fragments in a manner that is compliant >>>>>> with RFC 791 and RFC 8200. In many cases, middle boxes must maintain >>>>>> state >>>>>> in order to achieve this goal. >>>>>>> >>>>>>> Price and performance considerations frequently motivate network >>>>>> operators to deploy stateless middle boxes. These stateless middle boxes >>>>>> may >>>>>> perform sub-optimally or process IP fragments in a manner that is not >>>>>> compliant with RFC 791 or RFC 8200. Providers of such middle boxes MUST >>>>>> document product's their behavior. >>>>>> >>>>>> Hi Ron, >>>>>> >>>>>> Maybe s/may/sometimes/ to avoid any hint that we're advocating non- >>>>>> compliant behavior. >>>>>> >>>>> >>>>> Fair enough, change accepted. >>>>> >>>>>>> >>>>>>> For example, a network operator may be motivated to deploy a stateless >>>>>> load balancer. Because the load balancer is stateless, it is likely to >>>>>> exhibit on of >>>>>> the following behaviors: >>>>>>> >>>>>>> - For all packets, implement a load balancing algorithm whose inputs are >>>>>> drawn from the IP header. This algorithm facilitates RFC compliant >>>>>> behavior. >>>>>> However, it may distribute load unevenly. >>>>>> >>>>>> I don't think I would phrase it this way. It might be more along the >>>>>> lines that if >>>>>> load balancer takes into account transport layer information then it >>>>>> usually >>>>>> performs better. Also, in the case of IPv6 the flowlabel is part of IP >>>>>> header and >>>>>> could be used to achieve similar load balancing characteristics as the >>>>>> case that >>>>>> the transport ports are considered. So this statement might only be >>>>>> applicable >>>>>> to IPv4. >>>>> >>>>> >>>>> How does the following text strike you.. >>>>> >>>>> - For all packets, implement a load balancing algorithm whose inputs are >>>>> drawn from the IP header. This algorithm facilitates RFC compliant >>>>> behavior. However, this algorithm may not distribute load as evenly as >>>>> another algorithm whose inputs are drawn from the IP and transport layer >>>>> headers. >>>>> >>>>> I am going to push back on the flow label part because a) it is not >>>&g
Re: [Int-area] About limited domains (2)
On Mon, Nov 12, 2018 at 4:22 PM Brian E Carpenter wrote: > > Quoting the minutes on draft-carpenter-limited-domains-04: > > > RV: The hints that I'm hearing are that if you have well structured systems > > there are infinite ways to break the structure. If one allows people in the > > wild to > > do whatever they want, you get trends like this. It's not a trend you want > > to support. > > Our point is not about people doing things in the wild; it's about people > doing things inside a particular domain (a.k.a. environment). We (the IETF) > can't stop that, but we can in theory standardise technology to define the > domain and make it secure. Hi Brian, I don't think it's a question of trying to stop people from doing whatever they want, I think it's more of a question of whether IETF should be encouraging such behavior. >From the draft: "Nevertheless, because of the diversity of limited environments with specific requirements that is now emerging, specific standards will necessarily emerge." I don't think the necessity that specific standards need to be defined for limited domains has been established. For discussion, can you give a specific example of a required protocol that would only work in a limited domain, but would be incorrect if used in the Internet? Tom > > Brian > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Fri, Nov 16, 2018 at 7:02 AM Ron Bonica wrote: > > Hi Brian, > > Fair enough. Does the following text work? > >Ron > > 7.3. For Middle Box Developers > > Middle boxes SHOULD process IP fragments in a manner that is compliant with > RFC 791 and RFC 8200. In many cases, middle boxes must maintain state in > order to achieve this goal. > Ron, Devices that maintain protocol state in the network aren't protocol compliant either. > Price and performance considerations frequently motivate network operators to > deploy stateless middle boxes. These stateless middle boxes may perform > sub-optimally, process IP fragments in a manner that is not compliant with > RFC 791 or RFC 8200, or even discard IP fragments completely. Providers of > such middle boxes MUST document product's their behavior. This is too permissive for middle boxes to implement whatever ad hoc behavior they want. I would say it like: "Price and performance considerations frequently motivate network operators to deploy stateless middle boxes. Some deployed stateless middle boxes process IP fragments in a manner that is not compliant with RFC 791 or RFC 8200, or even discard IP fragments completely. Such behaviors are NOT RECOMMENDED. If a middleboxes implements non-standard behavior with respect to IP fragmentation, then that behavior MUST be clearly documented." > > The behaviors exhibited by the above-mentioned devices are not desirable. > However, one behavior may be acceptable to one network operator while another > behavior is acceptable to another network operator. Middle box vendors MUST > provide network operators with all of the information required to make > intelligent middle box deployment decisions. I don't think this paragraph is needed with the suggested text above. Tom > > > -Original Message- > > From: Brian E Carpenter > > Sent: Thursday, November 15, 2018 10:44 PM > > To: Ron Bonica ; Tom Herbert > > ; Joe Touch > > Cc: int-area > > Subject: Re: [Int-area] Stateless devices and IP fragmentation > > > > > These stateless middle boxes may perform sub-optimally or process IP > > > fragments in a manner that is not compliant with RFC 791 or RFC 8200. > > > > That seems to skirt round the real concern. Middleboxes don't exist in the > > world assumed by RFC 791 or 8200, so those RFCs don't place any compliance > > requirements on middleboxes. It's simply implicit that datagrams get > > delivered > > whether fragmented or not. RFC 1812 doesn't seem to mention that routers > > MUST forward fragments, presumably because it's blindingly obvious. Same > > for draft-ietf-6man-rfc6434-bis and draft-v6ops-ipv6rtr-reqs. > > > > So at least can we say: > > > > These stateless middle boxes may perform sub-optimally, process IP fragments > > in a manner that is not compliant with RFC 791 or RFC 8200, or even discard > > IP fragments completely. > > > > Regards > >Brian > > > > On 2018-11-16 10:35, Ron Bonica wrote: > > > Tom, Joe, Brian, > > > > > > I haven't seen a response to this message. Can I assume that you are OK > > > with > > this text? > > > > > > Ron > > > > > > > > >> -Original Message- > > >> From: Ron Bonica > > >> Sent: Wednesday, November 14, 2018 4:35 PM > > >> To: Tom Herbert > > >> Cc: int-area ; Joe Touch > > >> Subject: RE: [Int-area] Stateless devices and IP fragmentation > > >> > > >> Folks, > > >> > > >> We thrashing over the example. Can everybody agree to the following > > text? > > >> > > >>Ron > > >> > > >> 7.3. For Middle Box Developers > > >> > > >> Middle boxes SHOULD process IP fragments in a manner that is > > >> compliant with RFC 791 and RFC 8200. In many cases, middle boxes must > > >> maintain state in order to achieve this goal. > > >> > > >> Price and performance considerations frequently motivate network > > >> operators to deploy stateless middle boxes. These stateless middle > > >> boxes may perform sub-optimally or process IP fragments in a manner > > >> that is not compliant with RFC 791 or RFC 8200. Providers of such > > >> middle boxes MUST document product's their behavior. > > >> > > >> The behaviors exhibited by the above-mentioned devices are not desirable. > > >> However, one behavior may be acceptable to one network operator while > > >> another behavior is acceptable to another network operator. Middle > > >> box vendors MUST provide network operators with all of the > > >> information required to make intelligent middle box deployment > > >> decisions. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Stateless devices and IP fragmentation
On Sat, Nov 17, 2018 at 9:09 AM Joe Touch wrote: > > > > > On Nov 17, 2018, at 9:00 AM, Tom Herbert wrote: > > > > On Fri, Nov 16, 2018 at 7:02 AM Ron Bonica wrote: > >> > >> Hi Brian, > >> > >> Fair enough. Does the following text work? > >> > >> Ron > >> > >> 7.3. For Middle Box Developers > >> > >> Middle boxes SHOULD process IP fragments in a manner that is compliant > >> with RFC 791 and RFC 8200. In many cases, middle boxes must maintain state > >> in order to achieve this goal. > >> > > Ron, > > > > Devices that maintain protocol state in the network aren't protocol > > compliant either. > > They’re called endpoints — exactly because that’s what they have to be acting > like. > If the destination address of a packet is a local address of the device then they are not endpoints. They are intermediate nodes. Stateful intermediate nodes do attempt to emulate some of the functions of an endpoint, but that requires non-standard assumptions and cannot be protocol conformant with host requirements. > > > >> Price and performance considerations frequently motivate network operators > >> to deploy stateless middle boxes. These stateless middle boxes may > >> perform sub-optimally, process IP fragments in a manner that is not > >> compliant with RFC 791 or RFC 8200, or even discard IP fragments > >> completely. Providers of such middle boxes MUST document product's their > >> behavior. > > > > This is too permissive for middle boxes to implement whatever ad hoc > > behavior they want. I would say it like: > > > > "Price and performance considerations frequently motivate network > > operators to deploy stateless middle boxes. Some deployed stateless > > middle boxes process IP fragments in a manner that is not compliant > > with RFC 791 or RFC 8200, or even discard IP fragments completely. > > Such behaviors are NOT RECOMMENDED. If a middleboxes implements > > non-standard behavior with respect to IP fragmentation, then that > > behavior MUST be clearly documented.” > > That sounds OK to me - at least in the spirit of consensus. > > > > >> > >> The behaviors exhibited by the above-mentioned devices are not desirable. > >> However, one behavior may be acceptable to one network operator while > >> another behavior is acceptable to another network operator. Middle box > >> vendors MUST provide network operators with all of the information > >> required to make intelligent middle box deployment decisions. > > > > I don't think this paragraph is needed with the suggested text above. > > Agreed, FWIW. > > Joe > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] draft-ietf-intarea-frag-fragile-03
On Wed, Nov 21, 2018, 8:47 AM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Hi Ron, > > There needs to be a new subsection in Section 6 on UDP applications that > rely on IP fragmentation for greater performance. Here is proposed text: > > "Some UDP applications rely on IP fragmentation to achieve acceptable > levels > of performance. These applications use UDP datagram sizes that are larger > than > the path MTU so that more data can be conveyed between the application and > the kernel in a single system call. > > Historically, NFS version 2 [RFC1094] set a UDP datagram size of 8KB which > is > greater than the path MTU of most paths, resulting in IP fragmentation. > Currently, the Licklider Transmission Protocol [RFC5326] which is in > current > use on the International Space Station (ISS) uses UDP datagram sizes larger > than the path MTU to achieve acceptable levels of performance even though > this too invokes IP fragmentation. Also, the commonly-used iperf3 [IPERF3] > performance testing utility by default sets an 8KB UDP datagram size even > though IP fragmentation is invoked since the performance of smaller UDP > datagrams is much lower. > Hi Fred, I agree that NFS and ISS protocol are worth mentioning, but iperf shouldn't be mentioned since it is just a test program. > While it is natural to suggest that such applications should adjust their > application layer framing to better match the path MTU, such does > not always result in greater performance. For example, although the > "sendmmsg()" system call was designed to present the kernel with > multiple UDP datagrams in a single call, not all applications benefit > from its use." > The hardest part is pmtu discovery, signaling discovered pmtu to the UDP application, and then the application needs to know how to make smaller packets to fit into mtu. The last step is especially problematic since it's application specific logic. The natural recourse applications have is to just assume minimal MTU, but as you point out that can be poor performance compared to using fragmentation Tom > > Thanks - Fred > > > -Original Message- > > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Ron > Bonica > > Sent: Wednesday, November 21, 2018 6:32 AM > > To: int-area ; intarea-cha...@ietf.org > > Subject: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > Chairs, > > > > I have posted a new version of draft-ietf-intarea-frag-fragile, working > in comments from Tom and Brian. > > > > If you see fit, please initiate a working group last call. > > > >Ron > > > > ___ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-04.txt
Thanks for the update. I think section 7.3 strikes a pretty balance between middleboxes implementation and requirements. A couple of other comments: >From the draft: "7.1. For Application Developers Protocol developers SHOULD NOT develop new protocols that rely on IP fragmentation." This seems to be a recommendation for application developers, so maybe this should read "Application protocol developers ...". Or is this the recommendation intended to be broader than that to include transport protocol developers for instance? I believe use of the IPv6 flow label for stateless load balancing, and other instances where packets need to be matched to flow, should be RECOMMENDED. We have been using three tuple (addrs + flow label) for Receive Packet Steering on the host for quite a while now, and I believe there are switches that support this for ECMP also. The flow label is a generic mechanism that works not only with fragmentation, but any case where an intermediate node is unable or doesn't want to to parse the transport layer header to get ports from the transport layer. All major OSes should be setting flow label properly at this point. Tom On Tue, Nov 27, 2018 at 10:26 AM wrote: > > > 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 : IP Fragmentation Considered Fragile > Authors : Ron Bonica > Fred Baker > Geoff Huston > Robert M. Hinden > Ole Troan > Fernando Gont > Filename: draft-ietf-intarea-frag-fragile-04.txt > Pages : 25 > Date: 2018-11-27 > > Abstract: >This document describes IP fragmentation and explains how it reduces >the reliability of Internet communication. > >This document also proposes alternatives to IP fragmentation and >provides recommendations for developers and network operators. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-04 > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-frag-fragile-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-frag-fragile-04 > > > 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 mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Responses to feedback on GUE presentation from IETF #103
Please see my response below maked TH. Thanks, Tom --- ** TH's video link dropped shortly into the presentation and wasn't completed or able to respond to the comments ** CF: As TSVWG chair I didn't get why it was being proposed. TSVWG is in the title and this is what TSVWG does. Please talk to us about it. TH: That is in reference to draft-herbert-tsvwg-gte-00. My intent on presenting it was to inform about this potential work, not to propose it in int-area. SK: I think we did is say this was a 1 off document. Now there's 4. If it becomes a protocol suite, it doesn't below here. If TSVWG wants to take it TH: From the beginning there were actually two documents. The main GUE draft and GUE extensions. A major tenant of GUE is that it is extensible. But, aside from the initial set of extensions (and initial control messages) I would not foresee that things will be added a high rate; my estimate is maybe one extension every few years. The control messages draft is under development and not ready to be WG item yet. CF: I wanted to comment on it! Whether we need another encap protocol. We need a BOF etc. TH: I believe that draft-herbert-tsvwg-gte might ultimately be part of a more general efforts of how to use tunnels with transport layer semantics. There was a side meeting on this as LOOPS (localized optimization of path segment), and hopefully we can get a mailing list for discussion on the topic. SK: If there's a significant amount of work, we need a BOF. this is not the right place for it We can talk off line. TH: I don't believe GUE is a significant amount of work. AFAIK, there is no pending work to be done on GUE drafts (the two in WGLC). As I mentioned we have a Document Shepherd for one draft (draft-ietf-intarea-gue), but are still hoping to get one assigned to the other (draft-ietf-intarea-gue-extensions). ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] draft-ietf-intarea-frag-fragile-03
On Thu, Nov 29, 2018 at 10:27 AM Ron Bonica wrote: > > Fred, > > > > Without being too abrupt, there were then , and are now, much better ways to > solve this problem. > > > > A better approach would have been to fragment / reassemble at a higher layer. > That is the whole point of this document. Ron, I'm not sure I agree that it's always better to fragment/reassemble at a higher layer. The salient point about NFSv2 is that it's UDP and 8K blocks are more efficient to send. There are still similar use cases of UDP applications in datacenters, and there's no uniform way to deal with frag+reassmbly at the application layer. Just the other day I was talking to someone that works in a very large datacenter environment, and he mentioned that were in the process of changing MTUs to be a little above 4K (sending pages in a single packet is very low overhead and this make zero copy trivial). A problem of a large sprawling DC is that there are no flag days where everything is transitioned to new configurations, so it's very possible that some portion of the DC is not updated to support the larger MTU. In that case, it's much easier to just rely on PMTU discovery and IP fragmentation, rather than rewriting all the UDP applications to implement fragmentation. Tom > > > > Ron > > > > > > > > From: Templin (US), Fred L > Sent: Thursday, November 29, 2018 1:08 PM > To: Joe Touch ; Stewart Bryant > > Cc: Ron Bonica ; int-area ; > intarea-cha...@ietf.org > Subject: RE: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > Hi, regardless of how old and obsolete NFSv2 is, the text in RFC1094 perfectly > > addresses the point. I was working for Digital Equipment Corporation in the > > late 1980’s when Sun Microsystems first came out with NFS. The two companies > > tried to form an agreement where DEC would provide VAXen as NFS servers for > > Sun clients, but many DEC VAX systems used an Ethernet line card called the > > DELQA that was too slow to keep up with 10Mbps Ethernet line rates (!). > > > > When the VAX received a burst of IP fragments of an 8KB NFS/UDP datagram, > > it would drop one or more fragments and print “qerestart” in the system log. > > The DELQA would then reset itself and the network would be out of service > > until the restart completed. This rendered VAXen with DELQAs useless as an > > NFS server, so DEC had to qualify which of the VAX product line could actually > > support NFS. And, all because of IP fragmentation. > > > > So, I think there is value in keeping the citation. > > > > Thanks - Fred > > > > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Joe Touch > Sent: Thursday, November 29, 2018 8:41 AM > To: Stewart Bryant > Cc: Ron Bonica ; int-area ; > intarea-cha...@ietf.org > Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > I would hope it would be evident from context, but sure. > > > > Joe > > > On Nov 29, 2018, at 8:37 AM, Stewart Bryant wrote: > > > Either way it is useful to give the reviewer a heads up as to nits giving > errors and this being OK. > > S > > On 29/11/2018 14:42, Joe Touch wrote: > > They don’t need to be deleted if you include them deliberately. There is no > prohibition on citing such RFCs for your own documents historical background. > > > > Joe > > > On Nov 29, 2018, at 4:06 AM, Stewart Bryant wrote: > > But, always worth including a "do be deleted" note to the reviewers to stop > then all sending in feedback about the nits failure. > > Stewart > > > > On 27/11/2018 20:42, Joe Touch wrote: > > FWIW: > > > > > > On 2018-11-27 12:22, Ron Bonica wrote: > > Fred, > > If the NFSv2 and iPERF issues are not blocking, I would like to omit them. > The following are rational: > > ... > - Mechanically, it is difficult to reference an RFC that has been obsoleted > in an internet draft. The NIT checker complains bitterly. > > > > Those complaints are warnings only to help those who cite such documents > inadvertently; you can simply ignore them. (I do all the time - esp. for > historical discussions that cite early versions of newer RFCs or historical > standards). > > > > Joe > > > > ___ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] draft-ietf-intarea-frag-fragile-03
On Thu, Nov 29, 2018 at 3:41 PM Christian Huitema wrote: > > On 11/29/2018 1:05 PM, Templin (US), Fred L wrote: > > > iperf3 is a real Internet application in the same way that ping, traceroute, > > tcpdump, etc. are real applications. It is a well-known tool that network > > engineers use on a daily basis and demonstrates that UDP performance > > is highly correlated with UDP datagram size (i.e., even for sizes that > > exceed the PMTU). > > AFAIK the main difference between large and small UDP packets is doing > the fragmentation/reassembly in the application instead of in the > kernel's UDP stack. For an 8K packet, that means 6 socket calls in the > application case, versus 1 in the kernel case. That is indeed some > overhead. It is not a big deal for medium speed application like video, > but i can see how it will get in the way of running QUIC at several > Gbps, for instance. But then, the overhead could be trivially eliminated > with API improvements, such as passing several packets in a single call. sendmmsg and recvmmsg do that. > We can ponder why we have not seen such improvements yet, the main > explanation being lack of demand. I fully expect that this will change > if QUIC gets widely used. In fact, it would be good if the fragmentation > draft discussed this API issue. > > -- Christian Huitema > > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] draft-ietf-intarea-frag-fragile-03
On Fri, Nov 30, 2018 at 7:42 AM Christian Huitema wrote: > > > > > On Nov 30, 2018, at 7:25 AM, Templin (US), Fred L > > wrote: > > > > Right, we have talked about that. A disadvantage is that the application > > framing headers need to be repeated in each UDP datagram, and when > > the application headers are large the amount of room left for actual data > > is diminished. > > Seems like a weak argument. If the application is important and if > performance is an issue, the application should be updated. Rather the application performs fragmentation or it's done at a lower should show little difference in performance; either way there's equivalent work and packet overhead. The real performance advantage comes when the PMTU is large so that no fragmentation is done, that can substantially reduce number of packets sent and received. Fragmentation is needed along with PMTU discovery then because not all PMTUs are guaranteed to be the same even in a closed network. A material difference between application doing fragmentation and doing at IP layer is that the former requires every application to implement support, and the latter generically supports all applications. I think the draft is correct in saying that IP fragmentation should be avoided on the Internet. But in a closed environment like a datacenter where there's no typically no problematic devices like stateful firewalls in the path and there's little chance of attack on the reassmebly queue, IP fragmentation is perfectly useful and in use. However, even in that environment there are improvements that could be made like using flow label to to get consistent forwarding between fragments and non-fragments. Tom > > -- Christian Huitema > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] draft-ietf-intarea-frag-fragile-03
On Fri, Nov 30, 2018 at 9:55 AM Joe Touch wrote: > > > > > On Nov 30, 2018, at 9:46 AM, Ole Troan wrote: > > > > > > > >> On 30 Nov 2018, at 18:33, Joe Touch wrote: > >> > >> > >> > >>> On Nov 30, 2018, at 9:22 AM, Ole Troan wrote: > >>> > >>> > >>> > On 30 Nov 2018, at 16:49, Joe Touch wrote: > > 1) the lower down the fragmentation occurs, the less overhead is needed > (i.e., when performance is an issue, it’s even more important to > fragment as low as possible) > >>> > >>> That sounds like an unfounded myth. > >>> I would think it highly dependent on implementation. > >> > >> Reality: > >> > >> - every layer down you do it avoids a layer of header in-between *at every > >> fragment* > >> ie., IP fragments have only ONE UDP header and ONE application header, but > >> app-fragments have multiples of both. > >> > >> Do the math. > > > > Every ipv6 fragment has an additional 8 byte header. > > For IPv6, yes (not for IPv4). But that only counters the extra UDP header; > there’s still the application fragmentation header too. > > > But the network might not be the bottleneck here, and a few more bytes > > might not matter. As I said it depends. > > When it comes to performance making blanket statements is rarely a good > > idea. > > Such as "When it comes to performance making blanket statements is rarely a > good idea.”, agreed. That is true and it follows that more bytes in headers doesn't necessarily mean worse performance. For instance, it is much more expensive to compute the UDP checksum across IP fragments than if the application fragmented the message it self and each one has its own UDP header (checksum calculation is offloaded to the the NIC in the latter case). Tom > > But it’s nowhere near an unfounded myth. > > Joe > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] draft-ietf-intarea-frag-fragile-03
On Fri, Nov 30, 2018 at 9:57 AM Ron Bonica wrote: > > Guys, > > Does it really matter! Nobody is arguing that applications SHOULD send > packets larger than the MTU in order to improve performance. > > At best, they are arguing that a few outliers (LTP, NFSv2, iPERF) do. > Ron, I think the question is whether these really are outliers (DNS definitely isn't). For instance, while NFSv2 may have been deprecated, there are other block data protocols that still are in use and presumably could benefit from IP fragmentation (ROCEv2 for example). It's pretty obvious that fragmentation isn't currently feasible on the open Internet, but for other environments, like the datacenter, it may not only be relevant but desirable compared to other solutions. While the draft doesn't deprecate IP fragmentation, it does say "Protocol developers SHOULD NOT develop new protocols that rely on IP fragmentation.". That's a pretty negative and general statement against fragmentation. Without more qualification, I'm not sure getting consensus on this recommendation will be easy. Tom > > Ron > > > > -Original Message- > > From: Ole Troan > > Sent: Friday, November 30, 2018 12:46 PM > > To: Joe Touch > > Cc: Christian Huitema ; Ron Bonica > > ; int-area > > Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > > > > > > On 30 Nov 2018, at 18:33, Joe Touch wrote: > > > > > > > > > > > >> On Nov 30, 2018, at 9:22 AM, Ole Troan wrote: > > >> > > >> > > >> > > >>> On 30 Nov 2018, at 16:49, Joe Touch wrote: > > >>> > > >>> 1) the lower down the fragmentation occurs, the less overhead is > > >>> needed (i.e., when performance is an issue, it’s even more important > > >>> to fragment as low as possible) > > >> > > >> That sounds like an unfounded myth. > > >> I would think it highly dependent on implementation. > > > > > > Reality: > > > > > > - every layer down you do it avoids a layer of header in-between *at > > > every fragment* ie., IP fragments have only ONE UDP header and ONE > > application header, but app-fragments have multiples of both. > > > > > > Do the math. > > > > Every ipv6 fragment has an additional 8 byte header. But the network might > > not be the bottleneck here, and a few more bytes might not matter. As I > > said it > > depends. > > When it comes to performance making blanket statements is rarely a good > > idea. > > > > Ole > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] draft-ietf-intarea-frag-fragile-03
On Fri, Nov 30, 2018 at 11:43 AM Ron Bonica wrote: > > Inline.. > > > -Original Message----- > > From: Tom Herbert > > Sent: Friday, November 30, 2018 2:13 PM > > To: Ron Bonica > > Cc: Ole Troan ; Joe Touch > > ; int-area > > Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > On Fri, Nov 30, 2018 at 9:57 AM Ron Bonica wrote: > > > > > > Guys, > > > > > > Does it really matter! Nobody is arguing that applications SHOULD send > > packets larger than the MTU in order to improve performance. > > > > > > At best, they are arguing that a few outliers (LTP, NFSv2, iPERF) do. > > > > > Ron, > > > > I think the question is whether these really are outliers (DNS definitely > > isn't). > > DNS doesn't fragment to improved performance. It fragments to overcome PMTU > issues. > > > For instance, while NFSv2 may have been deprecated, there are other block > > data protocols that still are in use and presumably could benefit from IP > > fragmentation (ROCEv2 for example). > > It's pretty obvious that fragmentation isn't currently feasible on the open > > Internet, but for other environments, like the datacenter, it may not only > > be > > relevant but desirable compared to other solutions. > > So what makes the data center different from the global Internet in this > regard. Are there no middle boxes in the data center? Are the security > vulnerabilities associated with IP fragmentation not in play in the data > center? Ron, Typically, you won't find middleboxes in the datacenter. Datacenter networks are often CLOS fabrics built to be non-blocking and minimize latency between hosts. Middleboxes live at the edge of the datacenter-- firewalls, proxies, frontend servers, NAT, etc. There are probably two primary use cases of bandwidth in the datacenter-- RPC and remote memory/storage access. These have been implemented with TCP, UDP, or other IP protocols including proprietary IP protocols. There have also been attempts to use non-IP protocols like ROCE and FCoE. Fortunately, it seems most of the use cases have converged to use TCP/IP or UDP/IP. Also, at least in the datacenter environments I work in, multicast is not relevant as a application visible protocol. Datacenters are protected from the outside world from firewalls, so security is mostly assumed internally. The model does change somewhat if the datacenter supports third party multi-tenancy as that opens up the possibility of internal attacks, so the traditional model of perimeter security breaks done. In that case there may be middleboxes, either network devices or in hypervisors of servers, that isolate virtual networks from one another. > > > > > > While the draft doesn't deprecate IP fragmentation, it does say "Protocol > > developers SHOULD NOT develop new protocols that rely on IP > > fragmentation.". That's a pretty negative and general statement against > > fragmentation. Without more qualification, I'm not sure getting consensus on > > this recommendation will be easy. > > > > There is a big difference between SHOULD NOT and MUST NOT. If your > application only needs to work in a constrained environment, you can do > whatever you want. But if you want your application to work on the wide, wild > Internet, I would stay away from IP fragmentation. > I agree with that sentiment, but maybe the wording of the recommendation should be scoped correspondingly to only apply to protocols intended for use over the Internet. Tom > > Tom > > > > > > > > > > Ron > > > > > > > > > > -Original Message- > > > > From: Ole Troan > > > > Sent: Friday, November 30, 2018 12:46 PM > > > > To: Joe Touch > > > > Cc: Christian Huitema ; Ron Bonica > > > > ; int-area > > > > Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > > > > > > > > > > > > > > On 30 Nov 2018, at 18:33, Joe Touch wrote: > > > > > > > > > > > > > > > > > > > >> On Nov 30, 2018, at 9:22 AM, Ole Troan > > wrote: > > > > >> > > > > >> > > > > >> > > > > >>> On 30 Nov 2018, at 16:49, Joe Touch > > wrote: > > > > >>> > > > > >>> 1) the lower down the fragmentation occurs, the less overhead is > > > > >>> needed (i.e., when performance is an issue, it’s even more > > > > >>> important to frag
Re: [Int-area] draft-ietf-intarea-frag-fragile-03
On Fri, Nov 30, 2018 at 12:39 PM Fred Baker wrote: > > > > On Nov 30, 2018, at 11:12 AM, Tom Herbert wrote: > > It's pretty obvious that fragmentation isn't currently feasible on the > > open Internet, but for other environments, like the datacenter, it may > > not only be relevant but desirable compared to other solutions. > > > > While the draft doesn't deprecate IP fragmentation, it does say > > "Protocol developers SHOULD NOT develop new protocols that rely on IP > > fragmentation.". That's a pretty negative and general statement > > against fragmentation. Without more qualification, I'm not sure > > getting consensus on this recommendation will be easy. > > Thank you for your constructive comment. It at least gives us a direction to > try to improve the draft in. > > Two thoughts: > > "SHOULD" means, per RFC 2119, that it is a case in which the author would > like to make a blanket statement but recognizes that there may be exceptions > that s/he has not considered, and requires an implementor that doesn't follow > the mandate to state the exception. In this case, a new protocol that uses IP > fragmentation rather than using some higher layer would be expected to say > why - the default interpretation being that s/he was lazy or ignorant and > couldn't be bothered. In the event that a new protocol is developed that > depends on IP fragmentation, would you argue that the developer should not be > asked to think about and respond to the question "why"? > Bear in mind that "application developers" is a very broad category of people that include commercial developers, students, amateurs, etc. Right now, it's pretty easy to write a meaningful UDP application in just a couple of hours. I'm not sure it's reasonable for the college student writing a quick UDP app in their dorm room to have to consider all the pitfalls of fragmentation and whether they need to increase their complexity by an order of magnitude to implement fragmentation in their application. The promise of doing IP fragmentation at the network layer is that the application developer doesn't need to be concerned with such things. > The reason the draft makes a negative statement about > fragmentation/reassembly is that there is a measurable issue with > fragmentation/reassembly. To pick a data point, Geoff Huston has been > measuring a blogging in the past year or two about MTUs observed in DNS root > and resolver servers, and the reduced reliability of DNS as a result of > dependence on IP fragmentation. Fernando Gont has been doing experiments > measuring the impact of IPv6 extension headers in transit, one of which is > the fragmentation header. Another point, although I refer to general > commentary rather than data, is that PLPMTUD is not generally used for some > reason, and PMTUD - and packet fragmentation in general - is frequently > disrupted by filters. That is the reason that, as you state, fragmentation is > not generally useful on packets that will cross the open Internet. The issue > with saying it can only be used in a confined space is that the application > generally doesn't know the location or path that its packets will use. I'm thinking of a certain banking configuration that has been discussed in IETF circles in the past couple of years that has multiple layers of load balancers and firewall-equivalents within a single data center. The application simply doesn't know whether IP fragmentation will be useful in a given environment. If it is forced to make a non-fragmentation solution available as well as a fragmentation-based solution, the questions arise how it distinguishes the cases and why it really needs both. > My fundamental concern is that the wording in the draft generally recommends against the use of a standard protocol feature. Not because the protocol is broken or the feature has been obsoleted, but because some implementations are non-conformant with the protocol standard. I'm worried that this sort of recommendation and the rationale for it will be extrapolated to recommending against use of other standard features like extension headers (which you referred to above), use of any protocols other than TCP or UDP, or even the use of IPv6. Tom > So I'm really looking for alternative text that makes the point but gives > people the wiggle room they need to be comfortable. Happy to discuss by > phone/video if that's useful. > > > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Moving forward with draft-ietf-intarea-frag-fragile
On Sun, Dec 2, 2018 at 11:07 PM Suresh Krishnan wrote: > > Hi Joe/Fred T. /Tom, > You have brought up some good points and I would really like to get this > draft to progress in a timely manner. To help with this, I would greatly > appreciate your help to move this along by sending specific change proposals > pointing to the text in the draft you want changed preferably in the form of > OLD: NEW: text so that it is easy for the authors and the WG to identify what > the change entails. > > Also, with my AD hat off, I think the SHOULD NOT is the right generic > recommendation for future applications, but a few (non-exhaustive) exceptions > could easily be written into the MAY part. E.g. > Hi Suresh, I'm having trouble grasping the fact that this would be calling applications exceptions when they are doing nothing more than implementing against a long established standard. IMO, it is the non-conformant implementations that are motivating this discussion that should be considered the exceptions. As I mentioned, it seems like this "exception model" could easily be applied in several other instances that intermediate nodes don't properly support the standard protocols (EH, non-TCP, IPv6, etc.). I think the answer might be provided by how IPv6 incompatibility is dealt with. If a protocol feature is known to not work or is suspect in an environment, an application can fallback at run-time to a mode that doesn't use the feature. I suggest this text to describe it: "Application developers should be aware that IP fragmentation may not be viable across all paths in the Internet. Applications that might invoke IP fragmentation SHOULD provide a fallback mode that can be enabled at run-time to avoid the use fragmentation over networks paths which include intermediate nodes that do not properly handle fragments. The simplest fallback mechanism is too allow configuration of the maximum application message size to fit into a lower MTU or minimally supported MTUs (576 bytes for IPv4 and 1028 bytes for IPv6). Such configuration could be applied to all communications for the application, or to specific destinations whose paths are known be problematic for fragmentation. An application MAY choose to probe a destination by sending fragmented packets to determine whether the path to the destination properly supports fragmentation and then can adjust its message size based on the feedback. An application developer MAY implement application layer fragmentation. This might require implementing application protocol specific implementation for fragmentation and reassembly, as well as having a sufficiently reliable PMTU discovery mechanism (e.g., PLMPTUD). Because of the complexity and effort required to support application layer fragmentation, this is not a general solution and may be prohibitive or undesirable to some applications." > "However, there may be certain classes of applications that can benefit by > using IP layer fragmentation in order to reduce complexity or to minimize > overhead. (Examples of such applications include Tom>). These applications MAY prefer to use IP fragmentation." > > Does this sound like a reasonable way forward? > One nit: a recommendation that applications SHOULD NOT rely on fragmentation does not seem like a protocol requirement but more like a BCP to me. Tom > Thanks > Suresh > > On Sat, Dec 1, 2018, 7:16 AM Joe Touch wrote: >> >> >> >> > On Nov 30, 2018, at 2:57 PM, Tom Herbert wrote: >> > >> > ...student writing a quick UDP app in their dorm room to have to consider >> > all the pitfalls of fragmentation and whether they need to increase >> > their complexity by an order of magnitude to implement fragmentation >> > in their application. The promise of doing IP fragmentation at the >> > network layer is that the application developer doesn't need to be >> > concerned with such things >> >> Agreed. That and issues with IP frag are why we’re developing UDP frag. >> >> Joe >> ___ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-05.txt
Hi Brian, A few comments on new text in the draft... >From the draft: "Another term that has been used in some contexts is "controlled environment". For example, [RFC8085] uses this to delimit the scope within which a particular tunnel encapsulation might be used." I think this is mis-characterizing things a bit. The rationale for restricting an encapsulation protocol to a controlled environment is only applicable in the case that the traffic being carried isn't subject to congestion control. The controlled environment text is in GRE/UDP because of the rather narrow use case that GRE can carry non-IP, non-congestion controlled traffic like in encapsulated Ethernet (there is an explicit assumption that IP traffic is congestion controlled). This is only an _operational_ requirement. Assuming that the operational requirements for congestion control is met (easy enough to do with rate limiting from a source), there are no protocol restrictions, nor should there be any, on using GRE/UDP or any other encapsulation protocol over the Internet. "The recent discussions about the unreliability of IP fragmentation needed. and the filtering of IPv6 extension headers have clearly shown that at least for some protocol elements, transparency is a lost cause and middleboxes are here to stay." I can't say that I agree with this assessment, at least the part about transparency being a loss cause. It seems to preclude the possibility that non-conformant implementations can be fixed or that we could figure out ways to systematically work around them. This needs discussion, but it's probably outside the scope of limited domains. "In summary, some application environments require protocol features that cannot cross the whole Internet." This seems a little ambiguous to me. It would be good to have a definition what it means that a "protocol feature cannot cross the whole Internet". If taken literally, I believe that TCP is the only transport protocol and IPv4 is the network protocol that might be close to being able to cross the whole Internet. So then one could infer that all other transport and network protocols are relegated to only be used in limited domains. I don't believe that's the intent of the draft! :-) Tom On Wed, Dec 12, 2018 at 11:32 AM Brian E Carpenter wrote: > > An update following recent comments: > > Forwarded Message > Subject: I-D Action: draft-carpenter-limited-domains-05.txt > Date: Wed, 12 Dec 2018 11:26:16 -0800 > From: internet-dra...@ietf.org > Reply-To: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Limited Domains and Internet Protocols > Authors : Brian Carpenter > Bing Liu > Filename: draft-carpenter-limited-domains-05.txt > Pages : 23 > Date: 2018-12-12 > > Abstract: >There is a noticeable trend towards network requirements, behaviours >and semantics that are specific to a limited region of the Internet >and a particular set of requirements. Policies, default parameters, >the options supported, the style of network management and security >requirements may vary. This document reviews examples of such >limited domains, also known as controlled environments, and emerging >solutions, and develops a related taxonomy. It then briefly >discusses the standardization of protocols for limited domains. >Finally, it shows the needs for a precise definition of limited >domain membership and for mechanisms to allow nodes to join a domain >securely and to find other members, including boundary nodes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-carpenter-limited-domains-05 > https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-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/ > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
Hello. I have a couple of comments: >From the draft: "Middle boxes SHOULD process IP fragments in a manner that is compliant with RFC 791 and RFC 8200. In many cases, middle boxes must maintain state in order to achieve this goal." This requirement is confusing to me on several accounts. First of all, there are a lot of requirements about fragmentation in both RFC791 and RFC8200, including some MUSTs. This requirement seems to be updating and possibly relaxing some of those requirements, but is not specific. This seems ambiguous as a normative requirement. Secondly, the only specified interaction between fragmentation and intermediate nodes is that routers can fragment packets in IPv4. Other than that, a middlebox that complies with RFC791 and RFC8200 does not process or consider fragmentation of packets. Given that, it's unclear to me why middle boxes would need to maintain state to be protocol compliant. It's possible that the implicit exception of the requirement is that middleboxes might perform "in-network reassembly" or "virtual reassemlby" which would require state. If that is indeed the case then the requirements for the mechanisms should be spelled out. For stateless load balancing (described in section 4.4), the IPv6 flow label obviates the need for DPI. It is sufficient to hash over the three tuple to get good load balancing. All major OSes have been updated to set flow labels, and there are devices that already support this. IMO, the draft should make using flow label for stateless load balancing a SHOULD. Tom On Mon, Jan 14, 2019 at 11:55 AM Joel M. Halpern wrote: > > I have re-read this document. I think it is a useful document that > captures that state of a complex tradeoff and makes effective > recommendations. I support publishing it as a BCP. > > If the authors make further additions, adding a mention of ECMP as a > particular case of stateless load balancers might further improve the > document. > > Yours, > Joel > > On 1/14/19 1:13 PM, Wassim Haddad wrote: > > Dear all, > > > > This email starts an Int-Area WG Last Call on the latest version of "IP > > Fragmentation Considered Fragile” draft: > > > > https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-05 > > > > Please respond to this email to support the document and/or send comments > > by 2019-01-28. > > > > Please indicate if you are personally aware of any IPR that applies to > > draft-ietf-intarea-frag-fragile-xx? > > If so, has this IPR been disclosed in compliance with IETF IPR rules? > > > > > > Regards, > > > > Juan & Wassim > > ___ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
On Mon, Jan 14, 2019 at 5:30 PM Brian E Carpenter
wrote:
>
> On 2019-01-15 11:04, Tom Herbert wrote:
> > Hello. I have a couple of comments:
> >
> >>From the draft:
> > "Middle boxes SHOULD process IP fragments in a manner that is
> > compliant with RFC 791 and RFC 8200. In many cases, middle boxes must
> > maintain state in order to achieve this goal."
> >
> > This requirement is confusing to me on several accounts.
>
> Me too. I think the root of the problem is the word "compliant". To
> be compliant with the IP model, middleboxes should not exist. I think
> what the text is trying to say is more like:
>
> "Middle boxes SHOULD process IP fragments in a manner that is
> consistent with RFC 791 and RFC 8200."
>
> That's a requirement for effective transparency, not for compliance.
>
> > First of all,
> > there are a lot of requirements about fragmentation in both RFC791 and
> > RFC8200, including some MUSTs. This requirement seems to be updating
> > and possibly relaxing some of those requirements, but is not specific.
> > This seems ambiguous as a normative requirement.
> >
> > Secondly, the only specified interaction between fragmentation and
> > intermediate nodes is that routers can fragment packets in IPv4. Other
> > than that, a middlebox that complies with RFC791 and RFC8200 does not
> > process or consider fragmentation of packets. Given that, it's unclear
> > to me why middle boxes would need to maintain state to be protocol
> > compliant. It's possible that the implicit exception of the
> > requirement is that middleboxes might perform "in-network reassembly"
> > or "virtual reassemlby" which would require state. If that is indeed
> > the case then the requirements for the mechanisms should be spelled
> > out.
> >
> > For stateless load balancing (described in section 4.4), the IPv6 flow
> > label obviates the need for DPI. It is sufficient to hash over the
> > three tuple to get good load balancing. All
> > major OSes have been updated to set flow labels, and there are devices
> > that already support this. IMO, the draft should make using flow label
> > for stateless load balancing a SHOULD.
>
> Agreed, and the text would need to be a bit reorganized for that, by
> separating the v4 and v6 cases completely. Also things are rather
> different for in-transit load balancing (including ECMP and LAG) and
> server load balancing, but I don't think that changes the recommendation.
> The draft could cite RFC7098 for the server case. In RFC7098, we
> assumed that the balancer could revert to the old DPI method if the flow
> label is zero, which may lead to a fail if the packet is fragmented.
> But for in-transit load balancing of large numbers of flows, the
> {source, dest, flow_label} tuple will provide entropy even if the
> flow label is zero.
Right, if flow label is zero the algorithm just falls back to hashing
over the 2-tuple which is already what devices do today when then
can't parse the transport layer ports to get an L4 hash (e.g. for an
IPsec or GRE/IP packet).
Tom
>
> Brian
>
> >
> > Tom
> >
> > On Mon, Jan 14, 2019 at 11:55 AM Joel M. Halpern
> > wrote:
> >>
> >> I have re-read this document. I think it is a useful document that
> >> captures that state of a complex tradeoff and makes effective
> >> recommendations. I support publishing it as a BCP.
> >>
> >> If the authors make further additions, adding a mention of ECMP as a
> >> particular case of stateless load balancers might further improve the
> >> document.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 1/14/19 1:13 PM, Wassim Haddad wrote:
> >>> Dear all,
> >>>
> >>> This email starts an Int-Area WG Last Call on the latest version of "IP
> >>> Fragmentation Considered Fragile” draft:
> >>>
> >>> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-05
> >>>
> >>> Please respond to this email to support the document and/or send comments
> >>> by 2019-01-28.
> >>>
> >>> Please indicate if you are personally aware of any IPR that applies to
> >>> draft-ietf-intarea-frag-fragile-xx?
> >>> If so, has this IPR been disclosed in compliance with IETF IPR rules?
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Juan & Wassim
> >>> ___
> >>> Int-area mailing list
> >>> Int-area@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/int-area
> >>>
> >>
> >> ___
> >> Int-area mailing list
> >> Int-area@ietf.org
> >> https://www.ietf.org/mailman/listinfo/int-area
> >
> > ___
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area
> >
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)
On Tue, Jan 15, 2019, 6:17 PM Ron Bonica Tom, > > Please take a look at Section 4.3 (Stateless Firewalls). How can the > stateless firewall behave optimally without maintaining state? > Ron, A stateless firewall that maintains state is no longer a stateless firewall. Introducing state requires memory and additional logic that are at odds with the goal of cheap low end devices. A stateless firewall could just drop the first fragment that contains the transport layer header and allow non first fragments to past. This achieves the filtering goal to prevent delivery of the reassmbled packet. It does mean fragments that can't possibly be reassembled make it to the destination. Whether or not that is a mere nuisance or causes real problems that creates a DOS vector depends on other factors in deployment. Also, if state is required then what is the algorithm that uses that state? in section 4.6 virtual reassembly is mentioned in passing, but they goes on to say that has problems. It's also true that stateful firewalls inevitably break multi-path but stateless firewalls don't which is a big advantage. It's not clear to me that making stateless firewalls stateful is an improvement. Tom > While flow labels may help in the case of load balancers, the don't help > at all in the case of stateless firewalls. > Ron > > > Secondly, the only specified interaction between fragmentation and > > intermediate nodes is that routers can fragment packets in IPv4. Other > than > > that, a middlebox that complies with RFC791 and RFC8200 does not process > > or consider fragmentation of packets. Given that, it's unclear to me why > > middle boxes would need to maintain state to be protocol compliant. It's > > possible that the implicit exception of the requirement is that > middleboxes > > might perform "in-network reassembly" > > or "virtual reassemlby" which would require state. If that is indeed the > case > > then the requirements for the mechanisms should be spelled out. > > > > For stateless load balancing (described in section 4.4), the IPv6 flow > label > > obviates the need for DPI. It is sufficient to hash over the three tuple > > daddr, flow label> to get good load balancing. All major OSes have been > > updated to set flow labels, and there are devices that already support > this. > > IMO, the draft should make using flow label for stateless load balancing > a > > SHOULD. > > > > Tom > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)
On Wed, Jan 16, 2019 at 11:40 AM Ron Bonica wrote: > > Inline….. > > > > From: Tom Herbert > Sent: Wednesday, January 16, 2019 2:27 PM > To: Ron Bonica > Cc: int-area > Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom > Herbert) > > > > > > On Tue, Jan 15, 2019, 6:17 PM Ron Bonica > Tom, > > Please take a look at Section 4.3 (Stateless Firewalls). How can the > stateless firewall behave optimally without maintaining state? > > > > Ron, > > > > A stateless firewall that maintains state is no longer a stateless firewall. > Introducing state requires memory and additional logic that are at odds with > the goal of cheap low end devices. > > > > True, but orthogonal to the issue at hand. You asked why a middle box might > need to maintain state to perform properly. I offered the example of a > firewall. In the presence of fragments, only a stateful firewall can perform > its intended task. > Ron, I don't follow. If the intended task is to drop packets based on some filter then dropping the first fragment meets the requirement. If the intent is something else then the requirements should be enumerated. Neither do I understand why a stateful firewall uniquely satisfies the requirements without breaking others. All we know from the description is that they're stateful, but we don't know how they should manage and using state nor the requirements they have followed. Think of it this way, if I were a manufacturer of a stateless device and I read the draft I might be convinced of the recommedation that I need to add state to my devices. But then what does that mean? Where is the specification and requirements that tells me how to do that? Tom > > > > > A stateless firewall could just drop the first fragment that contains the > transport layer header and allow non first fragments to past. This achieves > the filtering goal to prevent delivery of the reassmbled packet. It does mean > fragments that can't possibly be reassembled make it to the destination. > Whether or not that is a mere nuisance or causes real problems that creates a > DOS vector depends on other factors in deployment. > > > > It is at least a nuisance and at worst a DOS vector. > > > > Also, if state is required then what is the algorithm that uses that state? > in section 4.6 virtual reassembly is mentioned in passing, but they goes on > to say that has problems. It's also true that stateful firewalls inevitably > break multi-path but stateless firewalls don't which is a big advantage. It's > not clear to me that making stateless firewalls stateful is an improvement. > > > > This is beyond the scope of this document. > > > > Ron > > > > > > Tom > > > > > > > While flow labels may help in the case of load balancers, the don't help at > all in the case of stateless firewalls. > > > Ron > > > Secondly, the only specified interaction between fragmentation and > > intermediate nodes is that routers can fragment packets in IPv4. Other than > > that, a middlebox that complies with RFC791 and RFC8200 does not process > > or consider fragmentation of packets. Given that, it's unclear to me why > > middle boxes would need to maintain state to be protocol compliant. It's > > possible that the implicit exception of the requirement is that middleboxes > > might perform "in-network reassembly" > > or "virtual reassemlby" which would require state. If that is indeed the > > case > > then the requirements for the mechanisms should be spelled out. > > > > For stateless load balancing (described in section 4.4), the IPv6 flow label > > obviates the need for DPI. It is sufficient to hash over the three tuple > > > daddr, flow label> to get good load balancing. All major OSes have been > > updated to set flow labels, and there are devices that already support this. > > IMO, the draft should make using flow label for stateless load balancing a > > SHOULD. > > > > Tom > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
On Wed, Jan 16, 2019 at 10:20 PM Joe Touch wrote: > > Tom, > > On 1/14/2019 2:04 PM, Tom Herbert wrote: > > Hello. I have a couple of comments: > > >From the draft: > "Middle boxes SHOULD process IP fragments in a manner that is > compliant with RFC 791 and RFC 8200. In many cases, middle boxes must > maintain state in order to achieve this goal." > > This requirement is confusing to me on several accounts. First of all, > there are a lot of requirements about fragmentation in both RFC791 and > RFC8200, including some MUSTs. This requirement seems to be updating > and possibly relaxing some of those requirements, but is not specific. > > I disagree; being compliant with existing RFCs neither updates nor relaxes > those RFCs. > > This seems ambiguous as a normative requirement. > > Perhaps vague, agreed. > > Secondly, the only specified interaction between fragmentation and > intermediate nodes is that routers can fragment packets in IPv4. > > Agreed. However, nodes that *create* packets with their own IP addresses act > as hosts; in that regard, middleboxes act both as intermediate (from the > private side to public) and hosts (from the public side). As hosts, packets > entering them, destined to *their* IP addresses, need to be reassembled, just > as with any other host. > > This is addressed in detail here: > > Touch, J,. "Middlebox Models Compatible with the Internet," Technical Report, > USC/ISI (ISI-TR-711), 2016. > > https://www.strayalpha.com/pubs/isi-tr-711.pdf > > Other > than that, a middlebox that complies with RFC791 and RFC8200 does not > process or consider fragmentation of packets. Given that, it's unclear > to me why middle boxes would need to maintain state to be protocol > compliant. > > If they process only IP headers, they don't. If they further consume the > packet's contents - as would a *host*, they need to reassemble that content > (even if virtually) to be able to interpret it. That includes associating > transport headers with all the content as well as inspecting that content. > Joe, As I mentioned, in-network reassembly has not been specified, only reassembly at end destinations has been. I suspects that implementations of in-network reassembly commonly make two incorrect assumptions: 1) All fragments of a packet traverse the network device performing reassembly 2) The first fragment is always received first Neither of these assumptions are valid for IP. > It's possible that the implicit exception of the > requirement is that middleboxes might perform "in-network reassembly" > or "virtual reassemlby" which would require state. If that is indeed > the case then the requirements for the mechanisms should be spelled > out. > > As with Ron, I agree that seems out of scope for this doc. > > For stateless load balancing (described in section 4.4), the IPv6 flow > label obviates the need for DPI. > > Only for flow-based routing; not for DPI processing involving content beyond > the transport header, e.g., content-based routing. I.e., it depends on how > far into the packet the DPI is going... > TLS and payload encryption have largely eliminated the ability for intermediate devices to perform DPI into content. Transport layer header encryption, like done in QUIC, will further reduce the value of doing DPI. Tom > It is sufficient to hash over the > three tuple to get good load balancing. All > major OSes have been updated to set flow labels, and there are devices > that already support this. IMO, the draft should make using flow label > for stateless load balancing a SHOULD. > > Tom > > On Mon, Jan 14, 2019 at 11:55 AM Joel M. Halpern wrote: > > I have re-read this document. I think it is a useful document that > captures that state of a complex tradeoff and makes effective > recommendations. I support publishing it as a BCP. > > If the authors make further additions, adding a mention of ECMP as a > particular case of stateless load balancers might further improve the > document. > > Yours, > Joel > > On 1/14/19 1:13 PM, Wassim Haddad wrote: > > Dear all, > > This email starts an Int-Area WG Last Call on the latest version of "IP > Fragmentation Considered Fragile” draft: > > https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-05 > > Please respond to this email to support the document and/or send comments by > 2019-01-28. > > Please indicate if you are personally aware of any IPR that applies to > draft-ietf-intarea-frag-fragile-xx? > If so, has this IPR been disclosed in compliance with IETF IPR rules? > > > Regards, > > Juan & Wassim > _
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
On Thu, Jan 17, 2019 at 7:06 AM Joe Touch wrote: > > Hi Tom, > > > On Jan 17, 2019, at 6:55 AM, Tom Herbert wrote: > > > >> On Wed, Jan 16, 2019 at 10:20 PM Joe Touch wrote: > >> > >> Tom, > >> > >> On 1/14/2019 2:04 PM, Tom Herbert wrote: > >> > >> Hello. I have a couple of comments: > >> > >>> From the draft: > >> "Middle boxes SHOULD process IP fragments in a manner that is > >> compliant with RFC 791 and RFC 8200. In many cases, middle boxes must > >> maintain state in order to achieve this goal." > >> > >> This requirement is confusing to me on several accounts. First of all, > >> there are a lot of requirements about fragmentation in both RFC791 and > >> RFC8200, including some MUSTs. This requirement seems to be updating > >> and possibly relaxing some of those requirements, but is not specific. > >> > >> I disagree; being compliant with existing RFCs neither updates nor relaxes > >> those RFCs. > >> > >> This seems ambiguous as a normative requirement. > >> > >> Perhaps vague, agreed. > >> > >> Secondly, the only specified interaction between fragmentation and > >> intermediate nodes is that routers can fragment packets in IPv4. > >> > >> Agreed. However, nodes that *create* packets with their own IP addresses > >> act as hosts; in that regard, middleboxes act both as intermediate (from > >> the private side to public) and hosts (from the public side). As hosts, > >> packets entering them, destined to *their* IP addresses, need to be > >> reassembled, just as with any other host. > >> > >> This is addressed in detail here: > >> > >> Touch, J,. "Middlebox Models Compatible with the Internet," Technical > >> Report, USC/ISI (ISI-TR-711), 2016. > >> > >> https://www.strayalpha.com/pubs/isi-tr-711.pdf > >> > >> Other > >> than that, a middlebox that complies with RFC791 and RFC8200 does not > >> process or consider fragmentation of packets. Given that, it's unclear > >> to me why middle boxes would need to maintain state to be protocol > >> compliant. > >> > >> If they process only IP headers, they don't. If they further consume the > >> packet's contents - as would a *host*, they need to reassemble that > >> content (even if virtually) to be able to interpret it. That includes > >> associating transport headers with all the content as well as inspecting > >> that content. > >> > > Joe, > > > > As I mentioned, in-network reassembly has not been specified, only > > reassembly at end destinations has been. > > Hint - if a packet arrives on your interface with your IP address, you ARE a > host. > Joe, Conversley, if a packet arrives on your interface that isn't destined to your IP address, you ARE NOT a host. > > I suspects that > > implementations of in-network reassembly commonly make two incorrect > > assumptions: > > The first one is above... > > > > 1) All fragments of a packet traverse the network device performing > > reassembly > > 2) The first fragment is always received first > > > > Neither of these assumptions are valid for IP. > > Agreed, but again, there are three incorrect assumptions. The first is that a > NAT isn’t a host, and too often that’s the one that causes the above two to > actually cause pain. > If NAT is a host, then it is only a host in the return path. Packets sent from the client behind a NAT have destinations addresses that are not those of the the NAT device. If a device is performing host procedures on such packets, like reassembly, then it is being done outside the auspices of the standard. In any case, this isn't a NAT specific issue. Stateful firewalls regularly process packets for which they aren't the destination. Tom > > > >> It's possible that the implicit exception of the > >> requirement is that middleboxes might perform "in-network reassembly" > >> or "virtual reassemlby" which would require state. If that is indeed > >> the case then the requirements for the mechanisms should be spelled > >> out. > >> > >> As with Ron, I agree that seems out of scope for this doc. > >> > >> For stateless load balancing (described in section 4.4), the IPv6 flow > >> label obviates the need for DPI. > >> > >> Only for flow-based routing; not for DPI processing involving content > >> beyond the transport header, e.g., content-based routing. I.e., it depends > >> on how far into the packet the DPI is going... > >> > > TLS and payload encryption have largely eliminated the ability for > > intermediate devices to perform DPI into content. Transport layer > > header encryption, like done in QUIC, will further reduce the value of > > doing DPI. > > Yes and no; there are still devices that do DPI on content - especially > devices that spoof the initial splash page for Internet access when at > hotspots. Some of them won’t even open a splash page unless customers first > access a non-TLS website. > > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
On Thu, Jan 17, 2019 at 8:24 AM Joe Touch wrote: > > Hi, Tom, > > On 2019-01-17 07:27, Tom Herbert wrote: > > On Thu, Jan 17, 2019 at 7:06 AM Joe Touch wrote: > > > Hi Tom, > > On Jan 17, 2019, at 6:55 AM, Tom Herbert wrote: > ... > > As I mentioned, in-network reassembly has not been specified, only > reassembly at end destinations has been. > > > Hint - if a packet arrives on your interface with your IP address, you ARE a > host. > > Joe, > > Conversley, if a packet arrives on your interface that isn't destined > to your IP address, you ARE NOT a host. > > > Correct. Note that the association of host with traffic counts for both > transmission and reception, though. > > > > I suspects that > implementations of in-network reassembly commonly make two incorrect > assumptions: > > > The first one is above... > > > 1) All fragments of a packet traverse the network device performing reassembly > 2) The first fragment is always received first > > Neither of these assumptions are valid for IP. > > > Agreed, but again, there are three incorrect assumptions. The first is that a > NAT isn't a host, and too often that's the one that causes the above two to > actually cause pain. > > If NAT is a host, then it is only a host in the return path. Packets > sent from the client behind a NAT have destinations addresses that are > not those of the the NAT device. If a device is performing host > procedures on such packets, like reassembly, then it is being done > outside the auspices of the standard. > > > > Not quite. The return path is certainly easier to see, but the forward path > doesn't *relay* the incoming packets; it consumes them. Which is what a host > does. > > The outgoing packets are emitted with the source IP of the NAT. So in the > forward direction, strictly, only the *content* is relayed. > > If that content is modified (i.e., address/port rewriting) or inspected, then > that device is acting as a host. > If the outgoing HOST packets depend on something of the incoming ones, then > that device is also acting as a host. > > > > In any case, this isn't a NAT specific issue. Stateful firewalls > regularly process packets for which they aren't the destination. > > > And they are similarly bound by the rules of being a host *when they do*. > Joe, That's impossible. The first rule is that a host is defined as a node to which packets are addressed. Intermediate nodes performing host processing on packets that don't have their address have already violated rule #1. If they're keeping flow state in the network (connection state or reassembly), then that inevitably forces the requirement that packets have to be routed through a particular node in order for state to be maintained. This is not a problem hosts have, and it's not required in IP that packets of a flow have to always take the same path to a destination. Without additional requirements on deployment, stateful devices break multi-path. So if these devices need to *emulate* host behaviors then there really should be a specification to that effect. It's not enough to simply say they have to follow host requirements. They can't and they clearly impose additional requirements. Tom > The Internet requirements work just fine; its the devices that aren't > following them. > > Joe > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
On Thu, Jan 17, 2019 at 12:48 PM Joe Touch wrote: > > Hi, Tom, > > > > > On 2019-01-17 08:58, Tom Herbert wrote: > > On Thu, Jan 17, 2019 at 8:24 AM Joe Touch wrote: > > > ... > Hint - if a packet arrives on your interface with your IP address, you ARE a > host. > > Joe, > > Conversley, if a packet arrives on your interface that isn't destined > to your IP address, you ARE NOT a host. > > > Correct. Note that the association of host with traffic counts for both > transmission and reception, though. > > > > I suspects that > implementations of in-network reassembly commonly make two incorrect > assumptions: > > > The first one is above... > > > 1) All fragments of a packet traverse the network device performing reassembly > 2) The first fragment is always received first > > Neither of these assumptions are valid for IP. > > > Agreed, but again, there are three incorrect assumptions. The first is that a > NAT isn't a host, and too often that's the one that causes the above two to > actually cause pain. > > If NAT is a host, then it is only a host in the return path. Packets > sent from the client behind a NAT have destinations addresses that are > not those of the the NAT device. If a device is performing host > procedures on such packets, like reassembly, then it is being done > outside the auspices of the standard. > > > > Not quite. The return path is certainly easier to see, but the forward path > doesn't *relay* the incoming packets; it consumes them. Which is what a host > does. > > The outgoing packets are emitted with the source IP of the NAT. So in the > forward direction, strictly, only the *content* is relayed. > > If that content is modified (i.e., address/port rewriting) or inspected, then > that device is acting as a host. > If the outgoing HOST packets depend on something of the incoming ones, then > that device is also acting as a host. > > > > In any case, this isn't a NAT specific issue. Stateful firewalls > regularly process packets for which they aren't the destination. > > > And they are similarly bound by the rules of being a host *when they do*. > > Joe, > > That's impossible. The first rule is that a host is defined as a node > to which packets are addressed. > > > A second rule - per RFC 1812 - is that forwarding devices modify only the > opcount and certain IP options. > > > > Intermediate nodes performing host > processing on packets that don't have their address have already > violated rule #1. > > > They consume those packets, they are acting as if they think all outgoing > dest addresses are theirs and assigned to their interface. I.e., from the > outside, they act exactly as if their interface has ALL those addresses. > > > If they're keeping flow state in the network > (connection state or reassembly), then that inevitably forces the > requirement that packets have to be routed through a particular node > in order for state to be maintained. > > > Agreed. And because they act as host, they fail badly when they're not > deployed under host assumptions and requirements. > > > > This is not a problem hosts have, > > > It is - that's implicit in the function of their reassembly mechanism and a > reason why it's hard to deploy "virtual" hosts that live in multipe places on > the network (e.g., for single-IP load balancing server farms, for virtual > deployment of copies of a single IP in multiple places, etc.) > > > and it's not required in IP that packets of a flow have to always take > the same path to a destination. > > > > Path, no - agreed. But *destination*, yes. Again, the host *is* the > destination. > > > > Without additional requirements on > deployment, stateful devices break multi-path. > > > Other way around; multipath breaks stateful devices (they don't work as > desired) when they're not deployed *as the hosts they actually are and always > have been* (at least when they perform certain functions we're talking about > there). > > > > So if these devices need to *emulate* host behaviors then there really > should be a specification to that effect. > > > When you act as a host, you have to follow the rules of being a host. > > > > It's not enough to simply > say they have to follow host requirements. > > They can't and they clearly > impose additional requirements. > > > I agree they don't; it's clear they CAN (it would be costly). > > They don't impose any new requirements beyond b
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
On Thu, Jan 17, 2019 at 3:17 PM Joe Touch wrote: > > > > On Jan 17, 2019, at 1:09 PM, Tom Herbert wrote: > > Joe, > > When they attempt to do host processing on packets that don't belong > to them they're not hosts. > > > They are every host for whose packets they process. > > And when they do this, they impose a new > requirement that hosts do not have which is that packets for some flow > must consistently the traverse the same intermediate node. > > > It’s not an intermediate node - it’s a host. It’s the same requirement as any > host - that a host has one point of attachment to a network for a given IP > address. > > In any case, as I said previously, reassembly is only specified as an > operations at destination hosts. > > > And these are destination hosts because of how they behave, which means they > need to reassemble (either actually or logically). > > It seems like there might be a need > for in-network reassmbly, or some nodes might be doing it already. > > > It’s not in-network - it’s at a host, but yes, some do reassemble (or its > equivalent). > > But, in that case we really need the specification of the protocol to > have a meaning discussion about it. > > > RFC 791 and 1122 provide everything that is needed. > > It’s not new, it’s just not an “intermediate” node. Never was. > Joe, You can try this experiment. Provision two stateful firewalls as egress points of a network. From an internal network network host connect to an external host of the network. Now changing routing. If packets to the external network were being routed through firewall A, changing routing so they go through firewall B. Now take a look at what happens to packets on the connection. They are dropped at firewall B because it does not have the connection state that firewall A has. The connection is no longer viable. You can call these devices whatever you want, but that doesn't change the fact that stateful devices in the network, including those that attempt reassembly, break multi-path. Tom > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
