Review of 'draft-ietf-v6ops-tunnel-security-concerns-02'

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Fred,

Please see below for my review of this document.
Fred B. suggested posting this directly to the list.

Thanks - Fred
fred.l.templin@boeing.com

Review of 'draft-ietf-v6ops-tunnel-security-concerns-02'
********************************************************

1) Section 2.1.1, on first use of the terms the document should
say more about what is meant by "defense in depth" and "security
gaps". Is it about ingress filtering? Is it about something else?

2) Section 2.2.2, please cite RFC2827 and RFC3704 upon first
mention of ingress filtering. Also check that the terms ingress
and egress are being used in the correct way. For example,
RFC2827 refers to ingress filtering as checking the outgoing
source address, which seems to be the opposite of what is being
represented in this document.

3) Section 2.2.2, sentence structure at end of first sentence.
Suggest changing to: "... are done to mitigate attacks and to
make it easier to identify the source of a packet; they are
also considered to be a good practice."

4) Throughout the document, it seems that there is an assumption
that only host<->host and host<->router tunneling is considered,
i.e., it does not seem to consider router<->router tunneling. In
particular, the use of the term "tunnel client" seems to always be
associated with a host and not another router. Is router<->router
tunneling considered as out-of-scope for this document? The
document should state the scope up front.

5) Section 3.1.2, first sentence of final paragraph, change to
"The other approach is to find tunneled packets to block in the
same way as would be done for inspecting native packets (Section
3.2)."

6) Section 3.1.2, final sentence of final paragraph, change to
"However, this faces the same difficulties..."

7) Section 3.2.2, first sentence of third paragraph, change
to "The implication of this latter case is that ..."

8) Section 3.2.3, first sentence, change to "As illustrated
above, it should be clear that inspecting the contents of
tunneled data packets that are not easily identified (e.g.,
those without a well-known UDP or TCP port) is highly
complex ..."

9) Section 4.1.2, paragraph beginning "(By the virtue of the
tunnel ... based on the outer IP.)". It seems odd to see a
new paragraph beginning with a parenthetical sentence. Also,
the paragraph itself seems to have excessive parentheticals.

10) Section 4.2.2, item 1. This concern is true not only for
tunnels but also for any service that keeps a NAT port open
indefinitely, for example through static administrative
configuration. NAT pin-holing concerns are therefore a
more broad-reaching subject and not specific to tunnels. 

11) Section 4.2.2, item 2, final sentence, this concern is
specific to the native routing and addressing of the inner
network layer protocol, so the use or non-use of tunneling
to reach the inner network layer destination is irrelevant.
Suggest removing this sentence.
  
12) Section 4.2.2, item 3, change first sentence to "The
tunnel protocol may contain more messages..." since the
use of tunneling does not always result in more messages
and longer path lengths.

13) Sections 4.1.3, 4.2.3 and 4.3.3, the recommendations
seem too broad. Minimization of some types of tunnels may
be appropriate, while use of other tunnel types may be
beneficial and not subject to these broader concerns.

14) Section 6.1, this section seems to assume reliance on
the DNS and bases some of the vulnerabilities on the
possibility for DNS spoofing. However, if the tunnel client
has a way to determine tunnel server addresses via some
secure means that does not involve the DNS then some
aspects of these vulnerabilities are mitigated. Perhaps
this can be captured in Section 6.1.3 in some way.

15) Section 7, final sentence before bulleted list, change
to "Several measures can be taken in order to secure the
operation of IPv6 tunnels, including:"