Re: WGLC: Re: Questions re: draft-ietf-mboned-driad-amt-discovery

Hi Kyle,

From: Kyle Rose <[email protected]>
> Re: "connection", RFC 7450 uses "connection" in a relevant way in exactly
> one place (4.1.4 Deployment) but (as noted in this draft) fails to define
> it. It does repeatedly refer to a three-way handshake, however, so perhaps
> text should be added to this draft to make it clear that "connection" is
> (AFAICT) being defined as completion of the first two steps of the three-way
> handshake from 7450. 

Something like that originally occurred to me, but I think DRIAD's
formulation disagrees with the simple form of that, because of a disconnect
in the handling of the L flag.

I'll tentatively call this suggestion "rejected with due consideration"
unless you want to discuss more, but here's the reasoning so that
anyone who disagrees can poke holes or propose some language that
handles it:


From https://tools.ietf.org/html/rfc7450#section-5.1.4
   The successful delivery of this message to a gateway marks the start
   of the second stage in the three-way handshake used to create or
   update tunnel state within a relay.

This makes no mention of the L-flag; receipt of the Membership Query is
the second stage of the 3-way handshake regardless of the L-flag value.

From https://tools.ietf.org/html/rfc7450#section-5.1.4.4
   (5.1.4.4.  Limit (L) Flag)
     ...   A gateway checks
   this flag before attempting to create new group subscription state on
   the relay to determine whether it should restart relay discovery.

DRIAD differs on this point for purposes of Happy Eyeballs by calling it
"not a connection" when a Membership Query arrives with the L flag, rather
than calling it a connection that should restart the discovery process:

From https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-09#section-2.4.3:
   o  An AMT connection is completed successfully when the gateway
      receives from a newly discovered relay a valid Membership Query
      message (Section 5.1.4 of [RFC7450]) that does not have the L flag
      set.

So I thought I'd just state the normative connection definition the way
that produces a better behavior, and ignore the independent existence on
the side of the three-way handshake concept.

I also didn't think it left things unclear, because the three-way
handshake isn't explicitly defined in its own terms either or used very
heavily in RFC 7450, it's just mentioned as the 3 involved message types
being stages of it, and then referred to in the security considerations
for pointing out that it protects against source-spoofing.

I thought trying to lay all that out would add more complication than
any confusion it would resolve by pointing out that the connection is
happening during the 3-way handshake, and that it's better to just leave
the definition of a connection for Happy Eyeballs purposes as its own
separate thing.

But do let me know if you have a suggestion for language that you think
would help, I'm not claiming the definition is perfect, just that it's
not obvious to me that it would improve by folding in a three-way
handshake mention.


> Re: the DNS rate limiting, what motivated the numbers in the normative:
> q( Otherwise, a gateway MUST provide a rate limit for the DNS queries, and
> its default settings MUST NOT permit more than 10 queries for any
> 100-millisecond period)

The first and biggest motivation is that I thought _some_ numbers should be
present.  It matters less what they are than that there is something.

The specific numbers chosen were from roughly eyeballing it as equivalent to
10 TCP connections within a second with a 10 initial cwnd, which isn't out of
line with what browsers often might do today while opening a web page, and
so at a roughly "not harmful" level suitable for a default.

In practice I'm expecting that real life deployments will mostly just use a
getaddrinfo call that's backstopped on their systems by dnsmasq's
--dns-forward-max.  But I just get kinda twitchy whenever I see places where
some remote process can cause some local process to send an unbounded number
of packets, so I thought I'd flag it so the engineer tasked with writing it
has an excuse to insist on a limit when his boss wants to do something clever.

I also thought it important because in Happy Eyeballs the DNS resolution phase
(section 3 of 8305) says "Both queries SHOULD be made as soon after one another
as possible", but this assumes we're talking about exactly 2 queries for a
single known hostname, not a chain of 2 queries one of which can produce
several hostnames, so I thought some mention of a limit was warranted.

When you ask about motivations I have to admit I put this in more to ease
my troubled soul than because I think it'll really prevent a problem on
someone's network in practice, based on any kind of sound measurements.  But
of course suggestions are welcome on improved language here.

> Happy to know if I just missed a discussion thread someplace.
Not that I know of...

> OW, looks good. Ship it.
Thanks.

Best regards,
Jake

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned