Subject: [Spud] Interactions between SPUD and I2NSF

From: "Philipp S. Schmidt" <[email-masked]>
Date: Tue, 10 Feb 2015 17:23:01 +0100

Hi,

as a response to our position paper at IAB SEMI workshop, I was aksed to
comment on the not-yet-cartered I2NSF WG (Interface to Network Security Functions).

I see a lot of overlap between the "service layer" defined in [draft-dunbar-i2nsf-problem-statement], but I am a little shaken between have an “joint approach” the complexity the whole frameing of I2NSF implies.

AVE!
  Philipp S. Schmidt / phils…
-- 
   {phils}--->---([email-masked])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <---(phone: +49-179-6737439)---<---(jabber: [email-masked])---'

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Feb 2015 00:13:13 +0000

Philipp,

> as a response to our position paper at IAB SEMI workshop, I was asked to
> comment on the not-yet-chartered I2NSF WG (Interface to Network Security
> Functions).
>
> I see a lot of overlap between the "service layer" defined in [draft-dunbar-
> i2nsf-problem-statement], but I am a little shaken between have an “joint
> approach” the complexity the whole framing of I2NSF implies.

What sort of "joint approach" is involved?

My reason for asking is that the proposed I2NSF charter: 
	http://www.ietf.org/mail-archive/web/i2nsf/current/msg00245.html

contains this clear sentence:

	It is a non-goal to create new protocols or data modeling languages for I2NSF interfaces.

Obviously, I2NSF is concerned with firewalls, and punching pinholes in at least
firewalls and NATs are things that SPUD needs to be concerned about, but is
there more?

At the other extreme, the design of SPUD should not touch the I2NSF service layer,
again quoting from the I2NSF draft charter:

	The Security Service and Policy Layer is for clients to express and monitor
		security policies for their specific flows.

We should leave that sort of security to the security experts, and hope that they
leave transport to the transport experts ;-).

And if anyone from the IESG is lurking on this list, here's one more example of
why Areas matter to the structure of the IETF.

Thanks,
--David

> -----Original Message-----
> From: Spud [mailto:[email-masked]] On Behalf Of Philipp S. Schmidt
> Sent: Tuesday, February 10, 2015 11:23 AM
> To: [email-masked]
> Subject: [Spud] Interactions between SPUD and I2NSF
> 
> Hi,
> 
> I see a lot of overlap between the "service layer" defined in [draft-dunbar-
> i2nsf-problem-statement], but I am a little shaken between have an “joint
> approach” the complexity the whole frameing of I2NSF implies.
> 
> AVE!
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: "Philipp S. Schmidt" <[email-masked]>
Date: Wed, 11 Feb 2015 09:53:03 +0100

Hi David,

> On 11.02.2015, at 01:13, Black, David <[email-masked]> wrote:
> 
> Philipp,
> 

A "joint approach” would in my opinion mean making sure terminology and
mental model of the network fit, and allow I2NSF to use SUPD as an
example for a protocol implementing their Security Service and Policy Layer.

> 		security policies for their specific flows.

Which is - in my opinion - a clear distinction where the interfaces _could_ be.

> why Areas matter to the structure of the IETF.

Sorry - I am quite new to the IETF - I just did not want to miss an opportunity
to bring people together that work on closely related topics (and admittingly 
get a feeling how where to put I2NSF in my personal mental model). 

AVE!

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Feb 2015 14:44:05 +0000

Hi Philipp,

> Which is - in my opinion - a clear distinction where the interfaces _could_ be.

+1!  SPUD may provide an opportunity to improve on what's currently done to punch
and maintain UDP pinholes.

> to bring people together that work on closely related topics (and admittedly

No apology needed - getting to this sort of clear distinction is helpful in
enabling work to get done in parallel.  For those not following I2NSF, it's
likely to be a WG-forming BOF in Dallas next month.

Thanks,
--David

> From: Philipp S. Schmidt [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2015 3:53 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [Spud] Interactions between SPUD and I2NSF
> 
> Hi David,
>