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

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 02 July 2020 08:29 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 7EE133A0039; Thu, 2 Jul 2020 01:29:25 -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=ham 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 UNOjiAtlc-SX; Thu, 2 Jul 2020 01:29:23 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50040.outbound.protection.outlook.com [40.107.5.40]) (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 D6F7F3A0035; Thu, 2 Jul 2020 01:29:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FaDaKhP2wYGXKXIt+SnGrB4MpvFsPjtzOPMhINn+wlDx+C3vHue/jTEiG5tOHmggUsNJQjkryBkYhWYFaJH9tj/L8mZdpKHjV81F7LDaa4CBprvWaJWJoHGKWffXxOcKpDmoho4r9yTA04j2mglX3C77ceOt7Rc0Ck6sH3lfU0TEF34pfAwL80l3uFRqKC+8ok8vPTA4Ban48u3ajuR3JNvAomhKVRpsSYE2ajJOUuztmOdYB+2xm05ELtD3Tij0L8+6QKEJyut5jRNw2OXkghrkJjOjpYRfIP//oXTP95S5RFPnwcz9R6uzFxYsSrOZyPpS2sPBYaWUvD6mRJAGcA==
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=0Zy4we7c45IkQCQ5RYmoL8Eh4sOFKxuUj6cLDS7h1dY=; b=BgTnULREKDmsCIWPHjNDRyvW7tbmvW0yTjNLT5lLX5Ug0+Ipe5imzVdm6NCNFM+9b3BfBGDUWqTnNQwmpV9m5snHW0ISRSTg6HhEm+DYlEW2zWqcJ0THLBTgc3TbRkejioZRinOpgaQDhkk+6rNeRkv5UGuQ7MhDxeQwyreV4lcGYhsK+DdNI3V74AUEXIrFnfFka98TlbtTsdZXQJI9eIK69Rq4cK3GCd0ScAA/bon3nupRkN5sMShJ6UOj5uuP+jvCQm1NybFwZFmzCCYkZORr4CfRvy5Evynp+kCP8RvkcWyxuT1z3SVSFGidzQHMFEL5XGY/nKOqPHBAAkTMzw==
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=0Zy4we7c45IkQCQ5RYmoL8Eh4sOFKxuUj6cLDS7h1dY=; b=qKVS9cQs8H/FKRzYk4lBu9XUfzkRGbY+/h0DrID6B/ndkrg6GG/JiVjcAHGyLNpzj+Hxna5FMnM0XoTtaE/NGuKxYE7oDLyFst1pIpA1k1p1Zh/PIeTj2kH4pzpEPJuxRGxI+4SH2xobDYFajIwqvHGZLY4fwQTK6l83fOaKhN8=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3450.eurprd07.prod.outlook.com (2603:10a6:7:2c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.10; Thu, 2 Jul 2020 08:29:19 +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.3153.024; Thu, 2 Jul 2020 08:29:19 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "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: AQHWNbpys3IsQC86lEKBHw33OSyC3ajDzHUAgAATg12AAW2a0IAFDUcAgAQPXgCAF6DokIAOHuMA
Date: Thu, 2 Jul 2020 08:29:19 +0000
Message-ID: <HE1PR0702MB3772C232462AED489A10BE80956D0@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> <HE1PR0702MB37726941ABF20E370AC80B0595940@HE1PR0702MB3772.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0702MB37726941ABF20E370AC80B0595940@HE1PR0702MB3772.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.81]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ee648dc5-2b0e-4ced-bae3-08d81e62042d
x-ms-traffictypediagnostic: HE1PR07MB3450:
x-microsoft-antispam-prvs: <HE1PR07MB34509F5E1221633E05B0559D956D0@HE1PR07MB3450.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0452022BE1
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WcHWb6RR8TdJpIWWOMdY2yz62HeDKWFU2nPIi4Czsyoeu5BLSYyiOaFu2xnc3HHcm+baeaPZZzhuGHH3BD31XGL6ojyEU3mWIPnAqy8/kM+BSDOWNrmPVViLnaIKAW2jY69bj+FiGWSkqj9Zyym3zztbF8rd4oj65Rz8wV8oOo41eiqSU5rXqTjJ0RqPxqXGRlsZOqFfU7DQcSjjL/blxyxe466ULxM2hTC61BG0uwa1z1A8qFQ96dlWr6m8Re2qoav1gOAzUUDNWtruKmxRcNltn5nZ8Jq/2vKz38YWK1To6uyzNlTK3Xx0IkWW1Z0Xx/HMJe2KwDaj3nKVyj0O9LkWucFa6O1ZPacrAGCclluwwHUXOYgD/Cp5CKIMfK56hQfObdSXrOAxnf9gduzt2A==
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)(376002)(136003)(39860400002)(396003)(346002)(366004)(8676002)(6916009)(8936002)(9686003)(66574015)(54906003)(55016002)(30864003)(316002)(83380400001)(99936003)(2906002)(86362001)(26005)(33656002)(44832011)(52536014)(186003)(6506007)(76116006)(53546011)(478600001)(7696005)(4326008)(66476007)(66616009)(966005)(5660300002)(71200400001)(66946007)(66446008)(64756008)(66556008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: XWfDQMzoCCf4sU7+zviOk5Rk+Lqf4nsCK/jY9Fq3ojaOSSkgUKSmsyJB2qjcZRxelNhrUihNN1nDH3jyDZcG2YxM/ewwoRFpqyEZ3YBQEpGt5yZjG36+LFuXwlt+GAf0rl5/is1jgkr7jwIP84Bfe+M0rAul1M/gDGaWH0NGKxv0J1AnYvhkjtQ8SCRUmVNH599PT/dkt8WWvhIeNj6e98Qz9Nxln7z/lMFp/g92kXxtMOjUags+HkXgrkrswgD/z8nnBWLQO/3TRGVKjuDoi7gIvTmuM7+Tv4ll9RyLQ1PMKSV+1/41A4kZxm/IT2oKOGktDuywUSygljXmAeu9RE7Q7+K/OZiQuUjt8kdC4ZLIbQWzs1jnlW0RTq0iXRQtekExJdQUiQeGQWu+pmsk/rdEC+WrG8pxV2X2uZSPr//mQwM+7Hq9DQku+o/Bd+Jn1bdo8lB4bq64wn9QHowCG1REzDGmSx0fHyEI4C3/zvVcxtPQW7lxR+YQF+NOgA1Z
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A3_01D6505B.A3CAEF00"
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: ee648dc5-2b0e-4ced-bae3-08d81e62042d
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2020 08:29:19.6847 (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: UtxedIlmvNo5+JDRZWd/dfIoxU28+t7RwQiG0gLeflxxdP3lGLBY8gFaqvn4uJTmCMKG6tdq5qPDcKNLvUhug5B9+u9/jvFqo7BrGmONMZg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3450
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/NszB30aHhRN15P0mjdXg-tzGjhw>
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: Thu, 02 Jul 2020 08:29:26 -0000

Hi Ben,

Please can you update your position on the document? 
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/


Cheers

Magnus Westerlund

> -----Original Message-----
> From: Magnus Westerlund
> <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
> Sent: den 23 juni 2020 13:56
> To: Magnus Westerlund <magnus.westerlund@ericsson.com>om>;
> 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: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with
> DISCUSS and COMMENT)
> 
> 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