Re: Comments on draft-ietf-v6ops-tunnel-security-concerns-00.txt

[Suresh Krishnan <suresh.krishnan@ericsson.com>]

Hi Gabi,
  Thanks for your comments. Please find responses inline

Gabi Nakibly wrote:
> Hello,
> I have some general comments concerning 
> draft-ietf-v6ops-tunnel-security-concerns-00.txt.
>  
> 1) In the Introduction the draft mentions tunnels that go through NATs 
> and it seems that it is focused solely on such tunnels. However, there 
> are some security vulnerabilities discussed throughout the draft 
> (specifically in sections 2 and 3) that relate to tunnels in general. I 
> think the draft should be positioned to address tunnels in general.

We have come to the same conclusion as you and we are trying to get this 
reviewed on a broader stage (such as intarea).


> 2) What is the relation of this draft to RFC4942 ("IPv6 transition 
> security considerations")? Will it update this RFC? There is some 
> considerable overlap between section 3 of the RFC and the draft. 
> The draft elaborates on issues which are already mentioned in section 
> 3 of the RFC and there are some points mentioned in the RFC which are 
> not raised in the draft. For example, using tunnels to make sure that 
> the Hop Limit = 255. Of course, there some issues in the draft which are 
> not mentioned in the RFC.

These two documents are largely independent. 4942 mainly covers issues 
with the IPv6 transition while the tunnel sec document covers also other 
 generic tunneling related security issues. Also the tunnel sec 
document goes into more detail about the issues.

> 3) The major recommendation of the draft is in 3.1.3: "Tunneling over 
> UDP or TCP (including HTTP) to reach the Internet is  not recommended as 
> a solution for managed networks.". Why is this recommendation relevant 
> only to managed networks? It seems that in unmanaged environments (home 
> or SOHO) the use of such tunnels will have similar effects.

It is an issue since managed networks may wish to enforce some kind of 
policy on the user initiated traffic and this becomes difficult in the 
presence of tunnels.

> 4) How the above recommendation settles with the softwire group's 
> recommendation to use LT2P tunnels in the hub and spoke scenario 
> (http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2tpv2-09.txt)?

We have not looked at this document yet. Thanks for the pointer.

Thanks
Suresh