[v6ops] draft-ietf-v6ops-tunnel-security-concerns-04

Hi, Suresh, Dave, Jim,

Thanks for the detailed and valuable analysis contained in this draft.

I tried to check which of the identified security concerns apply to the following deployed scenarios:
- 6to4 between two 6to4 routers
- 6rd in an ISP network.
They have in common that, in their application scenarios, tunnels traverse neither any NAT nor any firewall, and that tunnel endpoint addresses are algorithmically derived from addresses contained in tunneled packets.

This is what I obtained: 

o 2.1. Network Security Bypass 
=> Non applicable because no FW is traversed

o 2.2. IP Ingress and Egress Filtering Bypass 
=> Not applicable if consistency checks between encapsulated and encapsulating addresses checks are performed at tunnel exits, as recommended in 6to4 and 6rd specifications .

o 2.3.  Source Routing After the Tunnel Client 
=> No new risk is introduced by the fact that IPv6 has been locally tunneled before reaching a  routing function where source routing, if not appropriately controlled, can create a problem. 

o 3.1 Inefficiency of Selective Network Filtering of All Tunneled Packets
=> Non applicable because no FW is traversed

o 3.2. Problems with deep packet inspection of tunneled data packets
=> Non applicable because no FW is traversed (deep packet inspection can apply to decapsulated packets independently of their having been tunneled).

o 4.1 to 4.3 (NAT Holes Increase Attack Surface, Exposure of a NAT Hole, Public Tunnels Widen Holes in Restricted NATs)
=> Non applicable because no NAT is traversed

o 5.1 and 5.2 (Feasibility of Guessing Tunnel Addresses, Profiling Targets Based on Tunnel Address)
=> Non applicable because encapsulation headers add no information that isn't present in encapsulated headers

o 6.1. Attacks Facilitated By Changing Tunnel Server Setting
=> Non applicable in 6to4 to 6to4 because tunnel addresses are purely algorithmic (without any parameter).
=> 6rd is as reliable in this respect as the mechanism used to convey ISP parameters to hosts, e.g. DHCP.
NOTE: IMHO, the reference to draft-ietf-v6ops-tunnel-loops would better be in a separate paragraph than in a sentence at the end of this section (minor point).

In my understanding, this confirms that these two scenarios can reliably be deployed.
Thank you for correcting me if I missed something.

Regards,
RD

Le 21 oct. 2010 à 19:30, internet-drafts@ietf.org a écrit :

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations Working Group of the IETF.
> 
> 
> 	Title           : Security Concerns With IP Tunneling
> 	Author(s)       : S. Krishnan, et al.
> 	Filename        : draft-ietf-v6ops-tunnel-security-concerns-03.txt
> 	Pages           : 19
> 	Date            : 2010-10-21
> 
> A number of security concerns with IP tunnels are documented in this
> memo.  The intended audience of this document includes network
> administrators and future protocol developers.  The primary intent of
> this document is to raise the awareness level regarding the security
> issues with IP tunnels as deployed today.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-security-concerns-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <Pièce jointe Mail>_______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

[v6ops] draft-ietf-v6ops-tunnel-security-concerns-04 - applicability to 6to4 and 6rd