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

[David Harrington <[e-mail]>]

Hi,

For IANA to provide an assignment, a document usually needs to request
such an assignment.
Is this document requesting the assignment, or is another document doing
so?
If this document wants to mention such an IANA assignment, it should also
provide a reference to the document that requests IANA to do so.

--
David Harrington
[e-mail]
[phone]





On 4/11/12 6:00 AM, "jouni korhonen" <[e-mail]> wrote:

>Hi,
>
>Thank you for the review. See my comments inline.
>
>On Apr 10, 2012, at 3:36 PM, Alexey Melnikov wrote:
>
>> 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.
>
>Good point. We'll add the reference.
>
>
>> 
>> 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.
>
>Will add references to RFC3315 and RFC3971.
>
>> 
>>   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?
>
>Will add a reference to RFC4033.
>
>
>> 
>> 
>> 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.
>
>I guess it could be possible in theory.. if we assume the
>DNS server hosting the IPv4-only FQDN would be hostile,
>which is not a realistic assumption imho.
>
>
>> 
>> (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?
>
>Ok. We'll look into it.
>
>
>> 
>> 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.
>
>IANA is going to provide one. I think it is good to have
>this part still in the document. It was a non-trivial issue
>who is going to host the well-known name.
>
>- Jouni
>
>> 
>
>_______________________________________________
>secdir mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/secdir
>wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview