Re: [v6ops] New draft version (was: Re: Stewart Bryant's Discuss on draft-ietf-v6ops-tunnel-loops-03: (with DISCUSS))

[Fred Baker <[e-mail]>]

Well, as you requested, we'll discuss the updates at IETF-80 in the working group, and then advise the AD to continue if the working group buys into the updated draft.

On Mar 9, 2011, at 2:30 PM, Fred Templin wrote:

> Hello,
> 
> We have submitted a -04 draft version:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-04.txt
> 
> Changes in this version are:
> 
>   1) Section 1: clarification that only non-link-local prefixes are vulnerable, since
>       link-locals cannot be forwarded by an IPv6 router.
> 
>   2) Section 2: text and diagram updates to clarify packet flows
> 
>   3) New Section 3.2.4 added.
> 
> Items 1) and 2) above represent only very minor changes to what has already
> been reviewed by this distribution. Item 3) however includes a major new
> section with a mitigation that avoids the looping scenario by not assigning
> non-link-local IPv6 prefixes to the tunnel. This method is available only to
> ISATAP, and requires updates to RFC5214.
> 
> Please advise as to next steps,
> 
> Fred & Gabi
> 
> From: Fred Templin <[e-mail]>
> To: Gabi Nakibly <[e-mail]>; [e-mail]
> Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]
> Sent: Tue, February 22, 2011 5:31:27 AM
> Subject: Re: Stewart Bryant's Discuss on draft-ietf-v6ops-tunnel-loops-03: (with DISCUSS)
> 
> Hi Gabi,
> 
> As we are working on a major new subsection for the document that may well
> address the remaining concerns, I would rather we not press Stewart or the
> other reviewers until we agree on a way forward after I return from my vacation
> on 2/28 - OK?
> 
> Thanks - Fred
> 
> From: Gabi Nakibly <[e-mail]>
> To: [e-mail]
> Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]
> Sent: Mon, February 21, 2011 9:17:22 AM
> Subject: Re: Stewart Bryant's Discuss on draft-ietf-v6ops-tunnel-loops-03: (with DISCUSS)
> 
> Hi Stewart,
> We have yet to receive from you a response to our last email.
> 
> Gabi 
> 
> 
> 
> ----- Original Message ----
> > From: Gabi Nakibly <[e-mail]>
> > To: [e-mail]
> > Cc: The IESG <[e-mail]>; [e-mail]; 
> >[e-mail]
> > Sent: Sun, February 13, 2011 8:48:37 PM
> > Subject: Re: Stewart Bryant's Discuss on draft-ietf-v6ops-tunnel-loops-03: 
> >(with DISCUSS)
> > 
> > Hi Stewart,
> > 
> > >So are you saying that R1 lies to R2 about what it can reach, then    when R1 
> 
> > >actually gets a packet addressed to the address it lied    about, it forwards 
> 
> > >the packet to another router?
> > 
> > No. This is not what we are saying. Let me try again.  R2 receives an IPv6 
> > attack packet (this is packet #0 in the draft). The IPv6 destination address of 
> >
> > the packet has the prefix of T2. This is why R2 automatically encapsulates the 
> 
> > packet with the corresponding IPv4 destination address and forwards it. It does 
> >
> > so while not being aware of the fact that a node with that IPv6 destination 
> > address does not exist. The attacker chooses this IPv6 address so that the 
> > corresponding IPv4 address will be that of R1. R1 is passive. In particular it 
> 
> > does not lie about its IPv6 reachability. Once the packet reaches R1 it 
> > decapsulates it and examines the IPv6 destination address. Since this address 
> >is 
> >
> > not its own it forwards it.
> > 
> > >
> > >Of course that will form a loop, and the fix is either (preferably)    for R1 
> 
> > >not to tell lies, or if it must tell lies, to have the good    grace to drop 
> > >the packet who's address it lied about. That is just    routing 101.
> > >
> > >However the problem with the original sentence is that it is not    parsable
> > >English.  
> > >
> > >
> > >Are you saying:
> > >
> > >The attacker exploits the fact that R2 is unaware that R1 is    indicating 
> > >reachability for an address (a subset of the prefix it is    ) that it is 
> > >actually unable to reach.
> > >
> > >or maybe 
> > >
> > >Although R1 is indicating to R2 that it can reach a prefix (T2),    unbeknown 
> 
> > >to R2, R1 can only actually reach a subset of the    addresses contained 
> >within 
> >
> > >
> > >that  prefix. The attacker exploits the    fact that under these circumstances 
> >
> > 
> > >R1 will forward the unreachable    packets that it claimed it could reach into 
> >
> > 
> > >a part of the network    such that they will loop back to R1.
> > >
> > 
> > >You have two diagrams - a connectivity diagram and an encapsulation
> > >diagram. It would be a lot clearer if you had a single diagram
> > >showing the packet at each stage of its lifecycle round the loop.    Then
> > >of course words to match.
> > >
> > >At the moment the reader  needs to hold too much in your head to see    what 
> >is 
> >
> > >
> > >happening.
> > 
> > To make this easier to read we shall add the packet ids on Figure 1 and their 
> > direction in which they traverse.
> > >
> > >Yes, but a router must never advertise an address that it cannot    reach 
> > >(period).
> > 
> > As I said above, R1 does not advertise an IPv6 prefix (at least not one that 
> > relates to the attack). R2 advertises an IPv6 prefix as assigned to him by the 
> 
> > administrator. This advertisement is valid since R2 can reach hosts having 
> > addresses within this prefix. However, as all other routers on the Internet it 
> 
> > does not check whether all the addresses of this prefix are indeed assigned to 
> 
> > valid hosts. The attacker takes advantage of the fact that there are some 
> > addresses (at least one) in this prefix which are not assigned to valid hosts.
> > 
> > 
> > 
> >____________________________________________________________________________________
> >_
> > Sucker-punch spam with award-winning protection. 
> > Try the free Yahoo! Mail Beta.
> > http://advision.webevents.yahoo.com/mailbeta/features_spam.html
> > 
> 
> 
>