Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 23 June 2020 11:55 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 25B133A1880; Tue, 23 Jun 2020 04:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 cS49xwp9pnCB; Tue, 23 Jun 2020 04:55:57 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2043.outbound.protection.outlook.com [40.107.20.43]) (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 860BA3A187D; Tue, 23 Jun 2020 04:55:56 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hfkJYckIljGUYAh8Smm23NxdnHPoS8zlV5/Yu7xQcb6VM6NSEXvROoPUF3i20Hg+pHL85HWSKqh0+VmCFCp1U491zloO3ngFiLEf0JtXVfcw23U+b8USu9imsVlX03G/NjR5OGwOFKdRv4WkgymZigGWDowERjwxHQRgwHoVxiWMsloq39BPiFQLdCLH1MEc/iUGKNwCkdXUkq/wlUR6bF7FASZhmrFH5uVX4FPxfUW/f+1kn1NsG1cAmu9hC//DXC26NWY4t+tLG/87/D+UtQpoIdFwnyDwDPMtWrUmzHrdF/tGAVnYCpKKOE7erKu40DnN+1hI+Thk/rLDro93Vw==
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=r8rq9usDEqtfIP7nCI+ZJ7qGchVSMS3OsS+kZICxWB4=; b=mNGrz6LRFhkJeyKL5/m2E5EJe3KwGqYKTdml+S2OGGbGPpkrpzb+uVWlZQZnxilqcU/8NDwq6X+Pew73Cn2pll6w3oAh/5kgwbfJvZmxdvRMrYrTQvQAIHhO7GMsQMtDsQIuw9Tas1HrIq/0o8FHamFrzo1bm/v4dI4bH61FZLVun6aiQiGWfrYCFEsaBjiwGXzye8Qkn4wc1f+Cu7A60SOvx7Ufiuqw1tn1JzmOcJYwFSmV8s2lGNoj4jkR8xBPmwjgBmIZi2Sn3wAE6qj6SV3a2QOO3yDX1bZk+mRuTUWNGK5tV+HmjNU1noKQkXWJ4a7ICc5GV9fa3weNTz/ZhA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r8rq9usDEqtfIP7nCI+ZJ7qGchVSMS3OsS+kZICxWB4=; b=C3CHuhYAi0lIkdIA4+V+mARGSYNAnKYqsyEETvbNveJbuZKj0Ah1flXUCnup0o+wnX+sWG69MpCUIwGjbOqRwqk/vFicelLdhpwzAD0ShLqOM9Y9OwwLt3vGbKoBTqZWjtmRKcJNfb5VcmScwuIqTiD8fT0nnv8TrIr+FfnBsv8=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3705.eurprd07.prod.outlook.com (2603:10a6:7:8e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.15; Tue, 23 Jun 2020 11:55:52 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351%6]) with mapi id 15.20.3131.018; Tue, 23 Jun 2020 11:55:52 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "magnus.westerlund=40ericsson.com@dmarc.ietf.org" <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "kaduk@mit.edu" <kaduk@mit.edu>
CC: "BSipos@rkf-eng.com" <BSipos@rkf-eng.com>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "edward.birrane@jhuapl.edu" <edward.birrane@jhuapl.edu>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-dtn-tcpclv4@ietf.org" <draft-ietf-dtn-tcpclv4@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
Thread-Index: AQHWNbpys3IsQC86lEKBHw33OSyC3ajDzHUAgAATg12AAW2a0IAFDUcAgAQPXgCAF6DokA==
Date: Tue, 23 Jun 2020 11:55:52 +0000
Message-ID: <HE1PR0702MB37726941ABF20E370AC80B0595940@HE1PR0702MB3772.eurprd07.prod.outlook.com>
References: <CH2PR13MB357549D8058EBA5BD62321E39F8F0@CH2PR13MB3575.namprd13.prod.outlook.com> <2274729b98be317dcbce8d0da2b2153e87484ca1.camel@ericsson.com> <CH2PR13MB357598BB73AD4F49254CE6AA9F8A0@CH2PR13MB3575.namprd13.prod.outlook.com> <HE1PR0702MB377263D978ACF47594580991958B0@HE1PR0702MB3772.eurprd07.prod.outlook.com> <20200605180010.GJ58497@mit.edu> <7be234038011daeb25ebcd49ef5ba9909b188a52.camel@ericsson.com>
In-Reply-To: <7be234038011daeb25ebcd49ef5ba9909b188a52.camel@ericsson.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [176.10.164.117]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e9c482e0-8af1-45d1-6dad-08d8176c60e7
x-ms-traffictypediagnostic: HE1PR0702MB3705:
x-microsoft-antispam-prvs: <HE1PR0702MB37059A33A5FA80EAB4E4EB5295940@HE1PR0702MB3705.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04433051BF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: U7CabxYwWpzX2Vw13pDzyCoEdWNU7tHiFEPp5pN/FRmJB8FpWEE5UetF1k+Twj/9BiifJeSFpurPVwTSLWYrGH7REt1jg0Q3Mg1j8kijBR+2XEziLfeje//PvN908PLzYZ6LI6H0yAQ+5DHWNpwHgLJIgu7dUfpc0+ZWnoHUupJ/GwS9ZpFB7Ajj9PMCbtxULYTPrWD/teaA7v07UF40nmfNUxrNudqhJO1pVF36ZSjlIK5XwJsfzdIJOVjiyZbloNlEArCXcCcBmC552j9p/Uaj6YrrATw2sYvw2nduhexHO5f7lcClwSnT2In87ecYg2muyKu7flHMwgoZEsts0OA15WF7c1rJsDIVvaja15awmy/O364uWpiLsEXslJdj4LUacqUxWvZTYo+OUzFYrw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(366004)(136003)(396003)(39860400002)(966005)(6506007)(53546011)(64756008)(66556008)(66616009)(52536014)(4326008)(99936003)(66574015)(478600001)(8676002)(26005)(33656002)(83380400001)(86362001)(71200400001)(54906003)(66476007)(186003)(55016002)(76116006)(8936002)(66946007)(110136005)(2906002)(316002)(7696005)(44832011)(66446008)(9686003)(5660300002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: X11oQro+MERKyu0ficXgbsZFMaH+jarN/QiLSIqJa01baO+Y+h8wMfasY/2QbGsDvHFD9AoS6DFn8rgRpkKN7fLDsda5y7AC62c0el20ruAdxWr3OkKpx+PS4kpKwoo7heN+U1DxNJaprXQIT8oHspzfAikKG79esXRsMz1AQbIDGutMqaGVpzYw6t4kugNuiKE+1TPJspp0xZPyMGP99rpC1LWuSTZASWormmW7VNwOon9pX8tR4DReyF9DV8NykQWXCNbONL9FDswPZWAYuHOpJ7dYaurHqTubcwHVZIgEDkqRxrdsrw2e/wf7n4uOtN+vHIJvoVv5NmbMIivcDcaHh2RNzcEirNtk+bLSyCE898Z48VeyYjxSQpgSRn1v+EREUi3JpV7xXMEUVAdx9H8r6TZoWJskWDhCD/2cahOkvajsrJrNg2h5qnH3+M8af8km9OjKCXmyM/8L5Ij4y3FT2BiSROje/J6ooCC23fldBrFHT8bG411ka2rRhV0S
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0106_01D64966.00B76880"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e9c482e0-8af1-45d1-6dad-08d8176c60e7
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 11:55:52.1532 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ewDBV8udKBQTCmsKzdiY25b3//4NVjYDUtauv1NE44p9YOEn1lXXqrqu54DL5Wef4KRWb/0WmdzVb5ObxYtSXg1MntidH7NZfMZsZiO6PsI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3705
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/e_s06o5JmapzQw-M0HKXytocV5k>
Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (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." <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: Tue, 23 Jun 2020 11:55:59 -0000

Hi,

I think the new text on the CA looks reasonable as providing a context for
the certificate validation text. 

Ben, can you please check if the document resolves your discuss now? 

Cheers

Magnus Westerlund

> -----Original Message-----
> From: dtn <dtn-bounces@ietf.org> On Behalf Of Magnus Westerlund
> Sent: den 8 juni 2020 10:00
> To: kaduk@mit.edu
> Cc: BSipos@rkf-eng.com; dtn-chairs@ietf.org; edward.birrane@jhuapl.edu;
> iesg@ietf.org; draft-ietf-dtn-tcpclv4@ietf.org; dtn@ietf.org
> Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18:
> (with DISCUSS and COMMENT)
> 
> Hi Ben and Brian,
> 
> On Fri, 2020-06-05 at 11:00 -0700, Benjamin Kaduk wrote:
> > Hi Magnus, Brian,
> >
> > Sorry for the slow response here -- I've been trying to meet a
> > deadline at work and email responses have suffered.
> >
> > I think Brian's discussion and explanations in this thread are
> > generally spot-on.  I'll make a few notes inline but they don't really
> > touch on the core substance of things.
> >
> > I do wonder, though (Magnus), why you are under the impression that
> > (as stated in the start of the thread) " for normal Web PKI if a
> > browser opens a connection for alice.foo.com and gets a cert that says
> > foo.com and has a
> > AltSubjectName: alice.foo.com it will be fine. However, if I put in
> > alice.bar.com which is not a subdomain of the primary name in the cert
> > it will reject the altSubjectName."  My understanding matches Brian's
> > that all SANs and the CN are treated independently (and in particular,
> > that if SANs exist, they are generally preferred over CN).
> 
> Yes, I guess I made an error in though here. So maybe the better question
is
> what type of runtime validation that is done related to domain names on
the
> certificate and its chain, any at all? Or is all this checking happening
by the
> enitity signing the certificate in the certificate chain?
> 
> 
> What appear clear is that we really should keep the basic checking
required
> for any TLS usage in TCPCLv4 document seperated from what would be
> required for any type of PKI for the DTN or IPN namespaces.
> 
> I think the immediate question here boils down to what are the aspect
> around this that we need to note in the TCPCLv4 document? I do note that
> some of it is inlide below.
> 
> 
> >
> > [more inline]
> >
> > On Tue, Jun 02, 2020 at 12:58:43PM +0000, Magnus Westerlund wrote:
> > > Thanks Brian,
> > >
> > >
> > >
> > > I think what you write below are quite clear. And I think has
> > > reasonable security policies and a particular set of properties.
> > > However, I don't think either Section 4.4 or the Security
> > > Consideration goes into these. They support these but appear to have
> > > more fluid boundaries to even more policies. So the question is if
> > > the specification should be more articulate about these two targets
> > > and state that additional security policies with associated
> > > properties can be defined later either in implementation or future
> documents.
> >
> > I still have an action item to read the updated I-D, and will try to
> > keep this topic in mind as I do so.
> >
> > >
> > >
> > > Cheers
> > >
> > >
> > >
> > > Magnus
> > >
> > >
> > >
> > > From: Brian Sipos <BSipos@rkf-eng.com>
> > > Sent: den 1 juni 2020 18:57
> > > To: Magnus Westerlund <magnus.westerlund@ericsson.com>om>;
> > > iesg@ietf.org; kaduk@mit.edu
> > > Cc: dtn-chairs@ietf.org; dtn@ietf.org;
> > > draft-ietf-dtn-tcpclv4@ietf.org; edward.birrane@jhuapl.edu
> > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18:
> > > (with DISCUSS and COMMENT)
> > >
> > >
> > >
> > > Magnus,
> > >
> > > To clarify two distinct use cases for TCPCL security:
> > >
> > > 1.	On a private network, with private PKI and control of a CA:
> > > In this situation I see it more as the CA's obligation to coordinate
> > > with the network designer so that when a new BP Node is allocated
> > > that it gets proper BP configuration, TCPCL configuration, and a TLS
> > > certificate (to authenticate the Node ID URI) is produced. The
> > > validation of its identity and private key occurs via side channels
> > > the same way the Node is otherwise managed and configured.
> > > 2.	On a more open network, where some other organization
> controls PKI
> > > roots and signing CAs:
> > > In the near term, public CAs only know how to validate DNS names and
> > > are likely only willing to sign certificates with DNS name SANs. In
> > > this case
> >
> > I don't think this is quite true, depending on how you define "public
CAs".
> > There's a very long thread (including, unfortunately, a lot of
> > redundant bits where people are talking past each other) on a similar
> > topic, what it means to be a "public CA", and what "public CAs"
> > currently can and are
> > (not) willing to do, in the thread at
> >
> https://mailarchive.ietf.org/arch/msg/emu/8G6q7TnhgixgS92QWBNqL7vWd
> 2U/
> >
> > Key topics include the need for an agreed set of rules for CAs to
> > operate by in order for consuming applications to put trust in the
> > certifications coming out of the CAs.  That is, a sense that if the
> > rules are followed, then clients will get the properties they need by
> > trusting the CA signatures.  And, of course, enough people doing
> > enforcement that CAs actually follow the rules properly, to keep things
> working right.
> >
> > We're thinking about potentially having a future SAAG talk about
> > non-web PKI topics (and if there's guidance we can/should give for
> > starting such an ecosystem).
> >
> > > the CA doesn't know or care about the Node ID and any BP Node which
> > > authorizes transfers to/from a TCPCL entity with a DNS-only
> > > authentication just has to have an implicit trust that an
> > > authenticated DNS name will not falsely claim a Node ID. This risk
> > > is identified in Section 8.8 "Threat: BP Node Impersonation" [1] and
> > > a BP Node can choose accept this risk as a policy decision.
> > >
> > > I think both of these situations are reasonable if BP is used to
> > > traverse an open network where some of the intermediate nodes are
> not fully trusted.
> > > Like you said, it would be possible for the configuration of a node
> > > to have a specific whitelist of which public hosts are trusted to
forward
> bundles.
> > > And maybe the node policy can be nuanced as you have stated so that
> > > if a node is the bundle destination it *must* have a TLS-authenticated
> Node ID.
> > > In the end, the whole point of CL-level security is to ensure that
> > > data/bundles are not being leaked in the clear on a single hop. You
> > > still need to use BPSEC if the intent is to guaruantee integrity or
> > > authenticity of the bundle itself.
> > >
> > >
> > >
> > > Because ACME [2] provides a solid infrastructure to separate the
> > > mechanisms of how to challenge and validate a claim from what to do
> > > with the validated claims (i.e. issue a requested certificate), if
> > > it seems reasonable I am willing to create a draft of a new ACME
> > > challenge type for validating a DTN Node ID using a new BP
> > > administrative record type. This challenge type would be extremely
> > > logically simple and could be done on its own, outside of an ACME
server,
> to validate ownership of a Node ID in a more "manual" way.
> > > Doing this gives us something more concrete than a BCP explaining a
> > > procedure.
> >
> > I am wary of describing this as "outside of an ACME server": the
> > separate account-provisioning step and cryptographic means to bind an
> > intent to authorize a given name by a given account to the actual
> > challenge and challenge-validation steps are important parts of
> > achieving the properties that ACME provides.
> >
> > >
> > >
> > > [1]
> > > https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-20#section-8.8
> > >
> > > [2] https://tools.ietf.org/html/rfc8555#section-8
> > >
> > >
> > >
> > >   _____
> > >
> > > From: Magnus Westerlund <magnus.westerlund@ericsson.com
> > > <mailto:magnus.westerlund@ericsson.com> >
> > > Sent: Monday, June 1, 2020 09:53
> > > To: iesg@ietf.org <mailto:iesg@ietf.org>  <iesg@ietf.org
> > > <mailto:iesg@ietf.org> >; Brian Sipos <BSipos@rkf-eng.com
> > > <mailto:BSipos@rkf-eng.com> >; kaduk@mit.edu
> <mailto:kaduk@mit.edu>
> > > <kaduk@mit.edu <mailto:kaduk@mit.edu> >
> > > Cc: dtn-chairs@ietf.org <mailto:dtn-chairs@ietf.org>
> > > <dtn-chairs@ietf.org <mailto:dtn-chairs@ietf.org> >; dtn@ietf.org
> > > <mailto:dtn@ietf.org> <dtn@ietf.org <mailto:dtn@ietf.org> >;
> > > draft-ietf-dtn-tcpclv4@ietf.org
> > > <mailto:draft-ietf-dtn-tcpclv4@ietf.org>
> > > <draft-ietf-dtn-tcpclv4@ietf.org
> > > <mailto:draft-ietf-dtn-tcpclv4@ietf.org> >;
> > > edward.birrane@jhuapl.edu <mailto:edward.birrane@jhuapl.edu>
> > > <edward.birrane@jhuapl.edu <mailto:edward.birrane@jhuapl.edu> >
> > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18:
> > > (with DISCUSS and COMMENT)
> > >
> > >
> > >
> > > Hi,
> > >
> > > I would appreciate the SEC ADs input on this.
> > >
> > > I think you are correct that PKI structure and how to validate IPN
> > > and DTN URI in regards to the certificats are seperate document.
> > >
> > > So don't we have two different aspects here for TCPCLv4. One when it
> > > is used as CL to reach a next hop in the routing infrastructure,
> > > where the sending agent only need to know that it connected to the
> > > intended next hop. The other case is when the agent uses the CL to
> > > directly reach the peer agent with the intended BP layer destination
> > > Node ID. Maybe I have focused to much on the later and it is only
> > > the former that actually are needed here. Still BP routers do have
> > > their own Node ID and thus, I guess the identification dilema for
> > > Node IDs do remain.
> >
> > (I think this dilemma is at the core of my uneasiness with the draft
> > originally proposed for IESG Evaluation.  It's not a problem that's
> > fully solvable, though, so we'll need to clearly document what we
> > do/don't do and move on, as was noted later in the thread.)
> >
> 
> 
> 
> --
> Cheers
> 
> Magnus Westerlund
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> 
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn