[email protected] writes: > > We have following cases: > > > > 1) Initiator only supports/wants one address family, and it requests > > it. If responder supports that address family it will give address > > from that address family. > > [Med] Yes. > > If it also supports another family it may > > return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE too. > > [Med] An initiator which is interested to receive both would > naturally include both in its initial request.
This was case 1, where the initiator does not want two, it only wants one in this IKE SA, and if it supports two, it wants to make them separate IKE SAs because of policy reasons. The case 2 is when initiator asks for both. > > > If responder does not support address family requested it will > > return INTERNAL_ADDRESS_FAILURE (and perhaps include > > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if request would succeed with > > another address family). > > [Med] This is more complicated compared to the current design in the > draft which allows to return a status code. The initiator will then > know whether it has to retry with another address family. I do no see any difference here. Only thing is that we do not have two status codes (IP6_ONLY_ALLOWED, IP4_ONLY_ALLOWED), we have only one (ADDITIONAL_ADDRESS_FAMILY_POSSIBLE), and that the logic is reversed. I.e., in your case you return one of the two possible status codes if no other address family than what was requested can be given, in my proposal I would return the address of requested address family and status notification telling that another address family would also be possible. In both cases if the responder can return some address family it will return that in configuration payload, if not it will return INTERNAL_ADDRESS_FAILURE. As there can only be IP4_ONLY_ALLOWED or IP6_ONLY_ALLOWED but never both, what is the point of having two status codes? > > 2) Initiator is dual stack and requests both address families. If > > responder support both in same IKE SA, it will return address for > > both. > > [Med] Yes, but we need also to cover this case: > > o An initiator asks for both IPv4 and IPv6 addresses, but only one > address family can be assigned by the responder for policy > reasons. > > The initiator needs to know why only one address is assigned so that > it does not retry; hence the two separate codes. Initiator will know that it can get the address from the family that the responder returned. If there is no ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification, that means no other family is possible, thus there is no point of trying to retry. If ADDITIONAL_ADDRESS_FAMILY_POSSIBLE is returned (along with the actual ip addresses from one address family), then initiator knows it can retry. > > If it only supports one at time then it returns address for that > > and include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE to indicate that > > making another IKE SA will allow asking another set addresses. > > [Med] I'm afraid this is more complicated compared with the current > design which assumes that an initiator which interested to receive > both AFs will include both in the initial request. If Initiator and responder both support both address families, then no special status codes are needed, normal RFC7296 processing is fine. Only case where special status cases are needed in this case 2 (where initiator requests both address familieis), is when responder only supports two address families as separate IKE SAs. In that case for first request it will return addresses from one of the address familiies, and indicate that another address family would also be possible by adding ADDITIONAL_ADDRESS_FAMILY_POSSIBLE. When initiator sees that it can create another IKE SA, and request addresses from that other address family over that. This is similar than ADDITIONAL_TS_POSSIBLE in RFC7296. I.e., responder narrowed things down in traffic selectors because of policy reasons, but there would be another possible set of traffic selectors which could be used if requested separately. > > Also I do not think making it MUST to include those notifications is > > something we want to do here. > > [Med] From an interoperability standpoint, MUST is justified here. No? No, as current implementations do not do that, thus this would make all existing implementations not conforming to this, and would most likely also require version number upgrade from the 2.0 to something larger, so other end would know whether other end supports this new MUST or not. Anyways we always leave that kind of decisions to the policy, i.e., even if the implementation is dual-stack, it might not want to request both addresses, if it only needs one. Also you cannot really have MUST do xxx, except yyy. That would be SHOULD, but in this case I think MAY is better. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
