Subject: Re: [secdir] secdir review of draft-krishnan-v6ops-teredo-update-03

From: Suresh Krishnan <[email-masked]>
Date: Sun, 12 Oct 2008 23:48:29 -0400

Hi Tom,
   Thank you very much for your detailed review and sorry for the long
delay in our response. We have modified the draft to address some of
your concerns. We also had a few questions for you. Please find our
responses inline.

Tom Yu wrote:
> This document does not clearly identify its threat model.  In its
> Security Considerations, it mentions scanning for IPv6 addresses,
> particularly if the external IPv4 address and port number are known.
> I assume that the threat is an off-path attacker, because an on-path
> attacker could directly view all of the relevant IPv4 and IPv6
> addresses.  An off-path attacker is somewhat less likely to know the
> external UDP port number of the Teredo client, though.  Somewhat less
> clear is whether the document assumes that the attacker lacks IPv4
> connectivity.

We have added the following text to the Security Considerations section

"  The basic threat model for Teredo is described in detail in [RFC4380]
    section 7, but briefly the goal is that a Teredo client should be as
    secure as if a host were directly attached to an untrusted Internet
    link.  This document specifies updates to [RFC4380] that improve the
    security of the base Teredo mechanism regarding specific threats."

We have added the following text as a precise description of the threats

"IPv6 address scanning [RFC5157] by off-path attackers:" for the
paragraph starting with "The Teredo IPv6 Address format defined in
[RFC4380] section 4..."

and

"Opening a hole in an enterprise firewall
[I-D.ietf-v6ops-tunnel-security-concerns]:" for the paragraph starting
with "Teredo is NOT RECOMMENDED as a solution for managed networks."

> 
> I can infer from the Security Considerations text that one threat is
> an attack targeting vulnerabilities in IPv6-listening application
> software running on a Teredo client.  I can infer an additional
> possible threat is an attack targeting vulnerabilities in the IPv6
> stack implementation of a Teredo client.  Malicious creation of new
> mappings on the (non-full cone) NAT may also be a threat.
> 
> An attack could target the Teredo client implementation directly, but
> this might not require guessing the Teredo IPv6 address if the
> attacker has IPv4 connectivity.  Also, it appears that the Teredo
> client implementation is primarily responsible for validating the
> random number contained in the flags, so the flag randomization
> procedure described in this document will not defend against this sort
> of attack.

The attack surface in these two cases (attacking through Teredo and
attack through direct IPv4) is different. The document only addresses
the issues introduced by Teredo and not the generic IPv4 issues. The 
Teredo RFC (RFC4380) covers more threats to Teredo and this draft only 
augments it with respect to specific threats.

> 
> If the attacker lacks direct IPv4 connectivity, and the transited
> Teredo servers or Teredo relays validate the randomized flag bits, the
> malicious packets may be successfully blocked before they reach the
> Teredo client's IPv4 stack.  This requires additional state on the
> Teredo server, but possibly not on a Teredo relay.

A Teredo server cannot be used by an IPv6-only attacker to transit
any packets, since a Teredo server has no such functionality.
We are not aware of any way for a relay to 'validate'
the randomized bits in any useful and backwardly compatible way.

> 
> Increasing the IPv6 address range by a factor of 4096 seems like a
> reasonable approach for reducing the exposure of a Teredo client to
> IPv6 address scanning.  It also moderately increases the difficulty of
> using Teredo to maliciously create new NAT mappings.  This flag
> randomization does remove (except for one bit) all remaining
> possibility for future extension of the Teredo addressing format,
> which may be an acceptable tradeoff.

You are right. The consensus was that this is an acceptable tradeoff.

> 
> Deprecation of the cone bit seems like a good way of reducing the
> exposure of information about the security policy of the NAT.  An
> attacker with direct IPv4 connectivity could probably directly probe
> whether the NAT is a full-cone NAT, though.
> 
> Should this document reference (either normatively or informatively)
> draft-ietf-v6ops-tunnel-security-concerns-00, which appears to cover
> some of the possible threats not mentioned explicitly in this
> document?

You are right. We have added a reference to
draft-ietf-v6ops-tunnel-security-concerns-00 along with the specific
cases for which it is required.

Thanks
Suresh

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir