Re: Non-Last Small IPv6 Fragments

[Brian E Carpenter <[e-mail]>]

For my comment, search for "Aaargh"

On 2019-01-16 13:31, Warren Kumari wrote:
> 
> 
> On Mon, Jan 14, 2019 at 5:19 PM Fernando Gont <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 14/1/19 17:40, Erik Kline wrote:
>     >
>     >> If you really mean that the FH contains the L4 header, then:
>     >>
>     >> * There's the issue of EHs in the fragmentable part
>     >
>     > That would be addressed in an associated L4 doc, and it would probably
>     > say to ignore non-transport headers.
> 
>     In that case, we should be removing EHs in the fragmentable part (not
>     that it would be a a big deal.. just pointing it out).
> 
> 
> 
>     >>> This increases the overhead in a given fragment, but also helps to
>     >>> ensure that (eventually) intermediate systems can examine this field and
>     >>> preemptively make a drop/no-drop decision.
> 
>     Agreed.
> 
> 
> 
>     >>
>     >> Then we're back on draft-gont-v6ops-ipv6-ehs-packet-drops
>     >
>     > Understood, but any L3 solution is going to necessitate running into
>     > this.  UDP trailers is certainly cute (and +1 from me), but every
>     > transport will have to have some similar fix (or applications will
>     > have to consider rfc8085#section-3.2 type guidelines).  If there's to
>     > be an L3 solution to this L3 problem it will face some deployment
>     > issues but if its usefulness is sufficiently attractive it could find
>     > reasonably wide-spread support in due time (in the absence of ipng-ng,
>     > IPv6 is it for the long haul).
> 
>     Certainly what you describe is better than what we have -- still, I'd
>     say not good enough for fragments to survive (e.g. cases where they need
>     to be reassembled at high speed) -- and there's still the fundamental
>     problem of processing EHs.
> 
> 
>     >
>     > [Silly Idea #1]
>     >
>     > (/me thinks back to spud bof)
>     >
>     > Here's another random suggestion that maybe belongs in panrg or (more
>     > likely) the dumpster:
>     >
>     > A new hop-by-hop header under "00 1", i.e.
>     >
>     >     00 - skip over this option and continue processing the header
>     >
>     >     1 - Option Data may change en route
>     >
>     > of the form, for example, Option Type 00 1 00001, Opt Data Len 2,
>     > Option Data == MTU.  Here, the observation is that the main thing we
>     > have experience with "working" (for the most generous definition of
>     > "works") in this problemspace in the internet today is TCP MSS
>     > Clamping.  So let's have an MTU (or MSS) HbH option that can be
>     > revised monotonically downwards but never lower than 1280.  If it
>     > helps pad to 8 byte alignment we can have a 2nd 2-byte field that is
>     > untouched representing the sender's original MTU/MSS.
>     >
>     > In this way, a sender could include an HbH with either:
>     >
>     >     [HbH | 0 | 0x0202 | 2 | (1500=0x5dc) | Pad1 | Pad1]
> 
>     You mean as a kind of PMTUD?
> 
> 
> 
>     > [Silly Idea #2]
>     > Separate, even sillier idea: everyone converges on using 16 bits of
>     > the flow ID to encode the lowest MTU encountered along the path.  Here
>     > again, TCP MSS clamping style behaviour would be applied to this
> 
> 
> https://media.giphy.com/media/3o6ZthnDqxfAOFIhdC/giphy.gif
> Because there are deployed systems already, I don't think that this can be deployed **and fully relied upon**, but Ido think that it might actually be really useful. If the first 2 bits of the flow label are '11' or '10' or something, then it could mean that the next N (13?) bits of the flow label contain the minimum MTU along the path. 

Aaargh. That's a gross violation of the standard for the flow label. Short form: you can't use the flow label for signaling. Long form: RFC6436, RFC6437, plus RFC6294 for a menagerie of other terrible ways to abuse the flow label.

> It doesn't matter that it cannot be relied upon, because it could simply be used as a hint to the path MTU discovery (I tried to figure out where in RFC8201 if could be tied).
> Basically, if the N bits are less than 1280, ignore them. If they are larger than the host MTU, ignore them. If they fall between 1280 and $host_mtu, guess that they might be valid and prime the path MTU discovery process with this hint.
> Initially devices along the path will a: not touch the flow ID or b: scribble all over it like they currently do. Over time, new devices could be updated to do this, and the signal would slowly become more useable. 
> 
> It *does* mean that we would be removing (by convention) some of the possible entropy in

s/some/most/

Which is serious, since the layer 4 info is decreasingly available as entropy fodder.

   Brian

> the flow ID which might make ECMP harder, and may also discourage some of the other "lets scribble marking X into this field" ideas, but that might be a feature, not a bug.
> 
> I cannot tell if I've just taken a sharp turn into crazy town, or if this really is a good idea (and I haven't thought about it in depth - this is all a knee jerk reaction to something sufficiently hacky that it entertains me...)
> 
>  
> 
>     I assume this is for PMTUD, too. This option would be way better than
>     the preovious one (node will just not process EHs), but...give the path
>     that we have followed for FL standrdization, it wouldn't be useful for
>     anything else other than random bits. One might hack some other fields
>     e.g... special value for Payload length, but.. that would certainly look
>     ugly.
> 
> 
> What if you view it as an (initially) noisy hint, becoming more believable over time? As far as I can tell, an on-path attacker could degrade service by artificially signalling a lower MTU than really exists, but an onpath attacker could already do this (and much worse!).
> W
> 
>  
> 
> 
>     -- 
>     Fernando Gont
>     SI6 Networks
>     e-mail: [e-mail] <mailto:[e-mail]>
>     PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>