Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpsec-18: (with DISCUSS and COMMENT)

"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Mon, 17 February 2020 04:17 UTC

Return-Path: <Edward.Birrane@jhuapl.edu>
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 B61E11200F9; Sun, 16 Feb 2020 20:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 vleicpQaEFDj; Sun, 16 Feb 2020 20:17:52 -0800 (PST)
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 E86DA1200F7; Sun, 16 Feb 2020 20:17:51 -0800 (PST)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.16.0.42/8.16.0.42) with SMTP id 01H4FM4n146306; Sun, 16 Feb 2020 23:17:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version : subject; s=JHUAPLDec2018; bh=6c10RAY7AJaz24WvSNGpo8cPBd+p25MsLaO8iV0dyfA=; b=iA2a+C1aYRGkzT1NQ0eH6WYY3hGguMAovrucj4sY1jDCPkrTLTSkYyuqHXOcESlHav2V gb2clYKGMtTcFN4iUX7/YcS7hQn5RdtUfTMz0yZSAT1HDiT8Ebs1cj3geuTGKzN5vabj 5qBL5ZpccPvEEbA8HIWE+5WzC+t/m32YOUpOOGDJL0jyJvAZEgBQrbqKKKvX9vosVZEo 2GrIWg4QKsIX3S84REZ9UD8EFTIzWusqlaoRfa8W1ed8SLVk1RFHNu/kzxrS8qs8mjXZ vUVmiW/B5lPPUtvECYbyO2eW7PaTog19b1JIN2D7/kd6Tl3v9e0DaLaNN2EAVvd+l3Hr MQ==
Received: from aplex06.dom1.jhuapl.edu (aplex06.dom1.jhuapl.edu [128.244.198.140]) by aplegw01.jhuapl.edu with ESMTP id 2y7e0e0vjj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 16 Feb 2020 23:17:49 -0500
X-CrossPremisesHeadersFilteredBySendConnector: APLEX06.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by APLEX06.dom1.jhuapl.edu (128.244.198.140) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 16 Feb 2020 23:17:48 -0500
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.1473.003; Sun, 16 Feb 2020 23:17:48 -0500
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: "R. Atkinson" <rja.lists@gmail.com>, DTN WG <dtn@ietf.org>
CC: The IESG <iesg@ietf.org>
Thread-Topic: =?utf-8?B?W0VYVF0gUmU6IFtkdG5dICBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBv?= =?utf-8?B?biBkcmFmdC1pZXRmLWR0bi1icHNlYy0xODogKHdpdGggRElTQ1VTUyBhbmQg?= =?utf-8?Q?COMMENT)?=
Thread-Index: AQHV4PmFBLbpZ6PRO0KwfCuO71bTC6gaCFoAgATEIqA=
Date: Mon, 17 Feb 2020 04:17:47 +0000
Message-ID: <b9f6e1d5c32541658059d09caa5af0fc@aplex01.dom1.jhuapl.edu>
References: <158072863257.28637.8806505241822600245.idtracker@ietfa.amsl.com> <035730f96e28463a8141b026079bf3c3@aplex01.dom1.jhuapl.edu> <DE73788D-7E72-4246-B996-7F79AC805B87@kuehlewind.net> <820D95D0-F645-4551-9AE8-D30E49A2DD0E@antarateknik.com> <8A9F9AE8-18B3-4218-B8F5-D248BA4DF221@gmail.com>
In-Reply-To: <8A9F9AE8-18B3-4218-B8F5-D248BA4DF221@gmail.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OrganizationHeadersPreserved: APLEX06.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-17_02:2020-02-14, 2020-02-17 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/G1GNPm07wzprI-UcxJ2sNOn0d_w>
Subject: Re: [dtn] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?tn-bpsec-18=3A_=28with_DISCUSS_and_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." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2020 04:17:55 -0000

Ran,

  I do recall that you made this same point at one of the DTNWG meetings.  

  It seems the desired way forward would be to 

1. Take the current bpsec interoperability security contexts document (draft-ietf-dtn-bpsec-interop-sc) and make it a normative reference in bpsec.
2. State in the new section 9.1 of BpSec that the interop security contexts are mandatory-to-implement.
3. Put the interop security contexts into the review cycle (they are in WG last call at this point, I believe).

Would this be a satisfactory outcome?

-Ed


Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

-----Original Message-----
From: dtn <dtn-bounces@ietf.org> On Behalf Of R. Atkinson
Sent: Thursday, February 13, 2020 5:17 PM
To: DTN WG <dtn@ietf.org>
Cc: The IESG <iesg@ietf.org>
Subject: [EXT] Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpsec-18: (with DISCUSS and COMMENT)

APL external email warning: Verify sender dtn-bounces@ietf.org before clicking links or attachments 

All,

I think it quite reasonable for the WG to define at least one "mandatory-to-implement" (i.e., NOT mandatory to use) set of security algorithms/modes for BPsec — and I think it quite reasonable for the IESG to require that the WG make such a choice.

The IETF has at least 30 years of experience that if at least one “mandatory-to-implement” security profile is NOT required/specified, then non-interoperability is the actual result.  In this case, non-interoperability would mean that two different systems who DO wish to use BPsec between themselves actually cannot use it — because of disjoint algorithms/modes having been implemented in the different implementations.

I’m not terribly particular about which algorithms/modes the WG picks, although choosing algorithms/modes readily available in open-source libraries (for example: the OpenSSL library) does simplify life for implementers.

Yours,

Ran

> On Feb 11, 2020, at 11:37, Mehmet Adalier <madalier@antarateknik.com> wrote:
> 
> While it is possible to find such a minimal requirement, I do not believe that one is required at the BPsec protocol level.
> I'd also like to recommend that the BPsec RFC does not specify a "minimum" interoperability context.
> 
> Depending on the use-case, interoperable contexts can be defined as other specifications. 
> 
> An example is appropriate CCSDS books which indicate interoperable contexts. . Another example is the International Communication System Interoperability Standards (ICSIS).
> 
> Mehmet
> 
> 
> On 2/11/20, 4:04 AM, "dtn on behalf of Mirja Kuehlewind" <dtn-bounces@ietf.org on behalf of ietf@kuehlewind.net> wrote:
> 
>    Hi Ed,
> 
>    Thanks for the new text section 9.1. Reading this text I would to confirm one more thing: I understand that the best choice for the security context can be very different, however, the point of interoperability is to have at least one available, that might not be optimal but it better than none. Having one common security context required would also simply mean that each implementation would need to support that and therefore it becomes much easier for people to reply BPSec if the provided one is suitable. Is it not possible to find such a minimal requirement?
> 
>    Mirja
> 
> 
> 
>> On 8. Feb 2020, at 01:23, Birrane, Edward J. <Edward.Birrane@jhuapl.edu> wrote:
>> 
>> Mirja,
>> 
>> Thank you for the review. I have updated a new version of BPSEC  (BPSEC20) which attempts to address your DISCUSS and COMMENTS below.
>> 
>> Specific comments are in-line below.  I have enumerated the Discuss items as **D# and the comment items as **C# to aid in referencing these points going forward.
>> 
>> -Ed
>> 
>> ---
>> Edward J. Birrane, III, Ph.D.
>> Embedded Applications Group Supervisor Space Exploration Sector Johns 
>> Hopkins Applied Physics Laboratory
>> (W) 443-778-7423 / (F) 443-228-3839
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Mirja Kühlewind via Datatracker <noreply@ietf.org>
>>> Sent: Monday, February 03, 2020 6:17 AM
>>> To: The IESG <iesg@ietf.org>
>>> Cc: draft-ietf-dtn-bpsec@ietf.org; Scott Burleigh 
>>> <Scott.C.Burleigh@jpl.nasa.gov>ov>; dtn-chairs@ietf.org; 
>>> Scott.C.Burleigh@jpl.nasa.gov; dtn@ietf.org
>>> Subject: [EXT] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpsec-18: 
>>> (with DISCUSS and COMMENT)
>>> 
>>> APL external email warning: Verify sender noreply@ietf.org before 
>>> clicking links or attachments
>>> 
>>> Mirja Kühlewind has entered the following ballot position for
>>> draft-ietf-dtn-bpsec-18: 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 IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/
>>> 
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> --
>>> DISCUSS:
>>> --------------------------------------------------------------------
>>> --
>>> 
>>> Sec 1.2 says:
>>> "A sample security
>>>  context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) to 
>>> support  interoperability testing and serve as an exemplar for how 
>>> security  contexts should be defined for this specification."
>>> However I don't really understand how interoperability can be 
>>> reached if there is not at least one security context that is 
>>> mandatory to implement in this draft (especially as 
>>> ietf-dtn-bpsec-interop-sc is expired for more than half a year already)...?
>> 
>> **D1: I have added a new Section 9.1 to BPSEC20 which describes the desired approach to BPSec and security contexts.  I have also updated ietf-dtn-bpsec-interop-sc which should be going into WG last call.
>> 
>>> 
>>> --------------------------------------------------------------------
>>> --
>>> COMMENT:
>>> --------------------------------------------------------------------
>>> --
>>> 
>>> Please use the updated disclaimer in rfc8174.
>>> 
>> 
>> **C1: Agreed. The disclaimer has been updated in BPSEC20.
>> 
>> -Ed
>> 
> 
>    _______________________________________________
>    dtn mailing list
>    dtn@ietf.org
>    https://www.ietf.org/mailman/listinfo/dtn
> 
> 
> 
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn

_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn