Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Jan 2005 10:39:15 -0800 (PST)

[This got stuck in my outbox]

>                                 - a time that decrements in real time,
>                                   that is, one that will result in a
>                                   Lifetime of zero at the specified
>                                   time in the future, or
> 
>                                 - a fixed time that stays the same in
>                                   consecutive advertisements.
> 
> ==> AFAIK, the first option has not been implemented; I've at least not seen
> in done.  Therefore unless someone shows that there are two implementations
> of this, this must be removed. (The same for AdvPreferredLifetime, and a bit
> in section 6.2.7.)

FWIW This is implemented in Solaris 8 and later.
I don't know if there is an second independent implementation though.

>        Note: Implementations can choose to process the on-link aspects of
>        the prefixes separately from the address autoconfiguration aspects
>        of the prefixes by, e.g., passing a copy of each valid Router
>        Advertisement message to both an "on-link" and an "addrconf"
>        function.  Each function can then operate independently on the
>        prefixes that have the appropriate flag set.
> 
> ==> similar to above, has this been implemented ?  Not a as big issue as
> above for me, because this is just an implementation note.

As you say this is an implementation note. But it also attempts to
re-emphasize  the fact that the "on-link" and "addrconf" aspects of a prefix
information option are completely independent.

>     A proxy MAY multicast Neighbor Advertisements when its link-layer
>     address changes or when it is configured (by system management or
>     other mechanisms) to proxy for an address.  If there are multiple
>     nodes that are providing proxy services for the same set of addresses
>     the proxies SHOULD provide a mechanism that prevents multiple proxies
>     from multicasting advertisements for any one address, in order to
>     reduce the risk of excessive multicast traffic.
> 
> ==> does anyone implement this SHOULD?  Note that this does not give hints
> how to even go about doing that.  If not, remove.

It is an odd "SHOULD" in that it doesn't add a requirement on implemetors of
ND, but instead states a requirement on some potential other protocol which
uses proxy NAs.
But I do think that MIPv6 is an example of this. Even with multiple Home Agents
on the same home link, MIPv6 ensures that only one home agent performs proxy ND
for a given home address.

>       Inbound load balancing - Nodes with replicated interfaces may want
>             to load balance the reception of incoming packets across
>             multiple network interfaces on the same link.  Such nodes
>             have multiple link-layer addresses assigned to the same
>             interface.  For example, a single network driver could
>             represent multiple network interface cards as a single
>             logical interface having multiple link-layer addresses.
> 
>             Load balancing is handled by allowing routers to omit the
>             source link-layer address from Router Advertisement packets,
> [...]
> 
> ==> this is conflicting.  The first para discusses generic inbound load
> balancing, the second load balancing that applies only to routers w/ RAs. 
> How do hosts perform inbound load balancing?  Needs text tweaking..

Leaving the first paragraph as is, since it is basically explaining the term,
and adding something before the second paragraph that "Neighbor Discovery
allows a router to load balance traffic towards itself if the router has
multiple MAC addresses by ..."

>        Unlike in IPv4 Router Discovery the Router Advertisement messages
>        do not contain a preference field.  The preference field is not
>        needed to handle routers of different "stability"; the Neighbor
>        Unreachability Detection will detect dead routers and switch to a
>        working one.
> 
> ==> preference has been plugged back, though not for stability 
> reasons. I'd suggest just removing this paragraph.

I'm not sure removing aids in clarity for folks that come from the IPv4 word.
In ICMP router discovery, part of the reason for the preference field was
to handle routers with different stability, and that reason isn't present here
due to NUD. The fact that we've seen a need to introduce preferences for other
purposes is separate from that explanation.
So perhaps adding a note that preferences can be useful for other purposes
with a non-normative reference to the new spec would make sense.

> For instance, a
>     mobile node, using [MIPv6], moving to a new link would need to
>     discover such movement as soon as possible to minimize the amount of
>     packet losses resulting from the change in its topological movement.
>     Router Solicitations provide a useful tool for movement detection in
>     Mobile IPv6 as they allow mobile nodes to determine movement to new
>     links. Hence, if a mobile node received link layer information
>     indicating that movement might have taken place, it MAY send a Router
>     Solicitation immediately, without random delays. The strength of such
>     indications should be assessed by the mobile node's implementation
>     and is outside the scope of this specification.
> 
> ==> it might not hurt to discuss the potential pitfalls of this approach
> somewhere.  For example, n case the link indications are shaky, or just
> hints, and there is a significant number of MNs on a link, this could result
> in an RS storm.

Or at least clearly state the assumption that
1) this is only performed as part of a suspected movement
2) suspected movements are assumed to be uncorrelated between different hosts
   i.e. we assume that a trainload of wireless laptops wouldn't all detect 
   movement and send a RS at the same time
3) the 2) assumption might not be true in all cases

> ==> AFAICS, you can remove 'both the Override flag is clear and' here,
> because the same result happens if the Override flag is set.

No. The "but do not update the entry in any other way" does not apply when the
O  flag is set, since in that case the recorded link layer address is updated.

>     A router MUST limit the rate at which Redirect messages are sent, in
>     order to limit the bandwidth and processing costs incurred by the
>     Redirect messages when the source does not correctly respond to the
>     Redirects, or the source chooses to ignore unauthenticated Redirect
>     messages.  More details on the rate-limiting of ICMP error messages
>     can be found in [ICMPv6].
> 
> ==> 'or the source chooses to ignore unauthenticated Redirect
>     messages' smells quite a bit from a leftover of IPsec AH times.  Reword?

