Subject: [dtn] BPbis and BPSec

From: Rick Taylor <[email-masked]>
Date: Mon, 30 Jan 2017 10:27:33 +0000

All,

One of the most important issues that Stephen raises in his comments on
BPbis is the relationship between the draft and BPsec.  As you are all
aware, BPsec is not yet in WG Last Call.

If I understand Kapali's comments correctly, he suggests two possible
ways forward: The IPv4 way, and the IPv6 way.  I won't repeat his
excellent description here, but the gist of is: IPv4 says "You can do
extensions like this, and security might be a sensible extension", IPv6
says "This is where the security extension fits".

My understanding of the opinion of the working group is that BPsec is
the adopted method for securing BPbis. So my question(s) to the WG
group are:

1) Do we want to reference BPsec in BPbis (and vice-versa) - the IPv6
method?

1a) If yes to 1) BPsec needs to go for Last Call, and this will hold
back BPbis until both are ready: Is the WG happy to delay BPbis and
TCPCLv4?

1b) If no to 1) Is the WG happy to have alternate valid methods of
securing BPbis permitted by BPbis - The IPv4 method?

Comments please, especially if you think I've missed the point!

Rick

---

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 30 Jan 2017 07:52:16 -0500

> securing BPbis permitted by BPbis - The IPv4 method?

commenting as an individual.

There are multiple ways to secure a communication. IP deployment has 
shown that even where IPSec was « bundled » in IPv6, its deployment 
remains marginal, compared to TLS. TLS encrypts the payload without 
modifying anything in the IP headers and it is also controlled by the 
upper layer stack: an app can manage that secure connection, apply 
policies, etc…  By analogy, an encryption method within the payload of 
DTN that have no impact whatsoever on the DTN header might be worth 
considering.

Marc.

> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Jan 2017 10:06:20 +0000

Hi Rick,

> Comments please, especially if you think I've missed the point!

I think this misses the point that we had a definition for
how to secure the experimental RFC 5050. I really don't see
how it's credible to promote 5050bis as a proposed standard
but yet go "backwards" in terms of not having a well-defined
set of security mechanisms documented for 5050bis.

That says nothing about whether bpsec is mandatory to implement
or use nor about whether there could be additional specs that
define how to do security stuff.

I also don't think the analogy with IPv6 and IPsec is that
useful.

In terms of your questions above, I guess it may be clear
that I do favour holding 5050bis in the WG or RFC editor
queue until bpsec is done. Doing that by making the
reference to bpsec normative should work fine if that's
the outcome. And that also seems much more in line with the
WG charter which also calls for a standards track version
of RFC6257 to be produced.

S.

---

From: Rick Taylor <[email-masked]>
Date: Tue, 31 Jan 2017 13:12:19 +0000

Hi Stephen,

Commenting as an individual...

> set of security mechanisms documented for 5050bis.

I agree, BPbis without BPsec is a bad idea my opinion.

> define how to do security stuff.

And I agree that is currently unclear in the draft.

> I also don't think the analogy with IPv6 and IPsec is that

In my defence it wasn't my analogy, but it seemed a reasonable place to
start a discussion.  I'm sorry if it's misleading.

> of RFC6257 to be produced.

Yes, a BPsec standards track document is a WG charter item.  My
question for the group was trying to ask whether we should hold BPbis
(and TCPCLv4) for it or not.  My personal opinion is to hold BPsec
after WG Last Call, when the WG feels the draft is complete apart from
BPsec.

Are there any more opinions out there? Ed, how 'ready' do you feel
BPsec is?

Rick