Re: draft-nakibly-v6ops-tunnel-loops-03

[Fred Baker <fred@cisco.com>]

Let me repeat a question I asked before. Gaki reminds me that we discussed, in June, adoption of his document as a WG draft. It escaped my mind with the hubbub of the IETF meeting. There were several comments that it should be adopted as a working group draft. Are there at this time any objections? Barring any, I'll have him re-post as a working group draft.

On Aug 19, 2010, at 11:46 AM, Gabi Nakibly wrote:

> Hi Fred,
> 
> Thanks for your input.
> 
> Regarding the new revision of the draft, I would like to remind you that a few 
> weeks ago I have requested you and the WG to adopt the draft as a WG item. It 
> has received positive reviews from Mark Townsley and Brian Carpenter. Following 
> the feedback we revised the draft - we removed a mitigation measure and added a 
> new Recommendations section that clarifies which measures should be exercised 
> under various conditions. The reviewers support adopting the draft once their 
> comments are addressed.
> 
> Regarding the purpose of the draft, I definitely agree with you that the end 
> game is native IPv6. But as Brian commented, tunnels will be around for a while, 
> 
> weather we like it or not. So I think it would be prudent to have an 
> informational RFC that at least informs the community on the loop problem and to 
> 
> advice on measures to mitigate it (true - these are not perfect measures, but 
> they do the job). Otherwise operators might jeopardize their networks when 
> deploying the tunnels. I agree that a document is valuable only if it helps 
> people to deploy IPv6. But I would add - deploy securely (I note item #2 of the 
> v6ops charter). We certainly do not want people to suspect that IPv6 puts their 
> networks at risk. I believe that the draft helps people deploy IPv6 more 
> securely. 
> 
> 
> I would like to note that 6rd is also vulnerable to the attack. Following 
> discussions with Remi on the list a few months back, proper mitigation measures 
> were devised for 6rd as documented in the Security Considerations of RFC 5969. I 
> 
> think that appropriate mitigation measures for other tunnels should be also 
> devised.
> 
> As I understand, the ball is in your court. I truly hope that you decide on the 
> adoption of the draft as a WG item.
> 
> Thanks,
> Gabi
> 
> ----- Original Message ----
>> From: Fred Baker <fred@cisco.com>
>> To: Gabi Nakibly <gnakibly@yahoo.com>
>> Sent: Wed, August 18, 2010 10:20:06 PM
>> Subject: Re: draft-nakibly-v6ops-tunnel-loops-03
>> 
>> Thanks.
>> 
>> In the note I just sent to v6ops, I noted that you didn't present at IETF 78 
>> and that there had not been significant working group discussion on this on the 
> 
> 
> 
> 
> 
>> list, and suspected that you were done with it.
>> 
>> http://tools.ietf.org/rfcdiff?url2=draft-nakibly-v6ops-tunnel-loops-03.txt 
>> shows some changes, mostly minor editing and a rework of section 3.3 into 
>> section 4.
>> 
>> I'll give you my personal bias, just so that I'm perfectly transparent. I think 
>> 
>> 
>> 
>> 
>> 
>> this document and Suresh's document highlight a very basic concern, which is 
>> that IPv6 routing is in these cases completely disjoint from IPv4 routing, and 
>> they are opaque to each other, but they are not independent. If IPv6 routing is 
> 
> 
> 
> 
> 
>> going to depend on IPv4 routing, something true of all IPv6/IPv4 solutions, it 
>> would be much nicer if they were also linked, as I would argue is the case with 
> 
> 
> 
> 
> 
>> 6rd. I don't think you're going to fix the issues until they are.
>> 
>> I also think that the end game is not to perfect the coexistence mechanisms, 
>> but to make the transition. Anything that keeps people busy doing something 
>> besides native IPv6 deployment is only valuable if it helps them to deploy. 
>> 
>> 
>> In any event, thanks for reposting, and let's discuss it on the list.
>> 
>> On Aug 18, 2010, at 12:00 PM, Gabi Nakibly wrote:
>> 
>>> A new version of draft-nakibly-v6ops-tunnel-loops has been posted.
>>> The new version follows the comments given on the list.
>>> The major change is the addition of a Recommendation section 
>>> that recommends preferred mitigation measures under different conditions.
>>> 
>>> Gabi
>>> 
>>> 
>>> ----- Forwarded Message ----
>>>> From: IETF I-D Submission Tool <idsubmission@ietf.org>
>>>> To: gnakibly@yahoo.com
>>>> Cc: fltemplin@acm.org
>>>> Sent: Wed, August 18, 2010 9:46:46 PM
>>>> Subject: New Version Notification for draft-nakibly-v6ops-tunnel-loops-03
>>>> 
>>>> 
>>>> A new version of I-D, draft-nakibly-v6ops-tunnel-loops-03.txt has been 
>>>> successfully submitted by Gabi Nakibly and posted to the IETF repository.
>>>> 
>>>> Filename:    draft-nakibly-v6ops-tunnel-loops
>>>> Revision:    03
>>>> Title:        Routing Loop Attack using IPv6 Automatic Tunnels: Problem 
>>>> Statement and Proposed Mitigations
>>>> Creation_date:    2010-08-18
>>>> WG ID:        Independent Submission
>>>> Number_of_pages: 11
>>>> 
>>>> Abstract:
>>>> This document is concerned with security vulnerabilities in IPv6-in-
>>>> IPv4 automatic tunnels.  These vulnerabilities allow an attacker to
>>>> take advantage of inconsistencies between a tunnel's overlay IPv6
>>>> routing state and the native IPv6 routing state.  The attack forms a
>>>> routing loop which can be abused as a vehicle for traffic
>>>> amplification to facilitate DoS attacks.  The first aim of this
>>>> document is to inform on this attack and its root causes.  The second
>>>> aim is to present some possible mitigation measures.
>>>>                                                                               
>> 
>> 
>> 
>> 
>> 
>>   
>> 
>>>>   
>>>> 
>>>> 
>>>> 
>>>> The IETF Secretariat.
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
>