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