Last Call Review of draft-ietf-behave-nat64-learn-analysis-
review-ietf-behave-nat64-learn-analysis-secdir-lc-melnikov-2012-04-26-00

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.