Subject: [dtn] BPbis consensus status

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 16 Sep 2020 19:43:33 +0000

Hi.  As best I can work out from the last eight weeks of emails, here is the status of the remaining open questions on the BPbis draft.

1.	Should the BPbis specification mandate implementation of the BPSec security extensions?
	a.	On July 27, Marc Blanchet strongly opposes this mandate.
	b.	On July 28, Brian Sipos supports the mandate in a limited way: when bundle-level security is needed, that security must be provided by BPSec rather than by some other mechanism.  [This language now appears in section 9 of version 26 of the BPbis Internet Draft.]
	c.	On July 28, Ronny Bull agrees with Brian.
	d.	On July 28, Mehmet Adalier agrees with Brian.
	e.	On July 28, Ed Birrane agrees with Brian.
	f.	On July 29, Ran Atkinson supports the mandate in a more expansive way: implementation of BPSec is mandatory for any Bundle Protocol Agent that sources, verifies, and/or accepts a bundle.  A BPA that only forwards bundles (without verifying them) need not implement BPSec.
	g.	On July 29, Rick Taylor agrees with Ran.
	h.	On July 29, Ed Birrane agrees with Ran.
	i.	On July 29, Ronny Bull agrees with Ran.
	j.	On August 3, Adam Wiethuechter agrees with Brian.
	k.	On September 2, Magnus Westerlund supports the mandate without limitation.

2.	Is the registration policy for Bundle and Block Processing Control flags in sections 10.3 and 10.4 of BPbis version 26 satisfactory?
	a.	To date, no comments from the Working Group.

3.	Does the language in section 5.4 Step 2 of BPbis version 26 satisfactorily address the question of mandating implementation of TCPCL in the BPbis specification?
	a.	To date, no comments from the Working Group.

4.	Does the language in section 4.2.2 and 5.5 of BPbis version 26 satisfactorily address the question of authorizing Bundle Protocol Agents to override the bundle lifetimes asserted by BP applications?
	a.	To date, no comments from the Working Group.

5.	Does the language in section 4.1.5.1.1 of BPbis version 26 satisfactorily address the question of discerning whether or not a given dtn-scheme endpoint ID identifies a singleton endpoint?
	a.	To date, no comments from the Working Group.

6.	Does the language in section 10.6 of BPbis version 26 satisfactorily address the question of limiting the permitted number of different BP URI scheme type codes?
	a.	To date, no comments from the Working Group.

7.	In version 26 of the BPbis specification, all BP time values (e.g., bundle creation time, lifetime, bundle age) are denominated in milliseconds rather than in seconds or microseconds.  Is this satisfactory?
	a.	On July 28, Carsten Bormann notes that the CBOR representation of time values could utilize tags to reduce transmission bandwidth consumption.
	b.	On July 29, Jeremy Mayer endorses Carsten's idea: times may be denominated in seconds (tag 1) or at other granularity (tag 1001).
	c.	On July 29, Ed Birrane warns that this concept introduces the possibility of time values changing in transit, violating the immutability of primary blocks.
	d.	On July 29, Rick Taylor, Scott Burleigh, Ed Birrane, and Ran Atkinson discuss the question of what is really meant by the immutability of the primary block: semantic immutability or syntactic immutability?
	e.	On August 3, Adam Wiethuechter agrees with Ran that both semantic immutability and syntactic immutability are required.  He believes that denominating all DTN times in milliseconds is a good resolution.
	f.	On August 4, Lloyd Wood explains immutability.

8.	Does the language in section 4.3 of BPbis version 26 satisfactorily address the question of whether implementation of all extension blocks defined in the BPbis specification is mandatory or conditional?
	a.	To date, no comments from the Working Group.

Scott

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 16 Sep 2020 15:50:56 -0400

On 16 Sep 2020, at 15:43, Burleigh, Scott C (US 312B) wrote:

> Hi.  As best I can work out from the last eight weeks of emails, here 
> is the status of the remaining open questions on the BPbis draft.
>

