From: VANHULLEBUS Y. <va...@fr...> - 2005-07-10 14:37:09
|
On Sat, Jul 09, 2005 at 09:28:24PM -0700, uri...@op... wrote: > Can somebody please help me to clear this confusion: > > 1. RFC 3947 defines NAT-OA payload (which contains ID Type) and says > 1. that (a) ID type is defined in RFC 2407, and (b) only > 1. ID_IPV4_ADDR and ID_IPV6_ADDR types are allowed. > > 2. RFC 2407 defines ID_IPV4_ADDR = 1, > and ID_IPV6_ADDR = 5 > > 3. isakmp.h defines ISAKMP_ID_IPV4_ADDR = 0 (thankfully it's > ifdef'ed out). What is it doing there, and with such a weird value? From isakmp.h: #if 0 /* NOTE: MUST NOT use because of being defined in ipsec-doi instead them. */ /* 3.8 Identification Payload */ Guess this is a very old code which have never been cleaned out.... > ipsec_doi.h defines IPSECDOI_ID_IPV4_ADDR = 1, the correct value. > > So when processing NAT-OA payload in isakmp_quick, one should use > IPSECDOI_IP_IPV4_ADDR, right? Looks like, yes. > I find the logic of what needs to be done to add NAT-T support > fairly straightforward and trivial. But my unfamiliarity with how > the existing code does its nitty-gritty details makes it harder and > error-prone. Parsing the NAT-OA payloads in racoon is the "trivial" part of the code. After that, there is a need to keep such values, to send them to the kernel with the other infos (but I think at least some parts of that work is already done), and the most important is the kernel support for NAT-OA informations, checksums updates, etc... > > Is anybody familiar with the code internals willing to offer advice? What I'm missing is: > > 1. Parse the NAT-OA payload in isakmp_quick (isakmp_gen plus u_int8_t > type, plus 3 reserved bytes, plus the actual in_addr_t ipv4addr). IPv4 or IPv6 addr, regarding the value of the u_int8_t. > 2. Save the retrieved address in the new member of ph2handle > structure - nat_oa. Yep. > 3. When isakmp_quick comes to generating policy (assuming it is > enabled), check if NAT-T is (a) enabled, (b) detected > NATT_DETECTED_ME, and (c) our local IP address is stored in > nat_oa. If yes - replace src address with local address, and src > port with 0. No. Or, at least, it's not enough for all situations. If we are starting to support NAT-OA / NAT-T in transport mode, we should do it for all situations, including situations where we do NOT have generated policies. I don't have a solution to provide right now, but I can at least tell you this one will not be enough in some situations. And, in fact, regarding other parts of the thread about the SPD entries, I don't know exactly what to do. The "correct" SPD entry should be something like: <My addr> <Peer's private addr> esp/transport/<my addr>-<peer's public addr>/require; (or unique, or use, or maybe AH, that's not the actual problem). We need to know peer's public address to be able to send the encapsulated packet, but we also need the peer's internal IP to be able to match outgoing traffic. One again, I'm just telling that there is a problem, but I don't have a clean solution for now. Perhaps we should use peer's private address on the SPD entry, then set up information about public address in the SA informations ? But with such a mechanism, we can't initiate a negociation without more configuration parameters.... Yvan. |