Subject: Node requirements: draft-ietf-6man-node-req-bis-03.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 20 Jul 2009 16:25:40 -0400

Hi.

I've posted a revised version of the node requirments ID. This
document had stalled for a while and I volunteered to help move it
along. Wish me/us luck!

The new -03 version has only fairly minor changes relative to
-02. Specifically, they were (IMO) editorial cleanups that were no
brainers. A summary of the changes appears below.

Over the next few days, I will post some additional messages with
specific issues that still need to be resolved. The document will also
be discussed in Stockholm.

They include:

 - proper status of this document (info vs. BCP) and whether this
   document can update any existing RFC

 - Security recommendation. It clearly needs tweaking/updating, but
   the fundamental one  surrounds the current MUST for IPSec/ESP, MAY
   for AH, and SHOULD for some (unspecified) key management.

 - DHCP and stateless autoconf. This document is probably not the
   right place to discuss the M&O bits, but IMO this document should
   say more about DHCP vs. stateless and the issues surrounding when
   to implement one or the other. Not to mandate them. Actually, that
   raises an intersting point. This document (and RFC 4294) mandate
   (MUST) that hosts implement stateless autoconfiguration. This
   despite that this document is only informational, and no where in
   standards track RFCs is stateless autoconf mandated. This takes us
   back to the question of what the scope of this document should be.

If anyone has any other issues they think the document should address,
please speak up.

Thomas

John Loughney says:

> >section 5.1, last paragraph.  Shouldn't the doc reference RFC
> >5095 and deprecation of RH0?  suggest:
> >
> >   An IPv6 node MUST be able to process these headers.  An exception is=20
> >Routing Header type 0 (RH0) which is deprecated by [RFC 5095] due to=20
> >security concerns, and which MUST be treated as an unrecognized routing=20
> >type.
> 
> Issue 7. I think this would be good to add.

tn: done (and added reference)

> >5.2 - should RFC 5175 - extensions to RA flags - be included?
> 
> Issue 8: This would be good to add as well.

tn: done.

> >5.3.1 - would it be redundant to mention the default MTU defined in=20
> >2460, e.g. "The rules in RFC 2460 MUST be followed for default minimum=20
> >MTU size of 1280, packet fragmentation and reassembly."
> 
> Issue 9: This seems good to add.
 
tn: done. see replacement text

> >6.1 - A6 records: is NOT RECOMMENDED strong enough? =20
> >"conventional wisdom" is that A6 has been deprecated, while
> >3363 makes it experimental.  Perhaps the node requirements should say=20
> >SHOULD NOT implement A6.
> 
> I didn't give this an issue, as I think this is according to 2119 language.

tn: no change. "NOT RECOMMENDED" is equivalent to "SHOULD NOT".

> >7.1.1 - typo - update ref in title to 4213
> 
> Issue 10: I think this should be fixed.

tn: Done, but it causes the line to wrap.

> >8. - update ref to RFC 3776 to add RFC 4877 as well.  (updates 3776 for
> >4301 architecture)
> 
> Issue 11: Yup, this should be fixed.

tn: done.

---

From: <[email-masked]>
Date: Mon, 20 Jul 2009 15:55:13 -0500

Thomas,

>   standards track RFCs is stateless autoconf mandated. This takes us

How about RFC 2462?  Standards Track - IPv6 Stateless Address Autoconfiguration.

Regards,
Greg Rabil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Monday, July 20, 2009 4:26 PM
To: [email-masked]
Subject: Node requirements: draft-ietf-6man-node-req-bis-03.txt

Hi.

They include:

Thomas

tn: done.

> Issue 11: Yup, this should be fixed.

tn: done.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Mon, 20 Jul 2009 17:10:14 -0400

> How about RFC 2462?  Standards Track - IPv6 Stateless Address

My point is that nowhere in 2462 (or any other standards track RFC) is
it mandated that a host MUST implement 2462. 2462 (like most IETF
standards) is completely optional to implement. The Node Requirements
RFC arguably does not have authority to make 2462 mandatory to
implement. At least, not while it is an informational document and
says:

