[secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt

[Alexey Melnikov <[e-mail]>]

Hi,

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.

The document reviews possible solutions for the problem of allowing 
hosts and applications to learn if an IPv6 address is synthesized, which 
means a NAT64 is used to reach the IPv4 network or Internet. The 
document analyzes pros and cons of various approaches and also concludes 
with some recommendations about which approach is recommended.

Overall I think the Security Considerations section is reasonable (see 
some minor comments below). I think it is reasonable for the document to 
point to RFC 6147 for DSN64 related Security Considerations. The 
document also talks about Man-in-the-middle and Denial-of-Service 
attacks caused by forging of information required for IPv6 synthesis 
from corresponding IPv4 addresses.

Additionally, the document says:

    The DHCPv6 and RA
    based approaches are vulnerable for the forgery as the attacker may
    send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6
    authentication or SEND are used).

I think some Informative references to relevant documents should be 
inserted here in order to help readers find relevant information.

    If the attacker is already able to
    modify and forge DNS responses (flags, addresses of know IPv4-only
    servers, records, etc), ability to influence local address synthesis
    is likely of low additional value.  Also, a DNS-based mechanism is
    only as secure as the method used to configure the DNS server's IP
    addresses on the host.  Therefore, if the host cannot trust e.g.
    DHCPv6 it cannot trust the DNS server learned via DHCPv6 either,
    unless the host has a way to authenticate all DNS responses.

Maybe add an explicit DNSSEC reference here?


One other possible issue that you should consider:

5.1.2.  Analysis and discussion

    The CONs of the proposal are listed below:

I don't know how much of an issue this is in a real world, but one thought:

Can use of a well known IPv4-only FQDN be used for tracking 
applications/hosts which try to employ this algorithm? Such IPv4-only 
host might be an attractive target for compromise, if such information 
is valuable to an attacker.

(This might also apply to other DNS methods.)


Other comments (not really SecDir related):

I found the Abstract to be quite hard to read. Maybe reword to use 
shorter/simpler sentences?

5.1.1.  Solution description

    The Well-Known Name may be assigned by IANA or provided some third
    party, including application or operating system vendor.  The IPv4
    address corresponding to the Well-Known Name may be resolved via A
    query to Well-Known Name, assigned by IANA, or hard-coded.

Is IANA already providing one of these? If not, why speculate about 
this, as there is no action for IANA specified in this document.