Subject: [homenet] I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-02.txt

From: [email-masked]
Date: Tue, 19 May 2015 08:58:40 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Home Networking Working Group of the IETF.

        Title           : DHCP Options for Homenet Naming Architecture
        Authors         : Daniel Migault
                          Wouter Cloetens
                          Chris Griffiths
                          Ralf Weber
	Filename        : draft-ietf-homenet-naming-architecture-dhc-options-02.txt
	Pages           : 28
	Date            : 2015-05-19

Abstract:
   CPEs are usually constraint devices with reduced network and CPU
   capacities.  As such, a CPE hosting on the Internet the authoritative
   naming service for its home network may become vulnerable to resource
   exhaustion attacks.  One way to avoid exposing CPE is to outsource
   the authoritative service to a third party.  This third party can be
   the ISP or any other independent third party.

   Outsourcing the authoritative naming service to a third party
   requires setting up an architecture which may be unappropriated for
   most end users.  To leverage this issue, this document proposes DHCP
   Options so any agnostic CPE can automatically proceed to the
   appropriated configuration and outsource the authoritative naming
   service for the home network.  This document shows that in most
   cases, these DHCP Options make outsourcing to a third party (be it
   the ISP or any ISP independent service provider) transparent for the
   end user.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-naming-architecture-dhc-options-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Daniel Migault <[email-masked]>
Date: Tue, 19 May 2015 16:58:00 +0000

Hi, 

I believe draft-ietf-homenet-front-end-naming-delegation [1] , draft-ietf-homenet-naming-architecture-dhc-options [2] have addressed all comments we received so far. I believe these document are ready.

draft-ietf-homenet-front-end-naming-delegation-02 addresses the renumbering issue and added significant text in the security considerations section. So, please have a look these sections.

draft-ietf-homenet-naming-architecture-dhc-options-02.txt. The only changes from the previous version is the replacement of master/slave by primary/secondary. 

Feel free to provide feed backs!
BR, 
Daniel

[1] https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-02
[2] https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-02

-----Original Message-----
From: homenet [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, May 19, 2015 11:59 AM
To: [email-masked]
Cc: [email-masked]
Subject: [homenet] I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-02.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet

---

From: Ray Hunter <[email-masked]>
Date: Wed, 20 May 2015 13:35:47 +0200

Daniel Migault wrote:
> https://www.ietf.org/rfcdiff?url2=aft-ietf-homenet-naming-architecture-dhc-options-02
>
>

I have just read through 
again

Generally, it is looking pretty good.

A couple of comments:

1. The use of the name "Security Field" in section 6.1 this draft is 
rather unfortunate IMHO.

Humbly suggest "Supported Authentication Methods"? [to match terminology 
in 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-02 
]

Plus s/Security/Supported Authentication Methods/g in other sections.

2. I miss more detailed discussion in Section 7.1 about when/if a server 
should accept an update of the public key record from a CPE.

Section 9.2 notes this problem but doesn't address the problem further.

Section 9.2 should also probably note:
"The initial update of the public key between the CPE to the ISP 
infrastructure is fundamental to the security of the entire name 
delegation process. If an attacker can subvert the initial public key 
update, then all further security and encryption mechanisms may also be 
subverted."

Shouldn't section 9.2 of the draft " It is therefore RECOMMENDED to use 
the Authentication Option as specified in Section 22.11 of RFC3315"

I realise that there are conflicting requirements between zeroconf and 
knowing precisely which CPE is related to which customer.

3. Is there a need here for potentially further 
authentication/validation of the public key update option itself?

A number of mechanisms come to mind for consideration:
- no additional security
- server enforces a strong coupling between DHCP DUID <-> CPE 
authentication and customer related data (domain names, CPE public key)
- identifying a CPE by physical port of the inbound DHCP message and 
rejecting messages received on other physical ports
- locking updates on the server for public key records whilst an 
existing key is valid for this DUID/ DHCP Authentication pairing
- magic trust bootstrap via an out of band exchange leading to a nonce 
to be included with the OPTION_PUBLIC_KEY option

The first four items on the list would be server specific implementation 
choices, whereas the last would require an additional DHCP option to 
transport any nonce.

regards,
RayH