Subject: [CGA-EXT] Comments/Questions on draft-ietf-csi-proxy-send-00

From: Tony Cheneau <[email-masked]>
Date: Fri, 3 Jul 2009 15:17:28 +0200 (CEST)

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