Re: [Mip4] Current state of 3012bis solicited agent advertisement issue.

[Henrik Levkowetz <henrik@levkowetz.com>]

Tuesday 19 August 2003, Charles wrote:
> Henrik Levkowetz wrote:
> 
> > Background:
> > 
> > The current RFC3012 text says that an FA MAY include a new challenge in
> > any registration reply, successful or not.
> > 
> > At least one current implementation accordingly does not return a
> > challenge with the registration reply when the registration attempt for
> > some reason is unsuccessful (could be a timestamp mismatch with the HA,
> > or some other rectifiable issue with the first registration request).
> > 
> > At least one other current implementation expect an unsuccessful
> > registration reply to provide a new challenge (as the challenge used in
> > the previous registration request cannot be used again, and may have
> > been taken from the most recent unsolicited agent advertisement).
> > 
> > In this situation, these two implementations, which both follow the
> > current RFC 3012, deadlock and never can reach a successful
> > registration.
> 
> The client should NOT deadlock.  It should be able to
> use the next advertised (unsolicited) challenge.

Seems reasonable (although not explicitly described in 3012).

> > The implementation which does not supply a new challenge with an
> > unsuccessful registration reply expects an advertisement solicitation,
> > and will provide a fresh challenge in this case, but whether a fresh
> > challenge or a repeat of the most recent unsolicited multicast
> > challenge should be provided in a solicited advertisement is also not
> > specified in the current document text.
> 
> Either one should work, presumably...(?)

Either one would work for the client, but there are different pros
and cons, with some of the cons being rather disadvantageous, as
discussed earlier.

> > The discussions around this subject also brought to light a number
> > of denial of service attacks which would be possible with certain
> > ways of resolving the issues above.
> 
> I saw the one about how a client could "use" the unsolicited
> advertisements, BUT the foreign agent should not be fooled.
> In fact, a challenge used by one mobile node should still be
> able to be used by another mobile node (with a different IP
> address).  So, this does not seem like a very potent threat.

This is true for certain possible implementations of solicited
advertisements, but not for others. Obviously, we want sane
implementations of both unicast solicited advertisements and multicast
solicited advertisements (if we want to keep both kinds), so the goal of
the text clarifications which has been proposed and discussed is just
that.

One of the more disadvantageous implementations would be one where a
solicitation resulted in the generation of a new (multicast) challenge,
which would take the most recent slot of the CHALLENGE_WINDOW remembered
challenges. The lifetime of any challenge could then be severely reduced
by a malicious node soliciting with a high frequency. 

Another disadvantageous implementation would be to respond with unicast
solicited advertisements with a fresh challenge, treated in the same
manner as challenges returned to individual nodes in registration
replies. As there is only one valid such challenge remembered for each
individual node, a rogue node would then at any time be able to solicit
for a new advertisement, which would make any challenge individually
provided to the proper node earlier forgotten, i.e. invalid.

> > Here are proposed text changes for 3012bis, to ensure this deadlock
> > does not occur, and to prevent more grave denial of service attacks
> > than could occur in a non-3012bis situation. The text has been taken
> > from explicit text proposals and from the discussion notes when no
> > explicit text has been provided earlier.
> 
> But what if there isn't a deadlock situation?

Well, we observed one...

> > Proposed text:
> 
> I'll look at this next!

Right-o.

	Henrik


_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4