Subject: Re: [Mip4] DRAFT Minutes from MIP4 meeting in Washington

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Jan 2005 10:54:22 +0100

Dear Henrik, Charles,

Where are the slides of the "Adapting FMIPv6 for MIPv4" presentation at
Washington DC?  Specifically I'm looking for the comparisons and the
figures.  I can not find them on the mip4.org site.

Thanks,

Alex

Henrik Levkowetz wrote:
> Below are the minutes from the MIP4 WG meeting in Washington.
[...]
> The minutes are also available here in three different formats:
> 
>     http://www.mip4.org/ietf61/minutes.pyht
>     http://www.mip4.org/ietf61/minutes.html
>     http://www.mip4.org/ietf61/minutes.txt
[...]
> ========================================================================
> MIP4 WG  Minutes (Thursday, November 11, 2004, 1300-1500)
> ========================================================================
[...]
> 9. Adapting MIPv6 Fast Handover for MIP4:                Charlie Perkins
> ------------------------------------------------------------------------
> 
>   Issue:
> 
>     FMIPv4 motivation and design ideas, implementation benchmarks.
>     Available for anyone to work on - will not push this.
-- 
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: Kent Leung <[email-masked]>
Date: Wed, 19 Jan 2005 15:25:20 -0800

Hi.  I realized during our Deregistration/FHAE discussions that
we assumed that the FA's SA is indexed by the source IP address of the
RRQ on the HA.  But it's not explicitly clear in RFC 3344 (going back to
RFC 2002) that source IP address is the method to identify the FA since
CoA may also be used.

So this leaves ambiguity in implementation and also introduces deployment
issues where the SA is configured based on CoA.

I think we should clearly state some text to avoid ambiguity?  Something like
"The FA or HA is identified by the source IP address of the registration
message.  This IP address and the SPI is used to index the security
association to authenticate the message."

Thoughts?

Kent

