Comments/Questions on draft-ietf-csi-proxy-send-00

Hello,

I read draft-ietf-csi-proxy-send-00 and I have a few question/remarks.

First, just to be sure I understand the model completely:
The draft proposes that the router relies on a certificate extensions to
authorize it to act as proxy for third party nodes. This extension to SEND is
basically a switch that says "can proxy" or "can not proxy". This means that
once the administrator has allowed a router to act as a "proxy", the router can
effectively proxy for all the addresses which are described in the certificate
(in the addressPrefix element, I think). Right ?

If that so, the proxy/router became a primary choice target for an attacker.
This should be pointed out (in the security consideration part) that the
mechanism you propose give more power to an attacker that success a "Good
router goes bad" attack than the original RFC 3971 SEND spec.

Also, I'm not sure that the proxy should actually be a router. Currently, 
this limit is imposed because only the routers are provided with 
certificates (and the approach relies on certificates). However, if the 
proxy is a router, I think the solution does not address the problem shown 
in section 4.1.
RFC 4389 does not imposes the proxy to be a router (and this is why proxy can
rewrite RA messages). If the proxying node is not a router, it has to be
authorized to act as a proxy with another procedure.  Maybe with an ability to
send RA with no prefix information.

Hope I was clear enough. :)

Best regards,

I-D Action:draft-ietf-csi-send-cert-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Cga & Send maIntenance Working Group of the IETF.

	Title           : Certificate profile and certificate management for SEND
	Author(s)       : S. Krishnan, et al.
	Filename        : draft-ietf-csi-send-cert-00.txt
	Pages           : 15
	Date            : 2009-07-02

Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for
performing router authorization.  This document specifies a
certificate profile for SEND based on Resource Certificates along
with extended key usage values required for SEND.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-csi-send-cert-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce

(Others) comments on draft-ietf-csi-sndp-prob-01

Hello,

I (re)read draft-ietf-csi-sndp-prob-01 and I have the following (small)
comments:

In section 2.3:

    ND Proxy resends messages containing their original address, even
    after modification [RFC4389].  [...]

I think the text is a little fuzzy here. Can you explain in more detail to
which "original address" you refer to ?

In section 3.4:
The text is a bit light. It would be wise to warn that generating or
modify Router Advertisement message implies that the proxy has "at
least" the same credentials as the proxied router (e.g. authorized
prefix). Proxies might even have more power than "basic" routers, given 
that they can modify/generate Router Advertisement, Neighbor Sol/Adv for 
all the node of a subnet.

Hope it helps.

Regards,
 	Tony

