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

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

Hello again folks,

> Proposed text:
> 
> - Add at the end of section 2 (as Section 2.1) - or as section 3.6
> 
>   2.1 Handling of Solicited Agent Advertisements.
> 
>     When a foreign agent generates an Agent Advertisement in response to
>     a Router Solicitation [4], some additional considerations come into
>     play.  According to the Mobile IP base specification [7], the
>     resulting Agent Advertisement may be either multicast or unicast.
>     However, a foreign agent which provides challenge handling according
>     to this document is restricted to only respond with unicast agent
>     advertisements in response to a router solicitation.

This seems O.K.
 
>     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.

> - In section 3.2, change
> 
>   From:
>      The Foreign Agent MUST NOT accept any Challenge in the Registration
>      Request unless it was offered in last Registration Reply issued
>      to the Mobile Node, or else advertised as one of the last
>      CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
>      immediately preceding Agent advertisements.
> 
>   To:
>      The Foreign Agent MUST NOT accept any Challenge in the Registration
>      Request unless it was offered in the last Registration Reply or
>      unicast Agent Advertisement sent to the Mobile Node, or else
>      advertised as one of the last CHALLENGE_WINDOW (see section 9)
>      Challenge values inserted into the immediately preceding Agent
>      advertisements.

Looks O.K.

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

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

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

> - In Appendix E, change the second paragraph
> 
>   From:
> 
>     In the program fragment, it is presumed that the foreign agent
>     keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a
>     record of the last advertised challenge used by a mobile node, and
>     also a record of the last challenge provided to a mobile node in a
>     Registration Reply.
> 
>   To:
> 
>     In the program fragment, it is presumed that the foreign agent keeps
>     an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record
>     of the last advertised challenge used by a mobile node, and also a
>     record of the last challenge provided to a mobile node in a
>     Registration Reply or unicast Agent Advertisement.

This seems O.K.


Regards,
Charlie P.

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