Comments on draft-ietf-v6ops-tunnel-security-concerns

[Fernando Gont <fernando@gont.com.ar>]

Folks,

* Abstract (nit):

> The primary intent of
>    this document is to raise the awareness regarding the security issues
>    with IP tunnels as deployed today.

s/the awareness/awareness/


* Section 2.1.3:

>    Security administrators who do not consider tunneling an acceptable
>    risk should disable tunnel functionality either on the end-nodes
>    (hosts) or on the network nodes.  However, there may be an awareness
>    gap.  Thus, due to the possible negative security consequences, we
>    recommend that explicit user action be required to enable tunneling,
>    at least for the first time.

If tunnels are a concern to the secadmin, they should be disabled at the
perimeter. The sec admin has no control over, e.g. a user that connects
his laptop to the enterprise network.


* Section 2.1.3

>    For example, when Teredo is being enabled or when it is going to be
>    used for the first time, there could be a descriptive warning about
>    the possible reduction of defense in depth that will occur.

This makes sense for a technically-savvy user. The typical non-technical
user will simply press "Ok".


* Section 2.2.2

You never talk about filtering incoming packets based on their source
address. i.e., you should not allow packets with a source address that
belongs to your network to enter your network from the outside.


* Section 2.2.3

>    Tunnel clients should by default discard tunneled IP packets that
>    specify additional routing, as recommended in [RFC5095], though they
>    may also allow the user to configure what source routing types are
>    allowed.  All pre-existing source routing controls should be upgraded
>    to apply these controls to tunneled IP packets as well.

RFC 5095 talks about IPv6 "source routing". You should also be concerned
about IPv4 source routing. See:
* http://www.cpni.gov.uk/Docs/InternetProtocol.pdf
* draft-ietf-opsec-ip-security


* Section 3.1.3

You don't mention filtering proto 41 packets


* Section 3.2.2

>    For some protocols, it may be possible to monitor setup exchanges to
>    know to expect that data will be exchanged on certain ports later.
>    (Note that this does not necessarily apply to Teredo, for example,
>    since communicating with another Teredo client behind a cone NAT
>    device does not require such signaling.  However, deprecation of the
>    cone bit as discussed in [RFC4380] means this technique may indeed
>    work with Teredo.)

Even with deprecation of the cone-bit, you don't want a user with a
customized or legacy Teredo implementation to bypass these controls. So
security-wise, this control "does not work".


* Section 4.2.2:

>    2.  In some protocols (e.g., Teredo), the external IP address and
>        port are contained in the client's address that is used end-to-
>        end and possibly even advertised in a name resolution system.
>        While the tunnel protocol itself might only distribute this
>        address in IP headers, peers, routers, and other on-path nodes
>        still see the client's IP address.  Although this point does not
>        apply directly to protocols (e.g., L2TP) that do not construct
>        the inner IP address based on the outer IP address, the inner IP
>        address is still known to peers, routers, etc. and can still be
>        reached by attackers without knowing the external IP address or
>        port.

This is actually worse: the addresses might be stamped in, e.g. SMTP
envelopes. See Fred Baker's I-D on greynets.


Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1