[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] Daniel's comments (RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-code
From: Daniel Migault <daniel.migault () ericsson ! com>
Date: 2018-10-25 15:39:06
Message-ID: CADZyTkkXbJy0VuHDzHRnU6en2Rnce-vt0XH=rAYwT7epzE+v5w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks for your response, please see my response.
Yours,
Daniel
On Wed, Oct 24, 2018 at 9:11 AM <mohamed.boucadair@orange.com> wrote:
> Hi Daniel,
>
>
>
> Thank you for the comments.
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* IPsec [mailto:ipsec-bounces@ietf.org] *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?
>
>
>
<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 ?
>
>
>
> [Med] I'm not aware of other use cases but I'm more than happy to cite
> others if any.
>
> <mglt>That was a question, I am not aware of other use cases.</mglt>
>
>
> Of course these could be discussed after adoption.
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly <tpauly@apple.com> 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 <smyslov.ietf@gmail.com>
> 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/
> > > --
> > > kivinen@iki.fi
> > >
> > > _______________________________________________
> > > IPsec mailing list
> > > IPsec@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ipsec
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>Thanks for your response, please see my response. \
<br></div><div>Yours, <br></div><div>Daniel<br></div><div><br><div \
class="gmail_quote"><div dir="ltr">On Wed, Oct 24, 2018 at 9:11 AM <<a \
href="mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="FR">
<div class="m_698801957010098345WordSection1">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black">Hi Daniel, <u></u><u></u></span></p> <p \
class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black"><u></u> <u></u></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black" \
lang="EN-US">Thank you for the comments. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black" lang="EN-US"><u></u> <u></u></span></p> <p \
class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black" lang="EN-US">Please see inline. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black" lang="EN-US"><u></u> <u></u></span></p> <p \
class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black" lang="EN-US">Cheers,<u></u><u></u></span></p> <p \
class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black" lang="EN-US">Med<u></u><u></u></span></p> <p \
class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black" lang="EN-US"><u></u> <u></u></span></p> <div \
style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"> <div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">De \
:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> \
IPsec [mailto:<a href="mailto:ipsec-bounces@ietf.org" \
target="_blank">ipsec-bounces@ietf.org</a>] <b>De la part de</b> Daniel Migault<br>
<b>Envoyé :</b> vendredi 19 octobre 2018 12:28<br>
<b>À :</b> Tommy Pauly<br>
<b>Cc :</b> IPsecME WG; Valery Smyslov; Tero Kivinen<br>
<b>Objet :</b> Re: [IPsec] Call for WG Adoptation for \
draft-boucadair-ipsecme-ipv6-ipv4-codes<u></u><u></u></span></p> </div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">+1, there seems a problem to solve, so I support the \
adoption.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The question I would raise are:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">* 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. <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black"><u></u> <u></u></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black" \
lang="EN-US">[Med] What would be the purpose of \
IP46_SUPPORTED?<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black" \
lang="EN-US"><u></u> \
</span></p></div></div></div></div></div></blockquote><div><mglt>The \
notification of the support of the code points. These woudl be exchanged in the \
IKE_AUTH Similar as N(MOBIKE_SUPPORTED). </mglt><br><pre \
class="gmail-newpage"><br></pre></div><blockquote class="gmail_quote" style="margin:0 \
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" \
lang="FR"><div class="m_698801957010098345WordSection1"><div \
style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm \
4.0pt"><div><div><p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black" \
lang="EN-US"><u></u></span></p> </div>
<div>
<p class="MsoNormal">* 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. <span \
style="color:black"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black" lang="EN-US"><u></u> <u></u></span></p> <p \
class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black" lang="EN-US">[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. \
<u></u><u></u></span></p> <pre><span style="color:black" lang="EN-US">For example, if \
it really needs an IPv4, but gets an IPv6 prefix, it will need to issue a request in \
which only </span><span lang="EN-US"></span> \
</pre></div></div></div></div></div></blockquote><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
link="blue" vlink="purple" lang="FR"><div \
class="m_698801957010098345WordSection1"><div style="border:none;border-left:solid \
blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><pre><span \
lang="EN-US">INTERNAL_IP4_ADDRESS will be included and so on. </span><span \
style="color:black" lang="EN-US"> \
</span></pre></div></div></div></div></div></blockquote><div><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> \
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="FR"><div \
class="m_698801957010098345WordSection1"><div style="border:none;border-left:solid \
blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><pre><span style="color:black" \
lang="EN-US"><u></u><u></u></span></pre> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black" \
lang="EN-US"><u></u> <u></u></span></p> <p class="MsoNormal"><span lang="EN-US">In \
that case maybe the IP6 should be provided with the notification ,in case the host \
really wants a IP4 address. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier \
New";color:black" lang="EN-US"><u></u> <u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US">* While 3gpp use case is sufficient, I am \
wondering if we have use cases outside 3gpp where such extension is needed \
?<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black" \
lang="EN-US"><u></u> <u></u></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black" \
lang="EN-US">[Med] I'm not aware of other use cases but I'm more than happy to cite \
others if any.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span \
lang="EN-US"><u></u></span></p></div></div></div></div></div></blockquote><div><mglt>That \
was a question, I am not aware of other use cases.</mglt> <br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div link="blue" vlink="purple" lang="FR"><div \
class="m_698801957010098345WordSection1"><div style="border:none;border-left:solid \
blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><p class="MsoNormal"><span \
lang="EN-US"> <u></u></span></p> </div>
<div>
<p class="MsoNormal">Of course these could be discussed after \
adoption.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yours, <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Daniel<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly <<a \
href="mailto:tpauly@apple.com" target="_blank">tpauly@apple.com</a>> \
wrote:<u></u><u></u></p> </div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-right:0cm"> <p class="MsoNormal">Agreed with Valery \
that this is a fine starting point to define the problem, but we will need to iterate \
on the details. <br>
<br>
I do support adoption. <br>
<br>
Thanks,<br>
Tommy <br>
<br>
> On Oct 16, 2018, at 11:59 PM, Valery Smyslov <<a \
href="mailto:smyslov.ietf@gmail.com" target="_blank">smyslov.ietf@gmail.com</a>> \
wrote:<br> > <br>
> Hi,<br>
> <br>
> after reading the draft's introduction, I think the problem described<br>
> is real. So I support adoption of this draft.<br>
> <br>
> That said, it seems that the current draft solves the problem in <br>
> suboptimal way (too many new notifications defined), but that<br>
> can be definitely discussed in the WG. And yes, I'm ready to <br>
> review the draft.<br>
> <br>
> Regards,<br>
> Valery.<br>
> <br>
>> Our new charter has been approved and that includes item:<br>
>> <br>
>> RFC7296 defines a generic notification code that is related to a<br>
>> failure to handle an internal address failure. That code does not<br>
>> explicitly allow an initiator to determine why a given address<br>
>> family is not assigned, nor whether it should try using another<br>
>> address family. The Working Group will specify a set of more<br>
>> specific notification codes that will provide sufficient<br>
>> information to the IKEv2 initiator about the encountered failure.<br>
>> A possible starting pointing is<br>
>> draft-boucadair-ipsecme-ipv6-ipv4-codes.<br>
>> <br>
>> So this email will start one week long WG adoptation call for that<br>
>> document [1] for WG adoptation.<br>
>> <br>
>> Send your comments to this list before the 2018-10-21.<br>
>> <br>
>> [1] <a href="https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/" \
target="_blank"> https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/</a><br>
>> --<br>
>> <a href="mailto:kivinen@iki.fi" target="_blank">kivinen@iki.fi</a><br>
>> <br>
>> _______________________________________________<br>
>> IPsec mailing list<br>
>> <a href="mailto:IPsec@ietf.org" target="_blank">IPsec@ietf.org</a><br>
>> <a href="https://www.ietf.org/mailman/listinfo/ipsec" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipsec</a><br> > <br>
> _______________________________________________<br>
> IPsec mailing list<br>
> <a href="mailto:IPsec@ietf.org" target="_blank">IPsec@ietf.org</a><br>
> <a href="https://www.ietf.org/mailman/listinfo/ipsec" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipsec</a><br> <br>
_______________________________________________<br>
IPsec mailing list<br>
<a href="mailto:IPsec@ietf.org" target="_blank">IPsec@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/ipsec" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipsec</a><u></u><u></u></p> \
</blockquote> </div>
</div>
</div>
</div>
_______________________________________________<br>
IPsec mailing list<br>
<a href="mailto:IPsec@ietf.org" target="_blank">IPsec@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/ipsec" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipsec</a><br> \
</blockquote></div></div></div>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic