Re: NAT-Traversal - Security Considerations

[Ari Huttunen <[e-mail]>]

[e-mail] wrote:
> 
> I'm wondering myself about problems (one with Transport Mode, the other
> with Tunnel Mode) that can affect NAT-Traversal.
> 
> draft-ietf-ipsec-udp-encaps-02 deals with conflict problems but (i think)
> there are also problems that can occured with only one IPSec Client.
> 
> o Transport Mode
> 
>          +-----+
>          |  M  |
>          +-----+\
>                   \
>           +----+    \ /                +-----+
>          +| WS |-----+-----------------|  S  |
>         +|+----+    / \                +-----+
>         |+----+     NAT
>         +----+
> 
>    Math (M) is behind NAT and establish an SA with Server (S) using
>    a specific Trafic Descriptor (TS).
> 
>    After that, S will send all packets for NAT and selected by TS
>    (everything in many implementations and configurations) to M.
> 
>    This can cause a denial of service as Workstations (WS) and NAT
>    device will not be able to communicate with Server (S) anymore.
>    There is also confidentiality considerations as Math will receive
>    packets that are not for him.
> 
>    Am I right or is there a solution to avoid this problem as many
>    implementations will use the SA for every packet from S to NAT ?

It would seem to me that the IPsec layer in S needs to apply NAT for
packets that come via the SA, so they appear to come from address Y.
The server in S then thinks it's talking with Y. The return packets
to Y would then be NATed, and put to the SA, all other packets would
go through without any change. This way the TS doesn't apply to packets
to/from address 'NAT', but to address 'Y'. This would break if you want
part of the packets via an SA, and part in plaintext, using TS, because
server would see different IP addresses for the client, so don't do that.


> 
> o Tunnel Mode
> 
>                                              +-----+
>                                       +------| VIM |
>                     NAT               |      +-----+
>          +-----+    \ /            +----+
>          |  M  |-----+------+------| GW |
>          +-----+    / \     |      +----+
>                             |         |      +----+
>                             |         +------| IS |
>                          +--+--+             +----+
>                          |  S  |
>                          +-----+
> 
>    Math (M) is behind NAT and establish an SA with Gateway (GW) using a
>    specific Trafic Descriptor (TS). Using Tunnel Mode, Math will normally
>    use his private IP address but can also used a spoofed one: Server (S)
>    or VeryImportantMachine (VIM).
> 
>    After that, all packet for S or VIM (according to TS) will be sent to
>    M via UDP encapsulated tunnel. Even packets from Internal Server (IS)
>    to VIM will be sent to Math.
> 
>    This can be used by a malicious user to steal packets for VIM or to
>    deny communication with S.
> 
>    Am I right or am I missing something ?
>    How GW can decide if Math's IP is valid and is not a spoofed one ?

I had this in draft-huttunen-ipsec-esp-in-udp-00.txt:
> 
>    It is not possible for a hacker to obtain an arbitrary address in the
>    intranet being protected by the GW. If address assignment by the GW
>    is provided, only the address assigned to the hacker is allowed to pass
>    through the GW. In the other case, address is always assigned to
>    the hacker internally by the GW and the (arbitrary) IP address of the
>    hacker is always translated by a NAT functionality in the GW.

Perhaps I should have copied it to this current draft? Is it clear? 

Ari

> 
> --
> Mathieu Lafon - Arkoon Network Security

-- 
"They that can give up essential liberty to obtain a little 
temporary safety deserve neither liberty nor safety." - Benjamin Franklin

Ari Huttunen                   phone: [phone]
Software Architect             fax  : [phone]

F-Secure Corporation       http://www.F-Secure.com 

F(ully)-Secure products: Securing the Mobile Enterprise