Re: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)

Magnus Westerlund <> Mon, 03 June 2019 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6164D120091; Mon, 3 Jun 2019 05:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AEl-WUtkgQZY; Mon, 3 Jun 2019 05:57:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06D38120004; Mon, 3 Jun 2019 05:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=agsSYIprJX4yDyJ87YfW0Aq5uX8W7jc7hz27oJYkKjI=; b=fUvQS4mBXgk4TLFGWGz0QLJlHyaE5sfxE4Y1ssvFy7ZeK1b9ybtDHeebeVXBWuRjieF9p+2P7JJtNlcDw/NJ5pZ8htlm1wjjSC8vWhSacGTnPiudR53Zu0h7TpWj7UtN2ZiRqzr2GpHrvbfSJ+5rH2sGOPKTWBRH8Kp+edm62io=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Mon, 3 Jun 2019 12:57:27 +0000
Received: from ([fe80::896a:7ada:8bc9:d99d]) by ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1965.011; Mon, 3 Jun 2019 12:57:27 +0000
From: Magnus Westerlund <>
To: Charlie Perkins <>, The IESG <>
CC: "" <>, Samita Chakrabarti <>, Shwetha Bhandari <>, "" <>, "" <>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
Thread-Index: AQHVCZGXI4nmwI6HcECbi1AilmPE5g==
Date: Mon, 3 Jun 2019 12:57:27 +0000
Message-ID: <>
References: <> <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 738b30bb-5b4e-4d19-59ed-08d6e8230831
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2524;
x-ms-traffictypediagnostic: HE1PR0701MB2524:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0057EE387C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39860400002)(136003)(396003)(376002)(189003)(199004)(43544003)(51444003)(86362001)(64756008)(66446008)(66556008)(33656002)(99286004)(66066001)(26005)(76116006)(66946007)(66476007)(73956011)(508600001)(71190400001)(71200400001)(14454004)(256004)(76176011)(74316002)(2906002)(102836004)(7696005)(14444005)(3846002)(6116002)(966005)(9686003)(4326008)(5660300002)(476003)(25786009)(7736002)(305945005)(52536014)(316002)(110136005)(6436002)(68736007)(6246003)(6306002)(186003)(53936002)(81166006)(6506007)(446003)(53546011)(54906003)(8936002)(8676002)(44832011)(229853002)(81156014)(486006)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2524;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: YdSAns4rsGIkl/ky5Remwtbf228RPu9MDhhl/x3+HQ718kM0+MHI1fsqF831EvB6eZ5er27SZg+G8jaSOojyldZIn4tG6+opEshJAPdAeGrNBOD/aj2XyMmIF4hqTIN9jULQAciNS8iSZpmIUryFQ6HOaqlcnUCO4Q9FhAu0QZBKS80Xpv5KIh692SxJeTes0hNDD4+VZOIxVWG7sLTQOTyFJ0Cg8CZQm0lm2eP6neAo4uv9ir+mGSN0CXFLNKi8cMERHryyJknBcEDgDMghZ9I0jrbmemb0Ig9zFwpR/8iq85vxEsMdX0cu9z/N9sxhjeWgWrZDTQNkJgKBeLS7xCt2rSJkoDliN54EXJft6qb08JKB7cf9OHy9aCY98i3ybYljXIBa1ah6c4QO66m4wYVDtQVBsEqEP58kd732JeA=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 738b30bb-5b4e-4d19-59ed-08d6e8230831
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2019 12:57:27.6433 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2524
Archived-At: <>
Subject: Re: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Jun 2019 12:57:35 -0000

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
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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.

>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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

>> 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
>> 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.


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: