Subject: [homenet] naming drafts

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 4 Jun 2021 19:45:16 +0000

Hi homenet WG,
Stephen and I have been chatting about the status of the 2 naming drafts (draft-ietf-homenet-front-end-naming-delegation and draft-ietf-homenet-naming-architecture-dhc-options). 

We started a 3-week WGLC about a month ago (04 May). Both drafts received comprehensive review from Med. Stephen reviewed front-end-naming-delegation. Bernie reviewed the formatting of the DHC option. 
The authors provided updates to resolve these comments. Bernie acknowledged satisfactory resolution of his comments.
Requests to change terminology were satisfactorily resolved -- but that discussion doesn't count as really being part of anyone's review of the drafts.
Stephen and Juliusz expressed that they're still not convinced that DDNS isn't a good enough solution for the use case.

Stephen and I do not believe these drafts have received enough review or support to put them forward as representing WG consensus.

But the authors have spent significant effort in creating these drafts and the associated implementation. We will work with Éric V (as INT area AD) and the authors to determine next steps.

Barbara and Stephen

---

From: Michael Richardson <[email-masked]>
Date: Sat, 05 Jun 2021 14:46:16 -0400

STARK, BARBARA H <[email-masked]> wrote:
    > Stephen and Juliusz expressed that they're still not convinced that
    > DDNS isn't a good enough solution for the use case.

Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.

What specific solution are they talking about?  Tell us the whole story,
including how the credential gets into the device.

In particular, I'd like to know if it's okay with them if an arbitrary device
in their home automatically signs up with a DDNS provider, disclosing their
IPv6 address to the world.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 05 Jun 2021 21:33:00 +0200

Hi Michael,

> actually tell us what "DDNS" really is for them.

https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/

> IPv6 address to the world.

No; unless the user has explicitly requested that a device be accessible
from the Global Internet, it has no business publishing its IP address.
I've tried to be very clear on that specific point in the mail linked above.

Hope that clarifies things,

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Jun 2021 15:03:15 -0400

> https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/

Hi, thanks for that email, let me paste parts of it in.
I didn't find any clear definition of how DDNS works in that email.

    > I've tried to be very clear on that specific point in the mail linked above.

jc> Oh, nothing that geeky.  I copy my vacation photographs onto my NAS. I
jc> click the "share over the Internet" button on the NAS's web
jc> interface. The NAS performs DynDNS registration,

So, explain to me that this part works: "the NAS performs DynDNS registration"?

First, are you talking about RFC3007? No, I don't think so.  What's the
Performance Specification that describes this process?  Yes, I know where
the vendor specific documentation is.

Second, how are the credentials for that communication established?
What name does your NAS pick?   How did you communicate the credential to the
NAS?
Once the 14 year old in the house does this, how does the parent find out
about the name that was used?

Was it IPv4, IPv6 (and from which ISP, as our homenet architecture says we
can have more than one ISP. That's why we did all that BABEL stuff, right?),
and did the device publish a SLAAC derived IP, a privacy IP, a stable IPv6?

If the device renumbers, or experiences a flash renumbering, how does it know
to re-register?

So, let me know the details here, as these are the kind of things the HNA
mediated zone is dealing with.

> Sure.  Just like you, I'm expecting dynamic updates.  But I don't expect
> dynamic updates to be dependent on my CPE, which is buggy (it was provided
> by the major competitor of your employer) and isn't available at the

All sorts of devices can be buggy.
I don't expect to be dependent upon a buggy NAS either.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Jun 2021 20:32:22 +0100

Hi Michael,

> actually tell us what "DDNS" really is for them.

Just to clarify: I don't think/claim DDNS is "better" than
the proposal here, rather I don't find the arguments as to
why this is "better" convincing, and so, given that DDNS is
deployed, and has some similarity, I'm wondering if this
spec really has much of a chance at gaining traction.

As a result, I don't really think there's that much value
in attempting a point-scoring exercise comparing the two,
the question for me is really whether or not this spec is
so much better than DDNS that it could displace DDNS, and
I'm not convinced as of now. (But I'm often wrong of course.)

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Jun 2021 16:24:05 -0400

> spec really has much of a chance at gaining traction.

I don't think that they solve the same problem, nor do they have the same audience.

In particular, DDNS is very IPv4 specific and very divorced from ISP
operations, while the front-end naming is very IPv6 focused and integrates
much better with ISP operations.

Nothing we've done in Homenet has gained any traction, why do the chairs
suddenly care?

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Tue, 8 Jun 2021 11:29:56 +0200

Stephen Farrell wrote on 07/06/2021 21:32:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

Just trying to understand this hurdle/ line of reasoning.

So in addition to achieving "rough consensus", the IETF standardization 
process must also produce drafts that are very likely to gain traction 
to displace non-IETF non-standardised products that are already widely 
commercially deployed?

If that is the case, then perhaps the WG should have steered the draft 
to have been "DDNS, but standardised" or "a TR-069 compatible interface 
for DNS zone delegation".

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Jun 2021 11:05:35 +0100

Hiya,

> to displace non-IETF non-standardised products that are already widely 

No. This is not a process hurdle. It was one amongst
a bunch of personal comments I sent. And that I'm happy
to discuss with the authors without wearing any chair
or other hat.

The process problem with these drafts is the lack of
review means there's no way to claim they represent any
useful level of WG consensus.

Cheers,
S.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 08 Jun 2021 15:24:51 +0200

> I didn't find any clear definition of how DDNS works in that email.

[...]
> What's the Performance Specification that describes this process?  Yes,
> I know where the vendor specific documentation is.

As far as I'm aware, all the REST-like DDNS protocols are vendor-specific.
However, they are widely deployed.  To give a data point, the ISP-provided
CPE I'm using right now implements no less than three distinct vendor
protocols for name registration (disabled by default, thankfully).

Michael, it would probably take you 20 minutes to write up an I-D
describing a reasonable REST-based DDNS protocol, another 5 minutes to
write a client implementation in Javascript, and one hour to write
a robust server that is well integrated with Bind.

> [...]  What name does your NAS pick?  [...] Once the 14 year old in the
> house does this, how does the parent find out about the name that was
> used?

[...]

> If the device renumbers, or experiences a flash renumbering, how does it
> know to re-register?

All of these are interesting issues.  However, I don't see how they depend
on whether the update is carried over HTTPS or AXFR.

-- Juliusz

---

From: Daniel Migault <[email-masked]>
Date: Tue, 8 Jun 2021 09:55:37 -0400

I disagree that discussing whether the proposal will take over DDNS is a
side discussion that unfortunately happens at a bad time. If I interpret
the WGLC report, it is clearly noted as a lack of support.

