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

[<[e-mail]>]

Dear Stephen,

Thank you for the review. 

Please see inline.

Cheers,
Med

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

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

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

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

>
>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.
[Med] Fixed.

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

>
>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.
[Med] Fixed. 

>
>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.
[Med] Will consider this suggestion. 

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

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


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

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

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

>
>Thanks,
>
>Steve
>