Jean-Michel Combes | 7 Jun 2008 02:30
Picon

Re: New Version for draft-krishnan-csi-proxy-send-00

Hi,

After a quick review, I have one comment and one question:
- IMHO, your solution should work too with anycast addresses case
- How will a ND-Proxy get the certificate authorizing it to act as an ND-Proxy?

Thanks in advance for your reply.

Best regards.

JMC.

2008/6/6, Julien Laganier <julien.IETF@...>:
> Folks,
>
>  Sorry for the noise, but another update of the Secure Proxy ND Support
>  for SEND has been posted. It fixes some misreferences and has a
>  filename matching the WG name, thus it should appear in the
>  tools.ietf.org page.
>
>  The new draft has support for ND proxy as per:
>  - ND proxies [RFC4389]
>  - MIPv6 Home Agent [RFC3775]
>  - PMIPv6 Mobility Access Gateway [I-D.ietf-netlmm-proxymip6]
>
>  You can find it there:
>
>  <http://www.ietf.org/internet-drafts/draft-krishnan-csi-proxy-send-00.txt>
>
>  Comments are still welcome!
(Continue reading)

Julien Laganier | 12 Jun 2008 16:53
Favicon

Re: New Version for draft-krishnan-csi-proxy-send-00

Hello Jean-Michel,

On Saturday 07 June 2008, Jean-Michel Combes wrote:
> Hi,
>
> After a quick review, I have one comment and one question:
> - IMHO, your solution should work too with anycast addresses case

It seems so. It also seems it would work to secure NS/NA exchange based 
on certificates rather than CGA. To achieve that it would also be 
necessary to define another EKU (extended key usage) for "Address 
ownership", in addition to "Router" and "Proxy".

> - How will a ND-Proxy get the certificate authorizing it to act as an
> ND-Proxy?

In the same fashion that a Router gets the certificate authorizing it to 
act as a router.

Cheers,

--julien

> 2008/6/6, Julien Laganier <julien.IETF@...>:
> > Folks,
> >
> >  Sorry for the noise, but another update of the Secure Proxy ND
> > Support for SEND has been posted. It fixes some misreferences and
> > has a filename matching the WG name, thus it should appear in the
> > tools.ietf.org page.
(Continue reading)

Jean-Michel Combes | 18 Jun 2008 20:02
Picon

Re: New Version for draft-krishnan-csi-proxy-send-00

Hi Julien,

2008/6/12, Julien Laganier <julien.IETF@...>:
> Hello Jean-Michel,
>
>
>  On Saturday 07 June 2008, Jean-Michel Combes wrote:
>  > Hi,
>  >
>  > After a quick review, I have one comment and one question:
>  > - IMHO, your solution should work too with anycast addresses case
>
>
> It seems so. It also seems it would work to secure NS/NA exchange based
>  on certificates rather than CGA.

Not sure that certs defined in krishnan-cgaext-send-cert-eku are well
adapted for such a use: IMHO, prefix ownership is not the same as
address ownership.

> To achieve that it would also be
>  necessary to define another EKU (extended key usage) for "Address
>  ownership", in addition to "Router" and "Proxy".

But what is in the cert when you want to use it to proxy NS/NA? An
address or a prefix?

>
>
>  > - How will a ND-Proxy get the certificate authorizing it to act as an
(Continue reading)

Julien Laganier | 19 Jun 2008 10:09
Favicon

Re: New Version for draft-krishnan-csi-proxy-send-00

On Wednesday 18 June 2008, Jean-Michel Combes wrote:
> Hi Julien,

Hi Jean-Michel,

> 2008/6/12, Julien Laganier <julien.IETF@...>:
> > Hello Jean-Michel,
> >
> >  On Saturday 07 June 2008, Jean-Michel Combes wrote:
> >  > Hi,
> >  >
> >  > After a quick review, I have one comment and one question:
> >  > - IMHO, your solution should work too with anycast addresses
> >  > case
> >
> > It seems so. It also seems it would work to secure NS/NA exchange
> > based on certificates rather than CGA.
>
> Not sure that certs defined in krishnan-cgaext-send-cert-eku are well
> adapted for such a use: IMHO, prefix ownership is not the same as
> address ownership.