One more bit for hash information in CGAs? ( was [Fwd: [BEHAVE] Modified EUI-64 format]

There is an ongoing discussion in BEHAVE ml, where it seems that we 
could use the "g" bit in order to include hash information...
considering that the hash length is one of the key limitations of CGAs, 
we may consider updating 3972 to use this bit...
comments?

I attach the extract of the thread below...

-------- Mensaje original --------
Asunto: 	[BEHAVE] Modified EUI-64 format
Fecha: 	Thu, 2 Jul 2009 04:06:21 +0000
De: 	Dave Thaler <dthaler@...>
Para: 	Xing Li <xing@...>
CC: 	Behave WG <behave@...>

Similarly, with privacy addresses referred to in the draft quote
at top, RFC 3041 section 3.2.1 point 3 forces the randomized
interface identifier to adhere to this requirement, so that it's
a 63-bit random number, not a 64-bit random number.  And with
CGAs, RFC 3972 section 4 point 6 similarly forces a generated
interface identifier to adhere to this requirement. (As an aside,
it also reserves the "g" bit which is actually unnecessary
since it's not IEEE EUI-64-derived.  RFC 4291 only discusses
the "g" bit for addresses derived from IEEE EUI-64's, which
is why RFC 3041 and a translation format can still use that bit).

Re: One more bit for hash information in CGAs? ( was [Fwd: [BEHAVE] Modified EUI-64 format]

Dave Thaler escribió:
> I would agree with that, if 3972 is being updated anyway.
> I think CSI is not currently chartered to do so though.
>   

actually, we are

 From http://www.ietf.org/html.charters/csi-charter.html

- Update base specifications (RFC 3971 and 3972).
So far, though i haven0t seen much that needed to be changed in rfc3972, 
but this maybe be important

> -Dave
>
>   
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:marcelo@...]
>> Sent: Monday, July 06, 2009 11:58 AM
>> To: cga-ext@...
>> Cc: Dave Thaler
>> Subject: One more bit for hash information in CGAs? ( was [Fwd:
>> [BEHAVE] Modified EUI-64 format]
>>
>> There is an ongoing discussion in BEHAVE ml, where it seems that we
>> could use the "g" bit in order to include hash information...
>> considering that the hash length is one of the key limitations of CGAs,
>> we may consider updating 3972 to use this bit...
>> comments?
>>

Re: One more bit for hash information in CGAs? ( was [Fwd: [BEHAVE] Modified EUI-64 format]

Agreed. I think it is useful. Since the hash length is really limited, every
bit is cherish and important. One more bit means, in average, attackers have
to double their efforts in order to break the same CGA. This update suits
CSI charter well as we target to update SEND and CGA specifications from the
beginning of this CSI WG.

The only issue we need to solve is the complicite backwards compatibility.
Since we cannot indicate whether this is CGAv1 without g bit or CGAv2 with b
bit, we may have to fully abandon CGAv1 in the updating process. Personally,
I think it is fine through it requests all existing implementation changed.

Best regards,

Sheng

> -----Original Message-----
> From: cga-ext-bounces@... 
> [mailto:cga-ext-bounces@...] On Behalf Of marcelo bagnulo braun
> Sent: Tuesday, July 07, 2009 2:58 AM
> To: cga-ext@...
> Cc: Dave Thaler
> Subject: [CGA-EXT] One more bit for hash information in CGAs? 
> ( was [Fwd: [BEHAVE] Modified EUI-64 format]
> 
> There is an ongoing discussion in BEHAVE ml, where it seems 
> that we could use the "g" bit in order to include hash information...
> considering that the hash length is one of the key 
> limitations of CGAs, we may consider updating 3972 to use this bit...
> comments?
> 

Re: One more bit for hash information in CGAs? ( was [Fwd: [BEHAVE] Modified EUI-64 format]

Hello,

I agree too that it would be nice to extend the hash size, even for 1 bit. 
However, I am not sure that it should motivate a break in the backward 
compatibility. I mean, even if there is not wide deployment of SEND, 
other documents rely on the format of the CGA (HBA, RFC 5535 for example).

Maybe a change similar to RFC 4982 modifications could redefine the SEC
bits to indicate: number of bits for the hash2, the hash function and
the CGA version (indicating if "g" bit is used, and maybe more). Only
values 0 to 2 are currently used, leaving 5 values free to be assigned.

Regards,
 	Tony

On Tue, 7 Jul 2009, Sheng Jiang wrote:

> Agreed. I think it is useful. Since the hash length is really limited, every
> bit is cherish and important. One more bit means, in average, attackers have
> to double their efforts in order to break the same CGA. This update suits
> CSI charter well as we target to update SEND and CGA specifications from the
> beginning of this CSI WG.
>
> The only issue we need to solve is the complicite backwards compatibility.
> Since we cannot indicate whether this is CGAv1 without g bit or CGAv2 with b
> bit, we may have to fully abandon CGAv1 in the updating process. Personally,
> I think it is fine through it requests all existing implementation changed.
>
> Best regards,
>

I-D ACTION:draft-ietf-csi-proxy-send-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Cga & Send maIntenance Working Group of the IETF.

	Title		: Secure Proxy ND Support for SEND
	Author(s)	: S. Krishnan, J. Laganier, M. Bonola
	Filename	: draft-ietf-csi-proxy-send-01.txt
	Pages		: 22
	Date		: 2009-7-13
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-csi-proxy-send-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.