Christian,
I don’t think it’s necessary to have an exhaustive list of possible threats, I mean if network equipment or a network function is subverted, then most any protocol is subject to every kind of threat there is - confidential information can be disclosed, header fields can be modified, packets can be dropped, routing failures can occur, and so on. But you don’t see this level of analysis in most any other protocol spec coming out the IETF. Why is this one different? We already know that many bad things can happen as a result of subversion or tapping, I think the best advice we can give is “operationally avoid situations that would enable subversion or tapping." Your comment reminds me of a recent series of Dilbert cartoons, where a technical writer was assigned a project to list every possible warning for a new product. The warning document ended up 700 pages long and included items such as ‘Don’t start a fight with a rabid raccoon while using this product”.
Cheers,
Andy
On Fri, Sep 22, 2017 at 11:50 AM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
Christian, in terms of a Service Function sharing data with someone outside, I do not see how the NSH spec can talk about intended vs inadvertent sharing.
We do need to note that a subverted SF can make modifications or transmit information the specification and the operator do not intend. We are working to add that to the security considerations.
But that seems to be considerably less than you are asking for.
While we are going to add text to be more explicit about the weaknesses, I doubt very much it will rise to the level of a good quality threat analysis.
Yours,
Joel
On 9/21/17 12:53 AM, Christian Huitema wrote:
On 9/17/2017 5:04 AM, Joel M. Halpern wrote:
With regard to threats, a lot of the reason I have trouble with
providing good answers is that a service function that stores the
metadata for later analysis is perfectly legitimate. If the operator
contract with the SF provider is that the provider gets the metadata
the service function sees, that the operators chaice. Given that SFs
have to be able to get at whatever metadata they need, the protocol
can not inherently prevent that. People have suggested in
Internet-Drafts mechanisms whereby the SFF trim and restore the
metadata sets. that does not actually rpevent this, it merely adds
the complication that the operator has to configure what is allowed
where. If their contract for a given SF says that it gets all the
metadata, it will get all the metadata.
The one piece we can do is that personally identifying metadata can be
obfuscated, preferably by indirection. We should however recognize
that the indirection will be known to the operator, and if they choose
to reveal it by other means we can not prevent that.
I think the security section should list the threats clearly before
proposing mitigations. If you don't do that, implementers typically
treat the mitigation advice as optional, something that some committee
stuck there and that can be ignored.
Your point about third party contractors receiving privacy sensitive
information is not new. Yes, there can be legitimate business reasons to
provide information to third parties. But this normally goes with
contractual obligations regarding the handling of the data, such as for
what purpose, how it is protected by the third party, for how long it is
kept, how and when it shall be deleted, and whether it can be provided
further. This means that when such information is transmitted, the
transmission should be deliberate rather than inadvertent. As in, if the
contract with a third party does not require sending an specific piece
of metadata, it should not be sent.
-- Christian Huitema