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

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 2 Sep 2005 18:51:51 -0500

Hi Henrik,

As I said at the beginning of this discussion. Whatever the mailing list
agrees upon is absolutely ok with me. It may be against my opinion but
that how it works and I am absolutely fine with that.

On the other hand, if the resolution of this issue will boil down to
what you summarized as I quoted below, I believe the mailing list should
make a call and move forward.

"
For this particular case, it seems to me that the only thing you might
accomplish is to totally shoot down any use of the dynamic HA assignment
mechanism with arbitrary FAs at all, and that doesn't make sense to me.
"

I believe this issue has been discussed enough and I am not sure more
discussion will change the mind of those who participated in the
discussion so far one way or the other.

Regards,
Ahmad

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Friday, September 02, 2005 5:41 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Alpesh Patel (alpesh); Kent Leung (kleung); Pete McCann; 
> Margaret Wasserman; [email-masked]; Joel M. Halpern; Milind 
> Kulkarni (mkulkarn); Khalil, Mohamed [RICH2:2S20:EXCH]
> Subject: Re: [Mip4] Re: LC review: 
> draft-ietf-mip4-dynamic-assignment-05.txt
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Ahmad, all,
> 
> <hat type="just another guy">
> 
> On 2005-09-03 00:04 Ahmad Muhanna said the following:
> > Hi Alpesh,
> > 
> > Please see my comments inline.
> > 
> > Regards,
> > Ahmad
> > 
> >> 
> >> 
> >> Ahmad:
> >> 
> >> I am not convinced that having FHAE is required. There is no FHAE
> >> deployment today and mandating one as part of this draft is 
> >> an overburden.
> >> 
> > 
> > [Ahmad]
> > I was trying to address the comment that was raised by 
> Kent. However, 
> > my preference is to mandate a security association between 
> the FA and 
> > the HA which could be through FHAE, IPSec, etc. I believe this is a 
> > valid requirement and it is already mandated by RFC3543, 
> registration 
> > revocation under section 4.2.1: "
> > 4.2.1.  Negotiation of Revocation Support
> > 
> >    During the registration process, if the foreign agent wishes to
> >    participate in revocation messages with the home domain, 
> it MUST have
> >    an existing security association with the home agent 
> identified in
> >    the registration request, and append a revocation 
> support extension
> >    (defined in Section 3.2.) to it.
> > .......
> > "
> 
> Requiring a mandatory FHAE leaves the dynamic HA assignment 
> mechanism dead in the water, in order to mitigate a threat 
> which nobody so far has managed to convince me is in any way 
> more than a minor nuisance.
> 
> 
> >> If you look back at the threat models I mentioned in one of
> >> the previous emails, FHAE comes in handy if there is a rouge 
> >> between FA and HA changing the destination IP and forwarding 
> >> the RRQ to multiple HAs'. This I think is not the threat 
> >> model that we should be too much concerned about.
> > 
> > [Ahmad]
> > I respect your personal opinion. But in reality it is a real issue.
> 
> I've seen no convincing data on this, only your repeated 
> assertion that this is major.  I don't see that at all.
> 
> >> 
> >> The valid threat model is when a rogue on the MN/FA link
> >> changes the dst IP And forwards to multiple HAs. In that 
> >> case, the MN will receive multiple
> >> 
> >> replies (since the FA had multiple outstanding RRQs that the
> >> rogue generated).
> > 
> > [Ahmad]
> > I am not sure if this is a valid scenario that we need to 
> worry about. 
> > Can you please elaborate more?
> > 
> >> 
> >> In this case, we can put text in Security Considerations
> >> stating that the MN Must deregister if it receives 
> multiple replies.
> 
> This, on the other hand, seems to me to be a response 
> appropriate to the threat.  
> 
> >> If we are really paranoid about the first scenario, we can
> >> highlight this in Security Considerations and put text that 
> >> one way to mitigate is by reducing the lifetime of initial RRQ.
> > 
> > [Ahmad]
> > I am not sure what do you mean by paranoid here. I am really amazed 
> > that you still using this word. Anyway, It is probably more 
> beneficial 
> > to stay focused on the technical issue than the feelings. 
> Once more, 
> > this is not the first time that a security association 
> between the FA 
> > and HA is mandated. Please see comment above.
> 
> </hat>
> 
> <hat type="chair">
> 
> Ok. Discuss the issues here.  Expressing amazement at how 
> people use the language is not helping us to focus on the 
> technical issue, so let's assume that first sentence isn't there.
> 
> </hat>
> 
> <hat type="just another guy">
> 
> If you want to REQUIRE the existence of an FA/HA security 
> association in some or all deployments of MIPv4, that is a 
> major change to the whole protocol, and I think the best 
> course would be to write it up in a draft.
> 
> For this particular case, it seems to me that the only thing 
> you might accomplish is to totally shoot down any use of the 
> dynamic HA assignment mechanism with arbitrary FAs at all, 
> and that doesn't make sense to me.
> 
> </hat>
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFDGNT+eVhrtTJkXCMRAneLAJ9cxEoW3wJ5wWOBYYzTmiZXMVEuzQCg+R5a
> 73ppW4aTRIipgNy8bfbw5jw=
> =aK7H
> -----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: Sat, 03 Sep 2005 02:35:44 +0200

> that how it works and I am absolutely fine with that.
[...]

Ok, good.  I think the authors have a number of suggestions to choose from,
so I'd expect proposed text, and then we'll take the measure of the list.

	Henrik