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

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 31 Jul 2003 15:00:04 -0500

Henrik,

I am trying to understand the problem space of the issue you have raised on
the mailing list. At first glace, it seems the issue is related to "SHOULD"
terminology for sending the Registration Reply. But then you have mentioned
security issues associated with it. Your current proposal for the
multicasted agent advertisement (sent in response of agent solicitation) is
to reuse the challenge from the previous unsolicited agent advertisement.
It's not clear to me how this solution really solves the problem. Aging out
the challenge may not be very severe since the message has been multicasted
to other hosts as well. Also, by keeping the same challenge, the Mobile Node
will run out of challenge values for the registration.

It will be helpful if you can just explain the scenario which you are
considering and the relevant issue.

Thanks,
Jayshree

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Wednesday, July 30, 2003 3:04 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: mip4; Charles E. Perkins
> Subject: Re: [mobile-ip] Re: New issue: 3012bis challenges in 
> solicited ag ent advertisements
> 
> 
> Hi Jayshree,
> 
> 	comments inline.
> 
> 	Regards,
> 		Henrik
> 
> Wednesday 30 July 2003, Jayshree wrote:
> > Hi Henrik,
> > 
> > Please see my comments inline.
> > 
> > Thanks,
> > Jayshree
> > 
> > ...
> > > > [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?
> > > 
> > [JB] My question was related to second paragraph (section 
> 2.1) of your 
> > proposed text in which you are proposing that if the 
> solicited agent 
> > advertisement is multicasted, new challenge value must not be 
> > generated. Basically, the intent is to use the challenge sent in an 
> > Agent Advertisement for the Registration procedure. Re-using the 
> > challenge will solve only certain cases and not all.
> 
> I think that if the solicited agent adverticement re-uses the 
> most recent challenge from an unsolicited advertisement, 
> there are no unsolved cases, so the proposed text would be 
> good. The only potential problem with the solicited multicast 
> advertisements are that they occur at the command of an 
> uncontrolled entity, and may occur at any rate supportable by 
> the medium. So if the most recent unsolicited challenge was 
> not re-used, but a new generated and used to update the 
> challenge window, a hostile MN could swiftly age out earlier 
> challenges. This is inherently not the case with the 
> unsolicited advertisements, which occur at a fixed rate 
> controlled by the configuration of the 
> mobility agent.
> 
> Apparently, you think there are unsolved cases beyond this? Could 
> you elaborate on them, please?
> 
> > I can see the potential security problem in this particular 
> case but 
> > not sure on the severity because of the challenge 
> mechanism. Any help 
> > on this security topic will be appreciated.
> > >...
> > > > > 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.
> > 
> 
> 
>