Hi, I have cleared my discuss.
Cheers Magnus On Fri, 2019-08-30 at 23:13 +0530, Lijo Thomas wrote: > Hello Magnus: > > Please recall the Discuss in regard with our deadline-time draft and > we believe we addressed your comments in the current revision (05). > > It will be great if you could pass the Discuss positions in the > record, if the security concerns raised are addressed. > > The relevant text from security portion of 05 revision is below, for > your quick reference. > > << > > The protocol elements specified in this document are designed to > work > in controlled operational environments (e.g., industrial process > control and automation). In order to avoid misuse of the deadline > information that could potentially result in a Denial of Service > (DoS) attack, proper functioning of this deadline time mechanism > requires the provisioning and management of network resources for > supporting traffic flows with deadlines, performance monitoring, > and > admission control policy enforcement. The network provisioning > can > be done either centrally or in a distributed fashion. For > example, > tracks in a 6tisch network could be established by a centralized > PCE, > as described in the 6tisch architecture > [I-D.ietf-6tisch-architecture]. > > The Security Considerations of Detnet architecture > [I-D.ietf-detnet-architecture] mostly apply to this document as > well, > as follows. To secure the request and control of resources > allocated > for tracks, authentication and authorization can be used for each > device, and network controller devices. In the case of > distributed > control protocols, security is expected to be provided by the > security properties of the protocols in use. > > When deadline bearing flows are identified on a per-flow basis, > which > may provide attackers with additional information about the data > flows, when compared to networks that do not include per-flow > identification. The security implications of disclosing that > additional information deserve consideration when implementing > this > deadline specification. > > Because of the requirement of precise time synchronization, the > accuracy, availability, and integrity of time synchronization is > of > critical importance. Extensive discussion of this topic can be > found > in [RFC7384]. > > > > > Kindly let us know if your comments and valuable inputs. > > Thanks & Regards > Lijo Thomas > > > ------------------------------------------------------------------- > --------------------------- > > Subject: Re: [6lo] Magnus Westerlund's Discuss on draft-ietf- > 6lo-deadline-time-04: (with DISCUSS and COMMENT) > Date: Thu, 6 Jun 2019 09:46:17 +0530 > From: Lijo Thomas <[email protected]> > > To: 'Magnus Westerlund' <[email protected]> > > CC: [email protected] > > > > Hi Magnus, > > Thanks for the great response, we will update the draft accordingly. > > Thanks & Regards, > Lijo Thomas > -----Original Message----- > From: Magnus Westerlund <[email protected]> Sent: 05 > June 2019 17:23 > To: Lijo Thomas <[email protected]>; 'Charlie Perkins' > <[email protected]>; 'The IESG' <[email protected]> > Cc: [email protected]; 'Samita Chakrabarti' <[email protected] > >; > 'Shwetha Bhandari' <[email protected]>; [email protected]; > [email protected]; 'satish anamalamudi' < > [email protected]>; > [email protected] > Subject: Re: [6lo] Magnus Westerlund's Discuss on > draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT) > > Hi, > > Thanks for providing some background information. From my perspective > I > think there are some benefit to indicate the context the solution was > developed in. Note this is really comment level and not required. > > > > On 2019-06-05 07:54, Lijo Thomas wrote: > > Hi Magnus, > > Thanks for your detailed review and really appreciate your time taken > for the effort !!!!. > > Please find our below response for the frame work query addressed by > you. > > One of the main use cases of the draft is the industrial automation > and control applications. The end point of such applications puts the > deadline information as per its delay requirements. > I agree that the underlying 6Lo network needs to ensure that the > deadline is met using its delay sensitive routing and scheduling > mechanisms while forwarding the packet along the path. The 6Lo > network can support such a QoS requirement through end-to-end > provisioning of the required network resources either centrally > and/or in a distributed > fashion . > > > In the case of a 6tisch network, one could think of setting up tracks > [draft-ietf-6tisch-architecture] along with delay aware Scheduling > Function implemented by the intermediate nodes. The deadline draft > works well within the context of the framework described in the > draft-6tisch-architecture draft. The 6tisch architecture draft > defines tracks which could either be set up by a centralised entity > PCE or by setting up tracks in a distributed fashion by reserving > network resources that provide end-to-end delay guarantees. Packets > of application flows can be sent over these tracks and scheduled > based on their deadlines. The CAC can be exercised where reservation > fails for a new track setup. There are situations like asynchronous > time critical emergency messages where track set up delay is not > acceptable. In such cases, we can use distributed on-the-fly > scheduling using 6P protocol described in RFC 8480 that takes into > consideration the deadline information. > > There are several deadline based scheduling algorithms that have > proposed in the literature including the basic Earliest Deadline > First (EDF). Based on our deadline draft, we implemented this scheme > over a 6tisch network running on OpenWSN protocol stack and our draft > implementation has been merged with the OpenWSN environment for > future > downloads too. > > We would be happy to add some additional text specifying that ** a > network monitoring entity with call admission policy is expected to > be in place for observation and consequently better results during > real > implementations**. > > The proposed sentence appears problematic from two perspective. One > that it > might be an overly complex solution for certain closed systems. > Secondly, is it really "call admission" rather than flow admission? > > I think the right way forward here is that you document the security > issues > that anyone that intend to deploy this needs to consider. I think > that > discussion can discuss potential mitigations, but without specific > surround > contexts it is impossible to mandate any such. > > Cheers > > Magnus > > > > > Hope this address your few concerns and based on your response we > will update the draft. > > Happy to receive your further thoughts and valuable inputs. > > Thanks & Regards, > Lijo Thomas > > -----Original Message----- > From: 6lo <[email protected]> On Behalf Of Magnus Westerlund > Sent: 03 June 2019 18:27 > To: Charlie Perkins <[email protected]>; The IESG < > [email protected]> > Cc: [email protected]; [email protected]; > Samita Chakrabarti <[email protected]>; Shwetha Bhandari < > [email protected]>; [email protected] > Subject: Re: [6lo] Magnus Westerlund's Discuss on > draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT) > > Hi Charlie, > > Please see for further comments inline. > > On 2019-05-30 23:16, Charlie Perkins wrote: > > On 5/13/2019 6:41 AM, Magnus Westerlund via Datatracker wrote: > > Magnus Westerlund has entered the following ballot position for > draft-ietf-6lo-deadline-time-04: Discuss > > > > > -------------------------------------------------------------------- > - > - > DISCUSS: > -------------------------------------------------------------------- > - > - > > The security consideration section have significant short comings as > this mechanism enables multiple ways to attack both the packet and > the system to my understanding. I would appreaciate your > clarifications > on these matters. > > First of all by changing the dead-line so that it gets dropped > because it is already late, alternatively move the deadline time out > further in time (later), so that the forwarders may deliver it so > late that the receiver considers it to late. > Agreed that this vulnerability should be mentioned in the Security > Considerations. > > > > Secondly, there is the question if extensive use of this header will > cause overload or affect the scheduling of packet transmission affect > other traffic negatively. There appear to exist potential for new > ways of bad interflow interactions here. > If other packet transmissions have to be pre-empted in order for the > deadline to be met for a particular packet, then indeed this could > affect other traffic. It is also a matter of possible interest what > might happen if there were two packets in the transmission queue with > the same or different deadlines. However, the processing in these > cases is a local matter at each intermediate point, and out of scope > for > this > > draft. Does this also belong to be mentioned in the Security > Considerations? > Yes, I think so, as it points to a requirement to consider either > admission control or other solutions to keep the interaction on an > acceptable level. > > > > > > > -------------------------------------------------------------------- > - > - > COMMENT: > -------------------------------------------------------------------- > - > - > > Looking at this mechanism it appears to me as something that should > fit into a frame work, but that is not explicitly given. The main > reason I am raising that is that it appears to not care about a > number of interesting and challenging questions for a mechanism like > this. Questions that a particular framework can take care of, or > which any user of this mechanism would need to consider in their > deployment before they can determine if they can safely deploy it. It > might be that some of the questions have answers and I missed. In > that case please straighten me out. And if you have some additional > document that provides more detailed usage which discuss any of these > issues I would appreciate a pointer. > > This mechanism is a simple kind of signaling that could fit into > various frameworks, and exploring that space would be pretty > interesting. But it would represent a huge digression away from the > point of this draft, which all along was intended to offer a simple > mechanisms without getting involved with messy issues of policy. If > there is something missing in the basic mechanism, then that should > be fixed. But I don't see what is missing. Some of the discussion > below is also relevant to this point. > > So, there no specific first initial framework that this solution has > been developed to support? And you say you do not want to deal with > policy, and instead put that on the ones attempting to utilize it. > Considering the security issues, and the higher layer requirements > that this solution appears to create I think that is far from > optimal. I really think this document should have a section making > the assumptions about its expected deployments clear. > > > > > So quesitons that I got when reading this specification: > > 1. Are there any mechanism to provide feedback if the packets reach > the receiver in time? If the sender sets the deadline shorter than > the minimal one-way path delay, then all packets will be late. Will > any feedback be provided that this is happening? In cases D=1 this > appear to be a recipe for a black hole for the traffic. One can also > end up in situation where a large fraction of the packet are late. > This kind of signaling is far more appropriate at the application > level. To fully characterize the expected distribution of latency > values is out of scope for the draft, and the information needed > would usually depend on the application. Some applications don't care > much for dropped packets but don't want to handle packets coming in > too late. For other applications, knowing the distribution would > allow for setting a deadline that would usually all reception of 85% > of the packets (or some percentage predetermined by the application). > It's hard for me to see that as in scope for our draft. > > Sure, but the document could make it clear that there exist a need to > monitor the actual performance to know if the application will work > successful > > > > > > 2. Any mechanism that exist to determine what the expected latency > are from sender to receiver? > As above, I think this is most properly handled by the application > > > > 3. Are there any type of admittance or policy approval to use this > mechanism? > > The policy details are out of scope for this draft. However, it might > be worthwhile to mention that (similar to many QoS efforts) care must > be taken to avoid abuse. > > Please do. > > > > > 4. What is the relationship between traffic with a dead-line and > other traffic without a dead-line. Are traffic with a dead-line > implicitly allowed to pre-empt other traffic or at least to delay it > in > its queue? > > We don't specify that, and since it's a local matter at each node, a > mandate would be unenforceable. However, if it is important, we could > design an advisory extension to the draft for this purpose. The > problem is that the application should not necessarily need to be > involved with changing its behavior in response to (highly dynamic) > traffic conditions. > > Ok, I can agree that there is difficult to be descriptive here. As > long at the potential impact is a discussed security issue I think > this will be considered addressed. > > > 5. As Barry noted, what are the protection against missuse? > > These are issue that a framework or architecture would consider, I > note that > https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ > include some discussion of these topics. Still DETNET architecture > appear > more constrained when it comes to usage than what this mechanism > through its examples. > > I think it would be best to enlarge the discussion in the draft to > explain about the potential for abuse. I don't see just how the > simple mechanism at the level of 6LoRH should be charged with the > responsibility for an entire framework, and I really hope that simple > mechanisms such as this one can be found to have value even without > specification of a much larger set of protections and repairs. > > My questions where more coming from the aspect, how do you have been > part of developing this technical solution without having at least > one framework that addresses the raised issue? > > Thus, my preference that in the absence of a framework to point at, > that the assumptions on the hypothetical framework are documented. > > Cheers > > Magnus Westerlund > > ------------------------------------------------------------------- > --- > Network Architecture & Protocols, Ericsson Research > ------------------------------------------------------------------- > --- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: [email protected] > ------------------------------------------------------------------- > --- > > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo > > > ------------------------------------------------------------------- > --- > -------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and > destroy all copies and the original message. Any unauthorized review, > use, disclosure, dissemination, forwarding, printing or copying of > this email is strictly prohibited and appropriate legal action will > be > taken. > > ------------------------------------------------------------------- > --- > -------------------------------------- > > -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: [email protected] ----------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
