Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations
draft-ietf-v6ops-tunnel-loops-07

[Ballot discuss]
I do not understand what "The attacker exploits the fact that R2 does not know that R1 does not take part of T2" means.

I have tried to read section 2 a number of times and I do not understand the loop. Please re-write this section so that it clearly shows how the loop forms. When I understand how the loop forms, I will re-read the document and may have further comments.

I am concerned that R2 seems to be advertising reachability to an address that it cannot reach. It is fundamental to routing that routers must always tell the truth about what they can reach and if they do not do this loops and black holes form.

[Ballot discuss]
The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
  that has not been answered.  I think that a response is needed.

  Joel says:
  > It is unclear in the document what assumptions section 3.1 makes
  > about the relationship between supported tunnels and checked
  > embedded addresses.  Is there an assumption that the router only has
  > to check for addresses in the format and prefix it supports?
  The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
  that has not been answered.  I think that a response is needed.

[Ballot discuss]
"based on protocol-41 encapsulation" needs a reference

I do not understand what "The attacker exploits the fact that R2 does not know that R1 does not take part of T2" means.

I have tried to read section 2 a number of times and I do not understand the loop. Please re-write this section so that it clearly shows how the loop forms. When I understand how the loop forms, I will re-read the document and may have further comments.

I am concerned that R2 seems to be advertising reachability to an address that it cannot reach. It is fundamental to routing that routers must always tell the truth about what they can reach and if they do not do this loops and black holes form.

[Ballot discuss]
Having had some time to go back and re-read this document I am now not comfortable.

1. In Figure 1, why is R2 advertising reachability to an IPv6 at all? It has only one point of attachment to the v6
  network. I think you are trying to say that there is a virtual link (v6 capable) running over the v4 network. Isn't
  that link simply part of the v6 network?

2. Why is R2 advertising reachability to an address that is not reachable through it? You say:
      "...destined to a fictitious end point that appears to be reached via T2..."

[Ballot discuss]
This is a good document and should be published.

However, I have one concern about the described neighbor cache check
solution. First off, the document is incorrect that hosts must
continuously send RSes to keep their address configuration up to date.
More importantly, the neighbor cache is just that, a cache. A better
solution would be to probe for a neighbor and only drop the packet if
there was no response. This is already described in the document.
My suggestion would be to delete the neighbor cache check solution
entirely from the document.

I think it would also be great if this document made a stronger statement
about the IMO most important use case for automatic tunnels: broadband
home networks. These are very simple networks with just one exit router
and it would be important to highlight the significance (or lack
thereof) of the attack in this case & point to the recommended solution.

[Ballot discuss]
The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
  that has not been answered.  I think that a response is needed.

  Joel says:
  > It is unclear in the document what assumptions section 3.1 makes
  > about the relationship between supported tunnels and checked
  > embedded addresses.  Is there an assumption that the router only has
  > to check for addresses in the format and prefix it supports?
  The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
  that has not been answered.  I think that a response is needed.

[Ballot discuss]
"based on protocol-41 encapsulation" needs a reference

I have tried to read section 2 a number of times and I do not understand the loop.

I do not understand what "The attacker exploits the fact that R2 does not know that R1 does not take part of T2" means.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement
  and Proposed Mitigations'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-tunnel-loops/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-tunnel-loops/

Document Shepherd writeup for draft-ietf-v6ops-tunnel-loops-01

Prepared by Joel Jaeggli 11/16/2010

1.a

Joel Jaeggli v6ops wg co-chair is the document shepherd for
draft-ietf-v6ops-tunnel-loops. The document shepherd has read the
document, and concludes that as a result of comments received during
last call and subsequent changes that the document is prepared for
publication.

1.b

The document has been reviewed both in the v6ops working group and
passed last call. The document was socialized in softwire and elsewhere
work on ipv6 tunnels was performed, substantial comments were recived.

1.c

The shepherd believes that the documents conclusions are sound and a
will pass additional review.

1.d

The document shepherd has no such concerns.

1.e

WG last call generated some commentary on the draft. No opinions were
ventured that the document should not be published. The volume of
approval for the document was not huge, and we do not automatically
conclude that silence equals consent however we believe the the document
has received adequate coverage.

1.f

No appeals have been threatened or are anticipated.

1.g

The document passes idnits checking.

1.h

References are properly divided between normative and informative
references.

1.i

The document makes no requests of IANA. The IANA considerations sections
exists.

1.j

No formal language is present in the document.

1.k

Technical Summary

This document is concerned with security vulnerabilities in IPv6-in-
IPv4 automatic tunnels. These vulnerabilities allow an attacker to
take advantage of inconsistencies between the IPv4 routing state and
the 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.

Working Group Summary

The initial version of the document was published 10/20/09.
Subsequent to IETF 78 the document was accepted as a working group
document. Last call was completed on 10/12/10.

Document Quality

This work has benefited from discussions on the V6OPS, 6MAN and
SECDIR mailing lists. Remi Despres, Christian Huitema, Dmitry
Anipko, Dave Thaler and Fernando Gont are acknowledged for their
contributions.