Subject: [secdir] secdir review of draft-ietf-homenet-arch-10

From: Samuel Weiler <[email-masked]>
Date: Tue, 10 Sep 2013 22:53:52 -0400 (EDT)

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.

Even though this is an architecture document, I think it deserves some 
AD attention.

First: it seems odd to set an expectation for (near) 
zero-configuration:

    It is not practical to expect home users to configure their networks.
    Thus the assumption of this document is that the homenet is as far  as
    possible self-organising and self-configuring, i.e. it should
    function without pro-active management by the residential user.

and then decline to give any guidance about, arguably, the most 
important security choice in the document:

    This document takes no position on [whether 'default allow' or
    'default deny'] mode is the default, but assumes
    the choice for the homenet to use either mode would be available.

I found the "Name spaces" section (3.7.3) a bit confusing, in part 
because it doesn't specifically name DNS at the start of the section, 
even though the details below clearly point to DNS (IDNA, possible 
conflicts with dotless TLDs).  Perhaps the second paragraph of 3.7.4, 
explaining that there are some non-DNS alternatives under 
consideration, should be moved up?  Furthermore, there are some 
particular assertions in both 3.7.3 and 3.7.4 that need to be 
reconsidered:

-- "When DNS is used as the homenet name service, it includes both a
    resolving service and an authoritative service."  Does it
    necessarily?

-- "The name space(s) should be served authoritatively by the
    homenet..."   Why is that necessary?  (Indeed, there is text in
    3.7.4 that seems to conflict with this.)

-- There is a recommendation to support DNSSEC on the authoritative
    server side (in 3.7.4).  Shouldn't there be a similar
    recommendation on the resolver side?

---

From: Mark Townsley <[email-masked]>
Date: Wed, 11 Sep 2013 10:00:24 +0200

Hi Sam, thanks for the review. Inline...

On Sep 11, 2013, at 4:53 AM, Samuel Weiler wrote:

> Even though this is an architecture document, I think it deserves some AD attention.
> 
> 
> First: it seems odd to set an expectation for (near) zero-configuration:
> 
> and then decline to give any guidance about, arguably, the most important security choice in the document:
> 

Homenet's focus is on the interior of the home network. RFC 6204 already tackled the egress ("WAN Port") facing the ISP within v6ops, along with the painful process of this particular issue. Perhaps we should make that more clear in this document.

> 
> 
> I found the "Name spaces" section (3.7.3) a bit confusing, in part because it doesn't specifically name DNS at the start of the section, even though the details below clearly point to DNS (IDNA, possible conflicts with dotless TLDs).  Perhaps the second paragraph of 3.7.4, explaining that there are some non-DNS alternatives under consideration, should be moved up?  Furthermore, there are some particular assertions in both 3.7.3 and 3.7.4 that need to be reconsidered:
> 

Good points, but I'll let my DNS-hat-wearing co-chair chime in on these.

Thanks,

- Mark

---

From: Ray Bellis <[email-masked]>
Date: Wed, 11 Sep 2013 08:33:00 +0000

Sam,

>  resolving service and an authoritative service."  Does it

A Homenet that is not currently connected to the Internet still needs to be able to function, so (when DNS is used) authoritative local name service and a service for resolution of those local names are both needed.

>  3.7.4 that seems to conflict with this.)

One reason is simply to prevent names only intended to be known internally from being shared with externally maintained authoritative servers.

The other is the "disconnected homenet" mentioned above.

Can you please indicate which text you believe is in conflict?

>  recommendation on the resolver side?

That (short) paragraph is not specific to authoritative servers, it applies to the entire section.  The example of cache-poisoning further indicates its applicability to recursive resolution.

kind regards,

Ray

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 11 Sep 2013 11:17:00 -0400 (EDT)

>>  3.7.4 that seems to conflict with this.)
...
> Can you please indicate which text you believe is in conflict?

Sure.

in 3.7.3:

"The name space(s) should be served authoritatively by the
    homenet, most likely by a server resident on the CER."

in 3.7.4

"One approach ... is to run an authoritative
    name service on the CER and a secondary resolving name service
    provided by the ISP or perhaps a cloud-based third party."

The former I see as more prescriptive (you should do X) and the latter 
as just a suggestion (one idea is X).

I was challenging the prescription.  The quotes are necessarily in 
conflict, but they seem to carry very different force.

> That (short) paragraph is not specific to authoritative servers, it 
> applies to the entire section.  The example of cache-poisoning 
> further indicates its applicability to recursive resolution.

That is not clear from the text.  I read "it is desirable
    to support appropriate name service security methods, including
    DNSSEC." and interpreted as shown above.

-- Sam

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Sep 2013 15:39:11 +0000

On Sep 11, 2013, at 11:17 AM, Samuel Weiler <[email-masked]> wrote:
> I was challenging the prescription.  The quotes are necessarily in conflict, but they seem to carry very different force.

Actually they aren't in conflict.   3.7.3 is saying "you need an authoritative name server on the local net."   3.7.4 is saying "if you want names to be resolved externally, one way to make this work would be to set up secondaries on external servers."  In fact, the solution that I've seen discussed recently is to have the master on the local network be a hidden master, so that the only published authoritative servers for the zone would be the secondaries.   But the architecture document rightly avoids prescribing that solution.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 11 Sep 2013 15:56:39 +0000

> Actually they aren't in conflict.   3.7.3 is saying "you need an authoritative name server on the local net."   3.7.4 is saying "if you want names to be resolved externally, one way to make this wo…

I think the confusion is caused by the use of the phrase "secondary resolving name service" in 3.7.4

Ted is (correctly, I think) taking the intent of that to mean a secondary _authoritative_ service, but us DNS heads think of "resolving" as what stubs and recursive servers do.

Tim - can you please clarify the intent?

Ray