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

[Henrik Levkowetz <henrik@levkowetz.com>]

Hi Charles,

	Responding to the particular points where you had further comments:

Tuesday 19 August 2003, Charles wrote:
> Hello again folks,

[...]

>  
> >     The agent advertisement which is unicast back to the soliciting
> >     mobile node MUST be handled as follows: A new Challenge value MUST
> >     be re-generated periodically and remembered as the most recent
> >     challenge issued to the mobile node. It is RECOMMENDED that this
> >     period be on the order of 60 seconds. If the challenge most recently
> >     issued to the soliciting mobile node has not been previously used
> >     (as defined in Section 1.1), and the re-generation period has not
> >     elapsed, the most recent challenge unicast to the mobile node
> >     through a registration reply or a unicast agent advertisement SHOULD
> >     be repeated in the newly issued unicast agent advertisement. (For
> >     further discussion of this, see Section 12.)
> 
> I don't understand the need for the periodic regeneration.   Perhaps
> this is because I didn't follow all the previous discussion, but
> it seems to me that the mobile can retransmit its solicitation if
> it didn't get a challenge, and I can't think of any other reason for
> the periodic advertisement to be unicasted.

Some other people also had objections to the periodic regeneration.
It would only be necessary if the FA and mobile node had conflicting
ideas about the validity of a challenge, and even then there would be
the option of waiting for the next multicast advertisement. My impression
is that we should skip the regeneration.


[...]

> 
> > - In section 3.3, change
> > 
> >   From:
> >      The Foreign Agent SHOULD include a new Mobile-Foreign Challenge
> >      Extension in any Registration Reply, successful or not.  If the
> >      foreign agent includes this extension in a successful Registration
> >      Reply, the extension SHOULD precede a Mobile-Foreign authentication
> >      extension. Suppose the ...
> > 
> >   To:
> >      A Foreign Agent which provides challenge handling according to this
> >      document MUST include a previously unused Mobile-Foreign Challenge
> >      Extension in any Registration Reply, successful or not.  If the
> >      foreign agent includes this extension in a successful Registration
> >      Reply, the extension SHOULD precede a Mobile-Foreign authentication
> >      extension.
> 
> I don't understand why this is.  It would be especially unneeded if,
> for instance, the foreign agent had just sent a multicast Challenge value
> a few milliseconds earlier.

Yes. But then we will have to specify under which circumstances one
could omit returning a new challenge in a registration reply. The
current text has resulted in at least one implementation which never
return a new challenge with an unsuccessful registration reply, which
was one component in the observed deadlock.

> >      If the challenge most recently issued to the soliciting mobile node
> >      has not been previously used (as defined in Section 1.1), and the
> >      re-generation period (as described in section 2.1) has not elapsed,
> >      the most recent challenge unicast to the mobile node through a
> >      registration reply or a unicast agent advertisement SHOULD be
> >      repeated in the registration reply.
> 
> Here, again, I fail to see the point of the regeneration period.
> I hope someone won't mind educating me about it.

As indicated above, we don't really need it and it seems we don't have
consensus on it.

> > - Add the following at the end of Section 12:
> > 
> >     Note that an active attacker may try to prevent successful
> >     registrations by sending a large number of Agent Solicitations or
> >     bogus Registration Requests, each of which could cause the FA to
> >     respond with a fresh challenge, invalidating the challenge that the
> >     MN is currently trying to use.  To prevent such attacks, the FA
> >     SHOULD repeat the same challenge value in successive unicast
> >     responses to Agent Solicitations or in Registration Replies to
> >     Requests that did not contain valid MN-AAA or MN-FA authentication
> >     extensions for some limited period of time (on the order of 60
> >     seconds).  Note that each challenge returned to an MN MUST be
> >     previously unused by that MN.
> 
> Even better if the foreign agent allows more than one mobile node
> to use the same challenge value.  Why not?

This is the case with multicast challenges, of course. But currently we
only require the FA to remember one individual challenge per mobile
node, and if an impostor has the ability to invalidate that one (by
causing it to be replaced by a newer one) it has blocked the mobile from
succeeding in its next registration attempt.

	Regards,
		Henrik




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