I’m still opposed to have BPSEC be mandatory to implement as I think 
the security services can be done within the payload. IP is currently 
not secured on the Internet. It is within the IP payload (TLS) that 
security services are applied. I want a fully conformant BP 
implementation to ship without BPSec and without any specific use case 
(e.g. forwarding vs non-forwarding). However, I expect many use cases to 
require security, but again, in those cases, it can be accomplished 
within the payload, not at the BP level.

Having said that, if I’m the only one in that camp, then I guess I’m 
loosing…

Marc.

> 	b.	On July 28, Brian Sipos supports the mandate in a limited way: 
> when bundle-level security is needed, that security must be provided 
> by BPSec rather than by some other mechanism.  [This language now 
> appears in section 9 of version 26 of the BPbis Internet Draft.]
> 	f.	On July 29, Ran Atkinson supports the mandate in a more expansive 
> way: implementation of BPSec is mandatory for any Bundle Protocol 
> Agent that sources, verifies, and/or accepts a bundle.  A BPA that 
> only forwards bundles (without verifying them) need not implement 
> BPSec.
> 2.	Is the registration policy for Bundle and Block Processing Control 
> flags in sections 10.3 and 10.4 of BPbis version 26 satisfactory?
> 3.	Does the language in section 5.4 Step 2 of BPbis version 26 
> satisfactorily address the question of mandating implementation of 
> TCPCL in the BPbis specification?
> 4.	Does the language in section 4.2.2 and 5.5 of BPbis version 26 
> satisfactorily address the question of authorizing Bundle Protocol 
> Agents to override the bundle lifetimes asserted by BP applications?
> 5.	Does the language in section 4.1.5.1.1 of BPbis version 26 
> satisfactorily address the question of discerning whether or not a 
> given dtn-scheme endpoint ID identifies a singleton endpoint?
> 6.	Does the language in section 10.6 of BPbis version 26 
> satisfactorily address the question of limiting the permitted number 
> of different BP URI scheme type codes?
> 7.	In version 26 of the BPbis specification, all BP time values (e.g., 
> bundle creation time, lifetime, bundle age) are denominated in 
> milliseconds rather than in seconds or microseconds.  Is this 
> satisfactory?
> 	a.	On July 28, Carsten Bormann notes that the CBOR representation of 
> time values could utilize tags to reduce transmission bandwidth 
> consumption.
> 	b.	On July 29, Jeremy Mayer endorses Carsten's idea: times may be 
> denominated in seconds (tag 1) or at other granularity (tag 1001).
> 	c.	On July 29, Ed Birrane warns that this concept introduces the 
> possibility of time values changing in transit, violating the 
> immutability of primary blocks.
> 	d.	On July 29, Rick Taylor, Scott Burleigh, Ed Birrane, and Ran 
> Atkinson discuss the question of what is really meant by the 
> immutability of the primary block: semantic immutability or syntactic 
> immutability?
> 	e.	On August 3, Adam Wiethuechter agrees with Ran that both semantic 
> immutability and syntactic immutability are required.  He believes 
> that denominating all DTN times in milliseconds is a good resolution.
> 8.	Does the language in section 4.3 of BPbis version 26 satisfactorily 
> address the question of whether implementation of all extension blocks 
> defined in the BPbis specification is mandatory or conditional?
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: "R. Atkinson" <[email-masked]>
Date: Wed, 16 Sep 2020 19:36:29 -0400

> On Sep 16, 2020, at 15:50, Marc Blanchet <[email-masked]> wrote:
> 
> I’m still opposed to have BPSEC be mandatory to implement as I think the security services can be done within the payload. IP is currently not secured on the Internet.

For over 25 years now, IP has had IP-layer security in the form of IPsec (ESP & AH).

See RFC-1825 through RFC-1827 to see just how far back IPsec goes.  My team
demonstrated open-source running code for IPsec in 4.4 BSD in August 1995.[1]

For many years, all IPv6 implementations were required to implement IPsec,
although I believe that constraint has been lifted recently (LONG AFTER IPsec
was nearly universally implemented by IPv6 devices and I believe the exemption
is for tiny IoT devices).

