Re: Manual PMTUD [was ...rfc2460bis-08]

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> wrote:
    >> My claim is that (3) is irrelevant, IPsec AH has sadly (very very
    >> sadly from my point of view) failed.

    > Yes. But if you want to leave the way clear for defining a non-failing
    > alternative to AH, we would need inserted headers to be excluded from
    > AHng, which means some new design, I think.

The failure of AH across the Internet has nothing to do with the AH construct
itself.   It has to do with the failure to establish any kind of useable
Internet-wide trust infrastructure anchored in ownership of IP addresses.

You can't use AH to secure interesting headers across the Internet if you
can't establish trust to do the key management.

{IPsec ESP is equally a failure for Internet-wide usage, except that it is
useful for VPNs and Remote access scenarios in which trust can be established
in the small}

Given that the alternative to header insertion is IPIP insertion, if one
wants to protect headers, one can often use ESP equally well.  The one
advantage of AH was that one was sure that the stuff inside (after) the AH
is unencrypted.  This matters to firewalls and other auditing devices that
wish to validate a flow, but not interfere with one.

    >> The PMTUD argument would be persuasive for me if PMTUD via ICMP really
    >> worked. My experience is that there are just way many problems.
    >> PLPMTUD has been the only way I've gotten IPv6 over IPsec tunnels
    >> (where there is an MTU constriction) to work consistently, and I had
    >> argued that 2460bis should standardize this rather than PMTUD.

    > Right, but my understanding is that packets that grow in transit would
    > break PLPMTUD as well (at least temporarily).

Correct, but a path change also can cause such a thing, as can a lot of other
things.

    >> As for point (4), I think that we have a general problem here
    >> regardless of insertion.  It would be nice to come up with some
    >> solutions to the problems of insertion, noting that insertion is just
    >> something that shines light on a fundamental problem.

    > Well, ICMP misrouting is kind of intrinsic in a connectionless datagram
    > network with "transparent" middleboxes that mess with packets. I think
    > you could spend the rest of your life failing to fix that.

My point is that we need tools that let us investigate problems that occur in
the middle of the network.  Particularly, in the middle of other people's
networks.   For instance, there are (have been?) bugs in some ECMP solutions
that basically kill any TCP connection that lasts longer a few minutes.
Nobody using HTTP ever notices...

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-