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

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 6 Aug 2003 08:54:53 -0500

I am sorry for the late response.
Comments inline.

Regards,
Ahmad

Wednesday 30 July 2003, Ahmad wrote:
> 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.

No, unfortunately not. 3012bis sayst that an FA SHOULD (not MUST) provide a
new challenge in the registration reply.

<<Ahmad-START>>
Well, I do not want to go into a theoretical debate here BUT let us examine
what RFC2119 says about SHOULD:

"
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.
"
I am not sure what was the valid reason for any implementer to ignore this
one! 
Was there an understanding of the full implication here!!
<<Ahmad-END>>

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

This still does not provide any guidance on how specifically to handle
solicited agent advertisements. As we've come across this issue as an
interoperability problem in shipping implementations that follow the current
3012bis, it seems prudent to specify how to handle the situation, no?

<<Ahmad-START>>
Although, it is clearly mandates the FA to send a challenge that the MN can
use for Replay Protection/authentication.
Apparently FA can not communicate a previously used Challenge to a specific
MN. Yes?
How to implement the above is left as implementation specific and standard
should not restrict it. 

<<Ahmad-END>>

	Regards,
		Henrik

> > -----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 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: Henrik Levkowetz <[email-masked]>
Date: Wed, 6 Aug 2003 19:22:07 +0200

Hi Ahmad,

	Responding in 2 separate messages to your two comments:

> Was there an understanding of the full implication here!!

Well, the thing is, there are implementations out there which does not
return a new challenge with all registration replies. If we wish to
arrange for better interoperability, it doesn't really matter if we feel
they are wrong in not following the SHOULD, but rather that we decide
what is the behaviour needed for consistent interoperability, and
require that, no?

	Henrik

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 6 Aug 2003 19:28:06 +0200

Hi Ahmad,

	Responding to your second comment:

[...]

> How to implement the above is left as implementation specific and standard

	As long as we don't provide a specification on how to handle solicited
advertisements, and there may be both interoperability and security issues
with some of the possible implementations, I'd say that we have a flawed
standard. 

I'm sure that the present lack of text on the matter does not stem from 
a desire to leave it implementation dependent, but rather that no-one had
come across the potential problem and formulated a solution.

I believe that we should not leave this wide open and undefined.

	Henrik