Automated key management (which BPsec does not provide yet) came a bit
later with RFC-2407, RFC-2408 and RFC-2409.

IPsec BOTH supports end-to-end security and also can support VPN access. 
In practice, IPsec is probably used more with VPNs but it does still support
end-to-end security.

Virtually every IP-capable device (laptops, paid OSs, free OSs, smart handphones) 
has implemented IPsec for many years now.  

While the original goal of IPsec was end-to-end (e.g., host-to-host) security

Whether one uses IPsec is a very different question from whether it is widely
implemented, just as whether one uses BPsec for a given session is quite 
separate from whether it should be mandatory to implement.

If security is NOT mandatory-to-implement, then users in practice will not be able
to use it in situations where they would like to use it.  The deployed Internet
has over 35 years experience with this operational reality.

> It is within the IP payload (TLS) that security services are applied.

Security services are offered at MANY layers in the deployed Internet.  

TLS is far from being the only game in town.  I discuss IPsec above,
but there are numerous other mandatory security capabilities both
within TCP and below.

Routing protocols have had built-in cryptographic security (e.g., RFC-2082 et seq
for RIP; RFC-2178 et seq for OSPFv2; RFC-2385 eq seq for BGP) for over 20 years.
Even newer routing protocols such as BABEL have been required to have 
cryptographic authentication (e.g., RFC-7298).

> I want a fully conformant BP implementation to ship without BPSec and without any specific use case (e.g. forwarding vs non-forwarding). However, I expect many use cases to require security, but again, in those cases, it can be accomplished within the payload, not at the BP level.

I am open to hear what you have to say, but right now it is FAR from obvious to me

(a) precisely what you mean by “accomplished within the payload”,

(b) where that specification is documented, 

or (c) how you propose that [hypothetical] security service would be mandated. 

Over 35 years of deployed Internet experience all says that security won’t be
available in practice if it isn’t mandatory to implement.  I doubt BP can get
through the IETF approval processes without mandatory-to-implement security
of some sort in a standards-track RFC.

Yours,

Ran

[1] "https://www.usenix.org/legacy/publications/library/proceedings/sd96/atkinson.html"

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 16 Sep 2020 20:14:15 -0400

On 16 Sep 2020, at 19:36, R. Atkinson wrote:

>> I’m still opposed to have BPSEC be mandatory to implement as I 
>> think the security services can be done within the payload. IP is 
>> currently not secured on the Internet.
>

i know all this. been there. done a lot, specially on IPv6. I would love 
to have IP layer security, but that did not happened. What is deployed 
currently is that VPNs are not using IPsec but TLS over UDP. Zero trafic 
of real IPsec end-to-end. Hence my point: current IP stacks are not 
using IPsec.

> Security services are offered at MANY layers in the deployed Internet.

right, the first one in the stack (from bottom to up) is TLS over 
TCP/UDP. reality now.

> cryptographic authentication (e.g., RFC-7298).

ok. that is the control plane. fine by me.

>
>> I want a fully conformant BP implementation to ship without BPSec and 
>> without any specific use case (e.g. forwarding vs non-forwarding). 
>> However, I expect many use cases to require security, but again, in 
>> those cases, it can be accomplished within the payload, not at the BP 
>> level.
>

to me, security (i.e. auth/encryption) makes only sense at the transport 
layer (in the IP sense), since the application making the socket know 
and can enforce the security services it needs, including taking care of 
the key management. At the IP layer, it is not available to the 
application. Moreover, IPsec may only occur within some parts of the 
network, so the application does not have the ability to enforce full 
end-to-end encryption for example.  Back to BP, I see again that BPsec 
does not provide that facility to the application and does not warrant 
complete end-to-end security with the requirements the application 
wants/need.

> available in practice if it isn’t mandatory to implement.

we (I was involved a lot in IPv6, so…) tried hard to make IPsec 
mandatory for IPv6. I was one deeply involved in IPv6 and pushing IPsec, 
but it just did not happen. We failed.

