pasi.ero...@nokia.com writes:
> > ----------------------------------------------------------------------
> > 2.11. Address and Port Agility
> >
> > IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
> > AH associations for the same IP addresses it runs over.
> > ----------------------------------------------------------------------
> >
> > which usually means that for transport mode the addresses you expect
> > to se on ESP packets are same as what they were for the IKE packet
> > too, which is impossible now as the IKEv2 runs over IPv4, but ESP
> > packets run over IPv6.
>
> Hmm... What exactly that text means is actually a good question.
> If you have a multi-homed host using SCTP, for example, it would make
> sense to create a transport mode SA whose traffic selectors include
> more than one IP address. If there are no NATs, this would work fine
> (even though only one of the addresses in TS payloads would be equal
> to the address used for sending the IKE packet).
>
> So I'm not so sure if this text really prohibits the situation where
> transport mode traffic selectors aren't exactly the same as the
> addresses used for sending the IKE packet...
I agree that it does not explictly forbid having multiple addresses in
transport mode SA, but I do not think it is possible.
If we think this setup from the initiator point of view. He is sending
packet from src1 to dst1. The packet will trigger IPsec negotiation
which will then do SPD lookup. If entry is found from there, and this
is transport mode then the SPD does not have local and remote tunnel
addresses, but instead it assumes that src1 and dst1 are the address
used when creating IKE (or selecting IKE).
How do you plan to create such things using RFC4301 architecture?
I do not think SPD have any other places to store that kind of
information than in the local/remote tunnel addresses, and those are
only used in tunnel mode:
- (if tunnel mode) local tunnel address -- For a
non-mobile host, if there is just one interface, this
is straightforward; if there are multiple
interfaces, this must be statically configured. For a
mobile host, the specification of the local address
is handled externally to IPsec.
- (if tunnel mode) remote tunnel address -- There is no
standard way to determine this. See 4.5.3, "Locating
a Security Gateway".
Hmm.. it might be possible that if the PAD entry linked with that
transport mode SPD contains "peer gateway information" field which
indicates the security gateway, but the RFC4301 also says that:
For example, assume that IKE A receives an outbound packet destined
for IP address X, a host served by a security gateway. RFC 2401
[RFC2401] and this document do not specify how A determines the
address of the IKE peer serving X.
which would indicate that it might be possible to do this kind of
things with RFC4301 architecture. On the other hand it is talking
about security gateway, which usually indicates tunnel mode, as
security gateway is defined to be:
A security gateway is an intermediate system implementing
IPsec, e.g., a firewall or router that has been IPsec-enabled.
> Well, this is not the only place where RFC5555 may not work with just
> any IPsec implementation, and can require MIP-specific tweaks...
> (search for "implementation" in Section 5 if you really want to know)
I think knowledge adds pain, so I rather not... every time I try read
those MIP specific tweaks my heads start hurting, and I feel that
those tweaks are not going to work ever with any real IPsec
implementation.
> > As there is no NAT for the IPv6 addresses, then the SPD lookup based
> > on the traffic selectors would be fine, but there is no way to know
> > whether there is NAT between the IPv6 address or not, as we only
> > tested the presense of NAT for IPv4 addresses.
>
> Yes, that's true. (And even if you know there's NAT, you would not know
> what the mapped addresses are.)
Yes.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
