Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt
Hiya, A few responses below... On 26/05/2021 18:02, Daniel Migault wrote: Hi Stephen, Thanks for the questions / suggestions / comments. Please find some responses inline. I updated the document [1] and added issues on the git repo. Yours, Daniel [1] https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/cc07384cf6a93794f984d3393100e700a306317c#diff-1fb3d4609e8b03755bf2390df10a5ccd792f989796a0b922a273cd63418fcaa5 On Mon, May 24, 2021 at 5:01 PM Stephen Farrell wrote: Hiya, I had a read of this one. My comments (as an individual, not as chair) below. I'll chat with Barbara to see if we have a common position on how to handle next steps but am happy to chat about stuff below whenever. Cheers, S. review of draft-ietf-homenet-front-end-naming-delegation-15 sf, 20210524 general/technical: #1 This needs significant editorial work, there are too many grammatical issues, at least some of which lead to ambiguity. #2 If a home network/CPE isn't robust enough to serve as a DNS server for it's public zone, then how is it robust enough to resist attack/DoS on the addresses exposed in that zone? That seems to me to counter a bunch of the arguments for this approach, so I'd like to understand the proponents arguments there. At minimum, any for an "inside" server/name means that the CPE's f/w will be subject to the same kind of attacks that might happen if the CPE was the only/primary DNS server for the zone. CPE are optimized for packet l2/l3 packet switching as opposed to terminate services. Resources of the CPE are estimated for volumetric attacks that are expected to be handled by the ISP. Hosting DNS changes the scope on that the CPE becomes an addressable target, subject to application DoS attacks which it has not been in general designed for and which are much harder to tackle for an ISP as this is "legitimate" traffic. The document does not specify the HNA is addressable from inside the network and Figure 1 clearly separates the authoritative server from the HNA. Of course this could be implemented this way, but I am wondering if there is any text that suggests such an approach. It seems to me that discussion over the management of the authoritative DNS server on the CPE is out of the scope of the document. In addition, if an DDoS attack is handled from inside the homenet, the network admin is more likely to unplug that device than if performed from the Internet. I still don't get it sorry. Shodan and zmap will allow anyone to find the listening port in many cases, regardless of that being port 53/853 on the CPE or 443 (or even, gulp! port 80) on some host further into the homenet. My point here is not that one ought not provide a listening process within a homenet, but only that this proposal doesn't really solve robustness issues. #3 The arguments about handling "disruption with the ISP" could do with some more evidence, not necessarily as text in the draft, but it ought exist - does it? E.g. do we know that publishing ULAs isn't problematic? Do we know that GUAs in such scenarios aren't still usable for longish durations given a realistic pattern of ISP disruption? ISP disruption is not an argument but a requirement from RFC7368 section 3.7.5. I think we all experience some connectivity disruption, so I do not believe there is a need to clarify this exists. The most obvious case is equipment that goes down for some time. Sure. To try re-phrase my question: do we have evidence that the approach proposed here is more robust in that scenario? Yes I can see that resolving foo.myhome.example from inside to the HNA should still work, but how much better will that be *overall* given that foo.myhome.example may be cached in the stub resolver of clients on the homenet? I'm wondering if anyone's tried that kind of thing and said what they found basically. (And similarly wondering if publishing ULAs in the public DNS has any downsides.) A transition from one ISP to another seems to me a bit out of scope of the document. The document considers renumbering which could be a good start for a more complex management transition, that sounds to me very specific and out of scope of the document. We have added a section in the security consideration that I think covers your concern: """ The HNA enables to handle network disruption as it contains the Public Homenet Zone, which is provisioned to the Homenet Authoritative Servers. However, DNSSEC validation requires to validate the chain of trust with the DS RRset that is stored into the parent zone of the Registered Homenet Domain. As currently defined, the handling of the DS RRset is left to the Homenet DNSSEC resolver which retrieves from the parent zone via a DNS exchange and cache the RRset according to the DNS rules, that is respecting the TTL and RRSIG expiration time. Such constraints do put some limitations to the type of disruption the proposed architecture can handle. In particular, the disruption is expected to
Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt
Hi Juliusz, I think we responded to the question in 2014 [1]. I am happy to clarify our text of section 1.2. Could you please point out what in the draft you believe is wrong and what you would like to be updated. Yours, Daniel [1] https://mailarchive.ietf.org/arch/msg/homenet/qL5BmPs5LOi281AMTCD_lHt49Is/ On Tue, May 25, 2021 at 8:23 AM Juliusz Chroboczek wrote: > > #5 The arguments why this is better than DDNS don't convince > > me, except for the last one (new RR types). Given that DDNS is > > deployed, what's the chances that this would also get traction? > > I think that's an important point. I actually asked the very same > question back in 2014: > > > https://mailarchive.ietf.org/arch/msg/homenet/CBoLV2St-kSW0vQNE4GtKqRQthA/ > > https://mailarchive.ietf.org/arch/msg/homenet/m3tmE8m1pt11YIB5yAtWUMFlv3c/ > > The authors integrated the discussion as Section 1.2 of the draft, which > is what you are referring to. I'm not sure if I'm convinced by their > arguments, I suspect that there's some unstated requirement that I don't > undestand. > > -- Juliusz > > ___ > 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
Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt
Hi Stephen, Thanks for the questions / suggestions / comments. Please find some responses inline. I updated the document [1] and added issues on the git repo. Yours, Daniel [1] https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/cc07384cf6a93794f984d3393100e700a306317c#diff-1fb3d4609e8b03755bf2390df10a5ccd792f989796a0b922a273cd63418fcaa5 On Mon, May 24, 2021 at 5:01 PM Stephen Farrell wrote: > > Hiya, > > I had a read of this one. My comments (as an individual, not > as chair) below. I'll chat with Barbara to see if we have a > common position on how to handle next steps but am happy to > chat about stuff below whenever. > > Cheers, > S. > > review of draft-ietf-homenet-front-end-naming-delegation-15 > sf, 20210524 > > general/technical: > > #1 This needs significant editorial work, there are too many > grammatical issues, at least some of which lead to ambiguity. > > #2 If a home network/CPE isn't robust enough to serve as a DNS > server for it's public zone, then how is it robust enough to > resist attack/DoS on the addresses exposed in that zone? That > seems to me to counter a bunch of the arguments for this > approach, so I'd like to understand the proponents arguments > there. At minimum, any for an "inside" server/name means > that the CPE's f/w will be subject to the same kind of attacks > that might happen if the CPE was the only/primary DNS server > for the zone. > > CPE are optimized for packet l2/l3 packet switching as opposed to terminate services. Resources of the CPE are estimated for volumetric attacks that are expected to be handled by the ISP. Hosting DNS changes the scope on that the CPE becomes an addressable target, subject to application DoS attacks which it has not been in general designed for and which are much harder to tackle for an ISP as this is "legitimate" traffic. The document does not specify the HNA is addressable from inside the network and Figure 1 clearly separates the authoritative server from the HNA. Of course this could be implemented this way, but I am wondering if there is any text that suggests such an approach. It seems to me that discussion over the management of the authoritative DNS server on the CPE is out of the scope of the document. In addition, if an DDoS attack is handled from inside the homenet, the network admin is more likely to unplug that device than if performed from the Internet. > #3 The arguments about handling "disruption with the ISP" could > do with some more evidence, not necessarily as text in the > draft, but it ought exist - does it? E.g. do we know that > publishing ULAs isn't problematic? Do we know that GUAs in such > scenarios aren't still usable for longish durations given a > realistic pattern of ISP disruption? > > ISP disruption is not an argument but a requirement from RFC7368 section 3.7.5. I think we all experience some connectivity disruption, so I do not believe there is a need to clarify this exists. The most obvious case is equipment that goes down for some time. A transition from one ISP to another seems to me a bit out of scope of the document. The document considers renumbering which could be a good start for a more complex management transition, that sounds to me very specific and out of scope of the document. We have added a section in the security consideration that I think covers your concern: """ The HNA enables to handle network disruption as it contains the Public Homenet Zone, which is provisioned to the Homenet Authoritative Servers. However, DNSSEC validation requires to validate the chain of trust with the DS RRset that is stored into the parent zone of the Registered Homenet Domain. As currently defined, the handling of the DS RRset is left to the Homenet DNSSEC resolver which retrieves from the parent zone via a DNS exchange and cache the RRset according to the DNS rules, that is respecting the TTL and RRSIG expiration time. Such constraints do put some limitations to the type of disruption the proposed architecture can handle. In particular, the disruption is expected to start after the DS RRset has been resolved and end before the DS RRset is removed from the cache. One possible way to address such concern is to describe mechanisms to provision the DS RRset to the Homenet DNSSEC resolver such as HNCP for example. Such work is out of the scope of this document and is left from future work. """ Similarly, the zone content is also a bit out of scope of the document and the admin is supposed to be responsible for what he is publishing. The text mentions the publication of ULA with a may, as an example. I think it is useful to have this as a consideration but elaborating on this may end up in a complete book of managing the homenetwork, which I do not think is the purpose of this - already long - document. Removing the text would not affect the scope of the document, but I think it is useful information to avoid some mis-conceptions. #4 My home network is IPv6 renumbered every
