Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-25: (with DISCUSS and COMMENT)

[Daniel Migault <[e-mail]>]

Hi Paul,

Thanks for the response. Please find my responses in line. You can find the
changes there:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/63/commits/0d45a331b5cd2595454578b13a2973f68ec9f0b6

Yours,
Daniel

On Mon, Jan 9, 2023 at 9:57 PM Paul Wouters <[e-mail]> wrote:

>
> On Mon, Jan 9, 2023 at 2:52 PM Daniel Migault <[e-mail]> wrote:
>
>> Hi Paul,
>>
>> Thanks for the review. We updated the document as follows.
>>
>> https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/63/commits/f221d3413f71bf95f8961f8fe3c71e53f8f3dd20
>>
>
> Thanks for the update.
>
>
>> The only comment that has not been addressed is the one concerning the
>> MUD. You can find inline my comments.
>>
>
> I'm not sure that's the only remaining issue left, see below.
>
>
>
>>> #1 Document Status
>>>
>>> As other ADs have pointed out, Standards Track would not be the right
>>> intended status. Experimental would be a much better fit. I understand
>>> this is done because otherwise 3gpp won't consider the document, but
>>> whether the IETF should make its decisions based on that is something
>>> I'd like to discuss with the other members of the IESG.
>>
>>
> Note that this discussion happened, and the IESG decided that while the
> situation
> was a bit of an anomaly, to not block the document on this or insist to
> change the
> status to Experimental.
>
>
>>
>>
>> #2 Security Considerations for DM/DOI missing
>>>
>>> There is no Security Considerations paragraph for the DM/DOI ?
>>>
>>> For example, if I want to use "ietf.org" for my Public Homenet
>>> Zone, that should probably not be allowed to be served by the
>>> ISPs DM/DOI infrastructure. Similarly, currently non-existing
>>> domains like "mailietf.org" or TLDs should probably not be
>>> allowed. When allowing subdomains of existing registrations,
>>> perhaps it can recommend the DM/DOI does a verification check,
>>> eg via draft-ietf-dnsop-domain-verification-techniques
>>>
>>> To my view, the protocol assumes the registered domain is legitimate,
>> and this mostly because the HNA is authenticated. We do have a section that
>> details ownership of the domain name is necessary. I think the draft you
>> mention is a good fit in that section.
>>
>
> Sure, it is a bit light there though.
>
>
>> I am not against mentioning this in the security consideration, but one
>> thing that remains unclear to me is if I am asking the DOI to server
>> ietf.org, as the NS in the parent will not be updated, the zone will
>> only be known to me.
>>
>
> It is related to the same comments I gave to the catalog zone document,
> spoofing via additional data sections.
>
> Say you use GoDaddy and push ietf.org as your Public Homenet Zone.
> Indeed, no one will ask these godaddy servers normally. But now you
> register another domain,
> for example whateverisfree.org and give it an NS and A record of ietf.org.
> Now a resolver resolvng whateverisfree.org goes to the godaddy nameserver
> and it detects it can
> add the A record for ietf.org to the response of the NS record for
> whateverisfree.org. Now you might have poisoined a (non-DNSSEC) recursive
> nameserver.
>
> A note in the security section on this would be good. No need to explain
> this attack, just that there should be either a trust relationship, a new
> domain natively hosted already by the DNS hoster, or some kind of domain
> owner verification technique in use to prevent attacks against other
> domains.
>
>
>>   Furthermore, I expect the DOI will realize very quickly the domain
>> name is not legitimate.   Then I am wondering if that is an issue.
>>
>
> How would the DOI realize that? I can decide ietf.org is really my
> internally used domain ?
>
>
>> we have updated the text as follows:
>> ## Registered Homenet Domain
>>
>> The DOI MUST NOT serve any Public Homenet Zone that it has not strong
>> confidence the HNA owns the Registered Homenet Domain.
>> Proof of ownership is outside the document and is assumed such phase has
>> preceded the outsourcing of the zone.
>>
>
> That is good enough for me. Thanks.
>
>
>>
>> #3 Conveying the name of the zone to use
>>>
>>>         The HNA builds the Public Homenet Zone based on a template that
>>> is
>>>         returned by the DM to the HNA.  Section 6.5 explains how this
>>>         leverages the AXFR mechanism.
>>>
>>> If it uses AXFR, I guess the name itself cannot be part of the template
>>> and
>>> has to be handled differently. Unless it would use DNS catalog zones, eg
>>> draft-ietf-dnsop-dns-catalog-zones.
>>>
>>
>> In our case, the template contains the registered homenet zone, so I
>> agree with you that this is not a generic template, but a template being
>> used by the HNA.
>>
>>>
>>> Information on how to convey the name to be used as Public Homenet Zone
>>> should be added to Section 6.1.
>>>
>> I think this is stated in the following text:
>>
>> """
>> The NAME of the SOA RR MUST be the Registered Homenet Domain.
>> """
>>
>
> But how does it query for the AXFR if it does not know the zone name yet ?
> AXFR requires the zone name as argument,
> So the SOA RR has not yet been received when the name needs to be known.
> So this has to be conveyed somehow, and
> I don't understand how this currently happens.
>
>
In this document, the HNA knows the homenet registered domain, (as this is
the zone it is willing to outsource) as well as the DOI. As a result it is
able to send an AXFR query with the appropriate name. The response from the
DM will contain the name as well - that was the sense of my previous
response. The current document largely considers Homenet Registered Domain
to be a configuration parameter. The configuration parameters can be
manually entered, or as an initial setting ( see the use cases where the
CPE vendor also provides the domain name). There are also ways to discover
such parameters and the DHCP draft details how DHCP can be used to
provision these parameters. HNCP is probably also another way these
parameters can be provided to the selected HNA.

