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