Hi Erik, | -----Mensaje original----- | De: [email protected] [mailto:[email protected]] En nombre de | Erik Nordmark | Enviado el: jueves, 10 de diciembre de 2009 17:09 | Para: [email protected] | Asunto: [CGA-EXT] Applicability of draft-ietf-csi-proxy-send | | | The document lists three applicable scenarios, and I don't understand | how the ND Proxy (RFC 4389) fits with the proposed solution. | | My understanding of the usage model for RFC 4389 is that the hosts need | not be modified, nor have any specific configuration, to work with 4389 | proxies. | | However, csi-proxy-send not only requires that all the SeND hosts be | modified, it also makes them aware of the 4389 proxy. If we are going to | make host modifications and have the hosts be aware of the proxy, then | we can do something more robust than 4389. The desirable feature of 4389 | was to be transparent to the hosts and routers. | | The other scenarios are quite different. For instance a Mobile IPv6 host | is well aware that the home agent is a proxy on its behalf.
I don't understand properly your point. Well, if hosts were upgraded to 'Secure Proxy ND' (for example, to benefit from the MIPv6 scenario), applying these tools to RFC 4389 would be straightforward. I mean, maybe this would not the solution to build specifically for 4389, but it could save the day, couldn't it? The other change required is to have a certificate for the proxy, which could be propagated by the proxy itself into the proxied segments. Being strict, router configuration is not performed (RFC 4389, sec 1.3 says that it is not appropriate for scenarios when configuration of the router can be done). Specific configuration of the hosts (apart from being SEND and secure Proxy ND aware), i.e. per-host or even per-link configuration, is not required. Of course, the mechanism is not transparent, since routers or hosts are aware of which messages have been proxied. Is there any flaw on applying this mechanism to the 4389 scenario? Do you still think it is not appropriate for the scenario? Regards, Alberto | | Erik | | _______________________________________________ | CGA-EXT mailing list | [email protected] | https://www.ietf.org/mailman/listinfo/cga-ext _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
