Re: [Spud] Interactions between SPUD and I2NSF

["Black, David" <[e-mail]>]

Hi Philipp,

> > 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.
> 
> 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.

> > 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.
> 
> 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 admittedly
> get a feeling how where to put I2NSF in my personal mental model).

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

> -----Original Message-----
> From: Philipp S. Schmidt [mailto:[e-mail]]
> Sent: Wednesday, February 11, 2015 3:53 AM
> To: Black, David
> Cc: [e-mail]
> Subject: Re: [Spud] Interactions between SPUD and I2NSF
> 
> Hi David,
> 
> > On 11.02.2015, at 01:13, Black, David <[e-mail]> wrote:
> >
> > 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?
> 
> 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.
> 
> > 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.
> 
> Which is - in my opinion - a clear distinction where the interfaces _could_ be.
> 
> > 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.
> 
> 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!
>   Philipp S. Schmidt / phils…
> --
>    {phils}--->---([e-mail])--->---(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: [phone])---<---(jabber: [e-mail])---'