Predictions are not a technical discussion and can be very wrong ( "we will
never make a 32 bit operating system", "there is no reason anyone would
want a computer in their home"... the list can be as long as we wish). It
should not be considered in the decision to move the document forward. Will
it replace DDNS - I do not know. Not more than Stephen or Juliusz. I am
happy to have this discussion in 2 years. Today it gives a toxic tone to
the discussion.

I agree that more reviews is always preferred, but I am wondering how many
reviews would have been considered sufficient. Looking at the homenet
mailing list we can see that the number of reviews reflects the
participation of the mailing list. Though I really value your review, I am
not sure that (even with no hat) it encourages additional reviews, as it
forces the potential reviewer to take position against the opinion of the
chair. It seems to me that, if the number of reviews were an issue, this
could have been addressed otherwise.

>From my perspective all comments have been responded to, and technical
comments have been addressed.

Regarding the support, the proposal was initiated by an ISP. Today, I am
interested in this proposal because we have some demand for it. That some
folks prefer using DDNS for their own purpose is orthogonal to us. This is
why we want it to be published.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Jun 2021 15:10:54 +0100

Hiya,

On 08/06/2021 14:55, Daniel Migault wrote:
> I disagree that discussing whether the proposal will take over DDNS
> is a side discussion that unfortunately happens at a bad time. 

Sorry, I don't get what you mean.

> If I
> interpret the WGLC report, it is clearly noted as a lack of support.

No. It's me being critical of the text. I neither support
nor oppose this stuff, but the arguments presented for that
part aren't convincing IMO, which is what my comment said.

> 
> Predictions are not a technical discussion and can be very wrong (
> "we will never make a 32 bit operating system", "there is no reason
> anyone would want a computer in their home"... the list can be as
> long as we wish). It should not be considered in the decision to move
> the document forward. Will it replace DDNS - I do not know. Not more
> than Stephen or Juliusz. I am happy to have this discussion in 2
> years. Today it gives a toxic tone to the discussion.

Toxic? That's seems quite overblown. And plain wrong, if
you mean it to describe my review. I can understand the
frustration of working on something like this and not
seeing it progress as planned, but accusing me of creating
toxicity is not a fair accusation for you to make.

> I agree that more reviews is always preferred, but I am wondering how
> many reviews would have been considered sufficient.

Oh come on - we've tried a number of times to get people
to review these documents and we've never really gotten
that to happen. The level of review is nowhere near
sufficient to declare some meaningful WG consensus.

> Looking at the
> homenet mailing list we can see that the number of reviews reflects
> the participation of the mailing list.

That's true. I think it may be time to recognise reality
and close the WG perhaps.

> Though I really value your
> review, I am not sure that (even with no hat) it encourages
> additional reviews, as it forces the potential reviewer to take
> position against the opinion of the chair. It seems to me that, if
> the number of reviews were an issue, this could have been addressed
> otherwise.

Sorry, that doesn't make sense. As chair I wouldn't ask
for it to be published without doing my own personal review.
And I refuse to guarantee all such reviews will be positive.

> comments have been addressed.

Personally, I don't agree. As chair, I think it's moot,
as we don't have sufficient review to declare consensus
either way. (To be clear - the DDNS point is also moot
in terms of whether or not the technical comments have
been handled - that was a non-nit editorial point.)

> Regarding the support, the proposal was initiated by an ISP. Today, I
> am interested in this proposal because we have some demand for it.
> That some folks prefer using DDNS for their own purpose is orthogonal
> to us. This is why we want it to be published.

Sure, and as I said I'm not opposed to that. I suspect the
best thing is for the authors to chat with our AD and see
if he's either willing to AD-sponsor it, or to ask another
WG to adopt, or try find a dispatch-like process to see if
enough interest/review can be found that way.

Cheers,
S.

> 
> Yours, Daniel
> 
> On Tue, Jun 8, 2021 at 6:06 AM Stephen Farrell
> <[email-masked]> wrote:
> 
>> 
>> Hiya,
>> 
>>> So in addition to achieving "rough consensus", the IETF
>>> standardization process must also produce drafts that are very
>>> likely to gain traction to displace non-IETF non-standardised
>>> products that are already widely commercially deployed?
>> 
>> No. This is not a process hurdle. It was one amongst a bunch of
>> personal comments I sent. And that I'm happy to discuss with the
>> authors without wearing any chair or other hat.
>> 
>> The process problem with these drafts is the lack of review means
>> there's no way to claim they represent any useful level of WG
>> consensus.
>> 
>> Cheers, S.
>> 
>> _______________________________________________ homenet mailing
>> list [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Jun 2021 12:54:03 -0400

> a robust server that is well integrated with Bind.

Yes, I did that.  It's in front of you.
As you said, there are three different specifications: why didn't you pick one?

We went back and forth multiple times as to REST vs AXFR from the HNA.
The feedback *FROM DNS OPERATORS* (which you aren't) was that they preferred AXFR.

    > on whether the update is carried over HTTPS or AXFR.

It sure does, because DDNS as described by you is done by the end-device,
which can't see the IPv4 renumber, which btw, is all those devices support.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 8 Jun 2021 17:31:20 -0400

Hi Stephen,

I am just replying to clarify I am not complaining about you personally or
even your review. If further discussions are needed I am happy to set a
call at any time as email does not seem to me the most constructive path.

Yours,
Daniel

> Sorry, I don't get what you mean.

Let me try to provide more background. I am reading or interpreting your
response to Ray (quoted below) that the discussion on whether the proposal
will take over DDNS is a simple discussion that does not have any
consequences. I disagree with that. It seems that raising such discussion
during a WGLC has consequences, perhaps because I do not see the technical
aspect of the discussion.

"""
It was one amongst a bunch of personal comments I sent. And that I'm happy
to discuss with the authors without wearing any chair or other hat.
"""

> part aren't convincing IMO, which is what my comment said.

The lack of support appeared to me in the WGLC quoted below which mentions
"not enough support". I interpreted this as partly resulting from
challenging the proposal but maybe I am mis-interpreting this, though I
understand it also included partly a number of reviews.

"""
Stephen and I do not believe these drafts have received enough review or
support to put them forward as representing WG consensus.
"""

If I interprete "neither support nor oppose" of your response as being
neutral, I do have hard time to read it from the WGLC report which describe
your position as follows:

"""
Stephen and Juliusz expressed that they're still not convinced that DDNS
isn't a good enough solution for the use case.
"""

That said, I am fine that there are different opinions and people have
different predictions, as long as we agree these remain personal opinions
that should not influence moving the document forward. This is not clear to
me this is the way it is interpreted.

> I am not accusing anyone. The discussion is toxic in my point of view
because at this point it is very hard to engage someone into reviewing the
doc, as it is asking him to take a position in favor of or against some
parties. I do not believe that this results from your review, but rather
how your review has been summarized and has influenced the chair's
decision. Reviews are always welcome.

> sufficient to declare some meaningful WG consensus.

The question concerned the number of reviews that would have been
considered sufficient. I do not understand how this can be interpreted as
chairs not making enough effort to get reviews. It was not my intent. That
said, I remember that people committed to review, and maybe a reminder
would have been welcome.

> and close the WG perhaps.
I do not think that was not predictable, nor something that we learned
during this WGLC. If we had some other specific expectations, those should
have been clearly provided. And it is still unclear to me how many reviews
were expected for example.

> And I refuse to guarantee all such reviews will be positive.
Let me rephrase myself, I realize my words are ambiguous and apologize for
it.
I really appreciate your review. I appreciate your sharing even non
technical opinions, even triggering a discussion. I am not asking that the
review needs to be positive either. However, I have the impression that non
technical opinions had too much influence on the outcome.

> Personally, I don't agree.

I am happy to respond to comments that have not been answered.

> As chair, I think it's moot,
The document has been adopted by a WG, we have done such a process. I do
not understand why this should be re-done.

-- 
Daniel Migault
Ericsson

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Jun 2021 20:38:38 -0400

sf> Sure, and as I said I'm not opposed to that. I suspect the
    sf> best thing is for the authors to chat with our AD and see
    sf> if he's either willing to AD-sponsor it, or to ask another
    sf> WG to adopt, or try find a dispatch-like process to see if
    sf> enough interest/review can be found that way.

It's the WG's document, and the WG can abandon it if it likes.
That would require some consensus seeking discussing.

If it turns out the WG isn't interested in the document, I sure wish that the
WG had said so a year ago though.

---

From: Chris Box <[email-masked]>
Date: Thu, 10 Jun 2021 18:21:01 +0100

Hi everyone

I have belatedly reviewed both drafts. I missed the WGLC due to both
$dayjob and the IETF having a plethora of interesting working groups. But
still, I hope this feedback is useful

In general, I appreciate the aim of the drafts which I will paraphrase as
creating a way to automatically and reliably publish a home zone containing
a number (n) of smart devices. This makes a lot of sense when we know n is
going to carry on growing, and of course renumbering can be frequent.

My specific feedback is below, organised by section number.

*draft-ietf-homenet-front-end-naming-delegation-15*
1 It would be useful if the introductory text in the Abstract also appeared
here in the Introduction.

1.1 Typos: "humuan" and "addressees "

3.1 I'd prefer the diagram to be located at the beginning of this section.

4.7 This section should also state, as it does in section 7, that the
Hidden Primary Server be firewalled such that only the known address range
of the DMs are permitted to connect to it.

7 I'd prefer not to use the word "packets" when it's really messages that
we considering. Also in my opinion invalid messages to/from the DM ought to
be rejected rather than simply dropped.

Here's my suggested version, with changes highlighted in red:
   The Hidden Primary SHOULD drop any packets arriving on
   the WAN interface that are not issued from the DM.  The Hidden
   Primary SHOULD NOT send DNS messages other than DNS NOTIFY query,
   SOA response, IXFR response or AXFR responses.  The Hidden Primary
   SHOULD reject any incoming messages other than DNS NOTIFY response, SOA
   query, IXFR query or AXFR query.  The Hidden Primary SHOULD reject any
   non protected IXFR or AXFR exchange, depending on how the
   synchronization is secured.

12 This acknowledges that it's a little risky to publish names of home
devices publicly, and notes that often it's only the home owner or
immediate family that ought to be able to query these names. It says that
limiting ability to query can be done by IP source (IMHO tricky), or VPN.
To which I think, if the home owner is using a VPN to the home to query the
public zone, why do we need external publication at all? Some words to
explain that better might be useful.

*draft-ietf-homenet-naming-architecture-dhc-options-14*

3 In both American and British English I think the word "collocate" should
be "colocate" (or alternatively "co-locate").

3 What exactly is meant by "(eventually by a self signed certificate)"?

4.2 I think the HNA also needs to learn the set of IP addresses that the DM
might legitimately use in order to contact the HNA, so that these IPs can
be whitelisted in the CPE's firewall. Simply looking up the FQDN doesn't
provide that. Should it be added to this DHCP option?

Hope that's useful.

Thanks,
Chris

On Fri, 4 Jun 2021 at 20:45, STARK, BARBARA H <[email-masked]> wrote:

> Hi homenet WG,
> Stephen and I have been chatting about the status of the 2 naming drafts
> (draft-ietf-homenet-front-end-naming-delegation and
> draft-ietf-homenet-naming-architecture-dhc-options).
>
> We started a 3-week WGLC about a month ago (04 May). Both drafts received
> comprehensive review from Med. Stephen reviewed
> front-end-naming-delegation. Bernie reviewed the formatting of the DHC
> option.
> The authors provided updates to resolve these comments. Bernie
> acknowledged satisfactory resolution of his comments.
> Requests to change terminology were satisfactorily resolved -- but that
> discussion doesn't count as really being part of anyone's review of the
> drafts.
> But the authors have spent significant effort in creating these drafts and
> the associated implementation. We will work with Éric V (as INT area AD)
> and the authors to determine next steps.
>
> Barbara and Stephen
>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 14 Jun 2021 21:57:53 -0400

Thank you very much Chris for the review. That was very useful.  I have
updated the two documents according to your reviews. The resulting
architecture document is available here [1] and the resulting DHCP document
is available here [2].

You can also find a more detailed response inline.

Thanks again for the review!

Yours,
Daniel

[1]
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f1cb4c679b8b8f96bdeddcf056cdbe4e80f91c25

[2]
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/f4608d0ee2718c7d3747c848b5cbba028653c2e0

On Thu, Jun 10, 2021 at 1:21 PM Chris Box <[email-masked]> wrote:

> 1 It would be useful if the introductory text in the Abstract also
> appeared here in the Introduction.
>
>

we added the text at the beginning of the introduction

> 1.1 Typos: "humuan" and "addressees "

corrected. Thanks.

> 3.1 I'd prefer the diagram to be located at the beginning of this section.

The figure has been moved at the beginning of the section.

> of the DMs are permitted to connect to it.

Good catch.  Looking at the two sections, it looks these are a little bit
redundant, so rather than repeating the rules I prefered to suggest
firewalling as detailed in section 7.

This basically results by the text below:
"""
Limited exchanges:
: the purpose of the Hidden Primary Server is to synchronize with the DM,
not to serve any zones to end users, or the public Internet.
This results in a limited exchanges (AXFR/IXFR) with a small number of IP
address and such limitations SHOULD be enforced by policies describe din
 {{sec-cpe-sec-policies}}.
"""

>    synchronization is secured.
My interpretation between drop and reject is that drop does not provide any
response and acts as if the service does not exist while reject allows
responding with an error which in this case indicates the service exists
and has blocked the traffic.

The way we envisioned these policies is enforced by a firewall (as opposed
to the HNA itself) so the intention is to protect the HNA - including
hiding the HNA, in which case dropping seems the most obvious way to
implement these policies.
Now, since the traffic is protected by TLS, the rules associated with the
HNA are more application specific rules, and we can envision that with a
trusted peer, rejection might be more appropriate.

To address your comment I propose to differentiate the DNS rules from what
can be implemented by a firewall and take a large part of the text you
proposed resulting in the following text:

"""
The HNA SHOULD drop any packets arriving on the WAN interface that are not
issued from the DM.

Depending how the communications between the HNA and the DM are secured,
only packets associated to that protocol SHOULD be allowed.

At the DNS level, the HNA SHOULD NOT send DNS messages other than DNS
NOTIFY query, SOA response, IXFR response or AXFR responses.

The HNA SHOULD reject any incoming messages other than DNS NOTIFY response,
SOA query, IXFR query or AXFR query.
"""

> explain that better might be useful.
I have added some text to provide some explanations. It is correct that if
all your traffic is redirected in the home network, then there is little
interest in publishing all the names as they will only be accessed
internally. The text was trying to mention that a node may be willing to
set different policies for its traffic. Typically the web traffic is not
tunneled while the traffic to the homenet is tunneled. In this case, the
ability to define which IP address needs to be tunneled and which IP
address does not need to be tunneled requires to have this IP address so to
be able to publicly perform a DNS resolution.   The added text is as
follows:

"""
In such cases, the routing policy is likely to be defined by the
destination IP address.
This IP address potentially results from a DNS resolution over the Internet.
"""
I also added some references to lower the confidence in the security
provided by NSEC3 as well as a reference to draft-ietf-dnsop-nsec3-guidance
to configure appropriately NSEC3.

> fixed.

> I added a reference to the section it is discussed in the architecture
document. The idea is that in some cases such as the reverse zone, TLS is
not necessarily required as the ISP identifies the line. On the other hand,
we wanted to avoid to have different versions of the HNA - let's say a
secure version that uses TLS and a unsecure version that did not use TLS.
As a result, when authentication is not mandatory we prefer the use of a
self signed certificate.

> 4.2 I think the HNA also needs to learn the set of IP addresses that the
> DM might legitimately use in order to contact the HNA, so that these IPs
> can be whitelisted in the CPE's firewall. Simply looking up the FQDN
> doesn't provide that. Should it be added to this DHCP option?
>

This is correct, so the idea is that we could provision a list of IPv4 and
a list of IPv6. However, it seems simpler to only consider the DM FQDN and
let the HNA retrieve the IP addresses from a DNS(SEC) resolution. This is
correct that this provides an additional round trip and a resolution
service to be working. This could be difficult in the case of setting a
resolving service, but in our case, we do not have such issues.

>> But the authors have spent significant effort in creating these drafts
>> and the associated implementation. We will work with Éric V (as INT area
>> AD) and the authors to determine next steps.
>>
>> Barbara and Stephen
>>

-- 
Daniel Migault
Ericsson

---

From: Chris Box <[email-masked]>
Date: Tue, 15 Jun 2021 18:10:40 +0100

Hi Daniel.  Responses inline below.

>  {{sec-cpe-sec-policies}}.

I'm happy with that.

> My interpretation between drop and reject is that drop does not provide
> any response and acts as if the service does not exist while reject allows

I have the same interpretation.

> trusted peer, rejection might be more appropriate.

Agree, rejection is better when the trusted peer sends an invalid message.

> The HNA SHOULD drop any packets arriving on the WAN interface that are
> not issued from the DM.
>
> The HNA SHOULD reject any incoming messages other than DNS NOTIFY
> response, SOA query, IXFR query or AXFR query.
> """
>

The separation looks good, but I'd like to tweak the second paragraph. By
"only packets associated to that protocol" do you mean destination port
filtering?

> This IP address potentially results from a DNS resolution over the

So let's consider this use case where access to homenet devices is required
to be via VPN to the home. In theory, only one address needs to be
published externally. This is the current WAN IP of the home's VPN
termination point. Then the steps to access a particular smart device would
be:
1. Look up address of the home's VPN server.
2. Establish VPN.
3. From the VPN, the client learns the set of home-specific routes, and the
address of the Homenet Resolver that it should use.
4. Client queries the Homenet Resolver (over the VPN) for the address of
the smart device.
5. Client establishes connection to the smart device, over the VPN.

For this use case, there is no need to publish more than one name to the
DOI. Do you agree?

However I think the aim of this draft is to enable more than just that
case, so I can see that non-VPN cases are also useful.

> As a result, when authentication is not mandatory we prefer the use of a

The reference helps, thank you. But section 4.6 does not say that
self-signed is the target. It's given as one option, and that's probably
the right language. Hence I think the sentence here should be simplified to:

3. The HNA is authenticated (see Section 4.6 of
{{!I-D.ietf-homenet-front-end-naming-delegation}}) by the DM and the
RDM.

> resolving service, but in our case, we do not have such issues.

I'm not concerned about the additional round trip. I was more concerned
that the DM could be implemented as a frontend/backend architecture. The
FQDN would resolve to the front end, and this is likely to be a small list
of addresses, or even a single address. But the backend servers would have
distinct, different addresses. Connections from the DM to the HNA might be
initiated from the backend. If the HNA only looked up the FQDN, it would
drop legitimate connections. This suggests we need a way to inform the HNA
of the set of legitimate source addresses.

Chris

---

From: Daniel Migault <[email-masked]>
Date: Tue, 15 Jun 2021 20:27:25 -0400

Hi Chris,

Thanks for the follow-up. Please find more details and specific responses
to your questions and comments below. I also just pushed the changes you
recommended for the DHCP options.

Thanks!

Yours,
Daniel

On Tue, Jun 15, 2021 at 1:10 PM Chris Box <[email-masked]> wrote:

>> The way we envisioned these policies is enforced by a firewall (as
>> opposed to the HNA itself) so the intention is to protect the HNA -
>> including hiding the HNA, in which case dropping seems the most obvious way
>> to implement these policies.
>> To address your comment I propose to differentiate the DNS rules from
>> what can be implemented by a firewall and take a large part of the text you

To me IP and port filtering are implemented by the previous line. "only
packets associated with that protocol" to me means that only TLS packets
are allowed.   The reason we are not mentioning TLS explicitly is that
other protocols may be used.

>> I have added some text to provide some explanations. It is correct that
>> if all your traffic is redirected in the home network, then there is little
> So let's consider this use case where access to homenet devices is
> required to be via VPN to the home. In theory, only one address needs to be
> 3. From the VPN, the client learns the set of home-specific routes, and
> the address of the Homenet Resolver that it should use.

Yes, I agree. In that case, the proposal might also be a bit overkill. The
homenet zone does not need to be published (at all) and rather than
introducing a split dns for a single domain, maybe the most appropriate way
to handle this would be to have a  specific domain for the gateway (
different from the one used for homenet). It is likely that synchronizing
zones for a single domain may compete at that time with DDNS.

Just to clarify, the use case I was trying to expose is where the VPN only
carries traffic to the homenet.

> 3. The HNA is authenticated (see Section 4.6 of {{!I-D.ietf-homenet-front-end-naming-delegation}}) by the DM and the RDM.
>
> works for me. I changed it as you mentioned.

>> This is correct, so the idea is that we could provision a list of IPv4
>> and a list of IPv6. However, it seems simpler to only consider the DM FQDN
>> and let the HNA retrieve the IP addresses from a DNS(SEC) resolution. This
>> is correct that this provides an additional round trip and a resolution

-- 
Daniel Migault
Ericsson

---

From: Chris Box <[email-masked]>
Date: Tue, 22 Jun 2021 17:31:46 +0100

Daniel,

On Wed, 16 Jun 2021 at 01:27, Daniel Migault <[email-masked]> wrote:

>>> Depending how the communications between the HNA and the DM are
>>> secured, only packets associated to that protocol SHOULD be allowed.
>>>
>>>

Ah, I see, so this is about the payload of the packets. But surely
intelligent validation of the incoming packets is always going to happen?
This is a key property of any security protocol.
If the DM is listening on TCP 443, and the incoming packet is not a TLS
Client Hello that it is happy with, it'll get ignored.
If the DM is listening on UDP 500, and the incoming packet is not an
IKE_SA_INIT that it is happy with, it'll get ignored.

So I'm not disagreeing with you, I'm just questioning whether the sentence
is needed. I don't really mind if it stays.

>> of the set of legitimate source addresses.
What did you think of this last point?

Chris