Subject: [dtn-interest] BP-Tables

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 23 Apr 2012 10:01:36 -0500

A small team at NASA Glenn Research Center is looking at implementing the equivalent of IP-Tables for Store-Carry-and-Forward  (Disconnected) Networking

The following are some rough notes from our kickoff brainstorming session.  Anyone who has some ideas on what they might like to see, we would love to hear from you.

We plan to put together an internet draft document some of our thoughts.

A couple of things that sort of stood out:

*  We probably need something like ICMP (BCMP) to return status (with every node listening for this service
* It really would be nice to have services/applications separate from URI
* A more consistant/uniform naming scheme would be very useful
* It would be useful to be able to filer on something like organization (gets into a lot of mixing of Security/keys with identity verification)

Filtering on:
Size
Source URI
Destination URI
Lifetime (TTL) (limit acceptance of bundle based on time).
Hop Count (???)
Service (application == IP port) (how to determine???)

Should service be separate from URI?  (not currently possible in RFC 5050)
Key to deployment is Identity-based, not address-based - So do we need PIB to implement?
In RFC5050 - there is no addressing.  IP-tables are address-based.
Allocate resources (size, etc.) by URI.
Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?)
IP-Tables can filter on all fields, BP-Tables (should it also do equivalent?)
BP-Tables may help manage resource allocation for quality of service (50% "bulk" bundles, 50% "scheduled service" for example).

ID BP-Tables

 1.  Intro
    *   Why BP-Tables
 2.  IP-Tables
    *   What does IP-tables do
 3.  BP-Tables
    *   What is different
    *   What is similar
    *   What it should do
    *   What it can do
 4.  Items of interest
    *   URI vs. identity
    *   URI vs. application/service
    *   How do we identify application/service
 5.  ICMP -> BCMP
    *   Status replies
 6.  Network management and BP-Tables
 7.  Security Section
    *   BAB, PIB, and PCB key distribution

- Will

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 23 Apr 2012 11:35:17 -0400

- good idea!
- you should look at draft-blanchet-dtnrg-bp-app-framework as a way to identify service id in a normalized way.

Marc.

Le 2012-04-23 à 11:01, Ivancic, William D. (GRC-RHN0) a écrit :

> Intro
> Why BP-Tables
> IP-Tables
> What does IP-tables do
> BP-Tables
> What is different
> What is similar
> What it should do
> What it can do
> Items of interest
> URI vs. identity
> URI vs. application/service
> How do we identify application/service
> ICMP -> BCMP
> Status replies
> Network management and BP-Tables
> Security Section
> BAB, PIB, and PCB key distribution
> 
> - Will
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Simon Perreault <[email-masked]>
Date: Mon, 23 Apr 2012 11:42:26 -0400

On 2012-04-23 11:01, Ivancic, William D. (GRC-RHN0) wrote:
> A small team at NASA Glenn Research Center is looking at implementing
> the equivalent of IP-Tables for Store-Carry-and-Forward (Disconnected)
> Networking

Cool!

> The following are some rough notes from our kickoff brainstorming
> session. Anyone who has some ideas on what they might like to see, we
> would love to hear from you.

One thing that comes to mind and that I don't see in your list is 
statefulness. How would a stateful firewall work in DTN? Is it even 
possible/desirable?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 23 Apr 2012 10:43:07 -0500

Thanks,  Marc.  I was looking for that.  I saw the IANN document, but not this in the DTRNG wiki.  Perhaps you can put it on DTNRG wiki documents?  If not, let me know and I'll put in on.

I think in the long run, we are going to find that putting the service as part of the URI is not desirable.  It may be OK for a research protocol, but probably not beyond.  Thinks like BP-Table sort of make this apparent.

- Will

On Apr 23, 2012, at 11:35 AM, Marc Blanchet wrote:

- good idea!

Marc.

Filtering on:
Size
Source URI
Destination URI

ID BP-Tables

 1.  Intro
    *   Why BP-Tables
 2.  IP-Tables
    *   What does IP-tables do
 3.  BP-Tables
    *   What is different
    *   What is similar
    *   What it should do
    *   What it can do
 4.  Items of interest
    *   URI vs. identity

- Will
_______________________________________________
dtn-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/dtn-interest

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 23 Apr 2012 15:47:07 +0000

Will, is it really important to manage service/application separate from endpoint ID (which is what I think you are saying when you say URI)?  I can see why you need to be able to identify the service/application that characterizes a bundle, but I think you're okay so long as you can always trivially infer service/application from the EID.  Certainly that's already easy to do if you're using "ipn"-scheme EIDs, according to the formal definition of the scheme, but it ought to be easy to tweak the "dtn" scheme definition for this purpose as well if necessary.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Monday, April 23, 2012 8:02 AM
To: [email-masked]
Subject: [dtn-interest] BP-Tables

Filtering on:
Size
Source URI
Destination URI

ID BP-Tables
1.     Intro
o    Why BP-Tables
2.     IP-Tables
o    What does IP-tables do
3.     BP-Tables
o    What is different
o    What is similar
o    What it should do
o    What it can do
4.     Items of interest
o    URI vs. identity
o    URI vs. application/service
o    How do we identify application/service
5.     ICMP -> BCMP
o    Status replies
6.     Network management and BP-Tables
7.     Security Section
o    BAB, PIB, and PCB key distribution

- Will

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 23 Apr 2012 10:49:32 -0500

> statefulness. How would a stateful firewall work in DTN? Is it even 

Simon,  

'm not sure what you are asking?   

Are you asking about something like NATing/Masquerading?  
or Something else?
Can you please clarify?  

We sort of briefly discussed Masquerading, but not with a lot of thought yet.  We are not sure of its usefulness yet.

Thanks,

- Will

---

From: "Hylton, Alan G. (GRC-RHN0)" <[email-masked]>
Date: Mon, 23 Apr 2012 10:58:16 -0500

Howdy,

I think that this gets at a need for standardization of services.

Also, as an illustration, 3.3 might listen to 4.whatever, and 3.4 might listen to 5.whatever. Say you want to assure 4 that 1GB is set aside and 5 gets 2GB when receiving data. Part of the need for BP Tables is to have resource management in a general network setting. This guarantees that several science missions attached to a non-earth hub (a future TDRSS might be an axle between several hub-n-spokes) do not fight each other.

Alan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (313B)
Sent: Monday, April 23, 2012 11:47 AM
To: Ivancic, William D. (GRC-RHN0); [email-masked]
Subject: Re: [dtn-interest] BP-Tables

Scott

Filtering on:
Size
Source URI
Destination URI

ID BP-Tables
1.   Intro
o  Why BP-Tables
2.   IP-Tables
o  What does IP-tables do
3.   BP-Tables
o  What is different
o  What is similar
o  What it should do
o  What it can do
4.   Items of interest
o  URI vs. identity

- Will

---

From: "Iannicca, Dennis C. (GRC-RHN0)" <[email-masked]>
Date: Mon, 23 Apr 2012 10:58:50 -0500

> We sort of briefly discussed Masquerading, but not with a lot of thought yet.  We are not sure of its usefulness yet.
	
	I'm not sure that BP should necessarily care about maintaining a state as there is no inherent acknowledgements (unless we start talking about convergence layers).  I would think it's either going to be a convergence layer problem or an application layer problem to worry about keeping state.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 23 Apr 2012 12:00:10 -0400

> Are you asking about something like NATing/Masquerading?

Not necessarily.

> We sort of briefly discussed Masquerading, but not with a lot of thought yet.  We are not sure of its usefulness yet.

Agreed.

I'm thinking about the kind of firewall that tracks flows to ensure that 
flags make sense with the current state of the flow, to allow return 
packets, etc.

With iptables, the conntrack module handles statefulness.

IMHO the best example of a stateful firewall is pf, the one from OpenBSD 
and FreeBSD. In pf, everything is stateful by default, so you can just 
say things such as

pass out on em0 proto tcp to any port 80

and have it pass inbound packets associated with an established outbound 
flow.

Simon

---

From: "Clark, Gilbert" <[email-masked]>
Date: Mon, 23 Apr 2012 12:02:16 -0400

Cool stuff.  A few thoughts:

* YMMV, but I really believe that actively querying a DTN node has limited
applicability in the general case.  Thus, BCMP's interactivity might be
better defined as an interface by which to add new information to
heartbeat messages and / or define new triggers upon which to send data.
(Full disclosure: that's a shameless plug for stuff I'm working on.  Sorry
:)

* I like the idea of divorcing services / applications from the URL, but
that would probably necessitate some kind of IDL that could describe the
services / applications available at a certain endpoint.  When we start
doing that, it seems to me we've arrived back at problems that HTTP / WSDL
were designed to solve.  Am I missing something there?

* Regex would be *really*, *really* useful.

* Eventually, I could see a list of these definitions handling all the
*local* routing on the node, not just firewall rules.  For example:

bptables --src source.dtn --endpoint-match ^/my/service/.* --route-to
local:1234 
bptables --src source.dtn --endpoint-match ^/diagnostics/.* --route-to
local:1235

Just my $0.02; hope something in there is useful food for thought.

--Gilbert

From:  "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date:  Mon, 23 Apr 2012 11:01:36 -0400
To:  "[email-masked]" <[email-masked]>
Subject:  [dtn-interest] BP-Tables

A small team at NASA Glenn Research Center is looking at implementing the
equivalent of IP-Tables for Store-Carry-and-Forward  (Disconnected)
Networking

The following are some rough notes from our kickoff brainstorming session.
 Anyone who has some ideas on what they might like to see, we would love
to hear from you.  

*  We probably need something like ICMP (BCMP) to return status (with
every node listening for this service
* It really would be nice to have services/applications separate from URI
* A more consistant/uniform naming scheme would be very useful
* It would be useful to be able to filer on something like organization
(gets into a lot of mixing of Security/keys with identity verification)

Filtering on:
Size
Source URI
Destination URI

Should service be separate from URI?  (not currently possible in RFC 5050)
Key to deployment is Identity-based, not address-based - So do we need PIB
to implement?
In RFC5050 - there is no addressing.  IP-tables are address-based.
Allocate resources (size, etc.) by URI.
Bundling needs the equivalent of IP-ICMP. (Bundle Control Message
Protocol?)
IP-Tables can filter on all fields, BP-Tables (should it also do
equivalent?)
BP-Tables may help manage resource allocation for quality of service (50%
"bulk" bundles, 50% "scheduled service" for example).

ID BP-Tables

1. Intro
     * Why BP-Tables
2. IP-Tables
     * What does IP-tables do
3. BP-Tables
     * What is different
     * What is similar
     * What it should do
     * What it can do
4. Items of interest
     * URI vs. identity

- Will

---

From: Simon Perreault <[email-masked]>
Date: Mon, 23 Apr 2012 12:02:50 -0400

> 	I'm not sure that BP should necessarily care about maintaining a state as there is no inherent acknowledgements (unless we start talking about convergence layers).  I would think it's either going…

UDP also doesn't have inherent acknowledgements yet many firewalls 
operate statefully on UDP flows, including iptables.

Simon

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 23 Apr 2012 16:12:03 +0000

Alan, I certainly agree about the need for standardization of service identifiers.  FWIW, I believe CCSDS is already working on standardizing ipn-scheme service numbers through IANA.

I'm less clear on your illustration, though.  What you're describing sounds to me more like QoS than the sort of thing I usually think of a firewall supporting.  What's the argument for performing this function in bptables rather than in, say, routing?

Scott

From: Hylton, Alan G. (GRC-RHN0) [mailto:[email-masked]]
Sent: Monday, April 23, 2012 8:58 AM
To: Burleigh, Scott C (313B); Ivancic, William D. (GRC-RHN0); [email-masked]
Subject: RE: BP-Tables

Howdy,

Alan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Burleigh, Scott C (313B)
Sent: Monday, April 23, 2012 11:47 AM
To: Ivancic, William D. (GRC-RHN0); [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] BP-Tables

Scott

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Monday, April 23, 2012 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn-interest] BP-Tables

Filtering on:
Size
Source URI
Destination URI

ID BP-Tables
1.   Intro
o  Why BP-Tables
2.   IP-Tables
o  What does IP-tables do
3.   BP-Tables
o  What is different
o  What is similar
o  What it should do
o  What it can do
4.   Items of interest
o  URI vs. identity

- Will

---

From: "Iannicca, Dennis C. (GRC-RHN0)" <[email-masked]>
Date: Mon, 23 Apr 2012 12:28:44 -0500

> operate statefully on UDP flows, including iptables.

True.  It's something to consider.  I'm just thinking that once you start treating a series of bundles as an associated session which may or may not contain reply bundles you will need to worry about synchronizing state tables between forwarding nodes since the reply could take another path back.  Perhaps we should call this BP-chains at first. ;-)

---

From: "Hylton, Alan G. (GRC-RHN0)" <[email-masked]>
Date: Mon, 23 Apr 2012 12:34:27 -0500