> I doubt BP can get

I’m fine with having security mandatory to implement, but not at the 
BP layer (e.g. BPSec). That is what I’m saying. I’m not against 
BPsec, on the contrary, I’m just saying that it should not be 
mandatory to implement for all BP implementations and that security can 
be handled higher in the stack.

Regards, Marc.

>
> Yours,
>
> Ran
>
> [1] 
> "https://www.usenix.org/legacy/publications/library/proceedings/sd96/atkinson.html"
>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 17 Sep 2020 00:34:04 +0000

Hi, Marc.  One note of clarification: BPSec does provide "end-to-end" encryption (and/or integrity protection) if by "ends" we mean the bundle protocol agent that the sending application entity utilizes to transmit the data and the bundle protocol agent that the receiving application entity utilizes to receive the data.

If by "ends" you instead mean the sending and receiving application entities themselves, then of course BPSec doesn't provide end-to-end security service at that layer of the stack; BPSec provides security service at the bundle layer, not at the application layer.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Marc Blanchet
Sent: Wednesday, September 16, 2020 5:14 PM
To: R. Atkinson <[email-masked]>
Cc: DTN WG <[email-masked]>
Subject: [EXTERNAL] Re: [dtn] BPbis consensus status

On 16 Sep 2020, at 19:36, R. Atkinson wrote:

>> not secured on the Internet.
>
> See RFC-1825 through RFC-1827 to see just how far back IPsec goes.  My 
> team demonstrated open-source running code for IPsec in 4.4 BSD in 
> August 1995.[1]
>
> For many years, all IPv6 implementations were required to implement 
> IPsec, although I believe that constraint has been lifted recently 
> (LONG AFTER IPsec was nearly universally implemented by IPv6 devices 
> and I believe the exemption is for tiny IoT devices).
>
> In practice, IPsec is probably used more with VPNs but it does still 
> support end-to-end security.
>
> Whether one uses IPsec is a very different question from whether it is 
> widely implemented, just as whether one uses BPsec for a given session 
> is quite separate from whether it should be mandatory to implement.

i know all this. been there. done a lot, specially on IPv6. I would love to have IP layer security, but that did not happened. What is deployed currently is that VPNs are not using IPsec but TLS over UDP. Zero trafic of real IPsec end-to-end. Hence my point: current IP stacks are not using IPsec.

>
> If security is NOT mandatory-to-implement, then users in practice will 
> not be able to use it in situations where they would like to use it.  
> The deployed Internet has over 35 years experience with this 
> operational reality.
>

right, the first one in the stack (from bottom to up) is TLS over TCP/UDP. reality now.

> or (c) how you propose that [hypothetical] security service would be 

to me, security (i.e. auth/encryption) makes only sense at the transport layer (in the IP sense), since the application making the socket know and can enforce the security services it needs, including taking care of the key management. At the IP layer, it is not available to the application. Moreover, IPsec may only occur within some parts of the network, so the application does not have the ability to enforce full end-to-end encryption for example.  Back to BP, I see again that BPsec does not provide that facility to the application and does not warrant complete end-to-end security with the requirements the application wants/need.

> Over 35 years of deployed Internet experience all says that security 
> won’t be available in practice if it isn’t mandatory to implement.

we (I was involved a lot in IPv6, so…) tried hard to make IPsec mandatory for IPv6. I was one deeply involved in IPv6 and pushing IPsec, but it just did not happen. We failed.

> I doubt BP can get
> through the IETF approval processes without mandatory-to-implement 
> security of some sort in a standards-track RFC.

I’m fine with having security mandatory to implement, but not at the BP layer (e.g. BPSec). That is what I’m saying. I’m not against BPsec, on the contrary, I’m just saying that it should not be mandatory to implement for all BP implementations and that security can be handled higher in the stack.

Regards, Marc.

