Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Tom Herbert <[e-mail]>]

On Tue, Aug 28, 2018 at 5:24 PM, Toerless Eckert <[e-mail]> 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 implementation
> deltails to the IPv6 architects.
>
Per RFC8200:

"NOTE: While [RFC2460] required that all nodes must examine and
process the Hop-by-Hop Options header, it is now expected that nodes
along a packet's delivery path only examine and process the Hop-by-Hop
Options header if explicitly configured to do so."

That allowance should be sufficient to resolve most of the the
Hop-by-Hop being dropped problem. All that is being asked of
middleboxes is that they ignore HBH instead of dropping the packet if
they don't want to deal with them. That should not be difficult to
implement. Hopefully, it's just a matter of evangelization and time to
improve the situation.

> *sigh*.
>
>> 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.
>
> Yes, its a darn unthankful job trying to come up with good
> architectures for middleboxes when three is so much bad code and
> bad operations out there.
>
> Hence the thought in another venue
> to have those middlebox instructions encrypted in such a
> way that any onpath node not explicitly trusted to process
> would have no way to even determine whether those options are there
> and hence had no way to figure out what packets to drop. Of course
> this approach is a lot more expensive for forwarding planes and
> does require a lot more out-of-band synchronization.

Yes. But if this is done right, it would eliminate the need to
maintain costly flow state in the network. See
https://tools.ietf.org/html/draft-herbert-fast.

>
> See above: short of something that extreme, we should focus
> on doing the right thing for new code but build it in
> such a way that it is not blocked by bad existing old onpath code.
>
Agreed.

Tom