Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
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). >> 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 (all that apply to transports, including translation of signaling related to transport protocols and ports). 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 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 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. 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. >> ... >> 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. Which is a great reason why it might actually be useful to shift the security work to a "home entrance" device by placing the security there. It's a matter of system configuration, but the point is that it isn't the device that makes it incorrect; it is how it is configured and deployed. 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
>
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] WG Adoption Call: IP Fragmentation Considered Fragile
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. > 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; >> 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] WG Adoption Call: IP Fragmentation Considered Fragile
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. In fact, there are several that don't have them like IPsec, fragmented packets, or ICMP. Firewalls that drop anything but UDP and TCP are doing nothing more that ossifying the Internet. Besides that, there are now better alternatives anyway. Reassembly for NAT doesn't require any knowledge or port numbers or even what the transport protocol is. Routers can now use the IPv6 flow label instead of expensive DPI to get transport ports for ECMP as all major OSes now set non-zero flow labels. > flows. For each of these, a different identifier could be developed, but > they would not then reduce the need for ALL of these at the IP level at some > boxes. E.g., see draft-touch-tcpm-sno > > 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. 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. 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. > > 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 does a long way to at least force the issue. First TLS negated payload inspection at middelboxes. QUIC's encryption of transport layer header subsequently negated intermediate devices ability to peruse the transport layer. But, crypto isn't magic dust either. There is only so much of the packet we can encrypt, and a host at its discretion MAY want to share to share transport layer information in the network to get better service. So we need to keep working on solutions. 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 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 flows. For each of these, a different identifier could be developed, but they would not then reduce the need for ALL of these at the IP level at some boxes. E.g., see draft-touch-tcpm-sno Ultimately, we have to admit that a device that acts on behalf of a host IS a host and costs what a host costs. We can't keep believing there is magic dust that can establish a solution otherwise. 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
Hi, Toerless, Overall, I think that it's OK for the doc to remind of us of what is *already* required and best practice: - IPv4 hosts SHOULD avoid enabling in-net fragmentation (needed, in part, for IP ID compliance at high rate per RFC 6864) - IP routers MUST support forwarding of fragments - a router that forwards on information not available in the first fragment is acting as a proxy for a host; in that case, it SHOULD maintain enough context to forward fragments (which may involve delaying non-initial fragments and/or keeping state equivalent to reassembly between fragments) - NATs MUST support forwarding of fragments in both directions because they act as proxies for the private side host (done in the same manner as for routers, noted above) - transport layers SHOULD use PLPMTUD rather than PMTUD, if fragmentation is supported at the transport layer IMO, all other recommendations are premature at best. Pushing transport IDs into the IP header doesn't help; the transport layer already has EXACTLY the extra state needed (the frag ID), and new IP options are both costly and not robust -- adding them at best "shuffles the deck chairs". Joe On 2018-08-28 15:09, 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. > > 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. > > 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. > > 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, 2018 at 08:01:07PM -0700, Joe Touch wrote: > >> IPv6. IP options. > > IMHO hop-by-hop optsion got burned and are undeployable because the > RFCs never made it mandatory enough to have them never impact forwarding > performance randonly and badly. We had to abandon perfectly good > hop-by-hop inspection solutions because there whee so many stupid router > implemntations out there that didn't even have the feature but would still >
