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

From: "Jayshree Bharatia" <[email-masked]>
Date: Tue, 5 Aug 2003 15:13:59 -0500

Hi Henrik,

Having newly generated challenge in the unicast solicited advertisement is
ok. I will also change the text to reflect mandatory inclusion of the
challenge in a Registration Reply if the FA and the MN are compliant to
RFC3012bis.

I will able to close this issue once we have some opinions from others on
handling the challenge in a multicast agent advertisement.

Thanks,
Jayshree
> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Monday, August 04, 2003 5:05 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [mobile-ip] Re: New issue: 3012bis challenges in 
> solicited ag ent advertisements
> 
> 
> Hi Jayshree,
> 
> 	(I'm adding the mip4 list (and culling the cc list), in 
> line with your suggestion below of getting 
> opinions/suggestions from others too.)
> 
> 	More inline:
> 
> Monday  4 August 2003, Jayshree wrote:
> > Hi Henrik,
> > 
> > I can see the following options for the multicasted agent 
> > advertisement issue when it is sent as a response of the solicited 
> > agent advertisement: 1. Treat the agent advertisement 
> different if it 
> > was requested by the solicited agent advertisement (your 
> proposal) 2. 
> > Restrict sending multicasted agent advertisement 3. 
> Indicate potential 
> > issue with the use of multicated agent advertisement
> 
> Agreed on the alternatives.
> 
> > Option 1: Not preferred since the whole point of using the 
> challenge 
> > in the agent advertisement is so that the MN can use this challenge 
> > information in the registration procedure if needed. 
> Restricting new 
> > challenge value breaks the mechanism. I have reservation toward 
> > treating this specific case differently especially since it 
> has side 
> > effect (mentioned above).
> 
> Right, here I guess we have somewhat different viewpoints. I 
> see it this
> way: If all multicast advertisements which are done in 
> response to a solicitation simply repeat the challenge from 
> the most recent unsolicited advertisement, you are in a 
> situation analogous to the one where you was on-link at the 
> time of the unsolicited advertisement, and heard that. As I 
> believe all or nearly all solicitations are done in order to 
> find out if there is an FA on the link (because one did not 
> hear the most recent unsolicited advertisement) and not in 
> order to refresh a challenge, I find this acceptable. 
> 
> At the same time, you are of course perfectly correct in that 
> if the solicitation is done in order to refresh a challenge, 
> it is of no use at all to respond with the same challenge 
> sent with the most recent unsolicited advertisement. As the 
> mobile node has no way to request that the solicited 
> advertisement be sent unicast, the only thing it can do in 
> this situation is to wait for a new unsolicited advertisement 
> with a fresh challenge.
> 
> > Option 2: solves the problem but adds extra burden on the FA.
> 
> I guess you mean because it now needs to send unicast 
> responses, rather than multicast? But if soliciting is done 
> to refresh a challenge, then you'd still get just as many 
> solicitations whether they were multicast or unicast. 
> 
> I would deem it an acceptable solution to limit solicited 
> advertisements containing challenges to be unicast, never multicast.
> 
> > Option 3: Provides guideline to implementers on probable security 
> > threat. This was my earlier proposal.
> 
> Ok. I don't think guidelines is sufficient, I believe we need 
> requirements to avoid the exact interoperability problems we 
> recently experienced.
> 
> > I would suggest we can have opinions/suggestions from 
> others as well. 
> > I don't have any issue in incorporating the option agreed by all.
> 
> Right.
> 
> We also should have some text to clarify the handling of 
> unicast solicited advertisements. I guess we agree on the 
> handling of those? (i.e. a new challenge should be generated, 
> and treated analogous to a challenge returned with a 
> registration reply?)
> 
> There is one further change we maybe should review as part of 
> this: To change the requirement on returning a challenge with 
> any registration response from a SHOULD to a MUST. Any 
> viewpoints on that?
> 
> 	Regards,
> 		Henrik
> 
> > Regards,
> > Jayshree
> > 
> > > -----Original Message-----
> > > From: Henrik Levkowetz [mailto:[email-masked]]
> > > Sent: Monday, August 04, 2003 12:08 PM
> > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > > Subject: Re: [mobile-ip] Re: New issue: 3012bis challenges in 
> > > solicited ag ent advertisements
> > > 
> > > 
> > > On Monday,  4 Aug 2003, Jayshree wrote:
> > > 
> > > > Thanks for your reply. I understand your concerns now.
> > > 
> > > Ah, good! :-) I was almost ready to despair there for a 
> while ,,:-)
> > > 
> > > > The current text in
> > > > section 2 is very generic and pertains only to the Agent
> > > > Advertisement. This is regardless whether the response 
> is triggered 
> > > > due to solicited Agent advertisement from the MN or 
> whether it is 
> > > > multicasted. I am reluctant to change this section (section 
> > > 2) since
> > > > there is nothing special about sending the multicasted agent
> > > > advertisement due to solicited agent advertisement. The 
> > > issue is with
> > > > the fact that it is triggered/sent as a result of 
> solicited agent
> > > > advertisement.
> > > >
> > > > Hence, my proposals is that we can add text detailing this
> > > particular
> > > > scenario as a security threat in section 12 (Security
> > > Considerations)
> > > > of RFC3012bis. Is this solution agreeable to you?
> > > 
> > > I think this is not so good, as I don't think new
> > > requirements should be introduced in the Security 
> > > Considerations section, and the issue here is that we need 
> > > some requirements to regulate how unicast and multicast 
> > > solicited advertisements are handled - specification of this 
> > > should not be left open.
> > > 
> > > Whether the proposed text is added to seciton 2 or somewhere
> > > later, like for instance in a new section 3.6 is relatively 
> > > unimportant to me, the important thing is to define the 
> > > behaviour, that the defined behaviour is good, and that the 
> > > text is consistent.
> > > 
> > > 	Regards,
> > > 
> > > 		Henrik
> > > 
> > 
> 
> 
>