I mostly agree with Erik's suggested text, but would reword it a bit to say three things:
1) the concept of proxied NAs is not introduced by this draft, it's in the base ND spec, and the mechanisms in this draft do not introduce any additional security issues beyond the ones inherent in the base ND spec (which at Draft Std) 2) IPv4 ARP proxying is widely deployed and the security of this spec is no worse than IPv4 ARP proxying. Hence it does not make the situation worse, but instead provides the potential for adding security in the future. 3) this document assumes that securing proxyied NA's would be done by an extension to SEND -Dave > -----Original Message----- > From: Erik Nordmark [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 03, 2004 9:06 AM > To: Dave Thaler > Cc: [EMAIL PROTECTED] > Subject: ndproxy and SEND > > draft-thaler-ipv6-ndproxy-02.txt says: > > > o Support secure IPv6 neighbor discovery. This is discussed in > > the Security Considerations section. > > I don't understand what it means to support SEND, given that the > combination of SEND and ndproxy currently doesn't work. > > > As a result, securing Neighbor Discovery or ARP must take into > > account the ability to proxy messages. This document does not > > introduce any new requirements in this regard. > > I would be much clearer if the document instead said > This document assumes that SEND provide security for > proxy neighbor advertisement. > > The fact that SEND doesn't currently provide security for proxy neighbor > advertisements is an indication that 1) there isn't much perceived need > for it and/or 2) it is hard to do since authorization is a challenge. > > Hence it is useful to be very clear about the assumption on what SEND > provides. > > Erik > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
