RE: Node Requirements: Issue 13 - CGA/SeND support
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Node Requirements: Issue 13 - CGA/SeND support



Just for the sake of getting the discussion started, I drafted some text
we can discuss:
 
   Secure Neighbor Discovery [RFC3971] SHOULD be supported.  [RFC4861] states:

      Cryptographic security mechanisms for Neighbor Discovery are outside
      the scope of this document and are defined in [RFC3971].

   Secure Neighbor Discovery [RFC3971] SHOULD be used when physical security 
   on the link is not assured.  [RFC3971] states:

      The SEND protocol is designed to counter the threats to NDP.  These
      threats are described in detail in [22].  SEND is applicable in
      environments where physical security on the link is not assured (such
      as over wireless) and attacks on NDP are a concern.

   Secure Neighbor Discovery [RFC3971] MAY be disabled when the link is 
   point-to-point and link-layer security is assured, including mutual 
   authentication of the link end-points and data origin integrity protection. 

What do you think?

--julien


> -----Original Message-----
> From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of
> Thomas Narten
> Sent: Tuesday, July 21, 2009 2:36 PM
> To: ipv6 at ietf.org
> Subject: Node Requirements: Issue 13 - CGA/SeND support
> 
> Tim Chown <tjc at ecs.soton.ac.uk> writes:
> 
> > What about CGA/SeND support?  I can't see any reference to this
> > currently.   Should there be?   It's often waved as the answer to
> > make rogue RAs 'go away', so perhaps we should.
> 
> I agree we need to have a section that addresses this topic.
> 
> If no one suggests text, I'll take a stab.
> 
> Thomas
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.