Subject: [I2nsf] Packet-based model

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 09:40:40 -0400

Hi.  This does not affect the charter nor whether the group should be
chartered.

However, I wanted to explore the packet-based model for NSFs.
At the mic, Ed explained that he wanted this model because it's more
complex than flows.  Detecting scans, floods, DDOSes and other activity
involves more than one flow.
However, all the NSFs process packets.

I think my confusion comes from the fact that the framework and
information model document talk more about the parts of the space that
we understand than the parts we don't understand.

Packet-based (and context-based) information is used to decide what
per-packet processing to do.
That is, we might use packet information to decide that we want an IPS
to look at something.

The IPs can categorize things however it wants, but its input is
packets.  It can reassemble flows, track behavior of netblocks, track
behavior of users across devices, whatever it likes.
But we're going to use characteristics of packets and there contexts to
decide what functions to invoke.

This is more pronounced in the information model document.  Reading that
document it would be easy to come away with the idea that a main point
of the system is to actually act on those packets using the basic
actions, rather than invoke one of the security functions.  I think
better alignment between the framework and information model here would
help a lot.  I also think scoping the packet model to selection would
help.

However, I'd also like to ask some hypothetical questions to make sure
packets are the right model.

The packet model seems like it makes sense for any (semi)-transparent
security function.  That is, the security function is not the
destination address/port in the packet.  It may well modify the packets
to indicate it has inspected them; it may in some cases re-stream a
flow, but it's a network or transport-layer middlebox.

However there are a lot of other security functions.  I can set up a
mail scanner that my external MXes point to.  It's the actual
destination for my mail.  It may store-and-forward, will almost
certainly produce its own output streams, probably uses a different
identity for outbound connections than it receives inbound.
Similarly, I can have a reverse web proxy that's actually listed as my A
record.  It probably re-streams, may terminate TLS, probably inserts a
via header, may cache and never even forward a request.
I can have a SIP proxy that for example transforms from TCP to UDP or
SCTP.  Etc.
These devices may happen to have primary security function purposes.
The packet model doesn't fit them very well at all in my mind.  You can
shoehorn it, but it is not a natural fit.
If what you're saying is that these higher-layer devices are not NSFs
but are say application security functions, and they are out of scope,
then the packet model might well be a great fit.

If these higher-layer devices are in scope, then the packet model
doesn't seem like a good fit for them.

--Sam

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 23 Jul 2015 05:26:16 +0000

Many thanks for your detailed comments about the packet-based model, Sam.
Some of my responses are inline:

-----邮件原件-----
发件人: I2nsf [mailto:[email-masked]] 代表 Sam Hartman
发送时间: 2015年7月22日 21:41
收件人: [email-masked]
主题: [I2nsf] Packet-based model

Hi.  This does not affect the charter nor whether the group should be chartered.

However, I wanted to explore the packet-based model for NSFs.
At the mic, Ed explained that he wanted this model because it's more complex than flows.  Detecting scans, floods, DDOSes and other activity involves more than one flow.
However, all the NSFs process packets.

I think my confusion comes from the fact that the framework and information model document talk more about the parts of the space that we understand than the parts we don't understand.

[Frank]: currently they are. Because we are all the initial stage. But I believe we are pointing a good direction of packet-based paradigm to process any types of objects (i.e., flow, session, connection, contexts, etc) assembled from packets. The key point of the capability interface information model is to make it flexible and extensible enough to hold various advanced security functions. We'll keep on updating the draft to have more contents about this part.

Packet-based (and context-based) information is used to decide what per-packet processing to do.
That is, we might use packet information to decide that we want an IPS to look at something.

The IPs can categorize things however it wants, but its input is packets.  It can reassemble flows, track behavior of netblocks, track behavior of users across devices, whatever it likes.
But we're going to use characteristics of packets and there contexts to decide what functions to invoke.

This is more pronounced in the information model document.  Reading that document it would be easy to come away with the idea that a main point of the system is to actually act on those packets using the basic actions, rather than invoke one of the security functions.  I think better alignment between the framework and information model here would help a lot.  I also think scoping the packet model to selection would help.

[Frank]: good point. We'll do the alignment work. What do you mean of scoping the packet model to selection? Does it mean that the basic action or advanced security functions should be out of the scope of the packet-based model, which can be more sophisticated than the match part.

However, I'd also like to ask some hypothetical questions to make sure packets are the right model.

The packet model seems like it makes sense for any (semi)-transparent security function.  That is, the security function is not the destination address/port in the packet.  It may well modify the packets to indicate it has inspected them; it may in some cases re-stream a flow, but it's a network or transport-layer middlebox.

However there are a lot of other security functions.  I can set up a mail scanner that my external MXes point to.  It's the actual destination for my mail.  It may store-and-forward, will almost certainly produce its own output streams, probably uses a different identity for outbound connections than it receives inbound.
Similarly, I can have a reverse web proxy that's actually listed as my A record.  It probably re-streams, may terminate TLS, probably inserts a via header, may cache and never even forward a request.
I can have a SIP proxy that for example transforms from TCP to UDP or SCTP.  Etc.
These devices may happen to have primary security function purposes.
The packet model doesn't fit them very well at all in my mind.  You can shoehorn it, but it is not a natural fit.
If what you're saying is that these higher-layer devices are not NSFs but are say application security functions, and they are out of scope, then the packet model might well be a great fit.

If these higher-layer devices are in scope, then the packet model doesn't seem like a good fit for them.

[Frank]: I am not sure whether the high-layer security functions are in the scope or out now. Maybe they are in the scope in future. I'd like to listen to more comments.

--Sam

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 23 Jul 2015 01:58:48 -0400

>>>>> "Xialiang" == Xialiang (Frank) <[email-masked]> writes:

    Xialiang> [Frank]: good point. We'll do the alignment work. What do
    Xialiang> you mean of scoping the packet model to selection? Does it
    Xialiang> mean that the basic action or advanced security functions
    Xialiang> should be out of the scope of the packet-based model,
    Xialiang> which can be more sophisticated than the match part.

No, all I mean is that when describing the packet model explain that
we're talking about packets in terms of selection of what to process,
not saying that state is maintained only about packets.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 23 Jul 2015 09:17:27 +0200

Sam,

This is bit of a crash between what different communities call different 
things.

A few of us sat down wed afternoon (really about the time you were 
writing this) and came to the conclusion that we need to start with the 
term 'flows and services'.  This will do for a starter and the charter.  
I hope that the developers will each think about this and we may welll 
refine the english label for this policy concept as we progress on the 
documents.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 23 Jul 2015 03:51:02 -0400

>>>>> "Robert" == Robert Moskowitz <[email-masked]> writes:

    Robert> Sam, This is bit of a crash between what different
    Robert> communities call different things.

    Robert> A few of us sat down wed afternoon (really about the time
    Robert> you were writing this) and came to the conclusion that we
    Robert> need to start with the term 'flows and services'.  This will
    Robert> do for a starter and the charter.  I hope that the
    Robert> developers will each think about this and we may welll
    Robert> refine the english label for this policy concept as we
    Robert> progress on the documents.

I'll note that the charter text doesn't currently use the word packet
and seems fine.
If you want to change it to flow descriptor or whatever that's OK too.

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 23 Jul 2015 16:12:26 +0000

Based on the discussion from I2NSF mailing list and some offline discussions during breaks, I propose that I2NSF will use "Flow Based Model" from now on. All the I2NSF drafts need to be updated to reflect this terminology change. 

With this definition, I2NSF is to Create/Read/Update/Delete (CRUD) "Flow Descriptor" or "Flow Service Descriptor" dynamically to NSFs.

Let's all go back to confirm with our respective development teams if this terminology is acceptable. 

Sincerely thanks to everyone's participation, comments provided at the I2NSF BOF, the productive discussions after the BOF, the BOF Chairs, and the AD Kathleen's steering. 

Thank you. Have a safe trip back home!

Linda 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Thursday, July 23, 2015 9:51 AM
To: Robert Moskowitz
Cc: [email-masked]; Sam Hartman
Subject: Re: [I2nsf] Packet-based model

I'll note that the charter text doesn't currently use the word packet and seems fine.
If you want to change it to flow descriptor or whatever that's OK too.