> 2.  Introduction
> 
>    The goal of this document is to define the common functionality
>    required from both IPv6 hosts and routers.  Many IPv6 nodes will
>    implement optional or additional features, but this document
>    summarizes requirements from other published Standards Track
>    documents in one place.

How's this to drive the point home further... 2461 (Neighbor
Discovery) is NOT mandated. It is only listed as a SHOULD. (This is
because some link layers might not need all parts of ND. But this has
turned out to be bizarre because the important LLs do require ND, so
it effectively is a requirement.)

Of course, 2462 is widely implemented, and I'd strongly recommend that
devices should implement it (though I can think of some
exceptions). But we do have a fundmanental question about whether the
IPv6 Node Requirements document can make new requirements that are not
already in place in existing standards track documents.

Thomas

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 20 Jul 2009 17:58:13 -0400

> From: Thomas Narten [mailto:[email-masked]] 

> it effectively is a requirement.)

So perhaps some guidance on the attributes of the LL which make ND a
requirement should be included?

> already in place in existing standards track documents.

It is not entirely illogical to have multiple RFCs that describe
different aspects of IPv6, different possible tools in the toolchest
(such as DHCP, ND, and IPsec), and then one RFC that specifies the
minimal set of these tools that each category of IPv6 node must
implement. Something analogous to RFC 1122, for IPv6.

The title of the RFC, IPv6 Node Requirements, certainly implies that
this is its function. And furthermore, that's how some organizations,
such as DoD, have used the RFC.

To turn the question around, what is the purpose of RFC 4294, if not "to
define the common functionality required from both IPv6 hosts and
routers"? Seems to me that the mandatory and optional ingredients in
IPv6 nodes are likely to change in time, and that it is far easier for a
system designer to look through the requirments in one RFC than it is to
try to interpret the intent of multiple RFCs.

Bert

---

From: Bob Hinden <[email-masked]>
Date: Mon, 20 Jul 2009 17:14:16 -0700

Thomas,

Firstly, thanks for taking this on!

> already in place in existing standards track documents.

I think it is useful for IPv6 Node Requirements define what we expect  
an IPv6 node to do.  This is generally useful for the community and I  
think it was one of the reasons to write the document in the first  
place.

Regarding the status of the document, perhaps we should first decide  
what we want the document to do, such as saying that 2462 SHOULD be  
implemented, and make new requirements for nodes for things that have  
been developed since the original IPv6 node requirements was written  
(e.g., the extensions to RA flags).  Then we can decide what status  
the document should have.  If it needs to be standards track, we will  
have justification for doing that.  That is, let's keep our focus on  
what we expect to be in most IPv6 nodes.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Jul 2009 13:29:07 +1200

>    document can update any existing RFC

There's a standards-track beast defined in section 3.2 of RFC2026 as an
"Applicability Statement":

"  An Applicability Statement specifies how, and under what
   circumstances, one or more TSs [technical specifications] may be applied to support a particular
   Internet capability.
   ...
   An AS also specifies the circumstances in which the use
   of a particular TS is required, recommended, or elective..."

I think we can choose, if we want, to make the present document
an "Applicability Statement" Proposed Standard or BCP that describes
the functionality of a full-spec IPv6 node, and therefore elevates
MAY to SHOULD or MUST if we want to.

Personally, I think that's a good idea, rather than issuing an informational
document that leaves wiggle room on basics such as ND.

    Brian

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 21 Jul 2009 11:00:09 +0200

Hi all,

it would be nice to have a stronger position wether it is a guidance or
requirement doc. The point is the authority to which manufacturers refer
to prove that their nodes are IPv6 capable is not RFC4294 but the IPv6
ready logo program. the IPv6 ready certification also does not follow
100% RFC 4294: first, profiles are defined (phase 1, 2, 3), then in each
of them some points differ from RFC4294: e.g. in phase 2 PMTU discovery
is mandated, (not a SHOULD), in phase 1 and 2 IPSec is not mandated.

Does it make sense to define profiles (which others do anyway, like
DoD), and if not is it feasible to find a common denominator (to all
device and all LL) that makes sense and is not too limited. If some LL
cannot afford ND, does mandating ND make sense?

