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

[Sheng Jiang <shengjiang at huawei.com>]

Hi, Brian and all,

We are doing an open source implementation of SeND/CGA and some extension
what CSI WG is doing together with Beijing University of Post and
Communication. So far, the SeND/CGA implementation has been done and proved
work well through a little bit update may need. We will publish our source
code for download later this month or early next month after we finish the
extension implementation. Before us, Docomo also did experimental
implementation back to 2006.

Best regards,

Sheng

> -----Original Message-----
> From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of
Brian
> E Carpenter
> Sent: Thursday, July 23, 2009 12:32 PM
> To: john.loughney at nokia.com
> Cc: narten at us.ibm.com; julienl at qualcomm.com; ipv6 at ietf.org;
> hesham at elevatemobile.com
> Subject: Re: Node Requirements: Issue 13 - CGA/SeND support
> 
> What information do we have from the real world about deployability?
> 
> It would be foolish to mandate something that doesn't work well.
> 
>    Brian
> 
> On 2009-07-23 16:03, john.loughney at nokia.com wrote:
> > Hesham,
> >
> > I agree with you, the Node cannot know this, it can only do the right
thing
> once the SeND process starts. Do people feel that SeND should be a basic
feature
> of IPv6 that all nodes SHOULD support?
> >
> > John
> >
> > -----Original Message-----
> > From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of
ext
> Hesham Soliman
> > Sent: Wednesday, July 22, 2009 11:46 PM
> > To: Laganier, Julien; Thomas Narten; ipv6 at ietf.org
> > Subject: Re: Node Requirements: Issue 13 - CGA/SeND support
> >
> > Looks good in general, but I'm not sure if the host can always determine
the
> nature of the link or the level of security available on that link. It can
> probably infer (sometimes inaccurately) but it's not laways possible to
know.
> >
> > I agree with the SHOULDs and the intention of the MAY, I just don't know
if
> a host knows enough to decide about the MAY.
> >
> > Hesham
> >
> >
> > On 23/07/09 12:59 PM, "Laganier, Julien" <julienl at qualcomm.com> wrote:
> >
> >> 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
> >>> --------------------------------------------------------------------
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6 at ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6 at ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6 at ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------