Subject: [mobile-ip] New issue: 3012bis challenges in solicited agent advertisements

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 23 Jul 2003 17:04:51 +0200

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 30 Jul 2003 16:55:25 -0500

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-masked]] 
> Sent: Wednesday, July 23, 2003 10:05 AM
> To: mip4
> Cc: [email-masked]; 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 new challenge is produced for a unicast router 
> advertisement,  should it change the advertisement challenge history? 
>  * 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?
>  * 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?