Re: [Int-area] WGLC on draft-ietf-intarea-provisioning-domains-05

[Ted Lemon <[e-mail]>]

On Jun 18, 2019, at 6:39 PM, Wassim Haddad <[e-mail]> wrote:
> This email starts an Int-Area WG Last Call on the latest version of draft-ietf-intarea-provisioning-domains (“Discovering Provisioning Domain Names and Data"):
> 
> https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-05.txt
> 
> Please respond to this email to support the document and/or send comments by 2019-07-05.
> 
> Please indicate if you are personally aware of any IPR that applies to https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-xx and
> if so, has this IPR been disclosed in compliance with IETF IPR rules?

Sorry for the late response to this.   I think this is important work, and I am in favor of publication.   I do have comments, of course.  It’s been long enough since I looked at this document that my cache is blown, so some of my comments may already have been addressed—if so, just let me know—there’s no need to reiterate those discussions.

First, the abstract is three paragraphs.   That’s too long, and furthermore, I don’t think it states the problem in a way that would be helpful to someone reading abstracts to decide whether to read the rest of the document.   I would suggest something like this:

RFC 7556 describes the problem of multiple provisioning domains (PvDs): that a host may be connected to two or more networks at the same time, where those networks are operated by non-cooperating entities.  RFC 7556 provides a contextual framework through which hosts can sensibly operate in such environments.

This memo provides a mechanism to implement this framework. Network operators can use a Router Advertisement option to announce a PvD label; hosts can compare labels acquired on different network interfaces to differentiate between PvDs.  These options can directly carry some information about PvDs; an additional mechanism is provided for obtaining further PvD information using HTTP over TLS.

The introduction says this:

>    For example, if Alice has a mobile phone provider and a
>    broadband provider in her home, her devices and her applications
>    should be capable of seamlessly transitioning from one to the other
>    and be able to use her Wi-Fi to access local resources or use the
>    more suitable link on a per-application base.

But this isn’t correct, is it?  What the MPvD architecture does is to allow the host to seamlessly use both interfaces at the same time, not to make seamless transitions between them.

>    Similarly, the same PvD ID could be used
>    on different interfaces of a host in order to inform that those PvDs
>    ultimately provide identical services.


You might say “that those PvDs provide compatible services.”

>    This document also introduces a way for hosts to retrieve optional
>    and additional information related to a specific PvD by means of an
>    HTTP over TLS query using an URI derived from the PvD ID.

This can be read two ways.   I think you mean to say “optional additional information,” not “optional information and additional information,” which is also a valid way to read it.   I would suggest just deleting the “and” here.

>    The
>    retrieved JSON object contains additional information that would
>    typically be considered unfit, or too large, to be directly included
>    in the Router Advertisement, but might be considered useful to the
>    applications, or even sometimes users, when choosing which PvD should
>    be used.

What does it mean for information to be “unfit?”   I think it means either “there isn’t an RA option for it” or “it wouldn’t fit.”   So maybe just say that?

>    R-flag      :   (1 bit) 'Router Advertisement' flag stating whether
>       the PvD Option is followed (right after padding to the next 64
>       bits boundary) by a Router Advertisement message header (See
>       section 4.2 of [RFC4861] <https://tools.ietf.org/html/rfc4861#section-4.2>).

Why are you padding to a 64-bit boundary?   I can’t remember if this was discussed previously—sorry if I’m treading old ground.

>    A router MAY send RAs containing one PvD option, but MUST NOT include
>    more than one PvD option in each RA.  In particular, the PvD option
>    MUST NOT contain further PvD options.

You could delete “in particular” here—I think it’s more confusing than clarifying.

>    In order to provide multiple different PvDs, a router MUST send
>    multiple RAs.  Different explicit PvDs MAY be advertised with RAs
>    using the same IPv6 source address; but different implicit PvDs,
>    advertised by different RAs, MUST use different link-local addresses
>    because these implicit PvDs are identified by the source addresses of
>    the RAs.

If the router sends multiple RAs with the same header information, they are going to be seen as the same RA by a host that doesn’t implement PvD.  So I’m not convinced that this statement gets to the heart of what is being asked here.   I’m reading this as saying that if I want my router to advertise one implicit PvD and two explicit PvDs, it’s okay for all three of these to have the same link-local address.  Is this correct?  Also, and perhaps this is dealt with later, if it’s intended that an RA advertise an explicit PvD and not at the same time an implicit PvD (for non-PvD-aware hosts), it should be the case that the Prefix option(s) are inside the PvD option, not outside of it where a non-PvD-aware host would see them.

It looks like in the examples the PvD RA will always be seen as invalid by the host.  Is this the motivation for using a different link-local address (that is, would the host discard the valid non-PvD RA upon receiving the PvD RA with an apparent lifetime of 0)?   If so, say so explicitly.

>    PvD IDs MUST be compared in a case-insensitive manner (i.e., A=a),
>    assuming ASCII with zero parity while non-alphabetic codes must match
>    exactly (see also Section 3.1 of [RFC1035] <https://tools.ietf.org/html/rfc1035#section-3.1>).  For example,
>    "pvd.example.com." or "PvD.Example.coM." would refer to the same PvD.

Does this mean that you are using punycode?  What are the rules in that case (no pun intended)?

>    When a host retrieves configuration elements using DHCPv6 (e.g.,
>    addresses or DNS recursive resolvers), they MUST be associated with
>    the explicit or implicit PvD of the RA received on the same
>    interface, sent from the same LLA, and with the O-flag or M-flag set
>    [RFC4861 <https://tools.ietf.org/html/rfc4861>].  If no such PvD is found, or whenever multiple different
>    PvDs are found, the host behavior is unspecified.

I don’t think this works.  Why would the DHCP message necessarily have the same link-local address as the RA?   If you want to identify the DHCP server as belonging to a PvD, you should send a list of IPv4 addresses of DHCPv4 servers, and a list of DHCPv6 server identifiers for DHCPv6 servers.  Don’t assume that the router and the relay are the same device.  There are many ways this can break.

>    In all of these cases, the DNS server addresses SHOULD be strongly
>    associated with the corresponding PvD. 

What does it mean for a DNS server address to be weakly associated with the corresponding PvD?

>    Specificially, queries sent
>    to a configured recursive DNS server SHOULD be sent from a local IP
>    address that belongs to the matching PvD.

What does it mean for an IP address to belong to a PvD (I know, but you have to specify).

>       A PvD that uses a NAT64 [RFC6146 <https://tools.ietf.org/html/rfc6146>] and DNS64 [RFC6147 <https://tools.ietf.org/html/rfc6147>] will
>       synthesize IPv6 addresses in DNS answers that are not globally
>       routable, and cannot be used on other PvDs.  Conversely, an IPv4
>       address resolved via DNS on another PvD cannot be directly used on
>       a NAT64 network without the host synthesizing an IPv6 address.

This isn’t entirely making the right point.   The real point is that an IP address that works on one PvD might not work on another, whether it supports NAT64 or not.   So an IP address received from a DNS server on one PvD should not be used on a different PvD.   RFC 7556 doesn’t explain this clearly.  An example of this problem is when the address is an RFC1918 address.   Another example is when it’s behind a firewall (the VPN case).   Whether there’s a NAT64 translator on the path is actually immaterial—if it’s a global IPv4 address that’s not firewalled, that will work, and if it’s not, it won’t.

>    The purpose of this additional set of information is to securely
>    provide additional information to applications about the connectivity
>    that is provided using a given interface and source address pair.

“Securely?”   What does this mean in this context?  It looks like the answer is that because the PvD is used for the lookup, PKI validation will show that the source of the data is owned by the claimed owner of the PvD.   If so, you might want to say this, rather than just saying “securely.”

>    When a JSON object could
>    not be retrieved, an error message SHOULD be logged and/or displayed
>    in a rate-limited fashion.

Why this advice?  Doesn’t this depend on what kind of host we’re talking about?  Shouldn’t this be up to the implementation?   E.g., a constrained device probably can’t and shouldn’t do this.

>    After retrieval of the PvD Additional Information, hosts MUST keep
>    track of the Sequence Number value received in subsequent RAs
>    including the same PvD ID.

This leads me to a related question.  Suppose the host receives an RA with an old sequence number.  Should it ignore that RA?

>       When a host last retrieved an object at time A including a
>       validity time B, and is configured to keep the object up to date,
>       it MUST perform the update at a uniformly random time in the
>       interval [(B-A)/2,B].

This is unclear.   I think you mean the expiry time in the JSON data from the previous update, but when I first read it my mind immediately went to HTTP Cache-Control message header.  Of course, one could legitimately suggest that you just use the HTTP cache-control header rather than inventing a new validity lifetime… :)

> If any of the
>    prefixes included in the PIO is not covered by at least one of the
>    listed prefixes, the PvD associated with the tested prefix MUST be
>    considered unsafe and MUST NOT be used.  While this does not prevent
>    a malicious network provider, it does complicate some attack
>    scenarios, and may help detecting misconfiguration.

Is this discussed in the Security Considerations section?   If so, you should reference the subsection in which it is discussed.   If not, you should discuss it there—this is inadequate.

>    | name     | Human-readable  | UTF-8       | "Awesome Wi-Fi"        |
>    |          | service name    | string      |                        |

This is a huge attack surface.   If you ever present this to the user as a way to identify the network, then I (the attacker) can present this same string when spoofing your network, since the string isn’t in any way validated.   I strongly suggest that this be removed.

>    | localizedName | Localized user- | UTF-8   | "Wi-Fi Genial"        |
>    |               | visible service | string  |                       |
>    |               | name, language  |         |                       |
>    |               | can be selected |         |                       |
>    |               | based on the    |         |                       |
>    |               | HTTP Accept-    |         |                       |
>    |               | Language header |         |                       |
>    |               | in the request. |         |                       |

Same.  If you really want to do this, you need to define a validation mechanism that can be plausibly implemented by hosts.   I can think of ways of solving this problem, but it won’t do to simply leave it unsolved.

I realize that the PvD ID is not as human readable as this would be, but it can be validated using HTTPS, whereas the more human-readable name cannot.

>    It is also RECOMMENDED that the HTTPS server checks the IPv6 source
>    addresses of incoming connections (see Section 4.1 <https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-05#section-4.1>).  This check give
>    reasonable assurance that neither NPTv6 [RFC6296 <https://tools.ietf.org/html/rfc6296>] nor NAT66 were used
>    and restricts the information to the valid network users.

Why not say “SHOULD” here?   Also, it might to do be more explicit.  The text in section 4.2 is better.

>    Note that this check cannot be performed when the HTTPS query is
>    performed over IPv4.  Therefore, the PvD ID FQDN SHOULD NOT have a
>    DNS A record whenever all hosts using the given PvD have IPv6
>    connectivity.

Why can’t it?  Isn’t the IPv4 source address going to be an address that belongs to the operator?

>    the top-level JSON dictionary with a key of the format "vendor-*"
>    where the "*" is replaced by the implementers or vendors
>    denomination. 

What does “the vendor’s denomination” actually mean in practical terms?

> Users should always apply caution when connecting to an unknown network.

A better way to state this is:

Users cannot be assumed to be able to meaningfully differentiate between “safe” and “unsafe” networks.  This is a known attack surface that is present whether PvDs are in use or not, and hence cannot be addressed by this document.  However a host that correctly implements the MPvD architecture (RFC7556) using the mechanism described in this document will be less susceptible to such attacks than a host that does not.