Best,
Julien

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: mardi 21 juillet 2009 03:29
> To: Thomas Narten
> Cc: [email-masked]
> Subject: Re: Node requirements: draft-ietf-6man-node-req-bis-03.txt
> 
> 
> There's a standards-track beast defined in section 3.2 of 
> RFC2026 as an "Applicability Statement":
> 
> I think we can choose, if we want, to make the present 
> document an "Applicability Statement" Proposed Standard or 
> BCP that describes the functionality of a full-spec IPv6 
> node, and therefore elevates MAY to SHOULD or MUST if we want to.
> 
> Personally, I think that's a good idea, rather than issuing 
> an informational document that leaves wiggle room on basics 
> such as ND.
> 
>     Brian
>

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Jul 2009 14:32:10 +0100

A handful of comments.

Perhaps Section 12 of any -04 version can update it's 'open issue'
list to reflect what's below and anything else on the table?  And
are we content that the other things listed currently in section 12 
have been answered?

Can we say anything stronger for MLDv2 support?  It is frustrating 
to be in a campus deployment where one notable vendor continues to
not provide this - encouragement would be welcome.  

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.

There's a couple of newish RA-related RFCs out that may be relevant, 
though one is experimental: RFC 5006 (perhaps relevant in 6.2.2 of 
the node requirements draft) and RFC 5075.

Was there agreement or not to list various IPv6-over-Foo documents?
There's now also RFC 5121.

Tim

-- 
Tim

---

From: Bob Hinden <[email-masked]>
Date: Tue, 21 Jul 2009 11:25:41 -0700

Brian,

> document that leaves wiggle room on basics such as ND.

That would work for me.

Bob

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Jul 2009 17:36:11 -0400

> 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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Jul 2009 17:46:11 -0400

> the node requirements draft) and RFC 5075.

There was a thread previously about adding RFC 5006 to the document
(originally Issue 5).  See the archives starting at
http://www.ietf.org/mail-archive/web/ipv6/current/msg09984.html

I don't see the discussion as having closed on this issue yet.

What do people want said about this one?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Jul 2009 17:47:04 -0400

Tim Chown <[email-masked]> writes:

> Can we say anything stronger for MLDv2 support?

What is it you want to have said?

> It is frustrating to be in a campus deployment where one notable
> vendor continues to not provide this - encouragement would be
> welcome.

Can you be more specific? Is it not providing multicast support? or
MLDv1 instead of MLDv2? What is the problem you want better text to
fix?

(I do want to tweak the existing text again, even though I think I
drafted it, it still doesn't seem quite right to me, but I'm not sure
how that relates to your specific issue.)

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Jul 2009 17:55:09 -0400

> the node requirements draft) and RFC 5075.

We should mention RFC 5075/5175.

I came up with some text while thinking about this document a while
back, but I can't find it right off.  Oh. I alredy snuck it into the
document! :-)

Does the following make sense:

   5.3.  IPv6 Router Advertisement Flags Option - RFC 5175

   Router Advertisements include an 8-bit field of single-bit Router
   Advertisement flags.  The Router Advertisement Flags Option extends
   the number of available flag bits by 48 bits.  At the time of this
   writing, 6 of the original 8 bit flags have been assigned, while 2
   are available for future assignment.  No flags have been defined that
   make use of the new option, and thus strictly speaking, there is no
   requirement to implement the option today.  However, implementations
   that are able to pass unrecognized options to a higher level entity
   that may be able to understand them (e.g., a user-level process using
   a "raw socket" facility), MAY take steps to handle the option in
   anticipation of a future usage.

I really don't think we should require folks implement this option,
given it is not yet in use, and it may be years before any such bits
are assigned.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Jul 2009 18:01:31 -0400

> There's now also RFC 5121.

I think there was agreement for this, or at least, BrianC agreed with
me and no one else opposed.

E.g., see the thread starting around:
http://www.ietf.org/mail-archive/web/ipv6/current/msg10023.html

I will make the change, unless someone objects.

Thomas

---

From: <[email-masked]>
Date: Thu, 23 Jul 2009 04:25:39 +0200

