Hi Tero, RFC 4555 Appendix A.2 has more text discussing this topic (when you need to create a new ESP/AH SA, how do you know where to send the IKE packets). It basically concluded this is beyond the scope of the spec, and could be very simple (e.g. just configure a single IP address somewhere), or quite complex (e.g. multiple gateways to select from).
So I think this is quite possible with RFC 4301 architecture... (but probably not supported by all implementations) Best regards, Pasi > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of ext Tero Kivinen > Sent: 28 January, 2010 14:18 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] RFC5555 and Section 2.23.1 (was: IKEv2bis, > comments about sections 1-2) > > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
