RE: New issue: 3012bis challenges in solicited agent advertisements

Hi Henrik,

I think the issue at hand is already addressed in the standard as follows:

1. If the Foreign Agent is RFC3012(RFC3012-bis) compliant it sends a new
Challenge in RRP and then, as you said, we wont see this issue.

2. On the other hand, it is the responsibility of the FA to ensure that the
challenge it sends is a fresh one; especially when sent to a specific MN.
RFC3012 section 2.0, requires the FA to sends a challenge that can be used
by the MN to:
   - Provide a replay protection
   - authenticate the message

"
   The Challenge extension, illustrated in figure 1, is inserted in the
   Agent Advertisements by the Foreign Agent, in order to communicate
   the latest challenge value that can be used by the mobile node
   to compute an authentication for its next registration request
   message.  The challenge is selected by the foreign agent to provide
   local assurance that the mobile node is not replaying any earlier
   registration request.  Eastlake, et al. [5] provides more information
   on generating pseudo-random numbers suitable for use as values for
   the challenge.
"

Regards,
Ahmad


> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email protected]] 
> Sent: Wednesday, July 23, 2003 10:05 AM
> To: mip4
> Cc: [email protected]; Bharatia, Jayshree 
> [RICH1:2H13:EXCH]
> Subject: [mobile-ip] New issue: 3012bis challenges in 
> solicited agent advertisements
> 
> 
> Hi,
> 
> We've had some recent interoperability experiences around 
> 3012 / 3012bis which suggest that there are some cases 
> involving solicited agent advertisements which are not 
> currently covered, and which need to be explicitly described. 
> 
> Background:
> 
>  In 3012bis, a mobility agent generates a new challenge when 
> it does an  unsolicitated agent advertisement. These 
> challenges are remembered with  a history of CHALLENGE_WINDOW 
> challenges.
> 
>  A new challenge value is also produced for individual mobile 
> nodes when  replying with a challenge in a registration 
> response. The most recently  issued challenge is remembered 
> as part of that particular mobile node's  registration data.
> 
>  The case where a mobility agent responds with an 
> advertisement in response  to a router solicitation is not 
> explicitly covered. Such advertisements  may be either 
> unicast or multicast (unsolicited advertisements are  
> multicast, not unicast).
> 
> Issues:
> 
>  * When unicasting an agent advertisement in response to an 
> agent  solicitation, should a new challenge be produced, or 
> should the most  recent challenge generated for unsolicited 
> agent advertisements be  re-sent? 
>   ( If a mobile node for some reason has already used the most recent
>   challenge sent in an unsolicited agent advertisement, and 
> the foreign
>   agent does not (in spite of the proposed SHOULD in the 
> current draft)
>   include a new challenge in it's most recent registration 
> reply, it is
>   highly advisable that the challenge in a unicast solicitated agent
>   advertisement is fresh, not a copy of an earlier advertisement
>   challenge. )  
> 	- Proposal: For unicast advertisements, generate a new 
> challenge.
> 	
>  * If a new challenge is produced for a unicast router 
> advertisement,  should it change the advertisement challenge history? 
>   ( This could open up for a DOS attack, where a MN could solicitate
>   often enough that challenges available for other MNs listening to
>   regular RAs would only be within the remembered history for a very
>   short time. )
> 	- Proposal: Do not remember challenges generated for unicast
> 	  agent advertisements as part of the advertisement challenge
> 	  history of CHALLENGE_WINDOW challenges.
> 
>  * If not, should a new challenge produced for a unicast 
> router  advertisement be used completely analogous with a new 
> challenge  returned to an individual MN in a registration response?
> 	- Proposal: Yes, treat it in the same manner as a challenge
> 	  returned in a registration reply.
> 
>  * When multicasting a response to an agent solicitation, 
> should a new  challenge be produced, or should the most 
> recent challenge generated  for unsolicited agent 
> advertisements be re-sent?
>   ( Again, updating the history of advertisement challenges here could
>   open up for a DOS attack. Furthermore, as multicast solicited agent
>   advertisements can be heard by all on the link, not only the
>   soliciter, and handled as an unsolicited advertisement, they should
>   behave in the same manner as an unsolicited advertisement. )
> 	- Proposal: When the response to a solicitation is multicast,
> 	  re-use the most recently generated advertisement 
> challenge. Do not
> 	  update or invalidate the history of advertisement challenges.
> 
> 
> 
> Proposed text:
> 
> Add at the end of section 2:
> 
> 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. 
> 
>   If the solicited Agent Advertisement is multicast, it MUST NOT
>   generate a new Challenge value and update its window of remembered
>   advertised Challenges. It must instead re-use the most recent of the
>   CHALLENGE_WINDOW Advertisement Challenge values.
> 
>   If the solicited Agent Advertisement is unicast back to the 
> soliciting
>   mobile node, it MUST be handled in the same manner as described for
>   Challenges issued in a Registration Reply.  A new Challenge value
>   MUST be generated and remembered as the most recent 
> challenge issued 
>   to the mobile node.
> 
> 
> 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.  
> 
> 
> Comments?
> 
> 	Henrik
>