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

Stephen Hanna <shanna@juniper.net> Tue, 21 January 2014 23:46 UTC

Received-SPF: pass (mail134-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=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ;
From: Stephen Hanna <shanna@juniper.net>
To: "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: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQ==
Date: Tue, 21 Jan 2014 23:46:17 +0000
Message-ID: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
Precedence: list

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This document defines a new PCP (Port Control Protocol) option
to learn the IPv6 prefix(es) used by a PCP-controlled NAT64
device to build IPv4-converted IPv6 addresses (known as
"Pref64::/n").

The Security Considerations for this draft are a good start
but they are missing some key information.

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.

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

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.

2) Several places in the document, you say that PREFIX64 is
   a PCP "extension". The PCP spec doesn't define what a PCP
   extension is. Say "PCP option" instead.

3) In section 3.2.1, say "synthesize" not "synthesizes".

4) In section 4.1 and several other places, the field Pref64
   is also called Prefix64. Come up with one name for the
   field and stick with it.

5) Split section 4.2 into Client Behavior and Server Behavior.
   The current text is too confusing. For example, the text at
   the bottom of page 7 is a confusing mishmash of server and
   client handling of multiple PREFIX64 options.

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.

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.

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.

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?

I hope that you find these comments useful.

Thanks,

Steve

[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