Subject: [IPsec] Daniel's comments (RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes)

From: <[email-masked]>
Date: Wed, 24 Oct 2018 13:11:25 +0000

Hi Daniel,

Thank you for the comments.

Please see inline.

Cheers,
Med

De : IPsec [mailto:[email-masked]] De la part de Daniel Migault
Envoyé : vendredi 19 octobre 2018 12:28
À : Tommy Pauly
Cc : IPsecME WG; Valery Smyslov; Tero Kivinen
Objet : Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes

+1, there seems a problem to solve, so I support the adoption.

The question I would raise are:
* Do we want to add code and update IKEv2 or do we want to define an extension with IP46_SUPPORTED. For interoperability, the latest may be preferred.

[Med] What would be the purpose of IP46_SUPPORTED?

* Looking at the code points, I have the impression that with the current signaling, only the case where a single af is supported could be ambiguous. A host sending a request for IP4 and IP6 addresses, can easily deduce is which are the supported AF, except when the a single AF is supported.

[Med] There are cases where both AFs are supported, but only an address/prefix can be returned. Which address is returned is policy-based. An initiator which does not get an address family type does not know whether it didn’t get the requested AF because (1) it is not supported or (2) because of a policy. The behavior of the initiator may change as function of this.

For example, if it really needs an IPv4, but gets an IPv6 prefix, it will need to issue a request in which only INTERNAL_IP4_ADDRESS will be included and so on.

In that case maybe the IP6 should be provided with the notification ,in case the host really wants a IP4 address.

* While 3gpp use case is sufficient, I am wondering if we have use cases outside 3gpp where such extension is needed ?

[Med] I’m not aware of other use cases but I’m more than happy to cite others if any.

Of course these could be discussed after adoption.

Yours,
Daniel

On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly <[email-masked]<mailto:[email-masked]>> wrote:
Agreed with Valery that this is a fine starting point to define the problem, but we will need to iterate on the details.

I do support adoption.

Thanks,
Tommy

> On Oct 16, 2018, at 11:59 PM, Valery Smyslov <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
> after reading the draft's introduction, I think the problem described
> is real. So I support adoption of this draft.
>
> That said, it seems that the current draft solves the problem in
> suboptimal way (too many new notifications defined), but that
> can be definitely discussed in the WG. And yes, I'm ready to
> review the draft.
>
> Regards,
> Valery.
>
>> Our new charter has been approved and that includes item:
>>
>>    RFC7296 defines a generic notification code that is related to a
>>    failure to handle an internal address failure. That code does not
>>    explicitly allow an initiator to determine why a given address
>>    family is not assigned, nor whether it should try using another
>>    address family. The Working Group will specify a set of more
>>    specific notification codes that will provide sufficient
>>    information to the IKEv2 initiator about the encountered failure.
>>    A possible starting pointing is
>>    draft-boucadair-ipsecme-ipv6-ipv4-codes.
>>
>> So this email will start one week long WG adoptation call for that
>> document [1] for WG adoptation.
>>
>> Send your comments to this list before the 2018-10-21.
>>
>> [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/
>> --
>> [email-masked]<mailto:[email-masked]>
>>
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Oct 2018 11:39:06 -0400

Thanks for your response, please see my response.
Yours,
Daniel

On Wed, Oct 24, 2018 at 9:11 AM <[email-masked]> wrote:

> *De :* IPsec [mailto:[email-masked]] *De la part de* Daniel
> Migault
> *Envoyé :* vendredi 19 octobre 2018 12:28
> *À :* Tommy Pauly
> *Cc :* IPsecME WG; Valery Smyslov; Tero Kivinen
> *Objet :* Re: [IPsec] Call for WG Adoptation for
> draft-boucadair-ipsecme-ipv6-ipv4-codes
>
>
>
> * Do we want to add code and update IKEv2 or do we want to define an
> extension with IP46_SUPPORTED. For interoperability, the latest may be
> preferred.
>
>
>
<mglt>The notification of the support of the code points. These woudl be
exchanged in the IKE_AUTH Similar as  N(MOBIKE_SUPPORTED). </mglt>

* Looking at the code points, I have the impression that with the current
> signaling, only the case where a single af is supported could be ambiguous.
> A host sending a request for IP4 and IP6 addresses, can easily deduce is
> which are the supported AF, except when the a single AF is supported.
>
>
>
> [Med] There are cases where both AFs are supported, but only an
> address/prefix can be returned. Which address is returned is policy-based.
> An initiator which does not get an address family type does not know
> whether it didn’t get the requested AF because (1) it is not supported or
> (2) because of a policy. The behavior of the initiator may change as
> function of this.
>
> For example, if it really needs an IPv4, but gets an IPv6 prefix, it will need to issue a request in which only
>
> INTERNAL_IP4_ADDRESS will be included and so on.
>
> <mglt>ok so policy based means that we can expect everything, and we are
not able to define that policy in you draft. In other words we really need
all these code points</mglt>

>
>
> In that case maybe the IP6 should be provided with the notification ,in
> case the host really wants a IP4 address.
>
>
>
> * While 3gpp use case is sufficient, I am wondering if we have use cases
> outside 3gpp where such extension is needed ?
>
>
>
> <mglt>That was a question, I am not aware of other use cases.</mglt>

> On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly <[email-masked]> wrote:
>
> Agreed with Valery that this is a fine starting point to define the
> problem, but we will need to iterate on the details.
>
> I do support adoption.
>
> Thanks,
> Tommy
>
> > On Oct 16, 2018, at 11:59 PM, Valery Smyslov <[email-masked]>
> wrote:
> >
> > Hi,
> >
> >> [1]
> https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/
> >> --
> >> [email-masked]
> >>
> >> [email-masked]
> > [email-masked]
> [email-masked]
> [email-masked]