Subject: RE: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 5 Sep 2005 10:09:16 -0500

Comments inline.

Ahmad

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Kent,
> 
> On 2005-09-04 17:19 Kent Leung (kleung) said the following:
> > Let me clarify my position.
> > 
> > I had summarized the solution options which were discussed.
>  This does
> > not mean that I think this problem is really a big issue.
> Actually, I
> > think it's just a nit.
> > 
> > I don't think FHAE is needed in the solution.  Having this
> requirement
> > is too restrictive.  We should not go down this path.
> > 
> > So if someone can offer a solution that doesn't need FHAE _and_
> > doesn't require 2 round trips to establish the dynamic HA session, 
> > would you agree to go with that?
> > 
> > Kent
> 
> I'm not sure if my proposal regarding this was completely
> clear - just to make sure, let me propose some text below.  
> The idea is to require a MN which has used dynamic HA 
> assignment to listen for spurious additional registration 
> replies, and immediately de-register in response to any reply 
> arriving from a different HA than the one the most recent 
> registration request was sent to:
> 
> Section 5.1.1., add new para. 4:
> 
>    "Even if a successful Registration Reply is received, the MN must
>    continue to listen for successful Registration Replies.
> If any further
>    successful Registration Reply is received, the MN must immediately
>    send a deregistration (Registration Request with the Registration
>    Lifetime field set to 0) in response to an additional Registration
>    Reply which is a response to a Registration Request to which a
>    successful Registration Request has already been received.
> 
>    The reason is to terminate any inappropriate resource usage which
>    might result from an attacker duplicating the Registration Request
>    to multiple legitimate HAs, rather than letting it go only to the
>    intended recipient as intended by the requesting MN, as described
>    in Section x.x, Security Considerations."
> 

[Ahmad]
This solution does not work. check earlier discussion on this thread.

> 
> Section 5.1.2., add new para. 4:
> 
>    "Even if a successful Registration Reply is received, the MN must
>    continue to listen for successful Registration Replies.
> If any further
>    successful Registration Reply is received, the MN must immediately
>    send a deregistration (Registration Request with the Registration
>    Lifetime field set to 0) in response to an additional Registration
>    Reply which is a response to a Registration Request to which a
>    successful Registration Request has already been received.
> 
>    The reason is to terminate any inappropriate resource usage which
>    might result from an attacker duplicating the Registration Request
>    to multiple legitimate HAs, rather than letting it go only to the
>    intended recipient as intended by the requesting MN, as described
>    in Section x.x, Security Considerations."
> 

[Ahmad]
In the case of the MN with co-located is registered with an FA, the
proposed solution does not work. see comments above for section 5.1.1.

On the other hand, for the case of MN with co-located but not registered
with FA, IMO the proposed solution is not definitive. My understanding
is that MN stops listening to MIP UDP in one of the following
conditions:
1. When MN registration times out and no longer interested in
registering.
2. When MN receives a successful RRP. (make sense why to keep listening)
3. may be there is others?

IMO it is a burden and a waste of resources at the MN side.

Now here are some questions:
1. How long the MN needs to continue listening?
2. What happens if the RRP coming from one or several HA's got lost? We
still have the same problem.

> 
> Regards,
> 
> 
> 	Henrik
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFDGzDIeVhrtTJkXCMRAtahAKDGDwuzYQiGgEOABnnXnwi63KC4ywCeKElX
> 9TkenRtL/abDGn0l6skpmmY=
> =CoKu
> -----END PGP SIGNATURE-----
> 
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 05 Sep 2005 18:08:06 +0200

on 2005-09-05 17:09 Ahmad Muhanna said the following:
[...]
>> This solution does not work. check earlier discussion on this thread.

Thanks for the pointer.  In that case, unless anybody can propose a
mitigation, I'd propose that we document this in the security
considerations and leave it at that.

>> proposed solution does not work. see comments above for section 5.1.1.

I believe you're mistaken here, if you're talking about an MN with a
co-located address which is sending its registration request through
an FA.

>> 1. When MN registration times out and no longer interested in

If the registration times out on the MN, it has timed out on the HA too,
so we don't have a problem any more, no?

>> 2. When MN receives a successful RRP. (make sense why to keep listening)

No, there's no such requirement that I know of, and anyway, we are now
specifying what we require of an MN which is using dynamic HA assignment,
so we can very well specify that it should listen for this.

>> IMO it is a burden and a waste of resources at the MN side.

Well, I guess we have different viewpoints here, then.

>> 1. How long the MN needs to continue listening?

I see no reason why the MN has to start and stop listening.  As long as it
is maintaining a registration, it could be alert to spurious registration
replies with verifiable HA-MN auth ext, and de-register as needed.  Making
it start and stop just complicates things, I'd say...

>> still have the same problem.

In that case, the additional registration will have to time out.

	Henrik