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

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 5 Aug 2003 00:04:38 +0200

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

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

---

From: Pete McCann <[email-masked]>
Date: Tue, 5 Aug 2003 15:56:56 -0500

Hi,

 > containing challenges to be unicast, never multicast.

Isn't this open to a similar denial of service attack, assuming that
link layer spoofing is possible?  That is, an attacker can send
spoofed solicitations at a very high rate, causing the FA to
repeatedly (unicast) the agent advertisements with fresh challenges to
the victim's mobile node.  It could happen that the mobile is never
able to register because a new solicitation arrives at the FA before
the victim's RRQ.  The solicitation/advertisement effectively pushes
the last unicast challenge out of the 1 slot.

Perhaps it should be possible to return the same challenge value in
successive unicast solicited agent advertisements, as long as it was
not previously used (recall "previously used" means used with a valid
MN-AAA or MN-FA authentication extension).  I think the same procedure
(returning the same challenge) should be followed for unsuccessful
Registration Requests where the MN-AAA (or MN-FA) authentication did
not check out.  If desired, we could change the challenge value after
some fairly long period of time (like, 1 minute would easily be long
enough to avoid this DoS) if we are really worried about robustness.

 > > don't have any issue in incorporating the option agreed by all. 

I think some changes to the draft are in order to avoid the DoS
attacks pointed out by Henrik.

 > response from a SHOULD to a MUST. Any viewpoints on that?

Sounds like a good idea, although see above about returning the same
(unused) challenge in successive (unsuccessful) responses.

-Pete

---

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

Hi,

	Seems we are on the same page.

	Comments on the proposal of conditional generation of
new challenges inline:

> the last unicast challenge out of the 1 slot.

Yes, you're right. This could be just as damaging.

> enough to avoid this DoS) if we are really worried about robustness.

Yes, this seems like a good solution.

	Henrik