Ben Schwartz <bem...@google.com> wrote:
>> 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.
>>
> I'm not too worried about the "legalities". We write the rules!
Yes, but we did write the rules, and if you want to change them, you might
find that you will break the entire Internet.
>> 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.
>>
> No, the SPI# is allocated by AS pair, so the SPI scope is unambiguous (to
> the recipient) from the source IP. (There is no sequence number or replay
> defense.)
No, RFC4301 says that the SPI# is allocated by the host indicated by the IP dst.
If you allocate something for a host in the middle, then you will break IPsec
for all end-hosts. That's not going to fly.
> ICMPs go to the source IP, which is what we want. The only trick is
> that
No, that's absolutely not what you want.
The host that put inserted the AH has to get the ICMP errors about that AH.
> It's IPsec, but not as we know it. It's a "transparent variant of IPsec
> transport mode", or something like that.
It's not IPsec at all.
>> It's not that big deal, but I assume you'd like to use commodity off the
>> shelf hardware.
> I'm pretty sure this doesn't actually affect that. I think we would do
> something like "ESP Key = HKDF(IKEv2 DH key, source IP)", and then ESP
mode
> would run pretty much as usual. My main question was how to negotiate
this
> in the IKEv2 handshake.
You would be negotiating something new that's not ESP or AH.
> In terms of performance, my bigger concern is that sending and receiving a
> RISAV packet requires an IP->ASN mapping lookup. Hopefully ASBRs are good
> at that...
That's easy. That's just a routing lookup with nexthop=IPsec-SA#foo.
--
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
