Teredo Security Updates
RFC 5991

[Ballot discuss]
Given the importance of random number generation to this specification,
and our long and sad experience with bad RNGs in various implementations,
I would really like to see a discussion of this topic in the security
considerations with pointers to one or more informational references on
techniques for good RNGs.

Here are a couple of references that I am aware of:

NIST SP 800-90, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, March 2007.
http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf

ANSI X9.82-1:2006, Random Number Generation Part 1: Overview and Basic Principles

ANSI X9.82-3:2007, Financial Services - Random Number Generation Part 3: Deterministic Random Bit Generators

[There are certainly others, and I am not hung up on which references
you choose!]

[Ballot comment]
The first paragraph in the Security Considerations section states the
  goal of comparable address prediction resistance with respect to a
  host directly attached to an untrusted Internet link, but nothing in
  the Security Considerations section indicates how close the technique
  in this document comes to achieving that goal.  A short discussion of
  the 13 random bits and this goal should be added.

[Ballot discuss]
This document is clearly intended to update RFC 4380.  An RFC Editor
  note already adds "Updates: 4380" to the left side of the title page.
  Please revise the first paragraph of the Introduction to indicate
  that this document updates RFC 4380.

[Ballot comment]
Section 3.2 uses acronyms RA and RS; please expand them on first use.

  The first paragraph in the Security Considerations section states the
  goal of comparable address prediction resistance with respect to a
  host directly attached to an untrusted Internet link, but nothing in
  the Security Considerations section indicates how close the technique
  in this document comes to achieving that goal.  A short discussion of
  the 13 random bits and this goal should be added.

[Ballot discuss]
This document is clearly intended to update RFC 4380.  Please add
  "Updates: 4380 (once approved)" to the left side of the title page.
  Please revise the first paragraph of the Introduction to indicate
  that this document updates RFC 4380.

  Please add "Intended status: Standards Track" to the left side of
  the title page.

I have reviewed this draft and have the following comments. In general, the draft is in good shape and can move forward. I have two small technical issues and a few minor editorial ones. Nevertheless, I have decided to initiate last call, but I would appreciate a quick document update in the next few days to correct these issues.

Technical:
> Teredo Client: A node that has access to the IPv4 Internet and wants
> to gain access to the IPv6 Internet.
There are lots of such nodes, but not all of them are Teredo clients, i.e., implement the Teredo protocol... please correct the definition.

> Opening a hole in an enterprise firewall
> [I-D.ietf-v6ops-tunnel-security-concerns]: Teredo is NOT RECOMMENDED
> as a solution for managed networks.  Administrators of such networks
> may wish to filter all Teredo traffic at the boundaries of their
> networks.

I'm not sure the term "managed networks" is a correct one here. There are many types of managed networks, some care about blocking Teredo and some would not. Suggested rewrite:

"Opening a hole in an enterprise firewall [I-D.ietf-v6ops-tunnel-security-concerns]: Teredo is NOT RECOMMENDED as a solution for networks that wish to implement strict controls for what traffic passes to and from the Internet.  Administrators of such networks may wish to filter all Teredo traffic at the boundaries of their networks."

(Also, speaking personally, I may not completely agree with the conclusions from draft-ietf-v6ops-tunnel-security-concerns that inspection of tunneled traffic is always hard and inefficient. I think there is some room to allow firewalls to inspect tunneling traffic on top of well-known and established tunneling protocols such as Teredo.)

Editorial:

> Teredo IPv6 Address: An IPv6 address that starts with the prefix
> 2001:0000:/32 and is formed as specified in [RFC4380] section 2.14.

Wouldn't Section 4 be a better reference here?

> Teredo addresses are structured and some of the fields contained in
> them are fairly predictable.  This can be used to better predict the
> address.

