[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------