[ippm] Re: John Scudder's Discuss on draft-ietf-ippm-encrypted-pdmv2-09: (with DISCUSS and COMMENT)

["[e-mail]" <[e-mail]>]

John,
I am starting to address everyone's thoughts one by one.   So, there will be multiple emails but then we can keep each thought chain separate.
>From DISCUSS:
> I was surprised not to see any discussion of the global pointer in the privacy considerations. I didn’t see any helpful discussion > of deployment assumptions in the present document, but RFC 8250 says,
>   Advantages include:…

>  2. Ability to span organizational boundaries with consistent instrumentation.
> That implies to me that a given server might simultaneously be providing instrumentation to clients within different > organizations. A reasonable default assumption is that it’s inappropriate to leak information about one of these> clients to another. One might argue that even the metrics RFC 8250 exposes can leak some information to a savvy endpoint, > but the global pointer does so explicitly and by design: one client now gets to find out what the aggregate packet rate to other > clients is.
> It seems as though this deserves explicit treatment in the security and/or privacy considerations. Or of course if I’ve missed > something (e.g. this kind of data exposure between clients was always the expectation and everyone but me knows this) > please help me see that.
First:
>  2. Ability to span organizational boundaries with consistent instrumentation.
The key word here is "consistent".  The intent was that business partners who have performance problems in their connections between each other will be able to compare metrics.
This is not the same as saying that clients from different organizations will be using a shared server.  That is a different issue.  So, let's take that on.
Second:  
My thought on one client being able to see the aggregate number of packets sent by the server to all clients when using a server which serves multiple organizations is that, yes, this is an exposure but how one would use this in a way that is detrimental eludes me.
If a client knows how many packets her organization is sending and the number of global packets is larger than that, then she can possibly assume that there are other organizations on that server.  BUT not how many other organizations nor how many other clients.  Also not if the packets are TCP, UDP, ICMPv6 or anything else.  These packets may well be ND6 packets, depending on what the administrator has chosen to monitor with PDMv2.
By getting multiple values of the Global Counter at intervals, one could possibly deduce if there was some type of constant or consistent traffic but it would be a guess as to what that was.  Is it video?  Is it an FTP?
The idea of the counter was to enable the network performance analyst to "guess" at how busy the server was.   If the server response time is less than desirable and the Global Counter is increasing rapidly, then a conversation could be started with the manager of the server.  The idea of PDMv2 is to do quick triage, that is to allow an organization to know if the problem is more likely than not in the server / application component or the network.  I have been on calls with many people on them to try to solve just this particular issue on large production enterprise networks.   Once you can point people in one direction or another, then the teams for the server / network have many other fine-grained tools at their disposal.
For a hacker, there are better and easier ways to find actionable information.   This reminds me a bit about when I was using a shared hosting service to test IPv6 extension headers and we could see by doing a ping to ff02::1 (multicast all nodes) and a Wireshark packet trace, that ALL the other clients responded!   Then, we could actually tell WHO the clients were and their link local address and so forth.  (The hosting service has since disallowed response to FF02::1.)  
In my opinion, if you do a Wireshark packet trace at a coffee shop or on the airplane, there are many very interesting pieces of information you can get which are far more useful to a would-be hacker than the Global Counter.
The other thing is that your organization is using a shared service, the administrators of that organization's network know it is shared.  That is, it is not a shock that when you sign up for cloud hosting with a public provider, that other organizations also use that service.  A network administrator who wants all data and metrics to be completely private will not use a shared service.

Having said all this, we can certainly put some subset of the above as a guidance to the implementor in the draft to make it explicit that the value of the Global Counter can be seen by all users of the particular server.
Thoughts?
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
https://www.insidethestack.com
PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.org 

    On Monday, October 21, 2024 at 05:05:05 PM GMT+2, John Scudder via Datatracker <[e-mail]> wrote:  
 
 John Scudder has entered the following ballot position for
draft-ietf-ippm-encrypted-pdmv2-09: 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-ippm-encrypted-pdmv2/



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

Thanks for this document. I have one point I'd like to have a discussion about:

## DISCUSS

I was surprised not to see any discussion of the global pointer in the privacy
considerations. I didn’t see any helpful discussion of deployment assumptions
in the present document, but RFC 8250 says,

  Advantages include:
…
  2. Ability to span organizational boundaries with consistent
      instrumentation.

That implies to me that a given server might simultaneously be providing
instrumentation to clients within different organizations. A reasonable default
assumption is that it’s inappropriate to leak information about one of these
clients to another. One might argue that even the metrics RFC 8250 exposes can
leak some information to a savvy endpoint, but the global pointer does so
explicitly and by design: one client now gets to find out what the aggregate
packet rate to other clients is.

It seems as though this deserves explicit treatment in the security and/or
privacy considerations. Or of course if I’ve missed something (e.g. this kind
of data exposure between clients was always the expectation and everyone but me
knows this) please help me see that.


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

## COMMENT

### Global Pointer naming

I found the name “Global Pointer” curiously opaque. It’s not a pointer in any
conventional sense. I’m sure there’s some perfectly sensible historical reason
for this nomenclature, but if I were picking a name ab initio that wouldn’t be
it. “Global Packet Count” seems more descriptive, for instance.

### Section 6.4

      The basic mechanism is to encrypt the
  symmetric key with the public key by joining both yields.

I don’t understand what this means. In particular, “by joining both yields”
doesn’t make sense to me. If I remove those four words, the sentence scans
fine. Would it be reasonable to do that deletion?



_______________________________________________
ippm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]