Re: [Add] Fwd: New Version Notification for draft-btw-add-home-09.txt

[Michael Richardson <[e-mail]>]

Tiru and authors, I read through draft-btw-add-home-09.

First, I found the CLOUD-ish icon for the "LAN" confusing.
It looks like it is the "H" is inside the CPE.

                      ,--,--,--.
                   ,-'   +--+  `-.
                  ( LAN  |H |    CPE-
                   `-.   +--+   ,-'
                      `--'|-'--'


My eyes see a BOX, with an ISP facing interface labelled "CPE"
and a LAN facing interface labelled "LAN", and then I am
confused by the H inside, and thought it was the CPE acting
as a Host.  Only after a few figures did I understand that
this was a LAN "cloud"

I suggest:

    +-+
    |H|
    +-+         .-------.
     |  LAN     | CPE   +--- .. ISP-cloud
     +----------+       |
                '-------'

There is a tool written in perl called "asciio" which is fabulous for making
these kinds of ascii-art diagrams.  Highly recommended, but alas, it has no
cmd-line options, so integrating it into Makefile is a PITA.

section 3.1:

As I-D.ietf-v6ops-rfc7084-bis has not been worked on in awhile,
can you say what section deals with IPv4 service continuity, maybe
it is worth quoting the relevant text.

I would rather have four section (3.1.1/3.1.2/3.1.3/3.1.4) rather than just
four figures.

3.2: Unmanaged CPEs.

Well, I they are unmanaged by the ISP.
In may small offices, they are managed by a third service.
While some home owners neglect the devices, I wouldn't call them unmanaged.
They are home-owner managed.

As for:
   (assuming the CPE is
   compliant with the network access technical specification that is
   usually published by ISPs)

There is an EU guidelines that suggests that be required.  Some countries
have this as a regulation. Perhaps one of our european correspondants could
provide a useful reference.
They key point is, I think, that the device has no (private) trust anchors
pointing at the ISP, so the device can not validate ISP provided DoH/DoT/DoQ if the
ISP isn't using a public anchor.
There is no TR69 by which to configure the ADN.

the point starting at: Customers may also decide to deploy internal home
                       routers

is really a third kind of "CPE", which could appear in both managed and
unmanaged situations, and it's really this third situation that really
motivates getting this DHCP/RA option right.

section 4.1. DHCPv6 DNS Option.
I suggest you call it "Enc DNS Flags" rather than "Type", since it is split
up in bits.  I suggest you leave the comment about Unassigned Bits to the
IANA Considerations section.
I don't think that there is any reason to leave three bytes unassigned.
I don't think the ADN needs to be 32-bit aligned, since it is interpreted
as a sequence of bytes.

It seems to me that if we have the ADN, then the encrypted DNS service can
be reached at any IP address, including RFC1918, IPv6-LL, ULA, as long as
the service's certificate can be validated using the ADN.

For instance, a CPE device could advertise an IPv6-LL address for DNS, and
then form Circuit Proxy (aka Forward Proxy) to the ISP's service, without
necessarily requiring routing/forwarding to be active.  Any device on the LAN
could provide such service, actually.
It is worth remembering that openwrt's swiss-army-knife DNS/DHCP server
"dnsmasq" started life doing exactly that.

I suggest section 4.2, "DHCPv4 Encrypted DNS Option"

Can the OPTION_V4_ENC_DNS, Encrypted DNS Address Option, OPTION_V6_ENC_ADD
be ommitted (sending just the ADN), in which case the existing DNS address
options are assumed to work for Encrypted DNS at the "normal" port numbers?

Section 5:

"DoH clients re-iterates"   -> _re-iterates_ reads wrong.  "repeats" is
probably what you want.

section 7.1.1
please split the second paragraph into a new section.
Clearly, if the CPE is relaying the encrypted DNS server info, then it
doesn't need a ACME certificate.  That's exactly the case where the CPE is
not hosting encrypted DNS.  Maybe that's section 7.0

section 7.1.2:
        mention of sub-domains... and
        *left-most* label of the pre-configured ADN

I think the entire label has to match the certificate.
I think that it's that the ADN is a sub-domain of the pre-configured domain.
("blessed" might be the better term, channelling Perl more than D&D/Rogue),

Hate the diagram.  Here the DoH/DoT client is not inside the LAN cloud :-)

I think that section 7.2 should be split up into three sections:
1) the CPE will pass the ISP information on.
2) the CPE will provide reference to third-party service.
3) the CPE will be provide encrypted DNS itself thanks to the "security
   service provider" (possible, a person)

section 9.1 is great, and reflects the consensus about DHCP trust from the
virtual interim meeting.  I would reword:

   Because DHCP/RA messages are not encrypted or protected against
   modification within the LAN, their content can be spoofed or modified
   by active attackers (e.g., compromised devices within the home
   network).

to:

   DHCP/RA messages are not encrypted or protected against
   modification within the LAN.  Unless mitigated (described below),
   the content of DHCP and RA messages can be spoofed or modified by active
   attackers, such as compromised devices within the home network.

rework:
   Encrypted DNS sessions with rogue servers spoofing the IP address of
   a DNS server will fail because the DNS client will fail to
   authenticate that rogue server based upon PKIX authentication
   [RFC6125], particularly the authentication domain name in the
   Encrypted DNS Option.

too many embedded noun-phrases for non-native speakers :-)

9.4:
   This results in the
   key being shared to attackers resulting in security breach.
   Man-in-the-middle attacks are possible within home networks because WLAN
   authentication lacks peer entity authentication.

-> The shared key is available to all nodes, including attackers, so
   it is possible to mount an active on-path attack.

section 10, IANA lacks a repeat of the consideration for the Unassigned bits.

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