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
- To: Hesham Soliman <hesham at elevatemobile.com>, Thomas Narten <narten at us.ibm.com>, "ipv6 at ietf.org" <ipv6 at ietf.org>
- Subject: RE: Node Requirements: Issue 13 - CGA/SeND support
- From: "Laganier, Julien" <julienl at qualcomm.com>
- Date: Wed, 22 Jul 2009 21:29:22 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: ipv6 at core3.amsl.com
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl at qualcomm.com; q=dns/txt; s=qcdkim; t=1248323570; x=1279859570; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20<julienl at qualcomm.com> |To:=20Hesham=20Soliman=20<hesham at elevatemobile.com>,=0D =0A=20=20=20=20=20=20=20=20Thomas=20Narten=0D=0A=09<narte n at us.ibm.com>,=20"ipv6 at ietf.org"=20<ipv6 at ietf.org>|Date: =20Wed,=2022=20Jul=202009=2021:29:22=20-0700|Subject:=20R E:=20Node=20Requirements:=20Issue=2013=20-=20CGA/SeND=20s upport|Thread-Topic:=20Node=20Requirements:=20Issue=2013 =20-=20CGA/SeND=20support|Thread-Index:=20AcoKS01yiUkHuYR sQSqsMip3ZoGTygA85SlwAAJKBpgAAS67YA=3D=3D|Message-ID:=20< BF345F63074F8040B58C00A186FCA57F1C22ACCA8E at NALASEXMB04.na .qualcomm.com>|References:=20<BF345F63074F8040B58C00A186F CA57F1C22ACCA8D at NALASEXMB04.na.qualcomm.com>=0D=0A=20<C68 E1A01.E678%hesham at elevatemobile.com>|In-Reply-To:=20<C68E 1A01.E678%hesham at elevatemobile.com>|Accept-Language:=20en -US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5685"=3B=20a=3D"21099515"; bh=SJ8y3bzwejMaLrNEYygj3PGcja/MD6EOXePDD1XrgoA=; b=I62jPpIRep3cEUI8Y/baYEidlnQQm/pfc9peqY74RHXLKpxg1guTAAEY oOiT7lWq9kI3CWKZCy65sLkRfHSAcXj2CZey6p180XMKEtXM96/63HOaN DvOQClZJ4v4ddrHceA2DLDxiXDr8kxXhADQ/uPKZqE69Q4jKENlY1QXI2 g=;
- In-reply-to: <C68E1A01.E678%hesham at elevatemobile.com>
- List-archive: <http://www.ietf.org/mail-archive/web/ipv6>
- List-help: <mailto:ipv6-request@ietf.org?subject=help>
- List-id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
- List-post: <mailto:ipv6@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
- References: <BF345F63074F8040B58C00A186FCA57F1C22ACCA8D at NALASEXMB04.na.qualcomm.com> <C68E1A01.E678%hesham at elevatemobile.com>
- Thread-index: AcoKS01yiUkHuYRsQSqsMip3ZoGTygA85SlwAAJKBpgAAS67YA==
- Thread-topic: Node Requirements: Issue 13 - CGA/SeND support
I think there's three cases:
1. If a link is physically secured it means the link is heavily managed in which case it seems plausible that an admin configures the host on this link as plugged on physically secured link and turns off SEND, e.g., using whatever configuration knob is available on the particular OS. Otherwise (i.e., the link is not physically secured, or the node doesn't know if it is or not),
2. If the link is point-to-point and link layer security is enabled, the node IP layer can figure it out from the link layer through an appropriate API, and as a result turn off SEND. Otherwise,
3. The node uses SEND.
--julien
Hesham Soliman <hesham at elevatemobile.com> wrote:
>
> 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 always 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
> > --------------------------------------------------------------------
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.