Hi Tero, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Tero Kivinen [mailto:[email protected]] > Envoyé : mardi 29 janvier 2019 19:37 > À : BOUCADAIR Mohamed TGI/OLN > Cc : IPsecME WG > Objet : RE: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt > > [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. [Med] The difference is that the status codes in the draft reflect the capabilities of the responder independently of the address assignment. 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? [Med] If we reason in terms of AF capabilities/policies, codes for each AF is straightforward. > > > > 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. [Med] Isn't odd to return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE for a request which already asked for both AFs? > > 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. [Med] If we want more deterministic behaviors of initiators and more interoperability, MAY is too weak. SHOULD would be OK. > -- > [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
