Attempting to unify the order of quoted messages (then bottom posting)... On Fri, Sep 22, 2017 at 01:37:17PM -0400, Andrew G. Malis wrote: > > On Fri, Sep 22, 2017 at 11:50 AM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> > wrote: > > > > 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 > >> > >> > >> > >> > > > 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 > > > > > 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”. Where did the conception of "exhaustive" come from? The request that I am seeing could be restated as a desire to address the chain of thought that a reader of the document might have, namely "you are telling me to apply (some of) these protections, and make a judgment about which measures are appropriate; what do I need to consider in order to make that judgment?". That is, in the -23 Security Considerations we have: % NSH is always encapsulated in a transport encapsulation protocol (as % detailed in Section 4 of this specification); and, therefore, when % required, existing security protocols that provide authenticity % (e.g., [RFC6071]) can be used. Similarly, if confidentiality is % required, existing encryption protocols can be used in conjunction % with the NSH encapsulation. How do I tell when authenticity protection is required? How do I know when confidentiality is required? Or later on, % In order to protect the metadata, an % operator can utilize the aforementioned mechanisms provided by the % transport encapsulation protocols including authenticity and/or % confidentiality. An operator MUST carefully select the transport % encapsulation/underlay services to ensure end-to-end security % services, when those are desired. % [...] % Further, as described % under the "SFC Encapsulation" area of the Security Considerations of % [RFC7665], operators can and should use indirect identification for % metadata deemed to be sensitive (such as personally identifying % information) significantly mitigating the risk of privacy violation. % In particular, subscriber identifying information should be handled % carefully, and in general should be obfuscated. % [...] % For those situations where % obfuscation is either inapplicable or judged to be insufficient, an % operator can also encrypt the metadata. When should I desire end-to-end security? How do I tell what metadata is sensitive? When is obfuscation insufficient? Anyone implementing this document would need to come up with answers to those questions, and one could argue that the IETF has a duty to help them decide what to consider during the course of answering those questions. So no, we do not need to say "don't start a fight with a rabid racoon, whether or not you're using this product", but we presumably had some sort of threat in mind when introducing the suggestions to require authenticity, or confidentiality, or obfuscation. Is it so hard to give a few examples of these threats that inspired the proposed mitigations? Let's give the reader a better understanding of why we think these mitgations might be necessary -- not an exhaustive one, but a few big-picture threats. So yes, that could be things like * consider what attackers could tap your data lines (read, or write), whether your organization as a whole has a hope of defending against such attackers, and what impact that attacker could have with the capability to read and/or write such data * consider what potential impact there is of a configuration error that causes encapsulated packets to erroneously leave the administrative domain and escape to an external network; what impact would an attacker able to read packets on that external network have? * consider what potential impact there is of a configuration error that causes perimeter best practices to not be enforced (including BCP 38); what potential impact is there of an attacker being able to inject spoofed packets in this scenario? * [other suggestions here] Clearly, for some implementors/deployments, it may be reasonable to decide that an attacker with this sort of capabilities would be able to harm the organization in boundless other ways, so there is no value in protecting this one channel. But I do not expect that to universally be the decision. At risk of repeating myself (and Christian) -- giving me a list of potential mitigations without letting me know what they are supposed to mitigate is just giving me half of the question, and asking me to come up with an answer. Why not give me the rest of the question I have to answer? -Ben