>
> Yours,
>
> Ran
>
> [1]
> "https://urldefense.us/v3/__https://www.usenix.org/legacy/publications/library/proceedings/sd96/atkinson.html__;!!PvBDto6Hs4WbVuu7!eVZ4Yi2LPtGgdO4l426u_10Z28qXwJkfCX-hKp8iI7mtkO2LnXkcJpScQqy_18hxoKEdLqFyYEk$ "
>
> https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/dtn__
> ;!!PvBDto6Hs4WbVuu7!eVZ4Yi2LPtGgdO4l426u_10Z28qXwJkfCX-hKp8iI7mtkO2LnX
> kcJpScQqy_18hxoKEdz3iyPDg$

_______________________________________________
dtn mailing list
[email-masked]
https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!eVZ4Yi2LPtGgdO4l426u_10Z28qXwJkfCX-hKp8iI7mtkO2LnXkcJpScQqy_18hxoKEdz3iyPDg$

---

From: "Birrane, Edward J." <[email-masked]>
Date: Thu, 17 Sep 2020 03:03:45 +0000

Three points on BPSec:

1. The current BPSec document makes reference to "security-aware" nodes and in doing so postulates the existence of "security-unaware" nodes. If BPSec is mandatory to implement then there are no "security-unaware" nodes and I can make the adjustment to the BPSec specification to clarify that.

2. I read Marc's point as stating that security at the bundle layer is optional because security may be implemented by the payloads encapsulated by, or encapsulating the, bundle. To the extent that this allows a bundle without bundle security to be processed, I agree. Not every bundle may need BPSec.

3. Mandatory-to-Implement is a characteristic of the BP Agent , not the bundle. Even if the agent never produces a BPSec secured bundle, ignoring BPSec blocks in arriving bundles may become a vulnerability. What happens when a security-unaware BPA receives a bundle whose payload was encrypted with a BCB? Can a malicious node/BPA add fake BCBs to a bundle in the hopes that security-unaware BPAs will simply pass the traffic? Can a security-unaware node even have an expressive security policy around BPSec without implementing BPSec?

In short - I agree that there are many cases when a BPA may choose to not produce bundles with BPSec.  However, I am increasingly worried that a security-unaware BPSec may lead to unintended consequences.

For that reason, my intuition is that BPSec probably should be mandatory to implement by a BPA. Otherwise that one "efficient security unaware node" might become the security threat entry point.

Of course, I defer to the WG on the best way forward - but if BPSec becomes MTI, I will spin a new BPSec document shortly to note that.

-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

> From: dtn <[email-masked]> On Behalf Of Burleigh, Scott C (US 312B)
> Sent: Wednesday, September 16, 2020 8:34 PM
> To: Marc Blanchet <[email-masked]>; R. Atkinson
> <[email-masked]>
> Subject: [EXT] Re: [dtn] [EXTERNAL] Re: BPbis consensus status
> 
> APL external email warning: Verify sender [email-masked] before
> clicking links or attachments
> 
> Hi, Marc.  One note of clarification: BPSec does provide "end-to-end"
> encryption (and/or integrity protection) if by "ends" we mean the bundle
> protocol agent that the sending application entity utilizes to transmit the data
> and the bundle protocol agent that the receiving application entity utilizes to
> receive the data.
> 
> If by "ends" you instead mean the sending and receiving application entities
> themselves, then of course BPSec doesn't provide end-to-end security
> service at that layer of the stack; BPSec provides security service at the
> bundle layer, not at the application layer.
> 
> Scott
> 
> i know all this. been there. done a lot, specially on IPv6. I would love to have
> IP layer security, but that did not happened. What is deployed currently is
> that VPNs are not using IPsec but TLS over UDP. Zero trafic of real IPsec end-
> to-end. Hence my point: current IP stacks are not using IPsec.
> 
> >
> to me, security (i.e. auth/encryption) makes only sense at the transport layer
> (in the IP sense), since the application making the socket know and can
> enforce the security services it needs, including taking care of the key
> management. At the IP layer, it is not available to the application. Moreover,
> IPsec may only occur within some parts of the network, so the application
> does not have the ability to enforce full end-to-end encryption for example.
> Back to BP, I see again that BPsec does not provide that facility to the
> application and does not warrant complete end-to-end security with the
> requirements the application wants/need.
> 
> we (I was involved a lot in IPv6, so…) tried hard to make IPsec mandatory for
> IPv6. I was one deeply involved in IPv6 and pushing IPsec, but it just did not
> happen. We failed.
> 
> > I doubt BP can get
> I’m fine with having security mandatory to implement, but not at the BP layer
> (e.g. BPSec). That is what I’m saying. I’m not against BPsec, on the contrary,
> I’m just saying that it should not be mandatory to implement for all BP
> implementations and that security can be handled higher in the stack.
> 
> Regards, Marc.
> 
> >
> > Yours,
> >
> > Ran
> >
> > [1]
> >
> "https://urldefense.us/v3/__https://www.usenix.org/legacy/publications/li
> brary/proceedings/sd96/atkinson.html__;!!PvBDto6Hs4WbVuu7!eVZ4Yi2LPt
> GgdO4l426u_10Z28qXwJkfCX-
> hKp8iI7mtkO2LnXkcJpScQqy_18hxoKEdLqFyYEk$ "
> >
> https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/dtn__;!!
> PvBDto6Hs4WbVuu7!eVZ4Yi2LPtGgdO4l426u_10Z28qXwJkfCX-
> hKp8iI7mtkO2LnXkcJpScQqy_18hxoKEdz3iyPDg$

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 16 Sep 2020 23:25:53 -0400

