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

[[e-mail]]

Hi Michael,

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Add [mailto:[e-mail]] De la part de Michael
> Richardson
> Envoyé : samedi 26 septembre 2020 23:20
> À : tirumal reddy <[e-mail]>; [e-mail]
> Cc : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> Objet : Re: [Add] Fwd: New Version Notification for draft-btw-add-
> home-09.txt
> 
> 
> 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"

[Med] You got it :-)

The intent was to distinguish the case where a host connected ** from within** a LAN and the case where the host is directly connected (mobile networks, for example). 

> 
> I suggest:
> 
>     +-+
>     |H|
>     +-+         .-------.
>      |  LAN     | CPE   +--- .. ISP-cloud
>      +----------+       |
>                 '-------'
> 

[Med] Will see how to make things clearer. Thanks.

> 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.

[Med] Can add a pointer to 

" 5.4.1.  IPv4 Service Continuity in Customer LANs  . . . . . .  16 "

> 
> 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.

[Med]  Will add a sentence to state this.  

> 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.

[Med] If the CPE is compliant with the spec published by an ISP, it can get the ADN using any discovery means in place by the ISP. 

> 
> the point starting at: Customers may also decide to deploy internal
> home
>                        routers
> 
> is really a third kind of "CPE"

[Med] ... but still an unmanaged one.


, 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.

[Med] "Flags" is too generic an does not reflect that this field is about indicating the encrypted DNS type(s).

  I suggest you leave the comment about
> Unassigned Bits to the IANA Considerations section.

[Med] This depends whether we want to create a registry to track the bits.

> I don't think that there is any reason to leave three bytes
> unassigned.

[Med] Why?  

> I don't think the ADN needs to be 32-bit aligned, since it is
> interpreted as a sequence of bytes.

[Med] Agree. 

> 
> 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.

[Med] Yes. As you can see we don't have any restriction for the IP addresses to be supplied. We do have this text: 

"For example, a home
   router embedding a forwarder has to include one single IP address
   pointing to one of its LAN-facing interfaces."

We can add a statement similar to the one we have for RAs, though. 

> 
> 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"

[Med] If we use "DHCPv4" then we need to introduce a new term in the terminology section to basically say that: "DHCPv4 refers to DHCPv4 [RFC2131]" 

> 
> 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?

[Med] The current text does not assume this. If only an ADD is supplied, that name will be passed to a resolution library to retrieve the IP address(es). This is done to avoid probing.

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

[Med] Fixed. Thanks. 

> 
> 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

[Med] Good point. 

> 
> 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.

[Med] The certificate will include the CPE's sub-domain while the auto-upgrade is basd on the domain itself.

> 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 :-)

[Med] :-) 

> 
> 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)

[Med] Thanks for the suggestion. Will consider re-organizing the section. 

> 
> 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.
> 

[Med] I like this. Deal!

> 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 :-)

[Med] ACK.

> 
> 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.
> 

[Med] That's better. 

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

[Med] Will be added if the WG want to maintain an IANA registry to track the bits. 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.