PekkaS,
OK, I think I understand your comments now. We can incorporate them into
the draft. Thanx.
jak
----- Original Message -----
From: "Pekka Savola" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, May 01, 2002 11:36 PM
Subject: Re: I-D ACTION:draft-mkhalil-ipv6-fastra-00.txt
> 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]
--------------------------------------------------------------------
