Daniel Migault <mailto:[email protected]>
16 March 2015 02:48
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.
--
Daniel Migault
Ericsson
------------------------------------------------------------------------
I think the description of the requirements and overall chain of events
is excellent. Thanks for that.
However I'm not particularly convinced by the security and
authentication mechanisms, as the proposed text just seems to punt these
to another transport protocol.
I also don't see the recovery mechanism/ how to distinguish between a
break before make event, and a make before break where the ISP's DNS
servers may not be reachable at the moment of renumbering, or that a
Homenet is simply not reachable for some time, and comes up "unnumbered"
with no old IP, or that the Homenet never comes back at all. It seems to
me that you could also end up hosting lots of cruft in the ISP servers,
and there's a need for some garbage collection.
I also expect we need some more limitations on when/why a slave would
poll an unknown hidden master, otherwise it seems to me that we have a
nice DoS vector/ amplification attack. A number of attack machines could
spoof notification messages pointing to various ISP slave systems, all
pointing to a common target victim "new" hidden master.
It feels to me like
1) we need a more reliable update mechanism between the hidden master
and the slaves (to cover longer-term unreachability events, or a Homenet
hidden master going off air permanently)
2) we need a more effective authentication mechanism for triggering
updates, that is source IP address agnostic.
--
Regards,
RayH
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
