Re: [homenet] Dnsdir last call review of draft-ietf-homenet-front-end-naming-delegation-26

[Daniel Migault <[e-mail]>]

Hi Anthony,

Thanks for the response and the multiple reviews. These reviews have been
useful and in general I am happy with what we received from the various
directorates - so thanks for the extra work.

Yours,
Daniel

On Thu, Feb 9, 2023 at 5:31 AM Anthony Somerset
<[e-mail]> wrote:

> Hi Daniel
>
>
>
> I am happy with the proposed rewording of DDoS attack surface – this at
> least remains accurate to what is taking place.
>
>
>
> Thanks
>
>
>
> Anthony
>
>
>
> *From: *Daniel Migault <[e-mail]>
> *Date: *Wednesday, 08 February 2023 at 17:36
> *To: *Anthony Somerset <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: [homenet] Dnsdir last call review of
> draft-ietf-homenet-front-end-naming-delegation-26
>
> CAUTION: This email has originated from a free email service commonly used
> for personal email services, please be guided accordingly especially if
> this email is asking to click links or share information.
>
>
>
> Hi Anthony,
>
>
>
> Thanks for the review. Please find below how we intend to address your
> comments.
>
>
>
> Yours,
> Daniel
>
>
>
> On Tue, Jan 31, 2023 at 12:32 PM Anthony Somerset via Datatracker <
> [e-mail]> wrote:
>
> Reviewer: Anthony Somerset
> Review result: Ready with Issues
>
> Hello
>
> I have been selected as the DNS Directorate reviewer for this draft. The
> DNS Directorate seeks to review all DNS or DNS-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the ADs.
> For more information about the DNS Directorate, please see
> https://wiki.ietf.org/en/group/dnsdir
>
> There are are clear and direct references to various DNS RFC's and this
> draft is not in any major conflict with the wider DNS space but the
> following specific suggestions relating to DNS are made.
>
> I previously Reviewed Version 18 of this draft and am re-rereviewing in
> line with the comments I made in that review -
>
> https://datatracker.ietf.org/doc/review-ietf-homenet-front-end-naming-delegation-18-dnsdir-telechat-somerset-2022-10-12/
>
> Having re-read the new version a few times, and keeping track of the
> various
> reviews as not to duplicate reports for same issues i will try not say the
> same
> things again.
>
> I specifically note that Geoff has done a very definitive review of
> version 25
> of the document and i won't repeat those comments in this review but
> suffice
> to say i do concur with the assessment of the situation in his review and
> agree with the position of Ready with Issues as well
>
> I am happy with the large effort to reflow the document - it does now read
> in a
> more sensible order and helps with clarity.
>
> I am also happy with the additional security considerations that make
> sense.
>
> Major Issues: None
>
> Minor Issues:
>
> Section 2 - Public Authoritative Servers - my original NIT was dealt with
> but I
> note that anycast is now referenced here which is still extraneous, we are
> not
> attempting to deal with the standard of how Public Authoritative Servers be
> managed operationally
>
>
>
> I agree that we are not concerned on how the Public Authoritative Servers
> are managed. I suppose the comment is concerning the following sentence.
>
> If that the case, I am not reading any suggestion on how these servers are
> operated. Our main purpose here is to make sure the reader understands
> which servers we are talking about. This is the sense of the sentence: "are
> often implemented in an anycast fashion.". I propose to leave the text as
> it, but remain open to changes if I am missing something.
>
> """
>
>  are the authoritative name servers for
>       the Public Homenet Zone.  Name resolution requests for the
>       Registered Homenet Domain are sent to these servers.  Some DNS
>       operators would refer to these as public secondaries, and for
>       higher resiliency networks, are often implemented in an anycast
>       fashion.
>
> """
>
>
>
>
> Section 3 - now Section 5 - i note specifically the comment about:
>
> "In the case the HNA is a CPE, outsourcing to the DOI protects the home
> network
> against DDoS for example."
>
> I personally would consider this a dangerously inaccurate statement.
>
> This offers NO protection against a DDoS, at best it (only) slightly
> reduces
> the attack surface exposed but it provides no meaningful additional
> protection.
>
> I specifically repeat this and recommend the statement be removed or
> re-worded
> appropriately
>
> I see your point.
>
> I propose to replace:
>
> OLD:
>
> """
>
> In the case the HNA is a CPE, outsourcing to the DOI protects the home
> network against DDoS for example.
> """
>
> by NEW:
>
> """
>
> In the case the HNA is a CPE, outsourcing to the DOI reduces the attack
> surface of the home network to  DDoS for example.
>
>  """
>
>
>
> I assume the nit mentioned below have been addressed previously. In other
> words, no action is expected.
>
>
>
> Section 3.2 - Original NIT dealt with
>
> 1.1 - now 3 - NIT dealt with
>
> 3.1 now 5.1 - Typo fixed
>
> 4.5.1 - now 6.5.1 - i believe this NIT to be well addressed now, the
> reflowing
> of the document definitely helps here.
>
> Thanks
>
>
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
> This email disclaimer applies to the original email, all attachments and
> any subsequent emails sent by Liquid Telecom. This email contains valuable
> business information that is privileged, confidential and/or otherwise
> protected from disclosure, intended only for the named person or entity to
> which it is addressed. If you are not the intended recipient of this email
> and you received this e-mail in error, any review, use, dissemination,
> distribution, printing or copying of this e-mail is strictly prohibited and
> may be unlawful and/or an infringement of copyright. Please notify us
> immediately of the error and permanently delete the email from your system,
> retaining no copies in any media. No employee or agent is authorized to
> conclude any binding agreement on behalf of Liquid Telecom with another
> party or give any warranty by email without the express written
> confirmation by an authorized representative or a director of Liquid
> Telecom. Nothing in this email shall be construed as a legally binding
> agreement or warranty or an offer to contract. Liquid Telecom will not be
> responsible for any damages suffered by the recipient as a result of the
> recipient not taking cognizance of this principle. Liquid Telecom accepts
> no liability of whatever nature for any loss, liability, damage or expense
> resulting directly or indirectly from the access of any files which are
> attached to this message. Any email addressed to Liquid Telecom shall only
> be deemed to have been received once receipt is confirmed by Liquid Telecom
> orally or in writing. An automated acknowledgment of receipt will not
> suffice as proof of receipt by the Liquid Telecom. This email disclaimer
> shall be governed by the laws of South Africa.
>
> Internal All Employees
>


-- 
Daniel Migault
Ericsson