Subject: Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt

From: <[email-masked]>
Date: Wed, 6 Mar 2019 14:22:21 +0000

Hi Tero, all, 

Any chance to conclude this issue? In particular, is there a benefit in following your proposal compared to the current approach in the draft?

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : IPsec [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : jeudi 31 janvier 2019 08:17
> À : Tero Kivinen
> Cc : IPsecME WG
> Objet : Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt
> 
> Hi Tero,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Tero Kivinen [mailto:[email-masked]]
> > Envoyé : mercredi 30 janvier 2019 21:42
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : IPsecME WG
> > Objet : RE: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-
> 02.txt
> >
> > [email-masked] writes:
> > > > > [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.
> >
> > That would be fine, if the responder could return this information
> > before the initiator would do configuration request, so initiator
> > could adjusts its request accordingly, but that would require moving
> > those status notifications to IKE_SA_INIT, and for various reasons we
> > try to keep that as small as possible, so I do not think that is
> > correct place for those notifications.
> 
> [Med] That wasn't my point. My comment is that the codes are static even if
> they are made during address configuration. That is:
> (1) An IPv4-only responder will always include IP4_ONLY_ALLOWED independently
> of the request (IPv4, IPv6, IPv4 and IPv6).
> (2) An IPv6-only responder will always include IP6_ONLY_ALLOWED independently
> of the request.
> (3) A dual-stack responder configured with an IPv4 preference will always
> include IP4_ONLY_ALLOWED in a response to a dual-stack request.
> (4) A dual-stack responder configured with an IPv6 preference will always
> include IP6_ONLY_ALLOWED in a response to a dual-stack request.
> 
> The behavior of the initiator is more deterministic, e.g., when case (1) is
> encountered:
>     - An IPv6 initiator will stop trying asking for IPv6 addresses.
>     - A dual-stack initiator who asked for both won't try with a separate
> request for IPv6
>     - A dual-stack initiator who asked first for IPv4 won't sent a request
> for IPv6
>     - A dual-stack initiator who asked first for IPv6 will send a request for
> IPv4
> 
> Now consider that ADDITIONAL_ADDRESS_FAMILY_POSSIBLE is to be defined, this
> code will returned with the following conditions:
> 
> (a) An IPv4-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE
> only if the initiator asked for IPv6.
> (b) An IPv6-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE
> only if the initiator asked for IPv4.
> (c) A dual-stack responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if
> the initiator asked for both, but for policy matters only one AF can be
> assigned per request.
> 
> The behavior of the initiator is less deterministic, e.g., case (c): A dual-
> stack initiator who asked for both but got only IPv6 or IPv4 does not know
> why the other address is not assigned. It will then send a request to try to
> get an address.
> 
> Protocols with rich error codes makes it easier to adjust the behavior, to
> diagnostic, etc.
> 
> >
> > > > > > 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?
> >
> > Nope. We do that with other cases too. I.e., initiator did request for
> > both address families, but responder said he want to do those as
> > separate IKE SAs, and returned addresses for only one address family.
> 
> [Med] OK, I see, this is doing the same job as what we used to have in -01:
> 
>    o  SINGLE_AF_SUPPORTED: This status type indicates that only a single
>       address family can be assigned per request, not both.  This status
>       type is returned when an initiator requested both IPv4 and IPv6
>       addresses/prefixes in the same request, but only a single address
>       family can be assigned per request by the responder.
> 
>       The address family preference is defined by a policy that is local
>       to the responder.
> 
>       If a responder receives a request for both IPv4 and IPv6 address
>       families, it replies with the preferred address family and
>       includes SINGLE_AF_SUPPORTED notification status type.  Upon
>       receipt of this status type, the initiator MAY re-issue another
>       configuration request to ask for an additional address family.
> 
> I have removed that code because the message I got from the working group is
> to reduce the number of codes.
> 
> > The status notification indicates that initiator might create another
> > IKE SA and request another address family in there.
> >
> > If it is not there, it will just have to cope with the address family
> > it got in the response.
> >
> > This is same as what we do with ADDITIONAL_TS_POSSIBLE.
> >
> > > > > > 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.
> >
> > I would expect this is something that will be dictated by policy
> > anyways, and unless policy says otherwise implementation that will
> > support both address families always asks for both (I mean why not).
> > So I do not think there is any real difference in MAY or SHOULD.
> > Neither one of them can give any suggestion to the adminstrator making
> > the policy, he will decided what to configure regardless what we do
> > here in our documents.
> >
> > I still think MAY would be correct, but I do not complain if people in
> > the WG think SHOULD is better.
> > --
> > [email-masked]
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec