From nobody Fri Jun 4 07:52:43 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5F53A14C3 for ; Fri, 4 Jun 2021 07:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dedqAMFLJcmv for ; Fri, 4 Jun 2021 07:52:35 -0700 (PDT)
Received: from mx0e-0020b901.pphosted.com (mx0e-0020b901.pphosted.com [67.231.147.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989273A14C0 for ; Fri, 4 Jun 2021 07:52:35 -0700 (PDT)
Received: from pps.filterd (m0196083.ppops.net [127.0.0.1]) by mx0e-0020b901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 154EiC1s016588; Fri, 4 Jun 2021 14:52:31 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=InSight1906; bh=Fpko5qm36HtRcJXvylhCH9/yuvgBfCqA1xKeTIVtV1Q=; b=X6X5SjmHTdvsKMwLOxLEmXZQu3BUxCH+fgWRCj1yC+PKayv3xtxhK930N5PgYmZAKM7T k8VllIU08uIoOMCSjjgiyQuZX+dPMJz2JsbpZXUi06aR9Q7LpT9UicIO6XqjpcopMTPX 2d7CdN7KoadDZvY7d++u33qVb0HYE7bkJ/Gl+qCGiGVbKDQUzTjC7dlpmKhPSSsm0P4K zPvb6L9ld7co/bhWTwnKhQ6KUZlRY5jGXvN6xraOr+q21Wb92lVGoJXk9hH4MeqX885h vEBO7grUBxyu5nVrRZqZJWwpnhms3xj2V7EPunarVVFqj8Y4ic2FTbgxfG66Rp6Jxzo0 RQ==
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.137.102]) by mx0e-0020b901.pphosted.com with ESMTP id 38ygm8gv0d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jun 2021 14:52:31 +0000
Received: from ap-embx16-sp10.RES.AD.JPL (ap-embx16-sp10.jpl.nasa.gov [128.149.137.83]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.5.4/Sentrion-MTA-4.5.4) with ESMTPS id 154EqXgf105565 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Fri, 4 Jun 2021 14:52:33 GMT
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.14; Fri, 4 Jun 2021 07:52:30 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.2176.014; Fri, 4 Jun 2021 07:52:30 -0700
From: "Burleigh, Scott C (US 312B)"
To: "Felix.Flentge@esa.int" , "dtn@ietf.org"
Thread-Topic: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
Thread-Index: AQHXTh79VyDWupmNv0ykyISSrzdx9qsEAXYg
Date: Fri, 4 Jun 2021 14:52:30 +0000
Message-ID:
References: <36198_1621587275_60A7754B_36198_1601_1_OF73EFFF9B.4F542D9B-ONC12586DC.001DD087-C12586DC.0030F0EA@esa.int>
In-Reply-To: <36198_1621587275_60A7754B_36198_1601_1_OF73EFFF9B.4F542D9B-ONC12586DC.001DD087-C12586DC.0030F0EA@esa.int>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: multipart/alternative; boundary="_000_f4f3e6fe71a24066bcd75b471d1e7903jplnasagov_"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp10.jpl.nasa.gov [128.149.137.83]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-GUID: HjVCW2WrhtdsOq9KUlDS3OKkCW03xWHf
X-Proofpoint-ORIG-GUID: HjVCW2WrhtdsOq9KUlDS3OKkCW03xWHf
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-04_08:2021-06-04, 2021-06-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 adultscore=0 spamscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106040111
Archived-At:
Subject: Re: [dtn] [EXTERNAL] draft-ietf-dtn-bibect-03 issues
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 04 Jun 2021 14:52:42 -0000
--_000_f4f3e6fe71a24066bcd75b471d1e7903jplnasagov_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Felix, thanks for these. I'm working on the next edition of this draft and=
have modified it per your points 1(b) and 2.
I think the language you object to in 1(a) is pretty close to correct, thou=
gh. "Instantiation" is the construction of the node's initial state. The =
state of the node might or might not reside in some genuinely non-volatile =
medium, such as disk storage. If it does, then restarting the node would m=
ean resuming operation of the node starting from its current state as retri=
eved from that non-volatile medium; in this case, the CTCs would be element=
s of node state and custodial transmission counting would correctly resume =
from the current value. If not - that is, if the node is truly re-instanti=
ated - then there is no way to retain the values of the CTCs from the momen=
t at which the node was stopped; the counts must be initialized to zero. D=
o you see an alternative?
Scott
From: dtn On Behalf Of Felix.Flentge@esa.int
Sent: Friday, May 21, 2021 1:55 AM
To: dtn@ietf.org
Subject: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
Hi,
I have spotted two issues in draft 3 of the Bundle-In-Bundle Encapsulation:
1) Custodial Transmission Count
The CTC is defined in 3.2 as:
1. A "custodial transmission count" (CTC). A CTC is a
monotonically increasing integer indicating the number of
custodial BPDUs that have been issued to this BIBE node by the
local node since instantiation of the local node.
a) To have the CTC as the number of BPDUs since the instantiation of the lo=
cal node might be problematic in cases where the local node is re-started b=
ecause the CTC is later used as 'Transmission ID' which should be unique ov=
er some time frame.
b) In the definition above, the CTC is defined per custodial node. However,=
later it is stated:
"The transmission ID for a BPDU for which custody transfer IS
requested SHALL be the current value of the local node's custodial
transmission count, plus 1."
To me, this seems to indicate a single CTC per local node.
Scott confirmed that the first interpretation is correct (one CTC per custo=
dial node), so this text should be updated. It may still make sense to requ=
ire increasing of the transmission id by 'plus 1' only as this allows more =
efficient custody signals.
2) Section 3.4 defines:
A "custody transfer status report" is a bundle status report with the "rep=
orting node attempted custody transfer" flag set to 1.
This flag and issuing this status report is described nowhere. I assume thi=
s section should be removed.
Regards,
Felix
_________________________________________
ESA - European Space Agency
Dr. Felix Flentge
Software Engineer, OPS-GSB
Ground Systems Engineering Department
Directorate of Operations
ESA - ESOC
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany
Phone: +49 6151 90 4075 | Email: Felix.Flentge@esa.int
This message is intended only for the recipient(s) named above. It may cont=
ain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemina=
tion is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies app=
ropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data=
Protection Officer (dpo@esa.int).
--_000_f4f3e6fe71a24066bcd75b471d1e7903jplnasagov_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Felix, thanks for these. I’m working on =
the next edition of this draft and have modified it per your points 1(b) an=
d 2.
I think the language you object to in 1(a) is pretty=
close to correct, though. “Instantiation” is the constru=
ction of the node’s initial state. The state of the node might =
or might not reside in some genuinely non-volatile medium, such
as disk storage. If it does, then restarting the node would mean res=
uming operation of the node starting from its current state as retrieved fr=
om that non-volatile medium; in this case, the CTCs would be elements of no=
de state and custodial transmission counting
would correctly resume from the current value. If not – that i=
s, if the node is truly re-instantiated – then there is no way to ret=
ain the values of the CTCs from the moment at which the node was stopped; t=
he counts must be initialized to zero. Do you see
an alternative?
Scott
From: dtn <dtn-bounces@ietf.org> On =
Behalf Of
Felix.Flentge@esa.int
Sent: Friday, May 21, 2021 1:55 AM
To: dtn@ietf.org
Subject: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues=
Hi,
I=
have spotted two issues in draft 3 of the Bundle-In-Bundle Encapsulation:<=
/span>
1=
) Custodial Transmission Count
T=
he CTC is defined in 3.2 as:
&=
nbsp; 1. A "custodial transmission count" (CTC). &nb=
sp;A CTC is a
&=
nbsp; monotonically increasing integer indicating the =
number of
&=
nbsp; custodial BPDUs that have been issued to this BI=
BE node by the
&=
nbsp; local node since instantiation of the local node=
.
a=
) To have the CTC as the number of BPDUs since the instantiation of the loc=
al node might be problematic in cases where the local node is re-started be=
cause the CTC is later used as 'Transmission
ID' which should be unique over some time frame.
b=
) In the definition above, the CTC is defined per custodial node. However, =
later it is stated:
&=
quot;The transmission ID for a BPDU for which custody transfer IS
&=
nbsp; requested SHALL be the current value of the local node's custod=
ial
&=
nbsp; transmission count, plus 1."
T=
o me, this seems to indicate a single CTC per local node.
S=
cott confirmed that the first interpretation is correct (one CTC per custod=
ial node), so this text should be updated. It may still make sense to requi=
re increasing of the transmission id by 'plus
1' only as this allows more efficient custody signals.
2=
) Section 3.4 defines:
A=
"custody transfer status report" is a bundle status report=
with the "reporting node attempted custody transfer" flag set to=
1.
T=
his flag and issuing this status report is described nowhere. I assume this=
section should be removed.
R=
egards,
F=
elix
_=
________________________________________
E=
SA - European Space Agency
D=
r. Felix Flentge
S=
oftware Engineer, OPS-GSB
G=
round Systems Engineering Department
D=
irectorate of Operations
E=
SA - ESOC
R=
obert-Bosch-Str.5, D-64293 Darmstadt, Germany
P=
hone: +49 6151 90 4075 | Email:
Felix.Flentge@esa.int
This message is intended only for the recipient(s) named above. It may=
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or diss=
emination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applie=
s appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA=
Data Protection Officer (dpo@esa.int).<=
o:p>
--_000_f4f3e6fe71a24066bcd75b471d1e7903jplnasagov_--
From nobody Mon Jun 7 08:47:16 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811853A1B1A for ; Mon, 7 Jun 2021 08:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5txQ3P0qH55 for ; Mon, 7 Jun 2021 08:47:10 -0700 (PDT)
Received: from mx0e-0020b901.pphosted.com (mx0e-0020b901.pphosted.com [67.231.147.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3983A1B0D for ; Mon, 7 Jun 2021 08:47:09 -0700 (PDT)
Received: from pps.filterd (m0196083.ppops.net [127.0.0.1]) by mx0e-0020b901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 157FeZSK020392; Mon, 7 Jun 2021 15:47:08 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=InSight1906; bh=y7mjbZibKjm3ZaEmHqMllTdkPZUDUR7z3et/lt6WhM8=; b=v6aSfBRfctmw96RfB3Hq8l8cTLuaRkuMlDE5nxGRhPVrJpbv4RM7pLpcu0lLBq3v5gwR GeO9kPCRjgE0dGZA1atX2zWCk/OhzmF4Q9dTDTBpsE5r4AbIQXz7hGTANhDMpXl3CSMd fRu2kHhyDAszD12JZ/gqDDd2EVfaP0zFG3dh78hcCx93dHc+owSP8CFaMCXIxoO8f8I8 ZhpgAu8Ijw2Kbn5XmRZEklsTfDuyNiHF0WbEY0OteDf/xPPBKXcd80uuLsNIi/CP50FG LLHK7dC1OQruUemixbkcznURuEYFgzno1ODZHG/Kqm170Z9VQMmUEScqnz3gTWDRtXmL TA==
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.137.103]) by mx0e-0020b901.pphosted.com with ESMTP id 391bnu9n6g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jun 2021 15:47:07 +0000
Received: from ap-embx16-sp60.RES.AD.JPL (ap-embx16-sp60.jpl.nasa.gov [128.149.137.141]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.5.4/Sentrion-MTA-4.5.4) with ESMTPS id 157FlIge136772 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Mon, 7 Jun 2021 15:47:19 GMT
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp60.RES.AD.JPL (2002:8095:898d::8095:898d) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.14; Mon, 7 Jun 2021 08:47:06 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.2176.014; Mon, 7 Jun 2021 08:47:06 -0700
From: "Burleigh, Scott C (US 312B)"
To: Brian Sipos , "dtn@ietf.org"
Thread-Topic: [Acme] WGLC for ACME DTN Node ID
Thread-Index: AQHXLT5BfSNCozHHr0WDM1PTxsWmz6qw8xdwgEeRm6CAEIe9MA==
Date: Mon, 7 Jun 2021 15:47:06 +0000
Message-ID: <58b31926b00b4bcdb290544f59462d39@jpl.nasa.gov>
References: ,
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: multipart/alternative; boundary="_000_58b31926b00b4bcdb290544f59462d39jplnasagov_"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp60.jpl.nasa.gov [128.149.137.141]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-ORIG-GUID: UWCIVHXjSI-zKDPGfqT7ziLKBMrNo9em
X-Proofpoint-GUID: UWCIVHXjSI-zKDPGfqT7ziLKBMrNo9em
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-07_11:2021-06-04, 2021-06-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 malwarescore=0 bulkscore=0 mlxlogscore=921 adultscore=0 spamscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106070112
Archived-At:
Subject: Re: [dtn] [Acme] WGLC for ACME DTN Node ID
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 07 Jun 2021 15:47:15 -0000
--_000_58b31926b00b4bcdb290544f59462d39jplnasagov_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Good catch, Brian. Just to clarify in my mind: are you proposing that IANA=
Considerations section of the BPv7 specification should be updated, or are=
you proposing that the new language in the ACME document would be sufficie=
nt to establish the mechanism for allocating new BPv7 administrative record=
types? If the latter would pass muster with IESG then I am certainly for =
it.
Scott
From: dtn On Behalf Of Brian Sipos
Sent: Monday, May 31, 2021 8:08 AM
To: dtn@ietf.org
Subject: [EXTERNAL] Re: [dtn] [Acme] WGLC for ACME DTN Node ID
All,
The ACME validation draft is progressing to the point of IESG review, and o=
ne remaining known issue is the mechanism of allocating new BPv7 administra=
tive record types. The BPbis document does not reference the pre-existing I=
ANA registry the same way it does for block types and flags. This is not an=
ACME-related issue but would apply to any other new administrative record =
type allocation (e.g., BIBE).
I have added text to pre-submission ACME document [1] in Section 6 requirem=
ents and Section 9.3 IANA considerations: updating BPbis to use the IANA re=
gistry explicitly and for the registry to indicate BP version for each allo=
cation.
This update also allocates values ">=3D 65536" as Reserved for Private or E=
xperimental Use; similar to how other registries have high-value allocation=
s for P/E use. This change would have no effect on BPv6 as the type codes f=
or v6 are limited to 4-bit values.
Any objections to the ACME document to including this text or to reserve ad=
min. record types for P/E use? It could just as well go into a separate doc=
ument, since BPbis is already in the editor queue, but that would require a=
whole other review process for this small update.
[1] https://briansipos.github.io/acme-dtnnodeid/draft-ietf-acme-dtnnodeid.h=
tml
--_000_58b31926b00b4bcdb290544f59462d39jplnasagov_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Good catch, Brian. Just to clarify in my mind:=
are you proposing that IANA Considerations section of the BPv7 specificati=
on should be updated, or are you proposing that the new language in the ACM=
E document would be sufficient to establish
the mechanism for allocating new BPv7 administrative record types? I=
f the latter would pass muster with IESG then I am certainly for it.=
o:p>
Scott
From: dtn <dtn-bounces@ietf.org> On =
Behalf Of
Brian Sipos
Sent: Monday, May 31, 2021 8:08 AM
To: dtn@ietf.org
Subject: [EXTERNAL] Re: [dtn] [Acme] WGLC for ACME DTN Node ID<=
/o:p>
The ACM=
E validation draft is progressing to the point of IESG review, and one rema=
ining known issue is the mechanism of allocating new BPv7 administrative re=
cord types. The BPbis document does
not reference the pre-existing IANA registry the same way it does for bloc=
k types and flags. This is not an ACME-related issue but would apply to any=
other new administrative record type allocation (e.g., BIBE).=
span>
I have =
added text to pre-submission ACME document [1] in Section 6 requiremen=
ts and Section 9.3 IANA considerations: updating BPbis to use the IANA regi=
stry explicitly and for the registry to indicate
BP version for each allocation.
This up=
date also allocates values ">=3D 65536" as Reserved for Privat=
e or Experimental Use; similar to how other registries have high-value allo=
cations for P/E use. This change would have no effect
on BPv6 as the type codes for v6 are limited to 4-bit values.=
span>
Any obj=
ections to the ACME document to including this text or to reserve admin. re=
cord types for P/E use? It could just as well go into a separate document, =
since BPbis is already in the editor
queue, but that would require a whole other review process for this small =
update.
--_000_58b31926b00b4bcdb290544f59462d39jplnasagov_--
From nobody Mon Jun 7 14:10:13 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AFA3A10E8 for ; Mon, 7 Jun 2021 14:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rkf-eng.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PyGVVZKAcCN for ; Mon, 7 Jun 2021 14:10:07 -0700 (PDT)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2076.outbound.protection.outlook.com [40.107.93.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C733A10E4 for ; Mon, 7 Jun 2021 14:10:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lO7UDW6KNb1XKEiSw95kizXWkmNt4OM9XVhRlh5dFNgX7l2rZevGqZPaa4QXAT8xOV/EmRIYqEKh8Q+uEH9qKv1BudFWkzcx2Tcik40iKwstm9megMhQyxWqmgKvYZnh+wgnwrh13M+pWQ3TmiRgwSB5NNqTaiyeMXiBdGLq6Fntwl2YJRLuQKni9IwixPjD9LRFjvYFQw589QRbTsFfrGOZMrj136IokJfCBUK6JddllpLDPd/qskdBgP1zADXgY3zm7oLadaknB1lBW0fZawa0OpidMeqT1ZmlobyzDX6zNXNQN0B0PTJ/r7FDLniIoCno/jQKXzexQ4+8wg5NRw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n9SLP4Ekuc7HrUbIdGkBf2aQ9KJOvB9YOTH2YXtlVtQ=; b=Nk+h0DLH/WZgJb4hqm8g01OUIltyZoqyM/44IED51MxTeFsubbDquBc6ZEJTIY0JnwtbbmRwC8DK5crBhoQIggWa0vYZmIlpnRAC3vuEcLLXLjCHbYze3wsatAvRAYna5BtXa8GUfsYoGyDu0wgnHFSpSlRilV2jsvoygFuKXmaz/utaqTpUnj6N6bvhzCUxVZcHjKVeAowrCcm5Vdgz4slRX+UoTPwxPjIaMEakU0W0jz9b/Rd8HCPRF7P4GxclCNCUCKat20GTqY6vOAGZtzellI2NjL6i2tT3VJg+Fco1V0ehsAQYvhj2rS0ci/U3DhJ9LS3+fvXDyJ9H9gZ5RQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rkf-eng.com; dmarc=pass action=none header.from=rkf-eng.com; dkim=pass header.d=rkf-eng.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkf-eng.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n9SLP4Ekuc7HrUbIdGkBf2aQ9KJOvB9YOTH2YXtlVtQ=; b=Vh/GbH6QNEI8xZCesUKgCmzqpkVvyR1+7aV3geMcU8DvXfrJgXnpOG2ErCMMTRQkoJEViM9yEo1jBMZMvEy2uJ5+hmLoXGEk/xFHdlkEJjhXgJiqFVQd3CYDCR0c71TXM4ShDS/MpRS8q3t4VSn+O4FKIHrirnJ4S3IjneIGRwA=
Received: from MN2PR13MB3567.namprd13.prod.outlook.com (2603:10b6:208:168::10) by BL0PR13MB4433.namprd13.prod.outlook.com (2603:10b6:208:1cf::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.12; Mon, 7 Jun 2021 21:10:04 +0000
Received: from MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::4079:9d97:ece0:c82]) by MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::4079:9d97:ece0:c82%5]) with mapi id 15.20.4219.019; Mon, 7 Jun 2021 21:10:03 +0000
From: Brian Sipos
To: "Burleigh, Scott C (US 312B)" , "dtn@ietf.org"
Thread-Topic: [Acme] WGLC for ACME DTN Node ID
Thread-Index: AQHXLT5BfSNCozHHr0WDM1PTxsWmz6qw8xdwgEeRm6CAEIe9MIAADxHz
Date: Mon, 7 Jun 2021 21:10:03 +0000
Message-ID:
References: , , <58b31926b00b4bcdb290544f59462d39@jpl.nasa.gov>
In-Reply-To: <58b31926b00b4bcdb290544f59462d39@jpl.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: jpl.nasa.gov; dkim=none (message not signed) header.d=none;jpl.nasa.gov; dmarc=none action=none header.from=rkf-eng.com;
x-originating-ip: [96.241.16.84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d2cddffd-fd28-42f8-889f-08d929f89e7a
x-ms-traffictypediagnostic: BL0PR13MB4433:
x-microsoft-antispam-prvs:
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VQUeMf2HvbHkLF7WKVuGWgKx/zF0yuWYFKNsuiwNG7wPtodOfU9wx/TFaloK3lusv1H8ariIUmW1pt0/m9KYaZUf+GcaqwomABkTIOKbKDvkcCX7xTBLVHCdfMLtCH4blKIKK+czW13UdQb6EVuc6vVjiXlRTr3BCPfZ6HSG5Kxd3y74Q+3RBFexXcQcfdaNqxmJ2oDlltQJBHjauKRgySPdJ75PIYyZsols6dTIOtbjLx6KO6uv8CyNtILZlUghDpNNsiQBZFP+bAQk4YiIpzQygKemsfTlI02LOW4cGx+gh1ucTrq6e8YIkHavP8A+OhGAS7IlD6BGMOoRkALXQKASyTg+0oktxRryJDMIGJsJlCBCbClm46oYOE2Wv3ODc0wiPOKy5gtz3urZ6mm105LbtPDvF8AANpi3omceLCmA0GTN9+8CEGYqjIe8CeLaEq6RYfIA9ub/zS0X/97mWKJr7RFwQVPIMYIAGz6X//kSh/FLxjc5BUmr35ydRSbwUzdRn4DMfUcBtrfIVP3IzdlBcSy2cqOX79gwI6E3mISUiiiPzNzcQ4Y8k0PKuJxRH6+VG+G7tF+Ad2Q0O8hbOjbRSQx91mrtcaofl/QfdGvAVXZ6q4KeolWsdhKClN+VH+0wTGHY0A6UoQdBG3yWmowi2GX2MVeloSKAljCsFqLCisF1fEUD+rcUrDpuVxf/y0516gwh8OoXSyjSGgwoeA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3567.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(376002)(346002)(39830400003)(9686003)(38100700002)(122000001)(55016002)(5660300002)(66946007)(52536014)(66446008)(64756008)(2906002)(66476007)(76116006)(71200400001)(86362001)(33656002)(83380400001)(7696005)(166002)(66556008)(53546011)(8936002)(316002)(110136005)(8676002)(26005)(966005)(186003)(478600001)(19627405001)(6506007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?cSqQL0f1XB3+PhBNRrVnltx8uH5Ux0CGC/9/jVXmtsSdymj6pPSdPPu9xO?= =?iso-8859-1?Q?hFSDpweSIHLhPVuXqAPOoI8Tj1G6mN9UvDW+y9Yc+Te8IZiiS38utF79IF?= =?iso-8859-1?Q?KCjqA3fkD33EMqV0VOMWrCjsaepQmJtJgm0t9Qwj4/FSsJV177LipzsXOV?= =?iso-8859-1?Q?tXrLOMstrr/PDKlKPDwZprmfUhIFBhLEDNgInWncvTxQKgEx7ySTBfehHr?= =?iso-8859-1?Q?4z+PepNZZ4unhA0nq3fFH3iXdlb8W/MlN0kqresnTsJ5AzNEKTVZPccBwQ?= =?iso-8859-1?Q?2rIvBtHl8gVzoTqqGND6XiMdlYOllnFaVDcFUOB1qdkix/Jc0PR0clc5c4?= =?iso-8859-1?Q?n4pZbFVa/sOItBY96YdBfHA9VxkIFPEQtRSjL9EHkFaU3VNmMbs9SCSpzS?= =?iso-8859-1?Q?F3YumDL4hHB3wSJwb8xUj+UkuLKDqeK0eSUYbj+3PBkxPrZYtsOfcYAqMa?= =?iso-8859-1?Q?frsKsXPDRltcCTCSuM9yoTMEL2WaE0NUrRZyOZJKNZK4zN1flkU4l10eJa?= =?iso-8859-1?Q?iBEPffEZinLtwBxJCfwj6FcUdAA5HBwiMuIOEH0Nf1h9ZxPZRIwVhzhpI8?= =?iso-8859-1?Q?Stlkm+aHclzoTXmw1/n7Be2ne6StWQDmIXFrqkf0yj1wuma7ekL5RGYMfj?= =?iso-8859-1?Q?j5mEXAvNviw0guJKjlhjMaKSBnd5M9GeKB5HPj0D1oqB4ArI+MfQ2C5rJi?= =?iso-8859-1?Q?8zPttVGZoTehOppeClSWhyU/zq5TuwbO+QgjPKDW9LcSoUUtuUr4sEcJio?= =?iso-8859-1?Q?nlHUbHmY/TRmZryryNTYKVaWi2ugccE4dsB6ugtKqCxa9IJ5u1K93cthQe?= =?iso-8859-1?Q?Kkj5fbePxFK5EpYo+E5SDtkHf9JqUb1ZmQexXuT3uYuKiDGJz1grWoSe/I?= =?iso-8859-1?Q?HrymC3q2ZD0E7jkeEvvOqpI9A9iX7c4aqVkMGnVNMTD78dhMbseLijtEBb?= =?iso-8859-1?Q?FXdSZF2n2K0jfARFwr8o11QAOIMq3j56beIpuDUTloQ1A3bZoo4Ni2ZcPK?= =?iso-8859-1?Q?OZomKzYFIX3zKyfdGLSkb1AK2WMo+3WwPyRUl7rHvtaAqyfkfaJMI48OSo?= =?iso-8859-1?Q?wwkNbZgTcKVaab163rldakknbD8XDfGVAZfZfLoN5kl7aDE5m8YUCBPD5q?= =?iso-8859-1?Q?/g0vTKrBMg2dxtlILP7Z1RO+1SLB3A4SEzxECnlNevhdPP9uQ40M40Ijuk?= =?iso-8859-1?Q?pNuWZJxeouT7W/XS2yDMQwXZf/+Dpsj6KRHsKK513Bh7v86TtG6sRv7VYf?= =?iso-8859-1?Q?hdfnzr+4sqODSHObH7HGAvuJ8h//qo5Ryv4zZl6wNCHkH2ZzBBjhYdouoY?= =?iso-8859-1?Q?IIRONC++p4bamz7BkNQBZarcmYTdTxK5ecZSLmO5+cTkPO4=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB35677DC10DD7316E73D181099F389MN2PR13MB3567namp_"
MIME-Version: 1.0
X-OriginatorOrg: rkf-eng.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3567.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d2cddffd-fd28-42f8-889f-08d929f89e7a
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2021 21:10:03.3726 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yC5wb8O3Ml4gK81EXEp9uRFRSemzybqcplYri7Fqr4e38+CCE8jc/f2Bleb5vF+CfO1e1N/Fu1Os2whWLxms9Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR13MB4433
Archived-At:
Subject: Re: [dtn] [Acme] WGLC for ACME DTN Node ID
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 07 Jun 2021 21:10:12 -0000
--_000_MN2PR13MB35677DC10DD7316E73D181099F389MN2PR13MB3567namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Scott,
I'm treating the BPbis document as finished and published, and its requirem=
ents are self-consistent so it's not really a modification of existing requ=
irements in that document. Really, it's just informing BP implementations t=
o "look here for type codes also". You can see this in the new Section 6 te=
xt in the ACME draft [1]. This can be word-smithed however is needed.
[1] https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-acme-dtnnodeid-04
________________________________
From: Burleigh, Scott C (US 312B)
Sent: Monday, June 7, 2021 11:47
To: Brian Sipos ; dtn@ietf.org
Subject: RE: [Acme] WGLC for ACME DTN Node ID
Good catch, Brian. Just to clarify in my mind: are you proposing that IANA=
Considerations section of the BPv7 specification should be updated, or are=
you proposing that the new language in the ACME document would be sufficie=
nt to establish the mechanism for allocating new BPv7 administrative record=
types? If the latter would pass muster with IESG then I am certainly for =
it.
Scott
From: dtn On Behalf Of Brian Sipos
Sent: Monday, May 31, 2021 8:08 AM
To: dtn@ietf.org
Subject: [EXTERNAL] Re: [dtn] [Acme] WGLC for ACME DTN Node ID
All,
The ACME validation draft is progressing to the point of IESG review, and o=
ne remaining known issue is the mechanism of allocating new BPv7 administra=
tive record types. The BPbis document does not reference the pre-existing I=
ANA registry the same way it does for block types and flags. This is not an=
ACME-related issue but would apply to any other new administrative record =
type allocation (e.g., BIBE).
I have added text to pre-submission ACME document [1] in Section 6 requirem=
ents and Section 9.3 IANA considerations: updating BPbis to use the IANA re=
gistry explicitly and for the registry to indicate BP version for each allo=
cation.
This update also allocates values ">=3D 65536" as Reserved for Private or E=
xperimental Use; similar to how other registries have high-value allocation=
s for P/E use. This change would have no effect on BPv6 as the type codes f=
or v6 are limited to 4-bit values.
Any objections to the ACME document to including this text or to reserve ad=
min. record types for P/E use? It could just as well go into a separate doc=
ument, since BPbis is already in the editor queue, but that would require a=
whole other review process for this small update.
[1] https://briansipos.github.io/acme-dtnnodeid/draft-ietf-acme-dtnnodeid.h=
tml
--_000_MN2PR13MB35677DC10DD7316E73D181099F389MN2PR13MB3567namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Scott,
I'm treating the BPbis document as finished and published, and its requirem=
ents are self-consistent so it's not really a modification of existing requ=
irements in that document. Really, it's just informing BP implementations t=
o "look here for type codes also".
You can see this in the new Section 6 text in the ACME draft [1]. This can=
be word-smithed however is needed.
From: Burleigh, Scott C (=
US 312B) <scott.c.burleigh@jpl.nasa.gov>
Sent: Monday, June 7, 2021 11:47
To: Brian Sipos <BSipos@rkf-eng.com>; dtn@ietf.org <dtn@iet=
f.org>
Subject: RE: [Acme] WGLC for ACME DTN Node ID
Good catch, Brian. Just to clarify in my mind: are you proposing that=
IANA Considerations section of the BPv7 specification should be updated, o=
r are you proposing that the new language in the ACME document would be suf=
ficient to establish the mechanism for
allocating new BPv7 administrative record types? If the latter would=
pass muster with IESG then I am certainly for it.
Scott
From: dtn <dtn-bounces@ietf.org> On Behalf Of Brian Sip=
os
Sent: Monday, May 31, 2021 8:08 AM
To: dtn@ietf.org
Subject: [EXTERNAL] Re: [dtn] [Acme] WGLC for ACME DTN Node ID
The ACME validation draft is =
progressing to the point of IESG review, and one remaining known issue is t=
he mechanism of allocating new BPv7 administrative record types. The BPbis =
document does not reference the pre-existing
IANA registry the same way it does for block types and flags. This is not =
an ACME-related issue but would apply to any other new administrative recor=
d type allocation (e.g., BIBE).
I have added text to pre-subm=
ission ACME document [1] in Section 6 requirements and Section 9.3 IAN=
A considerations: updating BPbis to use the IANA registry explicitly and fo=
r the registry to indicate BP version for
each allocation.
This update also allocates va=
lues ">=3D 65536" as Reserved for Private or Experimental Use;=
similar to how other registries have high-value allocations for P/E use.&n=
bsp;This change would have no effect on BPv6 as the type
codes for v6 are limited to 4-bit values.
Any objections to the ACME do=
cument to including this text or to reserve admin. record types for P/E use=
? It could just as well go into a separate document, since BPbis is already=
in the editor queue, but that would
require a whole other review process for this small update.
--_000_MN2PR13MB35677DC10DD7316E73D181099F389MN2PR13MB3567namp_--
From nobody Mon Jun 7 14:59:03 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E013A132C for ; Mon, 7 Jun 2021 14:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjhL7MU8dvkE for ; Mon, 7 Jun 2021 14:58:55 -0700 (PDT)
Received: from mx0f-0020b901.pphosted.com (mx0f-0020b901.pphosted.com [67.231.155.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF943A132A for ; Mon, 7 Jun 2021 14:58:55 -0700 (PDT)
Received: from pps.filterd (m0196084.ppops.net [127.0.0.1]) by mx0e-0020b901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 157LsDHq027128; Mon, 7 Jun 2021 21:58:52 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=InSight1906; bh=/K/v+fQkOXtwAs1aaw1/J/pez4pj4viwrXzjS5qyOi8=; b=lGHXKMnwsCnI75HflcgapdPAvWCzOg05Puc+lAAXKbFaOCgwHakHsoXGNgztYjvlhNFN Dr4AtN0r8yW+t+mwqyS+XZcwXvHOvTqJe5LBGeK3jxIHvGR86HiRwbJ6hOlsJ/3f+Pdt l+UrHYSBCCQMM2eJWXvXbxdah72COM+YgZA8PeElDUDIE1vaBxCKAFMJcVhio+btlmPL HClR7st19Hqtnax0DXZSrZHwA6WBGD7E7IaReXNOQ0FOg2UZrmE0fcXGyneoy82CIRGe bTxXl11iZy4yx7qUPt7Zg8IPLbHT/XRIualVYMylRcMT+uaxwwxy9j0KD0jwr4XWGn6R NQ==
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.137.102]) by mx0e-0020b901.pphosted.com with ESMTP id 391u4qr4ug-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jun 2021 21:58:52 +0000
Received: from ap-embx16-sp40.RES.AD.JPL (ap-embx16-sp40.jpl.nasa.gov [128.149.137.86]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.5.4/Sentrion-MTA-4.5.4) with ESMTPS id 157LwrKN068111 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Mon, 7 Jun 2021 21:58:53 GMT
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp40.RES.AD.JPL (2002:8095:8956::8095:8956) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.14; Mon, 7 Jun 2021 14:58:50 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.2176.014; Mon, 7 Jun 2021 14:58:50 -0700
From: "Burleigh, Scott C (US 312B)"
To: Brian Sipos , "dtn@ietf.org"
Thread-Topic: [Acme] WGLC for ACME DTN Node ID
Thread-Index: AQHXLT5BfSNCozHHr0WDM1PTxsWmz6qw8xdwgEeRm6CAEIe9MIAADxHzgABadtA=
Date: Mon, 7 Jun 2021 21:58:50 +0000
Message-ID: <1fa1467000d642b19d5a45bf1a89946a@jpl.nasa.gov>
References: , , <58b31926b00b4bcdb290544f59462d39@jpl.nasa.gov>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: multipart/alternative; boundary="_000_1fa1467000d642b19d5a45bf1a89946ajplnasagov_"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp40.jpl.nasa.gov [128.149.137.86]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-GUID: CjE5E-LxqO0pYaYFCD0VMpmY80Kq5sbg
X-Proofpoint-ORIG-GUID: CjE5E-LxqO0pYaYFCD0VMpmY80Kq5sbg
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-07_15:2021-06-04, 2021-06-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 malwarescore=0 spamscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106070147
Archived-At:
Subject: Re: [dtn] [Acme] WGLC for ACME DTN Node ID
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 07 Jun 2021 21:59:02 -0000
--_000_1fa1467000d642b19d5a45bf1a89946ajplnasagov_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Looks good to me.
Scott
From: Brian Sipos
Sent: Monday, June 7, 2021 2:10 PM
To: Burleigh, Scott C (US 312B) ; dtn@ietf.o=
rg
Subject: [EXTERNAL] Re: [Acme] WGLC for ACME DTN Node ID
Scott,
I'm treating the BPbis document as finished and published, and its requirem=
ents are self-consistent so it's not really a modification of existing requ=
irements in that document. Really, it's just informing BP implementations t=
o "look here for type codes also". You can see this in the new Section 6 te=
xt in the ACME draft [1]. This can be word-smithed however is needed.
[1] https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-acme-dtnnodeid-04
________________________________
From: Burleigh, Scott C (US 312B) >
Sent: Monday, June 7, 2021 11:47
To: Brian Sipos >; dtn@ietf.o=
rg >
Subject: RE: [Acme] WGLC for ACME DTN Node ID
Good catch, Brian. Just to clarify in my mind: are you proposing that IANA=
Considerations section of the BPv7 specification should be updated, or are=
you proposing that the new language in the ACME document would be sufficie=
nt to establish the mechanism for allocating new BPv7 administrative record=
types? If the latter would pass muster with IESG then I am certainly for =
it.
Scott
From: dtn > On Behalf Of =
Brian Sipos
Sent: Monday, May 31, 2021 8:08 AM
To: dtn@ietf.org
Subject: [EXTERNAL] Re: [dtn] [Acme] WGLC for ACME DTN Node ID
All,
The ACME validation draft is progressing to the point of IESG review, and o=
ne remaining known issue is the mechanism of allocating new BPv7 administra=
tive record types. The BPbis document does not reference the pre-existing I=
ANA registry the same way it does for block types and flags. This is not an=
ACME-related issue but would apply to any other new administrative record =
type allocation (e.g., BIBE).
I have added text to pre-submission ACME document [1] in Section 6 requirem=
ents and Section 9.3 IANA considerations: updating BPbis to use the IANA re=
gistry explicitly and for the registry to indicate BP version for each allo=
cation.
This update also allocates values ">=3D 65536" as Reserved for Private or E=
xperimental Use; similar to how other registries have high-value allocation=
s for P/E use. This change would have no effect on BPv6 as the type codes f=
or v6 are limited to 4-bit values.
Any objections to the ACME document to including this text or to reserve ad=
min. record types for P/E use? It could just as well go into a separate doc=
ument, since BPbis is already in the editor queue, but that would require a=
whole other review process for this small update.
[1] https://briansipos.github.io/acme-dtnnodeid/draft-ietf-acme-dtnnodeid.h=
tml
--_000_1fa1467000d642b19d5a45bf1a89946ajplnasagov_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Looks good to me.
Scott
From: Brian Sipos <BSipos@rkf-eng.com> =
Sent: Monday, June 7, 2021 2:10 PM
To: Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov>=
;; dtn@ietf.org
Subject: [EXTERNAL] Re: [Acme] WGLC for ACME DTN Node ID<=
/p>
I'm tre=
ating the BPbis document as finished and published, and its requirements ar=
e self-consistent so it's not really a modification of existing requirement=
s in that document. Really, it's just
informing BP implementations to "look here for type codes also".=
You can see this in the new Section 6 text in the ACME draft [1]. This can=
be word-smithed however is needed.
Good catch, Brian. Just to clarify in my mind=
: are you proposing that IANA Considerations section of the BPv7 specificat=
ion should be updated, or are you proposing that the new language in the AC=
ME document would be sufficient to establish
the mechanism for allocating new BPv7 administrative record types? I=
f the latter would pass muster with IESG then I am certainly for it.=
o:p>
Scott
From: dtn <dtn-bounces@ietf.org>
On Behalf Of Brian Sipos
Sent: Monday, May 31, 2021 8:08 AM
To: dtn@ietf.org
Subject: [EXTERNAL] Re: [dtn] [Acme] WGLC for ACME DTN Node ID<=
/o:p>
The AC=
ME validation draft is progressing to the point of IESG review, and one rem=
aining known issue is the mechanism of allocating new BPv7 administrative r=
ecord types. The BPbis document does
not reference the pre-existing IANA registry the same way it does for bloc=
k types and flags. This is not an ACME-related issue but would apply to any=
other new administrative record type allocation (e.g., BIBE).<=
/o:p>
I have=
added text to pre-submission ACME document [1] in Section 6 requireme=
nts and Section 9.3 IANA considerations: updating BPbis to use the IANA reg=
istry explicitly and for the registry to
indicate BP version for each allocation.
This u=
pdate also allocates values ">=3D 65536" as Reserved for Priva=
te or Experimental Use; similar to how other registries have high-value all=
ocations for P/E use. This change would have no effect
on BPv6 as the type codes for v6 are limited to 4-bit values.<=
/o:p>
Any ob=
jections to the ACME document to including this text or to reserve admin. r=
ecord types for P/E use? It could just as well go into a separate document,=
since BPbis is already in the editor
queue, but that would require a whole other review process for this small =
update.
--_000_1fa1467000d642b19d5a45bf1a89946ajplnasagov_--
From nobody Tue Jun 8 01:07:34 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CFB3A272B for ; Tue, 8 Jun 2021 01:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu7djgxXoRTY for ; Tue, 8 Jun 2021 01:07:28 -0700 (PDT)
Received: from esrutmmgwext.esa.int (esrutmmgwext.esa.int [131.176.154.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11323A2728 for ; Tue, 8 Jun 2021 01:07:27 -0700 (PDT)
Received: from [172.18.96.7] (port=45470 helo=esrlnxmtaelb02.esrin.esa.int) by esrutmmgwext.esa.int with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1lqWlb-0005Su-20 for dtn@ietf.org; Tue, 08 Jun 2021 10:07:19 +0200
Received: from esrlnxsemxgwn01.esrin.esa.int (esrlnxmtaelb01-mgt.esrin.esa.int [172.18.28.24]) by esrlnxmtaelb02.esrin.esa.int (Postfix) with ESMTP id 8B00030A8FFC for ; Tue, 8 Jun 2021 10:07:19 +0200 (CEST)
Received: from esrlnxsemxgwn01.esrin.esa.int (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 66A6A801DC for ; Tue, 8 Jun 2021 10:07:19 +0200 (CEST)
Received: from esclnxsimxgwn01.esoc.esa.int (esclnxmtaelb01-dmz.esoc.esa.int [172.18.144.7]) by esrlnxsemxgwn01.esrin.esa.int (Postfix) with ESMTP id 0F2E280233 for ; Tue, 8 Jun 2021 10:07:19 +0200 (CEST)
Received: from esclnxsimxgwn01.esoc.esa.int (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C842180064 for ; Tue, 8 Jun 2021 10:07:18 +0200 (CEST)
Received: from PMSGIMTA1A.esa-ad.esa.int (unknown [10.17.12.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by esclnxsimxgwn01.esoc.esa.int (Postfix) with ESMTPS id 642A080061 for ; Tue, 8 Jun 2021 10:07:18 +0200 (CEST)
X-CTCH-RefID: str=0001.0A782F1F.60BF2537.00AA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
In-Reply-To:
References: <36198_1621587275_60A7754B_36198_1601_1_OF73EFFF9B.4F542D9B-ONC12586DC.001DD087-C12586DC.0030F0EA@esa.int>
To: "Burleigh, Scott C (US 312B)"
Cc: "dtn@ietf.org"
MIME-Version: 1.0
X-KeepSent: 1BAFD40D:088B02BC-C12586EE:00229940; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP10 SHF380 June 07, 2019
From: Felix.Flentge@esa.int
X-MIMETrack: S/MIME Sign by NLNOTES.EXE on Felix Flentge/esoc/ESA(Release 9.0.1FP10 SHF380|June 07, 2019) at 08/06/2021 10:07:13, Serialize by NLNOTES.EXE on Felix Flentge/esoc/ESA(Release 9.0.1FP10 SHF380|June 07, 2019) at 08/06/2021 10:07:13, Serialize complete at 08/06/2021 10:07:13, Itemize by NLNOTES.EXE on Felix Flentge/esoc/ESA(Release 9.0.1FP10 SHF380|June 07, 2019) at 08/06/2021 10:07:13, S/MIME Sign failed at 08/06/2021 10:07:13: Senders' signing certificate is expired, S/MIME Sign by ntaskldr.EXE on Felix Flentge/esoc/ESA(Release 9.0.1FP10 SHF380|June 07, 2019) at 08/06/2021 10:07:16, S/MIME Sign complete at 08/06/2021 10:07:16, Serialize by Router on smtpmta1a/esrin/ESA at 06/08/2021 10:07:18 AM, Serialize complete at 06/08/2021 10:07:18 AM
Message-ID:
Date: Tue, 8 Jun 2021 10:07:16 +0200
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z29138_boundary_sign
Archived-At:
Subject: Re: [dtn] [EXTERNAL] draft-ietf-dtn-bibect-03 issues
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 08 Jun 2021 08:07:33 -0000
This is an S/MIME signed message.
---------z29138_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 002C9B3FC12586EE_="
This is a multipart message in MIME format.
--=_alternative 002C9B3FC12586EE_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Scott, two thoughts on this:
1) Actually, the term "instantiation" might not be precise enough. I have=20
checked the BPv7 specification and found:
In the most familiar case, a bundle node is instantiated as a single
process running on a general-purpose computer, but in general the
definition is meant to be broader: a bundle node might alternatively
be a thread, an object in an object-oriented operating system, a
special-purpose hardware device, etc.
>From that I understood "instantiation" as "creation of an instance of a=20
process/thread/object/etc".=20
So, restarting a bundle node process would count as 'instantiation of the=20
local node' (a new process is created) and I would have to reset the CTC=20
to zero.=20
2) If we cannot resume from the 'current value', re-starting from zero=20
might be the best option in most cases. However, there may be some cases=20
where we would like to initiatialise the CTC differently, eg:
- we can use DTN Time mod x in cases where we know to have low bundle=20
rates (ie less then 1 bundle/second)
- if we receive a custody signal for a bundle which we don't have in our=20
CTDB (because we reset to zero), we might want to set the CTC to the=20
largest Transmission ID in the scope of the report plus some offset
Maybe we should clearly separate between the CTC as a counter and the=20
Transmission ID. The Transmission ID shall be unique per destination node=20
for the lifetime of the encapsulating bundle (there are cases where this=20
cannot be guaranteed). I think we might not even have to require that it=20
is always increased by one. It's just that the whole custody signalling=20
would become less efficient. Also, I might jut want to maintain a single=20
transmission ID counter if I know I will be only communication to a single =
destination entity for some time and then to another one. So, these=20
entities might see 'gaps' in the Transmission IDs but that would be fine.
Felix
From: "Burleigh, Scott C (US 312B)"
To: "Felix.Flentge@esa.int" , "dtn@ietf.org"=20
Date: 04/06/2021 16:52
Subject: RE: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
Felix, thanks for these. I?m working on the next edition of this draft=20
and have modified it per your points 1(b) and 2.
=20
I think the language you object to in 1(a) is pretty close to correct,=20
though. ?Instantiation? is the construction of the node?s initial state.=20
The state of the node might or might not reside in some genuinely=20
non-volatile medium, such as disk storage. If it does, then restarting=20
the node would mean resuming operation of the node starting from its=20
current state as retrieved from that non-volatile medium; in this case,=20
the CTCs would be elements of node state and custodial transmission=20
counting would correctly resume from the current value. If not ? that is, =
if the node is truly re-instantiated ? then there is no way to retain the=20
values of the CTCs from the moment at which the node was stopped; the=20
counts must be initialized to zero. Do you see an alternative?
=20
Scott
=20
From: dtn On Behalf Of Felix.Flentge@esa.int
Sent: Friday, May 21, 2021 1:55 AM
To: dtn@ietf.org
Subject: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
=20
Hi,=20
I have spotted two issues in draft 3 of the Bundle-In-Bundle=20
Encapsulation:=20
1) Custodial Transmission Count=20
The CTC is defined in 3.2 as:=20
1. A "custodial transmission count" (CTC). A CTC is a=20
monotonically increasing integer indicating the number of=20
custodial BPDUs that have been issued to this BIBE node by the=20
local node since instantiation of the local node.=20
a) To have the CTC as the number of BPDUs since the instantiation of the=20
local node might be problematic in cases where the local node is=20
re-started because the CTC is later used as 'Transmission ID' which should =
be unique over some time frame.=20
b) In the definition above, the CTC is defined per custodial node.=20
However, later it is stated:=20
"The transmission ID for a BPDU for which custody transfer IS=20
requested SHALL be the current value of the local node's custodial=20
transmission count, plus 1."=20
To me, this seems to indicate a single CTC per local node.=20
Scott confirmed that the first interpretation is correct (one CTC per=20
custodial node), so this text should be updated. It may still make sense=20
to require increasing of the transmission id by 'plus 1' only as this=20
allows more efficient custody signals.=20
2) Section 3.4 defines:=20
A "custody transfer status report" is a bundle status report with the=20
"reporting node attempted custody transfer" flag set to 1.=20
This flag and issuing this status report is described nowhere. I assume=20
this section should be removed.=20
Regards,=20
Felix=20
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=20
ESA - European Space Agency=20
Dr. Felix Flentge=20
Software Engineer, OPS-GSB=20
Ground Systems Engineering Department=20
Directorate of Operations=20
ESA - ESOC=20
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany=20
Phone: +49 6151 90 4075 | Email: Felix.Flentge@esa.int
This message is intended only for the recipient(s) named above. It may=20
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or=20
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies=20
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA=20
Data Protection Officer (dpo@esa.int).
--=_alternative 002C9B3FC12586EE_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Scott, two thoughts
on this:
1) Actually, the
term "instantiation" might not be precise enough. I have checked
the BPv7 specification and found:
In the most familiar case, a bundle
node is instantiated as a single
process running on a general-purpose
computer, but in general the
definition is meant to be broader:
a bundle node might alternatively
be a thread, an object in an object=
-oriented
operating system, a
special-purpose hardware device,
etc.
From that I unde=
rstood
"instantiation" as "creation of an instance of a process/thr=
ead/object/etc".
So, restarting
a bundle node process would count as 'instantiation of the local node'
(a new process is created) and I would have to reset the CTC to zero.
2) If we cannot
resume from the 'current value', re-starting from zero might be the best
option in most cases. However, there may be some cases where we would like
to initiatialise the CTC differently, eg:
- we can use DTN
Time mod x in cases where we know to have low bundle rates (ie less then
1 bundle/second)
- if we receive
a custody signal for a bundle which we don't have in our CTDB (because
we reset to zero), we might want to set the CTC to the largest Transmission
ID in the scope of the report plus some offset
Maybe we should
clearly separate between the CTC as a counter and the Transmission ID.
The Transmission ID shall be unique per destination node for the lifetime
of the encapsulating bundle (there are cases where this cannot be guarantee=
d).
I think we might not even have to require that it is always increased by
one. It's just that the whole custody signalling would become less efficien=
t.
Also, I might jut want to maintain a single transmission ID counter if
I know I will be only communication to a single destination entity for
some time and then to another one. So, these entities might see 'gaps'
in the Transmission IDs but that would be fine.
Felix
Fro=
m:
"Burleigh,
Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To:
"Felix.Flentge@esa.int"
<Felix.Flentge@esa.int>, "dtn@ietf.org" <dtn@ietf.org>=
;
Dat=
e:
04/06/2021
16:52
Sub=
ject:
RE:
[EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
Felix,
thanks for these. I’m working on the next edition of this draft
and have modified it per your points 1(b) and 2.
I
think the language you object to in 1(a) is pretty close to correct, though.
“Instantiation” is the construction of the node’s i=
nitial state.
The state of the node might or might not reside in some genuinely
non-volatile medium, such as disk storage. If it does, then restarting
the node would mean resuming operation of the node starting from its current
state as retrieved from that non-volatile medium; in this case, the CTCs
would be elements of node state and custodial transmission counting would
correctly resume from the current value. If not – that is, if t=
he
node is truly re-instantiated – then there is no way to retain the va=
lues
of the CTCs from the moment at which the node was stopped; the counts must
be initialized to zero. Do you see an alternative?
Scott
From:
dtn <dtn-bounces@ietf.org> On Behalf Of Felix.Flentge@esa.int<=
b>
Sent: Friday, May 21, 2021 1:55 AM
To: dtn@ietf.org
Subject: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
Hi,
I have spotted two issues in draft 3 of the Bundle-In-Bundle Encapsulation:=
1) Custodial Transmission Count
The CTC is defined in 3.2 as:
1. A "custodial transmission count" (CTC). A
CTC is a =
monotonically increasing integer indicating
the number of
custodial BPDUs that have been issued to this
BIBE node by the
local node since instantiation of the local
node.
a) To have the CTC as the number of BPDUs since the instantiation of the
local node might be problematic in cases where the local node is re-started
because the CTC is later used as 'Transmission ID' which should be unique
over some time frame.
b) In the definition above, the CTC is defined per custodial node. However,
later it is stated:
"The transmission ID for a BPDU for which custody transfer IS
requested SHALL be the current value of the local node's custodial<=
/span>
transmission count, plus 1."
To me, this seems to indicate a single CTC per local node.
Scott confirmed that the first interpretation is correct (one CTC per custo=
dial
node), so this text should be updated. It may still make sense to require
increasing of the transmission id by 'plus 1' only as this allows more
efficient custody signals.
2) Section 3.4 defines:
A "custody transfer status report" is a bundle status report
with the "reporting node attempted custody transfer" flag set
to 1.
This flag and issuing this status report is described nowhere. I assume
this section should be removed.
Regards, =
Felix
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ESA - European Space Agency
Dr. Felix Flentge
Software Engineer, OPS-GSB
Ground Systems Engineering Department
Directorate of Operations
ESA - ESOC
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany
Phone: +49 6151 90 4075 | Email: Feli=
x.Flentge@esa.int
This
message is intended only for the recipient(s) named above. It may contain
proprietary information and/or
protected
content. Any unauthorised disclosure, use, retention or dissemination is
prohibited. If you have received
this
e-mail in error, please notify the sender immediately. ESA applies appropri=
ate
organisational measures to protect
personal
data, in case of data privacy queries, please contact the ESA Data Protecti=
on
Officer (dpo@esa.int).
--=_alternative 002C9B3FC12586EE_=--
---------z29138_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIIIkQIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCBd4w
ggXaMIIEwqADAgECAhEA7yS8rnSGxcJuvLNGO/sEMzANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMjAwNjAzMDAwMDAwWhcNMjEwNjAzMjM1
OTU5WjCBvjEOMAwGA1UEERMFNzU3MzgxHjAcBgNVBAoTFUV1cm9wZWFuIFNwYWNlIEFnZW5jeTEe
MBwGA1UECRMVOC0xMCwgUnVlIE1hcmlvIE5pa2lzMREwDwYDVQQIEwhDZWRleCAxNTEOMAwGA1UE
BxMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQDEw1GZWxpeCBGbGVudGdlMSQwIgYJKoZIhvcN
AQkBFhVmZWxpeC5mbGVudGdlQGVzYS5pbnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQC4aiejKeJAQjj2Zd4YXPklQ7HTPpt0ZNGFkdAFN/MQiF4kV+eUoUk5Zeqnr1h4eIXcIa67nCtF
4B7QdVMLsHrJQqyr78ouMXtinXLWiI3PnQmZKWw7sfuy5rX+4heVrZliE5BM7os8vVKnX7gxe0+5
yQOKUnVCYfiF8YTNfXY/bUiUR4im7IFMhZZJyIoMQS6aZzHB+qAAPpOg404st3jU3h+L475U70ov
9+eZjNrTVufmbACEBhtMlNh9yvAg3qvzG4NYHJAKGLMY8s9/NfnjNQ7Pp2KBB8deXhQ7ubodIR/D
cYM+5bAC6ieunzbZBMVNPPYnyUl4V8cwYnrZ0IEfAgMBAAGjggH2MIIB8jAfBgNVHSMEGDAWgBSC
r2yM+MX+lmF86B89K3FIXsSLwDAdBgNVHQ4EFgQUpNb1b35fLveNeuuV64TDjRPiqlYwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEAG
A1UdIAQ5MDcwNQYMKwYBBAGyMQECAQMFMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2VjdGlnby5j
b20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JT
QUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8w
fTBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0
aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au
Y29tb2RvY2EuY29tMEcGA1UdEQRAMD6gJQYKKwYBBAGCNxQCA6AXDBVmZWxpeC5mbGVudGdlQGVz
YS5pbnSBFWZlbGl4LmZsZW50Z2VAZXNhLmludDANBgkqhkiG9w0BAQsFAAOCAQEAlj03X/TuoXbS
9ciHASddlWjtLX9axv/wEJdZc3/10s59LOLWQwjUtX5f2vjYmgHb6h4OOwdjCloLfatnS77Ua5B5
EDjp+wUVueRu7FtcRYxHPxunyr9MUOTyE/MQCkB2CfnV/T2jmED5LbtQu4GGcHep2PhfLQDpZFe9
sIOQeXd3x9lqaU63Nka1RXeTJABwuXk/tojUGIs+cWXSuIVbPkCs42WJqxy3tN3AvS6i/dJnr/nu
giuiSu+LFvpUrjyud//TWh7CgNngKKPpygMBRAbR6G80xkvFyEk66S+U6HPdJoLOA/Z3AQFDE/JD
/r/oS3THUiHViLNJPZX99TnpkTGCAoowggKGAgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UE
CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
Q0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5k
IFNlY3VyZSBFbWFpbCBDQQIRAO8kvK50hsXCbryzRjv7BDMwDQYJYIZIAWUDBAIBBQCgga4wGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNjA4MDgwNzEzWjAvBgkq
hkiG9w0BCQQxIgQgQL0BQ22FZai7RPbniNRwKHNCstCn1FnPvTMYLI7nzHUwQwYJKoZIhvcNAQkP
MTYwNDAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAZhxtwIAhGSzxQDpgNWbX6vCzPLstUTEXtHSykvTCj9gFZ5sHjWwP
7wp+QdcduNN4ls6llmOrPSauGny5+A0yaq1gKclaj2A5mig2djdOM5XrQC4VF8upSaxy8yzKqugH
0IE1IFwL3mPzjsBqY5HjpPRLzdpJVVE2OEDrnn4QVt2oJX029Tp86anr0wQBSFtlcfM6PPvFo3mz
R5DnyUcEvjjRqMvmVWczIlM2iIG73dGZQ+noA/qWLvNAZ5bBkAfMdXwkKDz9/gzGXDdWF64DTg1f
BXSQrqCBEGqzotBiwQXux15MY+ft26xiXKw4/SPlZwksqBcgZE6OaMT6Gf2UewAAAAA=
---------z29138_boundary_sign--
From nobody Tue Jun 8 12:51:24 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835B63A3BB7 for ; Tue, 8 Jun 2021 12:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4iEwkRn9IsB for ; Tue, 8 Jun 2021 12:51:16 -0700 (PDT)
Received: from mx0e-0020b901.pphosted.com (mx0e-0020b901.pphosted.com [67.231.147.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DC33A3BB6 for ; Tue, 8 Jun 2021 12:51:16 -0700 (PDT)
Received: from pps.filterd (m0196083.ppops.net [127.0.0.1]) by mx0e-0020b901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 158Jig8t006863; Tue, 8 Jun 2021 19:51:12 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=InSight1906; bh=aoY9ZWloK0SPqjvSNtHSCuIDlBePxT+fRtox7q5ny4o=; b=C/gf1rskrzkq5y4fBCyO5P7BHkMAULxxptFcpIRzNTvEp151MTglSKbZIB3ldYu8uGQK 6ztK0EUtdMZ3LDm3/2WSkH+bFmsjQOLfhQEg2gxSbgq11t1BHmpGPRaEbQtX7hkB55iY 9GV/qRRdiM2fAzXcQ8X8w2A5lkqZ5YjJW8DT9sURbi+IUiq8Vr/NKbNk17cFfuu6dZmT H86JJzGZoXuUIFXrH7vKKfaELAveNNDqdMMqfVvxGSJyY1d/o82C4cKNmOAxqH9HG0Y3 O0mB6c3BoLiErVKlOpjBkDtmwFGN8U4epzUcKCzMUc0aPVIRs706ikxdg0W5hONLSOQa 4A==
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.137.102]) by mx0e-0020b901.pphosted.com with ESMTP id 392edgr5wx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jun 2021 19:51:11 +0000
Received: from ap-embx16-sp50.RES.AD.JPL (ap-embx16-sp50.jpl.nasa.gov [128.149.137.140]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.5.4/Sentrion-MTA-4.5.4) with ESMTPS id 158JpDrh101310 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Tue, 8 Jun 2021 19:51:13 GMT
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp50.RES.AD.JPL (2002:8095:898c::8095:898c) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.14; Tue, 8 Jun 2021 12:51:10 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.2176.014; Tue, 8 Jun 2021 12:51:10 -0700
From: "Burleigh, Scott C (US 312B)"
To: "Felix.Flentge@esa.int"
CC: "dtn@ietf.org"
Thread-Topic: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
Thread-Index: AQHXTh79VyDWupmNv0ykyISSrzdx9qsEAXYggAZSOwCAAEdfoA==
Date: Tue, 8 Jun 2021 19:51:10 +0000
Message-ID:
References: <36198_1621587275_60A7754B_36198_1601_1_OF73EFFF9B.4F542D9B-ONC12586DC.001DD087-C12586DC.0030F0EA@esa.int>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: multipart/alternative; boundary="_000_b2bd331c725f45a49319eadd9b302947jplnasagov_"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp50.jpl.nasa.gov [128.149.137.140]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-ORIG-GUID: cVO4EOsx6Swya05OrK7HcTZxj8KuSrEV
X-Proofpoint-GUID: cVO4EOsx6Swya05OrK7HcTZxj8KuSrEV
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-08_14:2021-06-04, 2021-06-08 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 mlxlogscore=999 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106080127
Archived-At:
Subject: Re: [dtn] [EXTERNAL] draft-ietf-dtn-bibect-03 issues
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 08 Jun 2021 19:51:23 -0000
--_000_b2bd331c725f45a49319eadd9b302947jplnasagov_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi, Felix. I will agree that there is some infelicity in language here, bu=
t the problem is the use of "instantiated" in the sentence you quote. A BP=
node is explicitly expected to be able to retain outbound protocol data un=
its in some sort of storage medium while awaiting a transmission opportunit=
y; these retained bundles are elements of the node's state. A BP implement=
ation that discarded all node state upon the termination of a single proces=
s or thread would be a fragile and generally useless implementation.
I think it would be more accurate to say that a bundle node is a data struc=
ture, instantiated within some storage medium, that is animated by the spaw=
ning of a process or group of processes, or a thread or group of threads, e=
tc. The temporary cessation of the node's active operation should not caus=
e the node's state to be discarded, and the subsequent re-animation of the =
node is very different from re-instantiation.
It's a little bit like a Starbucks franchise. A Starbucks might be instant=
iated as a store front, a kiosk, a lunch counter inside a bookstore, etc. =
When you instantiate your Starbucks, you sign a lease, purchase equipment a=
nd supplies, and hire staff. When you animate it, you invite customers and=
your staff begin taking and filling orders. At night you close - de-anima=
te - the shop: the lights are turned off and the staff go home. The next m=
orning the shop is re-animated, not re-instantiated.
So restarting a bundle node process might indeed be a re-instantiation of t=
hat node, resetting the CTC to zero, but such an implementation of BP might=
not attract many users.
Scott
From: Felix.Flentge@esa.int
Sent: Tuesday, June 8, 2021 1:07 AM
To: Burleigh, Scott C (US 312B)
Cc: dtn@ietf.org
Subject: RE: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
Scott, two thoughts on this:
1) Actually, the term "instantiation" might not be precise enough. I have c=
hecked the BPv7 specification and found:
In the most familiar case, a bundle node is instantiated as a single
process running on a general-purpose computer, but in general the
definition is meant to be broader: a bundle node might alternatively
be a thread, an object in an object-oriented operating system, a
special-purpose hardware device, etc.
>From that I understood "instantiation" as "creation of an instance of a pro=
cess/thread/object/etc".
So, restarting a bundle node process would count as 'instantiation of the l=
ocal node' (a new process is created) and I would have to reset the CTC to =
zero.
2) If we cannot resume from the 'current value', re-starting from zero migh=
t be the best option in most cases. However, there may be some cases where =
we would like to initiatialise the CTC differently, eg:
- we can use DTN Time mod x in cases where we know to have low bundle rates=
(ie less then 1 bundle/second)
- if we receive a custody signal for a bundle which we don't have in our CT=
DB (because we reset to zero), we might want to set the CTC to the largest =
Transmission ID in the scope of the report plus some offset
Maybe we should clearly separate between the CTC as a counter and the Trans=
mission ID. The Transmission ID shall be unique per destination node for th=
e lifetime of the encapsulating bundle (there are cases where this cannot b=
e guaranteed). I think we might not even have to require that it is always =
increased by one. It's just that the whole custody signalling would become =
less efficient. Also, I might jut want to maintain a single transmission ID=
counter if I know I will be only communication to a single destination ent=
ity for some time and then to another one. So, these entities might see 'ga=
ps' in the Transmission IDs but that would be fine.
Felix
From: "Burleigh, Scott C (US 312B)" >
To: "Felix.Flentge@esa.int" >, "dtn@ietf.org" >
Date: 04/06/2021 16:52
Subject: RE: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
________________________________
Felix, thanks for these. I'm working on the next edition of this draft and=
have modified it per your points 1(b) and 2.
I think the language you object to in 1(a) is pretty close to correct, thou=
gh. "Instantiation" is the construction of the node's initial state. The =
state of the node might or might not reside in some genuinely non-volatile =
medium, such as disk storage. If it does, then restarting the node would m=
ean resuming operation of the node starting from its current state as retri=
eved from that non-volatile medium; in this case, the CTCs would be element=
s of node state and custodial transmission counting would correctly resume =
from the current value. If not - that is, if the node is truly re-instanti=
ated - then there is no way to retain the values of the CTCs from the momen=
t at which the node was stopped; the counts must be initialized to zero. D=
o you see an alternative?
Scott
From: dtn > On Behalf Of =
Felix.Flentge@esa.int
Sent: Friday, May 21, 2021 1:55 AM
To: dtn@ietf.org
Subject: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
Hi,
I have spotted two issues in draft 3 of the Bundle-In-Bundle Encapsulation:
1) Custodial Transmission Count
The CTC is defined in 3.2 as:
1. A "custodial transmission count" (CTC). A CTC is a
monotonically increasing integer indicating the number of
custodial BPDUs that have been issued to this BIBE node by the
local node since instantiation of the local node.
a) To have the CTC as the number of BPDUs since the instantiation of the lo=
cal node might be problematic in cases where the local node is re-started b=
ecause the CTC is later used as 'Transmission ID' which should be unique ov=
er some time frame.
b) In the definition above, the CTC is defined per custodial node. However,=
later it is stated:
"The transmission ID for a BPDU for which custody transfer IS
requested SHALL be the current value of the local node's custodial
transmission count, plus 1."
To me, this seems to indicate a single CTC per local node.
Scott confirmed that the first interpretation is correct (one CTC per custo=
dial node), so this text should be updated. It may still make sense to requ=
ire increasing of the transmission id by 'plus 1' only as this allows more =
efficient custody signals.
2) Section 3.4 defines:
A "custody transfer status report" is a bundle status report with the "rep=
orting node attempted custody transfer" flag set to 1.
This flag and issuing this status report is described nowhere. I assume thi=
s section should be removed.
Regards,
Felix
_________________________________________
ESA - European Space Agency
Dr. Felix Flentge
Software Engineer, OPS-GSB
Ground Systems Engineering Department
Directorate of Operations
ESA - ESOC
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany
Phone: +49 6151 90 4075 | Email: Felix.Flentge@esa.int
This message is intended only for the recipient(s) named above. It may cont=
ain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemina=
tion is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies app=
ropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data=
Protection Officer (dpo@esa.int).
--_000_b2bd331c725f45a49319eadd9b302947jplnasagov_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi, Felix. I will agree that there is some inf=
elicity in language here, but the problem is the use of “instantiated=
” in the sentence you quote. A BP node is explicitly expected t=
o be able to retain outbound protocol data units in some
sort of storage medium while awaiting a transmission opportunity; these re=
tained bundles are elements of the node’s state. A BP implement=
ation that discarded all node state upon the termination of a single proces=
s or thread would be a fragile and generally
useless implementation.
I think it would be more accurate to say that a bund=
le node is a data structure, instantiated within some storage medium, that =
is animated by the spawning of a process or group of processes, or a thread=
or group of threads, etc. The temporary
cessation of the node’s active operation should not cause the node=
8217;s state to be discarded, and the subsequent re-animation of the node i=
s very different from re-instantiation.
It's a little bit like a Starbucks franchise. =
A Starbucks might be instantiated as a store front, a kiosk, a lunch counte=
r inside a bookstore, etc. When you instantiate your Starbucks, you s=
ign a lease, purchase equipment and supplies,
and hire staff. When you animate it, you invite customers and your s=
taff begin taking and filling orders. At night you close – de-a=
nimate – the shop: the lights are turned off and the staff go home.&n=
bsp; The next morning the shop is re-animated, not re-instantiated.
So restarting a bundle node process might indeed be =
a re-instantiation of that node, resetting the CTC to zero, but such an imp=
lementation of BP might not attract many users.
Scott
From: Felix.Flentge@esa.int <Felix.Flentge=
@esa.int>
Sent: Tuesday, June 8, 2021 1:07 AM
To: Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov>=
;
Cc: dtn@ietf.org
Subject: RE: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues=
o:p>
Scott, two thoughts on this:
1=
) Actually, the term "instantiation" might not be precise enough.=
I have checked the BPv7 specification and found:
In the most familiar case, a bundle no=
de is instantiated as a single
process running on a general-purpose c=
omputer, but in general the
definition is meant to be broader: a b=
undle node might alternatively
be a thread, an object in an object-or=
iented operating system, a
special-purpose hardware device, etc.<=
/span>
F=
rom that I understood "instantiation" as "creation of an ins=
tance of a process/thread/object/etc".
S=
o, restarting a bundle node process would count as 'instantiation of the lo=
cal node' (a new process is created) and I would have to reset the CTC to z=
ero.
2=
) If we cannot resume from the 'current value', re-starting from zero might=
be the best option in most cases. However, there may be some cases where w=
e would like to initiatialise the CTC differently,
eg:
-=
we can use DTN Time mod x in cases where we know to have low bundle rates =
(ie less then 1 bundle/second)
-=
if we receive a custody signal for a bundle which we don't have in our CTD=
B (because we reset to zero), we might want to set the CTC to the largest T=
ransmission ID in the scope of the report plus
some offset
M=
aybe we should clearly separate between the CTC as a counter and the Transm=
ission ID. The Transmission ID shall be unique per destination node for the=
lifetime of the encapsulating bundle (there
are cases where this cannot be guaranteed). I think we might not even have=
to require that it is always increased by one. It's just that the whole cu=
stody signalling would become less efficient. Also, I might jut want to mai=
ntain a single transmission ID counter
if I know I will be only communication to a single destination entity for =
some time and then to another one. So, these entities might see 'gaps' in t=
he Transmission IDs but that would be fine.
F=
elix
From: "Burleigh, Scott C (=
US 312B)" <scott.c=
.burleigh@jpl.nasa.gov>
To: "Felix.Flentge@esa.int" <Felix.Flentge@esa.int>,
"dtn@ietf.org" <dtn@ietf.org>
Date: 04/06/2021 16:52
Subject: RE: [EXTERNAL] [dtn] d=
raft-ietf-dtn-bibect-03 issues
Felix, thanks for these. I’m working on=
the next edition of this draft and have modified it per your points 1(b) a=
nd 2.
I think the language you object to in 1(a) is prett=
y close to correct, though. “Instantiation” is the constr=
uction of the node’s initial state. The state of the node might=
or might not reside in some genuinely non-volatile medium, such
as disk storage. If it does, then restarting the node would mean res=
uming operation of the node starting from its current state as retrieved fr=
om that non-volatile medium; in this case, the CTCs would be elements of no=
de state and custodial transmission counting
would correctly resume from the current value. If not – that i=
s, if the node is truly re-instantiated – then there is no way to ret=
ain the values of the CTCs from the moment at which the node was stopped; t=
he counts must be initialized to zero. Do you see
an alternative?
Scott
From: dtn <dtn-bounces@ietf.org>
On Behalf Of Felix.Flentge@=
esa.int
Sent: Friday, May 21, 2021 1:55 AM
To: dtn@ietf.org
Subject: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
Hi,
<=
br>
I have spotted two issues in draft 3 of the Bundle-In-Bundle Encapsulation:=
<=
br>
1) Custodial Transmission Count
<=
br>
The CTC is defined in 3.2 as:
<=
br>
1. A "custodial transmission count" (CTC). A =
CTC is a
monotonically increasing integer indicating the =
number of
custodial BPDUs that have been issued to this BI=
BE node by the
local node since instantiation of the local node=
.
<=
br>
a) To have the CTC as the number of BPDUs since the instantiation of the lo=
cal node might be problematic in cases where the local node is re-started b=
ecause the CTC is later used as 'Transmission ID' which should be unique ov=
er some time frame.
<=
br>
b) In the definition above, the CTC is defined per custodial node. However,=
later it is stated:
<=
br>
"The transmission ID for a BPDU for which custody transfer IS <=
span style=3D"font-size:10.0pt;font-family:"Arial",sans-serif">
requested SHALL be the current value of the local node's custodial=
span>
transmission count, plus 1."
<=
br>
To me, this seems to indicate a single CTC per local node.
<=
br>
Scott confirmed that the first interpretation is correct (one CTC per custo=
dial node), so this text should be updated. It may still make sense to requ=
ire increasing of the transmission id by 'plus 1' only as this allows more =
efficient custody signals.
<=
br>
2) Section 3.4 defines:
<=
br>
A "custody transfer status report" is a bundle status repor=
t with the "reporting node attempted custody transfer" flag set t=
o 1.
<=
br>
This flag and issuing this status report is described nowhere. I assume thi=
s section should be removed.
<=
br>
Regards,
Felix
<=
br>
_________________________________________
ESA - European Space Agency
Dr. Felix Flentge
Software Engineer, OPS-GSB
Ground Systems Engineering Department
Directorate of Operations
ESA - ESOC
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany
Phone: +49 6151 90 4075 | Email: Felix.Flentge@esa.int
This message is intended only for the recipient(s) named =
above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, rete=
ntion or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediatel=
y. ESA applies appropriate organisational measures to protect=
o:p>
personal data, in case of data privacy queries, please co=
ntact the ESA Data Protection Officer (dpo@esa.int).
--_000_b2bd331c725f45a49319eadd9b302947jplnasagov_--
From nobody Tue Jun 8 22:01:47 2021
Return-Path:
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 461943A0C64; Tue, 8 Jun 2021 22:01:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To:
Cc: dtn@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.31.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: dtn@ietf.org
Message-ID: <162321490520.15057.2814432045744390461@ietfa.amsl.com>
Date: Tue, 08 Jun 2021 22:01:45 -0700
Archived-At:
Subject: [dtn] I-D Action: draft-ietf-dtn-bpsec-default-sc-08.txt
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Jun 2021 05:01:45 -0000
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Delay/Disruption Tolerant Networking WG of the IETF.
Title : BPSec Default Security Contexts
Authors : Edward J. Birrane, III
Alex White
Sarah Heiner
Filename : draft-ietf-dtn-bpsec-default-sc-08.txt
Pages : 51
Date : 2021-06-08
Abstract:
This document defines default integrity and confidentiality security
contexts that can be used with the Bundle Protocol Security Protocol
(BPSec) implementations. These security contexts are intended to be
used for both testing the interoperability of BPSec implementations
and for providing basic security operations when no other security
contexts are defined or otherwise required for a network.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-default-sc-08
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dtn-bpsec-default-sc-08
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
From nobody Wed Jun 9 07:17:36 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0031A3A18CB; Wed, 9 Jun 2021 07:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.389
X-Spam-Level:
X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5noXct-7Jp7; Wed, 9 Jun 2021 07:17:21 -0700 (PDT)
Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FE43A18C9; Wed, 9 Jun 2021 07:17:12 -0700 (PDT)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.16.0.43/8.16.0.43) with SMTP id 159EGxlL071119; Wed, 9 Jun 2021 10:17:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=JHUAPLDec2018; bh=I3SYfSrYGk6Bi44IkVkyNJgh7hD7NkF/JZjcnbpy0bs=; b=pH4O5RhymB1CIOdGwJVrPSGgC9vlDGPag8f2yuLuGGc/NovA/JAK0Z681LLL+47UKhMy IBg3Z0ubAsdKHQ9M0oY9yeZH+jgrnF0Mmo6VC96vX2hDTJHurW5C+d1SeUeVqugqe/Mo ci8+RBy+CvYDHJvteKhXyMEjPzu6ur2GgxTFGrFnWhObCeH5qC96vftkFyFLFFBXaOyi sLiOaKyBKhQ+36aLPmQnKNRUG1ttt7j6L2+cZHXVD87rfg63YzyXZtVIKfv4bOzX7NUT MoG+VfZEfoce+w3SpzSNTEuySZQkE8gdSsaJIGXjew1VkO4XDNRaM3a9JbXPmDZBLL+w iw==
Received: from aplex02.dom1.jhuapl.edu (aplex02.dom1.jhuapl.edu [128.244.198.6]) by aplegw01.jhuapl.edu with ESMTP id 391y9a99cp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 10:17:09 -0400
X-CrossPremisesHeadersFilteredBySendConnector: aplex02.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by aplex02.dom1.jhuapl.edu (128.244.198.6) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 9 Jun 2021 10:17:08 -0400
Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1497.018; Wed, 9 Jun 2021 10:17:08 -0400
From: "Birrane, Edward J."
To: Christian Huitema , "secdir@ietf.org"
CC: "draft-ietf-dtn-bpsec-default-sc.all@ietf.org" , "dtn@ietf.org" , "last-call@ietf.org"
Thread-Topic: [EXT] Secdir last call review of draft-ietf-dtn-bpsec-default-sc-07
Thread-Index: AQHXU+6UBlgxk74+pESA6s7S8RVd1qsLxdJg
Date: Wed, 9 Jun 2021 14:17:08 +0000
Message-ID: <5c607c5d7cf64b998a8bd2e057770ca0@aplex01.dom1.jhuapl.edu>
References: <162222621650.3936.204909667434697510@ietfa.amsl.com>
In-Reply-To: <162222621650.3936.204909667434697510@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.244.198.168]
Content-Type: multipart/alternative; boundary="_000_5c607c5d7cf64b998a8bd2e057770ca0aplex01dom1jhuapledu_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: aplex02.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-09_04:2021-06-04, 2021-06-09 signatures=0
Archived-At:
Subject: Re: [dtn] [EXT] Secdir last call review of draft-ietf-dtn-bpsec-default-sc-07
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Jun 2021 14:17:27 -0000
--_000_5c607c5d7cf64b998a8bd2e057770ca0aplex01dom1jhuapledu_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Q2hyaXN0aWFuLA0KDQoNCg0KICBUaGFuayB5b3UgZm9yIHRoaXMgdXBkYXRlZCByZXZpZXcuDQoN
Cg0KDQogIEkgdW5kZXJzdGFuZCBhbmQgYWdyZWUgd2l0aCB5b3VyIGFkZGl0aW9uYWwgY29tbWVu
dHMgb24gQUVBRCBhbmQgaGF2ZSBwcm9kdWNlZCBhIC0wOCB3aGljaCBJIGhvcGUgY2xhcmlmaWVz
IG9wdGlvbnMgYXJvdW5kIHRoZSBoYW5kbGluZyBvZiB0aGUgYXV0aGVudGljYXRpb24gdGFnLg0K
DQoNCg0KICBUaHJlZSBxdWljayBvYnNlcnZhdGlvbnM6DQoNCg0KDQotICAgICAgICAgICBUaGUg
QkNCLUFFUy1HQ00gc2VjdXJpdHkgY29udGV4dCB3aWxsIGFsd2F5cyBiZSBkb2N1bWVudGVkIGZv
ciB0aGUgR0NNIG1vZGUgb2YgQUVTIHNvLCBhcyB5b3Ugc2F5LCBtYW5hZ2luZyB0aGlzIGNvbXBs
ZXhpdHkgZm9yIEFFUy1HQ00gaXMgd29ya2FibGUuIEJ1dCBhbHNvIGFncmVlIHRoYXQgZm9yIERU
TiBhdCBsYXJnZSwgYXMgd2Ugd29yayB0byBpbmNvcnBvcmF0ZSBuZXdlciBlbmNyeXB0aW9uIGFs
Z29yaXRobXMsIG5ldyBzZWN1cml0eSBjb250ZXh0IGRvY3VtZW50cyB3aWxsIGJlIHByb2R1Y2Vk
IGFuZCBhdXRoZW50aWNhdGlvbi9lbmNyeXB0aW9uIGNhbiBiZSBqb2luZWQgZm9yIHRob3NlIGRv
Y3VtZW50cyBhbmQgYWxnb3JpdGhtcyBpbiBhIGxlc3MgY29tcGxleCB3YXkuDQoNCg0KDQotICAg
ICAgICAgIFdlIGFyZSBzdGlsbCB3b3JraW5nIHdpdGggKHNvbWUpIGFlcy1nY20gbGlicmFyaWVz
IHdob3NlIEFQSXMgc2VwYXJhdGUgdGhlIGF1dGhlbnRpY2F0aW9uIHRhZy4gRm9yIGV4YW1wbGUs
IHRoZSBtYmVkdGxzIChodHRwczovL3d3dy50cnVzdGVkZmlybXdhcmUub3JnL3Byb2plY3RzL21i
ZWQtdGxzLykgQVBJIHVzZXMgdGhlIGZ1bmN0aW9uICBtYmVkdGxzX2djbV9jcnlwdF9hbmRfdGFn
IHdoaWNoIHRha2VzIHRoZSB0YWcgc2VwYXJhdGVseSBmcm9tIHRoZSBjaXBoZXIgdGV4dC4gIEZv
ciBpbnRlcm9wZXJhYmlsaXR5LCBwdWxsaW5nIHRoZSB0YWcgaW50byBhIHNlY3VyaXR5IHJlc3Vs
dCBpcyBoZWxwZnVsLiBJZiBhIHNlY3VyaXR5IHNvdXJjZSB3ZXJlIHRvIHByb2R1Y2UgYSBibG9i
IHRoYXQgcmVwcmVzZW50ZWQgYW4gdW5rbm93biBvcmRlcmluZyBvZiBjaXBoZXIgdGV4dCBhbmQg
YXV0aGVudGljYXRpb24gdGFnLCB0aGVuIGEgc2VjdXJpdHkgZGVzdGluYXRpb24gdXNpbmcgbWJl
ZHRscyB3b3VsZCBub3QgbmVjZXNzYXJpbHkga25vdyB3aGVyZSBpbiB0aGF0IGJsb2IgdG8gcHVs
bCB0aGUgdGFnIHdoZW4gY29uc3RydWN0aW5nIHRoZSBjYWxsIHRvIG1iZWR0bHNfZ2NtX2NyeXB0
X2FuZF90YWcuIFByZWZlcnJpbmcgdG8gZXh0cmFjdCB0aGUgdGFnIGlzIGNsZWFybHkgbW9yZSBj
b21wbGV4aXR5IGJ1dCBpdCBhbHNvIG1heSBiZSBoZWxwZnVsIHdoZW4gd29ya2luZyBpbiBuZXR3
b3JrcyB0aGF0IGhhdmUgZGVwbG95ZWQgZGlmZmVyZW50IEFFUy1HQ00gaW1wbGVtZW50YXRpb25z
IGF0IGRpZmZlcmVudCBub2Rlcy4NCg0KDQoNCi0gICAgICAgICAgVGhlcmUgaGFzIGJlZW4gc29t
ZSBkaXNjdXNzaW9uIHdoZXJlIGhhdmluZyBjZXJ0YWluIGV4dGVuc2lvbiBibG9ja3MgYmUgZml4
ZWQtc2l6ZSB3b3VsZCBoZWxwIHdpdGggcHJvY2Vzc2luZywgd2hpY2ggaXMgd2hhdCBtYWRlIHRo
ZSBBRVMtR0NNIGNpcGhlciBzdWl0ZSBhdHRyYWN0aXZlIHRvIHRob3NlIHVzZXMuIEtlZXBpbmcg
dGhlIHRhZyBzZXBhcmF0ZSBpcyBhIHdheSB0byBwcmVzZXJ2ZSB0aGF0IGxlbmd0aCBjb25zdHJh
aW50IGluIHRoZSBmZXcgY2FzZXMgd2hlcmUgdGhhdCBpcyBoZWxwZnVsLg0KDQoNCg0KICBBZ2Fp
biwgdGhhbmsgeW91IGZvciB5b3VyIHRpbWU7IHRoZXNlIHJldmlld3MgaGF2ZSBtYWRlIHRoZSBk
ZWZhdWx0IHNlY3VyaXR5IGNvbnRleHQgZG9jdW1lbnQgbXVjaCBtb3JlIGNvbXBsZXRlIGFuZCB1
c2VmdWwuDQoNCg0KDQotRWQNCg0KDQoNCi0tLQ0KDQpFZHdhcmQgSi4gQmlycmFuZSwgSUlJLCBQ
aC5ELg0KDQpFbWJlZGRlZCBBcHBsaWNhdGlvbnMgR3JvdXAgU3VwZXJ2aXNvcg0KDQpTcGFjZSBF
eHBsb3JhdGlvbiBTZWN0b3INCg0KSm9obnMgSG9wa2lucyBBcHBsaWVkIFBoeXNpY3MgTGFib3Jh
dG9yeQ0KDQooVykgNDQzLTc3OC03NDIzIC8gKEYpIDQ0My0yMjgtMzgzOQ0KDQoNCg0KDQoNCg0K
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogQ2hyaXN0aWFuIEh1aXRl
bWEgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPg0KDQo+IFNlbnQ6IEZyaWRheSwg
TWF5IDI4LCAyMDIxIDI6MjQgUE0NCg0KPiBUbzogc2VjZGlyQGlldGYub3JnDQoNCj4gQ2M6IGRy
YWZ0LWlldGYtZHRuLWJwc2VjLWRlZmF1bHQtc2MuYWxsQGlldGYub3JnOyBkdG5AaWV0Zi5vcmc7
IGxhc3QtDQoNCj4gY2FsbEBpZXRmLm9yZw0KDQo+IFN1YmplY3Q6IFtFWFRdIFNlY2RpciBsYXN0
IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZHRuLWJwc2VjLWRlZmF1bHQtc2MtMDcNCg0KPg0K
DQo+IEFQTCBleHRlcm5hbCBlbWFpbCB3YXJuaW5nOiBWZXJpZnkgc2VuZGVyIG5vcmVwbHlAaWV0
Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+IGJlZm9yZSBjbGlja2luZw0KDQo+IGxpbmtz
IG9yIGF0dGFjaG1lbnRzDQoNCj4NCg0KPiBSZXZpZXdlcjogQ2hyaXN0aWFuIEh1aXRlbWENCg0K
PiBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQo+DQoNCj4gSSByZXZpZXdlZCBkcmFmdC1pZXRmLWR0
bi1icHNlYy1kZWZhdWx0LXNjLTAyIGFzIHBhcnQgb2YgYW4gZWFybHkgc2VjdXJpdHkNCg0KPiBy
ZXZpZXcgcmVxdWVzdGVkIGJ5IHRoZSB0cmFuc3BvcnQgQUQuIFRoaXMgaXMgdGhlIGZvbGxvdy11
cCBsYXN0IGNhbGwgcmV2aWV3IG9mDQoNCj4gZHJhZnQtaWV0Zi1kdG4tYnBzZWMtZGVmYXVsdC1z
Yy0wNy4NCg0KPg0KDQo+IFRoZSBkcmFmdCBpcyByZWFkeSwgYWx0aG91Z2ggSSB3b3VsZCBwcmVm
ZXIgdG8gc2VlIHNvbWVjaGFuZ2VzIGluIHRoZQ0KDQo+IGVuY29kaW5nIG9mIEFFQUQgdGFncyBh
cyBleHBsYWluZWQgYmVsb3cuDQoNCj4NCg0KPiBUaGUgY2hhbmdlcyBpbiBkcmFmdC0wNyBhZGRy
ZXNzIG1vc3Qgb2YgdGhlIHBvaW50cyBJIG1hZGUgaW4gdGhlIGVhcmx5DQoNCj4gcmV2aWV3Lg0K
DQo+IFRoZSBzbWFsbCBuaXQgY29uY2VybmluZyBhIHJlZmVyZW5jZSBpbiB0aGUgdGFibGUgb2Yg
QklCLUhNQUMtU0hBMiBTZWN1cml0eQ0KDQo+IFBhcmFtZXRlcnMgaXMgZml4ZWQgYW5kIHRoZSBp
bXBsZW1lbnRhdGlvbiBvZiBBRUFEIGFsZ29yaXRobXMgaXMgZWFzeSB0bw0KDQo+IHJlYWQuDQoN
Cj4NCg0KPiBJIGFwcHJlY2lhdGUgdGhhdCB0aGUgZHJhZnQgbm93IGNvbnRhaW5zIGFuIGVudGly
ZSBhcHBlbmRpeCBkZXNjcmliaW5nDQoNCj4gZXhhbXBsZXMgb2YgbWVzc2FnZXMsIHRoZWlyIGNs
ZWFyLXRleHQgZW5jb2RpbmcgYW5kIHRoZSByZXN1bHQgb2YNCg0KPiBhdXRoZW50aWNhdGlvbiBh
bmQgZW5jcnlwdGlvbi4gVGhpcyBwcm9iYWJseSByZXF1aXJlZCBzaWduaWZpY2FudCBlZmZvcnQs
IGFuZA0KDQo+IGl0IGRvZXMgYWRkcmVzcyBteSBzdWdnZXN0aW9uIHRvIGFkZCB0ZXN0IHZlY3Rv
cnMgaW4gb3JkZXIgdG8gbWFuYWdlDQoNCj4gaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS4NCg0K
Pg0KDQo+IEkgY291bGQganVzdCBzYXkgdGhhdCB0aGUgZHJhZnQgaXMgcmVhZHksIGV4Y2VwdCBm
b3Igb25lIGFkZGl0aW9uIHRoYXQgSSBmaW5kIGEgYml0DQoNCj4gc3B1cmlvdXMuDQoNCj4gVGhl
IGRlc2NyaXB0aW9uIG9mIEFFUy1HQ00gc3RhdGVzIHRoYXQgInRoZSBhdXRoZW50aWNhdGlvbiB0
YWcgcHJvZHVjZWQgYnkNCg0KPiB0aGUgR0NNDQoNCj4gbW9kZSBvZiBBRVMgaXMgbm90IGNvbnNp
ZGVyZWQgcGFydCBvZiB0aGUgY2lwaGVyIHRleHQgaXRzZWxmIiwgYW5kIHRoYXQgInRoZQ0KDQo+
DQoNCj4gYXV0aGVudGljYXRpb24gdGFnIGlzIGV4cGVjdGVkIHRvIGJlIGNhcnJpZWQgaW4gdGhl
IEJDQi1BRVMtR0NNDQoNCj4gICAgICAgICAgICAgc2VjdXJpdHkgYmxvY2siLiBUaGUNCg0KPiBz
dGF0ZW1lbnQgaXMgbm90IHRlY2huaWNhbGx5IGZhbHNlLCBidXQgdGhlIHNlcGFyYXRpb24gb2Yg
bWVzc2FnZSBhbmQgdGFnDQoNCj4gZ29lcyBhZ2FpbnN0IHRoZSBkZXNpZ24gb2YgbWFueSBBRUFE
IGltcGxlbWVudGF0aW9ucywgaW4gd2hpY2ggdGhlDQoNCj4gYXBwbGljYXRpb24gcHJvdmlkZXMg
dGhlIGNyeXB0byBBUEkgd2l0aCBhIGNsZWFyIHRleHQgb2Ygc29tZSBsZW5ndGgsIGFuZA0KDQo+
IHJldHJpZXZlcyBhIGNpcGhlciB0ZXh0IG9mIGEgZGlmZmVyZW50IGxlbmd0aCwgaW5jbHVkaW5n
IHRoZSB0YWcuIFNlcGFyYXRpbmcgdGhhdA0KDQo+IHRhZyBhbmQgbW92aW5nIGl0IHRvIGEgZGlm
ZmVyZW50IGxvY2F0aW9uIGlzIHlldCBhbm90aGVyIHdheSB0byBpbnRyb2R1Y2UNCg0KPiBjb21w
bGV4aXR5Lg0KDQo+DQoNCj4gVGhhdCBjb21wbGV4aXR5IGNhbiBwcm9iYWJseSBzdGlsbCBiZSBt
YW5hZ2VkIGZvciBBRVMtR0NNLCBidXQgdGhlIGdlbmVyYWwNCg0KPiB0cmVuZCBpcyB0byBpbXBs
ZW1lbnQgZW5jcnlwdGlvbiBhbmQgYXV0aGVudGljYXRpb24gaW4gYSBzaW5nbGUgb3BlcmF0aW9u
LiBJDQoNCj4gZnVsbHkgZXhwZWN0IHRoYXQgbmV3IGVuY3J5cHRpb24gYWxnb3JpdGhtcyB3aWxs
IGNvbnRpbnVlIHRoYXQgdHJlbmQsIGFuZCBtYXkNCg0KPiB3ZWxsIGRvIGF3YXkgd2l0aCB0aGUg
Zm9ybWFsIHNlcGFyYXRpb24gYmV0d2VlbiBjaXBoZXJ0ZXh0IGFuZCB0YWcuDQoNCj4gUmVjb2du
aXppbmcgdGhhdCBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiBhcmUgbm90IHNlcGFyYWJs
ZSB3b3VsZA0KDQo+IHNpbXBsaWZ5IHRoZSBEVE4gYnVuZGxlIHByb3RvY29sLg0KDQo+DQoNCg0K
--_000_5c607c5d7cf64b998a8bd2e057770ca0aplex01dom1jhuapledu_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n
czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy
IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz
cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwg
bGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt
ZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMTI5Ljc1cHQg
MS4waW4gMTI5LjdwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjcyMjM1MDk7
DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yOTM2NzE3
NjggMTQ2NDkyMDYxOCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5
MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl
dmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBs
aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm
b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl
bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps
ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9
DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt
c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0
LWlkOjEyNDczNzQ4NDE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh
dGUtaWRzOjQzMzY0MDM5MiAxNjkxMDIyNTgyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3
Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxl
dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5
OkNhbGlicmk7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u
dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps
ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7
bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls
ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi
IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0
IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk
Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNocmlzdGlhbiw8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7IFRoYW5rIHlvdSBmb3IgdGhpcyB1
cGRhdGVkIHJldmlldy4mbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw
OyBJIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGggeW91ciBhZGRpdGlvbmFsIGNvbW1lbnRzIG9u
IEFFQUQgYW5kIGhhdmUgcHJvZHVjZWQgYSAtMDggd2hpY2ggSSBob3BlIGNsYXJpZmllcyBvcHRp
b25zIGFyb3VuZCB0aGUgaGFuZGxpbmcgb2YgdGhlIGF1dGhlbnRpY2F0aW9uIHRhZy48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7IFRocmVlIHF1aWNrIG9ic2VydmF0aW9uczo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4
dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0
TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3
LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+
Jm5ic3A7VGhlIEJDQi1BRVMtR0NNIHNlY3VyaXR5IGNvbnRleHQgd2lsbCBhbHdheXMgYmUgZG9j
dW1lbnRlZCBmb3IgdGhlIEdDTSBtb2RlIG9mIEFFUyBzbywgYXMgeW91IHNheSwgbWFuYWdpbmcg
dGhpcyBjb21wbGV4aXR5IGZvciBBRVMtR0NNIGlzIHdvcmthYmxlLiBCdXQgYWxzbyBhZ3JlZSB0
aGF0IGZvciBEVE4gYXQgbGFyZ2UsIGFzIHdlIHdvcmsgdG8gaW5jb3Jwb3JhdGUgbmV3ZXIgZW5j
cnlwdGlvbiBhbGdvcml0aG1zLA0KIG5ldyBzZWN1cml0eSBjb250ZXh0IGRvY3VtZW50cyB3aWxs
IGJlIHByb2R1Y2VkIGFuZCBhdXRoZW50aWNhdGlvbi9lbmNyeXB0aW9uIGNhbiBiZSBqb2luZWQg
Zm9yIHRob3NlIGRvY3VtZW50cyBhbmQgYWxnb3JpdGhtcyBpbiBhIGxlc3MgY29tcGxleCB3YXku
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3Rl
eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9y
dExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6
Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd
PldlIGFyZSBzdGlsbCB3b3JraW5nIHdpdGggKHNvbWUpIGFlcy1nY20gbGlicmFyaWVzIHdob3Nl
IEFQSXMgc2VwYXJhdGUgdGhlIGF1dGhlbnRpY2F0aW9uIHRhZy4gRm9yIGV4YW1wbGUsIHRoZSBt
YmVkdGxzICg8YSBocmVmPSJodHRwczovL3d3dy50cnVzdGVkZmlybXdhcmUub3JnL3Byb2plY3Rz
L21iZWQtdGxzLyI+aHR0cHM6Ly93d3cudHJ1c3RlZGZpcm13YXJlLm9yZy9wcm9qZWN0cy9tYmVk
LXRscy88L2E+KQ0KIEFQSSB1c2VzIHRoZSBmdW5jdGlvbiAmbmJzcDttYmVkdGxzX2djbV9jcnlw
dF9hbmRfdGFnIHdoaWNoIHRha2VzIHRoZSB0YWcgc2VwYXJhdGVseSBmcm9tIHRoZSBjaXBoZXIg
dGV4dC4mbmJzcDsgRm9yIGludGVyb3BlcmFiaWxpdHksIHB1bGxpbmcgdGhlIHRhZyBpbnRvIGEg
c2VjdXJpdHkgcmVzdWx0IGlzIGhlbHBmdWwuIElmIGEgc2VjdXJpdHkgc291cmNlIHdlcmUgdG8g
cHJvZHVjZSBhIGJsb2IgdGhhdCByZXByZXNlbnRlZCBhbiB1bmtub3duIG9yZGVyaW5nDQogb2Yg
Y2lwaGVyIHRleHQgYW5kIGF1dGhlbnRpY2F0aW9uIHRhZywgdGhlbiBhIHNlY3VyaXR5IGRlc3Rp
bmF0aW9uIHVzaW5nIG1iZWR0bHMgd291bGQgbm90IG5lY2Vzc2FyaWx5IGtub3cgd2hlcmUgaW4g
dGhhdCBibG9iIHRvIHB1bGwgdGhlIHRhZyB3aGVuIGNvbnN0cnVjdGluZyB0aGUgY2FsbCB0byBt
YmVkdGxzX2djbV9jcnlwdF9hbmRfdGFnLiBQcmVmZXJyaW5nIHRvIGV4dHJhY3QgdGhlIHRhZyBp
cyBjbGVhcmx5IG1vcmUgY29tcGxleGl0eQ0KIGJ1dCBpdCBhbHNvIG1heSBiZSBoZWxwZnVsIHdo
ZW4gd29ya2luZyBpbiBuZXR3b3JrcyB0aGF0IGhhdmUgZGVwbG95ZWQgZGlmZmVyZW50IEFFUy1H
Q00gaW1wbGVtZW50YXRpb25zIGF0IGRpZmZlcmVudCBub2Rlcy48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21z
by1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl
PSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlcmUgaGFzIGJlZW4gc29t
ZSBkaXNjdXNzaW9uIHdoZXJlIGhhdmluZyBjZXJ0YWluIGV4dGVuc2lvbiBibG9ja3MgYmUgZml4
ZWQtc2l6ZSB3b3VsZCBoZWxwIHdpdGggcHJvY2Vzc2luZywgd2hpY2ggaXMgd2hhdCBtYWRlIHRo
ZSBBRVMtR0NNIGNpcGhlciBzdWl0ZSBhdHRyYWN0aXZlIHRvIHRob3NlIHVzZXMuIEtlZXBpbmcg
dGhlIHRhZyBzZXBhcmF0ZSBpcyBhIHdheSB0byBwcmVzZXJ2ZSB0aGF0IGxlbmd0aA0KIGNvbnN0
cmFpbnQgaW4gdGhlIGZldyBjYXNlcyB3aGVyZSB0aGF0IGlzIGhlbHBmdWwuIDxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgQWdhaW4sIHRoYW5rIHlvdSBmb3IgeW91ciB0aW1l
OyB0aGVzZSByZXZpZXdzIGhhdmUgbWFkZSB0aGUgZGVmYXVsdCBzZWN1cml0eSBjb250ZXh0IGRv
Y3VtZW50IG11Y2ggbW9yZSBjb21wbGV0ZSBhbmQgdXNlZnVsLg0KPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPi1FZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS08bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkVkd2FyZCBKLiBCaXJyYW5lLCBJSUks
IFBoLkQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5FbWJlZGRlZCBB
cHBsaWNhdGlvbnMgR3JvdXAgU3VwZXJ2aXNvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+U3BhY2UgRXhwbG9yYXRpb24gU2VjdG9yPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij5Kb2hucyBIb3BraW5zIEFwcGxpZWQgUGh5c2ljcyBMYWJvcmF0
b3J5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oVykgNDQzLTc3OC03
NDIzIC8gKEYpIDQ0My0yMjgtMzgzOTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEZyb206IENocmlzdGlh
biBIdWl0ZW1hIHZpYSBEYXRhdHJhY2tlciAmbHQ7bm9yZXBseUBpZXRmLm9yZyZndDs8L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNlbnQ6IEZyaWRheSwgTWF5IDI4LCAyMDIxIDI6
MjQgUE08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRvOiBzZWNkaXJAaWV0Zi5v
cmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IENjOiBkcmFmdC1pZXRmLWR0bi1i
cHNlYy1kZWZhdWx0LXNjLmFsbEBpZXRmLm9yZzsgZHRuQGlldGYub3JnOyBsYXN0LTwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgY2FsbEBpZXRmLm9yZzwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgU3ViamVjdDogW0VYVF0gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcg
b2YgZHJhZnQtaWV0Zi1kdG4tYnBzZWMtZGVmYXVsdC1zYy0wNzwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBUEwgZXh0
ZXJuYWwgZW1haWwgd2FybmluZzogVmVyaWZ5IHNlbmRlciA8YSBocmVmPSJtYWlsdG86bm9yZXBs
eUBpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp
b246bm9uZSI+bm9yZXBseUBpZXRmLm9yZzwvc3Bhbj48L2E+IGJlZm9yZSBjbGlja2luZzwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbGlua3Mgb3IgYXR0YWNobWVudHM8L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZndDsgUmV2aWV3ZXI6IENocmlzdGlhbiBIdWl0ZW1hPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jmd0OyBSZXZpZXcgcmVzdWx0OiBSZWFkeTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJIHJldmlld2VkIGRy
YWZ0LWlldGYtZHRuLWJwc2VjLWRlZmF1bHQtc2MtMDIgYXMgcGFydCBvZiBhbiBlYXJseSBzZWN1
cml0eTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmV2aWV3IHJlcXVlc3RlZCBi
eSB0aGUgdHJhbnNwb3J0IEFELiBUaGlzIGlzIHRoZSBmb2xsb3ctdXAgbGFzdCBjYWxsIHJldmll
dyBvZjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZHJhZnQtaWV0Zi1kdG4tYnBz
ZWMtZGVmYXVsdC1zYy0wNy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIGRyYWZ0IGlzIHJlYWR5LCBhbHRob3Vn
aCBJIHdvdWxkIHByZWZlciB0byBzZWUgc29tZWNoYW5nZXMgaW4gdGhlPC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jmd0OyBlbmNvZGluZyBvZiBBRUFEIHRhZ3MgYXMgZXhwbGFpbmVkIGJl
bG93LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jmd0OyBUaGUgY2hhbmdlcyBpbiBkcmFmdC0wNyBhZGRyZXNzIG1vc3Qgb2Yg
dGhlIHBvaW50cyBJIG1hZGUgaW4gdGhlIGVhcmx5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OyByZXZpZXcuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgc21h
bGwgbml0IGNvbmNlcm5pbmcgYSByZWZlcmVuY2UgaW4gdGhlIHRhYmxlIG9mIEJJQi1ITUFDLVNI
QTIgU2VjdXJpdHk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFBhcmFtZXRlcnMg
aXMgZml4ZWQgYW5kIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBBRUFEIGFsZ29yaXRobXMgaXMgZWFz
eSB0bzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVhZC48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
SSBhcHByZWNpYXRlIHRoYXQgdGhlIGRyYWZ0IG5vdyBjb250YWlucyBhbiBlbnRpcmUgYXBwZW5k
aXggZGVzY3JpYmluZzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZXhhbXBsZXMg
b2YgbWVzc2FnZXMsIHRoZWlyIGNsZWFyLXRleHQgZW5jb2RpbmcgYW5kIHRoZSByZXN1bHQgb2Y8
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNy
eXB0aW9uLiBUaGlzIHByb2JhYmx5IHJlcXVpcmVkIHNpZ25pZmljYW50IGVmZm9ydCwgYW5kPC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBpdCBkb2VzIGFkZHJlc3MgbXkgc3VnZ2Vz
dGlvbiB0byBhZGQgdGVzdCB2ZWN0b3JzIGluIG9yZGVyIHRvIG1hbmFnZTwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZndDsgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDsgSSBjb3VsZCBqdXN0IHNheSB0aGF0IHRoZSBkcmFmdCBpcyByZWFkeSwgZXhjZXB0IGZvciBv
bmUgYWRkaXRpb24gdGhhdCBJIGZpbmQgYSBiaXQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mZ3Q7IHNwdXJpb3VzLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIGRl
c2NyaXB0aW9uIG9mIEFFUy1HQ00gc3RhdGVzIHRoYXQgJnF1b3Q7dGhlIGF1dGhlbnRpY2F0aW9u
IHRhZyBwcm9kdWNlZCBieTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIEdD
TTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbW9kZSBvZiBBRVMgaXMgbm90IGNv
bnNpZGVyZWQgcGFydCBvZiB0aGUgY2lwaGVyIHRleHQgaXRzZWxmJnF1b3Q7LCBhbmQgdGhhdCAm
cXVvdDt0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZndDsgYXV0aGVudGljYXRpb24gdGFnIGlzIGV4cGVjdGVkIHRvIGJl
IGNhcnJpZWQgaW4gdGhlIEJDQi1BRVMtR0NNPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgc2VjdXJpdHkgYmxvY2smcXVvdDsuIFRoZTwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgc3RhdGVtZW50IGlzIG5vdCB0ZWNobmljYWxseSBmYWxzZSwgYnV0
IHRoZSBzZXBhcmF0aW9uIG9mIG1lc3NhZ2UgYW5kIHRhZzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZndDsgZ29lcyBhZ2FpbnN0IHRoZSBkZXNpZ24gb2YgbWFueSBBRUFEIGltcGxlbWVu
dGF0aW9ucywgaW4gd2hpY2ggdGhlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBh
cHBsaWNhdGlvbiBwcm92aWRlcyB0aGUgY3J5cHRvIEFQSSB3aXRoIGEgY2xlYXIgdGV4dCBvZiBz
b21lIGxlbmd0aCwgYW5kPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyByZXRyaWV2
ZXMgYSBjaXBoZXIgdGV4dCBvZiBhIGRpZmZlcmVudCBsZW5ndGgsIGluY2x1ZGluZyB0aGUgdGFn
LiBTZXBhcmF0aW5nIHRoYXQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRhZyBh
bmQgbW92aW5nIGl0IHRvIGEgZGlmZmVyZW50IGxvY2F0aW9uIGlzIHlldCBhbm90aGVyIHdheSB0
byBpbnRyb2R1Y2U8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGNvbXBsZXhpdHku
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mZ3Q7IFRoYXQgY29tcGxleGl0eSBjYW4gcHJvYmFibHkgc3RpbGwgYmUgbWFuYWdl
ZCBmb3IgQUVTLUdDTSwgYnV0IHRoZSBnZW5lcmFsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OyB0cmVuZCBpcyB0byBpbXBsZW1lbnQgZW5jcnlwdGlvbiBhbmQgYXV0aGVudGljYXRp
b24gaW4gYSBzaW5nbGUgb3BlcmF0aW9uLiBJPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jmd0OyBmdWxseSBleHBlY3QgdGhhdCBuZXcgZW5jcnlwdGlvbiBhbGdvcml0aG1zIHdpbGwgY29u
dGludWUgdGhhdCB0cmVuZCwgYW5kIG1heTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDsgd2VsbCBkbyBhd2F5IHdpdGggdGhlIGZvcm1hbCBzZXBhcmF0aW9uIGJldHdlZW4gY2lwaGVy
dGV4dCBhbmQgdGFnLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUmVjb2duaXpp
bmcgdGhhdCBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiBhcmUgbm90IHNlcGFyYWJsZSB3
b3VsZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgc2ltcGxpZnkgdGhlIERUTiBi
dW5kbGUgcHJvdG9jb2wuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K
--_000_5c607c5d7cf64b998a8bd2e057770ca0aplex01dom1jhuapledu_--
From nobody Fri Jun 25 13:20:44 2021
Return-Path:
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 345203A0D2D; Fri, 25 Jun 2021 13:20:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker
To: "The IESG"
Cc: draft-ietf-dtn-bpsec-default-sc@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org, Scott.C.Burleigh@jpl.nasa.gov, Scott.C.Burleigh@jpl.nasa.gov
X-Test-IDTracker: no
X-IETF-IDTracker: 7.32.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke
Message-ID: <162465244219.26735.12169980889573472012@ietfa.amsl.com>
Date: Fri, 25 Jun 2021 13:20:42 -0700
Archived-At:
Subject: [dtn] Martin Duke's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 25 Jun 2021 20:20:42 -0000
Martin Duke has entered the following ballot position for
draft-ietf-dtn-bpsec-default-sc-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
There are several references to the possibility that the AES-GCM API doesn't
allow for separation of the tag from the cipher text. I have not heard of
products with this API but will accept that they exist. But I'm confused as to
the handling of this case:
(4.4.1) says the tag MUST be CBOR encoded and (4.8.1) says the tag MUST be
reported in the security result; but how is this possible if the tag is not
extractable from the ciphertext?
Moreover, shouldn't there be a parameter or a scope flag somewhere that tells
the receiver if the tag is in the cipher text? It would be hard to discern the
sender's API a priori!
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
(4.5) Does "the total number of bytes processed" by AES-GCM include just
plaintext, or also the associated data?
(6.5) If a security block is cryptographically bound to a bundle, it
cannot be processed even if the security block and target both
coexist in the fragment. This is because fragments have different
primary blocks than the original bundle.
This should point out that it only applies if the primary block is part of the
AAD.
(A.4.4.1) It looks like the BIB data is simply a copy of the payload data, and
therefore incorrect. I didn't check to see if this leads to incorrect values
for the products of these inputs.
From nobody Mon Jun 28 07:14:49 2021
Return-Path:
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CF03A096C; Mon, 28 Jun 2021 07:14:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?=
To: "The IESG"
Cc: draft-ietf-dtn-bpsec-default-sc@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org, Scott.C.Burleigh@jpl.nasa.gov, Scott.C.Burleigh@jpl.nasa.gov
X-Test-IDTracker: no
X-IETF-IDTracker: 7.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?=
Message-ID: <162488967625.27649.1344527604101455188@ietfa.amsl.com>
Date: Mon, 28 Jun 2021 07:14:36 -0700
Archived-At:
Subject: [dtn] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?dtn-bpsec-default-sc-08=3A_=28with_COMMENT=29?=
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 28 Jun 2021 14:14:45 -0000
Éric Vyncke has entered the following ballot position for
draft-ietf-dtn-bpsec-default-sc-08: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you for the work put into this document.
Special thanks for the doc shepherd write-up about the WG process / consensus.
Please note that I did not review the CBOR-encoded examples.
Please find below some non-blocking COMMENT points (but replies would be
appreciated).
I hope that this helps to improve the document,
Regards,
-éric
Is the document limited to SHA-2 and AES-GCM ? How can it be extended to other
crypto algorithms ?
-- Section 3.3.1 --
Why is the CBOR encoding specified here ? The text says nothing about
serialization or message format, so, I do not understand why CBOR encoding is
required.
-- Sections 3.3.3 and 4.3.4 ---
Same comment as above but if there is transmission, what is the difference
between the reserved and the unassigned bits ? How should they be transmitted ?
How should they be processed by any receiver ?
-- Sections 3.3.4 and 4.3.5 --
Why putting the "0x" prefix in "0x7" but not for "6" in table 2 ?
From nobody Tue Jun 29 07:39:59 2021
Return-Path:
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AE63A364C; Tue, 29 Jun 2021 07:39:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Francesca Palombini via Datatracker
To: "The IESG"
Cc: draft-ietf-dtn-bpsec-default-sc@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org, Scott.C.Burleigh@jpl.nasa.gov, Scott.C.Burleigh@jpl.nasa.gov
X-Test-IDTracker: no
X-IETF-IDTracker: 7.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Francesca Palombini
Message-ID: <162497759269.17375.3427825251959918963@ietfa.amsl.com>
Date: Tue, 29 Jun 2021 07:39:53 -0700
Archived-At:
Subject: [dtn] Francesca Palombini's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 29 Jun 2021 14:39:53 -0000
Francesca Palombini has entered the following ballot position for
draft-ietf-dtn-bpsec-default-sc-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Thank you for the work on this document.
I'd like to discuss the following point. I also have some non blocking
comments, which I hope will help improve the document.
Francesca
1. -----
FP: I agree with my colleagues that extensibility should be considered for
algorithms. This document defines BIB-HMAC-SHA2 and BCB-AES-GCM, with the
algorithms these security contexts provide. Adding support for one algorithm
would need to define a new security context. Wouldn't it make sense to,
instead, provide a way to add algorithms to the existing algorithms? For
example, defining an IANA registry for each security context with the IDs of
algorithms supported (taken from COSE).
2. -----
- Bit 2 (0x0003): Security Header Flag.
FP: This should be (0x0004) and not (0x0003) (and same in a later section).
Also, this is not wrong, but the bitmaps (here and everywhere else) could also
be represented as 0b0100 in CBOR diagnostic notation, which to me is clearer.
3. -----
- Bits 8-15 are unassigned.
FP: I am wondering why the limit on Bit 15, marked as unassigned: I think it
would make sense to say Bits 8 and higher are unassigned. (This change would
need to be reflected in the IANA sections)
4. -----
FP: this might be me missing some fundamental reading from bpsec, but I see
that the blocks are defined as CBOR sequences. However, that is only mentioned
in the appendix (meant to be informative):
represented using CBOR structures. In cases where BP blocks (to
include BPSec security blocks) are comprised of a sequence of CBOR
objects, these objects are represented as a CBOR sequence as defined
in [RFC8742].
Is this defined somewhere else? If yes, could you add a pointer to the doc
where it is defined? If not, this should be clarified, and specified earlier in
the text, say in sections 3 and 4.
5. -----
[1, b'Twelve121212'] / Initialization Vector /,
FP: I think the IV value is wrong here and should be
h'5477656c7665313231323132'.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
6. -----
FP: I believe the reference to RFC 8152 should be replaced with references to
draft-ietf-cose-rfc8152bis-algs.
7. -----
BIB-HMAC-SHA2 defines the following security context parameters.
BIB-HMAC-SHA2 Security Parameters
+----+-----------------------+--------------------+---------------+
| Id | Name | CBOR Encoding Type | Default Value |
FP: Id should be defined, and a reference to the correct section of bpsec where
Ids are defined should be provided.
8. -----
+----+-----------------------+--------------------+---------------+
| 1 | SHA Variant | UINT | 6 |
FP: the correct terminology for CBOR types is not UINT but unsigned integer.
9. -----
| 2 | Wrapped Key | Byte String | NONE |
FP: Please explicitly write that NONE means that the key does not have a
default value.
10. -----
| 4 | Integrity Scope Flags | UINT | 0x7 |
+----+-----------------------+--------------------+---------------+
FP: This representation seems to be conflicting with the one for SHA Variant,
and although not wrong, usually 0x notation is given for byte strings, so this
might be confusing. I suggest to change the default value to 7, rather than 0x7.
11. -----
FP: I think this draft could make good use of a terminology section, where
terms such as security results, identifier, bundle, CRC, canonical form, set,
block type, block number, etc can point to the correct document defining them.
12. -----
on this security target, as discussed in Section 3.4).
FP: nit - one closed parenthesis too much.
13. -----
The HMAC key MAY be wrapped using the NIST AES-KW algorithm and
the results of the wrapping added as the wrapped key security
parameter for the BIB.
FP: I think this MAY is misleading: written like this, it seems as if the HMAC
key can also be sent unwrapped (while I understand the reason to add this MAY
was because the key might be retrieved in other ways than being sent).
14. -----
security block. This information includes the data included in the
confidentiality service and MAY include other information (additional
authenticated data), as follows.
FP: nit - This sentence is hard to parse, could it be rephrased to remove the
"include" duplication?
15. -----
The authentication tag calculated by the AES/GCM cipher MUST be
added as a security result for the security target in the BCB
holding results for this security operation.
and later on...
The authentication tag MUST be present in the BCB security context
parameters field if additional authenticated data are defined for
the BCB (either in the AAD scope flags parameter or as specified
by local policy). This tag MUST be 128 bits in length.
FP: I agree with Martin that the text is confusing about the presence of the
tag in the security result. Adding an "unless ..." would help.
16. -----
The plain text used during encryption MUST be calculated as the
single, definite-length CBOR byte string representing the block-type-
specific data field of the security target excluding the CBOR byte
string identifying byte and optional CBOR byte string length field.
FP: I think here you mean to say that:
The plain text used during encryption is the
block-type-specific data field value of the security target.
Is that right? I got a bit confused by the formulation, but please correct me
if this is anything else than just the value extracted from the CBOR encoding.
17. -----
The IV selected MUST be of the appropriate length. Because
replaying an IV in counter mode voids the confidentiality of all
messages encrypted with said IV, this context also requires a
unique IV for every encryption performed with the same key. This
means the same key and IV combination MUST NOT be used more than
once.
FP: This makes me uncomfortable, as I would like to see more indications on how
the IV uniqueness is achieved. Also, there should be mention of the failure to
provide IV uniqueness in the security considerations. However, I won't add this
to my discuss because I am sure the Sec ADs will have more detailed comments.
18. -----
This section presents a series of examples of constructing BPSec
security blocks (using the security contexts defined in this
document) and adding those blocks to a sample bundle.
FP: Thank you for this appendix. It would be good to point to the code used to
build these examples, if that is openly available.
19. -----
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Payload Block | 0 | 1 |
+----------------------------------------+-------+--------+
Figure 1: Example 1 Original Bundle
FP: It would be useful to explain (or point to the document explaining) this
representation.
20. -----
A.1.4. Final Bundle
FP: I think it would be useful to include the CBOR diagnostic notation for the
final bundle as well (several occurrences).
21. -----
FP: I guess this is more of a comment on bpsec than on this document, but I was
disappointed that no CDDL was defined for the CBOR encoding.
From nobody Tue Jun 29 13:44:52 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4CA3A0936; Tue, 29 Jun 2021 13:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDPYZ2hKQs5Q; Tue, 29 Jun 2021 13:41:53 -0700 (PDT)
Received: from aplegw02.jhuapl.edu (aplegw02.jhuapl.edu [128.244.251.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2133A0935; Tue, 29 Jun 2021 13:41:52 -0700 (PDT)
Received: from pps.filterd (aplegw02.jhuapl.edu [127.0.0.1]) by aplegw02.jhuapl.edu (8.16.0.43/8.16.0.43) with SMTP id 15TKacxI170513; Tue, 29 Jun 2021 16:41:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=JHUAPLDec2018; bh=NjdfzvOrQaO+29YmkKbh0M5eybe3lparpqeZBNYXMNg=; b=rgPPnGqgJI+Z1lIoV+g5qlio9wbPDw8Its5sbAac/hslFmE+vtDNHaJnGyKidUOmkga0 LZDE5HaeF2U1OWJLwuY5t8IBXbzM16DsZUkQBnlW66wEYqvl7NOZqTHqaUS7LSSC7zuJ Kwja6gfFV3BUgrWRXM0aOtSgW041P/8mCFfcTJHwfbUrGcp1NA/RkhKh0ub24R2VJniQ 3PKZ6Q/ISIbg3eVhe3EXWPRxxO2ylDLpMmYMe+eo//cCeBmJnmZeC88RF4k8uvrxlD0w 80A0mTehFf2uYQhW27daiABY0/zd4t5vWeWG61xj9JUrqKRdWp7mDJDRZLjKfVeJ4xWJ jw==
Received: from aplex02.dom1.jhuapl.edu (aplex02.dom1.jhuapl.edu [128.244.198.6]) by aplegw02.jhuapl.edu with ESMTP id 39g4jjrgur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Jun 2021 16:41:50 -0400
X-CrossPremisesHeadersFilteredBySendConnector: aplex02.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by aplex02.dom1.jhuapl.edu (128.244.198.6) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 29 Jun 2021 16:41:49 -0400
Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1497.018; Tue, 29 Jun 2021 16:41:49 -0400
From: "Birrane, Edward J."
To: Martin Duke , The IESG
CC: "draft-ietf-dtn-bpsec-default-sc@ietf.org" , "dtn-chairs@ietf.org" , "dtn@ietf.org" , "Scott.C.Burleigh@jpl.nasa.gov"
Thread-Topic: Martin Duke's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
Thread-Index: AddtFhfsldag/t4bRLiu61efYELudw==
Date: Tue, 29 Jun 2021 20:41:48 +0000
Message-ID:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.244.198.169]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OrganizationHeadersPreserved: aplex02.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-29_14:2021-06-29, 2021-06-29 signatures=0
Archived-At:
Subject: Re: [dtn] Martin Duke's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 29 Jun 2021 20:41:59 -0000
TWFydGluLA0KDQogIFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyBvZiB0aGUgLTA4IGRyYWZ0IQ0K
DQogIE15IHJlc3BvbnNlcyBhcmUgaW5jbHVkZWQgaW4tbGluZSBiZWxvdy4gIFRvIGhlbHAgd2l0
aCB0aGUgZGlzY3Vzc2lvbiwgSSBoYXZlIGVudW1lcmF0ZWQgZWFjaCBESVNDVVNTIGFzIEQjIGFu
ZCBlYWNoIENPTU1FTlQgYXMgQyMuDQoNCiAgSWYgd2UgbWFrZSB0aGUgc3VnZ2VzdGVkIGNoYW5n
ZXMgYmVsb3csIHdvdWxkIHRoZXkgYWRkcmVzcyB0aGUgY29uY2VybnMgbGlzdGVkIGluIHRoZSBE
SVNDVVNTPw0KDQotRWQNCg0KLS0tDQpFZHdhcmQgSi4gQmlycmFuZSwgSUlJLCBQaC5ELiAoaGUv
aGltL2hpcykNCkVtYmVkZGVkIEFwcGxpY2F0aW9ucyBHcm91cCBTdXBlcnZpc29yDQpTcGFjZSBF
eHBsb3JhdGlvbiBTZWN0b3INCkpvaG5zIEhvcGtpbnMgQXBwbGllZCBQaHlzaWNzIExhYm9yYXRv
cnkNCihXKSA0NDMtNzc4LTc0MjMgLyAoRikgNDQzLTIyOC0zODM5DQrCoCANCg0KPiAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ICg0LjQuMSkgc2F5cyB0
aGUgdGFnIE1VU1QgYmUgQ0JPUiBlbmNvZGVkIGFuZCAoNC44LjEpIHNheXMgdGhlIHRhZyBNVVNU
IGJlDQo+IHJlcG9ydGVkIGluIHRoZSBzZWN1cml0eSByZXN1bHQ7IGJ1dCBob3cgaXMgdGhpcyBw
b3NzaWJsZSBpZiB0aGUgdGFnIGlzIG5vdA0KPiBleHRyYWN0YWJsZSBmcm9tIHRoZSBjaXBoZXJ0
ZXh0Pw0KDQpJIGludGVycHJldGVkIHRoZSBhYm92ZSBhcyAyIGRpZmZlcmVudCBESVNDVVNTIHRv
cGljczogQ0JPUiBlbmNvZGluZyBhbmQgaGFuZGxpbmcgb2Ygc2VjdXJpdHkgcmVzdWx0cy4gDQoN
CkQxOiBBdXRoZW50aWNhdGlvbiBUYWcgZW5jb2RlZCB3aXRoIENCT1IgKFJlY29tbWVuZCBubyBj
aGFuZ2UpDQoNClRoZSBDQk9SIGVuY29kaW5nIGlzIG9ubHkgZm9yIHRoZSBBdXRoZW50aWNhdGlv
biBUYWcgU2VjdXJpdHkgUmVzdWx0IEZpZWxkLCB3aGljaCBvbmx5IGV4aXN0cyB3aGVuIHRoZSBh
dXRoZW50aWNhdGlvbiB0YWcgaXMgbm90IG90aGVyd2lzZSBnbHVlZCB0byB0aGUgY2lwaGVyIHRl
eHQgaW4gdGhlIHRhcmdldCBibG9jay4gIEluIGNhc2VzIHdoZXJlIHRoZSB0YWcgaXMgZ2x1ZWQg
dG8gdGhlIGNpcGhlciB0ZXh0IGl0c2VsZiwgdGhlIEF1dGhlbnRpY2F0aW9uIFRhZyBTZWN1cml0
eSBSZXN1bHQgRmllbGQgd291bGQgbm90IGJlIHByZXNlbnQuDQoNCg0KRDI6IENvbmZ1c2luZyB3
b3JkaW5nIHJlZ2FyZGluZyBNVVNUIGZvciBhdXRoZW50aWNhdGlvbiB0YWcgc2VjdXJpdHkgcmVz
dWx0IChGaXggV29yZGluZyBpbiBhIC0wOSkNCg0KSSBhZ3JlZSB0aGF0IHRoaXMgd29yZGluZyBp
cyBjb25mdXNpbmcuIFNlY3Rpb24gNC40IHN0YXRlcyB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiB0
YWcgaXMgdG8gYmUgcHJlc2VudCBhcyBhIHNlY3VyaXR5IHJlc3VsdCBvbmx5IGlmIHRoZSB0YWcg
aXMgbm90IG90aGVyd2lzZSBnbHVlZCB0byB0aGUgY2lwaGVyIHRleHQgYW5kIGluY2x1ZGVkIGlu
IHRoZSB0YXJnZXQgYmxvY2suICBCdXQgc2VjdGlvbiA0LjguMSBzYXlzIGJvdGggdGhhdCB0aGUg
YXV0aGVudGljYXRpb24gdGFnIG11c3QgYmUgaW5jbHVkZWQgYXMgYSBzZWN1cml0eSByZXN1bHQg
YW5kIG11c3QgYmUgcHJvY2Vzc2VkIGluIGFjY29yZGFuY2Ugd2l0aCBzZWN0aW9uIDQuNC4NCg0K
SSBiZWxpZXZlIHRoaXMgaXMgYSB0eXBvIGluIHNlY3Rpb24gNC44LjEsIHdoaWNoIHNob3VsZCBz
YXkgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gdGFnIE1BWSBiZSBhZGRlZCBhcyBhIHNlY3VyaXR5
IHJlc3VsdCBhbmQgTVVTVCBiZSBwcm9jZXNzZWQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC40
Lg0KDQogDQo+IE1vcmVvdmVyLCBzaG91bGRuJ3QgdGhlcmUgYmUgYSBwYXJhbWV0ZXIgb3IgYSBz
Y29wZSBmbGFnIHNvbWV3aGVyZSB0aGF0DQo+IHRlbGxzIHRoZSByZWNlaXZlciBpZiB0aGUgdGFn
IGlzIGluIHRoZSBjaXBoZXIgdGV4dD8gSXQgd291bGQgYmUgaGFyZCB0byBkaXNjZXJuDQo+IHRo
ZSBzZW5kZXIncyBBUEkgYSBwcmlvcmkhDQoNCg0KRDM6IFRhZyBQbGFjZW1lbnQgRmxhZyAoUmVj
b21tZW5kIG5vIGNoYW5nZSkNCg0KVGhlIGF1dGhlbnRpY2F0aW9uIHRhZyBzZWN1cml0eSByZXN1
bHQgZmllbGQgb25seSBleGlzdHMgdG8gaG9sZCB0aGUgdGFnIGluIHRoZSBpbnN0YW5jZSB3aGVu
IGl0IGlzIG5vdCBnbHVlZCB0byB0aGUgY2lwaGVyIHRleHQuIFRoZSBsYWNrIG9mIHRoZSBzZWN1
cml0eSByZXN1bHQgaXMgdGhlIGluZGljYXRpb24gdGhhdCB0aGUgdGFnIGV4aXN0cyB3aXRoIHRo
ZSBjaXBoZXIgdGV4dCBpbiB0aGUgdGFyZ2V0IGJsb2NrLiBXZSB3b3VsZCBub3QgbmVlZCBhbm90
aGVyIGZsYWcgb3IgcGFyYW1ldGVyIHRvIGNhcHR1cmUgdGhhdCBjYXNlLg0KDQoNCj4gDQo+IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gKDQuNSkgRG9l
cyAidGhlIHRvdGFsIG51bWJlciBvZiBieXRlcyBwcm9jZXNzZWQiIGJ5IEFFUy1HQ00gaW5jbHVk
ZSBqdXN0DQo+IHBsYWludGV4dCwgb3IgYWxzbyB0aGUgYXNzb2NpYXRlZCBkYXRhPw0KDQpDMTog
Qnl0ZXMgcHJvY2Vzc2VkIChSZWNvbW1lbmQgbm8gY2hhbmdlKQ0KDQpUaGUgdG90YWwgYnl0ZXMg
aW5jbHVkZXMgYm90aCBwbGFpbiB0ZXh0IGFuZCBhc3NvY2lhdGVkIGRhdGEuIA0KDQpGcm9tIEFw
cGVuZGl4IEIgb2YgdGhlIHJlZmVyZW5jZWQgTklTVCBkb2M6IA0KIlRoZXJlZm9yZSwgdGhlIHRv
dGFsIG51bWJlciBvZiBibG9ja3Mgb2YgcGxhaW50ZXh0IGFuZCBBQUQgdGhhdCBhcmUgcHJvdGVj
dGVkIGJ5IGludm9jYXRpb25zIG9mIHRoZSBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24gZnVuY3Rp
b24gZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUga2V5IHNob3VsZCBiZSBsaW1pdGVkLiINCg0K
DQo+ICg2LjUpIElmIGEgc2VjdXJpdHkgYmxvY2sgaXMgY3J5cHRvZ3JhcGhpY2FsbHkgYm91bmQg
dG8gYSBidW5kbGUsIGl0DQo+ICAgICAgIGNhbm5vdCBiZSBwcm9jZXNzZWQgZXZlbiBpZiB0aGUg
c2VjdXJpdHkgYmxvY2sgYW5kIHRhcmdldCBib3RoDQo+ICAgICAgIGNvZXhpc3QgaW4gdGhlIGZy
YWdtZW50LiAgVGhpcyBpcyBiZWNhdXNlIGZyYWdtZW50cyBoYXZlIGRpZmZlcmVudA0KPiAgICAg
ICBwcmltYXJ5IGJsb2NrcyB0aGFuIHRoZSBvcmlnaW5hbCBidW5kbGUuDQo+IA0KPiBUaGlzIHNo
b3VsZCBwb2ludCBvdXQgdGhhdCBpdCBvbmx5IGFwcGxpZXMgaWYgdGhlIHByaW1hcnkgYmxvY2sg
aXMgcGFydCBvZiB0aGUNCj4gQUFELg0KDQpDMjogQ2xhcmlmeSB3b3JkaW5nIChBZ3JlZWQgLSBh
ZGRyZXNzIGluIGEgLTA5KQ0KDQpPdXIgZGVmaW5pdGlvbiBvZiBiaW5kaW5nIHRvIHRoZSBidW5k
bGUgaXMgaW5jbHVkaW5nIHRoZSBwcmltYXJ5IGJsb2NrIGluIHRoZSBBQUQuICBNYWtpbmcgdGhp
cyBleHBsaWNpdCBoZXJlIHdvdWxkIG1ha2UgdGhhdCBjbGVhcmVyLiBJIGNhbiBtYWtlIHRoYXQg
Y2hhbmdlIGluIGFuIHVwY29taW5nIC0wOS4NCg0KDQo+IChBLjQuNC4xKSBJdCBsb29rcyBsaWtl
IHRoZSBCSUIgZGF0YSBpcyBzaW1wbHkgYSBjb3B5IG9mIHRoZSBwYXlsb2FkIGRhdGEsIGFuZA0K
PiB0aGVyZWZvcmUgaW5jb3JyZWN0LiBJIGRpZG4ndCBjaGVjayB0byBzZWUgaWYgdGhpcyBsZWFk
cyB0byBpbmNvcnJlY3QgdmFsdWVzIGZvcg0KPiB0aGUgcHJvZHVjdHMgb2YgdGhlc2UgaW5wdXRz
Lg0KDQpDMzogRml4IEJJQiBzaWduYXR1cmUgKEFncmVlZCAtIGFkZHJlc3MgaW4gYSAtMDkpDQoN
ClRoaXMgaXMgYSBnb29kIGNhdGNoLiBXZSB3aWxsIHVwZGF0ZSBhbmQgbWFrZSBzdXJlIGFueSBv
dGhlciBuZWVkZWQgY2hhbmdlcyBhcmUgbWFkZSBpbiBhbiB1cGNvbWluZyAtMDkuDQoNCg==
From nobody Tue Jun 29 15:12:24 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B1D3A1489; Tue, 29 Jun 2021 15:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KxOSxVEvVda; Tue, 29 Jun 2021 15:12:16 -0700 (PDT)
Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3873A1486; Tue, 29 Jun 2021 15:12:16 -0700 (PDT)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.16.0.43/8.16.0.43) with SMTP id 15TMAWhk089974; Tue, 29 Jun 2021 18:12:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=JHUAPLDec2018; bh=CHf01pbS6mDus/qeNLI+K3aBb4ef6HJ2Bp/du4UT5Ds=; b=YWPseIDc8GO698PoUbpOZXyDaTD3wdlQvqF6XzONUf9tqRvYXk5MTwmJIR4IP+L7tTM+ C1BWkUrS1BhGd2WEdV9RBuX8LJ08pZexyl3Ub5UM02k1e0ckLsRE7NoDVbno5ylx6aih T/B0Mo1jt9uxih4XLIvn7GIUoO3uaifc1/Snh+g1S1EQpqyNxtcWm+alk+ZTgTnKDAop BPpASVWHZjfGglScTr91CWAiS35AkB9LZm0xGQZSjD7L1HJsjFtLBbIy+d4vMYFP0NbS vlCo5VTIKloUt4nPbQ3vPTylyvevCFEpV8kiAWa+51UwmCwHSwI6TtJh5fdM00+gyIJj lw==
Received: from aplex02.dom1.jhuapl.edu (aplex02.dom1.jhuapl.edu [128.244.198.6]) by aplegw01.jhuapl.edu with ESMTP id 39g3hwrmk6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Jun 2021 18:12:11 -0400
X-CrossPremisesHeadersFilteredBySendConnector: aplex02.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by aplex02.dom1.jhuapl.edu (128.244.198.6) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 29 Jun 2021 18:12:10 -0400
Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1497.018; Tue, 29 Jun 2021 18:12:10 -0400
From: "Birrane, Edward J."
To: Francesca Palombini , The IESG
CC: "draft-ietf-dtn-bpsec-default-sc@ietf.org" , "dtn-chairs@ietf.org" , "dtn@ietf.org" , "Scott.C.Burleigh@jpl.nasa.gov"
Thread-Topic: Francesca Palombini's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
Thread-Index: AddtJ4up9ai93tCKTmCQdr167K9S3w==
Date: Tue, 29 Jun 2021 22:12:10 +0000
Message-ID:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.244.198.169]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OrganizationHeadersPreserved: aplex02.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-29_14:2021-06-29, 2021-06-29 signatures=0
Archived-At:
Subject: Re: [dtn] Francesca Palombini's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 29 Jun 2021 22:12:23 -0000
RnJhbmNlc2NhLA0KDQogIFRoYW5rIHlvdSBmb3IgdGhpcyBleGNlbGxlbnQgYW5kIHZlcnkgdGhv
cm91Z2ggcmV2aWV3IQ0KDQogIE15IHJlcGxpZXMgYXJlIGluLWxpbmUgYmVsb3cuIFRvIGFpZCBp
biBkaXNjdXNzaW9uLCBJIGhhdmUgZW51bWVyYXRlZCBESVNDVVNTZXMgYXMgRCMgYW5kIENPTU1F
TlRzIGFzIEMjLiBUaGlzIHByb3ZpZGVzIGEgc2xpZ2h0bHkgZGlmZmVyZW50IGVudW1lcmF0aW9u
IHRoYW4gdGhlIG9uZSB5b3UgcHJvdmlkZWQsIGJ1dCBob3BlZnVsbHkgaXQgaGVscHMgdG8gdHJh
Y2sgRElTQ1VTUyB2cyBDT01NRU5ULiANCg0KICBJZiB3ZSBtYWtlIHRoZSByZWNvbW1lbmRlZCBj
aGFuZ2VzIGluIGEgLTA5IGRyYWZ0LCBhcyBsaXN0ZWQgYmVsb3csIHdvdWxkIHRoYXQgcmVzb2x2
ZSB0aGUgRElTQ1VTU2VzIGFzIHdlIHVuZGVyc3RhbmQgdGhlbSBub3c/DQoNCi1FZA0KDQotLS0N
CkVkd2FyZCBKLiBCaXJyYW5lLCBJSUksIFBoLkQuIChoZS9oaW0vaGlzKQ0KRW1iZWRkZWQgQXBw
bGljYXRpb25zIEdyb3VwIFN1cGVydmlzb3INClNwYWNlIEV4cGxvcmF0aW9uIFNlY3Rvcg0KSm9o
bnMgSG9wa2lucyBBcHBsaWVkIFBoeXNpY3MgTGFib3JhdG9yeQ0KKFcpIDQ0My03NzgtNzQyMyAv
IChGKSA0NDMtMjI4LTM4MzkNCsKgIA0KIA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCj4gDQo+IDEuIC0tLS0tDQo+IA0KPiBGUDogSSBhZ3JlZSB3aXRoIG15
IGNvbGxlYWd1ZXMgdGhhdCBleHRlbnNpYmlsaXR5IHNob3VsZCBiZSBjb25zaWRlcmVkIGZvcg0K
PiBhbGdvcml0aG1zLiBUaGlzIGRvY3VtZW50IGRlZmluZXMgQklCLUhNQUMtU0hBMiBhbmQgQkNC
LUFFUy1HQ00sIHdpdGgNCj4gdGhlIGFsZ29yaXRobXMgdGhlc2Ugc2VjdXJpdHkgY29udGV4dHMg
cHJvdmlkZS4gQWRkaW5nIHN1cHBvcnQgZm9yIG9uZQ0KPiBhbGdvcml0aG0gd291bGQgbmVlZCB0
byBkZWZpbmUgYSBuZXcgc2VjdXJpdHkgY29udGV4dC4gV291bGRuJ3QgaXQgbWFrZQ0KPiBzZW5z
ZSB0bywgaW5zdGVhZCwgcHJvdmlkZSBhIHdheSB0byBhZGQgYWxnb3JpdGhtcyB0byB0aGUgZXhp
c3RpbmcgYWxnb3JpdGhtcz8NCj4gRm9yIGV4YW1wbGUsIGRlZmluaW5nIGFuIElBTkEgcmVnaXN0
cnkgZm9yIGVhY2ggc2VjdXJpdHkgY29udGV4dCB3aXRoIHRoZSBJRHMNCj4gb2YgYWxnb3JpdGht
cyBzdXBwb3J0ZWQgKHRha2VuIGZyb20gQ09TRSkuDQoNCkQxOiBSZWNvbW1lbmQgbm8gY2hhbmdl
Lg0KDQpUaGUgaW50ZW50IG9mIHRoZXNlIGRlZmF1bHQgc2VjdXJpdHkgY29udGV4dHMgd2FzIHRv
IG1ha2UgdGhlbSBzaW1wbGUgYW5kIGZ1bmN0aW9uYWwgd2l0aCB0aGUgZXhwZWN0YXRpb24gdGhh
dCBvdGhlciBzZWN1cml0eSBjb250ZXh0cyB3aXRoIHRoZSBjaGFyYWN0ZXJpc3RpY3MgeW91IGRl
c2NyaWJlIHdvdWxkIGNvbWUgbGF0ZXIuIEluIHBhcnRpY3VsYXIsIHRoZSBEVE5XRyBpcyB3b3Jr
aW5nIG9uIGEgc2VjdXJpdHkgY29udGV4dCBmb3IgQ09TRSwgdGhlIGRyYWZ0IG9mIHdoaWNoIGNh
biBiZSBmb3VuZCBhdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm
dC1ic2lwb3MtZHRuLWJwc2VjLWNvc2UtMDYNCg0KDQo+IDIuIC0tLS0tDQo+IA0KPiAgICAgICAt
IEJpdCAyICgweDAwMDMpOiBTZWN1cml0eSBIZWFkZXIgRmxhZy4NCj4gDQo+IEZQOiBUaGlzIHNo
b3VsZCBiZSAoMHgwMDA0KSBhbmQgbm90ICgweDAwMDMpIChhbmQgc2FtZSBpbiBhIGxhdGVyIHNl
Y3Rpb24pLg0KPiBBbHNvLCB0aGlzIGlzIG5vdCB3cm9uZywgYnV0IHRoZSBiaXRtYXBzIChoZXJl
IGFuZCBldmVyeXdoZXJlIGVsc2UpIGNvdWxkDQo+IGFsc28gYmUgcmVwcmVzZW50ZWQgYXMgMGIw
MTAwIGluIENCT1IgZGlhZ25vc3RpYyBub3RhdGlvbiwgd2hpY2ggdG8gbWUgaXMNCj4gY2xlYXJl
ci4NCg0KRDI6IEFncmVlZCEgDQoNCkdyZWF0IGNhdGNoIG9uIGEgdHlwby4gUmVjb21tZW5kIHRv
IGZpeCBpbiBhIC0wOS4gDQoNCiANCj4gMy4gLS0tLS0NCj4gDQo+ICAgICAgIC0gQml0cyA4LTE1
IGFyZSB1bmFzc2lnbmVkLg0KPiANCj4gRlA6IEkgYW0gd29uZGVyaW5nIHdoeSB0aGUgbGltaXQg
b24gQml0IDE1LCBtYXJrZWQgYXMgdW5hc3NpZ25lZDogSSB0aGluayBpdA0KPiB3b3VsZCBtYWtl
IHNlbnNlIHRvIHNheSBCaXRzIDggYW5kIGhpZ2hlciBhcmUgdW5hc3NpZ25lZC4gKFRoaXMgY2hh
bmdlDQo+IHdvdWxkIG5lZWQgdG8gYmUgcmVmbGVjdGVkIGluIHRoZSBJQU5BIHNlY3Rpb25zKQ0K
DQpEMzogUmVjb21tZW5kIG5vIGNoYW5nZS4gDQoNClRvIGFzc2lzdCB3aXRoIGhhcmR3YXJlIGlt
cGxlbWVudGF0aW9ucywgdGhlcmUgaXMgdmFsdWUgaW4gYWxsb3dpbmcgaW1wbGVtZW50ZXJzIHRv
IHByZXN1bWUgYW4gdXBwZXItYm91bmQgdG8gdGhlIHNpemUgb2YgdGhpcyBmaWVsZC4gDQoNCg0K
PiA0LiAtLS0tLQ0KPiANCj4gRlA6IHRoaXMgbWlnaHQgYmUgbWUgbWlzc2luZyBzb21lIGZ1bmRh
bWVudGFsIHJlYWRpbmcgZnJvbSBicHNlYywgYnV0IEkNCj4gc2VlIHRoYXQgdGhlIGJsb2NrcyBh
cmUgZGVmaW5lZCBhcyBDQk9SIHNlcXVlbmNlcy4gSG93ZXZlciwgdGhhdCBpcyBvbmx5DQo+IG1l
bnRpb25lZCBpbiB0aGUgYXBwZW5kaXggKG1lYW50IHRvIGJlIGluZm9ybWF0aXZlKToNCj4gDQo+
ICAgIHJlcHJlc2VudGVkIHVzaW5nIENCT1Igc3RydWN0dXJlcy4gIEluIGNhc2VzIHdoZXJlIEJQ
IGJsb2NrcyAodG8NCj4gICAgaW5jbHVkZSBCUFNlYyBzZWN1cml0eSBibG9ja3MpIGFyZSBjb21w
cmlzZWQgb2YgYSBzZXF1ZW5jZSBvZiBDQk9SDQo+ICAgIG9iamVjdHMsIHRoZXNlIG9iamVjdHMg
YXJlIHJlcHJlc2VudGVkIGFzIGEgQ0JPUiBzZXF1ZW5jZSBhcyBkZWZpbmVkDQo+ICAgIGluIFtS
RkM4NzQyXS4NCj4gDQo+IElzIHRoaXMgZGVmaW5lZCBzb21ld2hlcmUgZWxzZT8gSWYgeWVzLCBj
b3VsZCB5b3UgYWRkIGEgcG9pbnRlciB0byB0aGUgZG9jDQo+IHdoZXJlIGl0IGlzIGRlZmluZWQ/
IElmIG5vdCwgdGhpcyBzaG91bGQgYmUgY2xhcmlmaWVkLCBhbmQgc3BlY2lmaWVkIGVhcmxpZXIg
aW4gdGhlDQo+IHRleHQsIHNheSBpbiBzZWN0aW9ucyAzIGFuZCA0Lg0KDQpENDogUmVjb21tZW5k
IG5vIGNoYW5nZS4NCg0KVGhlIEJQU2VjIGRvY3VtZW50IGRlZmluZXMgdGhlIGNvbnRlbnRzIG9m
IGEgc2VjdXJpdHkgYmxvY2sgaW4gc2VjdGlvbiAzLjYgYXMgYSBzZXJpZXMgb2YgZmllbGRzIHRo
YXQgbXVzdCBpbmRpdmlkdWFsbHkgYmUgZW5jb2RlZCB1c2luZyBDQk9SLiAgVGhlIHJlZmVyZW5j
ZSB0byBSRkM4NzQyIGhlcmUgaXMgbWVhbnQgdG8gc2F5IHRoYXQgdGhlIG5vdGF0aW9uIHVzZWQg
aW4gdGhlIGFwcGVuZGl4IGZvciB0aGUgb3JkZXJlZCwgQ0JPUiBlbmNvZGVkIGZpZWxkcyBkZWZp
bmVkIGJ5IEJQU2VjIHdpbGwgdXNlIHRoZSBub3RhdGlvbiBmb3IgYW4gdW5hZG9ybmVkIENCT1Ig
c2VxdWVuY2UgaW4gZGlhZ25vc3RpYyBub3RhdGlvbiAoc2VjdGlvbiA0LjIgb2YgUkZDODc0Miku
IA0KDQoNCj4gNS4gLS0tLS0NCj4gDQo+ICAgICAgWzEsIGInVHdlbHZlMTIxMjEyJ10gLyBJbml0
aWFsaXphdGlvbiBWZWN0b3IgLywNCj4gDQo+IEZQOiBJIHRoaW5rIHRoZSBJViB2YWx1ZSBpcyB3
cm9uZyBoZXJlIGFuZCBzaG91bGQgYmUNCj4gaCc1NDc3NjU2Yzc2NjUzMTMyMzEzMjMxMzInLg0K
DQpENTogQWdyZWUuDQoNCmgnNTQ3NzY1NmM3NjY1MzEzMjMxMzIzMTMyJyBzaG91bGQgYmUgdXNl
ZCBoZXJlIGZvciBjbGFyaXR5LiBXZSBjYW4gcmVwcmVzZW50IHRoaXMgdmFsdWUgaW4gdGhpcyB3
YXkgaW4gYW4gdXBjb21pbmcgLTA5IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LiANCg0KDQo+IA0K
PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IDYuIC0t
LS0tDQo+IA0KPiBGUDogSSBiZWxpZXZlIHRoZSByZWZlcmVuY2UgdG8gUkZDIDgxNTIgc2hvdWxk
IGJlIHJlcGxhY2VkIHdpdGggcmVmZXJlbmNlcyB0bw0KPiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1
MmJpcy1hbGdzLg0KDQpDMTogUmVjb21tZW5kIG5vIGNoYW5nZQ0KDQpUaGUgcG9ydGlvbnMgb2Yg
UkZDODE1MiByZWZlcmVuY2VkIGluIHRoaXMgc2VjdXJpdHkgY29udGV4dCBkb2N1bWVudCBhcmUg
dW5jaGFuZ2VkIGluIHRoZSBSRkMgYW5kIHRoZSBkcmFmdCBiaXMuIFRoZXJlIHdhcyBhIG1pbm9y
IHByZWZlcmVuY2UgdG8gcmVmZXJlbmNlIHRoZSBleGlzdGluZyBzdGFuZGFyZC4gDQoNCj4gNy4g
LS0tLS0NCj4gDQo+ICAgIEJJQi1ITUFDLVNIQTIgZGVmaW5lcyB0aGUgZm9sbG93aW5nIHNlY3Vy
aXR5IGNvbnRleHQgcGFyYW1ldGVycy4NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgIEJJQi1I
TUFDLVNIQTIgU2VjdXJpdHkgUGFyYW1ldGVycw0KPiANCj4gICAgICstLS0tKy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCj4gICAg
IHwgSWQgfCAgICAgICAgICBOYW1lICAgICAgICAgfCBDQk9SIEVuY29kaW5nIFR5cGUgfCBEZWZh
dWx0IFZhbHVlIHwNCj4gDQo+IEZQOiBJZCBzaG91bGQgYmUgZGVmaW5lZCwgYW5kIGEgcmVmZXJl
bmNlIHRvIHRoZSBjb3JyZWN0IHNlY3Rpb24gb2YgYnBzZWMNCj4gd2hlcmUgSWRzIGFyZSBkZWZp
bmVkIHNob3VsZCBiZSBwcm92aWRlZC4NCg0KQzI6IEFncmVlZC4NCg0KVGhpcyB3b3VsZCBtYWtl
IHRoZSBtYXBwaW5nIG9mIGlkZW50aWZpZXIgY2xlYXJlciBhbmQgc2hvdWxkIGJlIGFkZGVkIGlu
IGEgLTA5IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LiANCg0KDQo+IDguIC0tLS0tDQo+IA0KPiAg
ICAgKy0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t
LS0tLS0tLS0tLS0tKw0KPiAgICAgfCAxICB8ICAgICAgU0hBIFZhcmlhbnQgICAgICB8ICAgICAg
ICBVSU5UICAgICAgICB8ICAgICAgIDYgICAgICAgfA0KPiANCj4gRlA6IHRoZSBjb3JyZWN0IHRl
cm1pbm9sb2d5IGZvciBDQk9SIHR5cGVzIGlzIG5vdCBVSU5UIGJ1dCB1bnNpZ25lZCBpbnRlZ2Vy
Lg0KDQpDMzogQWdyZWVkDQoNClRoZXNlIGluc3RhbmNlcyBjYW4gYmUgY29ycmVjdGVkIGluIGEg
LTA5IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50Lg0KDQoNCj4gOS4gLS0tLS0NCj4gDQo+ICAgICB8
IDIgIHwgICAgICBXcmFwcGVkIEtleSAgICAgIHwgICAgQnl0ZSBTdHJpbmcgICAgIHwgICAgICBO
T05FICAgICB8DQo+IA0KPiBGUDogUGxlYXNlIGV4cGxpY2l0bHkgd3JpdGUgdGhhdCBOT05FIG1l
YW5zIHRoYXQgdGhlIGtleSBkb2VzIG5vdCBoYXZlIGENCj4gZGVmYXVsdCB2YWx1ZS4NCg0KQzQ6
IEFncmVlZC4NCg0KVGhlc2UgaW5zdGFuY2VzIGNhbiBiZSBjb3JyZWN0ZWQgaW4gYSAtMDkgdmVy
c2lvbiBvZiB0aGUgZG9jdW1lbnQuDQoNCg0KPiAxMC4gLS0tLS0NCj4gDQo+ICAgICB8IDQgIHwg
SW50ZWdyaXR5IFNjb3BlIEZsYWdzIHwgICAgICAgIFVJTlQgICAgICAgIHwgICAgICAweDcgICAg
ICB8DQo+ICAgICArLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tLS0tLS0rDQo+IA0KPiBGUDogVGhpcyByZXByZXNlbnRhdGlvbiBzZWVt
cyB0byBiZSBjb25mbGljdGluZyB3aXRoIHRoZSBvbmUgZm9yIFNIQSBWYXJpYW50LA0KPiBhbmQg
YWx0aG91Z2ggbm90IHdyb25nLCB1c3VhbGx5IDB4IG5vdGF0aW9uIGlzIGdpdmVuIGZvciBieXRl
IHN0cmluZ3MsIHNvIHRoaXMNCj4gbWlnaHQgYmUgY29uZnVzaW5nLiBJIHN1Z2dlc3QgdG8gY2hh
bmdlIHRoZSBkZWZhdWx0IHZhbHVlIHRvIDcsIHJhdGhlciB0aGFuDQo+IDB4Ny4NCg0KQzU6IEFn
cmVlZC4NCg0KVGhpcyBjYW4gYmUgY29ycmVjdGVkIGluIGEgLTA5IHZlcnNpb24gb2YgdGhlIGRv
Y3VtZW50Lg0KDQoNCj4gMTEuIC0tLS0tDQo+IA0KPiBGUDogSSB0aGluayB0aGlzIGRyYWZ0IGNv
dWxkIG1ha2UgZ29vZCB1c2Ugb2YgYSB0ZXJtaW5vbG9neSBzZWN0aW9uLCB3aGVyZQ0KPiB0ZXJt
cyBzdWNoIGFzIHNlY3VyaXR5IHJlc3VsdHMsIGlkZW50aWZpZXIsIGJ1bmRsZSwgQ1JDLCBjYW5v
bmljYWwgZm9ybSwgc2V0LA0KPiBibG9jayB0eXBlLCBibG9jayBudW1iZXIsIGV0YyBjYW4gcG9p
bnQgdG8gdGhlIGNvcnJlY3QgZG9jdW1lbnQgZGVmaW5pbmcNCj4gdGhlbS4NCg0KQzY6IFJlY29t
bWVuZCBtaW5vciBjaGFuZ2UNCg0KVGhlc2UgdGVybXMgYXJlIGRlZmluZWQgYnkgdGhlIEJQIGFu
ZCBCUFNlYyBkb2N1bWVudHMgd2l0aCB3aGljaCB0aGUgc2VjdXJpdHkgY29udGV4dCBpcyB0byBi
ZSB1c2VkLiBSZWNvbW1lbmQgdGhhdCB0aGlzIGJlIG1hZGUgY2xlYXIgaW4gdGhlIEludHJvZHVj
dGlvbi4NCg0KDQo+IDEyLiAtLS0tLQ0KPiANCj4gICAgICAgb24gdGhpcyBzZWN1cml0eSB0YXJn
ZXQsIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMuNCkuDQo+IA0KPiBGUDogbml0IC0gb25lIGNs
b3NlZCBwYXJlbnRoZXNpcyB0b28gbXVjaC4NCg0KQzc6IEFncmVlZC4NCg0KVGhpcyBjYW4gYmUg
Y29ycmVjdGVkIGluIGEgLTA5IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50Lg0KDQoNCj4gMTMuIC0t
LS0tDQo+IA0KPiAgICAgICBUaGUgSE1BQyBrZXkgTUFZIGJlIHdyYXBwZWQgdXNpbmcgdGhlIE5J
U1QgQUVTLUtXIGFsZ29yaXRobSBhbmQNCj4gICAgICAgdGhlIHJlc3VsdHMgb2YgdGhlIHdyYXBw
aW5nIGFkZGVkIGFzIHRoZSB3cmFwcGVkIGtleSBzZWN1cml0eQ0KPiAgICAgICBwYXJhbWV0ZXIg
Zm9yIHRoZSBCSUIuDQo+IA0KPiBGUDogSSB0aGluayB0aGlzIE1BWSBpcyBtaXNsZWFkaW5nOiB3
cml0dGVuIGxpa2UgdGhpcywgaXQgc2VlbXMgYXMgaWYgdGhlIEhNQUMNCj4ga2V5IGNhbiBhbHNv
IGJlIHNlbnQgdW53cmFwcGVkICh3aGlsZSBJIHVuZGVyc3RhbmQgdGhlIHJlYXNvbiB0byBhZGQg
dGhpcw0KPiBNQVkgd2FzIGJlY2F1c2UgdGhlIGtleSBtaWdodCBiZSByZXRyaWV2ZWQgaW4gb3Ro
ZXIgd2F5cyB0aGFuIGJlaW5nIHNlbnQpLg0KDQpDODogQWdyZWVkLg0KDQpBZ3JlZWQgdGhhdCB0
aGlzIGNhbiBiZSBtaXN1bmRlcnN0b29kLiBSZWNvbW1lbmQgY2xhcmlmeWluZyB0aGF0IE1BWSBo
ZXJlIGluZGljYXRlcyB0aGF0IGtleSByZXRyaWV2YWwgbWF5IGhhcHBlbiB1c2luZyBvdGhlciBt
ZWFucy4NCg0KDQo+IDE0LiAtLS0tLQ0KPiANCj4gICAgc2VjdXJpdHkgYmxvY2suICBUaGlzIGlu
Zm9ybWF0aW9uIGluY2x1ZGVzIHRoZSBkYXRhIGluY2x1ZGVkIGluIHRoZQ0KPiAgICBjb25maWRl
bnRpYWxpdHkgc2VydmljZSBhbmQgTUFZIGluY2x1ZGUgb3RoZXIgaW5mb3JtYXRpb24gKGFkZGl0
aW9uYWwNCj4gICAgYXV0aGVudGljYXRlZCBkYXRhKSwgYXMgZm9sbG93cy4NCj4gDQo+IEZQOiBu
aXQgLSBUaGlzIHNlbnRlbmNlIGlzIGhhcmQgdG8gcGFyc2UsIGNvdWxkIGl0IGJlIHJlcGhyYXNl
ZCB0byByZW1vdmUgdGhlDQo+ICJpbmNsdWRlIiBkdXBsaWNhdGlvbj8NCg0KDQpDOTogQWdyZWVk
Lg0KDQpDYW4gcmVwaHJhc2UgdGhpcyBzZW50ZW5jZSBpbiBhIC0wOSB2ZXJzaW9uIG9mIHRoZSBk
b2N1bWVudC4NCg0KIA0KPiAxNS4gLS0tLS0NCj4gDQo+ICAgICAgIFRoZSBhdXRoZW50aWNhdGlv
biB0YWcgY2FsY3VsYXRlZCBieSB0aGUgQUVTL0dDTSBjaXBoZXIgTVVTVCBiZQ0KPiAgICAgICBh
ZGRlZCBhcyBhIHNlY3VyaXR5IHJlc3VsdCBmb3IgdGhlIHNlY3VyaXR5IHRhcmdldCBpbiB0aGUg
QkNCDQo+ICAgICAgIGhvbGRpbmcgcmVzdWx0cyBmb3IgdGhpcyBzZWN1cml0eSBvcGVyYXRpb24u
DQo+IA0KPiBhbmQgbGF0ZXIgb24uLi4NCj4gDQo+ICAgICAgIFRoZSBhdXRoZW50aWNhdGlvbiB0
YWcgTVVTVCBiZSBwcmVzZW50IGluIHRoZSBCQ0Igc2VjdXJpdHkgY29udGV4dA0KPiAgICAgICBw
YXJhbWV0ZXJzIGZpZWxkIGlmIGFkZGl0aW9uYWwgYXV0aGVudGljYXRlZCBkYXRhIGFyZSBkZWZp
bmVkIGZvcg0KPiAgICAgICB0aGUgQkNCIChlaXRoZXIgaW4gdGhlIEFBRCBzY29wZSBmbGFncyBw
YXJhbWV0ZXIgb3IgYXMgc3BlY2lmaWVkDQo+ICAgICAgIGJ5IGxvY2FsIHBvbGljeSkuICBUaGlz
IHRhZyBNVVNUIGJlIDEyOCBiaXRzIGluIGxlbmd0aC4NCj4gDQo+IEZQOiBJIGFncmVlIHdpdGgg
TWFydGluIHRoYXQgdGhlIHRleHQgaXMgY29uZnVzaW5nIGFib3V0IHRoZSBwcmVzZW5jZSBvZiB0
aGUNCj4gdGFnIGluIHRoZSBzZWN1cml0eSByZXN1bHQuIEFkZGluZyBhbiAidW5sZXNzIC4uLiIg
d291bGQgaGVscC4NCg0KQzEwOiBBZ3JlZWQuDQoNCkluIHJlc3BvbmRpbmcgdG8gTWFydGluJ3Mg
RElTQ1VTUyB3ZSBwcm9wb3NlZCBjbGFyaWZ5aW5nIHRoaXMgbGFuZ3VhZ2UgaW4gYSAtMDkgdmVy
c2lvbiBvZiB0aGUgZG9jdW1lbnQuDQoNCg0KPiAxNi4gLS0tLS0NCj4gDQo+ICAgIFRoZSBwbGFp
biB0ZXh0IHVzZWQgZHVyaW5nIGVuY3J5cHRpb24gTVVTVCBiZSBjYWxjdWxhdGVkIGFzIHRoZQ0K
PiAgICBzaW5nbGUsIGRlZmluaXRlLWxlbmd0aCBDQk9SIGJ5dGUgc3RyaW5nIHJlcHJlc2VudGlu
ZyB0aGUgYmxvY2stdHlwZS0NCj4gICAgc3BlY2lmaWMgZGF0YSBmaWVsZCBvZiB0aGUgc2VjdXJp
dHkgdGFyZ2V0IGV4Y2x1ZGluZyB0aGUgQ0JPUiBieXRlDQo+ICAgIHN0cmluZyBpZGVudGlmeWlu
ZyBieXRlIGFuZCBvcHRpb25hbCBDQk9SIGJ5dGUgc3RyaW5nIGxlbmd0aCBmaWVsZC4NCj4gDQo+
IEZQOiBJIHRoaW5rIGhlcmUgeW91IG1lYW4gdG8gc2F5IHRoYXQ6DQo+ICAgIFRoZSBwbGFpbiB0
ZXh0IHVzZWQgZHVyaW5nIGVuY3J5cHRpb24gaXMgdGhlDQo+ICAgIGJsb2NrLXR5cGUtc3BlY2lm
aWMgZGF0YSBmaWVsZCB2YWx1ZSBvZiB0aGUgc2VjdXJpdHkgdGFyZ2V0Lg0KPiANCj4gSXMgdGhh
dCByaWdodD8gSSBnb3QgYSBiaXQgY29uZnVzZWQgYnkgdGhlIGZvcm11bGF0aW9uLCBidXQgcGxl
YXNlIGNvcnJlY3QgbWUgaWYNCj4gdGhpcyBpcyBhbnl0aGluZyBlbHNlIHRoYW4ganVzdCB0aGUg
dmFsdWUgZXh0cmFjdGVkIGZyb20gdGhlIENCT1IgZW5jb2RpbmcuDQoNCkMxMTogQWdyZWVkIHRo
aXMgaXMgY29uZnVzaW5nLiBSZWNvbW1lbmQgcmV3b3JkaW5nIGluIGEgLTA5LiANCg0KVGhlIGJs
b2NrLXR5cGUtc3BlY2lmaWMgZGF0YSBmaWVsZCBpcyBlbmNvZGVkIGFzIGEgZGVmaW5pdGUtbGVu
Z3RoIENCT1IgYnl0ZSBzdHJpbmcuIFRoZSBDQk9SIGVuY29kaW5nIGlzIG5vdCBjb25zaWRlcmVk
IHBhcnQgb2YgdGhlIHBsYWluIHRleHQuIFdlIGNvdWxkIHJld29yZCB0aGlzIHRvIG1ha2UgY2xl
YXJlciB0aGF0IGFueSBDQk9SIGVuY29kaW5nIGFydGlmYWN0cyBhcmUgbm90IHRvIGJlIGNvbnNp
ZGVyZWQgYXMgcGFydCBvZiB0aGUgcGxhaW4gdGV4dC4NCg0KDQoNCj4gMTcuIC0tLS0tDQo+IA0K
PiAgICAgICBUaGUgSVYgc2VsZWN0ZWQgTVVTVCBiZSBvZiB0aGUgYXBwcm9wcmlhdGUgbGVuZ3Ro
LiAgQmVjYXVzZQ0KPiAgICAgICByZXBsYXlpbmcgYW4gSVYgaW4gY291bnRlciBtb2RlIHZvaWRz
IHRoZSBjb25maWRlbnRpYWxpdHkgb2YgYWxsDQo+ICAgICAgIG1lc3NhZ2VzIGVuY3J5cHRlZCB3
aXRoIHNhaWQgSVYsIHRoaXMgY29udGV4dCBhbHNvIHJlcXVpcmVzIGENCj4gICAgICAgdW5pcXVl
IElWIGZvciBldmVyeSBlbmNyeXB0aW9uIHBlcmZvcm1lZCB3aXRoIHRoZSBzYW1lIGtleS4gIFRo
aXMNCj4gICAgICAgbWVhbnMgdGhlIHNhbWUga2V5IGFuZCBJViBjb21iaW5hdGlvbiBNVVNUIE5P
VCBiZSB1c2VkIG1vcmUgdGhhbg0KPiAgICAgICBvbmNlLg0KPiANCj4gRlA6IFRoaXMgbWFrZXMg
bWUgdW5jb21mb3J0YWJsZSwgYXMgSSB3b3VsZCBsaWtlIHRvIHNlZSBtb3JlIGluZGljYXRpb25z
IG9uDQo+IGhvdyB0aGUgSVYgdW5pcXVlbmVzcyBpcyBhY2hpZXZlZC4gQWxzbywgdGhlcmUgc2hv
dWxkIGJlIG1lbnRpb24gb2YgdGhlDQo+IGZhaWx1cmUgdG8gcHJvdmlkZSBJViB1bmlxdWVuZXNz
IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gSG93ZXZlciwgSQ0KPiB3b24ndCBhZGQg
dGhpcyB0byBteSBkaXNjdXNzIGJlY2F1c2UgSSBhbSBzdXJlIHRoZSBTZWMgQURzIHdpbGwgaGF2
ZSBtb3JlDQo+IGRldGFpbGVkIGNvbW1lbnRzLg0KDQoNCkMxMjogUmVjb21tZW5kIG5vIGNoYW5n
ZS4NCg0KU2VjdGlvbiA0LjYgIkdDTSBDb25zaWRlcmF0aW9ucyIgbm90ZXM6DQoNClRoZSBwYWly
aW5nIG9mIGFuIElWIGFuZCBhIHNlY3VyaXR5IGtleSBNVVNUIGJlIHVuaXF1ZS4gIEFuIElWDQog
ICAgICBNVVNUIE5PVCBiZSB1c2VkIHdpdGggYSBzZWN1cml0eSBrZXkgbW9yZSB0aGFuIG9uZSB0
aW1lLiAgSWYgYW4gSVYNCiAgICAgIGFuZCBrZXkgcGFpciBhcmUgcmVwZWF0ZWQgdGhlbiB0aGUg
R0NNIGltcGxlbWVudGF0aW9uIGlzDQogICAgICB2dWxuZXJhYmxlIHRvIGZvcmdlcnkgYXR0YWNr
cy4gIE1vcmUgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZQ0KICAgICAgaW1wb3J0YW5jZSBvZiB0
aGUgdW5pcXVlbmVzcyBvZiB0aGUgSVYgdmFsdWUgY2FuIGJlIGZvdW5kIGluDQogICAgICBBcHBl
bmRpeCBBIG9mIFtBRVMtR0NNXS4NCg0KV2hpbGUgdGhlcmUgYXJlIG1hbnkgcG90ZW50aWFsIGlt
cGxlbWVudGF0aW9uIGFwcHJvYWNoZXMgKGdlbmVyYXRlIGFuZCB3cmFwIGEgbmV3IGtleSBmb3Ig
ZWFjaCBtZXNzYWdlLCB1c2UgYSBzdG9yZWQsIG1vbm90b25pY2FsbHkgaW5jcmVtZW50aW5nIHZh
bHVlLCBldGMuLikgd2UgZGlkIG5vdCBmZWVsIGl0IHdhcyBhcHByb3ByaWF0ZSB0byBwbGFjZSBp
bXBsZW1lbnRhdGlvbiBkZXNpZ24gaW50byB0aGlzIGRvY3VtZW50LiANCg0KDQo+IDE4LiAtLS0t
LQ0KPiANCj4gICAgVGhpcyBzZWN0aW9uIHByZXNlbnRzIGEgc2VyaWVzIG9mIGV4YW1wbGVzIG9m
IGNvbnN0cnVjdGluZyBCUFNlYw0KPiAgICBzZWN1cml0eSBibG9ja3MgKHVzaW5nIHRoZSBzZWN1
cml0eSBjb250ZXh0cyBkZWZpbmVkIGluIHRoaXMNCj4gICAgZG9jdW1lbnQpIGFuZCBhZGRpbmcg
dGhvc2UgYmxvY2tzIHRvIGEgc2FtcGxlIGJ1bmRsZS4NCj4gDQo+IEZQOiBUaGFuayB5b3UgZm9y
IHRoaXMgYXBwZW5kaXguIEl0IHdvdWxkIGJlIGdvb2QgdG8gcG9pbnQgdG8gdGhlIGNvZGUgdXNl
ZA0KPiB0byBidWlsZCB0aGVzZSBleGFtcGxlcywgaWYgdGhhdCBpcyBvcGVubHkgYXZhaWxhYmxl
Lg0KDQpDMTM6IFJlY29tbWVuZCBubyBjaGFuZ2UuDQoNClVuZm9ydHVuYXRlbHksIHdlIGFyZSBu
b3QgYWJsZSB0byBwcm92aWRlIHRoZSBzb2Z0d2FyZSBmb3IgZ2VuZXJhdGluZyB0aGlzLg0KDQoN
Cj4gMTkuIC0tLS0tDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEJsb2NrICAgICAg
ICAgICAgICAgICAgICBCbG9jayAgIEJsb2NrDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGlu
IEJ1bmRsZSAgICAgICAgICAgICAgICAgIFR5cGUgICAgTnVtYmVyDQo+IA0KPiArPT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSs9PT09PT09Kz09PT09PT09DQo+ICsNCj4g
ICAgICAgICB8ICBQcmltYXJ5IEJsb2NrICAgICAgICAgICAgICAgICAgICAgICAgIHwgIE4vQSAg
fCAgICAwICAgfA0KPiAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0rDQo+ICAgICAgICAgfCAgUGF5bG9hZCBCbG9jayAgICAg
ICAgICAgICAgICAgICAgICAgICB8ICAgMCAgIHwgICAgMSAgIHwNCj4gICAgICAgICArLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKw0KPiAN
Cj4gICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogRXhhbXBsZSAxIE9yaWdpbmFsIEJ1bmRs
ZQ0KPiANCj4gRlA6IEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBleHBsYWluIChvciBwb2ludCB0byB0
aGUgZG9jdW1lbnQgZXhwbGFpbmluZykgdGhpcw0KPiByZXByZXNlbnRhdGlvbi4NCg0KQzE0OiBB
Z3JlZWQuDQoNClRoaXMgaXMgc2ltaWxhciB0byBpbGx1c3RyYXRpb25zIGZyb20gdGhlIEJQU2Vj
IGRvY3VtZW50IGFuZCB3ZSBjYW4gYWRkIGEgcmVmZXJlbmNlIHRvIHRoYXQgaW4gYSAtMDkuDQog
DQoNCj4gMjAuIC0tLS0tDQo+IA0KPiBBLjEuNC4gIEZpbmFsIEJ1bmRsZQ0KPiANCj4gRlA6IEkg
dGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGluY2x1ZGUgdGhlIENCT1IgZGlhZ25vc3RpYyBu
b3RhdGlvbiBmb3IgdGhlDQo+IGZpbmFsIGJ1bmRsZSBhcyB3ZWxsIChzZXZlcmFsIG9jY3VycmVu
Y2VzKS4NCg0KQzE1OiBSZWNvbW1lbmQgbm8gY2hhbmdlLg0KDQpXZSBjb3VsZCBwcm92aWRlIGFu
IG92ZXJhbGwgYnVuZGxlLCBidXQgc2VjdXJpdHkgYmxvY2tzIGFyZSBnZW5lcmF0ZWQgYW5kIGNv
bnN1bWVkIG9uIGEgYmxvY2sgYmFzaXMsIHNvIGEgc2VjdXJpdHkgaW1wbGVtZW50YXRpb24gbWln
aHQgbm90IHByb2Nlc3MgYW4gZW50aXJlIGJ1bmRsZS4gDQoNCj4gMjEuIC0tLS0tDQo+IA0KPiBG
UDogSSBndWVzcyB0aGlzIGlzIG1vcmUgb2YgYSBjb21tZW50IG9uIGJwc2VjIHRoYW4gb24gdGhp
cyBkb2N1bWVudCwgYnV0IEkNCj4gd2FzIGRpc2FwcG9pbnRlZCB0aGF0IG5vIENEREwgd2FzIGRl
ZmluZWQgZm9yIHRoZSBDQk9SIGVuY29kaW5nLg0KDQpDMTY6IFJlY29tbWVuZCBubyBjaGFuZ2Uu
DQoNCkFncmVlZCB0aGlzIGlzIGEgY29tbWVudCBvbiB0aGUgQlBTZWMgZG9jdW1lbnQuIA0KDQo=
From nobody Tue Jun 29 15:13:28 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008473A14CA; Tue, 29 Jun 2021 15:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5A0wyBH0z0p; Tue, 29 Jun 2021 15:12:25 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532183A1492; Tue, 29 Jun 2021 15:12:25 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id s19so787119ilj.1; Tue, 29 Jun 2021 15:12:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jYrv7Q60eDT2Yc4rVxdT5mDf8oCrHtMaeFsy7s/ui2I=; b=Ae72/iasK1v8zMwp9PdUAz2uJLZFnFHwbAYhbWHh7MKIBDNIcfL0bIRWtu5qyXTNJ0 6UwUbMWMoIkRWTp9V08aUsXrM4v/9qKE1F20KS4qFkyik0+qMzdQpKhTnLtapOdrUsk5 zBcsG10kooUSl17FkZKWkzFoHvXGvQC557p5Jx6jD2ZBsgIMsEq2cdNakLhMKQLtUr9v EBQNIkTCDEyPeCyrduVR94km03PgvHK/tVn5WKIa8s8QTLh4LbKfny90xjz3Xzy7Rhaf CPt81dTh8YRYsn7tiz2BYRKLOUusJ6ASXP+SIzki5vQzXRb2XA7JL6BJc/Nj+AMhsmj/ jsMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jYrv7Q60eDT2Yc4rVxdT5mDf8oCrHtMaeFsy7s/ui2I=; b=L3psDPOcfndll2a4+5CMBJkna11Q1oINTD8dbWZYVuQGPurdyzvgoJzRcBVnz31KQt Rjffiqv2RKQ/HH2Iza7/mIX+z2KeEA4kyg/R0DwCO9wJGosTmRJHOo4eyYfnQIxB2gvM 0WqHkQJB05BkI10hKifv2I4BJt0Y1b4s4SSJzcnPgaRmILDb6rZN5b/a80Hbevh8SEq0 x8OGvVk/hMzKwtj07j75cT+lB/iLlRxrMYf3W3l5LYJvoYamMiJRnD4iqeE+Ixv4REaR 7BUiY0uZ8Ymd1Q1881+JOfsVNY3BMwv+H1Xuf8++cDWWwMLpk/d7vtnOsAY8sDILhIs+ ZhZA==
X-Gm-Message-State: AOAM532sTK2emvXG86SKoIRPuyMqFWv9oBOj+J4kN6IgFuFFX0X04iO4 8I+4/nJ8z/79hlDWoUesfdXkP0piRTbUJe1WheU=
X-Google-Smtp-Source: ABdhPJzG+3nKOrgf2kG5c0DQ5qDUMA/eE5sy7C1mbabwFaWnT3d806UiVsOCgYe6C4cVxQ2/zPk4XiEHX8kUmdELTMw=
X-Received: by 2002:a92:750c:: with SMTP id q12mr23563986ilc.303.1625004743284; Tue, 29 Jun 2021 15:12:23 -0700 (PDT)
MIME-Version: 1.0
References:
In-Reply-To:
From: Martin Duke
Date: Tue, 29 Jun 2021 15:12:11 -0700
Message-ID:
To: "Birrane, Edward J."
Cc: The IESG , "draft-ietf-dtn-bpsec-default-sc@ietf.org" , "dtn-chairs@ietf.org" , "dtn@ietf.org" , "Scott.C.Burleigh@jpl.nasa.gov"
Content-Type: multipart/alternative; boundary="0000000000007b616f05c5eee6d5"
Archived-At:
Subject: Re: [dtn] Martin Duke's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 29 Jun 2021 22:12:35 -0000
--0000000000007b616f05c5eee6d5
Content-Type: text/plain; charset="UTF-8"
Hi Ed, yes, all of your replies absolutely satisfy my concerns. Thanks!
On Tue, Jun 29, 2021 at 1:41 PM Birrane, Edward J. <
Edward.Birrane@jhuapl.edu> wrote:
> Martin,
>
> Thank you for the review of the -08 draft!
>
> My responses are included in-line below. To help with the discussion, I
> have enumerated each DISCUSS as D# and each COMMENT as C#.
>
> If we make the suggested changes below, would they address the concerns
> listed in the DISCUSS?
>
> -Ed
>
> ---
> Edward J. Birrane, III, Ph.D. (he/him/his)
> Embedded Applications Group Supervisor
> Space Exploration Sector
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 / (F) 443-228-3839
>
>
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > (4.4.1) says the tag MUST be CBOR encoded and (4.8.1) says the tag MUST
> be
> > reported in the security result; but how is this possible if the tag is
> not
> > extractable from the ciphertext?
>
> I interpreted the above as 2 different DISCUSS topics: CBOR encoding and
> handling of security results.
>
> D1: Authentication Tag encoded with CBOR (Recommend no change)
>
> The CBOR encoding is only for the Authentication Tag Security Result
> Field, which only exists when the authentication tag is not otherwise glued
> to the cipher text in the target block. In cases where the tag is glued to
> the cipher text itself, the Authentication Tag Security Result Field would
> not be present.
>
>
> D2: Confusing wording regarding MUST for authentication tag security
> result (Fix Wording in a -09)
>
> I agree that this wording is confusing. Section 4.4 states that the
> authentication tag is to be present as a security result only if the tag is
> not otherwise glued to the cipher text and included in the target block.
> But section 4.8.1 says both that the authentication tag must be included as
> a security result and must be processed in accordance with section 4.4.
>
> I believe this is a typo in section 4.8.1, which should say that the
> authentication tag MAY be added as a security result and MUST be processed
> as described in Section 4.4.
>
>
> > Moreover, shouldn't there be a parameter or a scope flag somewhere that
> > tells the receiver if the tag is in the cipher text? It would be hard to
> discern
> > the sender's API a priori!
>
>
> D3: Tag Placement Flag (Recommend no change)
>
> The authentication tag security result field only exists to hold the tag
> in the instance when it is not glued to the cipher text. The lack of the
> security result is the indication that the tag exists with the cipher text
> in the target block. We would not need another flag or parameter to capture
> that case.
>
>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > (4.5) Does "the total number of bytes processed" by AES-GCM include just
> > plaintext, or also the associated data?
>
> C1: Bytes processed (Recommend no change)
>
> The total bytes includes both plain text and associated data.
>
> From Appendix B of the referenced NIST doc:
> "Therefore, the total number of blocks of plaintext and AAD that are
> protected by invocations of the authenticated encryption function during
> the lifetime of the key should be limited."
>
>
> > (6.5) If a security block is cryptographically bound to a bundle, it
> > cannot be processed even if the security block and target both
> > coexist in the fragment. This is because fragments have different
> > primary blocks than the original bundle.
> >
> > This should point out that it only applies if the primary block is part
> of the
> > AAD.
>
> C2: Clarify wording (Agreed - address in a -09)
>
> Our definition of binding to the bundle is including the primary block in
> the AAD. Making this explicit here would make that clearer. I can make
> that change in an upcoming -09.
>
>
> > (A.4.4.1) It looks like the BIB data is simply a copy of the payload
> data, and
> > therefore incorrect. I didn't check to see if this leads to incorrect
> values for
> > the products of these inputs.
>
> C3: Fix BIB signature (Agreed - address in a -09)
>
> This is a good catch. We will update and make sure any other needed
> changes are made in an upcoming -09.
>
>
--0000000000007b616f05c5eee6d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Ed, yes, all of your replies absolutely satisfy my conc=
erns. Thanks!
Martin,<=
br>
=C2=A0 Thank you for the review of the -08 draft!
=C2=A0 My responses are included in-line below.=C2=A0 To help with the disc=
ussion, I have enumerated each DISCUSS as D# and each COMMENT as C#.
=C2=A0 If we make the suggested changes below, would they address the conce=
rns listed in the DISCUSS?
-Ed
---
Edward J. Birrane, III, Ph.D. (he/him/his)
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
=C2=A0
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> (4.4.1) says the tag MUST be CBOR encoded and (4.8.1) says the tag MUS=
T be
> reported in the security result; but how is this possible if the tag i=
s not
> extractable from the ciphertext?
I interpreted the above as 2 different DISCUSS topics: CBOR encoding and ha=
ndling of security results.
D1: Authentication Tag encoded with CBOR (Recommend no change)
The CBOR encoding is only for the Authentication Tag Security Result Field,=
which only exists when the authentication tag is not otherwise glued to th=
e cipher text in the target block.=C2=A0 In cases where the tag is glued to=
the cipher text itself, the Authentication Tag Security Result Field would=
not be present.
D2: Confusing wording regarding MUST for authentication tag security result=
(Fix Wording in a -09)
I agree that this wording is confusing. Section 4.4 states that the authent=
ication tag is to be present as a security result only if the tag is not ot=
herwise glued to the cipher text and included in the target block.=C2=A0 Bu=
t section 4.8.1 says both that the authentication tag must be included as a=
security result and must be processed in accordance with section 4.4.
I believe this is a typo in section 4.8.1, which should say that the authen=
tication tag MAY be added as a security result and MUST be processed as des=
cribed in Section 4.4.
> Moreover, shouldn't there be a parameter or a scope flag somewhere=
that
> tells the receiver if the tag is in the cipher text? It would be hard =
to discern
> the sender's API a priori!
D3: Tag Placement Flag (Recommend no change)
The authentication tag security result field only exists to hold the tag in=
the instance when it is not glued to the cipher text. The lack of the secu=
rity result is the indication that the tag exists with the cipher text in t=
he target block. We would not need another flag or parameter to capture tha=
t case.
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> (4.5) Does "the total number of bytes processed" by AES-GCM =
include just
> plaintext, or also the associated data?
C1: Bytes processed (Recommend no change)
The total bytes includes both plain text and associated data.
>From Appendix B of the referenced NIST doc:
"Therefore, the total number of blocks of plaintext and AAD that are p=
rotected by invocations of the authenticated encryption function during the=
lifetime of the key should be limited."
> (6.5) If a security block is cryptographically bound to a bundle, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be processed even if the security blo=
ck and target both
>=C2=A0 =C2=A0 =C2=A0 =C2=A0coexist in the fragment.=C2=A0 This is becau=
se fragments have different
>=C2=A0 =C2=A0 =C2=A0 =C2=A0primary blocks than the original bundle.
>
> This should point out that it only applies if the primary block is par=
t of the
> AAD.
C2: Clarify wording (Agreed - address in a -09)
Our definition of binding to the bundle is including the primary block in t=
he AAD.=C2=A0 Making this explicit here would make that clearer. I can make=
that change in an upcoming -09.
> (A.4.4.1) It looks like the BIB data is simply a copy of the payload d=
ata, and
> therefore incorrect. I didn't check to see if this leads to incorr=
ect values for
> the products of these inputs.
C3: Fix BIB signature (Agreed - address in a -09)
This is a good catch. We will update and make sure any other needed changes=
are made in an upcoming -09.
--0000000000007b616f05c5eee6d5--
From nobody Tue Jun 29 15:31:38 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD62E3A157C; Tue, 29 Jun 2021 15:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aQwVx-4xZBW; Tue, 29 Jun 2021 15:31:10 -0700 (PDT)
Received: from aplegw02.jhuapl.edu (aplegw02.jhuapl.edu [128.244.251.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89073A1564; Tue, 29 Jun 2021 15:31:09 -0700 (PDT)
Received: from pps.filterd (aplegw02.jhuapl.edu [127.0.0.1]) by aplegw02.jhuapl.edu (8.16.0.43/8.16.0.43) with SMTP id 15TMUHdj067122; Tue, 29 Jun 2021 18:31:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=JHUAPLDec2018; bh=yrg1Am8+mm2dP2ptiob0JPkJmQo8HMKIwANRy6EV/2w=; b=OoHMDBbTbX9G63H98EjdSkg2i46Xvws7/6vgtOCVW7cBH7t5qCOIhT39uFWxdMIKBg1o 8vSSglvGHC1zylb2rNS6eCkHDBQGdsfsUE6i079ETioxIWD2+Ug8IcBwCvwfEn1FNkOx fxzHN42C07bP5/YiIjuWQjRIAxHOUJH+mM4PGGRzEu+Yb3cDN+71SUkzjoTjbHge30DQ se2KaOyYq4LXy5wt0d4deiQDhAWruNBl7UQ0TwSn8BfrO1fq69gkUG5IWBNPULZzGet9 QdSA/AegJS8sRFfjvcXEC9NNNJUE4rVm9QBy3ll5hy8JMgo16k9o21gU9D7pUjN+FrXB gA==
Received: from aplex03.dom1.jhuapl.edu (aplex03.dom1.jhuapl.edu [128.244.198.7]) by aplegw02.jhuapl.edu with ESMTP id 39g4jjrkbd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Jun 2021 18:31:07 -0400
X-CrossPremisesHeadersFilteredBySendConnector: APLEX03.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by APLEX03.dom1.jhuapl.edu (128.244.198.7) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 29 Jun 2021 18:31:06 -0400
Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1497.018; Tue, 29 Jun 2021 18:31:06 -0400
From: "Birrane, Edward J."
To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG
CC: "draft-ietf-dtn-bpsec-default-sc@ietf.org" , "dtn-chairs@ietf.org" , "dtn@ietf.org" , "Scott.C.Burleigh@jpl.nasa.gov"
Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZHRu?= =?utf-8?Q?-bpsec-default-sc-08:_(with_COMMENT)?=
Thread-Index: AddtNJMQwkbSAnkMS/64sf3aJQU15g==
Date: Tue, 29 Jun 2021 22:31:05 +0000
Message-ID:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.244.198.169]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OrganizationHeadersPreserved: APLEX03.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-29_14:2021-06-29, 2021-06-29 signatures=0
Archived-At:
Subject: Re: [dtn] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?dtn-bpsec-default-sc-08=3A_=28with_COMMENT=29?=
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 29 Jun 2021 22:31:23 -0000
w4lyaWMsDQoNCiAgVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IQ0KDQogIEkgaGF2ZSBlbnVtZXJh
dGVkIHRoZSBDT01NRU5UcyBiZWxvdyBhcyBDIyBmb3IgcmVmZXJlbmNlIGFuZCBwcm92aWRlZCBh
IHJlY29tbWVuZGF0aW9uIGZvciBlYWNoLg0KDQogIFBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGVz
ZSByZWNvbW1lbmRlZCBhY3Rpb25zIGFwcHJvcHJpYXRlbHkgYWRkcmVzcyB5b3VyIGNvbW1lbnRz
LiAgDQoNCi1FZA0KDQotLS0NCkVkd2FyZCBKLiBCaXJyYW5lLCBJSUksIFBoLkQuIChoZS9oaW0v
aGlzKQ0KRW1iZWRkZWQgQXBwbGljYXRpb25zIEdyb3VwIFN1cGVydmlzb3INClNwYWNlIEV4cGxv
cmF0aW9uIFNlY3Rvcg0KSm9obnMgSG9wa2lucyBBcHBsaWVkIFBoeXNpY3MgTGFib3JhdG9yeQ0K
KFcpIDQ0My03NzgtNzQyMyAvIChGKSA0NDMtMjI4LTM4MzkNCsKgIA0KPiAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSXMgdGhlIGRvY3VtZW50IGxpbWl0ZWQg
dG8gU0hBLTIgYW5kIEFFUy1HQ00gPyBIb3cgY2FuIGl0IGJlIGV4dGVuZGVkIHRvDQo+IG90aGVy
IGNyeXB0byBhbGdvcml0aG1zID8NCg0KQzE6IFJlY29tbWVuZCBubyBjaGFuZ2UuDQoNClllcywg
dGhpcyBkb2N1bWVudCBpcyBsaW1pdGVkIHRvIHRoZXNlIHR3byBzZWN1cml0eSBjb250ZXh0IGFu
ZCBpdHMgaW50ZW50IHdhcyB0byBkZWZpbmUgdHdvIHNpbXBsZSwgYmFzZWxpbmUgY29udGV4dHMu
IA0KDQpPdGhlciBkb2N1bWVudHMgd2lsbCBleGlzdCB0byBkZWZpbmUgb3RoZXIgc2VjdXJpdHkg
Y29udGV4dHMsIHRvIGluY2x1ZGUgYSBzZWN1cml0eSBjb250ZXh0IGZvciBDT1NFIHdoaWNoIGFs
bG93cyBmb3IgbW9yZSBmbGV4aWJsZSBkZWZpbml0aW9ucyAoaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ic2lwb3MtZHRuLWJwc2VjLWNvc2UtMDYpLiANCg0KDQo+
IC0tIFNlY3Rpb24gMy4zLjEgLS0NCj4gV2h5IGlzIHRoZSBDQk9SIGVuY29kaW5nIHNwZWNpZmll
ZCBoZXJlID8gVGhlIHRleHQgc2F5cyBub3RoaW5nIGFib3V0DQo+IHNlcmlhbGl6YXRpb24gb3Ig
bWVzc2FnZSBmb3JtYXQsIHNvLCBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSBDQk9SIGVuY29kaW5n
DQo+IGlzIHJlcXVpcmVkLg0KDQpDMjogUmVjb21tZW5kIG5vIGNoYW5nZS4NCg0KVGhlIEJQU2Vj
IHN0YW5kYXJkLCB3aGljaCBpZGVudGlmaWVzIHRoZSBzZWN1cml0eSBibG9ja3MgYmVpbmcgcG9w
dWxhdGVkIGJ5IGEgc2VjdXJpdHkgY29udGV4dCByZXF1aXJlcyB0aGF0IHNlY3VyaXR5IGNvbnRl
eHRzIHNwZWNpZnkgaG93IGEgc2VjdXJpdHkgcGFyYW1ldGVyIGFuZCBhIHNlY3VyaXR5IHJlc3Vs
dCBiZSBlbmNvZGVkLiBTZWN0aW9uIDkuMyBvZiB0aGUgQlBTZWMgZG9jdW1lbnQgIkF1dGhvcnNo
aXAiIHN0YXRlczoNCg0KICAgbyAgU2VjdXJpdHkgQ29udGV4dCBQYXJhbWV0ZXJzLiAgU2VjdXJp
dHkgY29udGV4dHMgTVVTVCBkZWZpbmUgdGhlaXINCiAgICAgIHBhcmFtZXRlciBJZHMsIHRoZSBk
YXRhIHR5cGVzIG9mIHRob3NlIHBhcmFtZXRlcnMsIGFuZCB0aGVpciBDQk9SDQogICAgICBlbmNv
ZGluZy4NCg0KICAgbyAgU2VjdXJpdHkgUmVzdWx0cy4gIFNlY3VyaXR5IGNvbnRleHRzIE1VU1Qg
ZGVmaW5lIHRoZWlyIHNlY3VyaXR5DQogICAgICByZXN1bHQgSWRzLCB0aGUgZGF0YSB0eXBlcyBv
ZiB0aG9zZSByZXN1bHRzLCBhbmQgdGhlaXIgQ0JPUg0KICAgICAgZW5jb2RpbmcuDQoNCg0KPiAt
LSBTZWN0aW9ucyAzLjMuMyBhbmQgNC4zLjQgLS0tDQo+IFNhbWUgY29tbWVudCBhcyBhYm92ZSBi
dXQgaWYgdGhlcmUgaXMgdHJhbnNtaXNzaW9uLCB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlDQo+IGJl
dHdlZW4gdGhlIHJlc2VydmVkIGFuZCB0aGUgdW5hc3NpZ25lZCBiaXRzID8gSG93IHNob3VsZCB0
aGV5IGJlDQo+IHRyYW5zbWl0dGVkID8NCg0KQzM6IEFncmVlZC4gIA0KDQpXaGlsZSB0aGUgdGV4
dCBzYXlzIHRoZXNlIHNob3VsZCBiZSBpZ25vcmVkLCBsYW5ndWFnZSBjb3VsZCBiZSBhZGRlZCB0
byBhIC0wOSBzcGVjaWZ5aW5nIHRoYXQgdGhlc2UgYml0cyBiZSBzZXQgdG8gMCBvbiB0cmFuc21p
c3Npb24uDQoNCj4gSG93IHNob3VsZCB0aGV5IGJlIHByb2Nlc3NlZCBieSBhbnkgcmVjZWl2ZXIg
Pw0KDQpDNDogQWdyZWVkIGFuZCBmaXhlZCBieSBDMy4gDQoNCkluIGNvb3JkaW5hdGlvbiB3aXRo
IEMzIGFib3ZlLCBpZiBzZXQgdG8gMCBvbiB0cmFuc21pc3Npb24sIHRoaXMgd2lsbCBjYXVzZSB0
aG9zZSBmbGFncyB0byBiZSBpZ25vcmVkIGJ5IGEgcmVjZWl2ZXIuDQoNCj4gLS0gU2VjdGlvbnMg
My4zLjQgYW5kIDQuMy41IC0tDQo+IFdoeSBwdXR0aW5nIHRoZSAiMHgiIHByZWZpeCBpbiAgIjB4
NyIgYnV0IG5vdCBmb3IgIjYiIGluIHRhYmxlIDIgPw0KDQoNCkM1OiBBZ3JlZWQuIA0KDQpUaGlz
IHdpbGwgYmUgY29ycmVjdGVkIGluIGEgLTA5IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LiANCg==
From nobody Tue Jun 29 19:48:19 2021
Return-Path:
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD753A13D1; Tue, 29 Jun 2021 19:48:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker
To: "The IESG"
Cc: draft-ietf-dtn-bpsec-default-sc@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org, Scott.C.Burleigh@jpl.nasa.gov, Scott.C.Burleigh@jpl.nasa.gov
X-Test-IDTracker: no
X-IETF-IDTracker: 7.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk
Message-ID: <162502129278.4688.16016391507186667540@ietfa.amsl.com>
Date: Tue, 29 Jun 2021 19:48:13 -0700
Archived-At:
Subject: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 30 Jun 2021 02:48:13 -0000
Benjamin Kaduk has entered the following ballot position for
draft-ietf-dtn-bpsec-default-sc-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Thank you for writing this document; I'm really glad that it will be
available to illuminate the particulars of BPsec usage and provide a
default option when running BPsec in relatively bland environments.
However, I think there are a few gaps between the current specification
and a strong/reliable default security option.
(D1) the construction for the HMAC input plaintext and GCM AAD seems to
be "malleable" at the security context layer. That is, in order for the
cryptographic integrity protection mechanism to provide strong
guarantees for the application protocol's semantics, the mapping from
protocol parameters (e.g., "security target contents", "primary block")
to the actual byte string used as the IPPT/AAD inputs to HMAC/GMAC needs
to be an injective mapping (in the mathematical sense). If injectivity
does not hold, then there is more than one possible application
semantics that could be perceived as valid upon successful validation of
the authentication tag at the recipient; this "malleability" across
different interpretations of the bytes covered by a given integrity tag
gives an opening by which an attacker can target the application
semantics.
The current construction seems
"malleable" because the scope flags are not protected in any way and
could be modified by an attacker, and the scope flags affect which
application protocol fields (and thus, semantics) are used to construct
the IPPT/AAD. If the attacker modifies the messages to move those
encoded bytes from one location to another, the modified message could
still pass cryptographic verification but be interpreted with different
semantics than intended. We do correctly note that the security context
identifier and the security context parameters of the security block are
not included in the input data, but the conclusion that "successful
verification implies that these parameters were unchanged from what the
security source has specified" does not seem entirely warranted without
further analysis that relies on the internal structure of the different
potential parts of the IPPT/AAD.
[side note: the IETF security community tends towards "always include as
much information in the MAC as you can without breaking operations",
which would naively be everything included with scope flags 0x7. Always
including everything removes the malleability, since there are no gaps
to move around. But I think I can come up with scenarios where this
flexibility would indeed be needed in BP operations, so my tentative
conclusion is that the simple "always MAC everything" approach will not
work here.]
Specifically, to the extent that we may have injectivity, we seem to be
relying on the specific encoding details of the different types of
information that could be used in constructing the IPPT and AAD. Since
the IPPT/AAD is currently just the concatenation (in a particular order)
of any/all of a few pieces of data, we can only get injectivity if each
of those pieces of data is self-framing and *self-identifying* by its
encoded form. (If we, for example, prefixed each self-framing part with
a type identifier for what followed, that would make the overall
encoding self-identifying for what is contained therein.) E.g., the
primary block is going to be a CBOR array with (at least?) 8 elements,
starting with 0x0808, and is self-framing by virtue of being a CBOR
object. But the "security target other fields" are not so clearly self
framing, as it's more of a CBOR sequence with type code, block number,
and control flags as three unsigned integers; we have to know a priori
to read three CBOR unsigned integers and treat that as a single object.
Furthermore, the "BIB other fields" (or "BCB other fields") are also
three CBOR unsigned integers, and since it's possible for (e.g.) a BIB
to be the security target of a BIB, the block type code cannot
distinguish between a security target and the BIB information. Only the
block number could, but IIRC the block number itself is malleable to an
on-path attacker. And this analysis only covers the currently specified
scope flags; any future additions might add new ways for injectivity to
fail. It's much better to have a strong injective construction at the
higher layer and not rely on the internal encoding details of the
component pieces.
So, I think we need to include at least the scope flags as part of the
IPPT/AAD in order to provide injectivity. It might be worth considering
adding additional framing and typing to make clear boundaries between
the different parts of the IPPT/AAD, but my current understanding is
that it would not be strictly necessary to do so.
(D2) There seems to be some risk associated with the current HMAC
construction, since the HMAC with a given key over a given plaintext
will be the same each time it is calculated. In other protocol
contexts, this has led to practical attacks and HMAC forgery, by using a
side-channel to gain insight into the verifier's behavior and guessing
the correct HMAC tag for a given (attacker-selected) plaintext a byte at
a time. With only a modest number of trials (4k on average for
HMAC-SHA-256, assuming a fully reliable side channel) this would let the
attacker extract the valid HMAC tag that the verifier produced for
comparison against the attacker's guess at the HMAC tag. Since this is
the HMAC tag over the attacker's chosen plaintext, this lets the
attacker obtain a valid HMAC tag without knowing the HMAC key.
Now, it seems clear that in the preponderance of BP deployments there
will not be an effective side channel available! But IMO this still
reflects a fundamental cryptographic weakness in the protocol and we
should make some effort to address it. There are a couple potential
mitigation approaches off the top of my head, which can be combined if
desired: include a nonce as part of the HMAC input (and encourage
rejection of reused nonces), and require constant-time comparison of the
supplied and expected authentication tag (to prevent using a side
channel from reading it off byte by byte). I suspect that there may be some
operational issues with the "unique nonce per HMAC" approach that would
make it not terribly reliable in practice, but "use a constant-time
comparison" should be fairly straightforward.
(D3) While we do provide the standard guidance against using any given
key with more than one algorithm (e.g., with HMAC-SHA-256 and
AES256-GCM), there seem to be additional considerations relevant to this
protocol that merit further discussion in the security considerations.
Specifically, we make provision for an AES-KW wrapped key to be included
along with the security payload and mandate that if present, such a key
be used. Given that the parameter holding the wrapped key does not seem
to be bound to a given message, it seems fairly straightforward for an
in-network attacker to "slice and dice" the ciphertext and wrapped key
away from each other, and cause any wrapped key it has seen to be
attempted to be used with a given algorithm+ciphertext. This, in turn,
would provide attacker-induced key reuse across algorithms, which is
something that we want to avoid. While providing full protection
against key reuse with different algorithms would prove fairly
challenging and probably require significant state on the
verifier/security destination, we should at least have some discussion
of the situation, and could provide some modest mitigation techniques
such as using distinct KEKs for receiving wrapped keys that have different
intended usage. That is, one KEK for receiving AES keys, another for
HMAC keys, etc.. Attaching context (intended algorithm, etc.) to the
KEK allows such context to be indirectly attached to the received
wrapped keys, which otherwise would come without much context for
intended usage.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thanks to Christian Huitema for the multiple secdir reviews, and special
thanks to the authors for adding examples/test vectors as he
recommended, as well as the other updates.
Section 3.1
BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the
supported length of the SHA-2 hash value. These variants correspond
to "HMAC 256/256", "HMAC 384/384", and "HMAC 512/512" as defined in
[RFC8152] Table 7: HMAC Algorithm Values. [...]
This is unfortunate timing, I suppose, but RFC 8152 is going to be
replaced imminently by draft-ietf-cose-rfc8152bis-algs and
draft-ietf-cose-rfc8152bis-struct, which are virtually certain to be
published as RFCs before this document.
Section 3.2
NOTE: The security context identifier and security context
parameters of the security block are not included in the IPPT
because these parameters, by definition, are required to verify
or accept the security service. Successful verification at
security verifiers and security acceptors implies that these
parameters were unchanged since being specified at the security
source.
(related to D1, but distinct...)
This seems to be only mostly true ... if some other security context was
created that also used HMAC-SHA2 it seems like the same output might be
obtained or validated across security contexts ... but this would only
cause problems if there were different semantics afforded to the
different security contexts in some way. Any attack would also be
stymied if the honest participants were rigorous in separation of keys,
with any given key being used with only one security context.
Section 3.3.3
Integrity scope flags that are unrecognized MUST be ignored, as
future definitions of additional flags might not be integrated
simultaneously into security context implementations operating at all
nodes.
It's not entirely clear how useful a mandate to ignore unrecognized
flags will be, if the flags would change the plaintext input and thus
the value of the HMAC output. I guess maybe the intent is just that
intermediate notes processing a bundle but not acting as security
acceptor should pass through such flags unchanged?
Section 3.3.4
BIB-HMAC-SHA2 Security Parameters
+----+-----------------------+--------------------+---------------+
| Id | Name | CBOR Encoding Type | Default Value |
+----+-----------------------+--------------------+---------------+
| 1 | SHA Variant | UINT | 6 |
| 2 | Wrapped Key | Byte String | NONE |
| 4 | Integrity Scope Flags | UINT | 0x7 |
+----+-----------------------+--------------------+---------------+
The examples use a parameter Id of '3' for the Integrity Scope Flags,
not the '4' shown here. Since the parameter Ids are just CBOR integers,
the sequential assignment with '3' would seem to make the most sense.
Section 3.7.1
Any local flags used to generate the IPPT SHOULD be placed in the
integrity scope flags security parameter for the BIB unless these
flags are expected to be correctly configured at security
verifiers and acceptors in the network.
Just to confirm: do we want "SHOULD ... unless" or "MUST ... unless"?
Section 4.2
NOTE: The security context identifier and security context
parameters of the security block are not included as additional
authenticated data because these parameters, by definition, are
those needed to verify or accept the security service.
Therefore, it is expected that changes to these values would
result in failures at security verifiers and security acceptors.
As for the BIB, this note seems only mostly true.
Section 4.3.2
When not provided, implementations SHOULD assume a value of 3
(indicating use of A256GCM), unless an alternate default is
[same comment about "SHOULD ... unless" as above]
Section 4.5
The security provided by block ciphers is reduced as more data is
processed with the same key. The total number of bytes processed
with a single key for AES-GCM is recommended to be less than 2^64, as
described in Appendix B of [AES-GCM].
The treatment in Appendix B seems to be specific to the authentication
functionality (and seems to refer to number of *blocks*, not number of
*bytes*); section 8.3 of that document has additional guidance on
overall invocations of the authenticated encryption function, that
include smaller limits that apply to the number of invocations of the
function.
Section 4.6
The pairing of an IV and a security key MUST be unique. An IV
MUST NOT be used with a security key more than one time. If an IV
I believe that the use with the *encryption* function is the risky one.
This is good, because if IV reuse with decryption was problematic, our
use of AES-KW would induce pretty strong requirements for state-keeping
on verifiers/recipients in order to meet this requirement that could be
operationally challenging!
As discussed in Appendix B of [AES-GCM], implementations SHOULD
limit the number of unsuccessful verification attempts for each
key to reduce the likelihood of guessing tag values.
This type of check would also have potential issues with state-keeping
when AES-KW is used, since an attacker could cause a large number of
keys to have been used at least once.
Section 4.8.2
The authentication tag MUST be present in the BCB security context
parameters field if additional authenticated data are defined for
the BCB (either in the AAD scope flags parameter or as specified
by local policy). This tag MUST be 128 bits in length.
I think the authentication tag always needs to be present, not "just"
when there is AAD used.
Section 7
I see that RFC 5649 (or really, RFC 3537) is also available as a
reference for an AES-KW algorithm, and that the NIST reference indicates
that the RFCs are "essentially equivalent" to what is specified in the
NIST reference. My understanding is that we have a mild preference for
IETF references over external references when a choice is available.
Likewise, RFC 2104 is available as an HMAC reference.
Section A.1.4
Is the final "full output bundle" supposed to include the payload block
after the BIB block? I do not see it...
NITS
Section 3.1
The BIB-HMAC-SHA2 security context provides a keyed hash over a set
of plain text information. This context uses the Secure Hash
Algorithm 2 (SHA-2) discussed in [SHS] combined with the HMAC keyed
hash discussed in [HMAC].
I think s/keyed hash/keyed-hash Message Authentication Code (MAC)/.
Section 3.3.3
Bits in this field represent additional information to be included
when generating an integrity signature over the security target.
My preference is to avoid using the word "signature" to describe a MAC,
but I recognize that there is some precedent for using "signature" in
this manner. (I won't mention it again for this document.)
Section 3.5
HMAC keys used with this context MUST be symmetric and MUST have a
key length equal to the output of the HMAC. For this reason, HMAC
keys will be integer divisible by 8 bytes and special padding-aware
AES key wrap algorithms are not needed.
s/HMAC Keys will be/HMAC key lengths will be/
Section 4.2
Keys used with this context MUST be symmetric and MUST have a key
length equal to the key length defined in the security context
parameters or as defined by local security policy at security
verifiers and acceptors. For this reason, content-encrypting keys
will be integer divisible by 8 bytes and special padding-aware AES
key wrap algorithms are not needed.
Similarly, s/content-encrypting keys will be/content-encrypting key
lengths will be/.
Section 4.7.1
The plain text used during encryption MUST be calculated as the
single, definite-length CBOR byte string representing the block-type-
specific data field of the security target excluding the CBOR byte
string identifying byte and optional CBOR byte string length field.
I don't think I see why the CBOR byte string length field is "optional"
in this scenario. (Likewise for decryption.)
| 18ED | 18 | ED |
+------------------------------+---------+--------------------------+
| C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF |
I'm having trouble decoding the "CBOR part"s here; in particular, I
expected to see the major type 2 and CBOR "argument" with the length of
the byte string, which '4C' seems to match up with for the second
example, but not be present for the first example. Are '18' and 'C2'
supposed to be CBOR tags?
Section 4.8.1
The key length used by this security context MUST be considered
when setting the AES variant security parameter for the BCB if it
differs from the default AES variant. Otherwise, the AES variant
The "MUST be considered" language feels odd to me (what does
"considered" mean?); the "SHOULD be added as the [parameter] if it
differs from the default" languaged used for the SHA2 output length
feels more natural to me.
Section 4.8.2
During encryption, five inputs are prepared for input to the AES/GCM
cipher: the decryption key, the IV, the security target cipher text
s/encryption/decryption/
Section 6.2
In the event that a key is compromised, any security operations
using a security context associated with that key SHOULD also be
considered compromised. This means that the BIB-HMAC-SHA2
security context SHOULD NOT provide integrity when used with a
compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality
when used with a compromised key.
I'm a little confused by the phrasing "SHOULD NOT provide
[confidentiality/integrity]", since the reality is more along the lines
of that they will not do so, factually speaking. Perhaps the intent is
that the "SHOUL NOT be treated as providing" the indicated properties?
Section 6.4
The AES key wrap (AES-KW) algorithm used by the security contexts in
this document does not use an initialization vector and does not
require any key padding. [...]
Very pedantically, I think that AES-KW does not use a per-invocation IV
(there is a single globally constant IV used as input to the AES cipher
operation).
Section A.1.4
I suggest using lowercase hex digits consistently.
Section A.3.1.2
What do the chevrons around "300" indicate?
Section A.3.5, A.4.5
I suggest consistently using lowercase hex digits here as well. (It
shows up when I try to diff a manually assembled bundle against the
encoded output shown here.)
From nobody Wed Jun 30 13:12:32 2021
Return-Path:
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEF83A294B; Wed, 30 Jun 2021 13:12:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker
To: "The IESG"
Cc: draft-ietf-dtn-bpsec-default-sc@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org, Scott.C.Burleigh@jpl.nasa.gov, Scott.C.Burleigh@jpl.nasa.gov
X-Test-IDTracker: no
X-IETF-IDTracker: 7.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw
Message-ID: <162508394635.24113.10020117717816135182@ietfa.amsl.com>
Date: Wed, 30 Jun 2021 13:12:26 -0700
Archived-At:
Subject: [dtn] Roman Danyliw's No Objection on draft-ietf-dtn-bpsec-default-sc-08: (with COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 30 Jun 2021 20:12:26 -0000
Roman Danyliw has entered the following ballot position for
draft-ietf-dtn-bpsec-default-sc-08: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Christian Huitema for the SECDIR review.
I support the DISCUSS positions of Martin Duke, Francesca Palombini and
Benjamin Kaduk whose substantive positions have already noted what would have
been my feedback.
** Section 4.5. Per “The total number of bytes processed with a single key for
AES-GCM is recommended to be less than 2^64, as described in Appendix B of
[AES-GCM].” It would also be worth nothing that in additional to the number of
process bytes, that there is a limit of 2^32 of invocations with the same key
per Section 8.3 of [AES-GCM].
From nobody Wed Jun 30 20:49:55 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE1B3A07A3; Wed, 30 Jun 2021 20:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOuFqNRkl2Io; Wed, 30 Jun 2021 20:48:34 -0700 (PDT)
Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA383A0798; Wed, 30 Jun 2021 20:48:32 -0700 (PDT)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.16.0.43/8.16.0.43) with SMTP id 1613mUBb137163; Wed, 30 Jun 2021 23:48:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=JHUAPLDec2018; bh=xpQ0xNl4ahcUdST8qJ1WfvQZKzi8VjNnjRmRfWe6NP4=; b=YDhHWpBqL99lI6a/7C5fsT9uIlVX8OEUPL1gaNy/LvLO5hE2r0QHCGT524TOAhbocUAD aU3ncwFdJqEPawYtbh2+UtVe6NbCgbTCsQGdFqsBwQJllozpo/vKDKdfx3v5im6yMIEO 02QxmnqvtSTsqW0J+iAPef8qi37jWZkrXtyZoewHmfdGBGaiO4Cn4cY3jGXAwl7RS3HW 3XsvPi7NSjpQOzoG7Dvn1JOjaLkyzFzhNH8f8Zac7KTTnDW6Lgn/mUQMroywEMoxoL3Y Ljp2l4jNzbSM09Pf1VtJ9mqPA1CIWyURLEKUmlyXdhAf7m9WhVxHmhcRbiDgtR/stt3Y qw==
Received: from aplex04.dom1.jhuapl.edu (aplex04.dom1.jhuapl.edu [128.244.198.162]) by aplegw01.jhuapl.edu with ESMTP id 39g3hwsuh0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Jun 2021 23:48:30 -0400
X-CrossPremisesHeadersFilteredBySendConnector: APLEX04.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by APLEX04.dom1.jhuapl.edu (128.244.198.162) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 30 Jun 2021 23:48:30 -0400
Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1497.018; Wed, 30 Jun 2021 23:48:29 -0400
From: "Birrane, Edward J."
To: Benjamin Kaduk , The IESG
CC: "draft-ietf-dtn-bpsec-default-sc@ietf.org" , "dtn-chairs@ietf.org" , "dtn@ietf.org" , "Scott.C.Burleigh@jpl.nasa.gov"
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
Thread-Index: AdduH2DpUX+Ey/2MSUCWfRiQjaRYwQ==
Date: Thu, 1 Jul 2021 03:48:28 +0000
Message-ID:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.244.198.169]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OrganizationHeadersPreserved: APLEX04.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-01_01:2021-06-30, 2021-07-01 signatures=0
Archived-At:
Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 01 Jul 2021 03:48:39 -0000
QmVuamFtaW4sDQoNCiAgVGhhbmsgeW91IGZvciB0aGlzIHRob3JvdWdoIGFuZCBleGNlbGxlbnQg
cmV2aWV3LiANCg0KICBNeSByZXBsaWVzIGFyZSBpbi1saW5lIGJlbG93LCBhbmQgSSBoYXZlIGVu
dW1lcmF0ZWQgQ09NTUVOVFMgd2l0aCBDIyB0byBhaWQgaW4gcmVmZXJlbmNpbmcgZ29pbmcgZm9y
d2FyZDsgRElTQ1VTU2VzIHdlcmUgcHJpb3IgZW51bWVyYXRlZC4NCg0KICBXb3VsZCB0aGUgcHJv
cG9zZWQgY2hhbmdlcyBiZWxvdyBhZGRyZXNzIHlvdXIgY29uY2VybnMgcmVnYXJkaW5nIHRoaXMg
ZG9jdW1lbnQ/DQoNCi1FZA0KDQoNCi0tLQ0KRWR3YXJkIEouIEJpcnJhbmUsIElJSSwgUGguRC4g
KGhlL2hpbS9oaXMpDQpFbWJlZGRlZCBBcHBsaWNhdGlvbnMgR3JvdXAgU3VwZXJ2aXNvcg0KU3Bh
Y2UgRXhwbG9yYXRpb24gU2VjdG9yDQpKb2hucyBIb3BraW5zIEFwcGxpZWQgUGh5c2ljcyBMYWJv
cmF0b3J5DQooVykgNDQzLTc3OC03NDIzIC8gKEYpIDQ0My0yMjgtMzgzOQ0KwqAgDQoNCj4gLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IChEMSkgdGhlIGNvbnN0
cnVjdGlvbiBmb3IgdGhlIEhNQUMgaW5wdXQgcGxhaW50ZXh0IGFuZCBHQ00gQUFEIHNlZW1zIHRv
DQo+IGJlICJtYWxsZWFibGUiIGF0IHRoZSBzZWN1cml0eSBjb250ZXh0IGxheWVyIA0KPFNOSVA+
DQo+IFNvLCBJIHRoaW5rIHdlIG5lZWQgdG8gaW5jbHVkZSBhdCBsZWFzdCB0aGUgc2NvcGUgZmxh
Z3MgYXMgcGFydCBvZiB0aGUgSVBQVC9BQUQNCj4gaW4gb3JkZXIgdG8gcHJvdmlkZSBpbmplY3Rp
dml0eS4gIEl0IG1pZ2h0IGJlIHdvcnRoIGNvbnNpZGVyaW5nIGFkZGluZw0KPiBhZGRpdGlvbmFs
IGZyYW1pbmcgYW5kIHR5cGluZyB0byBtYWtlIGNsZWFyIGJvdW5kYXJpZXMgYmV0d2VlbiB0aGUN
Cj4gZGlmZmVyZW50IHBhcnRzIG9mIHRoZSBJUFBUL0FBRCwgYnV0IG15IGN1cnJlbnQgdW5kZXJz
dGFuZGluZyBpcyB0aGF0IGl0DQo+IHdvdWxkIG5vdCBiZSBzdHJpY3RseSBuZWNlc3NhcnkgdG8g
ZG8gc28uDQoNCkQxOiBBZ3JlZSB3aXRoIHByb3Bvc2VkIGNoYW5nZS4gQXBwbHkgaW4gYSAtMDku
DQoNCkFncmVlIHRoYXQgaW5jbHVkaW5nIHRoZSBzY29wZSBmbGFncyBhcyBwYXJ0IG9mIHRoZSBI
TUFDIGlucHV0IHBsYWludGV4dCBhbmQgR0NNIEFBRCB3b3VsZCBwcmV2ZW50IHRoZSBjb25kaXRp
b24geW91IGRlc2NyaWJlLCBhcyB0aGV5IHdvdWxkIHNwZWNpZnkgdGhlIGZpZWxkcyB0byBiZSBp
bmNsdWRlZCBhbmQgdGhlIG9yZGVyIGluIHdoaWNoIHRoZXkgYXJlIHRvIGJlIGluY2x1ZGVkLg0K
DQpSZWNvbW1lbmQgdXBkYXRpbmcgdGhlIElQUFQgYW5kIEFBRCBjb25zdHJ1Y3Rpb24gYWxnb3Jp
dGhtcyB0byBpbmNsdWRlIHRoZSBzY29wZSBmbGFncy4NCg0KIA0KPiAoRDIpIFRoZXJlIHNlZW1z
IHRvIGJlIHNvbWUgcmlzayBhc3NvY2lhdGVkIHdpdGggdGhlIGN1cnJlbnQgSE1BQw0KPiBjb25z
dHJ1Y3Rpb24sIHNpbmNlIHRoZSBITUFDIHdpdGggYSBnaXZlbiBrZXkgb3ZlciBhIGdpdmVuIHBs
YWludGV4dCB3aWxsIGJlDQo+IHRoZSBzYW1lIGVhY2ggdGltZSBpdCBpcyBjYWxjdWxhdGVkLiAN
CjxTTklQPg0KPiAgSSBzdXNwZWN0IHRoYXQgdGhlcmUgbWF5IGJlIHNvbWUgb3BlcmF0aW9uYWwN
Cj4gaXNzdWVzIHdpdGggdGhlICJ1bmlxdWUgbm9uY2UgcGVyIEhNQUMiIGFwcHJvYWNoIHRoYXQg
d291bGQgbWFrZSBpdCBub3QNCj4gdGVycmlibHkgcmVsaWFibGUgaW4gcHJhY3RpY2UsIGJ1dCAi
dXNlIGEgY29uc3RhbnQtdGltZSBjb21wYXJpc29uIiBzaG91bGQgYmUNCj4gZmFpcmx5IHN0cmFp
Z2h0Zm9yd2FyZC4NCg0KRDI6IEFncmVlIHdpdGggcHJvcG9zZWQgY2hhbmdlLiBBcHBseSBpbiBh
IC0wOS4NCg0KTWFpbnRhaW5pbmcgdGhlIHN0YXRlIGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0
aCBhIG5vbmNlIGluIGEgRFROIHdpbGwsIGFzIHlvdSBtZW50aW9uLCBiZSBwcm9ibGVtYXRpYy4g
VXNpbmcgYSBjb25zdGFudC10aW1lIGNvbXBhcmlzb24gdG8gbWFrZSB0aGUgc29mdHdhcmUgaXNv
Y2hyb25vdXMgd291bGQgbWl0aWdhdGUgYSB0aW1pbmcgYXR0YWNrLiAgDQoNClRoZSBxdWVzdGlv
biBpcyB3aGV0aGVyIHRvIG1ha2UgYSBjb25zdGFudC10aW1lIGNvbXBhcmlzb24gYSBTSE9VTEQg
b3IgYSBNVVNULiBDZXJ0YWlubHkgbWFraW5nIHN1Y2ggYSBmdW5jdGlvbiBpcyBub3QgZGlmZmlj
dWx0LCBidXQgaXQgbWlnaHQgbm90IGJlIHN0cmljdGx5IG5lY2Vzc2FyeSB3aGVuLCBzYXksIG9y
Yml0aW5nIE1hcnMuIA0KDQpJIHByb3Bvc2UgYWRkaW5nIHRoaXMgdG9waWMgaW4gc2VjdXJpdHkg
Y29uc2lkZXJhdGlvbnMsIHN0YXRpbmcgdGhhdCBhIGNvbnN0YW50LXRpbWUgY29tcGFyaXNvbiBT
SE9VTEQgYmUgdXNlZCB0byBwcm90ZWN0IGFnYWluc3QgdGltaW5nIGF0dGFja3MgYW5kIGFic2Vu
dCB0aGF0LCB0aGUgaW1wYWN0IG9mIHNpZGUtY2hhbm5lbCBhbmQgdGltaW5nIGF0dGFja3MgbXVz
dCAobG93ZXJjYXNlKSBiZSBjb25zaWRlcmVkIGFzIHBhcnQgb2YgaW1wbGVtZW50YXRpb24uDQoN
Cg0KIA0KPiAoRDMpIFdoaWxlIHdlIGRvIHByb3ZpZGUgdGhlIHN0YW5kYXJkIGd1aWRhbmNlIGFn
YWluc3QgdXNpbmcgYW55IGdpdmVuIGtleQ0KPiB3aXRoIG1vcmUgdGhhbiBvbmUgYWxnb3JpdGht
IChlLmcuLCB3aXRoIEhNQUMtU0hBLTI1NiBhbmQgQUVTMjU2LUdDTSksDQo+IHRoZXJlIHNlZW0g
dG8gYmUgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyByZWxldmFudCB0byB0aGlzIHByb3RvY29s
IHRoYXQNCj4gbWVyaXQgZnVydGhlciBkaXNjdXNzaW9uIGluIHRoZSBzZWN1cml0eSBjb25zaWRl
cmF0aW9ucy4NCjxTTklQPg0KPiBhbmQgY291bGQgcHJvdmlkZSBzb21lIG1vZGVzdCBtaXRpZ2F0
aW9uDQo+IHRlY2huaXF1ZXMgc3VjaCBhcyB1c2luZyBkaXN0aW5jdCBLRUtzIGZvciByZWNlaXZp
bmcgd3JhcHBlZCBrZXlzIHRoYXQgaGF2ZQ0KPiBkaWZmZXJlbnQgaW50ZW5kZWQgdXNhZ2UuICBU
aGF0IGlzLCBvbmUgS0VLIGZvciByZWNlaXZpbmcgQUVTIGtleXMsIGFub3RoZXINCj4gZm9yIEhN
QUMga2V5cywgZXRjLi4gIEF0dGFjaGluZyBjb250ZXh0IChpbnRlbmRlZCBhbGdvcml0aG0sIGV0
Yy4pIHRvIHRoZSBLRUsNCj4gYWxsb3dzIHN1Y2ggY29udGV4dCB0byBiZSBpbmRpcmVjdGx5IGF0
dGFjaGVkIHRvIHRoZSByZWNlaXZlZCB3cmFwcGVkIGtleXMsDQo+IHdoaWNoIG90aGVyd2lzZSB3
b3VsZCBjb21lIHdpdGhvdXQgbXVjaCBjb250ZXh0IGZvciBpbnRlbmRlZCB1c2FnZS4NCg0KRDM6
IEkgYWdyZWUgdGhhdCBLRUsgcmUtdXNlIGFjcm9zcyBjb250ZXh0cyBpcyBwcm9ibGVtYXRpYyBh
bmQgd2Ugc2hvdWxkIGFkZHJlc3MgdGhpcyBpbiBhIC0wOS4NCg0KU2luY2UgdGhlIEtFSyBpcyBu
b3QgaW5jbHVkZWQgaW4gdGhlIHNlY3VyaXR5IGJsb2NrIGl0c2VsZiwgdGhpcyBzZWVtcyB0byBi
ZSBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNv
bnNpZGVyYXRpb25zIC0gbmFtZWx5IHRoYXQgdGhlIHNhbWUgS0VLIE1VU1QgTk9UIGJlIHVzZWQg
Zm9yIG90aGVyIHNlY3VyaXR5IGNvbnRleHRzIChjZXJ0YWlubHkgbm90IGJldHdlZW4gSE1BQyBh
bmQgR0NNKS4gQSBjb21wbGlhbnQgc2VjdXJpdHkgc291cmNlIHdvdWxkIG5vdCB1c2UgdGhlIHNh
bWUgS0VLIHRvIHdyYXAgYm90aCBhbiBITUFDLVNIQS0yNTYgYW5kIGFuIEFFUzI1Ni1HQ00ga2V5
LiBBbmQgYSBzZWN1cml0eSB2ZXJpZmllciBvciBzZWN1cml0eSBhY2NlcHRvciB3b3VsZCBub3Qg
dXNlIHRoZSBzYW1lIEtFSyB0byB1bndyYXAgc3VjaCBrZXlzLg0KDQoNCg0KPiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gU2VjdGlvbiAzLjENCj4gDQo+ICAg
IEJJQi1ITUFDLVNIQTIgc3VwcG9ydHMgdGhyZWUgdmFyaWFudHMgb2YgSE1BQy1TSEEsIGJhc2Vk
IG9uIHRoZQ0KPiAgICBzdXBwb3J0ZWQgbGVuZ3RoIG9mIHRoZSBTSEEtMiBoYXNoIHZhbHVlLiAg
VGhlc2UgdmFyaWFudHMgY29ycmVzcG9uZA0KPiAgICB0byAiSE1BQyAyNTYvMjU2IiwgIkhNQUMg
Mzg0LzM4NCIsIGFuZCAiSE1BQyA1MTIvNTEyIiBhcyBkZWZpbmVkIGluDQo+ICAgIFtSRkM4MTUy
XSBUYWJsZSA3OiBITUFDIEFsZ29yaXRobSBWYWx1ZXMuICBbLi4uXQ0KPiANCj4gVGhpcyBpcyB1
bmZvcnR1bmF0ZSB0aW1pbmcsIEkgc3VwcG9zZSwgYnV0IFJGQyA4MTUyIGlzIGdvaW5nIHRvIGJl
IHJlcGxhY2VkDQo+IGltbWluZW50bHkgYnkgZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtYWxn
cyBhbmQgZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtDQo+IHN0cnVjdCwgd2hpY2ggYXJlIHZp
cnR1YWxseSBjZXJ0YWluIHRvIGJlIHB1Ymxpc2hlZCBhcyBSRkNzIGJlZm9yZSB0aGlzDQo+IGRv
Y3VtZW50Lg0KDQpDMTogQ29uY3VyLiBBZGRyZXNzIGluIGEgLTA5Lg0KDQpUaGUgc2xpZ2h0IHBy
ZWZlcmVuY2UgZm9yIHVzaW5nIFJGQzgxNTIgd2FzIHRoYXQgaXQgd2FzIHB1Ymxpc2hlZCBhbmQg
dGhlIGluZm9ybWF0aW9uIHRoYXQgdGhlIGRlZmF1bHQgc2VjdXJpdHkgY29udGV4dCByZWZlcmVu
Y2VzIHdhcyB1bmNoYW5nZWQuIElmIHdlIGFyZSB2aXJ0dWFsbHkgY2VydGFpbiB0aGF0IGNoYW5n
aW5nIHJlZmVyZW5jZXMgZG9lcyBub3QgaW50cm9kdWNlIGEgdGltaW5nIGRlcGVuZGVuY3kgd2Ug
Y2FuIHVwZGF0ZSB0aGlzIGluIGEgLTA5Lg0KDQogDQo+IFNlY3Rpb24gMy4yDQo+IA0KPiAgICAg
ICAgTk9URTogVGhlIHNlY3VyaXR5IGNvbnRleHQgaWRlbnRpZmllciBhbmQgc2VjdXJpdHkgY29u
dGV4dA0KPiAgICAgICAgcGFyYW1ldGVycyBvZiB0aGUgc2VjdXJpdHkgYmxvY2sgYXJlIG5vdCBp
bmNsdWRlZCBpbiB0aGUgSVBQVA0KPiAgICAgICAgYmVjYXVzZSB0aGVzZSBwYXJhbWV0ZXJzLCBi
eSBkZWZpbml0aW9uLCBhcmUgcmVxdWlyZWQgdG8gdmVyaWZ5DQo+ICAgICAgICBvciBhY2NlcHQg
dGhlIHNlY3VyaXR5IHNlcnZpY2UuICBTdWNjZXNzZnVsIHZlcmlmaWNhdGlvbiBhdA0KPiAgICAg
ICAgc2VjdXJpdHkgdmVyaWZpZXJzIGFuZCBzZWN1cml0eSBhY2NlcHRvcnMgaW1wbGllcyB0aGF0
IHRoZXNlDQo+ICAgICAgICBwYXJhbWV0ZXJzIHdlcmUgdW5jaGFuZ2VkIHNpbmNlIGJlaW5nIHNw
ZWNpZmllZCBhdCB0aGUgc2VjdXJpdHkNCj4gICAgICAgIHNvdXJjZS4NCj4gDQo+IChyZWxhdGVk
IHRvIEQxLCBidXQgZGlzdGluY3QuLi4pDQo+IFRoaXMgc2VlbXMgdG8gYmUgb25seSBtb3N0bHkg
dHJ1ZSAuLi4gaWYgc29tZSBvdGhlciBzZWN1cml0eSBjb250ZXh0IHdhcw0KPiBjcmVhdGVkIHRo
YXQgYWxzbyB1c2VkIEhNQUMtU0hBMiBpdCBzZWVtcyBsaWtlIHRoZSBzYW1lIG91dHB1dCBtaWdo
dCBiZQ0KPiBvYnRhaW5lZCBvciB2YWxpZGF0ZWQgYWNyb3NzIHNlY3VyaXR5IGNvbnRleHRzIC4u
LiBidXQgdGhpcyB3b3VsZCBvbmx5IGNhdXNlDQo+IHByb2JsZW1zIGlmIHRoZXJlIHdlcmUgZGlm
ZmVyZW50IHNlbWFudGljcyBhZmZvcmRlZCB0byB0aGUgZGlmZmVyZW50IHNlY3VyaXR5DQo+IGNv
bnRleHRzIGluIHNvbWUgd2F5LiAgQW55IGF0dGFjayB3b3VsZCBhbHNvIGJlIHN0eW1pZWQgaWYg
dGhlIGhvbmVzdA0KPiBwYXJ0aWNpcGFudHMgd2VyZSByaWdvcm91cyBpbiBzZXBhcmF0aW9uIG9m
IGtleXMsIHdpdGggYW55IGdpdmVuIGtleSBiZWluZw0KPiB1c2VkIHdpdGggb25seSBvbmUgc2Vj
dXJpdHkgY29udGV4dC4NCg0KQzI6IENvbmN1ci4gICBBZGRyZXNzIGluIGEgLTA5Lg0KDQpBcyBw
YXJ0IG9mIHRoZSBjb21tZW50cyBvbiBEMywgd2Ugc2hvdWxkIHJlcXVpcmUgdGhhdCBLRUtzIHVz
aW5nIGluIHRoZXNlIHNlY3VyaXR5IGNvbnRleHRzIG5vdCBiZSByZXVzZWQgaW4gYW55IG90aGVy
IHNlY3VyaXR5IGNvbnRleHQuDQoNCg0KPiBTZWN0aW9uIDMuMy4zDQo+IA0KPiAgICBJbnRlZ3Jp
dHkgc2NvcGUgZmxhZ3MgdGhhdCBhcmUgdW5yZWNvZ25pemVkIE1VU1QgYmUgaWdub3JlZCwgYXMN
Cj4gICAgZnV0dXJlIGRlZmluaXRpb25zIG9mIGFkZGl0aW9uYWwgZmxhZ3MgbWlnaHQgbm90IGJl
IGludGVncmF0ZWQNCj4gICAgc2ltdWx0YW5lb3VzbHkgaW50byBzZWN1cml0eSBjb250ZXh0IGlt
cGxlbWVudGF0aW9ucyBvcGVyYXRpbmcgYXQgYWxsDQo+ICAgIG5vZGVzLg0KPiANCj4gSXQncyBu
b3QgZW50aXJlbHkgY2xlYXIgaG93IHVzZWZ1bCBhIG1hbmRhdGUgdG8gaWdub3JlIHVucmVjb2du
aXplZCBmbGFncyB3aWxsDQo+IGJlLCBpZiB0aGUgZmxhZ3Mgd291bGQgY2hhbmdlIHRoZSBwbGFp
bnRleHQgaW5wdXQgYW5kIHRodXMgdGhlIHZhbHVlIG9mIHRoZQ0KPiBITUFDIG91dHB1dC4gIEkg
Z3Vlc3MgbWF5YmUgdGhlIGludGVudCBpcyBqdXN0IHRoYXQgaW50ZXJtZWRpYXRlIG5vdGVzDQo+
IHByb2Nlc3NpbmcgYSBidW5kbGUgYnV0IG5vdCBhY3RpbmcgYXMgc2VjdXJpdHkgYWNjZXB0b3Ig
c2hvdWxkIHBhc3MgdGhyb3VnaA0KPiBzdWNoIGZsYWdzIHVuY2hhbmdlZD8NCg0KDQpDMzogQ29u
Y3VyLiBBZGRyZXNzIGluIGEgLTA5Lg0KDQpBZ3JlZSB0aGlzIGlzIGFtYmlndW91cy4gUGFydGlj
dWxhcmx5IGlmIHRoZSBzY29wZSBmbGFncyBhcmUgbm93IHBhcnQgb2YgdGhlIElQUFQvQUFELCB0
aGV5IGNhbm5vdCBiZSBjaGFuZ2VkIGluLXRyYW5zaXQuDQoNCg0KPiBTZWN0aW9uIDMuMy40DQo+
IA0KPiAgICAgICAgICAgICAgICAgICAgICBCSUItSE1BQy1TSEEyIFNlY3VyaXR5IFBhcmFtZXRl
cnMNCj4gDQo+ICAgICArLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t
LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQo+ICAgICB8IElkIHwgICAgICAgICAgTmFtZSAgICAg
ICAgIHwgQ0JPUiBFbmNvZGluZyBUeXBlIHwgRGVmYXVsdCBWYWx1ZSB8DQo+ICAgICArLS0tLSst
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t
LS0rDQo+ICAgICB8IDEgIHwgICAgICBTSEEgVmFyaWFudCAgICAgIHwgICAgICAgIFVJTlQgICAg
ICAgIHwgICAgICAgNiAgICAgICB8DQo+ICAgICB8IDIgIHwgICAgICBXcmFwcGVkIEtleSAgICAg
IHwgICAgQnl0ZSBTdHJpbmcgICAgIHwgICAgICBOT05FICAgICB8DQo+ICAgICB8IDQgIHwgSW50
ZWdyaXR5IFNjb3BlIEZsYWdzIHwgICAgICAgIFVJTlQgICAgICAgIHwgICAgICAweDcgICAgICB8
DQo+ICAgICArLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t
LSstLS0tLS0tLS0tLS0tLS0rDQo+IA0KPiBUaGUgZXhhbXBsZXMgdXNlIGEgcGFyYW1ldGVyIElk
IG9mICczJyBmb3IgdGhlIEludGVncml0eSBTY29wZSBGbGFncywgbm90IHRoZQ0KPiAnNCcgc2hv
d24gaGVyZS4gIFNpbmNlIHRoZSBwYXJhbWV0ZXIgSWRzIGFyZSBqdXN0IENCT1IgaW50ZWdlcnMs
IHRoZQ0KPiBzZXF1ZW50aWFsIGFzc2lnbm1lbnQgd2l0aCAnMycgd291bGQgc2VlbSB0byBtYWtl
IHRoZSBtb3N0IHNlbnNlLg0KDQoNCkM0OiBDb25jdXIuIEFkZHJlc3MgaW4gYSAtMDkuDQoNCiAN
Cj4gU2VjdGlvbiAzLjcuMQ0KPiANCj4gICAgICAgQW55IGxvY2FsIGZsYWdzIHVzZWQgdG8gZ2Vu
ZXJhdGUgdGhlIElQUFQgU0hPVUxEIGJlIHBsYWNlZCBpbiB0aGUNCj4gICAgICAgaW50ZWdyaXR5
IHNjb3BlIGZsYWdzIHNlY3VyaXR5IHBhcmFtZXRlciBmb3IgdGhlIEJJQiB1bmxlc3MgdGhlc2UN
Cj4gICAgICAgZmxhZ3MgYXJlIGV4cGVjdGVkIHRvIGJlIGNvcnJlY3RseSBjb25maWd1cmVkIGF0
IHNlY3VyaXR5DQo+ICAgICAgIHZlcmlmaWVycyBhbmQgYWNjZXB0b3JzIGluIHRoZSBuZXR3b3Jr
Lg0KPiANCj4gSnVzdCB0byBjb25maXJtOiBkbyB3ZSB3YW50ICJTSE9VTEQgLi4uIHVubGVzcyIg
b3IgIk1VU1QgLi4uIHVubGVzcyI/DQoNCkM1OiBDb25jdXIuIEFkZHJlc3MgaW4gYSAtMDkuDQoN
CkFncmVlIC0gdGhpcyBpcyBhIE1VU1QuLi51bmxlc3MuIA0KDQoNCj4gU2VjdGlvbiA0LjINCj4g
DQo+ICAgICAgICBOT1RFOiBUaGUgc2VjdXJpdHkgY29udGV4dCBpZGVudGlmaWVyIGFuZCBzZWN1
cml0eSBjb250ZXh0DQo+ICAgICAgICBwYXJhbWV0ZXJzIG9mIHRoZSBzZWN1cml0eSBibG9jayBh
cmUgbm90IGluY2x1ZGVkIGFzIGFkZGl0aW9uYWwNCj4gICAgICAgIGF1dGhlbnRpY2F0ZWQgZGF0
YSBiZWNhdXNlIHRoZXNlIHBhcmFtZXRlcnMsIGJ5IGRlZmluaXRpb24sIGFyZQ0KPiAgICAgICAg
dGhvc2UgbmVlZGVkIHRvIHZlcmlmeSBvciBhY2NlcHQgdGhlIHNlY3VyaXR5IHNlcnZpY2UuDQo+
ICAgICAgICBUaGVyZWZvcmUsIGl0IGlzIGV4cGVjdGVkIHRoYXQgY2hhbmdlcyB0byB0aGVzZSB2
YWx1ZXMgd291bGQNCj4gICAgICAgIHJlc3VsdCBpbiBmYWlsdXJlcyBhdCBzZWN1cml0eSB2ZXJp
ZmllcnMgYW5kIHNlY3VyaXR5IGFjY2VwdG9ycy4NCj4gDQo+IEFzIGZvciB0aGUgQklCLCB0aGlz
IG5vdGUgc2VlbXMgb25seSBtb3N0bHkgdHJ1ZS4NCg0KQzY6IENvbmN1ci4gQWRkcmVzcyBpbiBh
IC0wOS4NCg0KQmFzZWQgb24gRDEsIHVwZGF0ZSB0aGUgdGV4dCB0byBjbGFyaWZ5IHRoaXMgbm90
ZS4NCg0KDQo+IFNlY3Rpb24gNC4zLjINCj4gDQo+ICAgIFdoZW4gbm90IHByb3ZpZGVkLCBpbXBs
ZW1lbnRhdGlvbnMgU0hPVUxEIGFzc3VtZSBhIHZhbHVlIG9mIDMNCj4gICAgKGluZGljYXRpbmcg
dXNlIG9mIEEyNTZHQ00pLCB1bmxlc3MgYW4gYWx0ZXJuYXRlIGRlZmF1bHQgaXMNCj4gDQo+IFtz
YW1lIGNvbW1lbnQgYWJvdXQgIlNIT1VMRCAuLi4gdW5sZXNzIiBhcyBhYm92ZV0NCg0KQzc6IENv
bmN1ci4gQWRkcmVzcyBpbiBhIC0wOS4NCg0KDQo+IFNlY3Rpb24gNC41DQo+IA0KPiAgICBUaGUg
c2VjdXJpdHkgcHJvdmlkZWQgYnkgYmxvY2sgY2lwaGVycyBpcyByZWR1Y2VkIGFzIG1vcmUgZGF0
YSBpcw0KPiAgICBwcm9jZXNzZWQgd2l0aCB0aGUgc2FtZSBrZXkuICBUaGUgdG90YWwgbnVtYmVy
IG9mIGJ5dGVzIHByb2Nlc3NlZA0KPiAgICB3aXRoIGEgc2luZ2xlIGtleSBmb3IgQUVTLUdDTSBp
cyByZWNvbW1lbmRlZCB0byBiZSBsZXNzIHRoYW4gMl42NCwgYXMNCj4gICAgZGVzY3JpYmVkIGlu
IEFwcGVuZGl4IEIgb2YgW0FFUy1HQ01dLg0KPiANCj4gVGhlIHRyZWF0bWVudCBpbiBBcHBlbmRp
eCBCIHNlZW1zIHRvIGJlIHNwZWNpZmljIHRvIHRoZSBhdXRoZW50aWNhdGlvbg0KPiBmdW5jdGlv
bmFsaXR5IChhbmQgc2VlbXMgdG8gcmVmZXIgdG8gbnVtYmVyIG9mICpibG9ja3MqLCBub3QgbnVt
YmVyIG9mDQo+ICpieXRlcyopOyBzZWN0aW9uIDguMyBvZiB0aGF0IGRvY3VtZW50IGhhcyBhZGRp
dGlvbmFsIGd1aWRhbmNlIG9uIG92ZXJhbGwNCj4gaW52b2NhdGlvbnMgb2YgdGhlIGF1dGhlbnRp
Y2F0ZWQgZW5jcnlwdGlvbiBmdW5jdGlvbiwgdGhhdCBpbmNsdWRlIHNtYWxsZXINCj4gbGltaXRz
IHRoYXQgYXBwbHkgdG8gdGhlIG51bWJlciBvZiBpbnZvY2F0aW9ucyBvZiB0aGUgZnVuY3Rpb24u
DQoNCkM4OiBDb25jdXIuIEFkZHJlc3MgaW4gYSAtMDkuDQoNClRoZSB2YWx1ZSBvZiBwbGFjaW5n
IHBvaW50ZXJzIHRvLCBhbmQgcmVwZWF0aW5nIGluZm9ybWF0aW9uIGZyb20sIG90aGVyIGRvY3Vt
ZW50cyBpcyB0byBoZWxwIGltcGxlbWVudGVycywgYW5kIGFncmVlIHRoaXMgaXMgYWRkaXRpb25h
bCBpbmZvcm1hdGlvbiB0aGF0IHdvdWxkIGhlbHAgaW1wbGVtZW50ZXJzLg0KDQo+IFNlY3Rpb24g
NC42DQo+IA0KPiAgICAgICBUaGUgcGFpcmluZyBvZiBhbiBJViBhbmQgYSBzZWN1cml0eSBrZXkg
TVVTVCBiZSB1bmlxdWUuICBBbiBJVg0KPiAgICAgICBNVVNUIE5PVCBiZSB1c2VkIHdpdGggYSBz
ZWN1cml0eSBrZXkgbW9yZSB0aGFuIG9uZSB0aW1lLiAgSWYgYW4gSVYNCj4gDQo+IEkgYmVsaWV2
ZSB0aGF0IHRoZSB1c2Ugd2l0aCB0aGUgKmVuY3J5cHRpb24qIGZ1bmN0aW9uIGlzIHRoZSByaXNr
eSBvbmUuDQo+IFRoaXMgaXMgZ29vZCwgYmVjYXVzZSBpZiBJViByZXVzZSB3aXRoIGRlY3J5cHRp
b24gd2FzIHByb2JsZW1hdGljLCBvdXIgdXNlIG9mDQo+IEFFUy1LVyB3b3VsZCBpbmR1Y2UgcHJl
dHR5IHN0cm9uZyByZXF1aXJlbWVudHMgZm9yIHN0YXRlLWtlZXBpbmcgb24NCj4gdmVyaWZpZXJz
L3JlY2lwaWVudHMgaW4gb3JkZXIgdG8gbWVldCB0aGlzIHJlcXVpcmVtZW50IHRoYXQgY291bGQg
YmUNCj4gb3BlcmF0aW9uYWxseSBjaGFsbGVuZ2luZyENCg0KDQpDOTogQ29uY3VyISBBZGRyZXNz
IGluIGEgLTA5Lg0KDQpUaGlzIHNob3VsZCBiZSBjbGFyaWZpZWQuDQoNCg0KPiAgICAgICBBcyBk
aXNjdXNzZWQgaW4gQXBwZW5kaXggQiBvZiBbQUVTLUdDTV0sIGltcGxlbWVudGF0aW9ucyBTSE9V
TEQNCj4gICAgICAgbGltaXQgdGhlIG51bWJlciBvZiB1bnN1Y2Nlc3NmdWwgdmVyaWZpY2F0aW9u
IGF0dGVtcHRzIGZvciBlYWNoDQo+ICAgICAgIGtleSB0byByZWR1Y2UgdGhlIGxpa2VsaWhvb2Qg
b2YgZ3Vlc3NpbmcgdGFnIHZhbHVlcy4NCj4gDQo+IFRoaXMgdHlwZSBvZiBjaGVjayB3b3VsZCBh
bHNvIGhhdmUgcG90ZW50aWFsIGlzc3VlcyB3aXRoIHN0YXRlLWtlZXBpbmcgd2hlbg0KPiBBRVMt
S1cgaXMgdXNlZCwgc2luY2UgYW4gYXR0YWNrZXIgY291bGQgY2F1c2UgYSBsYXJnZSBudW1iZXIg
b2Yga2V5cyB0byBoYXZlDQo+IGJlZW4gdXNlZCBhdCBsZWFzdCBvbmNlLg0KDQpDMTA6IE5vIGlz
c3VlLiBBZGRyZXNzIGluIGEgLTA5Lg0KDQpJIGNhbiBhZGQgdGhpcyB0ZXh0IHRvIHRoZSBwYXJh
Z3JhcGggZGlzY3Vzc2luZyB0aGlzLCBidXQgZG8gbm90IGhhdmUgaW1wbGVtZW50YXRpb24gZ3Vp
ZGFuY2UgYXNzb2NpYXRlZCB3aXRoIGl0Lg0KDQo+IFNlY3Rpb24gNC44LjINCj4gDQo+ICAgICAg
IFRoZSBhdXRoZW50aWNhdGlvbiB0YWcgTVVTVCBiZSBwcmVzZW50IGluIHRoZSBCQ0Igc2VjdXJp
dHkgY29udGV4dA0KPiAgICAgICBwYXJhbWV0ZXJzIGZpZWxkIGlmIGFkZGl0aW9uYWwgYXV0aGVu
dGljYXRlZCBkYXRhIGFyZSBkZWZpbmVkIGZvcg0KPiAgICAgICB0aGUgQkNCIChlaXRoZXIgaW4g
dGhlIEFBRCBzY29wZSBmbGFncyBwYXJhbWV0ZXIgb3IgYXMgc3BlY2lmaWVkDQo+ICAgICAgIGJ5
IGxvY2FsIHBvbGljeSkuICBUaGlzIHRhZyBNVVNUIGJlIDEyOCBiaXRzIGluIGxlbmd0aC4NCj4g
DQo+IEkgdGhpbmsgdGhlIGF1dGhlbnRpY2F0aW9uIHRhZyBhbHdheXMgbmVlZHMgdG8gYmUgcHJl
c2VudCwgbm90ICJqdXN0Ig0KPiB3aGVuIHRoZXJlIGlzIEFBRCB1c2VkLg0KDQpDMTE6IENvbmN1
ciEgQWRkcmVzcyBpbiBhIC0wOS4NCg0KVGhhbmsgeW91IGZvciB0aGlzIGNhdGNoLg0KDQo+IFNl
Y3Rpb24gNw0KPiANCj4gSSBzZWUgdGhhdCBSRkMgNTY0OSAob3IgcmVhbGx5LCBSRkMgMzUzNykg
aXMgYWxzbyBhdmFpbGFibGUgYXMgYSByZWZlcmVuY2UgZm9yIGFuDQo+IEFFUy1LVyBhbGdvcml0
aG0sIGFuZCB0aGF0IHRoZSBOSVNUIHJlZmVyZW5jZSBpbmRpY2F0ZXMgdGhhdCB0aGUgUkZDcyBh
cmUNCj4gImVzc2VudGlhbGx5IGVxdWl2YWxlbnQiIHRvIHdoYXQgaXMgc3BlY2lmaWVkIGluIHRo
ZSBOSVNUIHJlZmVyZW5jZS4gIE15DQo+IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB3ZSBoYXZlIGEg
bWlsZCBwcmVmZXJlbmNlIGZvciBJRVRGIHJlZmVyZW5jZXMgb3Zlcg0KPiBleHRlcm5hbCByZWZl
cmVuY2VzIHdoZW4gYSBjaG9pY2UgaXMgYXZhaWxhYmxlLg0KPiANCj4gTGlrZXdpc2UsIFJGQyAy
MTA0IGlzIGF2YWlsYWJsZSBhcyBhbiBITUFDIHJlZmVyZW5jZS4NCg0KQzEyOiBObyBpc3N1ZS4g
QWRkcmVzcyBpbiBhIC0wOS4NCg0KRmluZSB0byByZWZlcmVuY2UgSUVURiByZWZlcmVuY2VzIG92
ZXIgb3RoZXJzIGlmIHRoZXkgYXJlIGVxdWl2YWxlbnQuDQoNCj4gU2VjdGlvbiBBLjEuNA0KPiAN
Cj4gSXMgdGhlIGZpbmFsICJmdWxsIG91dHB1dCBidW5kbGUiIHN1cHBvc2VkIHRvIGluY2x1ZGUg
dGhlIHBheWxvYWQgYmxvY2sgYWZ0ZXINCj4gdGhlIEJJQiBibG9jaz8gIEkgZG8gbm90IHNlZSBp
dC4uLg0KDQpDMTM6IFRoYXQgY2FuIGJlIGFkZGVkIGluIGEgLTA5Lg0KDQoNCj4gTklUUw0KPiAN
Cj4gU2VjdGlvbiAzLjENCj4gDQo+ICAgIFRoZSBCSUItSE1BQy1TSEEyIHNlY3VyaXR5IGNvbnRl
eHQgcHJvdmlkZXMgYSBrZXllZCBoYXNoIG92ZXIgYSBzZXQNCj4gICAgb2YgcGxhaW4gdGV4dCBp
bmZvcm1hdGlvbi4gIFRoaXMgY29udGV4dCB1c2VzIHRoZSBTZWN1cmUgSGFzaA0KPiAgICBBbGdv
cml0aG0gMiAoU0hBLTIpIGRpc2N1c3NlZCBpbiBbU0hTXSBjb21iaW5lZCB3aXRoIHRoZSBITUFD
IGtleWVkDQo+ICAgIGhhc2ggZGlzY3Vzc2VkIGluIFtITUFDXS4NCj4gDQo+IEkgdGhpbmsgcy9r
ZXllZCBoYXNoL2tleWVkLWhhc2ggTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlIChNQUMpLy4N
Cg0KQzE0OiBDb25jdXIuIEFkZHJlc3MgaW4gYSAtMDkuDQoNCg0KPiBTZWN0aW9uIDMuMy4zDQo+
IA0KPiAgICBCaXRzIGluIHRoaXMgZmllbGQgcmVwcmVzZW50IGFkZGl0aW9uYWwgaW5mb3JtYXRp
b24gdG8gYmUgaW5jbHVkZWQNCj4gICAgd2hlbiBnZW5lcmF0aW5nIGFuIGludGVncml0eSBzaWdu
YXR1cmUgb3ZlciB0aGUgc2VjdXJpdHkgdGFyZ2V0Lg0KPiANCj4gTXkgcHJlZmVyZW5jZSBpcyB0
byBhdm9pZCB1c2luZyB0aGUgd29yZCAic2lnbmF0dXJlIiB0byBkZXNjcmliZSBhIE1BQywgYnV0
DQo+IEkgcmVjb2duaXplIHRoYXQgdGhlcmUgaXMgc29tZSBwcmVjZWRlbnQgZm9yIHVzaW5nICJz
aWduYXR1cmUiIGluIHRoaXMgbWFubmVyLg0KPiAoSSB3b24ndCBtZW50aW9uIGl0IGFnYWluIGZv
ciB0aGlzIGRvY3VtZW50LikNCg0KQzE1OiBObyBDaGFuZ2UuDQoNCj4gU2VjdGlvbiAzLjUNCj4g
DQo+ICAgIEhNQUMga2V5cyB1c2VkIHdpdGggdGhpcyBjb250ZXh0IE1VU1QgYmUgc3ltbWV0cmlj
IGFuZCBNVVNUIGhhdmUgYQ0KPiAgICBrZXkgbGVuZ3RoIGVxdWFsIHRvIHRoZSBvdXRwdXQgb2Yg
dGhlIEhNQUMuICBGb3IgdGhpcyByZWFzb24sIEhNQUMNCj4gICAga2V5cyB3aWxsIGJlIGludGVn
ZXIgZGl2aXNpYmxlIGJ5IDggYnl0ZXMgYW5kIHNwZWNpYWwgcGFkZGluZy1hd2FyZQ0KPiAgICBB
RVMga2V5IHdyYXAgYWxnb3JpdGhtcyBhcmUgbm90IG5lZWRlZC4NCj4gDQo+IHMvSE1BQyBLZXlz
IHdpbGwgYmUvSE1BQyBrZXkgbGVuZ3RocyB3aWxsIGJlLw0KDQpDMTY6IENvbmN1ciEgQWRkcmVz
cyBpbiBhIC0wOS4NCg0KDQo+IFNlY3Rpb24gNC4yDQo+IA0KPiAgICBLZXlzIHVzZWQgd2l0aCB0
aGlzIGNvbnRleHQgTVVTVCBiZSBzeW1tZXRyaWMgYW5kIE1VU1QgaGF2ZSBhIGtleQ0KPiAgICBs
ZW5ndGggZXF1YWwgdG8gdGhlIGtleSBsZW5ndGggZGVmaW5lZCBpbiB0aGUgc2VjdXJpdHkgY29u
dGV4dA0KPiAgICBwYXJhbWV0ZXJzIG9yIGFzIGRlZmluZWQgYnkgbG9jYWwgc2VjdXJpdHkgcG9s
aWN5IGF0IHNlY3VyaXR5DQo+ICAgIHZlcmlmaWVycyBhbmQgYWNjZXB0b3JzLiAgRm9yIHRoaXMg
cmVhc29uLCBjb250ZW50LWVuY3J5cHRpbmcga2V5cw0KPiAgICB3aWxsIGJlIGludGVnZXIgZGl2
aXNpYmxlIGJ5IDggYnl0ZXMgYW5kIHNwZWNpYWwgcGFkZGluZy1hd2FyZSBBRVMNCj4gICAga2V5
IHdyYXAgYWxnb3JpdGhtcyBhcmUgbm90IG5lZWRlZC4NCj4gDQo+IFNpbWlsYXJseSwgcy9jb250
ZW50LWVuY3J5cHRpbmcga2V5cyB3aWxsIGJlL2NvbnRlbnQtZW5jcnlwdGluZyBrZXkgbGVuZ3Ro
cw0KPiB3aWxsIGJlLy4NCg0KQzE3OiBDb25jdXIhIEFkZHJlc3MgaW4gYSAtMDkuDQoNCj4gU2Vj
dGlvbiA0LjcuMQ0KPiANCj4gICAgVGhlIHBsYWluIHRleHQgdXNlZCBkdXJpbmcgZW5jcnlwdGlv
biBNVVNUIGJlIGNhbGN1bGF0ZWQgYXMgdGhlDQo+ICAgIHNpbmdsZSwgZGVmaW5pdGUtbGVuZ3Ro
IENCT1IgYnl0ZSBzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSBibG9jay10eXBlLQ0KPiAgICBzcGVj
aWZpYyBkYXRhIGZpZWxkIG9mIHRoZSBzZWN1cml0eSB0YXJnZXQgZXhjbHVkaW5nIHRoZSBDQk9S
IGJ5dGUNCj4gICAgc3RyaW5nIGlkZW50aWZ5aW5nIGJ5dGUgYW5kIG9wdGlvbmFsIENCT1IgYnl0
ZSBzdHJpbmcgbGVuZ3RoIGZpZWxkLg0KPiANCj4gSSBkb24ndCB0aGluayBJIHNlZSB3aHkgdGhl
IENCT1IgYnl0ZSBzdHJpbmcgbGVuZ3RoIGZpZWxkIGlzICJvcHRpb25hbCINCj4gaW4gdGhpcyBz
Y2VuYXJpby4gIChMaWtld2lzZSBmb3IgZGVjcnlwdGlvbi4pDQo+IA0KPiAgICB8ICAgICAgICAg
ICAgIDE4RUQgICAgICAgICAgICAgfCAgICAxOCAgIHwgICAgICAgICAgICBFRCAgICAgICAgICAg
IHwNCj4gICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgIHwgQzI0Q0RFQURCRUVGREVBREJFRUZERUFEQkVF
RiB8ICAgQzI0QyAgfA0KPiBERUFEQkVFRkRFQURCRUVGREVBREJFRUYgfA0KPiANCj4gSSdtIGhh
dmluZyB0cm91YmxlIGRlY29kaW5nIHRoZSAiQ0JPUiBwYXJ0InMgaGVyZTsgaW4gcGFydGljdWxh
ciwgSSBleHBlY3RlZA0KPiB0byBzZWUgdGhlIG1ham9yIHR5cGUgMiBhbmQgQ0JPUiAiYXJndW1l
bnQiIHdpdGggdGhlIGxlbmd0aCBvZiB0aGUgYnl0ZQ0KPiBzdHJpbmcsIHdoaWNoICc0Qycgc2Vl
bXMgdG8gbWF0Y2ggdXAgd2l0aCBmb3IgdGhlIHNlY29uZCBleGFtcGxlLCBidXQgbm90IGJlDQo+
IHByZXNlbnQgZm9yIHRoZSBmaXJzdCBleGFtcGxlLiAgQXJlICcxOCcgYW5kICdDMicNCj4gc3Vw
cG9zZWQgdG8gYmUgQ0JPUiB0YWdzPw0KDQpDMTg6IE5vIElzc3VlLiBBZGRyZXNzIGluIGEgLTA5
Lg0KDQpXZSBjYW4gY2xlYW4gdGhpcyB1cC4gQzIgaXMgdGhlIHRhZyBmb3IgYSBieXRlIHN0cmlu
ZyBob2xkaW5nIGEgYmlnIG51bS4gQWdyZWUgdGhhdCBhcyBieXRlIHN0cmluZ3Mgd2Ugc2hvdWxk
IHNlZSAweDQxRUQgYW5kIDB4NENERUFEQkVFRi4uLg0KDQo+IFNlY3Rpb24gNC44LjENCj4gDQo+
ICAgICAgIFRoZSBrZXkgbGVuZ3RoIHVzZWQgYnkgdGhpcyBzZWN1cml0eSBjb250ZXh0IE1VU1Qg
YmUgY29uc2lkZXJlZA0KPiAgICAgICB3aGVuIHNldHRpbmcgdGhlIEFFUyB2YXJpYW50IHNlY3Vy
aXR5IHBhcmFtZXRlciBmb3IgdGhlIEJDQiBpZiBpdA0KPiAgICAgICBkaWZmZXJzIGZyb20gdGhl
IGRlZmF1bHQgQUVTIHZhcmlhbnQuICBPdGhlcndpc2UsIHRoZSBBRVMgdmFyaWFudA0KPiANCj4g
VGhlICJNVVNUIGJlIGNvbnNpZGVyZWQiIGxhbmd1YWdlIGZlZWxzIG9kZCB0byBtZSAod2hhdCBk
b2VzDQo+ICJjb25zaWRlcmVkIiBtZWFuPyk7IHRoZSAiU0hPVUxEIGJlIGFkZGVkIGFzIHRoZSBb
cGFyYW1ldGVyXSBpZiBpdCBkaWZmZXJzDQo+IGZyb20gdGhlIGRlZmF1bHQiIGxhbmd1YWdlZCB1
c2VkIGZvciB0aGUgU0hBMiBvdXRwdXQgbGVuZ3RoIGZlZWxzIG1vcmUNCj4gbmF0dXJhbCB0byBt
ZS4NCg0KQzE5OiBBZ3JlZS4gQWRkcmVzcyBpbiBhIC0wOS4NCg0KPiBTZWN0aW9uIDQuOC4yDQo+
IA0KPiAgICBEdXJpbmcgZW5jcnlwdGlvbiwgZml2ZSBpbnB1dHMgYXJlIHByZXBhcmVkIGZvciBp
bnB1dCB0byB0aGUgQUVTL0dDTQ0KPiAgICBjaXBoZXI6IHRoZSBkZWNyeXB0aW9uIGtleSwgdGhl
IElWLCB0aGUgc2VjdXJpdHkgdGFyZ2V0IGNpcGhlciB0ZXh0DQo+IA0KPiBzL2VuY3J5cHRpb24v
ZGVjcnlwdGlvbi8NCg0KQzIwOiBDb25jdXIhIEFkZHJlc3MgaW4gYSAtMDkuDQoNCj4gU2VjdGlv
biA2LjINCj4gDQo+ICAgICAgIEluIHRoZSBldmVudCB0aGF0IGEga2V5IGlzIGNvbXByb21pc2Vk
LCBhbnkgc2VjdXJpdHkgb3BlcmF0aW9ucw0KPiAgICAgICB1c2luZyBhIHNlY3VyaXR5IGNvbnRl
eHQgYXNzb2NpYXRlZCB3aXRoIHRoYXQga2V5IFNIT1VMRCBhbHNvIGJlDQo+ICAgICAgIGNvbnNp
ZGVyZWQgY29tcHJvbWlzZWQuICBUaGlzIG1lYW5zIHRoYXQgdGhlIEJJQi1ITUFDLVNIQTINCj4g
ICAgICAgc2VjdXJpdHkgY29udGV4dCBTSE9VTEQgTk9UIHByb3ZpZGUgaW50ZWdyaXR5IHdoZW4g
dXNlZCB3aXRoIGENCj4gICAgICAgY29tcHJvbWlzZWQga2V5IGFuZCBCQ0ItQUVTLUdDTSBTSE9V
TEQgTk9UIHByb3ZpZGUgY29uZmlkZW50aWFsaXR5DQo+ICAgICAgIHdoZW4gdXNlZCB3aXRoIGEg
Y29tcHJvbWlzZWQga2V5Lg0KPiANCj4gSSdtIGEgbGl0dGxlIGNvbmZ1c2VkIGJ5IHRoZSBwaHJh
c2luZyAiU0hPVUxEIE5PVCBwcm92aWRlDQo+IFtjb25maWRlbnRpYWxpdHkvaW50ZWdyaXR5XSIs
IHNpbmNlIHRoZSByZWFsaXR5IGlzIG1vcmUgYWxvbmcgdGhlIGxpbmVzIG9mIHRoYXQNCj4gdGhl
eSB3aWxsIG5vdCBkbyBzbywgZmFjdHVhbGx5IHNwZWFraW5nLiAgUGVyaGFwcyB0aGUgaW50ZW50
IGlzIHRoYXQgdGhlICJTSE9VTA0KPiBOT1QgYmUgdHJlYXRlZCBhcyBwcm92aWRpbmciIHRoZSBp
bmRpY2F0ZWQgcHJvcGVydGllcz8NCg0KQzIxOiBDb25jdXIuIEFkanVzdCB0byBzYXkgIlNIT1VM
RCBOT1QgYmUgdHJlYXRlZCBhcyBwcm92aWRpbmcuLi4iIGluIGEgLTA5Lg0KDQo+IFNlY3Rpb24g
Ni40DQo+IA0KPiAgICBUaGUgQUVTIGtleSB3cmFwIChBRVMtS1cpIGFsZ29yaXRobSB1c2VkIGJ5
IHRoZSBzZWN1cml0eSBjb250ZXh0cyBpbg0KPiAgICB0aGlzIGRvY3VtZW50IGRvZXMgbm90IHVz
ZSBhbiBpbml0aWFsaXphdGlvbiB2ZWN0b3IgYW5kIGRvZXMgbm90DQo+ICAgIHJlcXVpcmUgYW55
IGtleSBwYWRkaW5nLiAgWy4uLl0NCj4gDQo+IFZlcnkgcGVkYW50aWNhbGx5LCBJIHRoaW5rIHRo
YXQgQUVTLUtXIGRvZXMgbm90IHVzZSBhIHBlci1pbnZvY2F0aW9uIElWDQo+ICh0aGVyZSBpcyBh
IHNpbmdsZSBnbG9iYWxseSBjb25zdGFudCBJViB1c2VkIGFzIGlucHV0IHRvIHRoZSBBRVMgY2lw
aGVyDQo+IG9wZXJhdGlvbikuDQoNCkMyMjogQ29uY3VyLiBBZGRyZXNzIGluIGEgLTA5Lg0KDQpX
ZSBjYW4gbWFrZSB0aGF0IGNsYXJpZmljYXRpb24uDQoNCj4gU2VjdGlvbiBBLjEuNA0KPiANCj4g
SSBzdWdnZXN0IHVzaW5nIGxvd2VyY2FzZSBoZXggZGlnaXRzIGNvbnNpc3RlbnRseS4NCg0KQzIz
OiBDb25jdXIuIEFkZHJlc3MgaW4gYSAtMDkuDQoNCj4gU2VjdGlvbiBBLjMuMS4yDQo+IA0KPiBX
aGF0IGRvIHRoZSBjaGV2cm9ucyBhcm91bmQgIjMwMCIgaW5kaWNhdGU/DQoNCkMyNDogTm8gY2hh
bmdlLg0KDQo8PCA+PiBpbmRpY2F0ZSBDQk9SIGl0ZW1zIGVtYmVkZGVkIGluIGEgYnl0ZSBzdHJp
bmcsIGRlZmluZWQgaW4gRy4zIG9mIFJGQzg2MTAuDQoNCiANCj4gU2VjdGlvbiBBLjMuNSwgQS40
LjUNCj4gDQo+IEkgc3VnZ2VzdCBjb25zaXN0ZW50bHkgdXNpbmcgbG93ZXJjYXNlIGhleCBkaWdp
dHMgaGVyZSBhcyB3ZWxsLiAgKEl0IHNob3dzIHVwDQo+IHdoZW4gSSB0cnkgdG8gZGlmZiBhIG1h
bnVhbGx5IGFzc2VtYmxlZCBidW5kbGUgYWdhaW5zdCB0aGUgZW5jb2RlZCBvdXRwdXQNCj4gc2hv
d24gaGVyZS4pDQoNCkMyMzogQ29uY3VyLiBBZGRyZXNzIGluIGEgLTA5Lg0K
From nobody Wed Jun 30 20:58:16 2021
Return-Path:
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A527D3A0852; Wed, 30 Jun 2021 20:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e87nQ0k4k7n9; Wed, 30 Jun 2021 20:58:11 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361963A084D; Wed, 30 Jun 2021 20:58:10 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1613w31H011624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Jun 2021 23:58:07 -0400
Date: Wed, 30 Jun 2021 20:58:03 -0700
From: Benjamin Kaduk
To: "Birrane, Edward J."
Cc: The IESG , "draft-ietf-dtn-bpsec-default-sc@ietf.org" , "dtn-chairs@ietf.org" , "dtn@ietf.org" , "Scott.C.Burleigh@jpl.nasa.gov"
Message-ID: <20210701035803.GO17170@mit.edu>
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
Archived-At:
Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 01 Jul 2021 03:58:15 -0000
Hi Ed,
Skimming quickly, your proposals all seem reasonable at first read.
In particular your proposed resolutions will address the Discuss points.
I will plan to make a closer read when I am not under deadline pressure,
in case there is anything where I want to provide any further remarks or
clarification.
Thanks!
-Ben
On Thu, Jul 01, 2021 at 03:48:28AM +0000, Birrane, Edward J. wrote:
> Benjamin,
>
> Thank you for this thorough and excellent review.
>
> My replies are in-line below, and I have enumerated COMMENTS with C# to aid in referencing going forward; DISCUSSes were prior enumerated.
>
> Would the proposed changes below address your concerns regarding this document?
>
> -Ed
>
>
> ---
> Edward J. Birrane, III, Ph.D. (he/him/his)
> Embedded Applications Group Supervisor
> Space Exploration Sector
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 / (F) 443-228-3839
>
>
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > (D1) the construction for the HMAC input plaintext and GCM AAD seems to
> > be "malleable" at the security context layer
>
> > So, I think we need to include at least the scope flags as part of the IPPT/AAD
> > in order to provide injectivity. It might be worth considering adding
> > additional framing and typing to make clear boundaries between the
> > different parts of the IPPT/AAD, but my current understanding is that it
> > would not be strictly necessary to do so.
>
> D1: Agree with proposed change. Apply in a -09.
>
> Agree that including the scope flags as part of the HMAC input plaintext and GCM AAD would prevent the condition you describe, as they would specify the fields to be included and the order in which they are to be included.
>
> Recommend updating the IPPT and AAD construction algorithms to include the scope flags.
>
>
> > (D2) There seems to be some risk associated with the current HMAC
> > construction, since the HMAC with a given key over a given plaintext will be
> > the same each time it is calculated.
>
> > I suspect that there may be some operational
> > issues with the "unique nonce per HMAC" approach that would make it not
> > terribly reliable in practice, but "use a constant-time comparison" should be
> > fairly straightforward.
>
> D2: Agree with proposed change. Apply in a -09.
>
> Maintaining the state information associated with a nonce in a DTN will, as you mention, be problematic. Using a constant-time comparison to make the software isochronous would mitigate a timing attack.
>
> The question is whether to make a constant-time comparison a SHOULD or a MUST. Certainly making such a function is not difficult, but it might not be strictly necessary when, say, orbiting Mars.
>
> I propose adding this topic in security considerations, stating that a constant-time comparison SHOULD be used to protect against timing attacks and absent that, the impact of side-channel and timing attacks must (lowercase) be considered as part of implementation.
>
>
>
> > (D3) While we do provide the standard guidance against using any given key
> > with more than one algorithm (e.g., with HMAC-SHA-256 and AES256-GCM),
> > there seem to be additional considerations relevant to this protocol that
> > merit further discussion in the security considerations.
>
> > and could provide some modest mitigation
> > techniques such as using distinct KEKs for receiving wrapped keys that have
> > different intended usage. That is, one KEK for receiving AES keys, another
> > for HMAC keys, etc.. Attaching context (intended algorithm, etc.) to the KEK
> > allows such context to be indirectly attached to the received wrapped keys,
> > which otherwise would come without much context for intended usage.
>
> D3: I agree that KEK re-use across contexts is problematic and we should address this in a -09.
>
> Since the KEK is not included in the security block itself, this seems to be something that needs to be addressed in the security considerations - namely that the same KEK MUST NOT be used for other security contexts (certainly not between HMAC and GCM). A compliant security source would not use the same KEK to wrap both an HMAC-SHA-256 and an AES256-GCM key. And a security verifier or security acceptor would not use the same KEK to unwrap such keys.
>
>
>
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > Section 3.1
> >
> > BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the
> > supported length of the SHA-2 hash value. These variants correspond
> > to "HMAC 256/256", "HMAC 384/384", and "HMAC 512/512" as defined in
> > [RFC8152] Table 7: HMAC Algorithm Values. [...]
> >
> > This is unfortunate timing, I suppose, but RFC 8152 is going to be replaced
> > imminently by draft-ietf-cose-rfc8152bis-algs and draft-ietf-cose-rfc8152bis-
> > struct, which are virtually certain to be published as RFCs before this
> > document.
>
> C1: Concur. Address in a -09.
>
> The slight preference for using RFC8152 was that it was published and the information that the default security context references was unchanged. If we are virtually certain that changing references does not introduce a timing dependency we can update this in a -09.
>
>
> > Section 3.2
> >
> > NOTE: The security context identifier and security context
> > parameters of the security block are not included in the IPPT
> > because these parameters, by definition, are required to verify
> > or accept the security service. Successful verification at
> > security verifiers and security acceptors implies that these
> > parameters were unchanged since being specified at the security
> > source.
> >
> > (related to D1, but distinct...)
> > This seems to be only mostly true ... if some other security context was
> > created that also used HMAC-SHA2 it seems like the same output might be
> > obtained or validated across security contexts ... but this would only cause
> > problems if there were different semantics afforded to the different security
> > contexts in some way. Any attack would also be stymied if the honest
> > participants were rigorous in separation of keys, with any given key being
> > used with only one security context.
>
> C2: Concur. Address in a -09.
>
> As part of the comments on D3, we should require that KEKs using in these security contexts not be reused in any other security context.
>
>
> > Section 3.3.3
> >
> > Integrity scope flags that are unrecognized MUST be ignored, as
> > future definitions of additional flags might not be integrated
> > simultaneously into security context implementations operating at all
> > nodes.
> >
> > It's not entirely clear how useful a mandate to ignore unrecognized flags will
> > be, if the flags would change the plaintext input and thus the value of the
> > HMAC output. I guess maybe the intent is just that intermediate notes
> > processing a bundle but not acting as security acceptor should pass through
> > such flags unchanged?
>
>
> C3: Concur. Address in a -09.
>
> Agree this is ambiguous. Particularly if the scope flags are now part of the IPPT/AAD, they cannot be changed in-transit.
>
>
> > Section 3.3.4
> >
> > BIB-HMAC-SHA2 Security Parameters
> >
> > +----+-----------------------+--------------------+---------------+
> > | Id | Name | CBOR Encoding Type | Default Value |
> > +----+-----------------------+--------------------+---------------+
> > | 1 | SHA Variant | UINT | 6 |
> > | 2 | Wrapped Key | Byte String | NONE |
> > | 4 | Integrity Scope Flags | UINT | 0x7 |
> > +----+-----------------------+--------------------+---------------+
> >
> > The examples use a parameter Id of '3' for the Integrity Scope Flags, not the
> > '4' shown here. Since the parameter Ids are just CBOR integers, the
> > sequential assignment with '3' would seem to make the most sense.
>
>
> C4: Concur. Address in a -09.
>
>
> > Section 3.7.1
> >
> > Any local flags used to generate the IPPT SHOULD be placed in the
> > integrity scope flags security parameter for the BIB unless these
> > flags are expected to be correctly configured at security
> > verifiers and acceptors in the network.
> >
> > Just to confirm: do we want "SHOULD ... unless" or "MUST ... unless"?
>
> C5: Concur. Address in a -09.
>
> Agree - this is a MUST...unless.
>
>
> > Section 4.2
> >
> > NOTE: The security context identifier and security context
> > parameters of the security block are not included as additional
> > authenticated data because these parameters, by definition, are
> > those needed to verify or accept the security service.
> > Therefore, it is expected that changes to these values would
> > result in failures at security verifiers and security acceptors.
> >
> > As for the BIB, this note seems only mostly true.
>
> C6: Concur. Address in a -09.
>
> Based on D1, update the text to clarify this note.
>
>
> > Section 4.3.2
> >
> > When not provided, implementations SHOULD assume a value of 3
> > (indicating use of A256GCM), unless an alternate default is
> >
> > [same comment about "SHOULD ... unless" as above]
>
> C7: Concur. Address in a -09.
>
>
> > Section 4.5
> >
> > The security provided by block ciphers is reduced as more data is
> > processed with the same key. The total number of bytes processed
> > with a single key for AES-GCM is recommended to be less than 2^64, as
> > described in Appendix B of [AES-GCM].
> >
> > The treatment in Appendix B seems to be specific to the authentication
> > functionality (and seems to refer to number of *blocks*, not number of
> > *bytes*); section 8.3 of that document has additional guidance on overall
> > invocations of the authenticated encryption function, that include smaller
> > limits that apply to the number of invocations of the function.
>
> C8: Concur. Address in a -09.
>
> The value of placing pointers to, and repeating information from, other documents is to help implementers, and agree this is additional information that would help implementers.
>
> > Section 4.6
> >
> > The pairing of an IV and a security key MUST be unique. An IV
> > MUST NOT be used with a security key more than one time. If an IV
> >
> > I believe that the use with the *encryption* function is the risky one.
> > This is good, because if IV reuse with decryption was problematic, our use of
> > AES-KW would induce pretty strong requirements for state-keeping on
> > verifiers/recipients in order to meet this requirement that could be
> > operationally challenging!
>
>
> C9: Concur! Address in a -09.
>
> This should be clarified.
>
>
> > As discussed in Appendix B of [AES-GCM], implementations SHOULD
> > limit the number of unsuccessful verification attempts for each
> > key to reduce the likelihood of guessing tag values.
> >
> > This type of check would also have potential issues with state-keeping when
> > AES-KW is used, since an attacker could cause a large number of keys to have
> > been used at least once.
>
> C10: No issue. Address in a -09.
>
> I can add this text to the paragraph discussing this, but do not have implementation guidance associated with it.
>
> > Section 4.8.2
> >
> > The authentication tag MUST be present in the BCB security context
> > parameters field if additional authenticated data are defined for
> > the BCB (either in the AAD scope flags parameter or as specified
> > by local policy). This tag MUST be 128 bits in length.
> >
> > I think the authentication tag always needs to be present, not "just"
> > when there is AAD used.
>
> C11: Concur! Address in a -09.
>
> Thank you for this catch.
>
> > Section 7
> >
> > I see that RFC 5649 (or really, RFC 3537) is also available as a reference for an
> > AES-KW algorithm, and that the NIST reference indicates that the RFCs are
> > "essentially equivalent" to what is specified in the NIST reference. My
> > understanding is that we have a mild preference for IETF references over
> > external references when a choice is available.
> >
> > Likewise, RFC 2104 is available as an HMAC reference.
>
> C12: No issue. Address in a -09.
>
> Fine to reference IETF references over others if they are equivalent.
>
> > Section A.1.4
> >
> > Is the final "full output bundle" supposed to include the payload block after
> > the BIB block? I do not see it...
>
> C13: That can be added in a -09.
>
>
> > NITS
> >
> > Section 3.1
> >
> > The BIB-HMAC-SHA2 security context provides a keyed hash over a set
> > of plain text information. This context uses the Secure Hash
> > Algorithm 2 (SHA-2) discussed in [SHS] combined with the HMAC keyed
> > hash discussed in [HMAC].
> >
> > I think s/keyed hash/keyed-hash Message Authentication Code (MAC)/.
>
> C14: Concur. Address in a -09.
>
>
> > Section 3.3.3
> >
> > Bits in this field represent additional information to be included
> > when generating an integrity signature over the security target.
> >
> > My preference is to avoid using the word "signature" to describe a MAC, but
> > I recognize that there is some precedent for using "signature" in this manner.
> > (I won't mention it again for this document.)
>
> C15: No Change.
>
> > Section 3.5
> >
> > HMAC keys used with this context MUST be symmetric and MUST have a
> > key length equal to the output of the HMAC. For this reason, HMAC
> > keys will be integer divisible by 8 bytes and special padding-aware
> > AES key wrap algorithms are not needed.
> >
> > s/HMAC Keys will be/HMAC key lengths will be/
>
> C16: Concur! Address in a -09.
>
>
> > Section 4.2
> >
> > Keys used with this context MUST be symmetric and MUST have a key
> > length equal to the key length defined in the security context
> > parameters or as defined by local security policy at security
> > verifiers and acceptors. For this reason, content-encrypting keys
> > will be integer divisible by 8 bytes and special padding-aware AES
> > key wrap algorithms are not needed.
> >
> > Similarly, s/content-encrypting keys will be/content-encrypting key lengths
> > will be/.
>
> C17: Concur! Address in a -09.
>
> > Section 4.7.1
> >
> > The plain text used during encryption MUST be calculated as the
> > single, definite-length CBOR byte string representing the block-type-
> > specific data field of the security target excluding the CBOR byte
> > string identifying byte and optional CBOR byte string length field.
> >
> > I don't think I see why the CBOR byte string length field is "optional"
> > in this scenario. (Likewise for decryption.)
> >
> > | 18ED | 18 | ED |
> > +------------------------------+---------+--------------------------+
> > | C24CDEADBEEFDEADBEEFDEADBEEF | C24C |
> > DEADBEEFDEADBEEFDEADBEEF |
> >
> > I'm having trouble decoding the "CBOR part"s here; in particular, I expected
> > to see the major type 2 and CBOR "argument" with the length of the byte
> > string, which '4C' seems to match up with for the second example, but not be
> > present for the first example. Are '18' and 'C2'
> > supposed to be CBOR tags?
>
> C18: No Issue. Address in a -09.
>
> We can clean this up. C2 is the tag for a byte string holding a big num. Agree that as byte strings we should see 0x41ED and 0x4CDEADBEEF...
>
> > Section 4.8.1
> >
> > The key length used by this security context MUST be considered
> > when setting the AES variant security parameter for the BCB if it
> > differs from the default AES variant. Otherwise, the AES variant
> >
> > The "MUST be considered" language feels odd to me (what does
> > "considered" mean?); the "SHOULD be added as the [parameter] if it differs
> > from the default" languaged used for the SHA2 output length feels more
> > natural to me.
>
> C19: Agree. Address in a -09.
>
> > Section 4.8.2
> >
> > During encryption, five inputs are prepared for input to the AES/GCM
> > cipher: the decryption key, the IV, the security target cipher text
> >
> > s/encryption/decryption/
>
> C20: Concur! Address in a -09.
>
> > Section 6.2
> >
> > In the event that a key is compromised, any security operations
> > using a security context associated with that key SHOULD also be
> > considered compromised. This means that the BIB-HMAC-SHA2
> > security context SHOULD NOT provide integrity when used with a
> > compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality
> > when used with a compromised key.
> >
> > I'm a little confused by the phrasing "SHOULD NOT provide
> > [confidentiality/integrity]", since the reality is more along the lines of that
> > they will not do so, factually speaking. Perhaps the intent is that the "SHOUL
> > NOT be treated as providing" the indicated properties?
>
> C21: Concur. Adjust to say "SHOULD NOT be treated as providing..." in a -09.
>
> > Section 6.4
> >
> > The AES key wrap (AES-KW) algorithm used by the security contexts in
> > this document does not use an initialization vector and does not
> > require any key padding. [...]
> >
> > Very pedantically, I think that AES-KW does not use a per-invocation IV
> > (there is a single globally constant IV used as input to the AES cipher
> > operation).
>
> C22: Concur. Address in a -09.
>
> We can make that clarification.
>
> > Section A.1.4
> >
> > I suggest using lowercase hex digits consistently.
>
> C23: Concur. Address in a -09.
>
> > Section A.3.1.2
> >
> > What do the chevrons around "300" indicate?
>
> C24: No change.
>
> << >> indicate CBOR items embedded in a byte string, defined in G.3 of RFC8610.
>
>
> > Section A.3.5, A.4.5
> >
> > I suggest consistently using lowercase hex digits here as well. (It shows up
> > when I try to diff a manually assembled bundle against the encoded output
> > shown here.)
>
> C23: Concur. Address in a -09.