Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS and COMMENT)

[Sebastian Kiesel <[e-mail]>]

Hi Benjamin,

please find below our responses to your questions and concerns,
except those related to authenticity and the usage of DNSSEC.
For the latter I have started a separate thread, so we can
hopefully find a solution that addresses both your and Erik's concerns.

On Wed, Dec 19, 2018 at 10:36:18AM -0800, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-alto-xdom-disc-04: 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-alto-xdom-disc/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 3.3's procedures for shortening domain names seem potentially
> problematic.  While I can understand the desire to reduce the number of
> DNS queries, I'm not sure that it's really appropriate to place restrictions
> on what prefix lengths/boundaries can be used to divide administrative
> domains in a standards-track document.

The current procedure specification tries to make a compromise
between flexibility and avoiding excess load on the DNS.

For the intended use case it is not a primary concern to find out the
exact prefix lenghts that have been delegated.  If, say, I am the owner
of a IPv4 /17, I can either try to make an agreement with the owner of
the other half of the /16 (if the delegation structure is that way) and
jointly run one ALTO server for the /16, or I can add 128 NAPTRs, one
for each /24 in my range, that point to my ALTO server. Both methods
would work for our use case.

The exact prefix lengths for which we do a query (/32, /24, /16 for IPv4
and /128, /64, /56, /48, /32 for IPv6) were taken from RFC 7216.  Maybe
we should add /40 to the IPv6 list, for a regular spacing between the
steps, but not significantly more to avoid an excess number of queries?


> In particular, the IPv4 procedure
> only allows lengths that end on octet boundaries, which seems to ignore the
> possibility of using procedures from BCP 20.

In the intended use case (of ALTO XDOM DISC, not overall ALTO that has
a broader applicability) we assume that single-homed networks (in
particular the residential DSL/cable subscribers) will normally
not want to publish their own ALTO information but will leave that
up to their upstream ISP.  Although ALTO is by no means technologically
tied to BGP, we anticipate that BGP will be the most important
information source and that the operator of the outermost BGP-enabled
router will have the most incentives to publish a digest of his
routing policies and costs through ALTO to the application overlays.
In these scenarios, IPv4 prefix lengths > 24 do not matter.

That being said, the procedure is compatible with BCP20: For

1.2.0.192.in-addr.arpa. IN CNAME   1.0/25.2.0.192.in-addr.arpa.

1.0/25.2.0.192.in-addr.arpa. IN PTR     host1.A.domain.

you could add

1.0/25.2.0.192.in-addr.arpa. IN IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.A.example.net/ird!" .



> IPv6 is a somewhat different
> case, but my understanding is that in the general case prefix boundaries
> can land on arbitrary nibbles, and if we only look at a specific subset for
> NAPTR records we risk not matching up with reality.  The lists in the
> fourth column of the table in Section 3.4 would presumably need to be
> revised as well, if this changes.
> 
> >From Section 5.2.1:
> 
>    We assume that if two organizations share parts of their DNS
>    infrastructure, i.e., have common in-addr.arpa. and/or ip6.arpa.
>    subdomains, they will also be able to operate a common ALTO server,
> 
> Perhaps I am confused, but common subdomains in the reverse zones just
> implies a common IP address block.  Why does it also imply a common DNS
> infrastructure?

This paragraph has BCP 20 in mind.  What we want to say is that if you
use BCP 20, there will be someone who gets the reverse DNS delegation
for the /24 and who has to setup all that CNAMES in his name servers.
So BCP 20 implies a little bit more interaction and trust than just
getting a domain for the /24 delegated.  Maybe the organizations
involved in that can also jointly run one ALTO server and everyone may
feed his ALTO information into it.  Or, they may use CNAMES to put
NAPTRs on the /32, or they leave the ALTO configuration their upstream
ISP (see above).

I'll try to find a better wording.

> I also have a few points relating to the security of DNS and DNSSEC.

Please let's discuss these issues in the other mail thread, to address
Erik's concerns, too.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I didn't see a response to the secdir review, and agree that discussion
> of authorization policy would be appropriate.
> 
> Section 3.1
> 
> Does this procedure really make sense for a prefix length of zero (or
> should the inequalities in the second paragraph have a strict inequality
> for 0 < L)?

This will be addressed in the new version of the draft.
Syntactically valid is 0 <= L <= 32 (v4) or 0 <= L <= 128 (v6).
Supported by the procedure is  8 <= L <= 32 (v4) or 32 <= L <= 128 (v6).

> 
>    In the intended usage scenario, the procedure SHOULD always be called
>    with the parameter SP set to "ALTO:https".  [...]
> 
> This requirement is also stated in Section 2; generally we recommend to
> not duplicate normative requirements (with 2119 language) in multiple
> places, to avoid the risk of them getting out of sync.

