Re: [Add] WGLC for draft-ietf-add-dnr

[Chris Box <[e-mail]>]

Hi everyone.

I've assessed DNR against relevant parts of draft-ietf-add-requirements.
Here's the first.

    +=============+===================================================+
    | Requirement | Description                                       |
    +=============+===================================================+
    | R1.1        | Discovery SHOULD provide a local network the      |
    |             | ability to announce to clients a set of, or       |
    |             | absence of, designated resolvers.                 |

It's not clear to me how you use DNR to advertise the *absence *of
local encrypted DNS. Are we saying the router should send a frame with
zero option length (if that is considered a multiple of 16), and zero
ADN length? If yes, we should write that. If that's a bad design, we
should think about what is better.

    +-------------+---------------------------------------------------+
    | R1.3        | Discovery SHOULD support all encrypted DNS        |
    |             | protocols standardised by the IETF.               |

The requirement is approximately met, by virtue of building on SVCB.
However I think the draft should normatively depend on
draft-ietf-add-svcb-dns rather than the generic
draft-ietf-dnsop-svcb-https.

There's a point to clarify. It is not stated whether it is useful or
valid for the SVCB Service Priority to be zero (i.e. AliasMode). I
suspect not since it would mean the mandatory SvcParams could not be
populated, and may require the client to perform an additional
bootstrapping query, potentially over Do53.

    | R2.1        | Networks SHOULD be able to announce one or more   |
    |             | designated encrypted DNS resolvers using existing |
    |             | mechanisms such as DHCPv4, DHCPv6, IPv6 Router    |
    |             | Advertisement, and the Point-to-Point Protocol.   |

Met for the first three mechanisms, but PPP is missing. I'll come back
to that in a minute.

    +-------------+---------------------------------------------------+
    | R2.2        | The format for resolver designation SHOULD be     |
    |             | specified such that provisioning mechanisms       |
    |             | defined outside of the IETF can advertise         |
    |             | encrypted DNS resolvers.                          |
    +-------------+---------------------------------------------------+
    | R2.3        | This format SHOULD convey, at minimum, the        |
    |             | information the client needs to make contact with |
    |             | each designated resolver.                         |
    +-------------+---------------------------------------------------+
    | R2.4        | This format MAY convey additional resolver        |
    |             | information.                                      |

Not met, and it seems to be an easy thing to add. Doing so could make
it easier and more consistent for use over, for example, 3GPP mobile
networks.

What should it look like? If we follow the example of the provided
DHCP formats, it would require two blob formats, one each for IPv4 and
IPv6.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Service Priority        |         Addr Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      ipv6-address(es)                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          ADN Length           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
~                  authentication-domain-name                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 Service Parameters (SvcParams)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Service Priority        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Length  |               |
+-+-+-+-+-+-+-+-+               +
~        IPv4 Address(es)       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ADN Length  |               |
+-+-+-+-+-+-+-+-+               +
~  authentication-domain-name   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~Service Parameters (SvcParams) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I am more drawn to Ben's suggestion:

After the option code, length, and (for RA) lifetime fields, I propose
that we use the following format for all versions:
> 1. A 1-byte unsigned integer indicating the number of IP addresses
> 2. That many IP addresses (v4 or v6 depending on context)
> 3. The SvcPriority, ADN, and SvcParams, encoded as in SVCB RDATA

Which, for those who like pictures, probably means something along the
lines of this.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  # of Addrs   |               |
+-+-+-+-+-+-+-+-+               +
~          Address(es)          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Service Priority        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~  Authentication-domain-name   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~Service Parameters (SvcParams) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Whichever generic format we select, it could then also be applied to
PPP IPCP as a new extension:

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Type TBA   |    Length     |      Encrypted-DNS-Server
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Encrypted-DNS-Server (cont)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Now I'll cover the final set of requirements.

    +-------------+---------------------------------------------------+
    | R5.1        | Discovery MUST NOT worsen a client's security or  |
    |             | privacy posture.                                  |

Section 7 discusses security. I can't spot any way in which DNR makes it worse.

    +-------------+---------------------------------------------------+
    | R5.2        | Threat modelling MUST assume that there is a      |
    |             | passive eavesdropping attacker on the local       |
    |             | network.                                          |

Section 7.3 has two sentences on this so it's been considered, but I
don't know if it needs expanding.

    +-------------+---------------------------------------------------+
    | R5.3        | Threat modelling MUST assume that an attacker can |
    |             | actively attack from outside the local network.   |

Section 7.1 considers active attack from both inside and outside.
However I suggest the word "CPE" is made more generic to refer to any
such router at the boundary of the local network.

    +-------------+---------------------------------------------------+
    | R5.4        | Attackers MUST NOT be able to redirect encrypted  |
    |             | DNS traffic to themselves when they would not     |
    |             | otherwise handle DNS traffic.                     |
    +-------------+---------------------------------------------------+

This seems to be met.

So in summary I would prefer to see some changes before it leaves the WG.
To make this easier, can we please maintain it in
https://github.com/ietf-wg-add/draft-ietf-add-dnr?

Thanks
Chris


On Thu, 24 Feb 2022 at 15:57, Deen, Glenn <Glenn_Deen=
[e-mail]> wrote:

> The ADD draft DHCP and Router Advertisement Options for the Discovery of
> Network-designated Resolvers (DNR)
> https://datatracker.ietf.org/doc/draft-ietf-add-dnr/ is ready for WGLC.
>
> WGLC will run until March 14th, please post all comments to the ADD
> mailing list.
>
> ADD Co-chairs
> Glenn Deen & David Lawrence
>
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>