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

[Daniel Migault <[e-mail]>]

Hi,

Thank you for the feed back. Here is an update of the renumbering section.
I considered the two cases make-before-break and break-before-make.

Feel free to make any comment.

BR,
Daniel

9 Renumbering

This section details how the CPE is expected to handle renumbering.
Renumbering has been extensively described in RFC4192 and analyzed in
RFC7010. This section is largely inspired by these document, and the reader
is expected to become familiar with them.

This section considers two ways to renumber the home network:
    - make-before-break: In this scenario, the new prefix is advertised,
the network is configured to prepare the transition to the new prefix.
During a period of time, the two prefixes old and new coexist, before the
old prefix is completely removed.
    - break-before-make: In this scenario, the new prefix is advertised
making the old prefix obsolete.

The make-before-break scenario is recommended, but this section details
both.

In both scenarios, this section is focused on how renumbering affects the
DNS(SEC) Homenet Zone and how renumbering affects the communication between
the Hidden Master and the slave hosted on the Public Authoritative Name
Server Set. This section designates by OLD_PREFIX and OLD_IP the IP prefix
and IP addresses that are to be replaced and NEW_PREFIX and the NEW_IP the
replacing IP prefix and IP addresses.

The initial situation is as follows: the CPE has configured its naming
architecture as depicted in Figure 1 (Section 4.1). More specifically, the
CPE has set the DNS(SEC) Homenet Zone as detailed in Section 4.2, and it is
assumed that some hosts are configured with OLD_PREFIX. In addition the
Hidden Master and the Public Authoritative Name Server Set are configured
as detailed in Section 5. The Public Authoritative Name Server Set is
configured as a slave for the Homenet Domain Name. The communication
between the Hidden Master and the slave uses the OLD_IP of the Hidden
Master. Usually, the slave is configured with the master's IP address. In
our case the slave is configured with OLD_IP.

    9.1 make-before-break

    In the make-before-break renumbering scenario, the CPE is informed that
renumbering will happen in the future. The CPE waits that routers ad
switches are ready to route both OLD_PREFIX and OLD_PREFIX on the home
network. The necessary time for the CPE to be aware of the bindings between
the hosts of the home network and the NEW_IPs may vary, depending on how
binding between the NEW_IPs and the various hosts in the home network is
performed as well as how the CPE is informed of the newly assigned IP
addresses. After some time, either that all hosts have provided their
corresponding NEW_IPs or a timer has expired, the CPE provides an updated
version of the DNS(SEC) Homenet Zone to the Hidden Master. As explained in
Section 9.1.1, the TTLs may also be adjusted.

    The updated DNS(SEC) Homenet Zone is then updated on the slave using
the same configuration as used until now. In fact, there is no need to
update the master/slave configuration as currently both IP addresses of the
Hidden Master are reachable (IP_OLD and IP_NEW). This process may have been
proceed earlier, or may be processed later. Even though updating the
DNS(SEC) Homenet Zone and updating the IP address used by the Hidden Master
are completely different processes, they may be combined as explained in
section 9.1.2. At that time, the DNS(SEC) Homenet Zone has been updated
with both NEW_IPs and OLD_IPs, the DNS(SEC) Homenet Zone is being publicly
published on the Public Masters, and the master/slave mechanism uses the
NEW_IP of the Hidden Master.

    The final step consists in removing the OLD_IPs of the DNS(SEC) Homenet
Zone file and updating the zone on the Public Masters. The removal of the
OLD_IPs RRsets SHOULD be performed such that there is no more RRSets
contains OLD_IPs in any cache when OLD_PREFIX is not reachable anymore.
TTLs should be chosen appropriately to meet timing constraints as explained
in section 9.1.1.

    9.1.1 Adjusting TTLs

    As TTL designates how long the RRsets are cached, they should be
adjusted regarding the time both OLD_IP and NEW_IP are reachable and the
time OLD_IPs are removed from the DNS(SEC) Homenet Zone. Let T_OLD_NEW
designate the time the DNS(SEC) Homenet Zone contains both OLD_IPs and
NEW_IPs, and T_NEW the time when OLD_IPs are removed from the DNS(SEC)
Homenet Zone. Let OLD_TTL the TTL value before T_OLD_NEW, OLD_NEW_TTL the
TTL value after T_OLD_NEW and NEW_TTL the TTL value after T_NEW.

    When a RRset is modified, it takes 2*TTL seconds for the previous value
to be removed from all caches. As a result, it will take 2*OLD_TTL before
the DNS(SEC) Homenet Zone becomes stable have have its RRsets containing
both OLD_IPs and NEW_IP in all caches. Going to a stable state where both
OLD_IP and NEW_IP are stored in caches is not mandatory. On the other hand,
it is of primary importance that OLD_IP is not anymore in caches when
OLD_PREFIX becomes unreachable, i.e. T_OLD_NEW + 2 OLD_TTL <
T_OLD_PREFIX_UNREACHABLE. This equation provides indication on how to chose
T_OLD_NEW  as other parameters may be fixed. Similarly, T_NEW should be
chosen so that T_NEW + 2*OLD_NEW_TTL < T_OLD_PREFIX_UNREACHABLE. This
equation provides indications on how OLD_NEW_TTL and T_NEW may be chosen.

    Figure below illustrates a timing example.



       Updating Zone    Last RRsets with      Updating Zone   Last RRsets
with     T_OLD_PREFIX_UNREACHABLE
       with OLD_IP      OLD_IP only expires   with NEW_IP     OLD_IP and
NEW_IP    OLD_PREFIX becomes
       and NEW_IPs      from cache            only            expires from
cache   unreachable
             |               |                       |
|                 |
             |               |                       |
|                 |
   OLD_TTL   v  OLD_NEW_TTL  v                       v  NEW_TTL
v                 v

----------+---------------+-----------------------+------------+----------------------
          T_OLD_NEW       T_OLD_NEW + 2 OLD_TTL    T_NEW      T_NEW +
2*OLD_NEW_TTL




    9.1.2 Updating the IP address of the Hidden Master


    This section details how the slave may be advertised the Hidden Master
has changed its IP address, and consequently update its configuration. Note
also that the IP address of the Hidden Master does not appear in the
DNS(SEC) Homenet Zone as the Hidden Master is kept "hidden".

    The Hidden Master sends 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 may be 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 performed 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.

    9.2 break-before-make

    In the break-before-make, the CPE is being assigned a new prefix at the
time the old prefix is not reachable. This situation necessarily results in
making the hosts unreachable, as the DNS cannot be updated instantly. More
specifically, RRset with OLD_IP will remain in cache for 2*TTL.

    In this case, the DNS(SEC) Homenet Zone is rebuilt with the NEW_IPs
only, and eventually resigned. In fact OLD_IPs are already unreachable,
thus they are not mentioned in the zone. The Hidden Master then performs
sends a NOTIFY using the newly assigned IP address and performs both a zone
synchronization and a configuration update at the same time as described in
section 9.1.2.





On Sat, Mar 14, 2015 at 8:05 PM, Brian E Carpenter <
[e-mail]> wrote:

> > 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.
>
> That seems to assume a break-before-make renumbering. The preferred
> scenario is make-before-break, although we need to be able to support
> both. I hope you can adjust the text to allow both.
>
>     Brian
>



-- 
Daniel Migault
Ericsson