Subject: I-D ACTION:draft-ietf-v6ops-teredo-security-concerns-00.txt

From: [email-masked]
Date: Mon, 30 Jul 2007 13:15:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Teredo Security Concerns
	Author(s)	: J. Hoagland, S. Krishnan
	Filename	: draft-ietf-v6ops-teredo-security-concerns-00.txt
	Pages		: 21
	Date		: 2007-7-30
	
   Additional security concerns with Teredo are documented, beyond what
   is in RFC 4380.  This is based on an independent analysis of Teredo's
   security implications.  The primary intent of this document is to
   provide information and recommendations to the IETF that can be used
   in any updated Teredo specification.  The second intended audience is
   anyone that can help improve security in Teredo as deployed, so they
   will be aware of these concerns.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-teredo-security-concerns-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-v6ops-teredo-security-concerns-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-teredo-security-concerns-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 30 Jul 2007 22:12:59 +0300

> 	Filename	: draft-ietf-v6ops-teredo-security-concerns-00.txt

Some comments (some probably already made):

* Section 2.1 says:
  "When Teredo is being enabled or when it is
   going to be used for the first time, perhaps there should be a
   descriptive warning about the possible evasion that will occur."

That feels really intractable in practice. I understand it's a "should 
perhaps", but I doubt anyone's ever going to implement this, really.

* Section 2.2: not at all clear to me what the recommendations mean to 
Teredo clients. The protocol already includes quite a bunch of sanity 
checks on IPv6 addresses. If anything, what should additionaly be done 
needs to be clarified.

* Section 2.3 on source routing should be slimmed down; the 
Recommendations should consist of following 
draft-ietf-ipv6-deprecate-rh0, which need to be Reference'd.

* Sections 4.1, 4.2, 4.3: In theory, bringing up the service only when 
needed is a good idea. This is however a bit vague. The only way I can 
think of doing this without wreaking havoc to the normative 
non-blocking-ness of getaddrinfo() from the Basic IPv6 API, is to bring 
the Teredo tunnel whenever there is no other global IPv6 connectivity.

That however is a very objectable idea, as it effectively suppress the 
idea of "host-specific" relays. As such, the real "global" Teredo 
relays would be used even when they could be avoided, which is bad 
considering they are a bottleneck already.

Whether this means that or something else, I think it would need 
clarifications.

* Section 5.1: Flag randomization is a protocol update. I personnaly do 
not care whether the working group is chartered for it, or not. It 
still is a protocol update.

I suppose, the draft needs to target Standard Tracks and tentatively 
Update RFC4380 for this to stand.

I cannot say I think burning out all but one of the reserved flags was a 
terrible idea, but, oh well, it's done by the de facto monopoly client 
implementation.

* Section 5.2: exact same remark. Deprecating the Cone bit is a protocol 
update. Besides, this has implications to the qualification procedure, 
so it cannot be that simple. (I agree it should be done however).

Best regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/