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

[Roberto Peon <[e-mail]>]

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