This will be addressed in the new version of the draft.

> Section 3.2
> 
>    First, the procedure checks the prefix length L for unsupported
>    values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the
>    procedure aborts and indicates an "invalid prefix length" error to
>    the caller.  Similarly, if AT=IPv6 and L < 32, the procedure aborts
>    and indicates an "invalid prefix length" error to the caller.
> 
> Is this in conflict with the inequalities in the second paragraph of
> section 3.1?

see above.

> 
>    If AT=IPv4, a domain name R32 is constructed according to the rules
>    specified in Section 3.5 of [RFC1035] and it is rooted in the special
>    domain "IN-ADDR.ARPA.".
> 
> RFC1035 doesn't use the term "R32", so some sort of text or
> typographical clarification that the term is new to this document would
> be helpful.  Similarly for "R128".

Thanks for pointing this out. This will be addressed in the new version
of the draft.

> Section 3.5
> 
>    The procedure performs one or more DNS lookups in a well-defined
>    order (corresponding to descending prefix lenghts, see Section 3.4),
> 
> nit: "lengths"
> 
> Section 4.1
> 
>    An ALTO client may invoke the ALTO Cross-Domain Server Discovery
>    Procedure (as specified in Section 3) for an IP address or prefix "X"
>    and get a list of one or more IRD URI(s), including order and
>    preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https").  These
>    IRD(s) will always contain a network and a cost map, as these are
>    mandatory information resources (see Section 11.2 of [RFC7285]).
> 
> nit: There seems to be a missing transition here, since the IRD URI(s)
> are URIs, which must be dereferenced or otherwise accessed in order to
> retrieve the actual IRD(s) (and their network/cost maps).  (Similarly for
> the subsequent sections as well.)
> 
> nit: we probably need a reference (7285?) for "PID", as well as
> expansion on first usage.  Please also expand ECS on first usage.

OK.  I thought there were enough references to RFC 7285 in the first
paragraph of section 4 to make clear that we assume the reader is
familiar with the key concepts of RFC 7285 (Actually this is true for
the whole document).

>                     Accessing cells outside column "X" and row "X" may
>    not yield useful results.
> 
> nit: I would suggest something like "accessing cells that relate to
> neither column 'X' nor row 'X'", since the current text could be read to
> indicate the single cell at their intersection, which is not a terribly
> interesting cell.

Thanks for pointing this out. This will be addressed in the new version
of the draft.

> 
> Section 5.1.2
> 
>                                                      Similarly, resource
>    consumers on mobile hosts SHOULD query the resource directory again
>    after a change of IP address, in order to get a list of candidate
>    resource providers that is optimized for the new IP address.
> 
> Is it really the case that IP address change is the only situation for a
> mobile host what would cause refresh of the directory information to be
> advisable?

Do you have a particular scenario in mind that we might have forgotten?

> 
> Section 6.1
> 
>                   Note that if TLS is used to protect ALTO, the server
>       certificate will contain the host name (CN).  Consequently, only
>       the host part of the HTTPS URI will be authenticated, i.e., the
>       result of the ALTO server discovery procedure.  [...]
> 
> nit: I think this is talking about what happens after the ALTO server
> discovery procedure; the TLS CN check does not help with verifying the
> discovery procedure itself.  (That is, something like "it only
> authenticates the result of the ALTO server discovery procedure and not
> the discovery procedure itself".)

correct. the intent is to explain why in the world wide web, we can
use DNS-without-DNSSEC and later validate the result with the cert,
but not here. We'll rewrite that paragraph a bit.

> 
> Section C.1
> 
>    The ALTO protocol specification [RFC7285] details how an ALTO client
>    can query an ALTO server for guiding information and receive the
>    corresponding replies.  However, in the considered scenario of a
>    tracker-based P2P application, there are two fundamentally different
>    possibilities where to place the ALTO client:
> 
> nit: I think this is the first time that the P2P scenario is mentioned,
> so more lead-in than just "the considered scenario" might help the
> reader.
> 
>    In the second scenario (see Figure 4), the resource directory has an
> 
> Is this Figure 4 or Figure 3?

both ... see Figures 3 and 4

> Section C.2
> 
> This analysis seems a little one-sided, in that it presents the benefit
> of tracker-based selection without mention of the additional costs that
> the tracker bears in this solution (needing to do quality-based
> selection over the N=10000 total peers instead of random selection).
> Depending on how that cost scales, the overal best choice may differ.

Well, this is true for (almost?) every ALTO use case.  Do some addtional
effort to choose your communication partners, get better performance
in the overlay and cause less resource consumption in the underlying
infrastructure. This only pays off for larger data transmissions, but
there, it will.


Thanks for pointing out these nits!
Sebastian