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

From: "Sami Vaarala" <[email-masked]>
Date: Thu, 18 Mar 2004 10:32:19 +0200

Alan,

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

I agree.  We actually had some discussion about this during RFC 3519
work, but it was last minute and there was no concrete need for a change
at that time.

> 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
> [...]

I've been thinking along the same lines.  But I'd like to take this
proposal a bit further: I'd like to include both source and destination
address *and* port of the original UDP packet.  This information should
flow in both directions, MN->HA and HA->MN (and FAs of course).

This is the cleanest approach, in my opinion, because NATs may operate
on any of these fields.  To be future proof, we should have all the
information available for detection and compensation.  (I realize this
is in conflict with UNSAF considerations though.)

As for the current uses, we need some extra stuff to:

  - to handle the FA case being discussed (allow src address != CoA)

  - to detect destination address NAT (port forwarding) robustly
    (it can be done in other ways too, though.)

  - to cover the admittedly improbable corner case where only the MN
    source port (and not the source address) is NATted

Best regards,

-Sami

-- 
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: Thu, 18 Mar 2004 22:24:42 -0800

Hi Sami.

I wonder if we really should bother with port numbers for "improbable
corner case"?  Has anyone ever run into the case of port address
translation only without private/public IP address translation?  I'm open
to this only if it's for real to avoid cluttering protocol, product
documentation, training, etc.  :)

As for identifying the destination IP address, are we talking about the
case of a NAT box in front of the HA?  And that NAT box translates the
public IP address of HA (HApub) to private address (HApriv) for RRQ
from FA/MN?

It's a good idea to have both IP addresses from MN/FA and HA.  The
NAT Traversal detection and tunnel setup would work bidirectional.

Only issue is protecting extension in FA - HA messages?  MN CCOA
mode would work fine.

Kent