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?
----------------------------------------------------------------------
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 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.
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.
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.
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.
Regards,
Charlie P.
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