I would support Applicability Statement status as that would give us more room to make some recommendations on specifications outside of the core set of IPv6 standards.  If you look at what Tim is asking for MLDv2, others are asking for SeND/CGA, etc. - I think it makes a lot of sense ot have a document that can give more guidence than just informational. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Brian E Carpenter
Sent: Monday, July 20, 2009 9:29 PM
To: Thomas Narten
Cc: [email-masked]
Subject: Re: Node requirements: draft-ietf-6man-node-req-bis-03.txt

>    document can update any existing RFC

There's a standards-track beast defined in section 3.2 of RFC2026 as an "Applicability Statement":

I think we can choose, if we want, to make the present document an "Applicability Statement" Proposed Standard or BCP that describes the functionality of a full-spec IPv6 node, and therefore elevates MAY to SHOULD or MUST if we want to.

Personally, I think that's a good idea, rather than issuing an informational document that leaves wiggle room on basics such as ND.

    Brian

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 22 Jul 2009 19:59:37 -0700

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

> Sent: Tuesday, July 21, 2009 2:36 PM
> To: [email-masked]
> Subject: Node Requirements: Issue 13 - CGA/SeND support
>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 23 Jul 2009 13:45:37 +1000

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

---

From: <[email-masked]>
Date: Thu, 23 Jul 2009 06:03:02 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Hesham Soliman
Sent: Wednesday, July 22, 2009 11:46 PM
To: Laganier, Julien; Thomas Narten; [email-masked]
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" <[email-masked]> wrote:

> Just for the sake of getting the discussion started, I drafted some 
> text we can discuss:
>

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 22 Jul 2009 21:29:22 -0700

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 <[email-masked]> 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
> 
> 
> text
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> >> Thomas Narten

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 22 Jul 2009 21:32:07 -0700

John,

I think the node can know this in a number of situations, and if it doesn't, it can still use SEND in mixed mode which would let the node issue SEND protected ND signaling, while accepting both SEND-protected and unprotected ND signaling.

But the question you're asking is indeed a good one: is SEND a basic feature of IPv6 that all nodes SHOULD support. Probably we should try to answer this before entering into the details of when to use it or not.

--julien

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 22, 2009 9:03 PM
> To: [email-masked]; Laganier, Julien; [email-masked];
> [email-masked]
> Subject: RE: Node Requirements: Issue 13 - CGA/SeND support
> 
> 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
> 
> 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.
> 
> >> Of Thomas Narten

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2009 16:31:52 +1200

What information do we have from the real world about deployability?

It would be foolish to mandate something that doesn't work well.

   Brian

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 23 Jul 2009 14:30:21 +1000

Hi John, 
 I think it needs to be a should.

Hesham

> 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 
> 
> 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
> 
>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 23 Jul 2009 14:32:12 +1000

On 23/07/09 2:29 PM, "Laganier, Julien" <[email-masked]> wrote:

> 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),

=> Agreed.

> 
> 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,

=> Not sure about that. What does PPP tell you about a 3G link? Nothing
useful. Ideally, there should be such API and it is there in some cases but
not all.

Hesham

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 23 Jul 2009 15:10:10 +0800

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian
> E Carpenter
> Sent: Thursday, July 23, 2009 12:32 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
thing
> once the SeND process starts. Do people feel that SeND should be a basic
feature
> of IPv6 that all nodes SHOULD support?
> >
> > John
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext
> Hesham Soliman
know.

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Jul 2009 09:20:07 +0200

Julien,

>       as over wireless) and attacks on NDP are a concern.

Excellent IMHO.
Full support

>    authentication of the link end-points and data origin integrity  

This seems to me redundant in view of previous sentences, and  
unnecessarily subject to debate.
I suggest to just delete this one.

Regards,
RD

---

From: Hongyu Li <[email-masked]>
Date: Thu, 23 Jul 2009 16:52:16 +0800

I would support this. SeND is useful in some case, but not necessary for all cases. It would be helpful to say when it is SHOULD or
MAY be used.

Hongyu

