Re: [Mip4] 3344bis clarification on identifying the FA's SA

[Pete McCann <[e-mail]>]

Hi, all,

Kent Leung writes:
 > Hi Henrik.
 > 
 > At 01:33 AM 1/20/2005 +0100, Henrik Levkowetz wrote:
 > 
 > 
 > >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.
 > 
 > 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.

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.

 > >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".
 > 
 > 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.
 > 
 > 
 > >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.
 > 
 > KL>
 > 
 > See above.  I think we should not force this binding of addresses.
 > 
 > 
 > >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...

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

 > 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


-- 
Mip4 mailing list: [e-mail]
    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/