[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is tunnel IP address included in SA?


--- On Fri, 29 Aug 1997 12:16:52 +0900  Motonori Shindo <mshindo@ascend.co.jp> wrote:

> There seems to be several ways to find the tunnel IP address for a
> particular destination IP address.
> 
>  (1) DNS TX record
> 
>  (2) ISAKMP/Oakley (or other KMPs)
> 
>  (3) an implementatin-specific way to determine what destination IP
>      address corresponds to what tunnel IP address. Probably in manual
>      fashion.

Whether or not one likes the KX (Note: KX != TX) record notion, there is some 
text in draft-rfced-info-atkinson-kx-*.txt about Proxy KM that might be useful 
to consider.

In particular, if one is trying to setup a secure ESP tunnel for a destination
that does not implement IPsec itself, it is unlikely that the same destination
will be implementing ISAKMP/Oakley to facilitate approach (3).  However, in a
world of Secure DNS, it would be straight-forward to use the KX record for the
intended destination to indicate the node that is authorised to handle KM 
on behalf of the destination node.  At that point, normal ISAKMP/Oakley 
(or other KM protocol) can do the rest of the work to setup the needed 
ESP tunnel SA.

> I think that (2) is the way to go ultimately, but at the early stage
> of the deployment of IPsec, (1) or (3) seems to be feasible. Is there
> any known implementation that is using (1) approach? Does curent BIND
> (8.X?) support this RR?

I don't know about TX.

KX record has been implemented in BIND (though not by Paul) and is deployed 
in certain IP-based networks, but it is not clear to me whether that implementation 
is widely available.

> Now I am wondering why people chose the way like this. I guess the way
> I initially come up with isn't that bad. That is,
> 
>  (4) To have one SA for each final destination IP address and such an 
>      SA have a corresponding tunnel IP address.

I am not sure what you are saying.

Do you mean that an SA should have:
	Source Identity
	Source Proxy Identity (currently generally called Proxy Identity)
	Destination Identity
	Destination Proxy Identity

	???

The Source Proxy Identity (and validation of it at receive time) is _necessary_ 
to prevent use of tunnel-mode IPsec to implement spoofing attacks.
 
> This approach is considered to be one of the variant of (3) approach,
> but the way to have an SA is different. For example,
> 
> 
>       |                               |
>  PC1 -+                               +- PC21
>       |         (Internet)            |
>       +-- R1 --- ......... --- R2 ----+
>       |             .                 |
>                     .                 +- PC22
>                    R3                 |
>                     |
>                 ----+---+--
>                        PC3 
> 
> In the figure above, PC1 sends datagarams to PC21, PC22, and
> PC3. Then, R1 should have three SAs like,
> 
>    SA1 :  destIP = PC21, SPI(AH, keyed-MD5, MD5key=xxxxx, tunnelIP= R2)
>    SA2 :  destIP = PC22, SPI(ESP, DES-CBC, DESkey=yyyyy, tunnelIP= R2)
>    SA3 :  destIP = PC3,  SPI(AH, keyed-MD5, key=zzz, tunnelIP= R3)
> 
> This approach eliminates the need to resolve the tunnel IP address for
> each destination IP address by making a tunnel IP address be a part of
> SA information.
> 
> Any comments?

How does the Tunnel IP address get into the SA in the first place ?
It seems like one MUST resolve it _before_ putting it into the SA.

Ran
rja@inet.org
References: