Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

[Michael Richardson <[e-mail]>]

Ben Schwartz <[e-mail]> wrote:
    >> Ben Schwartz <[e-mail]> wrote:
    >>
    > ....

    >> > The real motivation to support AH in this draft comes down to MTU
    >> > overhead.  Going from 24 bytes of MTU loss to 73 bytes seems
    >> > potentially significant, especially because:
    >>
    >> Where will you put the original src/dst IPs?
    >> 24 bytes is the AH overhead only.  The v6 src/dst requires 32 bytes,
    >> at which point you might as well just have an IPIP header at 44 bytes.
    >>

    > They're in the outer IP header, unchanged, so it really is just 24 bytes.

No, that's not legal or practical.

Even assuming that you can insert an AH header (which I think you can legally
do in IPv4, but not in IPv6), then you have to use a SPI# allocated by
destination ASBR, so you have to put the dstip= ASBR.

Really, you need to change the srcip= as well, because otherwise, ICMPs go to
the wrong place.

If you want do something else, then it's relly not IPsec.

    >> > I actually think RISAV uses RPKI for exactly the thing that RFC 9255
    >> > wants: directing IP packets to the corresponding AS number.
    >>
    >> I'm not convinced it will fly.
    >> I agree with you, but I feel like I'm in the rough.
    >>

    > I think we can set this aside until we've ironed out the technical wrinkles.

I actually think thta you need to do this up-front, otherwise, you are
wasting your time.

    >> The draft notes some interesting questions about how sequence numbers
    >> > work in this situation.  The best solution I came up with was to put
    >> > the source IP into the "Additional Data" of the AEAD (or equivalent),
    >> > but this seems like it would need a new IKEv2 extension.
    >>
    >> yes, that's an entirely new cipher mode.
    >>

    > How big a deal is a new cipher mode? It doesn't sound so bad.

It's not that big deal, but I assume you'd like to use commodity off the
shelf hardware.

    >> You have, btw, just re-invented SKIP.  And maybe that's what you actually
    >> want, btw.
    >>

    > Oh, wow.  SKIP (https://datatracker.ietf.org/doc/draft-ietf-ipsec-skip/ for
    > those following along) looks like exactly the "proposed extensions"
    > mentioned in Section 5.2 and Section 5.3 of RISAV, so it's definitely
    > relevant.  Too bad it doesn't exist...

I think that SKIP is probably the best direction to think about.
Some ex-SUN people will buy you drinks until you die if you go that way.

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