[Int-area] Benjamin Kaduk's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-intarea-provisioning-domains-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Alexey basically already noted this in his Comment, but I'll elevate it
to a Discuss: the usage of TLS for retrieving PvD Additional Information
is not really completely specified -- generally in this sort of case
where there's a (provisioning) domain name to authenticate we'd expect
to require that the server present a certificate with DNS-ID [RFC6125]
that matches the expected name.  We could also cite RFC 7525 for TLS
best practices and/or make a TLS version recommendation (i.e., 1.3).

There seems to be a missing step in the binding of the PvD ID to the
actual usage, or rather, we are making stronger statements about
authenticity than the technology seems to justify.  While we can verify
that the TLS certificate used to access the additional information
matches with the PvD ID provided, there doesn't seem to be a step to
validate that the PvD ID in question is applicable for the current
network environment.  The prefix match helps some, but (to first order)
only for globally-routable prefixes in the absence of NAT.  Malicious
routers (e.g., coffeeshop wifi) can fairly easily implement NAT66 and
circumvent host-side countermeasures; tunneling traffic through to a
compromised host actually in the target PvD would allow circumvention of
the TLS-server-side countermeasures.  I have some suggested rewordings
in the Comment section that should bring the claims in line with what is
actually provided.

(As something of a side note, it seems that the JOSE/signature scheme
discussed in the secdir review thread, that does have a tighter binding
to the local network with the PvD, could defeat the caching attack
discussed there by having the host supply a nonce in the RS and
including that in the signed response, but that requires a lot of
expensive signatures and has some challenging key-management problems.
So it doesn't seem worth pursuing, even though it's attractive to make
more use of the network locality.)

The IANA Considerations for PvD Option Flags indicates that bits 0 to 15
are managed by IANA, but I think there are only 12 bits available due to
the 4-bit Delay field.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.1

Do we want to give any guidance about what to put for the Sequence
Number (and/or Delay) when the H-bit is not set?  IIUC they are only
relevant for the fetching of additional data.

   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]).  The usage of the inner message header is
      described in Section 3.4.

nit(?): I'd be wary of saying "PvD option is followed", since IIUC the
inner RA header and subsequent options are still part of "the PvD
option".

Section 3.2

   In order to provide multiple different PvDs, a router MUST send
   multiple RAs.  If more than one different Implicit PvD is advertised,
   the RAs MUST be sent from different link-local source addresses.

This seems to imply that implicit PvDs can be advertised via the PvD RA,
but the only contents specified for the "PvD ID FQDN" field thereof is a
DNS-format FQDN, and we don't say how to construct one of those for an
implicit PvD.  I think the intent is just to say that "RAs sent from
different link-local source addresses establish distinct implicit PvDs,
in the absence of a PvD Option".

Section 3.4

   received RA otherwise.  If an RA message header is present both
   within the PvD Option and outside it, as indicated by the R-flag, the
   header within the PvD Option takes precedence.

Why is the R-flag relevant?

   Similarly, hosts MUST associate all network configuration objects
   (e.g., default routers, addresses, more specific routes, DNS
   Recursive Resolvers) with the PvD associated with the RA which last
   updated the object.  For example, addresses that are generated using
   a received Prefix Information option (PIO) are associated with the
   PvD of the last received RA which included the given PIO.

I'm not sure I'm parsing the first sentence as intended.  For any given
configuration object, there will be an RA which has most-recently
updated that object ("last updated the object"); that RA has some
associated PvD, whether via explicit PvD ID option or assignment of
implicit PvD.  It sounds like this is telling me to associate the object
with the aforementioned PvD, so that "last PvD wins" for any given
object, but this seems at odds with the idea of having multiple PvDs
active at once, with separate configurations.  So I'm not sure that
the "last updated" phrasing is giving the right impression.

   While resolving names, executing the default address selection
   algorithm [RFC6724] or executing the default router selection
   algorithm when forwarding packets ([RFC4861], [RFC4191] and

Is this an exhaustive list?

   [RFC8028]), hosts and applications MAY consider only the
   configuration associated with any non-empty subset of PvDs.

   For example, a host MAY associate a given process with a specific
   [...]

nit: maybe these should not be separate paragraphs?

Section 3.4.1

   When a host retrieves stateful assignments using DHCPv6, such
   assignments MUST be associated with the received PvD which was
   received with RAs with the M-flag set and including a matching PIO.

Is there a reason to use different language here than the previous
paragraph (which was "all the explicit and implicit PvDs received on the
same interface and [stuff about the RA]")?

   In cases where an address would be assigned by DHCPv6 and no matching
   PvD could be found, hosts MAY associate the assigned address with any
   implicit PvD received on the same interface or to multiple of
   implicit PvD received on the same interface.  This is intended to
   resolve backward compatibility issues with rare deployments choosing
   to assign addresses with DHCPv6 while not sending any matching PIO.

Wouldn't backwards compatibility be better if we specified "all implicit
PvD on the same interface" rather than leaving things in a
nondeterministic state?

Section 3.4.2

   When a PvD-aware host retrieves configuration elements from DHCPv4,
   the information is associated either with a single Explicit PvD on
   that interface, or else with all Implicit PvDs on the same interface.

This is further specified in the following two paragraphs, right?  So
maybe "as detailed below" would help the reader.

Section 3.4.4

   PvD-aware hosts can be provisioned with recursive DNS servers via RA
   options passed within an Explicit PvD, via RA options associated with
   an Implicit PvD, via DHCPv6 or DHCPv4, or from some other
   provisioning mechanism that creates an Implicit PvD (such as a VPN).

nit: didn't we say that IPsec VPNs were explicit PvDs?  If so, they will
not be provisioning recursive DNS servers via RA options, and thus are
not covered by any of the items in this listing.

   In all of these cases, the recursive DNS server addresses SHOULD be
   associated with the corresponding PvD.  Specifically, queries sent to
   a configured recursive DNS server SHOULD be sent from a local IP
   address that was provisioned by the PvD via RA or DHCP.  Answers

nit: are they provisioned "by" the PvD" or "with"/"for" the PvD?

   PvD-aware applications will be able to select which PvD(s) to use for
   DNS resolution and connections, which allows them to effectively use
   multiple Explicit PvDs.  In order to support non-PvD-aware
   applications, however, PvD-aware hosts SHOULD ensure that non-PvD-
   aware name resolution APIs like "getaddrinfo" only use resolvers from
   a single PvD for each query.  Handling DNS across PvDs is discussed

just to check: this SHOULD is only at a per-API-call level, and
subsequent calls to getaddrinfo (even with the same arguments) are
permitted to use results from different PvDs?  I would have naievly
expected that the "default PvD" used for such non-PvD-aware applications
would be relatively stable over time...

Section 4

   This JSON object is restricted to the restricted profile of I-JSON,
   as defined in [RFC7493].

nit: I-JSON is a restricted profile of JSON, but does not itself has a
"restricted profile" subset, so I'd suggest just "is restricted to the
I-JSON profile".

Section 4.1

   Note that the DNS name resolution of the PvD ID, the PKI (Public Key
   Infrastructure) checks as well as the actual query MUST be performed
   using the considered PvD.  In other words, the name resolution, PKI

nit(?): I am not sure if these "PKI checks" are supposed to be DNSSEC or
the TLS validation.  I don't think we previously discussed having
separate per-PvD TLS trust anchors, which mostly leads me to assume
DNSSEC PKI, but greater clarity in the document would be welcome.

   If the HTTP status of the answer is greater than or equal to 400 the
   host MUST abandon and consider that there is no additional PvD
   information.  If the HTTP status of the answer is between 300 and

nit: "abandon" is a transitive verb and requires an object.

   399, inclusive, it MUST follow the redirection(s).  If the HTTP
   status of the answer is between 200 and 299, inclusive, the host MAY
   get a file containing a single JSON object.

Is redirect-chasing recursive or one-time?
I agree with Alissa that this "MAY" is not normatiave.

   After retrieval of the PvD Additional Information, hosts MUST
   remember the last Sequence Number value received in the RA including
   the same PvD ID.  Whenever a new RA for the same PvD is received with

nit: s/the RA/an RA/

   a different Sequence Number value, or whenever the expiry date for
   the additional information is reached, hosts MUST deprecate the
   additional information and stop using it until a new JSON object is
   retrieved.

Is this really just "a different Sequence Number value" or do we want "a
larger Sequence Number value"?  If the former, then it's not really
functioning as a *sequence* number, is it?
Also, is the "until [...]" clause really needed?  Regardless of whether
new additional information is retrieved (and validated), *this*
additional information is still not being used.

nit: if we are going to say "uniformly random" for the [(B-A)/2,B]
interval, we should probably also use "uniformly" for the "random time
between zero and 2**(Delay * 2) milliseconds".

   Since the 'Delay' value is directly within the PvD Option rather than
   the object itself, an operator may perform a push-based update by
   incrementing the Sequence value while changing the Delay value

nit: "Sequence Number"

Section 4.2

   RA by the network operator.  In particular, when a captive portal is
   present, hosts MUST still be allowed to perform DNS, PKI and HTTP
   over TLS operations related to the retrieval of the object, even
   before logging into the captive portal.

I assume "DNS" here means "DNS over UDP(/TCP) on port 53 in the
traditional, unencrypted, protocol of STD 13"?  It may be prudent to be
clear about the expectations here.

   Routers SHOULD increment the PVD Option Sequence Number by one
   whenever a new PvD Additional Information object is available and
   should be retrieved by hosts.  If the value exceeds what can be
   stored in the Sequence Number field, it SHOULD wrap back to zero.

Why are these just "SHOULD"?

   The server providing the JSON files SHOULD also check whether the
   client address is part of the prefixes listed into the additional
   information and SHOULD return a 403 response code if there is no
   match.

(I assume that the "SHOULD" is to allow for exceptions when NAT-shaped
things are in use.)
nit: "is part of" is perhaps a bit odd

Section 4.3

[perhaps update the example "expires" value to something slightly more
current, both here and in 4.3.1?]

   | noInternet | No Internet, set     | Boolean  | true               |
   |            | when the PvD is      |          |                    |
   |            | restricted.          |          |                    |

nit: "set to 'true'"; setting it to "false" does not provide such an
indication :)

In addition to Alissa's Discuss point, "MUST create sub-dictionaries,
[...] with a key of the format 'vendor-*'" is in conflict with "URN
namespace SHOULD be used rather than the 'vendor-*' format".

Section 4.4

   When a host retrieves the PvD Additional Information, it MUST verify
   that the TLS server certificate is valid for the performed request
   (e.g., that the Subject Alternative Name is equal to the PvD ID
   expressed as an FQDN).  This authentication creates a secure binding
   between the information provided by the trusted Router Advertisement,

What makes an RA "trusted"?

   and the HTTPS server.  However, this does not mean the Advertising
   Router and the PvD server belong to the same entity.

Can you give me an example of when they would not be part of the same
entity?  I can only partially see how that would happen.

I see there's some discussion of client IPv4 addresses here, but note
that the "prefixes" entry in the additional information is specifically
limited to IPv6 prefixes.  Does the prefix check just not work at all
for IPv4, or we know that NAT44 is too prevalent for it to be worth
trying, or ...?

Section 5

Do you want to also mention that some fields (e.g., Sequence Number) are
only listed when relevant, and/or provide default values for the
examples when they are not explicitly listed?

Section 5.2

   In the above example, non-PvD-aware hosts will only use the first RA
   sent from their default router and using the 2001:db8:cafe::/64
   prefix.  PvD-aware hosts will autonomously configure addresses from

nit(?): I can't decide whether "from" or "for" is intended in "from
their default router".

   both PIOs, but will only use the source address in 2001:db8:f00d::/64
   to communicate past the first hop router since only the router
   sending the second RA will be used as default router; similarly, they
   will use the DNS server 2001:db8:f00d::53 when communicating with
   this address.

nit: I'm not sure I understand what "communicating with this address" is
intended to mean (it would make more sense to me as "communicating from
this adddress").

Section 5.3

      *  RA Header: router lifetime = 1600 (PvD-aware hosts will use
         this router as a default router), implicit length = 2

just to check my understanding: this is only "use as a default router"
within the scope of this PvD (and will use the other RA's data as
default router for the other PvD)?  I'd perhaps consider adding "for
this PvD", though it's far from clear that such clarification in the
text is needed.

Section 6

This RA Option can include other RA Options; we should probably note
that the security considerations of the included options continue to
apply.

When RAs have to be split to avoid exceeding the link MTU, there is
perhaps some scope for selective packet blocking to influence host
behavior (by denying them some of the PvD-specific configuration),
though of course such attacks are pretty challenging on a local
network/link.

Attacks to block attempts to retrieve the additional information are
more likely succeed, though the scope is perhaps limited since all that
stuff is supposed to be optional.  We can't really limit what vendors
will do with it, though, so we should probably treat it as having some
significant risk of DoS.

Expiration times are represented as absolute times, so the usual
considerations about accurate time and clock skew apply.

   This specification does not improve the Neighbor Discovery Protocol
   security model, but extends the purely link-local trust relationship
   between the host and the default routers with HTTP over TLS
   communications which servers are authenticated as rightful owners of
   the FQDN received within the trusted PvD ID RA option.

I think I need some more persuasion to believe that the routers are
actually "authenticated as rightful owners of the FQDN received" as
claimed here.  In light of the following paragraph in the text, perhaps
we should say something more like "validates that the owner of the FQDN
authorizes its use with the prefix advertised by the router" and "in
combination with implicit trust in the local router (if present), this
gives the host some level of assurance that the PvD is authorized for
use in this environment.  However, when the local router cannot be
trusted, no such guarantee is available."

   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 or not PvDs are in use, and hence cannot be
   addressed by this document.  However, a host that correctly
   implements the multiple PvD architecture ([RFC7556]) using the
   mechanism described in this document will be less susceptible to such
   attacks than a host that does not by being able to check for the
   various misconfigurations described in this document.

I think this is only true for certain definitions of "safe" and would
like to learn more about what definition the authors had in mind when
writing this.

Section 7

Whenever we introduce new identifier (types), the question of privacy
considerations arises with respect to tracking of the identified entity
or related entities, among other things.  The PvD itself here is not
really "trackable", so we seem to be concerned only with tracking of
devices that connect to /use a given PvD.  I'll try to walk through the
workflow to confirm that there's not more that needs to be said here:
Generally, a host is going to mostly just be receiving the PvD ID value,
and not broadcasting it in much outgoing traffic.  It would perhaps get
some configuration about PvD IDs in some area (though configured PvD IDs
seems more likeoy on routers than hosts), and receives PvD IDs via RA
options, and uses the PvD ID to correlate/associate information across
RAs, potentially across networks and mobility events.  The only time I
see the PvD ID being sent outbound from a PvD-aware host is in the query
to the PvD's well-known URI for additional information, and we say that
the DNS resolution used to look up that name must be from the same
configuration that claims to use that PvD. This is done with the intent
that there's no additional information leakage, as we're essentially
just echoing back the PvD ID to the same administrative entity that gave
it to us.  For honest routers it clearly should work fine, but what
happens if we have dishonest routers?  A dishonest router could send an
RA claiming a different/bogus PvD ID, and an honest host as specified
here would then go ahead and make the DNS+HTTPS query for additional
information, which is still just echoing back the value that was sent,
to who sent it.  There would only be some additional information leakage
if the host was configured to be selective about which PvDs to fetch
additional information for, so that the attacker could check whether a
given PvD ID was on the whitelist or not.  I think, though, that even if
a host does have a whitelist of PvD IDs it will use, there's still no
harm from always fetching the additional information and just discarding
it for non-whitelisted PvDs -- that lets such a host blend into the
genera population of PvD-aware hosts without directly revealing that it
has a whitelist or the contents thereof.  (Its subsequent network
traffic might still give some implicit signal, though that's perhaps
less conclusive.)

I don't have a great sense of how (un)likely host-leve PvD whitelists
are to be seen in practice, and thus whether it's worth putting the
above advice/analysis (just the "to blend in, always fetch even if you
ignore" part) into the document.  Given that we do mention
FQDN/IP-prefix whitelists, I'm leaning towards including this aspect as
well.

(The above analysis changes some if a host is going to be caching any
PvD-specific information across mobility events within the same PvD, but
I don't see much to indicate that such long-term caching would occur.)

   default router, this property can't be ensured.  Therefore, hosts
   willing to retrieve the PvD Additional Information before using it
   without leaking identity information, SHOULD make use of an IPv6

nit: this is either tautological or not saying what it's intended to,
since it's impossible to use the information without having first
retrieved it...

   Privacy Address and SHOULD NOT include any privacy sensitive data,
   such as User Agent header or HTTP cookie, while performing the HTTP
   over TLS query.

...so perhaps rephrasing akin to "To minimize the leakage of identity
information while retrieving PvD Additional Information, hosts SHOULD
[...]" is in order.

   From a user privacy perspective, retrieving the PvD Additional
   Information is not different from establishing a first connection to
   a remote server, or even performing a single DNS lookup.  For
   example, most operating systems already perform early queries to well
   known web sites, such as http://captive.example.com/hotspot-
   detect.html, in order to detect the presence of a captive portal.

I understand the desire to only use names/numbers designated as "for
example use" in RFCs, but this seems like a case where it might be worth
making an exception.

   Network operators SHOULD restrict access to PvD Additional
   Information to only expose it to hosts that are connected to the
   local network, especially if the Additional Information would provide
   information about local network configuration to attackers.  This can

(It seems that even the existence of a vendor-* subobject might be
considered "sensitive" in this fashion.)

Section 8.2

Is there any additional guidance we wish to give to the Experts?

Section 8.3

   document (as specified in Figure 1).  Future assignments require
   Standards Action [RFC8126], via a Standards Track RFC document.

nit: please drop the "via a Standards Track RFC document" clause; it's
basically redundant with Standards Action and I'm not sure why there's a
specific need to disallow BCP documents from allocating such codepoints.

Section 8.4

   Interoperability considerations: This document specifies format of
   conforming messages and the interpretation thereof.

nit: "the format"

   Applications that use this media type: This media type is intended to
   be used by network advertising additional Provisioning Domain
   information, and clients looking up such information.

nit: "networks" plural

Section 10.1

I'm not sure whether RFCs 2131, 3646, and 8106 need to be Normative.

Section 10.2

On the other hand, RFC 2818 does seem like it needs to be Normative (and
7556 as was already mentioned).