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

["Charles E. Perkins" <charliep@iprg.nokia.com>]

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.

> 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...(?)

> 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.

> 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?

> Proposed text:

I'll look at this next!

Regards,
Charlie P.

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