From: <ar...@na...> - 2008-10-30 14:47:43
|
Hi, Timo Teräs <tim...@ik...> writes: >> In order to have racoon use the CoA, the MIPv6 module sends a MIGRATE >> message which includes a KMADDRESS extension. The extension provides the >> CoA and the address of the HA to the Key Manager (IKE daemon). This is >> the ones we store in SP (local and remote hints), Phase 1 handles if > > And we only have either local or remote hint per SP. As HA is fixed, but > depending on the SP direction we set local or remote. Hum, I kind of disagree here: both should be set, even if at the moment remote will not change on the MN (i.e. will be the HA address) and local will not change on the HA (its address). KMADDRESS provides both addresses and we just set them. I don't see any reason to make things asymmetrical here, all the more if there is a need later, as commented in previous email: >> One small note though: even if the addresses currently are the CoA and >> the address of the HA, the mechanism leaves room for the MIPv6 module to >> select different addresses (say the address of another Mobile Node in >> the future). What do you think? >>> Is this correct? >> >> Yes. And I would also add at the end of the last sentence ' and the >> hints in the SP for future needs'. > > Right. > > I'm now thinking if it made sense to keep src/dst always tied to > the HoA address, and add {src,dst}_coa. Since the transport mode > stuff is also logically tied to HoA. Maybe this is not a practical > thing to do. Sorry Timo but I don't understand what you are suggesting here. > The logic is very similar to BEET. Is there some things we could > do so that possible BEET implementation would be easier? I read one of the early BEET specs a while ago but It is not fresh enough to answer that one. > Also phase2 src/dst is currently tied to phase1 src/dst. > Maybe it'd be an idea to make phase2:s tied to phase1 instead. E.g. > if phase1 dies, it's remembered in expired state until we have > a new phase1 or the phase2 dies. This way we would not need > to update phase2 structs at all. (The identities/inner addresses > never change right?) Yes, maybe we could save some bits in the structures but there is currently a lot of code using src/dst of Phase 2 (not only in my patches). Among other thinsg, this would probably mean rewriting some lookup logic. I wonder about side effects, i.e. if it should be done now. To me, it looks like something that should be put on the (growing) todo list, but I let you decide ;-) > I was trying to look if your code breaks NAT-T by only using the > sa_src/dst. I guess it might working correctly. But the comment > about sainfo is wrong: > > + * - sainfo has not been selected only based on ID payload > + * information but also based on specific Phase 1 > + * credentials (iph2->sainfo->id_i is defined), i.e. > + * local configuration _explicitly_ expect that user > + * (e.g. from asn1dn "C=FR, ...") with those IDs) */ > > sainfo is not remote block. sainfo is the phase 2 specific config > block and it's ID is an IP identity always. This has nothing to > do with remote blocks and the above comment is (partly) wrong. Maybe the comment is misleading but I don't think it is wring. It would have been better with an example. Here is one of the sainfo blocks I have on my HA *in order to have the addresses bound to the particular identity of the MN, as expected by RFC 3775 and/or RFC 3776* : sainfo address 2001:db8:83:f002:21e:bff:fe4e:3c2[0] 135 address 2001:db8:902:2:20d:93ff:fe55:8f58[0] 135 from asn1dn "C=FR, ST=FRANCE, O=NATISBAD, OU=IPsec Services, CN=arno, emailAddress=ar...@na..." { ... stuff ... } That *and* the use of remote anonymous { .... peers_identifier asn1dn "C=FR, ST=FRANCE, O=NATISBAD, OU=IPsec Services, CN=*, emailAddress=*"; verify_identifier on; .... } ... gives me the binding. I think you might be interested by the comment associated with racoon.conf file at http://natisbad.org/MIPv6/#haconf Tell me what you think. >> Maybe I was not clear: I don't say it is not safe to send IDci and IDcr, >> I just say that when I force idci = idcr = 1 in isakmp_quick.c, then, >> there are some part of NAT-T code that are no more reached (natoa >> parameter). It is possible that this will work but I just wonder how. > > Which part of NAT-T code? I think the patch you sent inline couple of > mails ago was truncated. In my opinion it is irrelevant if we send or > do not send idci/idcr. In case they are not sent we should just assume > that idci/idcr are IKE addresses and "any upper layer protocol". > Using the same logic we can remove support_proxy and instead compare > sa_src/dst and phase1 src/dst. Let's consider that I just change the following block in quick_i1send() (isakmp_quick.c), by idci = idcr = 1; (i.e. always send IDci/IDcr): if (id->proto_id == 0 && id_p->proto_id == 0 && iph2->ph1->rmconf->support_proxy == 0 && iph2->sa_src == NULL && iph2->sa_dst == NULL && ipsecdoi_transportmode(iph2->proposal)) { idci = idcr = 0; } else idci = idcr = 1; Then, a few lines later: if (pfsgroup) np = ISAKMP_NPTYPE_KE; else if (idci || idcr) np = ISAKMP_NPTYPE_ID; else np = natoa; we will never enter the last part anymore (np = natoa). Perhaps it is ok, but I prefer understanding why. Cheers, a+ |