Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
Stephen Hanna <shanna@juniper.net> Thu, 23 January 2014 15:20 UTC
Return-Path: <shanna@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A951A000F; Thu, 23 Jan 2014 07:20:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYT_1rO5OF7h; Thu, 23 Jan 2014 07:20:35 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA461A0004; Thu, 23 Jan 2014 07:20:34 -0800 (PST)
Received: from mail47-co1-R.bigfish.com (10.243.78.246) by CO1EHSOBE039.bigfish.com (10.243.66.104) with Microsoft SMTP Server id 14.1.225.22; Thu, 23 Jan 2014 15:20:34 +0000
Received: from mail47-co1 (localhost [127.0.0.1]) by mail47-co1-R.bigfish.com (Postfix) with ESMTP id E05FAD201FC; Thu, 23 Jan 2014 15:20:33 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -21
X-BigFish: VPS-21(zz98dI1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h9a9j1155h)
Received-SPF: pass (mail47-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(199002)(51704005)(189002)(164054003)(24454002)(76786001)(54316002)(93136001)(76796001)(92566001)(47736001)(46102001)(33646001)(49866001)(81816001)(93516002)(76482001)(94316002)(86362001)(65816001)(77982001)(53806001)(76576001)(56776001)(50986001)(80976001)(83322001)(74876001)(79102001)(31966008)(87266001)(85306002)(80022001)(87936001)(81342001)(74366001)(4396001)(47446002)(66066001)(59766001)(54356001)(2656002)(69226001)(47976001)(63696002)(19580395003)(74316001)(74502001)(85852003)(90146001)(74706001)(51856001)(83072002)(81686001)(81542001)(15975445006)(56816005)(74662001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB737; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.13; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail47-co1 (localhost.localdomain [127.0.0.1]) by mail47-co1 (MessageSwitch) id 1390490431886174_13601; Thu, 23 Jan 2014 15:20:31 +0000 (UTC)
Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.251]) by mail47-co1.bigfish.com (Postfix) with ESMTP id C9F0CD00055; Thu, 23 Jan 2014 15:20:31 +0000 (UTC)
Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 23 Jan 2014 15:20:31 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 23 Jan 2014 15:20:28 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) with Microsoft SMTP Server (TLS) id 15.0.851.11; Thu, 23 Jan 2014 15:20:26 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0851.011; Thu, 23 Jan 2014 15:20:26 +0000
From: Stephen Hanna <shanna@juniper.net>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-pcp-nat64-prefix64.all@tools.ietf.org" <draft-ietf-pcp-nat64-prefix64.all@tools.ietf.org>
Thread-Topic: secdir Review of draft-ietf-pcp-nat64-prefix64-04
Thread-Index: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQBPUUuAAAMzYfA=
Date: Thu, 23 Jan 2014 15:20:25 +0000
Message-ID: <638ccecdeecb4b458718b1c33821c092@BLUPR05MB737.namprd05.prod.outlook.com>
References: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.239.13]
x-forefront-prvs: 0100732B76
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 15:20:38 -0000
Med, Thanks for your response. Coming along nicely! A few comments on your changes below, marked with [SRH]. Thanks, Steve Med wrote: > Steve wrote: > >1) The second paragraph of the Security Considerations section > > points out that if an attacker can fool a host into using > > the wrong value for Pref64::/n, the traffic generated using > > that value will be delivered to the wrong location. That's > > right but not all the implications are mentioned. A MITM > > (Man In The Middle) attack can be performed in this manner, > > permitting alterations to the traffic (not just eavesdropping). > > This should be mentioned. > [Med] I updated the text as follows: > > OLD: > > As discussed in [RFC6147], if an attacker can manage to change the > Pref64::/n used by the DNS64 function, the traffic generated by the > host that receives the synthetic reply will be delivered to the > altered Pref64. This can result in either a denial-of-service (DoS) > attack, a flooding attack, or an eavesdropping attack. This attack > could be achieved either by altering PCP messages issued by a > legitimate PCP server or by using a fake PCP server. > > NEW: > > As discussed in [RFC6147], if an attacker can manage to change the > Pref64::/n used by the DNS64 function, the traffic generated by the > host that receives the synthetic reply will be delivered to the > altered Pref64. This can result in either a denial-of-service (DoS) > attack, a flooding attack, or a MIM (Man In The Middle) attack. > This attack > could be achieved either by altering PCP messages issued by a > legitimate PCP server or by using a fake PCP server. > > Better? [SRH] Yes, but the conventional abbreviation for Man In The Middle is MITM not MIM. Who knows why?! > >2) The next paragraph of the Security Considerations section > > suggests defenses to prevent the attacker from substituting > > the wrong value for Pref64::/n. However, the defense that > > is suggested (IP-based ACLs on the PCP server, client, or > > network) won't help much. Attackers can just place the > > PCP server's IP address in the source address of the fake > > PCP response packet sent by the attack. > > [Med] anti-spoofing filters can be used to prevent such attack. Ingress > filters can be also enforced at boundaries of a domain to prevent such > attack. I do think the text is still correct. [SRH] These countermeasures provide no defense against an attacker who is on the path from the PCP server to the client. This is not a theoretical attack, as described in certain news reports recently (Der Spiegel). > > The nonce in the > > MAP or PEER response means that the attacker must capture > > or predict this value but no nonce is present in the ANNOUNCE > > response so that would probably be the preferred attack > > method, especially since ANNOUNCE responses can be sent > > out via multicast at any time. I suggest that the spec > > prohibit sending the PREFIX64 option in a multicast > > ANNOUNCE response, unless effective countermeasures for > > this attack are found. > [Med] Isn't this covered by this text: > > " Means to defend against attackers who can modify packets between > the > PCP server and the PCP client, or who can inject spoofed packets > that > appear to come from a legitimate PCP server SHOULD be enabled." [SRH] That would be a reasonable countermeasure if such means actually existed. Could you describe what those means would be? As I mentioned above, ingress filters and anti-spoofing filters are ineffective against on-path attackers. > >In addition to these security issues, I found some other issues > >that are not related to security: > > > >1) You should explain that RFC 6146 defines Pref64::/n. > > Otherwise, that term is quite cryptic. > [Med] I added this new sentence: > > According to [RFC6146], NAT64 uses Pref64::/n to construct > IPv4-Converted IPv6 addresses as defined in [RFC6052]. > > Better? [SRH] Great! [SRH] Deleted several more comments that you have addressed. > >6) Text near the top of page 8 says "The PCP server can be > > configured with a customized IPv6 prefix list" but that > > won't work when PREFIX64 is added to a multicast ANNOUNCE > > response. That's another reason not to permit this, in > > addition to security issue 2) above. > [Med] I added this sentence: > > " Note, it is NOT > RECOMMENDED to include PREFIX64 options in ANNOUNCE messages if a > customized IPv6 prefix list is configured to the PCP server. " > > Better? [SRH] Maybe. Is there some way that including PREFIX64 options in ANNOUNCE messages will work if a customized IPv6 prefix list is configured to the PCP server? If not, this should be a MUST NOT instead of a NOT RECOMMENDED. > >7) When IPv4 prefix lists are configured and multiple IPv6 > > prefix lists are also configured, the first PREFIX64 > > option includes the IPv4 prefix lists. Can the later > > PREFIX64 options also include their own IPv4 prefix > > lists? If one or more of those later PREFIX64 options > > does NOT have its own IPv4 prefix list, what does that > > mean? Does it inherit the IPv4 prefix list of the > > previous PREFIX64 option? The current text is not clear. > [Med] Only the first occurrence can carry the IPv4 prefix because other > occurrences are not used by building IPv4-converted addresses, but only > to distinguish these addresses if received in referrals. I can add a > sentence to indicate this explicitly in the text. [SRH] Thanks. Please do. > >8) The example in section 5.1 says that it "depicts a > > typical usage of the PREFIX64 option when a DNS64 > > capability is embedded in the host." Did you mean > > "is not embedded"? I don't see how DNS64 is being > > used in this example. > > [Med] The text is correct. DNS64 is used to form locally an IPv4- > converted IPv6 address. The example assumes the address of the IPv4 > server is retrieved using A records. DNS exchanges are not mentioned in > the figure to avoid overloading it. [SRH] OK. You may want to explain this a bit more. > >9) Is this document still relevant? RFC 7051 says: > > > > Our conclusion is to recommend publishing the Well-Known DNS Name > > heuristic discovery-based method as a Standards Track IETF document > > for applications and host implementors to implement as-is. > > > > With that, is there still a need for this document? > [Med] Yes, this is explicitly mentioned in the shepherded text of > RFC7050. Please refer to > https://datatracker.ietf.org/doc/rfc7050/history/ > > " The document specifies a heuristic that is not perfect and so some > points were rough, but the constraint for this document was to > operate > without changes to code (only configuration) in existing networks. > Given that constraint, there was strong consensus. Relaxing the > constraint would allow one to do better, and that is the focus of a > draft recently submitted to the PCP WG." [SRH] OK, fine. You might want to mention that in your draft. Otherwise, other readers may have the same confusion. They're not likely to read the shepherd text for RFC 7050!
- [secdir] secdir Review of draft-ietf-pcp-nat64-pr… Stephen Hanna
- Re: [secdir] secdir Review of draft-ietf-pcp-nat6… mohamed.boucadair
- Re: [secdir] secdir Review of draft-ietf-pcp-nat6… Stephen Hanna
- Re: [secdir] secdir Review of draft-ietf-pcp-nat6… mohamed.boucadair
- Re: [secdir] secdir Review of draft-ietf-pcp-nat6… Stephen Hanna
- Re: [secdir] secdir Review of draft-ietf-pcp-nat6… mohamed.boucadair
- Re: [secdir] secdir Review of draft-ietf-pcp-nat6… Ted Lemon