Subject: Re: I-D ACTION:draft-mkhalil-ipv6-fastra-00.txt

From: Pekka Savola <[email-masked]>
Date: Wed, 1 May 2002 17:55:20 +0300 (EEST)

On Mon, 29 Apr 2002 [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: IPv6 Fast Router Advertisement
> 	Author(s)	: J. Kempf, M. Khalil, B. Pentland
> 	Filename	: draft-mkhalil-ipv6-fastra-00.txt
> 	Pages		: 3
> 	Date		: 26-Apr-02
> 	
> This document specifies an amendment to the router solicitation
> handling procedures in RFC 2461 that allow for improved default 
> router aquisition performance when an active IP host moves from
> one subnet to another.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-00.txt

I'm not sure how this ended up Cc:'ed to ipng but anyway..

A few comments:

3.0 Processing Router Solicitations

   A router that is configured to provide fast RAs MUST maintain a
   counter, FastRACounter, of the fast RAs sent since the last
   unsolicited multicast RA was sent. when an RS is received, an
   RA MUST be sent immediately if:

                FastRACounter <= MAX_FAST_RAS

==> I think the wording should be much more clear on what exactly is a 
router configured to provide fast RAs, especially if it _MUST_ send fast 
RA's in contradiction to the current specification.

   A router SHOULD choose to unicast the response directly to the 
   soliciting host's address (if the solicitation's source address
   is not the unspecified address), otherwise the router MUST schedule
   a multicast Router Advertisement in accordance with RFC 2461.

==> Clarification: if the router would not schedule an RA by RFC 2461
(e.g. skip the scheduling to prevent DoS)

==> Using unicast was a MAY.  I think there should be some discussion why 
this should be changed.

 When the multicast RA has been sent, FastRACounter
   MUST be reset to zero and processing for fast RAs recommences.

[and]

4.0 Security Considerations

   This draft specifies a minor modification to RFC 2461. There are no 
   considerations for this draft.

==> please have a look at:

http://search.ietf.org/internet-drafts/draft-rescorla-sec-cons-05.txt

At the very least, 100 Fast RA's per multicast unsolicited interval, 
the minimum decreased by MIPv6 to 0.05 seconds: potentially about 2,000 
RA's from a router a second.  Potential DoS?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Wed, 1 May 2002 09:03:37 -0700

HI Pekka,

> I'm not sure how this ended up Cc:'ed to ipng but anyway..

IPNG would be the logical working group that would take it on I think,
since it involves a change in RFC 2461.

> RA's in contradiction to the current specification.

The previous paragraph states what a fast RA is namely:

   An RA that is immediately
   unicast to the sender rather than delayed
   is known as a "fast RA".

As to what it means for a router to be configured to provide fast RAs,
it means
that the router disposes of RSs as described. I guess we could make that
a little clearer.

> (e.g. skip the scheduling to prevent DoS)

I don't understand the problem. Are you concerned that the router will
be
bombarded by RSs with the unspecified address? RFC 2461 contains
explicit instructions about the timing of multicast RAs, so I don't see
what the threat is.

> ==> Using unicast was a MAY.  I think there should be some discussion
why

I suppose we could make it a MAY, but this draft is in the context of an
enhancement to RFC 2461 and is, itself, a MAY.
Within the context of this draft, it seems as if SHOULD should work,
since it will remain MAY in the context of RFC 2461.

> RA's from a router a second.  Potential DoS?

I'll check the reference, but I'm not sure I understand your point. An
attacker can only force the router to send out up to  FastRACounter
unicast RAs before it rolls over to a multicast. We could increase the
recommended default. We could add some adaptive logic which requires the
router to continue using multicast for some period of time before
rolling back to unicast, to limit the scope of a DoS attack. Since there
is currently no security on ND, there is no way to check whether a host
sending an RS is authorized to use the link. We should probably mention
this in the Security Considerations section in any case.

            jak

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 May 2002 09:36:26 +0300 (EEST)

On Wed, 1 May 2002, James Kempf wrote:
> it means that the router disposes of RSs as described. I guess we could
> make that a little clearer.

My main concern here was how this will work on a router which supports 
fast RA's, but does not necessarily turn it on, at least on all of its 
interfaces.  Some interfaces (or even a subset of nodes attached to an 
interface) might require fast RA's, some not.

> be bombarded by RSs with the unspecified address? RFC 2461 contains

My main concern was the wording.  Let's take an example not related to RFC 
2461 to illustrate this:

Base spec says:

 - if conditions X, Y, and Z are met, schedule an event

Advanced spec says:

 - schedule an event

This is IMO not 100% specific whether advanced spec should also check for 
conditions X, Y, and Z.

Perhaps this clarifies what I was trying to say.

> since it will remain MAY in the context of RFC 2461.

Ok.

But still, some brief discussion why replying using unicast was chosen 
would to be more preferred might be useful.
 
> this in the Security Considerations section in any case.

It seemed to me that a node could get a router to send 100/0.05 == 2000 
RA's (with default settings) per second, but I may be missing something.

In any case, my main problem was not with a huge fear of DoS, but that 
Security Considerations section was hand-waved away.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 2 May 2002 08:43:08 -0700

PekkaS,

OK, I think I understand your comments now. We can incorporate them into
the draft. Thanx.

            jak

----- Original Message -----
From: "Pekka Savola" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, May 01, 2002 11:36 PM
Subject: Re: I-D ACTION:draft-mkhalil-ipv6-fastra-00.txt

> > > ==> Using unicast was a MAY.  I think there should be some
discussion