Can't SeND nodes choose to ignore redirects that aren't protected by SeND?

>     An example of denial of service attacks is that a node on the link
>     that can send packets with an arbitrary IP source address can both
>     advertise itself as a default router and also send "forged" Router
>     Advertisement messages that immediately time out all other default
>     routers as well as all on-link prefixes.
> 
> ==> 'on-link' is not accurate.  Using these mechanisms, you can't capture
> _all_ on-link traffic as that goes between the nodes.  You can capture that
> e.g. by advertising more specifics in RAs, with NA/ND spoofing, etc., but
> the sentence does not seem to be 100% correct.

What's the bug? If there are no on-link prefixes advertised, then the host will
send all packets to a default router. So if an attacker sends RAs with a zero
valid lifetime for all the prefixes and a zero default router lifetime for all
the routers, and advertises itself as a default router, then all packets will
be sent to that spoofed router. So I think the text is correct.

   Erik

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jan 2005 20:51:29 +0200 (EET)

> for a given home address.

Even more reason to remove it from here, unless it has been 
implemented (I haven't seen it for sure -- doing it robustly is pretty 
difficult).

> multiple MAC addresses by ..."

This does not address the point because Neighbor Discovery allows a 
_host_ to load balance incoming traffic as well ?

> with a non-normative reference to the new spec would make sense.

Fine with me.

> 3) the 2) assumption might not be true in all cases

Works for me.

> Can't SeND nodes choose to ignore redirects that aren't protected by SeND?

Sure.  I was just referring this editorially, that "unauthenticated" 
is often an overloaded term, referring to IPsec AH..

> be sent to that spoofed router. So I think the text is correct.

That approach is correct, but beacause the "two hour rule" applies to 
the on-link prefixes, it's not "immediately".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Jan 2005 11:07:43 -0800

Pekka Savola wrote:

> Even more reason to remove it from here, unless it has been implemented 
> (I haven't seen it for sure -- doing it robustly is pretty difficult).

As I said above, I think the MIPv6 RFC is the "implementation" in this 
case. But it does make sense to clarify that the text is about a 
requirement on other protocols which use proxy ND.

> _host_ to load balance incoming traffic as well ?

Sorry, I can't understand how your comment relates to mine.
We can make the text be more clear that the first paragraph 
explains/defines the term, and the above addition to the second 
paragraph. Wouldn't that work?

> Sure.  I was just referring this editorially, that "unauthenticated" is 
> often an overloaded term, referring to IPsec AH..

But here the fact that it doesn't specify how it is authenticated is a 
feature; if there is a new ND authentication scheme we want this to 
apply there as well.

And I don't think the anti-spam folks mean IPsec AH when they say 
"authenticated email" :-)

> the on-link prefixes, it's not "immediately".

That apparently a commonly held misunderstanding. The 2 hour rule only 
applies two stateless address autoconfiguration only. (It is only in RFC 
2462, not in 2461.)

    Erik

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 13 Jan 2005 14:28:27 -0500 (EST)

Hi Pekka,

On Thu, 13 Jan 2005, Pekka Savola wrote:
...<snipped>...
>the on-link prefixes, it's not "immediately".

Not really. This two hour minimum applies only to stateless autoconf.

Cheers
Suresh

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 14 Jan 2005 14:48:33 +0900

>>>>> On Thu, 13 Jan 2005 10:39:15 -0800 (PST), 
>>>>> Erik Nordmark <[email-masked]> said:

> I don't know if there is an second independent implementation though.

KAME/BSD also implements the former type of lifetimes (although the
current implementation cannot specify the expiration time for this
type of lifetimes.  It can only specify whether the lifetime
decrements in real time).

BTW: do we really need this level of detailed inspection to meet the
two-implementation requirement for a DS?  When I raised a similar
question when we discussed how we should deal with the M/O flags in
rfc2462bis wrt this requirement, I was told that we usually only
require a rougher level (e.g. whether there are more than two
implementations that support NS/NA/RA/RS/Redirect messages without
requiring line-by-line conformance to the corresponding RFC).  I
personally prefer detailed inspection (if we can do that within a
reasonable period), but I can live with the rougher version as a
real-world compromise.  In any case, we should basically be consistent
on the requirement level not to make a double-standard.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Jan 2005 08:51:28 +0200 (EET)

On Fri, 14 Jan 2005, JINMEI Tatuya / [ISO-2022-JP] ¿ÀÌÀÃ£ºÈ wrote:
> two-implementation requirement for a DS?

That is a matter of interpretation.  Traditionally, the ADs have not 
required them, but personally I think the spirit of the policy 
requires them.

For what it's worth, why I'm asking these is because IMHO it's very 
important that the spec mirrors what's implemented (or what we believe 
definitely must be implemented).  It seems to me that at places the 
gap between implementations and the spec has gotten wider.  The big 
point of DS/FS is to evaluate that gap and do something about it.

One way to do that would be remove some of the more rarery implemented 
statements from the spec or change their requirement level from SHOULD 
to MAY, MUST to SHOULD, etc.

---

From: Tim Hartrick <[email-masked]>
Date: 14 Jan 2005 10:50:36 -0800

Jinmei,

> on the requirement level not to make a double-standard.

In my opinion we do not need this level of detail.  I think that the
current discussion of removal of unimplemented or not widely implemented
implementation options is overkill.

Tim Hartrick
Mentat Inc.