Valery Smyslov writes: > > The rest of the section is ok. On the other hand if someone creates > > second IKE SA and because it is not only SA does not send > > INITIAL_CONTACT notification, it would be quite useless to start dead > > peer detection for the IKE SA sharing same IP-address, because the new > > IKE SA created did already tell that this is not the only IKE SA... > > Isn't it already presumed? Do you think we should mention this > explicitely?
No, when you did say that the INITIAL_CONTACT is always ignored :-) If you ignore it you cannot use that information whether it was there not... Thats why I complained about MUST be ignored. > How about: > > Additionally, the event of creating a new unauthenticated IKE SA > containing INITIAL_CONTACT notification can be used to trigger > an out-of-order check on existing unauthenticated IKE SAs, > possibly limited to identical or close-by IP addresses or to identical > identities > of the just created IKE SA. > > (added wods "containing INITIAL_CONTACT notification "). Looks good. > Unfortunately with the current matching rules > you cannot specify in PAD that the remote ID can be anything. Why not? The RFC4301 talks about IKE ID, it does not anywhere specify that you must only use the remote ID when matching PAD. If you support IKEv2 You Tarzan, me Jane feature, you need to do that anyways. Again this is implementation dependant, and you can implement this in multiple ways. One way to implement is to have completely separate SPDs for each local identities, and that would be useful if you want to support virtual routers or similars. In some cases you might simply have some rules giving both local and remote identities, and match both, or some rules having only one. > For example, if ID Type is Key ID, then only exact > match is allowed by RFC4301, so you cannot express that > for this unauthenticated connection client's ID of type > Key ID is irrelevant. Sure you can. The RFC4301 sets the minimum bar for the matching rules. If your implementation wants it can take the Key ID, divide it to factors, and select the SPD entry based on the largist factor the number has :-) And it would still be according to the RFC4301 if you ALSO support exact match. In the RFC4301 it does say: The Key ID field is defined as an OCTET string in IKE. For this name type, only exact-match syntax MUST be supported (since there is no explicit structure for this ID type). Additional matching functions MAY be supported for this ID type. I.e. additional matching functions MAY be supported... Bah, running late again, I will come back to final version 2.4 section tomorrow... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