--
      |           |                   Kent Leung
     :|:         :|:                  IP Mobility Development
    :|||:       :|||:                 IOS Technologies Division
   :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
  c i s c o S y s t e m s             Email: [email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 20 Jan 2005 01:33:03 +0100

Hi Kent,

> association to authenticate the message."

I suspect that the reason this has not been raised before is that before
we introduced NAT traversal into the equation, it was an unstated
assumption that the source IP address and the CoA address would be the same.

Indeed, it is this assumption which is the base for detection of NATs in
3519 - if src address and CoA address differ, then you say "Ah, this
packet has gone through a NAT".

So one way of clearing up the ambiguity could be the text you propose;
another could be to clearly state that the FA sends the reply with the
source address equal to the Care-of Address, typically through the
interface having this address.

There may be other ones too, and I'm not sure which is the best way to go
here.

One question which pops into my head, though, is why base this on the src
address, in preference to the CoA?  It would be interesting to hear your
reasoning here.  Which one we pick may impact a 3519bis (NAT traversal)
document more or less...

	Henrik

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 20 Jan 2005 08:46:43 +0100

Kent,

Just a thought, what happens when you have a FA with multiple interfaces
that all utilize the same CoA? Do you have to have multiple SAs for what is
basically one FA?

/Fredrik 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Kent Leung
> Sent: den 20 januari 2005 00:25
> To: [email-masked]
> Subject: [Mip4] 3344bis clarification on identifying the FA's SA
> 
> Hi.  I realized during our Deregistration/FHAE discussions 
> that we assumed that the FA's SA is indexed by the source IP 
> address of the RRQ on the HA.  But it's not explicitly clear 
> in RFC 3344 (going back to RFC 2002) that source IP address 
> is the method to identify the FA since CoA may also be used.
> 
> So this leaves ambiguity in implementation and also 
> introduces deployment issues where the SA is configured based on CoA.
> 
> I think we should clearly state some text to avoid ambiguity? 
>  Something like "The FA or HA is identified by the source IP 
> address of the registration message.  This IP address and the 
> SPI is used to index the security association to authenticate 
> the message."
> 
> Thoughts?
> 
> Kent
> 
> --
>       |           |                   Kent Leung

---

From: Kent Leung <[email-masked]>
Date: Thu, 20 Jan 2005 11:33:03 -0800

Hi Henrik.

>assumption that the source IP address and the CoA address would be the same.

KL>

Actually, RFC 2002/3344 states to use the egress interface's IP address as the
source IP address of the RRQ  (sect. 3.7.2.2).  When RFC 3519 was introduced,
the mandate for the addressed to be the same was added.

>packet has gone through a NAT".

KL>

Yes.  There has been contention on this matching address requirement.
Excerpt from "[issue44] RFC 3344 - Source Address of the RRQ  & FHAE
issues" thread:

>Keeping RFC3344 text as is presently enables a vendor/operator to use
>different IP addresses for the signaling control and the data forwarding
>plane which might be useful in a number of configurations and operational
>environments. In addition, removing the general assumption that the outgoing
>source IP address is associated with the outgoing interface (a fairly common
>IP configuration) and replacing it with a nailed up source address because of
>a bug in NAT Traversal, may well cause us future problems.

There was general agreement to untie this link in 3519bis to allow the
source IP address to be the egress interface's for NAT Traversal case.

>interface having this address.

KL>

See above.  I think we should not force this binding of addresses.

>reasoning here.  Which one we pick may impact a 3519bis (NAT traversal)

KL>

Good question.  Just to point out it's not just me.

>At 09:39 AM 12/15/2004 -0600, Pete McCann wrote:
>But the FA can be identified from its source IP address in the RRQ
>(absent NAT considerations).

At 01:21 PM 12/17/2004 -0800, Charles E.Perkins wrote:
>Up until now, I have thought that the mobility security association
>was selected based on the source IP address of the IP packet,
>since it was a security association for a network-layer protocol.

Since RFC was ambiguous on how exactly to identify
the FA, I came up with logic that works in all cases.  However,
it became apparent during the discussion on deregistration of
previous CoA using FHAE that source IP address of packet
works while the CoA will not.

Kent

---

From: Kent Leung <[email-masked]>
Date: Thu, 20 Jan 2005 11:42:23 -0800

Hi Fredrik.

Yes, unfortunately that would be the case when using the source IP
address for indexing the SA.

BTW, there were discussions of using FA NAI to identify the FA
for authentication.  This would allow one SA per FA.

Subject was "[Issue 45] RFC 3344 - FHAE issue when using
a   different careofaddress".

>At 01:03 PM 3/16/2004 -0800, Kent Leung wrote:
>Use of FA NAI sounds reasonable and generic FA identifier will
>come in handy for future features.

But this is outside the scope of 3344bis.  I'm seeking a clarification
in 3344bis.

Kent

---

From: Pete McCann <[email-masked]>
Date: Mon, 24 Jan 2005 10:26:44 -0600

Hi, all,

 > the mandate for the addressed to be the same was added.

Clearly, this only applies when using an FA-located CoA, right?
For Co-located CoA (in an R-bit environment) the FA must relay the
message with a different source IP address and CoA.

 > >reasoning here.  Which one we pick may impact a 3519bis (NAT traversal)

Just to amplify the choice quotes that Kent prints below: the source
IP address is really all that you have to go on when registering a
co-located CoA via the FA.  I don't think we should be adding logic
that checks the 'D' bit before deciding what to use as the index to
the SA.

For the NAT case, the right solution might be to program the SAs into
the HA with the IP address of the NAT.  This is sort of like logically
extending the FA to include an extra interface which happens to be on
another box.

-Pete

---

From: Kent Leung <[email-masked]>
Date: Mon, 24 Jan 2005 10:00:49 -0800

>message with a different source IP address and CoA.

Yes. The behavior of the R-bit is documented in Sect. 4.11 in RFC 3519.

Kent