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. > 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. > 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. > 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. > ==> 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. > 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. jak -------------------------------------------------------------------- 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] --------------------------------------------------------------------
