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

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Apr 2012 13:36:07 +0100

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Apr 2012 13:40:45 +0100

I have to admit that my knowledge of DNSSEC is lacking, so can somebody 
help me answer this question (which I didn't mention in my SecDir review):

5.2.  EDNS0 option indicating AAAA Record synthesis and format

5.2.1.  Solution description

    The third revision of "EDNS0 Option for Indicating AAAA Record
    Synthesis and Format", a draft document submitted to the behave WG in
    February 2011 by Jouni Korhonen and Teemu Savolainen, defined a new
    EDNS0 option [RFC2671], which contained 3 flag bits (called SY-bits).
    The EDNS0 option served as an implicit indication of the presence of
    DNS64 server and the NAT64 device.  The EDNS0 option SY-bit values
    other than '000' and '111' explicitly told the NSP prefix length.
    Only the DNS64 server could insert the EDNS0 option and the required
    SY-bits combination into the synthesized AAAA Resource Record.

Will DNS64 insertion of this option invalid DNSSEC signature?

---

From: jouni korhonen <[email-masked]>
Date: Wed, 11 Apr 2012 13:00:14 +0300

Hi,

Thank you for the review. See my comments inline.

On Apr 10, 2012, at 3:36 PM, Alexey Melnikov wrote:

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

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

> Maybe add an explicit DNSSEC reference here?

Will add a reference to RFC4033.

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

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

Ok. We'll look into it.

> 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

---

From: David Harrington <[email-masked]>
Date: Wed, 11 Apr 2012 07:16:49 -0400

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
[email-masked]
+1-603-828-1401

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

>_______________________________________________
>secdir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/secdir
>wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: jouni korhonen <[email-masked]>
Date: Wed, 11 Apr 2012 15:21:10 +0300

Hi,

> Is this document requesting the assignment, or is another document doing

Another document.

> provide a reference to the document that requests IANA to do so.

The document that requests the actual assignment is already referenced 
in the same section.

- Jouni

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Apr 2012 19:28:22 +0100

> Hi,
Hi Jouni,
> On Apr 10, 2012, at 3:36 PM, Alexey Melnikov wrote:
  [...]
> DNS server hosting the IPv4-only FQDN would be hostile,
Not necessarily, for example it can be compromised.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Apr 2012 19:29:24 +0100

> provide a reference to the document that requests IANA to do so.
+1.
> --
> David Harrington
> [email-masked]
> +1-603-828-1401
>
>
>
>
>
> On 4/11/12 6:00 AM, "jouni korhonen"<[email-masked]>  wrote:
>> Hi,
>>

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 11 Apr 2012 15:33:17 -0400 (EDT)

On Tue, 10 Apr 2012, Alexey Melnikov wrote:

> I have to admit that my knowledge of DNSSEC is lacking, so can somebody help 
> me answer this question (which I didn't mention in my SecDir review):
>
...
>   EDNS0 option [RFC2671], which contained 3 flag bits (called SY-bits).
...
> Will DNS64 insertion of this option invalid DNSSEC signature?

No.  EDNS0 "stuff" is not DNSSEC-signed.

I'm not familiar with the cited proposal, but it looks like a poor 
choice for the task -- EDNS0 "stuff" is hop-by-hop, and this look like 
data that should persist through the network.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 11 Apr 2012 15:39:14 -0400 (EDT)

> Will add references to RFC3315 and RFC3971.

More generally, please add informative citations to all of the docs 
(e.g the ones mentioned in 5.*) -- don't just give us the ID titles, 
actually cite them.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 11 Apr 2012 15:45:44 -0400 (EDT)

Adding my own comments:

I think there may be a key "con" missing in the discussion of the two 
EDNS0 approaches (in 5.2 in 5.3).  EDNS0 "stuff", whether flags or 
options, are typically hop-by-hop only.  That severely limits the 
applicability of these approaches.

-- Sam

---

From: jouni korhonen <[email-masked]>
Date: Thu, 12 Apr 2012 11:06:09 +0300

Hi,

On Apr 11, 2012, at 10:39 PM, Samuel Weiler wrote:

> More generally, please add informative citations to all of the docs (e.g the ones mentioned in 5.*) -- don't just give us the ID titles, actually cite them.

Ack.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Thu, 12 Apr 2012 11:11:30 +0300

Hi,

On Apr 11, 2012, at 10:45 PM, Samuel Weiler wrote:

> Adding my own comments:
> 
> I think there may be a key "con" missing in the discussion of the two EDNS0 approaches (in 5.2 in 5.3).  EDNS0 "stuff", whether flags or options, are typically hop-by-hop only.  That severely limits the applicability of these approaches.

You mean, unless the "EDNS0 capable" DNS64 is the first DNS server the
end host talks to, one cannot guarantee the EDNS0 option survives through
all DNS proxies and (caching) servers in between?

That would be something to point out.. me thinks.

- Jouni

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 12 Apr 2012 11:25:26 -0400 (EDT)

> all DNS proxies and (caching) servers in between?

Yes, but it's even worse than that: if ANY other nameserver is in 
between, you likely won't see the option.  EDNS0 options are not 
transitive.

-- Sam