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

[Stephen Hanna <[e-mail]>]

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

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

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

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

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

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

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