Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
Apologies for the very late reply: change weekends. Daniel Migault mailto:mglt.i...@gmail.com 20 March 2015 20:55 Hi Ray, Please see my comments in text. 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. Thank you for raising this point, but this is not the case. I need to make the text clearer. When a renumbering occurs, the Hidden Master changes its IP address, and has to provide the new IP address to the slave. This can be done with DNS extensions or other layers. I will update the section 9.1.2 to clarify this. Cool. Thanks. 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 am not sure I correctly get the use case: a) It seems to me you consider also the case where the slave is being renumbered. I did not considered this point and assume these servers will hardly renumbered. To be honest this should be a corner case. But it would be nice if the slave was also discovered via a DNS records rather, than a literal, or cached IPv6 address. b) It also seems to me you consider a Homenet work that is removed or not in used, and you wonder what happen to the zone? My understanding is that it is similar a service you subscribed and you do not use. Do you mean that we should state that after some time, the slave may remove its zone? Correct. It would be cruft removal. Can you please elaborate on the use cases you think we should comment? Is sounds to me these considerations may not be related to renumbering, but instead to general operations. They are indeed more general cases of changes. 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. This is mentioned in the NOTIFY RFC1996 in the security consideration. A forged NOTIFY results makes the slave trigger a SOA query. These are small paquets, thus the amplification factor is very small. RFC1996 qualify it as a begnin DoS attack. But I agree I will comment on that. Actually I though of writing a specific section on it. That will be done in the next version anyway. If we are not specifying the mechanism more precisely, then there should be some warning that the slave should only try once to reach the new hidden master for every incoming notify request. Ant retries should be triggered from the hidden master sending a new NOTIFY request, not the slave retrying independently. Otherwise you really are creating an amplification attack. 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. This is the case, as authentication is based only cryptographic keys. The IP address is only used for reach-ability and is never used otherwise. -- Regards, RayH -- Daniel Migault Ericsson -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
Hi, Thanks for the comments. We have also discussed this issue during the meeting in Dallas, I will provide a version soon. BR, Daniel On Fri, Apr 3, 2015 at 3:46 PM, Ray Hunter v6...@globis.net wrote: Apologies for the very late reply: change weekends. Daniel Migault mglt.i...@gmail.com 20 March 2015 20:55 Hi Ray, Please see my comments in text. 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. Thank you for raising this point, but this is not the case. I need to make the text clearer. When a renumbering occurs, the Hidden Master changes its IP address, and has to provide the new IP address to the slave. This can be done with DNS extensions or other layers. I will update the section 9.1.2 to clarify this. Cool. Thanks. 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 am not sure I correctly get the use case: a) It seems to me you consider also the case where the slave is being renumbered. I did not considered this point and assume these servers will hardly renumbered. To be honest this should be a corner case. But it would be nice if the slave was also discovered via a DNS records rather, than a literal, or cached IPv6 address. Exactly, if the primary designates the secondaries with FQDNs it makes synchronization resilient to secondary renumbering. This has been suggested by Mark, and I have this on my local copy. b) It also seems to me you consider a Homenet work that is removed or not in used, and you wonder what happen to the zone? My understanding is that it is similar a service you subscribed and you do not use. Do you mean that we should state that after some time, the slave may remove its zone? Correct. It would be cruft removal. Can you please elaborate on the use cases you think we should comment? Is sounds to me these considerations may not be related to renumbering, but instead to general operations. They are indeed more general cases of changes. 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. This is mentioned in the NOTIFY RFC1996 in the security consideration. A forged NOTIFY results makes the slave trigger a SOA query. These are small paquets, thus the amplification factor is very small. RFC1996 qualify it as a begnin DoS attack. But I agree I will comment on that. Actually I though of writing a specific section on it. That will be done in the next version anyway. If we are not specifying the mechanism more precisely, then there should be some warning that the slave should only try once to reach the new hidden master for every incoming notify request. Ant retries should be triggered from the hidden master sending a new NOTIFY request, not the slave retrying independently. Otherwise you really are creating an amplification attack. Well, in our case, the NOTIFY payload is authenticated. Eventually, the NOTIFY may be replayed multiple time during the valid time of the RRSIG. The slave is expected to have protections against replay attacks, especially given that NOTIFY are not expected to be sent in burst and multiple renumbering are expected o happen rarely. I think we consider this case then, and I will try to make it clear. 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. This is the case, as authentication is based only cryptographic keys. The IP address is only used for reach-ability and is never used otherwise. -- Regards, RayH -- Daniel Migault Ericsson -- Daniel Migault Ericsson -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
Hi Ray, Please see my comments in text. 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. Thank you for raising this point, but this is not the case. I need to make the text clearer. When a renumbering occurs, the Hidden Master changes its IP address, and has to provide the new IP address to the slave. This can be done with DNS extensions or other layers. I will update the section 9.1.2 to clarify this. 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 am not sure I correctly get the use case: a) It seems to me you consider also the case where the slave is being renumbered. I did not considered this point and assume these servers will hardly renumbered. b) It also seems to me you consider a Homenet work that is removed or not in used, and you wonder what happen to the zone? My understanding is that it is similar a service you subscribed and you do not use. Do you mean that we should state that after some time, the slave may remove its zone? Can you please elaborate on the use cases you think we should comment? Is sounds to me these considerations may not be related to renumbering, but instead to general operations. 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. This is mentioned in the NOTIFY RFC1996 in the security consideration. A forged NOTIFY results makes the slave trigger a SOA query. These are small paquets, thus the amplification factor is very small. RFC1996 qualify it as a begnin DoS attack. But I agree I will comment on that. Actually I though of writing a specific section on it. That will be done in the next version anyway. 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. This is the case, as authentication is based only cryptographic keys. The IP address is only used for reach-ability and is never used otherwise. -- Regards, RayH -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
Daniel Migault mailto:mglt.i...@gmail.com 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
Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
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
Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
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 v6...@globis.net wrote: Daniel Migault wrote: Hi, Please find the new version of DHCP Options for Homenet Naming Architecture
Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
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: internet-dra...@ietf.org mailto:internet-dra...@ietf.org Date: Tue, Feb 17, 2015 at 8:33 PM Subject: [homenet] I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt To: i-d-annou...@ietf.org mailto:i-d-annou...@ietf.org Cc: homenet@ietf.org mailto:homenet@ietf.org 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 homenet@ietf.org mailto:homenet@ietf.org 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
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: internet-dra...@ietf.org Date: Tue, Feb 17, 2015 at 8:33 PM Subject: [homenet] I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt To: i-d-annou...@ietf.org Cc: homenet@ietf.org 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