On 16 Sep 2020, at 20:34, Burleigh, Scott C (US 312B) wrote:

> encryption (and/or integrity protection) if by "ends" we mean the 
> bundle protocol agent that the sending application entity utilizes to 
> transmit the data and the bundle protocol agent that the receiving 
> application entity utilizes to receive the data.
>
> If by "ends" you instead mean the sending and receiving application 
> entities themselves, then of course BPSec doesn't provide end-to-end 
> security service at that layer of the stack; BPSec provides security 
> service at the bundle layer, not at the application layer.

exactly. again, nothing wrong in having security at the BP layer. 
People/use cases might like to do that there. My only point is to not 
make it mandatory, since, as current Internet deployment tells us, the 
applications need to be aware of security services and this happens 
within the payload of the IP/BP, not at the IP/BP layer.

Marc.

>>> think
> i know all this. been there. done a lot, specially on IPv6. I would 
> love to have IP layer security, but that did not happened. What is 
> deployed currently is that VPNs are not using IPsec but TLS over UDP. 
> Zero trafic of real IPsec end-to-end. Hence my point: current IP 
> stacks are not using IPsec.
>
>>
>> for RIP; RFC-2178 et seq for OSPFv2; RFC-2385 eq seq for BGP) for 
>> over
>> 20 years.
> to me, security (i.e. auth/encryption) makes only sense at the 
> transport layer (in the IP sense), since the application making the 
> socket know and can enforce the security services it needs, including 
> taking care of the key management. At the IP layer, it is not 
> available to the application. Moreover, IPsec may only occur within 
> some parts of the network, so the application does not have the 
> ability to enforce full end-to-end encryption for example.  Back to 
> BP, I see again that BPsec does not provide that facility to the 
> mandatory for IPv6. I was one deeply involved in IPv6 and pushing 
> IPsec, but it just did not happen. We failed.
>
>> I doubt BP can get
> mandatory to implement for all BP implementations and that security 
> can be handled higher in the stack.
>
> Regards, Marc.
>
>>
>> Yours,
>>
>> Ran
>>
>> [1]

---

From: "R. Atkinson" <[email-masked]>
Date: Thu, 17 Sep 2020 18:46:11 -0400

> On Sep 16, 2020, at 23:25, Marc Blanchet <[email-masked]> wrote:
> ... as current Internet deployment tells us, the applications need to be aware
> of security services ...

Marc,

Your words above - to the extent they are true — are a reason 
to have a well documented BPsec API which applications can use
if/when appropriate.

Such an API probably should be documented in an Informational RFC.
Is that something you might want to undertake — since you are so
passionate about it ??

From a logic perspective, those words quoted above are really NOT a reason 
for  BPsec to be optional to implement.

Yours,

Ran

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Sep 2020 14:03:26 +0000

Hi,

Personal opinions below. 

Marc, I think comparing BPSec with IP and IPsec is wrong for several reasons. I
think one of the more significant ones are related to the identification of the
peer entitity and who you are and establishing security between these two
entities end-to-end. IPSec is to low level for that to work in the Internet as
endpoint or possibly whole networks (due to NATs) exist under the umbrella of an
IP address. However, I don't see that being the case for BP. Here BP can address
the applicaiton specifically and create security association end-to-end between
the application entities on different nodes. Becasue the BP agent can provide
unique DTN addresses for each application and establish different BPSec security
contexts to prevent this missmatch. So BPSec has all the chance of being the
basic security layer end-to-end that IPsec never succed as. 

Yes, there are hurdle to get the details for security contexts (security
profile) and its key-management done. But without this I don't see how DTN will
even become more that narrow nichese where it is used ontop of a private
network. There are some utility in that, but far from the promise of the network
and networks for delay tolerant applications that could use a interwork layer. I
think BP can succeed, but not without a security solution that work and are
generally available and supported. 

Cheers

Magnus

-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile +46 73 0949079
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 18 Sep 2020 10:07:44 -0400

> basic security layer end-to-end that IPsec never succed as.

well, I personally disagree and still stand. However, as I wrote some 
emails ago, it seems that I’m the only one in this email list on that 
side, so I’m loosing and it is fine. We shall just proceed with the 
concensus of the group. No issues for me to proceed the way the group 
wants

Regards, Marc.

>>> ... as current Internet deployment tells us, the applications need 
>>> to be
>>> aware
>>> of security services ...
>>
>> Marc,
>>

---

From: Lloyd W <[email-masked]>
Date: Thu, 24 Sep 2020 19:19:39 +1000

hi Scott,

what do you mean by "verify" here?

A bundle can contain a checksum (section 4.1) and that checksum SHOULD/MUST (imo) be checked before a bundle is forwarded further, to prevent transmitting corruption that would e.g. misdirect a bundle.

Is that "verification"? That affects the interpretation of your statement of Ran's 1f.

Lloyd Wood
[email-masked]

Your quality source for focused bundle checksum concerns for over a decade.

> On 17 Sep 2020, at 05:43, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> wrote:
>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 24 Sep 2020 14:06:58 +0000

Hi, Lloyd.  Ran used the word "verify" in his post of July 29, so this is really a question for him; I just excerpted his language.

In the context of that thread, my own understanding of "verify" here would be to confirm the integrity of the bundle by checking the security results of its block integrity blocks against their targets.  Checking the security results of the BIB covering the primary block would additionally confirm the bundle's authenticity, provided the bundle was not anonymous.

But again this is strictly my own understanding, I can't speak for Ran.

Scott

-----Original Message-----
From: Lloyd W <lloyd.wood=[email-masked]> 
Sent: Thursday, September 24, 2020 2:20 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [dtn] BPbis consensus status

hi Scott,

Lloyd Wood
[email-masked]

> https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!a3XWTUOXdqmodzQfpyIFhIhyqxpJfG8fXEahPmjUmrnDhFgypBoBnuD7AXVBfcD5MgWY-vdSnkM$

---

From: "R. Atkinson" <[email-masked]>
Date: Thu, 24 Sep 2020 13:40:37 -0400

Lloyd,

If this is a question about quoted item #1 in Scott’s note below, then I can clarify that my original intended meaning for “verify” would be "cryptographically verify”.

Probably some slight editing (e.g., insert the word “cryptographically” in the right place) to the earlier proposed text would be desirable to make that meaning more clear.

I don’t know what others in the WG think about that (slight) change to the earlier proposed text.

Yours,

Ran

> On Sep 24, 2020, at 05:19, Lloyd W <lloyd.wood=[email-masked]> wrote:
> 
> hi Scott,
>