Review of draft-ietf-v6ops-cpe-simple-security-12
arno@natisbad.org (Arnaud Ebalard) Thu, 15 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 69D6F3A6AA2 for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 15 Jul 2010 08:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 VvCYOeQv8Kbi for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 15 Jul 2010 08:42:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 664EA3A6B3D for <v6ops-archive@lists.ietf.org>; Thu, 15 Jul 2010 08:42:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1OZQUd-000OYL-7t for v6ops-data0@psg.com; Thu, 15 Jul 2010 15:36:59 +0000
Received: from [2a01:e0b:1:97:2e0:f4ff:fe1b:b624] (helo=copper.chdir.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <arno@natisbad.org>) id 1OZQUZ-000OXt-Hn for v6ops@ops.ietf.org; Thu, 15 Jul 2010 15:36:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:Date:Message-ID: MIME-Version:Content-Type; bh=vMPBjVfngTYrePtDV5ni7sbKeB+ZEt02C7 zcHTs4Lrw=; b=mcBCL/1IeAdiWLF3eiVYxuQgFBSSG8lPYrmGDt3/kozFvu9j0M ytMd1gI+1oPOy6a9sz6aLzgYyTw2TkJ+12Tx6RSmBhZebtUOL+qjGaPOVIoO3VDz jKwj/dVplAIjRfccs1i+ne8nmzryDgoKKlPf7roP8fu09MkClt21LTVLY=
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <arno@natisbad.org>) id 1OZQUV-0007Aq-9Q; Thu, 15 Jul 2010 17:36:51 +0200
X-Hashcash: 1:20:100715:v6ops@ops.ietf.org::T3vU7j6kqfRMkaMl:00000000000000000000000000000000000000000001Ufz
X-Hashcash: 1:20:100715:jhw@apple.com::8FIkv9C6fXYkD/xv:00002Zss
From: arno@natisbad.org
To: v6ops@ops.ietf.org
Cc: James Woodyatt <jhw@apple.com>
Subject: Review of draft-ietf-v6ops-cpe-simple-security-12
X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc
X-Fingerprint: D3A5 B68A 839B 38A5 815A 781B B77C 0748 A7AE 341B
Date: Thu, 15 Jul 2010 17:37:01 +0200
Message-ID: <87k4owbvtu.fsf@small.ssi.corp>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
Hi, I read the draft (except for SCTP and DCCP related parts). IMHO, it is in good shape. I have some comments inline below. They are mainly related to IPsec/IKE and MIPv6. Please, bear with me if some have already been discussed on the list; I have not followed associated discussions. > 2. Overview > > For the purposes of this document, residential Internet gateways are > assumed to be fairly simple devices with a limited subset of the full > range of possible features. They function as default routers > [RFC4294] for a single local-area network, e.g. an Ethernet, a Wi-Fi > network, a bridge between two or more such segments. They have only > one interface by which they can access the Internet service at any > one time, using any of several possible sub-IP mechanisms including > tunnels and transition mechanisms. > > In referring to the security capabilities of residential gateways, it > is reasonable to distinguish between their "interior" network, i.e. > the local-area network, and their "exterior" networks, e.g. the > public Internet and the networks of Internet service providers. This > document is concerned only with the behavior of IP packet filters > that police the flow of traffic between the interior IPv6 network and > the exterior IPv6 networks of residential Internet gateways. > > The operational goals of security capabilities in Internet gateways > are described with more detail in "Local Network Protection for IPv6" > [RFC4864], but they can be summarized as follows. > > o Check all traffic to and from the public Internet for basic > sanity, e.g. anti-spoofing and "martian" [RFC4949] filters. > > o Allow tracking of applications usage by source and destination > transport addresses. s/transport/network/ ? > 3.1. Stateless Filters > > [snip] > > REC-8: By DEFAULT, inbound non-recursive DNS queries received on ^^^^^^^^^^^^^ Why non-recursive? What about recursive ones? In the end, is the integrated DNS resolver expected to process any kind of DNS solicitation originating from outside? > exterior interfaces MUST NOT be processed by any integrated DNS > resolving server. > > REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on > exterior interfaces MUST NOT be processed by any integrated DHCPv6 > server. > > 3.2. Connection-free Filters > > Some Internet applications use connection-free transport protocols > with no release semantics, e.g. UDP. These protocols pose a special > difficulty for stateful packet filters because most of the > application state is not carried at the transport level. State > records are created when communication is initiated and abandoned > when no further communication is detected after some period of time. > > 3.2.1. Internet Control and Management > > Recommendations for filtering ICMPv6 messages in firewall devices are > described separately in [RFC4890] and apply to residential gateways > with the additional recommendation that incoming "Destination > Unreachable" and "Packet Too Big" error messages that don't match any > filtering state should be dropped. > > REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination > Unreachable" and "Packet Too Big messages" containing IP headers that > do not match generic upper-layer transport state 3-tuples. I understand the purpose of the REC but I wanted to point the following just in case: if one decides to hardcode one of the other requirements without internally creating an "upper-layer transport state 3-tuples" (e.g. treat it statelessly), the result will be that associated ICMPv6 traffic may be dropped. The example I can provide is associated with the default pass-through rule for ESP (REC-21) which contain a MUST but REC-23 contains only a SHOULD for the use of a filter state record. I would like to avoid ESP-related traffic (e.g. PMTUD traffic) to get dropped. ESP does not seem to have the same kind of clarification than the one that REC-17 provides for UDP or REC-31 provides for TCP, i.e. something like "If a gateway forwards a ESP traffic flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing ESP headers that match the flow state record." Another solution would be to add a warning about related traffic in REC-21 or REC-23. Maybe the weird behavior of existing boxes made me paranoid. > 3.2.4. IPsec and Internet Key Exchange (IKE) > > The Internet protocol security suite (IPsec) offers greater > flexibility and better overall security than the simple security of > stateful packet filtering at network perimeters. Therefore, > residential IPv6 gateways need not prohibit IPsec traffic flows. > > REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT > prohibit the forwarding of packets, to and from legitimate node > addresses, with destination extension headers of type "Authenticated > Header (AH)" [RFC4302] in their outer IP extension header chain. > > REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT > prohibit the forwarding of packets, to and from legitimate node > addresses, with an upper layer protocol of type "Encapsulating > Security Payload (ESP)" [RFC4303] in their outer IP extension header > chain. > > Internet Key Exchange (IKE) is a secure mechanism for exchanging > cryptographic material. Residential IPv6 gateways are expected to > facilitate the use of IPsec security policies by allowing inbound IKE > flows. What about the following to replace the first sentence: Internet Key Exchange (IKE) is a secure mechanism for performing mutual authentication, exchanging cryptographic material and establishing IPsec Security Associations between peers. > 3.2.5. Mobility Support in IPv6 > > Mobility support in IPv6 [RFC3775] relies on the use of an > encapsulation mechanism in flows between mobile nodes and their > correspondent nodes, involving the use of the type 2 IPv6 routing > header and the Home Address destination header option. It also relies on Mobility Header (nh 135) passing through, for instance for required CoTI/CoT messages exchanged between the MN and the CN, before traffic using HAO in DestOpt or RH2 is exchanged. IMHO, there should be a REC to support MH to pass through. Even inbound MH traffic: more on that below. > In contrast > to mobility support in IPv4, mobility is a standard feature of IPv6, > and no security benefit is generally to be gained by denying > communications with either interior or exterior mobile nodes. > > REC-25: The state records for flows initiated by outbound packets > that bear a Home Address destination option [RFC3775] are > distinguished by the addition of the home address of the flow as well > as the interior Care-of address. IPv6 gateways MUST NOT prohibit the > forwarding of any inbound packets bearing type 2 routing headers, > which otherwise match a flow state record, and where A) the > destination matches the home address of the flow, and B) the Home > Address field in the routing header matches the interior Care-of > address of the flow. I think the last sentence is wrong. It should IMHO be: IPv6 gateways MUST NOT prohibit the forwarding of any inbound packets bearing type 2 routing headers, which otherwise match a flow state record, and where A) the address in the destination field of the IPv6 header matches the interior Care-of Address of the flow, and B) the Home Address field in the Type 2 Routing Header matches the Home Address of the flow. In more details, when a RO packet (e.g. TCP, MH, UDP, ...) is received by an internal MN from an external CN, its on-wire format is the following: IPv6(src=CN,dst=CoA)/RH2(HomeAddress=HoA)/TCP This is what the CPE will see. Additionally, this REC-25 supports an internal MN exchanging RO traffic with an external CN: MN --------- CPE ----------------- Internet -------------- CN ---- IPv6(src=CoA, dst=CN)/DestOpt(HOA(hoa=HoA))/TCP ----> <--- IPv6(src=CN,dst=CoA)/RH2(HomeAddress=HoA)/TCP ------- *but does not* support an internal CN (or MN) accepting bindings for an external MN, i.e.: CN --------- CPE ----------------- Internet -------------- MN (CoA, HoA) <--- IPv6(src=CoA, dst=CN)/DestOpt(HOA(hoa=HoA))/TCP ----- ---- IPv6(src=CN,dst=CoA)/RH2(HomeAddress=HoA)/TCP ------> is that out of scope or is it just missing? If that is not out of scope, a specific REC may be needed or REC-25 may be extended. Additionally, for that to be useful, inbound MH traffic need to be authorized. There is also another unrelated point associated with this REC-25: using TCP as an example, the CPE may not see the 3-way handshake between a MN and a CN if the TCP connection establishment is done via the tunnel to the Home Agent. Later, when this TCP traffic is route optimized, no TCP state exist in the CPE. I understand that REC-25 covers that with the "any" keyword in "IPv6 gateways MUST NOT prohibit the forwarding of *any* inbound packets bearing type 2 routing headers, ..." but I don't think it will be obvious for someone not familiar with the protocol that standard TCP RECs do not apply here, i.e. that somehow REC-25 applies before stateful rules. Stating it explictly in the document may help. Cheers, a+
- Review of draft-ietf-v6ops-cpe-simple-security-12 Arnaud Ebalard
- RE: Review of draft-ietf-v6ops-cpe-simple-securit… Laganier, Julien