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

Mark Townsley <> Wed, 11 September 2013 08:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A9FC11E81FD for <>; Wed, 11 Sep 2013 01:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ra90l1XVwhks for <>; Wed, 11 Sep 2013 01:00:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7655811E81F0 for <>; Wed, 11 Sep 2013 01:00:29 -0700 (PDT)
Received: by with SMTP id c1so4438636eek.10 for <>; Wed, 11 Sep 2013 01:00:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Mjpi7WWtt+kmOIN4UpCP4fILTatirw63f0cZVG1ynUM=; b=GlTH9SaYks4cFc4p3S34WZZRtUBNBX5zfrQacyehuKdhtaP6HOaMP15Avay0ku9H06 mM1v78gqacZBnW0ftsZQX85Fr8xRmRTf0VLsJ5uQY6CRgKaMGIA1QoZjwj10/8iqwtRU f0ktSAraY3vip96SxCRrFYm3kwy6uzanF3fN3vQXvHiffJIut3fHvhT1Z9qetZWZqwv+ klRuF3WPOAy+yN+M0S1zlFnZN6Nt9ZgjoCijq8ty7u4In9EAYLVFXreOdSMAehcpJd+K Erqao8tEuHfHQfMkyi0IK3EiD/v6oJmyJ7RLcXhDRfUXB907WsNngF4mIfgyqTEwMNDp kN1Q==
X-Gm-Message-State: ALoCoQkoonoaGmiAb99fXI8H7Fq+FV+mHwsJdEihuiqkvr44f9/qpG2uIC2xGCPv7njJ8ebksivG
X-Received: by with SMTP id s49mr423796eeg.54.1378886428088; Wed, 11 Sep 2013 01:00:28 -0700 (PDT)
Received: from ( []) by with ESMTPSA id p5sm38037023eeg.5.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 01:00:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley <>
In-Reply-To: <>
Date: Wed, 11 Sep 2013 10:00:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Samuel Weiler <>
X-Mailer: Apple Mail (2.1283)
X-Mailman-Approved-At: Wed, 11 Sep 2013 02:30:11 -0700
Cc: Ray Bellis <>,,,
Subject: Re: [secdir] secdir review of draft-ietf-homenet-arch-10
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Sep 2013 08:00:37 -0000

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

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

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

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:
> -- "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?

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


- Mark