Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt

[Daniel Migault <[e-mail]>]

Hi,

Thank you for raising this issue. I think we should add some text in the
architecture draft [1] rather than the dhcp draft.

I would propose the following text. Please let me know if this addresses
your concern, so I can update the draft.

9 Renumbering

This section details how the CPE is expect to handle renumbering.

Suppose the CPE has configured its naming architecture as depicted in
Figure 1 (Section 4.1). The CPE has set the DNS(SEC) Homenet Zone as
detailed in Section 4.2, and set its Hidden Master and the Public
Authoritative Name Server Set as detailed in Section 5. The Public
Authoritative Name Server Set is configured as a Slave for the Homenet
Domain Name and usually, its associated master is identified by its IP
address.

When a renumbering operation occurs, the CPE IP prefix is modified. As a
result, IP addresses of the Homenet DNS(SEC) Zone are not valid anymore --
as we assume the DNS(SEC) Homenet only has global reachable IP addresses.
In addition, the Slave cannot anymore reach its master.

In order to mitigate the renumbering, the CPE MUST rebuild its Homenet
DNS(SEC) Zone, and eventually re-sign the zone. As the Hidden Slave is not
anymore reachable by the slave, so the CPE is expect to provide the new IP
address to the slave so the regular master/slave synchronization can be
re-initiated. For that purpose, the CPE MUST send a NOTIFY DNS query to the
masters. When the slave receives the NOTIFY DNS query and have
authenticated the NOTIFY DNS query, it sends a response back to the
master.  The slave may notices that the IP address is not associated to the
Hidden Master IP address(es), however, the slave is not expected to update
its master / slave configuration as the IP address is most likely not
protected. Instead the slave is expected to perform a reachability check
before setting the master/slave configuration. The reachability check is
combined with the regular master/slave synchronization, that is to say a
DNS query for the SOA is sent by the slave to the master. The difference
with the regular master/slave synchronization is that the IP used to reach
the slave is not provided by the master/slave setting, but is instead
provided by the NOTIFY DNS query. If an authenticated response is received
the slave MAY update its master/slave settings with the new IP address.

The reason a change of master does not necessarily results in updating the
master/slave configuration is that the CPE may be multi-homed, in which
case multiple IP addresses may be used in parallel. In such cases, it is
not necessary to update the master/slave configuration. Instead, the update
should be performe only when the IP is not in the pool of the IP addresses
used by the CPE.  The edns-client-subnet option described in
[draft-vandergaast-edns-client-subnet-02] may be used to advertise the
valid IP addresses of the Hidden Master. However, for sake of simplicity,
we recommend that unless the slave is aware that the Hidden Master uses
multiple IP addresses, the Hidden Master uses a single IP address at a
time, meaning that a change of IP address would result in a modification of
the master/slave setting on the slave.


Note that the NOTIFY DNS query can be authenticated even though the IP
address is unknown to the slave. As described in RFC1996, the NOTIFY
payload carries the Homenet Domain Name. Similarly, if SIG(0) or TSIG is
used to secure the transaction between the Hidden Master and the slave, the
Homenet Domain Name is also indicated in the RRSIG RRset. Unless the
transport layer can handle with an IP update, if DTLS/TLS is used, than a
new socket may be opened, which results results in a new authentication
exchange before the NOTIFY DNS query is sent. If IPsec is used,
authentication is based on the IP address. Unless MOBIKE is supported by
IKEv2, a new IPsec Security Association should be negotiated. If MOBIKE is
supported, than the Hidden Master can inform the slave that its IP address
has been updated.

Note also that the IP address is not authenticated, unless IPsec with the
AH mode is used. The reliability of this IP address is left to the
reachability check. As a results, the IP address may not be the one
associated to the Hidden Master, but instead the one of a proxy or any
middle box. For this reason it matters to authenticate and protect the IP
payload with appropriated security protocols listed in Section 5.2.  One
way DNS could be used to provide the IP addresses associated to the CPE
would be to use the edns-client-subnet option described in
[draft-vandergaast-edns-client-subnet-02], however, this may be used
cautiously in case any kind of translation address mechanism occurs between
the master and the slave.






[1]
http://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-01






On Wed, Mar 4, 2015 at 7:23 AM, Ray Hunter <[e-mail]> wrote:

>
>
> Daniel Migault wrote:
>
>> Hi,
>>
>> Please find the new version of DHCP Options for Homenet Naming
>> Architecture <https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-
>> architecture-dhc-options/>.
>>
>> The issue raised on the previous version was how these options were
>> compatible with multiple ISPs. This use case is illustrated in section A. 4
>> multiple ISPs.
>>
>> BR,
>> Daniel
>>
>>
>> ---------- Forwarded message ----------
>> From: <[e-mail] <mailto:[e-mail]>>
>> Date: Tue, Feb 17, 2015 at 8:33 PM
>> Subject: [homenet] I-D Action: draft-ietf-homenet-naming-
>> architecture-dhc-options-01.txt
>> To: [e-mail] <mailto:[e-mail]>
>> Cc: [e-mail] <mailto:[e-mail]>
>>
>>
>>
>> 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-01.txt
>>         Pages           : 28
>>         Date            : 2015-02-16
>>
>> 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:
>> http://tools.ietf.org/html/draft-ietf-homenet-naming-
>> architecture-dhc-options-01
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-
>> naming-architecture-dhc-options-01
>>
>>
>> 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 <
>> http://tools.ietf.org>.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> homenet mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
> I finally got around to reading this draft. It's been on my todo list for
> some time,
>
> It looks very good, but I am missing the detail of how a renumbering event
> would be handled.
>
> Is that the same process as adding a new Homenet CPE?
>
> Worst case would seem to be where a user chooses scenario A3, but the ISP
> initiates a renumbering event without warning/coordination (new PD prefix).
>
> My understanding of the plumbing is that something like BIND running on
> the Public Authoritative Master(s)  (slaves) would be hard-coded with a
> fixed IP addresses pointing at the hidden master running on the Homenet.
> Configuring multiple masters is possible in BIND, so that's not an
> insurmountable barrier, and it would be possible to run with both addresses
> from the old and new prefixes simultaneously, and let BIND work out which
> one was reachable.
>
> But maybe if the NOTIFY process in Section 5.1.1 from the CPE to the
> Public Authoritative Master(s) anyway already contains the address from the
> new prefix, and the process already checks validity and reachability of the
> hidden master before replacing the old entry, then maybe there's no need to
> run with multiple masters for any overlapping time at all.
>
> The timing intrigues me.
>
> --
> Regards,
> RayH
>
>


-- 
Daniel Migault
Ericsson