> Behalf Of Laganier, Julien
> Sent: Thursday, July 23, 2009 11:00 AM
> To: Thomas Narten; [email-masked]
> Just for the sake of getting the discussion started, I 
> drafted some text we can discuss:
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 23 Jul 2009 09:00:12 -0400

> It would be foolish to mandate something that doesn't work well.

I think these are key questions we need to think hard about.

As far as I can tell, SEND has not been implemented in any real
product or major distribution. (It would be good to find out what
implementations have been done and where they have been used.)

More importantly, I don't believe we have any significant operational
experience with the technology. We don't know if the current specs are
sufficient to implement and operate SEND on real networks.

Finally, SEND is new technology, in that there is no IPv4
counterpart. So it isn't just an IPv6 version of something that we
know works fine in IPv4. So again, we should be cautious in how
strongly we recommend its usage. The fact that IPv4 does not have a
SEND equivalent suggests that SEND is not critical technology that
needs to be widely implemented in order for IPv6 to be useful.

There is also a Cga & Send maIntenance (csi) WG that is working on
some SEND extensions, including developing X.509 certificate
management tools that presumably will help in making SEND more
deployable operationally.

This all leads me to conclude that the node requirements doc should
not make SEND even a SHOULD. Ideally, somewhere between a MAY and
SHOULD. I'd love to see SEND implemented and deployed (so we can
figure out how well it works and fix any shortcomings), but I think it
is premature to recommend its implementation an all nodes.

Thomas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 15:12:47 +0200

> implementations have been done and where they have been used.)

FWIW, send is available in junos

http://www.juniper.net/techpubs/en_US/junos9.3/information-products/topic-collections/release-notes/9.3/m-mx-t-series-new-features.html 

http://www.juniper.net/techpubs/software/junos/junos93/swconfig-routing/secure-neighbor-discovery-configuration-guidelines.html

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 24 Jul 2009 09:43:16 +0200

Hi,

> is premature to recommend its implementation an all nodes.

+1

Some implementations have been done, which provided some feedback on the
specification (padding in Signature Option, ...) but the main issue IMHO
is the lack of feedback from a deployment standpoint (router load,
certificates deployment and maintenance, ...).

Even if some vendors have various levels of support for the protocol in
their routers, there is no major client OS providing a good level of
support for the protocol: not available yet in Windows or OS X,
available in FreeBSD via the ports (DoCoMo implementation, no upstream
maintainer), externally available for Debian, not available in Ubuntu or
RedHat ... 

Cheers,

a+

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 24 Jul 2009 13:14:29 +0200

On Fri, 24 Jul 2009 09:43:16 +0200, [email-masked] (Arnaud Ebalard)
> maintainer), externally available for Debian, not available in Ubuntu or

IIRC, the DoCoMo implementation is basically a proof-of-concept-grade hack.
It works with user-space packet filtering hooks, instead of being built
into the real IPv6 neighbor discovery code.

SeND is theoretically not easy to deploy - you need to provision
cryptography material on all nodes. That implementations are not even
properly integrated into operating systems makes it worse. I somewhat
expect that somewhat secure networks will use network-side filtering as is
done for ARP instead, as it requires no host-side changes.

I don't think it deserves a "SHOULD" at this point.

-- 
Rémi Denis-Courmont

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 24 Jul 2009 13:07:55 +0200

Hi,

> http://www.juniper.net/techpubs/software/junos/junos93/swconfig-routing/secure-neighbor-discovery-configuration-guidelines.html 

Perhaps it's just the documentation (or me) but there is nothing about
the use of certificates for routers or CPS/CPA messages, which tend to
let me think that part of the spec is not supported.

Cheers,

a+

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 24 Jul 2009 13:36:31 +0200

Hi Rémi,

> into the real IPv6 neighbor discovery code.

Your IIRC is valid. It uses libnetfilter_queue to access the interesting
ICMPv6 packets (RS, RA, NS, NA and redirect) from userspace (INPUT and
OUTPUT). Based on configuration, the packets are checked or mangled, and
possibly passed back to the firewall to continue their journey.