I see a lot of overlap between what BP Tables would/should offer with other networking concepts. Indeed, there is some QoS here and network management. It still seems appropriate to me to have one table to rule them all, so to speak. Ensuring that there is enough resources left to get all of the science data is necessary for scientists to be on board with DTN both for space and earth missions. Having policies at the node level is the first step towards this form of control over the entire network as a system. It makes the most sense to me to have these policies consolidated as I see the role of BP Tables being bigger to DTNs than IP Tables to non-tolerant networks. This is just me, of course, which is why this is brought before the group.

It occurs to me that having policies spread out over many separate entities does not scale with large networks and would make it tougher to maintain consistency.

I see the routers as complex enough to stand alone. To include the capability to pick apart bundles and determine if they meet certain policies would make them overweight. That being said, I would expect BP Tables to consult with the router at some point. I would not be surprised if ultimately BP Tables would talk to a BCMP (ICMP counterpart).

For now, I think the least invasive way of adding to DTN is to add one section that manages these concerns. If the BP Tables implementation is flexible enough it can handle a host of policies (to be pruned, eventually, I am sure) rather than modifying and adding. This makes it easier to have ION and DTN2 (hopefully, IBR someday?) implementations.

Alan

From: Burleigh, Scott C (313B) [mailto:[email-masked]]
Sent: Monday, April 23, 2012 12:12 PM
To: Hylton, Alan G. (GRC-RHN0); Ivancic, William D. (GRC-RHN0); [email-masked]
Subject: RE: BP-Tables

Scott

Howdy,

Alan

Scott

Filtering on:
Size
Source URI
Destination URI

ID BP-Tables
1.Intro
o Why BP-Tables
2.IP-Tables
o What does IP-tables do
3.BP-Tables
o What is different
o What is similar
o What it should do
o What it can do
4.Items of interest
o URI vs. identity
o URI vs. application/service
o How do we identify application/service
5.ICMP -> BCMP
o Status replies
6.Network management and BP-Tables
7.Security Section
o BAB, PIB, and PCB key distribution

- Will

---

From: Greg Troxel <[email-masked]>
Date: Mon, 23 Apr 2012 13:40:10 -0400

I would suggest that you also look at other-than-Linux firewall
implementations (ipfilter, ipfw, pf, npf) as part of the early stages of
investigation.

One issue in IP firewalling that has been muddled in at least several
implementations is separating:

  - controlling what traffic can transit a router, and
  - controlling what traffic can access a host

This seems important in BP as well.

Another thing to think about early is how firewalls relate to
opportunistic transfer over wireless -- what are you trying to protect,
and why?  With BP, the traditional notion of "inside the firewall" seems
harder to pin down, and if that notion is unsound, controlling transit
traffic becomes less interesting.

---

From: "Fall, Kevin" <[email-masked]>
Date: Mon, 23 Apr 2012 17:49:27 +0000

A few thoughts-

Regarding the 'things that sort of stood out':

  *   I'd say the Internet experience of ICMP is that we'd prefer to have signaling coupled with the data transfer.  The bundle protocol does this I believe.
  *   It was intended to combine the services/applications in the URI; this is extremely useful for web apps for example, where a service may wish to eat variable amounts of the URI as arguments.  It also comes up in cache control.  This generalizes where different location in the topology may be interested in different prefixes of the URI.  Further, it would seem to me that the "bad traffic" is unlikely to arrange the service/app ID they way you'd like it to be.
  *   Yes, I agree that more consistent/uniform naming for at least a few schemes would be good
  *   Sure, it could be.  But more useful may be something related the type of content or the tags on the content.

So, most of the "filtering on" items in the list don't seem fundamental (or maybe even that useful).  The architecture describes 'security gateways' that might check various credentials at interesting locations in the network.  That could use some investigation, imho.

- K

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]<mailto:[email-masked]>>
Date: Mon, 23 Apr 2012 10:01:36 -0500
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [dtn-interest] BP-Tables

Filtering on:
Size
Source URI
Destination URI

ID BP-Tables

  1.  Intro
     *   Why BP-Tables
  2.  IP-Tables
     *   What does IP-tables do
  3.  BP-Tables
     *   What is different
     *   What is similar
     *   What it should do
     *   What it can do
  4.  Items of interest
     *   URI vs. identity

- Will
_______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 23 Apr 2012 13:03:49 -0500

Maybe a better term (for generic)  than BP-Tables would be BP-Firewall

-Will

On Apr 23, 2012, at 1:40 PM, Greg Troxel wrote: