Subject: RE: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues

From: "O'Neill Alan" <[email-masked]>
Date: Fri, 19 Mar 2004 05:06:16 -0500

Hi Kent,

-----Original Message-----
From: Kent Leung [mailto:[email-masked]] 

What is meant by "signed"?  Implying FHAE protected or some
FA signature in the extension?  A bit more clarification would help.

AWO> Yes - FHAE protected was the assumption if one exists. 

Let's say there is no pre-existing SA between FA and HA.  How
is the extension protected?

AWO> Thinking as I write (which is often inadvisable at 8.30pm), it may well
be, that in principle, given that this extension is only used in a comparison
with the unprotected packet source address, that it might be ok to leave
unsigned because whilst a fraudulent delta could be created by a MiTM by
modifying the extension, they could just as easily create that delta with a
signed version, simply by changing the unprotected packet source address. We
should think about that aspect a lot more though I agree.

It's a good idea.  But I assumed that this was not used because the
FA cannot add extensions without FHAE to protect the message?
So as long as we have a method to protect this new extension, I'm
fine with it since it meets our requirement for an FA identifier for the
FHAE authentication.

AWO> Ok - that's good.

Though using FA NAI has the advantage of minimizing SA entries on
HA.  There would be one SA for FA, regardless how many CoA or
source IP addresses used in the registration request.  I'm sure not
everyone will agree that it's a good thing. :)

AWO> I was primarily keen to push back on the FA CoA nailing, and an FHAE
identification solution potentially falls out as well. However, I can
certainly see the benefit of your scheme for the FHAE issue.

Alan

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

---

From: Kent Leung <[email-masked]>
Date: Mon, 22 Mar 2004 15:56:18 -0800

Hi Pete.  We can put together a draft on Mobility Agent
Identifier extension for SAs to guard against NAT traversal,
if that's OK with everyone.

I agree that 3344bis doesn't need the RFC 3519-related change.

Kent

At 04:32 PM 3/22/2004 -0600, Pete McCann wrote:

>Hi,
>
>[sorry about my long absence from the thread; was traveling all last
>  week]
>
>Kent, I think your response last week convinced me that ignoring the R
>bit is not a good idea, and I agree that the HA should check the FHAE,
>if it is present, and discard the message if it doesn't check.
>
>It also seems like the cleanest solution to the NAT traversal problem
>is to encode the identities of the FA and HA (probably using NAI
>format) in Mobile IP extensions, and to use these identities to index
>security associations.  There is some precedent for this in the MN-AAA
>extension, when used with the MN NAI extension and all-zero IP source
>address.
>
>I also agree with Alan that the restriction on the RRQ source IP
>address made in 3519 is not ideal, and that we shouldn't require this
>in the base protocol.
>
>However, we need to figure out how to get from where we are now to the
>ideal case.  It sounds like there were different opinions on whether a
>NAT traversal fix of some sort (new extension) should go into the base
>protocol or into a new document.
>
>I tend to come out on the side of a new document, and to let the
>sleeping dog (NAT traversal) lie for now with the current
>IP-address-indexed SAs and the band-aid solution given in 3519.  This
>is based on a desire to get 3344 done without too many fundamental
>changes, although I am not sure that even now we can go directly to
>Draft Standard with the changes we have made so far.  It is also based
>on my own old-fashioned bias that IP protocols shouldn't have to take
>NATs into account during their design; rather, it should be the other
>way around.
>
>If someone wants to put together a new document on Mobility Agent
>Identifier extensions I think that would be a good idea.  In that
>document, we could make changes to the way that SAs are indexed in a
>way that is robust against all forms of NAT.
>
>Does anyone feel really strongly that we need to make this change now
>in the 3344bis document?
>
>-Pete

---

From: Pete McCann <[email-masked]>
Date: Mon, 22 Mar 2004 16:32:41 -0600

Hi,

-Pete