RE: NAT Traversal

["William Dixon" <wdixon@windows.microsoft.com>]

Just a status note that the NAT-T authors are reviewing an option to
start on 500, then float the port off of 500 to another well-known port
because of the Ipsec-aware NATs already out there.  

Our test code showed that doing this passed 10-12 major NAT boxes in
both their normal and "IPsec aware" modes, for 1 and 2 clients behind
the NAT, with serially established IPsec SA pairs UDPnon-500-ESP to the
same dest IP.  I regret that I haven't been able to post the earlier or
even the later test results, just due to lack of bandwidth.  The task is
still in queue, I haven't given up yet...and hopefully Ted & Barbara
were able to allow 15min on the agenda in Minneapolis.

With this change, I see no deployment blocker for IKE and IPsec working
transparent through "normal" NATs and "IPsec aware" NATs.  However,
adoption may still require IPR clarification.  

Jayant, I don't see the Trlokom IPR notice on the IETF site.  Didn't you
say you submitted one ?  

-----Original Message-----
From: Greg Bailey [mailto:greg@minerva.com] 
Sent: Monday, February 25, 2002 4:48 PM
To: ipsec@lists.tislabs.com
Cc: ark-gvb-x
Subject: RE: NAT Traversal


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hallam-Baker, 
> Phillip
> Sent: Mon 25 Feb 02 14:05
> To: 'Derek Atkins'; Jayant Shukla
> Cc: ipsec@lists.tislabs.com
> Subject: RE: NAT Traversal
 
[...]

> The problem with NAT suggests to me that their authentication role was

> not properly understood in IPSEC. I have never seen an internet 
> service advertised by IP address (except for the A root). Ergo it is 
> not a primary authentication point.

Inasmuch as the job description of a NAT box is to lie about identities
in terms of IP addresses, it seems to me that the authentication role of
a NAT box is basically to emphasize the importance of having at least
one mandatory type of supported ID that is capable of being globally
unique for use in lieu of IP address when the actual IP address of an
end point is neither unique nor visible in IP headers sent or received
by the other end point.

Unless the NAT box is formally acting as a security gateway, I would
much rather base my policies on what the "invisible" box on the other
end says its identity is rather than on something which could be a total
fabrication by the NAT box.  Not that this is a complete solution but
given the "signa- ture" difficulty of grokking what is going on at the
other end of a NAT box I think it would make the rest of a solution
easier.

The lack of an alternate, mandatory ID form is also something that seems
to me to limit the usefulness of IKEv1 when defining policies for
talking to a particular privileged mobile computer whose IP address
varies with its location of the moment.

> The IP address is sometimes a secondary authentication mechanism and 
> should be validated as part of the process of establishing an SA.
>
> 		Phill

    Greg Bailey     |  ATHENA Programming, Inc  |  503-295-7703  |
  ----------------  |  310 SW 4th Ave  Ste 530  |  fax 295-6935  |
  greg@minerva.com  |  Portland, OR  97204  US  |