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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <mglt.ietf@xxxxxxxxx>
Date: Wednesday, 08 February 2023 at 17:36
To: Anthony Somerset <Anthony.Somerset@xxxxxxxxxxx>
Cc: dnsdir@xxxxxxxx <dnsdir@xxxxxxxx>, draft-ietf-homenet-front-end-naming-delegation.all@xxxxxxxx <draft-ietf-homenet-front-end-naming-delegation.all@xxxxxxxx>, homenet@xxxxxxxx <homenet@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Re: [homenet] Dnsdir last call review of draft-ietf-homenet-front-end-naming-delegation-26

 

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 <noreply@xxxxxxxx> 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
homenet@xxxxxxxx
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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux