[Int-area] Mohamed Boucadair's Discuss on draft-ietf-intarea-proxy-config-11: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-intarea-proxy-config-11: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

Hi Tommy, Dragana, and Yaroslav,

Thank you for the effort put into this document.

Please find some points for discussion below:

# IETF LC Comments

Unless I’m mistaken, there was no discussion/follow-up to the comments received
during IETF LC.

I have delayed my review with the hope to see a new version.

# Applicability Scope & Target Deployment

I appreciate that the document includes the following:

   Additionally, this document outlines how these mechanisms might be
   used to discover proxies associated with a network (Section 5).
   However, this approach is not described for the purpose of generic
   proxy discovery, and requires careful security considerations for
   clients to limit usage to trusted scenarios.

However, it is not clear the target protocols and the conditions under which
this can be used.

The examples are more about HTTP, but still there is no explicit discussion
about target deployment. Please consider clarifying the scope and target
deployment.

# Partial Solution

CURRENT:
   The mechanisms defined in this document are intended to offer a
   standard alternative that works for URI-based proxies and avoids
   dependencies on executing Javascript scripts, which are prone to
   implementation-specific inconsistencies and can open up security
   vulnerabilities.

However, the alternative design proposed in this document does only provide a
partial solution as it relies on RFC 8801. This can be seen as encouraging
fragmented solutions with the inherit implications on deployment (including
selection when several mechanisms as supported by a client: which one has
higher priority, etc.).

The document lacks a discussion about operational constraints/limits, including
a discussion about how IPv4/IPv6 feature parity can be provided.

# DNS Dependency

CURRENT:
   Presence of this SvcParamKey, named pvd indicates that the proxy host
   supports PvD discovery via the well-known PvD URI ".well-known/pvd"
   defined in Section 4.1 of [PVDDATA].  The presence of this key in an
   HTTPS or SVCB record signals that the proxy's PvD Additional
   Information can be fetched using the "https" scheme from the proxy
   host on port 443 using the well-known path.  The presentation and
   wire-format values for pvd SvcParamKey MUST be empty.

How this works for private proxies for which there is no record in the public
DNS? Wouldn’t this be problematic especially in cases where resolvers supplied
by the PvD access network are not used to resolve the name?

Unless I’m missing something the usefulness of these attributes depends on the
underlying setup. These assumptions (and implications) should be described.

# CIDR

CURRENT:
   The subnets array includes IPv4 and IPv6 address literals, as well as
   IPv4 and IPv6 address subnets written using CIDR notation [CIDR].

CIDR is normative for subnet attribute. Please move that ref to Normative.

# Inappropriate Uses of Key Words

Several parts of IANA section include normative language such as in:

CURRENT:
   New assignments in the "Proxy Information PvD Keys" registry will be
   administered by IANA through Expert Review [RFC8126].  Experts are
   requested to ensure that defined keys do not overlap in names or
   semantics, do not contain an underscore character ("_") in the names
   (since underscores are reserved for vendor-specific keys), and have
   clear format definitions.  The reference and notes fields MAY be
   empty.

The use of key words is not compliant with
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/.
Please fix. Thanks.


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

# Upgrade

CURRENT:
   Using this mechanism a client can learn that a legacy insecure HTTP
   proxy that the client is configured with is also accessible using
   HTTPS.

Can’t this be done by leveraging existing SVCB records (i.e., without the pvd
keys)?

# Mixing Protocol and Operational considerations

There are several places where deployment considerations are mixed with
protocol matters. For example,

CURRENT:
   Note that all proxies that are co-located on the same host share the
   same PvD Additional Information.  Proxy deployments that need
   separate PvD configuration properties MUST use different hosts.

Better to have these grouped into a dedicated Operational Considerations
section.

# Mandatory keys

CURRENT:
   PvD Additional Information is required to contain the "identifier",
   "expires", and "prefixes" keys.

Please consider citing rfc8801#section-4.3

# Discovering proxies from network PvDs

## I suggest to place this section under an Operational Considerations Section.

## BTW, can this part be expanded to elaborate which specific aspects need more
exploration and how the lack thereof is a hinderance for deployment:

CURRENT:
   Further security and experience considerations are needed for these
   cases.

## Please consider reminding that OSP cons in rfc8801#section-5 apply.

# [IANA_PVD] and [IANA_SVCB]

CURRENT:
   This document registers two new keys in the "Additional Information
   PvD Keys" registry [IANA_PVD].

   ..
   IANA is requested to add a new entry to the "DNS SVCB Service
   Parameter Keys (SvcParamKeys)" registry [IANA_SVCB]:

I think both should be listed as Informative, not Normative.

Cheers,
Med