An address is a "degenerated" prefix, i.e. a /128 prefix. From that 
point of view address ownership is just a special case of prefix 
ownership.

But what you seems to get at is that authorization to advertize a prefix 
is different from ownership of that prefix, and there I agree.

I don't think we'd have a problem since what I proposed is to use 
(Continue reading)

Suresh Krishnan | 18 Jun 2008 20:16
Picon
Favicon

Re: New Version for draft-krishnan-csi-proxy-send-00

Hi Jean-Michel,
   Please see comments inline

Jean-Michel Combes wrote:
> Hi Julien,
> 
> 2008/6/12, Julien Laganier <julien.IETF@...>:
>> Hello Jean-Michel,
>>
>>
>>  On Saturday 07 June 2008, Jean-Michel Combes wrote:
>>  > Hi,
>>  >
>>  > After a quick review, I have one comment and one question:
>>  > - IMHO, your solution should work too with anycast addresses case
>>
>>
>> It seems so. It also seems it would work to secure NS/NA exchange based
>>  on certificates rather than CGA.
> 
> Not sure that certs defined in krishnan-cgaext-send-cert-eku are well
> adapted for such a use: IMHO, prefix ownership is not the same as
> address ownership.

Why not :-)? If the IP address in the certificate is a /128 and the EKU 
value is "owner" (or some variant of this), these certificates can be 
used for address ownership.

> 
>> To achieve that it would also be
(Continue reading)

Jean-Michel Combes | 18 Jun 2008 23:14
Picon

Re: New Version for draft-krishnan-csi-proxy-send-00

Hi Suresh,

Sorry but some points are unclear for me.

At first, what are assumptions you have regarding the MN?
From my point of view, the MN is able to use SEND: in using either CGA
or a cert linked to its address. Is it the same assumption for you
because I am not sure this is the case? :)

Second point, if the MN have a CGA, how does the ND Proxy get the cert
which will allow it to sign the NDP signaling instead of the MN?

Last point, if the MN have a cert linked to its address, how does this
cert is provided to the MN?

Thanks for your help.

Cheers.

JMC.

2008/6/18, Suresh Krishnan <suresh.krishnan@...>:
> Hi Jean-Michel,
>   Please see comments inline
>
>  Jean-Michel Combes wrote:
>
> > Hi Julien,
> >
> > 2008/6/12, Julien Laganier <julien.IETF@...>:
(Continue reading)

Suresh Krishnan | 19 Jun 2008 23:56
Picon
Favicon

Re: New Version for draft-krishnan-csi-proxy-send-00

Hi Jean-Michel,

Jean-Michel Combes wrote:
> Hi Suresh,
> 
> Sorry but some points are unclear for me.
> 
> At first, what are assumptions you have regarding the MN?
> From my point of view, the MN is able to use SEND: in using either CGA
> or a cert linked to its address. Is it the same assumption for you
> because I am not sure this is the case? :)

Yes. I am working under the same assumption as you :-).

> 
> Second point, if the MN have a CGA, how does the ND Proxy get the cert
> which will allow it to sign the NDP signaling instead of the MN?

I think I am beginning to understand your issue. One thing I would like 
to point out is that the ND proxy gets the authority to do this not from 
the MN being proxied but from some other entity that is trusted by the 
receiving MN.

> 
> Last point, if the MN have a cert linked to its address, how does this
> cert is provided to the MN?

This is out of scope of this document. The document does not talk about 
certificates for end nodes.

(Continue reading)

Jean-Michel Combes | 27 Jun 2008 20:42
Picon

Re: New Version for draft-krishnan-csi-proxy-send-00

Hi Suresh,

I had a private exchange last week with Julien about my comments and
now I have no more issues with your proposal :)

Cheers.

JMC.

2008/6/19 Suresh Krishnan <suresh.krishnan@...>:
> Hi Jean-Michel,
>
> Jean-Michel Combes wrote:
>>
>> Hi Suresh,
>>
>> Sorry but some points are unclear for me.
>>
>> At first, what are assumptions you have regarding the MN?
>> From my point of view, the MN is able to use SEND: in using either CGA
>> or a cert linked to its address. Is it the same assumption for you
>> because I am not sure this is the case? :)
>
> Yes. I am working under the same assumption as you :-).
>
>>
>> Second point, if the MN have a CGA, how does the ND Proxy get the cert
>> which will allow it to sign the NDP signaling instead of the MN?
>
> I think I am beginning to understand your issue. One thing I would like to
(Continue reading)

