Re: [BEHAVE] Security issues when an IPv4 address is shared bydifferent CPE

> -----Original Message-----
> From: behave-bounces@ietf.org 
> [mailto:behave-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
> Sent: Monday, December 01, 2008 7:18 AM
> To: behave@ietf.org
> Subject: [BEHAVE] Security issues when an IPv4 address is 
> shared bydifferent CPE
> 
> 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.

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
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave