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

From: Stephen Hanna <[email-masked]>
Date: Tue, 21 Jan 2014 23:46:17 +0000

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

---

From: <[email-masked]>
Date: Thu, 23 Jan 2014 16:00:04 +0100

Dear Stephen,

Thank you for the review. 

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Stephen Hanna [mailto:[email-masked]]
>Envoyé : mercredi 22 janvier 2014 00:46
>À : [email-masked]; The IESG; draft-ietf-pcp-nat64-
>[email-masked]
>Objet : secdir Review of draft-ietf-pcp-nat64-prefix64-04
>
[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?

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

The nonce in the
>   ANNOUNCE response, unless effective countermeasures for
[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."

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

>   extension is. Say "PCP option" instead.
[Med] Fixed.

>3) In section 3.2.1, say "synthesize" not "synthesizes".
[Med] Thanks for catching it. Fixed.

>   is also called Prefix64. Come up with one name for the
[Med] Fixed. 

>   client handling of multiple PREFIX64 options.
[Med] Will consider this suggestion. 

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

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

>   "is not embedded"? I don't see how DNS64 is being

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

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

>I hope that you find these comments useful.
[Med] Thanks for the review. Much appreciated.

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 23 Jan 2014 15:20:25 +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:

[SRH] Yes, but the conventional abbreviation for
Man In The Middle is MITM not MIM. Who knows why?!

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

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

>    IPv4-Converted IPv6 addresses as defined in [RFC6052].

[SRH] Great!

[SRH] Deleted several more comments that you have addressed.

>       customized IPv6 prefix list is configured to the PCP server. "

[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] 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] 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] Yes, this is explicitly mentioned in the shepherded text of
> RFC7050. Please refer to
> https://datatracker.ietf.org/doc/rfc7050/history/
> 

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

---

From: <[email-masked]>
Date: Fri, 24 Jan 2014 09:55:34 +0100

Dear Stephen,

Please see inline.

Cheers,
Med

>Envoyé : jeudi 23 janvier 2014 16:20
>À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; The IESG; draft-ietf-pcp-
>[email-masked]
>Objet : RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04
>
>Med,
>
[Med] Fixed.

>not a theoretical attack, as described in certain news reports
[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.

>anti-spoofing filters are ineffective against on-path
[Med] As mentioned above, ACLs are sufficient in some deployment contexts. 

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

>> sentence to indicate this explicitly in the text.
[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."

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

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 24 Jan 2014 10:54:09 +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: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, January 24, 2014 3:56 AM
> To: Stephen Hanna; [email-masked]; The IESG; draft-ietf-pcp-nat64-
> Subject: RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04
> 
> Dear Stephen,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> [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.
> 
> [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.
> 
> >
> " When multiple PREFIX64 options are included in the same PCP message,
> only the first PREFIX64 option occurrence may include the IPv4 Prefix
> List field."
> 
> 
> >

---

From: <[email-masked]>
Date: Fri, 24 Jan 2014 13:51:00 +0100

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

>Envoyé : vendredi 24 janvier 2014 11:54