I would rewrite the second sentence (which currently doesn't say much) as follows: "This makes it easier to predict an address, opening a (small) vulnerability."

>    open on a IPv4 address, prior to trying to form a Teredo address for
s/on a/on an/

> 4. Acknowledgments
> ....
> 5. Security Considerations

I think it would be better if all the technical parts of the document were explained first, followed by the acknowledgment section. That is, I think Section 5 would come more naturally before Section 4.

PROTO writeup for:
draft-thaler-v6ops-teredo-extensions-06.txt and
draft-krishnan-v6ops-teredo-update-06.txt

  (1.a)  Who is the Document Shepherd for this document?

These are individual AD-sponsored submissions.  RFC 4858 only specifies
document shepherds for WG documents.  Per Jari's suggestion, I'm
answering these questions as if I were the shepherd.

          Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Yes.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

These documents were discussed within and reviewed by the V6OPS WG
(being the successor to NGTRANS which published RFC 4380, which these
update/extend), and went through two pseudo-WGLCs:
http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00007.html
http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01408.html

Comments were received on the public list from Remi Denis:
http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01183.html
http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01415.html
and from a bunch of others privately to the authors.

These drafts are I-D versions of a document [MS-TERE] that has been
hosted on a Microsoft site
(http://msdn.microsoft.com/en-us/library/cc247482(PROT.13).aspx)
where it has been subject to detailed review by:

* The Technical Committee (thetc.org) which is an independent
  organization tasked by the US government with reviewing and quality
  checking/reporting of Microsoft protocol documents, and

* compliance test suite developers who developed tests from the
  document and verified that the widely deployed implementation
  matches the spec, and

* by network sniffer developers who have written parsers for it. 

Much feedback from those communities has also been addressed before and
during the WGLCs.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No concerns.

draft-krishnan-v6ops-teredo-update is a result of detailed security
reviews of RFC 4380, independently by both Symantec and Microsoft.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.

No concerns.

          Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

Yes.

The base Teredo RFC (RFC 4380) was in the same position when it was
approved as a Proposed Standard:
  https://datatracker.ietf.org/ipr/129/
where the declaration states it's RAND-Z for standards-track IETF documents.

The intent is that the extensions and security updates have the same
status as RFC 4380.  The disclosure on draft-thaler-v6ops-teredo-extensions
is:
  https://datatracker.ietf.org/ipr/1022/

The disclosures on draft-krishnan-v6ops-teredo-update is:
  https://datatracker.ietf.org/ipr/1042/

The declarations are again RAND-Z for standards track.

As such, the V6OPS WG saw no issues with the extensions and the security
update having the same status as the base protocol, and it being
Proposed Standard.


  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There were not V6OPS WG documents, but the V6OPS WG reviewed them due
to the original Teredo protocol being an NGTRANS output.  Within V6OPS,
they represent the strong concurrence of a few knowledgeable individuals,
with others being silent.  Both drafts are also widely deployed.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No such threats or appeals.


  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)

          Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?

Yes.  (And there is no MIB, media type, or URI type.)

          If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Intended Status:  Proposed Standard


  (1.h)  Has the document split its references into normative and
          informative?

Yes.

          Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

All normative references are upward references, and all are RFCs.


  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?

Yes.

          If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?

No reservations are necessary.

          Are the IANA registries clearly identified?

N/A.

          If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?

The documents do not create a new IANA registry.

          Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

N/A.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no sections written in a formal language.


  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

draft-thaler-v6ops-teredo-extensions specifies a set of extensions to
the Teredo protocol.  These extensions provide additional capabilities
to Teredo, including support for more types of NATs, and support for
more efficient communication (fewer signaling packets).

draft-krishnan-v6ops-teredo-update specifies a set of security updates
for Teredo that mitigate a number of security concerns.  Specifically,
the Teredo protocol defines a set of flags that are embedded in every
Teredo IPv6 address, and this document modifies the use of this flags
field in a backwards compatible way.

Microsoft's own spec [MS-TERE] combined teredo-update and
teredo-extensions, and the same IPR (RAND-Z) declaration
applies to both.  However, the teredo-update and teredo-extensions
docs are now separate to reflect V6OPS consensus that they should be separate:

1) The former addresses the security concerns raised with
  the original RFC, while the latter adds new functionality

2) Hence teredo-update needs to UPDATE 4380, the latter
  need not be listed as such once published as an RFC.

It's also worth noting that a third document
(draft-ietf-v6ops-tunnel-security-concerns, which is not part of this
publication request) discusses security issues and potential mitigations
regarding tunneling more generally, which were identified in the security
reviews of Teredo and other protocols, and is informatively referenced
by draft-krishnan-v6ops-teredo-update. 
draft-ietf-v6ops-tunnel-security-concerns has undergone SECDIR review,
and can be treated as further elaboration on the security considerations
sections of any tunneling protocol document.  Hence the security
considerations sections of the two documents being put forward for
publication now were deemed sufficient for those documents, given this
informative reference.

The third document was originally a V6OPS WG document because it
specifies no protocol behavior, just discusses issues, and because it
was about IPv6 tunneling.  However, the scope of the document was then
broadened to apply to any types of tunneling (not just IPv6), and
that's why it was since moved to (and was reviewed in) INTAREA, where
the discussion was about whether to merge it with Joe Touch's draft
on tunneling issues unrelated to security.  Based on INTAREA discussion,
the consensus was that the community had no preference and it was up to
the authors.  Neither the authors nor Joe Touch had a preference either,
and so the decision was made to keep them separate in the interests of
avoiding useless work in merging them.


          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

No rough areas.

draft-krishnan-v6ops-teredo-update is closely related to
draft-thaler-v6ops-teredo-extensions.  The "Teredo update"
is a set of simple security fixes to the base Teredo protocol
to reflect what actually got implemented and deployed.
(The history is that Symantec originally wrote the security concerns
document and made a number of security recommendations, which mostly
match what Vista and Windows 7 actually do, and the recommendations
were what then became teredo-update.  When the WG reviewed the
recommendations, the only ones that had WG consensus turned out to
be the same ones that Vista and Windows 7 did, and the other things
were either removed or made MAY's to reflect WG consensus.)


          Document Quality
            Are there existing implementations of the protocol?

Yes.

            Have a
            significant number of vendors indicated their plan to
            implement the specification?

Only one "full" implementation is known to exist - Windows 7 includes
all extensions specified, and Vista includes almost all of them.  However,
separate partial implementations were done by test suite compliance
developers and parser developers.


            Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?

Remi Denis made very useful comments publically during the WGLCs.  In addition, the TC previously did thorough reviews.


            If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

N/A

          Personnel
            Who is the Document Shepherd for this document?

These are individual AD-sponsored submissions.  RFC 4858 only specifies
document shepherds for WG documents.  Per Jari's suggestion, I'm
answering these questions as if I were the shepherd.


            Who is the
            Responsible Area Director?

Jari Arkko, jari.arkko@piuha.net


            If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'


The documents don't require IANA experts as there are no IANA actions.



  The Document Shepherd MUST send the Document Shepherd Write-Up to the
  Responsible Area Director and iesg-secretary@ietf.org together with
  the request to publish the document.  The Document Shepherd SHOULD
  also send the entire Document Shepherd Write-Up to the working group
  mailing list.  If the Document Shepherd feels that information which
  may prove to be sensitive, may lead to possible appeals, or is
  personal needs to be written up, it SHOULD be sent in direct email to
  the Responsible Area Director, because the Document Shepherd Write-Up
  is published openly in the ID Tracker.  Question (1.f) of the
  Write-Up covers any material of this nature and specifies this more
  confidential handling.