Subject: Re: [CGA-EXT] New Version for draft-krishnan-csi-proxy-send-00

From: "Jean-Michel Combes" <[email-masked]>
Date: Sat, 7 Jun 2008 02:30:25 +0200

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 <[email-masked]>:
> 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 <[email-masked]>
> To: [email-masked]
> 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
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/cga-ext
>
>
_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Jun 2008 16:53:20 +0200

Hello Jean-Michel,

> - 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

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

Cheers,

--julien

> >  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.
> >
> >  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.
> >
> >  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.
> >
> >
> >
> >

---

From: "Silviu VLASCEANU" <[email-masked]>
Date: Thu, 12 Jun 2008 17:26:23 +0200

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,

-- 
Silviu Vlasceanu

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Jun 2008 17:37:25 +0200

>             | DST = solicited_node(B)  |                          |

Yes, thanks for catching for catching this Silviu.

--julien

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 18 Jun 2008 20:02:39 +0200

Hi Julien,

2008/6/12, Julien Laganier <[email-masked]>:
>  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

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

> In the same fashion that a Router gets the certificate authorizing it to

May I have details in the case of the MIPv6 scenario? Specially, who
does provide the cert?

Cheers.

JMC.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Jun 2008 14:16:21 -0400

Hi Jean-Michel,
   Please see comments inline

> adapted for such a use: IMHO, prefix ownership is not the same as

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.

> But what is in the cert when you want to use it to proxy NS/NA? An

The /128 address of the node with eku value of "owner"

> May I have details in the case of the MIPv6 scenario? Specially, who

In very basic terms, the certificate is provided by anyone the MN that 
the MN trusts. e.g. this could be the mobility service provider.

Cheers
Suresh

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 18 Jun 2008 23:14:04 +0200

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 <[email-masked]>:
> value is "owner" (or some variant of this), these certificates can be used
> for address ownership.
>
>
> >
> >
>  In very basic terms, the certificate is provided by anyone the MN that the
> MN trusts. e.g. this could be the mobility service provider.
>
>  Cheers
>  Suresh
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 19 Jun 2008 10:09:30 +0200

Hi Jean-Michel,

> > It seems so. It also seems it would work to secure NS/NA exchange
> > based on certificates rather than CGA.
>

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 
different EKU to clearly distinguish between "Address ownership", i.e. 
in the context of SEND the authorization to issue ND signalling for a 
given IP address, vs. "router", i.e. the authorization to issue ND 
signalling advertizing a given IP prefix, and "proxy", i.e. the ability 
to issue ND signalling for any IP address within a given IP prefix.

> But what is in the cert when you want to use it to proxy NS/NA? An

There seems to be a confusion here. The usage of certs for address 
ownesrhip and security of NS/NA exchanges I proposed in the previous 
message is orthogonal to support of proxy ND, these are two different 
things.

The draft proposes to use certificates to support proxy ND, in which 
case the cert contains either the on-link prefix, or nothing.

For the address ownership usage I proposed, the cert would contain the 
address of the node asserting ownership without CGA.

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

In my view there's no difference between provisioning of authorizatoin 
certificates on router vs. home agents.

Not sure what kind of detail you're concerned about. It would help if 
you would sketch up the detailed provisionning of certificates on a 
router and point out to the steps that are different for a HA in your 
opinion.

Cheers,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 19 Jun 2008 10:24:26 +0200

Hello Jean-Michel,

> Sorry but some points are unclear for me.

Let's try to clear them then.

> 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?

Like a router does. The certificate of the ND proxy doesn't need to 
contain the address the specific address of a MN, it can simply contain 
a prefix advertized on the links, thus authorizing the ND proxy to 
issue ND signalling for all addresses under that prefix. The 
certificate can also contain no prefix at all, in which case the ND 
proxy can issue ND signalling for any address.

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

That's again orthogonal to secure ND proxy, but let me answer once more: 
in a similar fashion that a router does, e.g. the administrator install 
the certificate on the node, like it does on the router.

> Thanks for your help.

You're welcome.

--julien

> > > > 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.
> >
> > > >  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?
> >
> > > > In the same fashion that a Router gets the certificate
> > > > authorizing it to act as a router.
> > >
> > > May I have details in the case of the MIPv6 scenario? Specially,
> > > who does provide the cert?
> >
> >  In very basic terms, the certificate is provided by anyone the MN
> > that the MN trusts. e.g. this could be the mobility service
> > provider.
> >
> >  Cheers
> >  Suresh
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 19 Jun 2008 17:56:30 -0400

Hi Jean-Michel,

> because I am not sure this is the case? :)

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

> 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.

> cert is provided to the MN?

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

Cheers
Suresh

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 27 Jun 2008 20:42:12 +0200

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 <[email-masked]>:
> 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.
>
>>