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

Hi Jayshree,

	Comments inline.

	Regards,
		Henrik

Monday 28 July 2003, Jayshree wrote:
> Hello Henrik,
> 
> Please see my response inline.
> 
> Thanks,
> Jayshree
> 
> > -----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: 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.
> > 
> [JB] I am trying to see the difference between the "multicasted response to
> an agent solicitation" case vs "unsolicited multicasted agent
> advertisement". From the above description, it seems you agree that both
> these cases are handled in similar way. But the proposed text (section
> 2.1-second paragraph mentioned below) just talks about multicasted response
> to solicited Agent Advertisement. Why? 

Umm.. no, the proposed text (see below) for section 2.1 has 3 paragraphs, and
the third paragraph talks about the case where the response is unicast back
to the solicitor, not multicast. Or did I misunderstand you somehow?

> Also, I am not sure I agree with your
> statement regarding DOS attack since this may be the case for the
> "unsolicited multicasted agent advertisement" as well. It will be good if
> you can provide further clarification on this issue.

No, as long as an attacker cannot provoke too early removal of challenges
from the challenge window, there is no problem. Only if the attacker is
given a way to provoke premature ageing of the challenges is there a problem.
For this reason, we need to describe a way to handle solicited advertisements
which doesn't provide such a possibility. I'm not sure I understand where
we disagree?

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