Ben Schwartz <bem...@google.com> wrote:
>> Ben Schwartz <bem...@google.com> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
