Subject: [BEHAVE] Security issues when an IPv4 address is shared by different CPE

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 1 Dec 2008 16:18:01 +0100

Not sure whether this is the right place to post (notably because it is not about NAT 66 ;-))...
 
Several proposals around 'carrier grade NAT' share one public IPv4 address among several CPEs. While it is common now to 'share' on public IPv4 on a CPE among all hosts within the same home, sharing a public IPv4 address among several CPE is a vastly different threat model.

1) PMTUD: if a malicious CPE is connected to the same server as a normal CPE, then the malicious CPE can send ICMP packet_too_big to reduce the used MTU between this server and _ALL_ CPE sharing the public IPv4 address. This will slow down the traffic from this server because the PMTUD cache is on a per host basis AFAIK.

2) FATE SHARING: if the same malicious CPE launches some kind of attack against a server, then the server will probably react by black listing the IPv4 address... Also preventing all other CPE to connect to this server.

3) LOG CONFUSION: IPv4 servers are heavily relying on the fact that one IPv4 address maps to a single user. Correlation between actions (often used in the case of security incident 'what kind of damages has the bad guy done?') becomes mostly impossible. Similar to this would be the confusion of some 'dumb' load balancers.

And another issue is ID collision (not really a security issue tough) but a malicious CPE could send IP datagram to the 'shared' server with a good chance of ID collision among all the hosts behind so many CPE. If packets are fragmented, this will become really really difficult to de-fragment correctly.

Just my 0,01 EUR

-éric
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 1 Dec 2008 17:26:23 +0200

On Monday 01 December 2008 17:18:01 ext Eric Vyncke (evyncke), you wrote:
> And another issue is ID collision (not really a security issue tough) but a
> malicious CPE could send IP datagram to the 'shared' server with a good
> chance of ID collision among all the hosts behind so many CPE. If packets
> are fragmented, this will become really really difficult to de-fragment
> correctly.

True but...
Fragmentation does not really work through NATs in the first place, especially 
large ones (which are unlikely to bother with defragmentation and 
refragmentation).

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Dec 2008 08:00:01 +1100

In message <[email-masked]>, "=?iso-8859-1?q
?R=E9mi?= Denis-Courmont" writes:
> > And another issue is ID collision (not really a security issue tough) but=
>  a
> Fragmentation does not really work through NATs in the first place, especia=
> lly =
> 
> large ones (which are unlikely to bother with defragmentation and =
> 
> refragmentation).

	Well DNS doesn't work well these days without fragmentation.
	I know I've had to tune my recursive servers to deal with
	broken reassembly today.  Not everyone will be capable of
	doing that however.  It isn't that hard to do reassembly
	before forwarding the reply.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Mon, 1 Dec 2008 20:35:49 -0500

I would just like to point out that there are already many ISPs today  
that assign 1918-style addresses to their customers.

- Philip

On Mon, 1-Dec-08, at 10:18 , Eric Vyncke (evyncke) wrote:

> Several proposals around 'carrier grade NAT' share one public IPv4  
> address among several CPEs. While it is common now to 'share' on  
> public IPv4 on a CPE among all hosts within the same home, sharing a  
> public IPv4 address among several CPE is a vastly different threat  
> model.
>
> 1) PMTUD: if a malicious CPE is connected to the same server as a  
> normal CPE, then the malicious CPE can send ICMP packet_too_big to  
> reduce the used MTU between this server and _ALL_ CPE sharing the  
> public IPv4 address. This will slow down the traffic from this  
> server because the PMTUD cache is on a per host basis AFAIK.
>
> 2) FATE SHARING: if the same malicious CPE launches some kind of  
> attack against a server, then the server will probably react by  
> black listing the IPv4 address... Also preventing all other CPE to  
> connect to this server.
>
> 3) LOG CONFUSION: IPv4 servers are heavily relying on the fact that  
> one IPv4 address maps to a single user. Correlation between actions  
> (often used in the case of security incident 'what kind of damages  
> has the bad guy done?') becomes mostly impossible. Similar to this  
> would be the confusion of some 'dumb' load balancers.
>
> And another issue is ID collision (not really a security issue  
> tough) but a malicious CPE could send IP datagram to the 'shared'  
> server with a good chance of ID collision among all the hosts behind  
> so many CPE. If packets are fragmented, this will become really  
> really difficult to de-fragment correctly.
>
> Just my 0,01 EUR
>
> -éric

---

From: Fernando Gont <[email-masked]>
Date: Tue, 02 Dec 2008 00:56:28 -0300

>is not about NAT 66 ;-))...

haha... good one. ;-)

>public IPv4 address among several CPE is a vastly different threat model.
>

This is a good point.

>black listing the IPv4 address... Also preventing all other CPE to 

Another good point.

>really difficult to de-fragment correctly.

Yes, but you do not need to be behind a NAT. You could simply forge 
the source address of a packet to perform the same attack. See 
Section 4.1.2 of http://www.gont.com.ar/papers/InternetProtocol.pdf

BTW, you may want to have a look at this document: 
http://www.gont.com.ar/drafts/nat-security/draft-gont-behave-nat-security-01.txt 
. We will try to address the points you raised in the next revision 
of our document.

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 19 Dec 2008 18:08:38 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Vyncke (evyncke)
> Sent: Monday, December 01, 2008 7:18 AM
> To: [email-masked]
> Subject: [BEHAVE] Security issues when an IPv4 address is 
> shared bydifferent CPE
> 
> Several proposals around 'carrier grade NAT' share one public 
> IPv4 address among several CPEs. While it is common now to 
> 'share' on public IPv4 on a CPE among all hosts within the 
> same home, sharing a public IPv4 address among several CPE is 
> a vastly different threat model.

Eric,

Your list of security issues also applies to the port range
proposals (draft-despres-sam, draft-ymbk-aplusp).  

At this point, the best place for text such as yours is probably
draft-gont-behave-nat-security.  However, that document is specific
to NAT right now but the authors might be able to expand the
document's scope to also discuss the general security issues of
sharing addresses.

There is also text in Section 9.1 of 
draft-wing-nat-pt-replacement-comparison that could be lifted.  
I expect that document will probably die.

-d

> 1) PMTUD: if a malicious CPE is connected to the same server 
> as a normal CPE, then the malicious CPE can send ICMP 
> packet_too_big to reduce the used MTU between this server and 
> _ALL_ CPE sharing the public IPv4 address. This will slow 
> down the traffic from this server because the PMTUD cache is 
> on a per host basis AFAIK.
> 
> 2) FATE SHARING: if the same malicious CPE launches some kind 
> of attack against a server, then the server will probably 
> react by black listing the IPv4 address... Also preventing 
> all other CPE to connect to this server.
> 
> 3) LOG CONFUSION: IPv4 servers are heavily relying on the 
> fact that one IPv4 address maps to a single user. Correlation 
> between actions (often used in the case of security incident 
> 'what kind of damages has the bad guy done?') becomes mostly 
> impossible. Similar to this would be the confusion of some 
> 'dumb' load balancers.
> 
> And another issue is ID collision (not really a security 
> issue tough) but a malicious CPE could send IP datagram to 
> the 'shared' server with a good chance of ID collision among 
> all the hosts behind so many CPE. If packets are fragmented, 
> this will become really really difficult to de-fragment correctly.
> 
> Just my 0,01 EUR
> 
> -éric