RE: Is "Version Greasing" a new benfit or a new obstacle?

[Mikkel Fahnøe Jørgensen <[e-mail]>]

China blocks as a rule.
Russia is running an experiment to block the rest of the internet.
USA blocks net neutrality.
EU blocks cookies.
GB blocks itself.

So blocking is not limited to what an operator considers best for business.


On 10 April 2019 at 18.59.15, Border, John ([e-mail]) wrote:


I understand why people want to come down on the side of preventing
ossification. But, things have changed. There are a lot of more negative
consequences now when people unnecessarily block things. I think operators
would put a lot of pressure on vendors to not do it now and to fix it if
they did "by accident". Of course, I am only one operator. It would be nice
to hear from others...



John


-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Roberto Peon
Sent: Wednesday, April 10, 2019 12:52 PM
To: G Fairhurst <[e-mail]>; [e-mail]
Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?

WARNING: The sender of this email could not be validated and may not match
the person in the "From" field.

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know
the content is safe.


You're kinda between a rock-and-a-hard-place either way:

- We've seen how much fun ossification is in TCP and HTTP. If the thing is
observable, it will be ossified seems to be the lesson. A lot of the reason
why QUIC was started in the first place was because of the inability to
improve TCP due to this ossification.
- OTOH, there is the fear of unknown/unobservable which might cause
operators to block things, whether predictably or not.

My opinion is that it is better to start with preventing ossification, and
then if that results in too large a percentage of operators blocking
things, to re-evaluate.

My guesses:
IP+port tuples and traffic patterns are still observable (for better and
worse), which implies operators will still have significant tools for
managing traffic. I believe that these are acted on/matched (ML or not)
regardless of any other data presented. In other words, I have a doubt that
stating the version in an observable way will prevent the use of such
tools.

Most problems I've seen associated with implementations rather than
protocol versions (though when the latter happens it is pretty severe). If
you believe this assertion, then acting on protocol version is less
interesting than attempting to act based on implementation fingerprints.
-=R


On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" <[e-mail]
on behalf of [e-mail]> wrote:

Obscuring the version of a protocol seems like a major design design
decision for wider use cases. So, I'm trying to understand the
motivation for version greasing.

(1) I know there were instances where some early versions of QUIC were
blocked due to an uninitentional matching of the header. Is there
evidence of intentional attempts to block updates to protocols?

(2) Thinking about operating a network that cares about user support and
protection from unwanted traffic, I would expect that there would be
cases where traffic pattern anomolies are found and the appropriate
thing would be to try to determine if a new protocol had been deployed
and monitor it, if not, then the next most obvious thing could be to
block all unexpected traffic, that seems like a decision to hide the
version could increase ossification for new versions in these cases.

(3) Similarly, if a threat is known to impact only a specific (older)
version, it would seem to motivate a drop of that traffic that seeks to
use that version, while still permitting other traffic. Forcing version
detection to use pattern matching/ML will lead to less predictable
outcomes, or blocking based on address, etc.

(4) This obfusticates the most basic piece of reporting information used
for support. It hides the extent of deployment of the current protocol
version and prevlance of old implementations.

(5) On the support, if a problem only emerges when a particular version
is used with a particular address, then this helps pinpoint the issues.
Matching client versions to servers is much more of an issue if the user
community uses a wide range of servers (less so, I expect for major
providers: google, facebook, etc, etc), but significant when there is a
use of a diverse set of external sites and sites with their own load
balancers, etc and a need to manage interactions with L2 services.

I am intersted in knowing if this is likely to benefit or be a new
obstacle?

Gorry