Julien Laganier | 19 Jun 2008 10:24
Favicon

Re: New Version for draft-krishnan-csi-proxy-send-00

On Wednesday 18 June 2008, Jean-Michel Combes wrote:
> Hi Suresh,

Hello Jean-Michel,

> Sorry but some points are unclear for me.

Let's try to clear them then.

> At first, what are assumptions you have regarding the MN?
> From my point of view, the MN is able to use SEND: in using either
> CGA or a cert linked to its address. Is it the same assumption for
> you because I am not sure this is the case? :)

First let's talk about nodes rather than MN since I don't see what's 
specific about mobility in this discussion.

With the current SEND a node has no alternative to CGA to prove address 
ownership. I evocated a possible use of certificates for that purpose 
but that is unspecified. At last IETF, Eric Levy-Abegnoli also 
presented modifications to the SEND specification that would allow use 
of certificates.

This use of certified addresses is orthogonal the the Secure Proxy ND 
discussion, although the solution is the same, i.e. using a certificate 
to authorize issuing ND signalling for one/some addresses.

> Second point, if the MN have a CGA, how does the ND Proxy get the
> cert which will allow it to sign the NDP signaling instead of the MN?

(Continue reading)

Silviu VLASCEANU | 12 Jun 2008 17:26
Picon

Re: New Version for draft-krishnan-csi-proxy-send-00

Hello,

I have a comment related to section 4.1 of the draft-00:

4.1. Scenario 1: RFC 4389 Neighbor Discovery Proxy



Link 1 Link 2

Host A ND Proxy (P) Host B
| | |
| SRC = A | |
| DST = solicited_node(B) | |
| ICMPv6 NS | |
| TARGET = B | |
| SLLAO = B_LL | |
|---------^^^^------------>| |

The underlined (^^^^) SLLAO, shouldn't it rather be A_LL?

Best regards,

2008/6/12 Julien Laganier <julien.IETF <at> laposte.net>:
Hello Jean-Michel,

On Saturday 07 June 2008, Jean-Michel Combes wrote:
> Hi,
>
> After a quick review, I have one comment and one question:
> - IMHO, your solution should work too with anycast addresses case

It seems so. It also seems it would work to secure NS/NA exchange based
on certificates rather than CGA. To achieve that it would also be
necessary to define another EKU (extended key usage) for "Address
ownership", in addition to "Router" and "Proxy".

> - How will a ND-Proxy get the certificate authorizing it to act as an
> ND-Proxy?

In the same fashion that a Router gets the certificate authorizing it to
act as a router.

Cheers,

--julien

> 2008/6/6, Julien Laganier <julien.IETF <at> laposte.net>:
> > Folks,
> >
> >  Sorry for the noise, but another update of the Secure Proxy ND
> > Support for SEND has been posted. It fixes some misreferences and
> > has a filename matching the WG name, thus it should appear in the
> > tools.ietf.org page.
> >
> >  The new draft has support for ND proxy as per:
> >  - ND proxies [RFC4389]
> >  - MIPv6 Home Agent [RFC3775]
> >  - PMIPv6 Mobility Access Gateway [I-D.ietf-netlmm-proxymip6]
> >
> >  You can find it there:
> >
> >
> > <http://www.ietf.org/internet-drafts/draft-krishnan-csi-proxy-send-
> >00.txt>
> >
> >  Comments are still welcome!
> >
> >
> >  --julien
> >
> >
> >
> > ---------- Message transféré ----------
> > From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> > To: julien.ietf <at> laposte.net
> > Date: Fri, 6 Jun 2008 08:24:12 -0700 (PDT)
> > Subject: New Version Notification for
> > draft-krishnan-csi-proxy-send-00
> >
> >  A new version of I-D, draft-krishnan-csi-proxy-send-00.txt has
> > been successfuly submitted by Julien Laganier and posted to the
> > IETF repository.
> >
> >  Filename:        draft-krishnan-csi-proxy-send
> >  Revision:        00
> >  Title:           Secure Proxy ND Support for SEND
> >  Creation_date:   2008-06-06
> >  WG ID:           Independent Submission
> >  Number_of_pages: 22
> >
> >  Abstract:
> >  Secure Neighbor Discovery (SEND) specifies a method for securing
> >  Neighbor Discovery (ND) signaling against specific threats.  As
> >  specified today, SEND assumes that the node advertising an address
> > is the owner of the address and is in possession of the private key
> > used to generate the digital signature on the message.  This means
> > that the Proxy ND signaling initiated by nodes that do not possess
> > knowledge of the address owner's private key cannot be secured
> > using SEND.  This document extends the current SEND specification
> > with support for Proxy ND, the Secure Proxy ND Support for SEND.
> >
> >
> >
> >  The IETF Secretariat.
> >
> >
> >
> >
> > _______________________________________________
> >  CGA-EXT mailing list
> >  CGA-EXT <at> ietf.org
> >  https://www.ietf.org/mailman/listinfo/cga-ext
>
> _______________________________________________
> CGA-EXT mailing list
> CGA-EXT <at> ietf.org
> https://www.ietf.org/mailman/listinfo/cga-ext


_______________________________________________
CGA-EXT mailing list
CGA-EXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/cga-ext



--
Silviu Vlasceanu
<div>
<p>Hello,<br><br>I have a comment related to section 4.1 of the draft-00:<br><br></p>4.1.  Scenario 1: RFC 4389 Neighbor Discovery Proxy<br><br><br><br>          Link 1                                               Link 2<br><br>          Host A                   ND Proxy (P)                Host B<br>            |                          |                          |<br>            | SRC = A                  |                          |<br>            | DST = solicited_node(B)  |                          |<br>
            | ICMPv6 NS                |                          |<br>            | TARGET = B               |                          |<br>            | SLLAO = B_LL             |                          |<br>            |---------^^^^------------&gt;|                          |<br><br>The underlined (^^^^) SLLAO, shouldn't it rather be <span>A_LL</span>?
<br><br>Best regards,<br><br><div class="gmail_quote">2008/6/12 Julien Laganier &lt;<a href="mailto:julien.IETF <at> laposte.net">julien.IETF <at> laposte.net</a>&gt;:<br><blockquote class="gmail_quote">
Hello Jean-Michel,<br><div class="Ih2E3d">
<br>
On Saturday 07 June 2008, Jean-Michel Combes wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; After a quick review, I have one comment and one question:<br>
&gt; - IMHO, your solution should work too with anycast addresses case<br><br>
</div>It seems so. It also seems it would work to secure NS/NA exchange based<br>
on certificates rather than CGA. To achieve that it would also be<br>
necessary to define another EKU (extended key usage) for "Address<br>
ownership", in addition to "Router" and "Proxy".<br><div class="Ih2E3d">
<br>
&gt; - How will a ND-Proxy get the certificate authorizing it to act as an<br>
&gt; ND-Proxy?<br><br>
</div>In the same fashion that a Router gets the certificate authorizing it to<br>
act as a router.<br><br>
Cheers,<br><br>
--julien<br><div>
<div></div>
<div class="Wj3C7c">
<br>
&gt; 2008/6/6, Julien Laganier &lt;<a href="mailto:julien.IETF <at> laposte.net">julien.IETF <at> laposte.net</a>&gt;:<br>
&gt; &gt; Folks,<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;Sorry for the noise, but another update of the Secure Proxy ND<br>
&gt; &gt; Support for SEND has been posted. It fixes some misreferences and<br>
&gt; &gt; has a filename matching the WG name, thus it should appear in the<br>
&gt; &gt; <a href="http://tools.ietf.org" target="_blank">tools.ietf.org</a> page.<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;The new draft has support for ND proxy as per:<br>
&gt; &gt; &nbsp;- ND proxies [RFC4389]<br>
&gt; &gt; &nbsp;- MIPv6 Home Agent [RFC3775]<br>
&gt; &gt; &nbsp;- PMIPv6 Mobility Access Gateway [I-D.ietf-netlmm-proxymip6]<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;You can find it there:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &lt;<a href="http://www.ietf.org/internet-drafts/draft-krishnan-csi-proxy-send-" target="_blank">http://www.ietf.org/internet-drafts/draft-krishnan-csi-proxy-send-</a><br>
&gt; &gt;00.txt&gt;<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;Comments are still welcome!<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;--julien<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; ---------- Message transf&eacute;r&eacute; ----------<br>
&gt; &gt; From: IETF I-D Submission Tool &lt;<a href="mailto:idsubmission <at> ietf.org">idsubmission <at> ietf.org</a>&gt;<br>
&gt; &gt; To: <a href="mailto:julien.ietf <at> laposte.net">julien.ietf <at> laposte.net</a><br>
&gt; &gt; Date: Fri, 6 Jun 2008 08:24:12 -0700 (PDT)<br>
&gt; &gt; Subject: New Version Notification for<br>
&gt; &gt; draft-krishnan-csi-proxy-send-00<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;A new version of I-D, draft-krishnan-csi-proxy-send-00.txt has<br>
&gt; &gt; been successfuly submitted by Julien Laganier and posted to the<br>
&gt; &gt; IETF repository.<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;Filename: &nbsp; &nbsp; &nbsp; &nbsp;draft-krishnan-csi-proxy-send<br>
&gt; &gt; &nbsp;Revision: &nbsp; &nbsp; &nbsp; &nbsp;00<br>
&gt; &gt; &nbsp;Title: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Secure Proxy ND Support for SEND<br>
&gt; &gt; &nbsp;Creation_date: &nbsp; 2008-06-06<br>
&gt; &gt; &nbsp;WG ID: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Independent Submission<br>
&gt; &gt; &nbsp;Number_of_pages: 22<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;Abstract:<br>
&gt; &gt; &nbsp;Secure Neighbor Discovery (SEND) specifies a method for securing<br>
&gt; &gt; &nbsp;Neighbor Discovery (ND) signaling against specific threats. &nbsp;As<br>
&gt; &gt; &nbsp;specified today, SEND assumes that the node advertising an address<br>
&gt; &gt; is the owner of the address and is in possession of the private key<br>
&gt; &gt; used to generate the digital signature on the message. &nbsp;This means<br>
&gt; &gt; that the Proxy ND signaling initiated by nodes that do not possess<br>
&gt; &gt; knowledge of the address owner's private key cannot be secured<br>
&gt; &gt; using SEND. &nbsp;This document extends the current SEND specification<br>
&gt; &gt; with support for Proxy ND, the Secure Proxy ND Support for SEND.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;The IETF Secretariat.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; &nbsp;CGA-EXT mailing list<br>
&gt; &gt; &nbsp;<a href="mailto:CGA-EXT <at> ietf.org">CGA-EXT <at> ietf.org</a><br>
&gt; &gt; &nbsp;<a href="https://www.ietf.org/mailman/listinfo/cga-ext" target="_blank">https://www.ietf.org/mailman/listinfo/cga-ext</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; CGA-EXT mailing list<br>
&gt; <a href="mailto:CGA-EXT <at> ietf.org">CGA-EXT <at> ietf.org</a><br>
&gt; <a href="https://www.ietf.org/mailman/listinfo/cga-ext" target="_blank">https://www.ietf.org/mailman/listinfo/cga-ext</a><br><br><br>
_______________________________________________<br>
CGA-EXT mailing list<br><a href="mailto:CGA-EXT <at> ietf.org">CGA-EXT <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/cga-ext" target="_blank">https://www.ietf.org/mailman/listinfo/cga-ext</a><br>
</div>
</div>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>Silviu Vlasceanu
</div>
Julien Laganier | 12 Jun 2008 17:37
Favicon

Re: New Version for draft-krishnan-csi-proxy-send-00

On Thursday 12 June 2008, Silviu VLASCEANU wrote:
> Hello,
>
> I have a comment related to section 4.1 of the draft-00:
>
> 4.1.  Scenario 1: RFC 4389 Neighbor Discovery Proxy
>
>
>
>           Link 1                                               Link 2
>
>           Host A                   ND Proxy (P)                Host B
>
>             | SRC = A                  |                          |
>             | DST = solicited_node(B)  |                          |
>             | ICMPv6 NS                |                          |
>             | TARGET = B               |                          |
>             | SLLAO = B_LL             |                          |
>             |---------^^^^------------>|                          |
>
> The underlined (^^^^) SLLAO, shouldn't it rather be A_LL?

Yes, thanks for catching for catching this Silviu.

--julien

Gmane