Tero Kivinen wrote:
> > If a connection is established using NAT-T, doesn't IKEv2 already
> > specify that "Any authenticated IKE packet or any authenticated UDP
> > encapsulated ESP packet can be used to detect that the IP address or
> > the port has changed."? Since ADDRESS_UPDATE message is
> > authenticated why it can't be used for roaming from NAT cases?
>
> Because the ADDRESS_UPDATE packet specifically FAILS the
> authentication. The ADDRESS_UPDATE packet contains the IP numbers, and
> those IP numbers DO NOT match the outer IP-address of the packet,
> thus it fails. The NAT-T takes address updates from the outer
> IP-address, in the MOBIKE we take it from inside the packet.
Note that we have not yet decided (as far as I have understood)
that the ADDRESS_UPDATE packet will even contain the IP number
(I know it does in your proposal). And even if it does, we have
not decided what happens if it does not match the outer IP address..
<snip>
> We can make transition from NAT-T to MOBIKE and vice versa to work
> somehow, and we can probably even extend the NAT-T to support
> multihoming for the IP-addresses not behind the NAT. If we want to
> complete protection against 3rd party bombing, then we cannot add
> NAT-T support to MOBIKE (they will be separate protocols).
>
> I do not see why we have to combine NAT-T and MOBIKE, I think it is
> better to keep them separate and make the transtions from one to
> another work. It is simplier and also offers clear point for the
> policy decision.
I'm still a bit confused by what you mean by "transitions from
one to another" and keeping them separate.
If you can do this transition without creating a new IKEv2 SA,
then it implies that MOBIKE and NAT-T will not be 100% separate,
since some IKEv2 message added by MOBIKE will modify state used
by NAT-T.
Or do you perhaps mean that the initiator has to decide before
opening an IKEv2 SA which will be used? Or decide after the
first two messages? (This would IMHO be a totally unnecessary
restriction.)
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.