RE: NAT Traversal

["Greg Bailey" <greg@minerva.com>]

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