I don't think the daemon is ready for prime time but the idea of doing
things in userland is not completely broken. It has some advantages. At
least, I kind of hope we will never have X.509 Cert handling and ASN.1
parsing in the kernel. 

Cheers,

a+

---

From: Ana Kukec <[email-masked]>
Date: Fri, 24 Jul 2009 13:54:15 +0200

> done for ARP instead, as it requires no host-side changes.

DoCoMo's implementation is not properly integrated into operating 
systems, but IMO that is not the case with other implementations. As you 
have mentioned, DoCoMo's SeND uses Berkley Packet Filter to divert SeND 
traffic from kernel to a userland daemon, and vice versa; which means 
that (1) all network traffic (both SeND and non-SeND) has to traverse 
through the filter and (2) netgraph subsystems (that is not available in 
all operating systems). But this will be fixed soon -- the 
implementation that i am working on, within the FreeBSD community, will 
introduce the native kernel APIs for SeND for *BSDs. The code will be 
partially built into the real ND code in kernel, except part of the 
cryptographic processing that will remain in the user land.

What i am trying to say is that there are serious SeND implementations. 
IMO, we just lack for the interoperability testing results.

Ana

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 24 Jul 2009 23:40:14 +1000

> cryptography material on all nodes.

=> Why? You only need to provision routers if you want them to support proof
of prefix ownership, but you certainly don't need to provision all nodes,
that's the advantage of CGAs.

Hesham

That implementations are not even

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 24 Jul 2009 15:54:23 +0200

> that's the advantage of CGAs.
That's true for CGA, but not for router authorization. Any node that 
want to verify router authorization need to be provisionned with the 
anchor certificate.
Eric

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 24 Jul 2009 15:52:47 +0200

Hi Hesham,

> that's the advantage of CGAs.

What's the point of SEND *for authenticating routers* if you use only
CGA and not certificates? And if you use certificates, then nodes need
to be provided with trust anchors. Or am I missing your point?

Cheers,

a+

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 24 Jul 2009 16:07:03 +0200

On Fri, 24 Jul 2009 23:40:14 +1000, Hesham Soliman
<[email-masked]> wrote:
> => Why? You only need to provision routers if you want them to support
> proof of prefix ownership, but you certainly don't need to provision
> all nodes, that's the advantage of CGAs.

First, you need a trust anchor to verify. Trust cannot be bootstrapped out
of nothing, or I missed something?

As far CGAs, they require a "postcard" IPR license from Microsoft:
https://datatracker.ietf.org/ipr/676/
which -I assume- makes them legally incompatible with the Linux IPv6 stack
in USA.

-- 
Rémi Denis-Courmont

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Jul 2009 00:18:36 +1000

On 25/07/09 12:07 AM, "Rémi Denis-Courmont" <[email-masked]> wrote:

On Fri, 24 Jul 2009 23:40:14 +1000, Hesham Soliman
<[email-masked]>

=> I'm clearly not talking about routers. You said that you need to
configure "all nodes" that's simply not true for proving address ownership,
that's why we use CGAs, to avoid bootstrapping trust.

As far CGAs, they require a "postcard"
> IPR license from Microsoft:
which -I
> assume- makes them legally incompatible with the Linux IPv6 stack
in USA.

=> Completely different issue, which is clearly understood by all those OSs
supporting SeND.

Hesham 

-- 
Rémi 
> Denis-Courmont

--------------------------------------------------------------
> ------
Administrative
> Requests: 
> https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------
> ---------------------------------

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 24 Jul 2009 23:57:16 +1000

> want to verify router authorization need to be provisionned with the

=> Yes of course. 

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 24 Jul 2009 23:56:47 +1000

On 24/07/09 11:52 PM, "Arnaud Ebalard" <[email-masked]> wrote:

> What's the point of SEND *for authenticating routers*

=> SeND is not only for authenticating routers, in fact that particular
function was done last. It's about address ownership, which couldn't be done
without CGAs. 

  if you use only
> to be provided with trust anchors. Or am I missing your point?

=> I think so, you don't need to provision hosts with anything to allow them
to prove that they own an address. That's the whole point of CGAs. Prefixes
are a different story of course.

Hesham