Review of 'draft-ietf-v6ops-tunnel-security-concerns-02'
"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 22 July 2010 15:42 UTC
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EC13A6814 for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 22 Jul 2010 08:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.086
X-Spam-Level:
X-Spam-Status: No, score=-4.086 tagged_above=-999 required=5 tests=[AWL=-1.591, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_44=1, J_BACKHAIR_46=1, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-PvSIlqfzim for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 22 Jul 2010 08:42:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C40A3A67B3 for <v6ops-archive@lists.ietf.org>; Thu, 22 Jul 2010 08:42:42 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Obxm7-000JqU-32 for v6ops-data0@psg.com; Thu, 22 Jul 2010 15:33:31 +0000
Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <Fred.L.Templin@boeing.com>) id 1Obxm3-000Jpk-Sn for v6ops@ops.ietf.org; Thu, 22 Jul 2010 15:33:28 +0000
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o6MFXOCb010101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <v6ops@ops.ietf.org>; Thu, 22 Jul 2010 08:33:25 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o6MFXOgL015457 for <v6ops@ops.ietf.org>; Thu, 22 Jul 2010 08:33:24 -0700 (PDT)
Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o6MFXOYq015429 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <v6ops@ops.ietf.org>; Thu, 22 Jul 2010 08:33:24 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Thu, 22 Jul 2010 08:33:23 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: IPv6 Operations <v6ops@ops.ietf.org>
Date: Thu, 22 Jul 2010 08:33:21 -0700
Subject: Review of 'draft-ietf-v6ops-tunnel-security-concerns-02'
Thread-Topic: Review of 'draft-ietf-v6ops-tunnel-security-concerns-02'
Thread-Index: AcsprIZO4Pi5Eh+MTD6r2KIAnuIEHwABiohA
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A649E152296E@XCH-NW-01V.nw.nos.boeing.com>
References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie> <E1626B04-D81C-466C-9D18-AC1690FADB1C@tony.li> <4C484AE6.9020400@inex.ie>
In-Reply-To: <4C484AE6.9020400@inex.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
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:"
- draft-azinger-cidrv6-00 Leo Vegoda
- Re: draft-azinger-cidrv6-00 Tony Li
- Re: draft-azinger-cidrv6-00 Nick Hilliard
- Re: draft-azinger-cidrv6-00 Brian E Carpenter
- Re: draft-azinger-cidrv6-00 Tony Li
- Re: draft-azinger-cidrv6-00 Fred Baker
- Re: draft-azinger-cidrv6-00 Fred Baker
- Re: draft-azinger-cidrv6-00 Nick Hilliard
- Review of 'draft-ietf-v6ops-tunnel-security-conceā¦ Templin, Fred L
- Re: draft-azinger-cidrv6-00 David Conrad
- RE: draft-azinger-cidrv6-00 Templin, Fred L
- Re: draft-azinger-cidrv6-00 Tony Li
- Re: draft-azinger-cidrv6-00 Tony Li
- RE: draft-azinger-cidrv6-00 Templin, Fred L