Subject: [multipathtcp] NATs and MPTCP security

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 22 Nov 2010 17:25:27 +0100

Hello,

MPTCP has been designed with NATs and middleboxes in mind. However when
considering security, these devices cause annoying problems. To
illustrate these problems, it is interesting to remember which fields of
the IP and TCP headers can be modified by middleboxes :

- source IP address
- destination IP address
- source port
- destination port
- sequence number
- acknowledgement number
- window

This implies that in practice a security mechanism for MPTCP can only
rely on information that is exchanged inside TCP options as all the
other fieds of the TCP header are 'mutable'. This is important in
comparison with shim6 or sctp for example where middleboxes are not as
important.

This also implies that we have to be careful with the ADD_ADDR and
REMOVE_ADDR options as when one of the communicating hosts is behind a
NAT we can advertise information about addresses that are either
unreachable or correspond to different hosts (e.g. a client using an
RFC1918 address behind a NAT and a server that resides in a LAN attached
to another LAN using the same private IP addresses as those of the client).

Olivier
-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: "McDonald, Andrew" <[email-masked]>
Date: Tue, 30 Nov 2010 13:13:24 +0000

> to another LAN using the same private IP addresses as those of the client).

'Topology hiding', i.e. avoiding exposing information about the 
structure of the internal network behind a NAT, is sometimes cited as a 
'security benefit' of NATs.

I suspect having 'internal' addresses exposed in this way would be seen 
as 'a bad thing' by NAT/firewall vendors. They might do a couple of 
things as a result:
a) provide a 'NAT helper' that rewrites it in some way
b) strip that option
c) drop the packet
If you were to do something in a NAT/firewall, I suspect (b) is probably 
the correct choice (since the NAT probably can't rewrite the option 
correctly, and dropping packets hurts performance).

regards,

Andrew