>
>>
>>>
>>> #4 HNA IP address
>>>
>>>         As a result, the HNA must provide the IP address the DM should
>>> use to
>>>         reach the HNA.
>>>
>>> Note there is an odd lowercase "must" here, which becomes stranger when
>>> later
>>> on it states:
>>>
>>>         By default, the IP address used by the HNA in the Control Channel
>>>         is considered by the DM and the explicit specification of the
>>>         IP by the HNA is only OPTIONAL.
>>>
>>> So it seems the HNA doesn't need to "must provide", as its IP as visible
>>> by the
>>> DM/DOI is used anyway and providing it (explicitly) is deemed OPTIONAL ?
>>>
>>> I see your point. "must" here indicate that the DM needs to know the IP.
>> OPTIONAL indicates the HNA may send it via a DNS exchange but the IP can
>> also be taken from the control channel.
>>
>> We replace with the text below:
>> """
>> As a result, the HNA needs to provide the IP address the DM should use to
>> reach the HNA.
>>
>
> But why does it "need to provide that", if the DM sees the HNA's IP
> address on the incoming
> connection anyway and may use that as said later in the document ?
>
> I was using "need to provide" to say they want to establish a primary
secondary relation, so in one way or another the secondary needs to know
the address of the primary. This was a generic/abstract comment. The
document describes two ways to provide that value.: In the IP header and in
the DNS packet. The reason to have two ways is to enable the primary to use
different IP addresses for the control and synchronization channel.

>
>
>> If the HNA detects that it has been renumbered, then it MUST use the
>> Control Channel to update the DOI with the new IPv6 address it has been
>> assigned.
>> The Synchronization Channel will be set between the new IPv6 (and IPv4)
>> address and the IP address of the DM.
>> By default, the IP address used by the HNA in the Control Channel is
>> considered by the DM and the explicit specification  of the IP by the HNA
>> is only OPTIONAL.
>>
>
> So I dont understand this. What if the HNA uses 1.2.3.4 to connect to the
> DM and tells the DM its IP is 8.8.8.8 ?
> (or similar example with ipv6)
>
> I think in the worst case, that is when SOA requests are not mutually
authenticated. The DM may send a SOA request to 8.8.8.8, as the zone does
not exist, the synchronization will be stopped. If the zone exists, it will
not be able to establish the TLS session. As the HNA is authenticated, if
that was used for an attack, the attacker is easily identified and the DOI
can easily ban it.
That said, the issue you are raising is how this can be used as an
indirection attack. This Is unlikely because of the mutual TLS
authentication or both channels (control and  synchronization channels).
These channels, when authenticated, need to have the same HNA identity.

>
> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> The description of what a Public Homenet Zone is a bit better, but I
>>> think
>>> it would be good to add a sentence somewhere saying it more concise,
>>> eg "The device assigned zone or user configurable zone to use as the
>>> domain to publicly serve hostnames in the home network is called the
>>> "Public
>>> Homenet Zone". In this document, "myhome.example" is used as the example
>>> for an enduser owned domain configured as Public Homenet Zone.
>>>
>>> We added the lines.
>>
>
> Thanks.
>
>
>
>> After reading a few "Public Homenet Zone" names, I also didn't understand
>>> a sentence where it said "Homenet Zone" because it is so similar and
>>> I didn't realize for a bit that "Public" was missing. I'd recommend
>>> renaming "Homenet Zone" to "Private Homenet Zone" to make this more
>>> obvious (to both implementers and endusers)
>>>
>>> We had this terminology at some point and removed it as it was confusing
>> since the Private Homenet Zone has some communalities with the Public
>> Homenet Zone.  At that point, I would prefer not to change the terminology.
>>
>
> Okay.
>
>
>>
>>         This is a zone transfer over TLS
>>>
>>> It would be clearer to call this to be over mutual TLS to distinguish it
>>> from DoH or Dot where the client does not authenticate itself at all.
>>> (other places did properly add a note about mutual auth)
>>>
>>>  Changed to: This is a zone transfer over mutually authenticated TLS.
>>
>>         Revealing the address of the HNA in the DNS is not desirable.
>>>
>>> Is there an issue if this is revealed? How hard is it to find the HNA
>>> if you know any other IP from the Public Homenet Zone ? Should there
>>> be a Ssecurity Consideration for embedded DHCP/RA servers on how to
>>> assign IPv6 addresses to hide the HNA better from the user content?
>>>
>>> The IP address of your HNA in our use-case can be any IP address from
>> your prefix.  But in any case it defies the purpose of outsourcing, so
>> unless one knows exactly what it does, we do not expect the HNA to appear
>> in the zone.
>>
>
> well, is it getting a randomized IP from the IPv6 prefix? I don't see a
> recommendation for that in the Security
> Considerations or Operational Considerations sections. If not, then it is
> likely that xxx::1 is the router, and xxx::2
> is the HNA, even if this is not put in the DNS it would be easy to find.
>

You are correct. I will add some recommendations. But I also think that
what you raised is that knowing the IP address is not so crucial as long as
the HNA does not respond to these queries.
I replace the sentence by:
Unless the HNA is able to support the traffic load, the HNA SHOULD NOT
appear as a visible NS
records of the Public Homenet Zone.

I also added the following sentence when we discuss the IP address of the
HNA in section " Providing information for the Synchronization Channel"

It is RECOMMENDED the IP address of the HNA is randomly chosen to prevent
it from being easily
discovered as well.

>
>         (if the NS are in-bailiwick [RFC8499]).
>>>
>>> The term "in-bailiwick" is being sunset for "in-domain", see
>>> https://www.mail-archive.com/[e-mail]/msg26229.html (this term
>>> appears
>>> more than once in the document)
>>>
>>> changed
>>
>
> Thanks.
>
>
>>         (a high range port)
>>>
>>> It is an ephemeral port. Those happen to be high in the valid range, but
>>> I would
>>> not call it "high port" as that is poorly defined (32768+ ? 55000+ ? etc)
>>>
>>>  changed to make sure this is understood. (an ephemeral also commonly
>> designated as high range port)
>>
>>>          (another high range port)
>>>
>>>  changed to another ephemeral port
>>
>
> Can live it that :)
>
> Same here. I would also change XXXX and YYYY to XXXXX and YYYYY as these
>>> would
>>> very likely be higher than 32768 and so would be 5 digits, not 4.
>>>
>>> YYYY and ZZZZ have been changed.
>>
>
> Ok.
>
>
>>         and so DNS notifies are sent over the Control Channel, secured by
>>> TLS.
>>>
>>> mutually authenticated TLS.
>>>
>>> changed
>>
>>>         As this AXFR runs over a TCP channel secured by TLS
>>>
>>> mutually authenticated TLS.
>>>
>>> changed
>>
>
> Thanks.
>
>
>>         [RFC9103] makes no requirements or recommendations on any extended
>>>         key usage flags for zone transfers, and this document adopts the
>>> view
>>>         that none should be required, but that if there are any set, they
>>>         should be tolerated and ignored.  A revision to this
>>> specification
>>>         could change this, and if there is a revision to [RFC9103] to
>>> clarify
>>>
>>> This is a weird way of saying, "EKU usage SHOULD follow the requirements
>>> of
>>> [RFC9103]" and leave it up to 9103 to get updated for this document's
>>> normative
>>> reference to be considered updated as well. (this appears twice in the
>>> document)
>>>
>>> changed
>>
>
> Thanks.
>
>
>>         The use of a TLS session tickets [RFC8446], Section 4.6.1 is
>>>         RECOMMENDED.
>>>
>>> According to 2119, RECOMMENDED means SHOULD. I think that a SHOULD for
>>> using TLS
>>> session tickets is a bit strong. I could see that a setup like this
>>> might not
>>> need to communicate more than once every few days, in which case it is
>>> likely
>>> that the TLS session ticket has expired anyway. I think MAY would be more
>>> appropriate here.
>>>
>> I am expecting more frequent SOA requests.
>>
>
> I don't know what the default timeouts are for TLS session cookies. I
> still think a MAY is better than a
> SHOULD, as this is still only talking about one TLS connection per
> whatever time unit (1h? 5m ?) which
> should not really be an issue for a homenet server or the DOI / DM
> infrastructure. It's not like it has thousands
> of requests per second like a TLS webserver, It's an optimalization, but
> not a crucial one. I'll leave the final
> say to you but I still strongly recommend a MAY over a SHOULD.
>
I need to look at this I have in mind for a week.

>
>
>>>         The DM SHOULD ignore the Pre-requisite and Additional Data
>>> sections, if
>>>         present.
>>>
>>> Why is this not a MUST ?
>>>
>> These fields are potentially left for future use.
>>
>
> As the AXFR/IXFR sends those records anyway, as you are not modifying that
> protocol, I don't think that is
> needed to allow for future use. It can be a MUST ignore now, and if a
> later spec is written, it can change those
> parts to "MUST read from the additional section".
>
>
>>
>>
>>>
>>>         This document exposes a mechanism that prevents the HNA from
>>> being
>>>         exposed to queries from the Internet.
>>>
>>> It does not "expose a mechanism" for that. It did offer some policy
>>> decisions on
>>> how to limit queries and drop certain ones. Which is re-iterated in the
>>> sentences immediately following this. I would remove this sentence.
>>>
>>> deleted
>>
>
> Thanks.
>
>
>>         The DNSSEC keys are needed on an hourly to weekly basis, but not
>>> more
>>>         often.
>>>
>>> This isn't entirely true, when devices' their IP addresses are being
>>> added,
>>> removed of modified. Perhaps add some weasel wording like "are generally
>>> needed
>>> on an ...."
>>>
>>> changed
>>
>
> Thanks.
>
>
>
>>
>>
>>> I find the term "home network operator" a bit misleading. We are really
>>> talking
>>> about endusers here, not qualified or licensed "operators". Some of the
>>> Security Considerations given to these "home network operators" seems
>>> rather
>>> technical. Instead, I feel the protocol really needs to protect the
>>> enduser
>>> from making mistakes. Perhaps the Security Considerations for them need
>>> to be
>>> tweaked to apply to the protocol and its implementers.
>>>
>>> I do agree. Home networks may also be quite large, and yes the
>> considerations are more for the developers of the protocol which are
>> expected to tweak it to their targeted end users.
>>
>
> Fair enough.
>
>
>>         Carriers may need to deploy additional mitigations to ensure that
>>>         attacks do not originate from their networks.  The use of
>>> RFC8520 (MUD)
>>>         filters is one such method.
>>>
>>> I didn't think MUD was deployed by Carriers for in-home devices? Do you
>>> mean to
>>> say that Carriers could recommend CPE equipment and in-home devices that
>>> support the use of RFC8520 (MUD) filters ? Or do you envision MUD capable
>>> devices in the HomeNet actually get their MUD profiles enforced by the
>>> Carrier/ISP ?
>>>
>>
> So this is still an open item.
>
>
>>
>>> NITS:
>>>
>>
> [...]
>
> Thanks.
>
> Paul
>
>

-- 
Daniel Migault
Ericsson