On Wed, 1 May 2002, James Kempf wrote: > 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.
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. > > 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) > > > > 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. 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. > > ==> Using unicast was a MAY. I think there should be some discussion > why > > this should be changed. > > > > 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. Ok. But still, some brief discussion why replying using unicast was chosen would to be more preferred might be useful. > > 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? > > > > 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. 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. -- 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 PROTECTED] --------------------------------------------------------------------
