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

[<[e-mail]>]

Dear Stephen,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Stephen Hanna [mailto:[e-mail]]
>Envoyé : jeudi 23 janvier 2014 16:20
>À : BOUCADAIR Mohamed IMT/OLN; [e-mail]; The IESG; draft-ietf-pcp-
>[e-mail]
>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!
>