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

From: "O'Neill Alan" <[email-masked]>
Date: Thu, 18 Mar 2004 02:14:27 -0500

WG,

The following fix does not seem ideal to me.

RFC3344 enables the RREQ from the FA to the HA to use any address valid at
the outgoing interface as the source IP address. This as we know causes NAT
detection problems in NAT Traversal, and as such, in my view is not a defect
in RFC3344, but a defect in NAT Traversal.

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.

I believe the better (but neither the least effort or quickest) solution is
instead to modify the NAT Traversal work by having an FA, that is NAT
Traversal capable and behind a NAT (ie would presently request UDP
tunneling), additionally add its RREQ source address into the RREQ as a
signed skippable MIP extension. This ensures that the source address change
in the RREQ through the NAT can be explicitly and unambiguously detected at
the HA by source address comparisons, rather than by comparison with the FA
CoA in the RREQ. This is then complaint with present RFC3344. The signed
source address does not of course improve NAT Traversal security because the
packet source address can still be modified by a MiTM, but it might be more
generally useful for detecting source address modifications when a NAT
Traversal was neither requested nor expected.

Restating, MIP architecture requires that any information used for MIP
signaling or packet redirection to be a signed entity, and we are now finding
that the packet source address now needs to be considered as such
information. Therefore we need to sign it. Locking the packet source address
to the signed FA CoA is a short cut to the same end, but of course requires
that handful of nails.

Note also that including this extension that carries the original source
address, when forwarding a deregistration of a CoA that is located at a
different FA, would then resolve the FHAE issue as it would always enable the
HA to detect the forwarding FA source address and hence determine the
required FHAE SA.

Thoughts ?

Alan.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sri
Gundavelli
Sent: Saturday, March 13, 2004 10:06 AM
To: [email-masked]
Subject: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ [Issue]

This has been entered in the issue tracker as issue 44.

owner: Sri Gundavelli <[email-masked]>:

category: Technical
draft: draft-ietf-mip4-rfc3344bis
priority: Must fix
status: No discussion
title: RFC 3344 - Source Address of the RRQ [Issue]

RFC 3344:
Section 3.7.2.2. Forwarding a Valid Request to the Home Agent

"Specific fields within the IP header and the UDP header of the
   relayed Registration Request MUST be set as follows:
      IP Source Address
               The foreign agent's address on the interface from which
               the message will be sent."

Per the above the text, the foreign agent is required to send the RRQ
with the source address of the outgoing interface and this essentially
conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the
foreign agent is required to set the source address of the RRQ to its
care-of address, so that the home agent does not detect NAT incorrectly.
The logic of NAT detection at the home agent is by comparing the source
address of the RRQ to the care-of address in the RRQ's MIP header. So,
we need to fix the text in 3344. There is no reason why the foreign agent
MUST set the source address of the RRQ to the IP address of its outgoing
interface. We should infact enforce the foreign agent to set the source
address of the RRQ to the FA care of address.
_________________________________________________
Mip4 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip4/issue44>
_________________________________________________

-- 
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/

-- 
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: Sri Gundavelli <[email-masked]>
Date: Thu, 18 Mar 2004 01:57:44 -0800 (PST)

Hi Alan,

> Traversal was neither requested nor expected.

I agree we need a better NAT detection scheme. What you are asking for is
essentially an FA Identity extension. HA can use the information from
this extension for Security Association lookup and as well for the NAT
detection. This should fix both issue 44 and 45. However, if we don't
plan to go that path, we can probably remove the MUST clause for setting
the RRQ source address to the FA Care-of address and just leave it as
a recommended and with potential for detecting NAT incorrectly ?

Sri.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 18 Mar 2004 09:25:23 +0100

Hi Alan,

    Your argument below is persuasive.  It seems to me this would be a
fairly clean solution which leaves 3344 as flexible as today, improves
NAT traversal and solves the deregistration FHAE problem.

	Henrik

---

From: [email-masked]
Date: Thu, 18 Mar 2004 21:57:08 +0200

Hi, 

> NAT traversal and solves the deregistration FHAE problem.

I posted a reply earlier but it's probably still in moderation list.
Anyway, I agree with Alan's comments as well. 

However, to me the most future proof solution is to add four fields
into RFC 3519 or a new extension: src address, src port, dst address,
dst post.  These should also go in both directions (MN/FA->HA, HA->MN/FA).
As NATs operate on potentially all of these fields, it makes sense to
provide the originals for MIP nodes (I know this may violate against
UNSAF considerations more than RFC 3519 does, though.) 

The immediate use would be to cover the FA CoA issue under discussion,
but having an "original src port" field would also cover the (admittedly
corner) case where only the source port gets NATted.  This info could also
be used to help with port forwarding (where destination address and/or port
is translated; dest address only is not enough if only the port gets
translated). 

Netseal implemented this as a separate extension which goes alongside
the RFC 3519 extension.  But it could just as well be a part of the
RFC 3519 extension(s).  Are there plans to revise RFC 3519 in the near
future? 

Best, 

 -Sami 

 --
Sami Vaarala
http://www.hut.fi/~svaarala

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 18 Mar 2004 21:17:32 +0100

Hi Sami,

> Anyway, I agree with Alan's comments as well. 

Yes.  A lot of mail hasn't made it to me at work today, so I'm picking
up a lot of stuff here at home.  Sorry for the delay ... :-)

> UNSAF considerations more than RFC 3519 does, though.) 

Mm, yes, but we seem to be needing it.  I like it.

> is translated; dest address only is not enough if only the port gets

Clearly not.

> RFC 3519 extension(s).  Are there plans to revise RFC 3519 in the near

No such plans at this time.  I don't know what's better - to write a short
draft defining new subtypes to the NAT traversal extensions 44 / 144, to
revise 3519, or to define a new extension for this in 3344bis...

I guess I'd think first in terms of a short separate document.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 19 Mar 2004 01:04:05 +0100

|| (reposting this with [issue44] in the subject line so it'll be picked
|| up by the issue tracker - Sami, you managed to get rid of the issue
|| number somehow!  ,,:-)     
|| 
|| Our issue tracker (at http://mip4.org/issues/tracker/mip4/) is pretty
|| good at picking up the discussions on the list and archiving them by
|| issue - if there's an issue number in the subject.  For now, the first
|| entry of an issue has to be made at the tracker web site, but I'm 
|| looking at doing something about that too, so new issues posted to 
|| the list with appropriate keywords will also be picked up correctly.
||
||	Henrik

Clearly not.

	Henrik

---

From: Kent Leung <[email-masked]>
Date: Thu, 18 Mar 2004 21:52:25 -0800

Hi Alan.

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

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

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.

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. :)

Kent