[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-nakibly-v6ops-tunnel-loops-03
Hi Fred,
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
> Sent: Thursday, August 19, 2010 11:58 AM
> To: IPv6 v6ops
> Subject: Re: draft-nakibly-v6ops-tunnel-loops-03
>
> 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.
I have no objections to posting as a wg draft.
You did not ask for feedback on the (off-list?) exchange below,
but regarding perfecting coexistence mechanisms I believe that
the IRON proposal is pretty close to having done that. IMHO, it
is worthy of a closer look.
Finally, please note that the correct spelling of my colleague's
name is "G-a-b-i" - an honorable man by my reckoning.
Thanks - Fred
fred.l.templin@boeing.com
> 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.
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
>