Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
<mohamed.boucadair@orange.com> Fri, 24 January 2014 12:51 UTC
Return-Path: <mohamed.boucadair@orange.com>
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 22E251A02F5; Fri, 24 Jan 2014 04:51:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
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 ECjsEduYMDIo; Fri, 24 Jan 2014 04:51:07 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA461A02D1; Fri, 24 Jan 2014 04:51:07 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 411A22AC3F8; Fri, 24 Jan 2014 13:51:05 +0100 (CET)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 21BF318004F; Fri, 24 Jan 2014 13:51:02 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 24 Jan 2014 13:51:01 +0100
From: mohamed.boucadair@orange.com
To: Stephen Hanna <shanna@juniper.net>, "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>
Date: Fri, 24 Jan 2014 13:51:00 +0100
Thread-Topic: secdir Review of draft-ietf-pcp-nat64-prefix64-04
Thread-Index: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQBPUUuAAAMzYfAAIo4UkAAGxHpwAAQQFCA=
Message-ID: <94C682931C08B048B7A8645303FDC9F36F4736056F@PUEXCB1B.nanterre.francetelecom.fr>
References: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr> <638ccecdeecb4b458718b1c33821c092@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F473603EB@PUEXCB1B.nanterre.francetelecom.fr> <9e76a90f04f24e3aa156abcc1cca7f5e@BLUPR05MB737.namprd05.prod.outlook.com>
In-Reply-To: <9e76a90f04f24e3aa156abcc1cca7f5e@BLUPR05MB737.namprd05.prod.outlook.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.24.102114
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: Fri, 24 Jan 2014 12:51:10 -0000
Re-, For issue#9, I didn't added any change for the moment but will reconsider it if we received a similar comment during the WGLC. The next revision of the draft will include what we have agreed so far. Thank you very much for your careful review. Much appreciated ! Cheers, Med >-----Message d'origine----- >De : Stephen Hanna [mailto:shanna@juniper.net] >Envoyé : vendredi 24 janvier 2014 11:54 >À : BOUCADAIR Mohamed IMT/OLN; secdir@ietf.org; The IESG; draft-ietf-pcp- >nat64-prefix64.all@tools.ietf.org >Objet : RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04 > >Med, > >Thanks for addressing so many of my concerns. I'm happy with >the changes that you have made. > >I didn't see a response to issue 9) below (about RFC 7050). >Do you have any plans to address that? > >Thanks, > >Steve > >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Sent: Friday, January 24, 2014 3:56 AM >> To: Stephen Hanna; secdir@ietf.org; The IESG; draft-ietf-pcp-nat64- >> prefix64.all@tools.ietf.org >> Subject: RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04 >> >> Dear Stephen, >> >> Please see inline. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De : Stephen Hanna [mailto:shanna@juniper.net] >> >Envoyé : jeudi 23 janvier 2014 16:20 >> >À : BOUCADAIR Mohamed IMT/OLN; secdir@ietf.org; The IESG; draft-ietf- >> pcp- >> >nat64-prefix64.all@tools.ietf.org >> >Objet : RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04 >> > >> >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?! >> [Med] Fixed. >> >> > >> >> >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). >> [Med] The deployment I have in mind is a pcp service offered by a >> service provider while pcp clients are hosted in a CPE or in connected >> devices (either behind the CPE or directly to the service provider >> network). To achieve the attack vector you described, the mis-behaving >> node should be in the service provider network or connected to that >> network. If that service provider enforced anti-spoofing filters, then >> a mis-behaving node cannot act as a fake pcp server. >> >> I understand this is a deployment case among others. So to be accurate, >> I changed the text as follows: >> >> OLD: >> For example, access control lists (ACLs) can be installed on the PCP >> client, PCP server, and the network between them, so those ACLs >> allow >> only communications from a trusted PCP server to the PCP client. >> >> NEW: >> In some deployments, access control lists (ACLs) can be installed on >> the PCP client, PCP server, and the network between them, so those >> ACLs allow only communications from a trusted PCP server to the PCP >> client. >> >> >> > >> >> > 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. >> [Med] As mentioned above, ACLs are sufficient in some deployment >> contexts. >> >> >> > >> >> >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. >> >> [Med] An example is the use of separate zones (see for instance >> http://tools.ietf.org/search/draft-penno-pcp-zones-01) or if several >> logical topologies are configured. >> >> > >> >> >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. >> [Med] I added this sentence to Section 4.1: >> >> " When multiple PREFIX64 options are included in the same PCP message, >> only the first PREFIX64 option occurrence may include the IPv4 Prefix >> List field." >> >> >> > >> >> >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. >> [Med] I made this change: >> >> OLD: >> "once the IPv6-only client discovers the IPv4 address of the remote >> IPv4-only server" >> >> NEW: >> " once the IPv6-only client discovers the IPv4 address of the remote >> IPv4-only server (e.g., using DNS)" >> >> and added this sentence: >> >> " Note: DNS exchange to retrieve the IPv4 address of >> the IPv4-only Server is not shown in the figure. " >> >> > >> >> >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