> On 1 Jul 2020, at 01:11, Bernard Aboba via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Bernard Aboba > Review result: Ready with Issues > > Subject: Transport Directorate review of draft-ietf-mpls-sfl-framework > > Reviewer: Bernard Aboba > Review result: Ready with (Minor) Issues > Document: draft-ietf-mpls-sfl-framework-08 > Reviewer: Bernard Aboba > Review Date: 2020-06-30 > Intended Status: Informational > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@xxxxxxxx if you reply to or forward this review. > > Summary: > This document is ready for publication, but has some minor issues > that could be addressed. > > Comments: > The document is short and clearly written. While it references > the requirements in RFC 8372, it does not refer to them, so it's > hard to verify whether this document does address those > requirements (and how). > > Also, this document doesn't cover data collection or SFL allocation, > so there is quite a bit that is out of scope. This makes me wonder > whether an implementation of this specification could interoperate > with other implementations based solely on this specification. Dear Bernard The intent of this document is to set out the framework in which other specific documents, which describe specific protocol actions, act. There is a document in flight which describes the use of this method for OAM actions and a control plane. Both of this will be implementable specifications. This informational text is not intended to be directly implementable and needs other supporting text. > > Major Issues: > No major issues found > > Minor Issues: > > Section 6 Privacy Considerations > > Section 3 states: > > " There are many possible additional actions such as > the measurement of the number of received packets in a flow, > triggering IPFIX inspection, triggering other types of Deep Packet > Inspection, or identification of the packet source." > > [BA] Based on the above statements, it would seem that this specification > has potential uses (e.g. DPI) that have inherent privacy implications. > This seems to be worth mentioning. There is privacy text in the document. The scope of this protocol is a well managed and controlled network. If the operator were to do DPI to impose the SFL at ingress, there would be no need for them to telegraph this to the far end of the LSP when they could send that information from the ingress node. > > "Whilst the inclusion of the additional > granularity does allow greater insight into the flow characteristics > it does not specifically identify which node originated the packet > other than by inspection of the network at the point of ingress, or > inspection of the control protocol packets." > > [BA] By definition, flow identities provide insight into flow characteristics. > By correlating the flow identity with persistent identifiers such as MAC > addresses, the flow identity can be linked to a device or user > without needing to inspect the network at the point of ingress or to > inspect control protocol packets. So there can be an incremental privacy > impact, even if the flow identifier does not itself identify a > user. It is unlikely that the use of this protocol would be for anything other than exceptional actions such as instrumentation. The identifier space is too small for, for example, for every flow to be marked, so I don’t think the risk is significant. If you wanted to spy on packets, you would do better to correlate with the VPN or pseudowire identity rather than this. > > Section 7 Security Considerations > > "The issue noted in Section 6 is a security consideration." > > [BA] I don't think that the privacy issues described in Section 6 need necessarily be referenced > in the security considerations section. I think you can delete this sentence. > Yes I will remove that reference, several people have commented. Best regards Stewart > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
