Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04

Stephen Hanna <shanna@juniper.net> Fri, 24 January 2014 10:54 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 35BA61A0283; Fri, 24 Jan 2014 02:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 784Vyd78YoPx; Fri, 24 Jan 2014 02:54:19 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7576C1A0226; Fri, 24 Jan 2014 02:54:19 -0800 (PST)
Received: from mail26-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE028.bigfish.com (10.236.130.91) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Jan 2014 10:54:18 +0000
Received: from mail26-co9 (localhost [127.0.0.1]) by mail26-co9-R.bigfish.com (Postfix) with ESMTP id E574A1202BD; Fri, 24 Jan 2014 10:54:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -74
X-BigFish: VPS-74(zz98dI9371Ic89bh148cI542I1432I15caKJ4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h9a9j1155h)
Received-SPF: pass (mail26-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(52604005)(189002)(199002)(51704005)(13464003)(377454003)(164054003)(24454002)(55784002)(76786001)(93516002)(92566001)(54316002)(93136001)(76796001)(81816001)(33646001)(49866001)(76576001)(46102001)(76482001)(86362001)(94316002)(65816001)(77982001)(53806001)(50986001)(80976001)(56776001)(83322001)(47736001)(87266001)(79102001)(31966008)(85306002)(80022001)(87936001)(81342001)(74366001)(4396001)(47446002)(66066001)(59766001)(19580395003)(47976001)(15202345003)(19580405001)(54356001)(2656002)(74876001)(69226001)(63696002)(56816005)(74316001)(85852003)(90146001)(74502001)(81686001)(81542001)(51856001)(83072002)(74706001)(15975445006)(74662001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB737; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.13; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail26-co9 (localhost.localdomain [127.0.0.1]) by mail26-co9 (MessageSwitch) id 1390560854407500_32635; Fri, 24 Jan 2014 10:54:14 +0000 (UTC)
Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.229]) by mail26-co9.bigfish.com (Postfix) with ESMTP id 5E7DA10004B; Fri, 24 Jan 2014 10:54:14 +0000 (UTC)
Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 24 Jan 2014 10:54:13 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 24 Jan 2014 10:54:12 +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; Fri, 24 Jan 2014 10:54:10 +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; Fri, 24 Jan 2014 10:54:10 +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: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQBPUUuAAAMzYfAAIo4UkAAGxHpw
Date: Fri, 24 Jan 2014 10:54:09 +0000
Message-ID: <9e76a90f04f24e3aa156abcc1cca7f5e@BLUPR05MB737.namprd05.prod.outlook.com>
References: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr> <638ccecdeecb4b458718b1c33821c092@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F473603EB@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F473603EB@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: 01018CB5B3
Content-Type: text/plain; charset="iso-8859-1"
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: Fri, 24 Jan 2014 10:54:22 -0000

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!
> >
> 
>