Subject: [I2nsf] FW: How did Video Conference Calls go through FW before Video Conference Controller can inform network to by-pass FW dynamically?

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Feb 2015 18:41:04 +0000

FYI

-----Original Message-----
From: Pascal Menezes [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2015 12:24 PM
To: Linda Dunbar
Subject: RE: How did Video Conference Calls go through FW before Video Conference Controller can inform network to by-pass FW dynamically?

We have to manually configure a wide set of port ranges for our media to pass thru(ex: ports 50,000 to 50,999) if there is a firewall placed in the middle of any enterprise  deployment (very common for defense in depth postures) .  This causes a bigger attack surface area.  What our UC SDN NBI does is create dynamic pinhole firewalls rules that are only active for when the UC media session is alive. Once the session is over the pinhole policy is removed 

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Wednesday, February 4, 2015 8:32 AM
To: Pascal Menezes
Subject: How did Video Conference Calls go through FW before Video Conference Controller can inform network to by-pass FW dynamically?

Pascal, 

During the call yesterday, you stated that you had to manually provision FW to let some calls by-pass FW. Therefore you need an automatic interfaces to dynamically change the policy to by-pass FW. 

But with such high bandwidth (like you said 10G or higher rate), how can manual setting do the job? 

The IETF Security AD Kathleen had the same question. 

Linda

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 

Maybe the Skype example will be more fitting.  Although I'd be interested to know how the voice and multi-media problem has been solved already and what advantages are offered by doing this through
I2 NSF.

Thank you,
Kathleen

>
> Myo
>
> -----Original Message-----
> From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
> Sent: 3 February 2015 2:16 PM
> To: Kathleen Moriarty
> Cc: John Strassner; Pascal Menezes; Romascanu, Dan (Dan); 
> [email-masked]; Natale, Bob; Xialiang (Frank); Joseph Salowey
> Subject: Re: [I2nsf] I2NSF to address problems discussed by IAB SEMI 
> workshop (was RE: Intent As The Common Interface to Network Resources 
> (Dave
> Lenrow)
>
> Kathleen,
>
> The example is Microsoft Skype Link Gateway needs to dynamically 
> inform the network security controller to have some specific encrypted 
> flows by-passing some FW/IPS/IDS for a specific time span.
> Otherwise, some flows can't go through the FW/IPS/IDS because the 
> payload is encrypted.
>
> Pascal Menezes from Microsoft (CC'ed) can explain better.
>
> Thanks, Linda
>
>
> -----Original Message-----
> From: Kathleen Moriarty [mailto:[email-masked]]
>
>>
>
> Linda,
>
> Do you have more information on this particular example?  Where I 
> work, the explicitly do not intercept encrypted traffic destined for 
> financial services organizations and this has been a long standing 
> feature of the firewall product in place.  It's not clear to me why an 
> additional application gateway would be needed to avoid the firewall.
> Why can't the existing methods to filter web traffic at proxies be 
> couples with the existing interception services (I'm not advocating 
> for interception services of TLS traffic and did have the methods used 
> in firewalls today added to the attacks on TLS drafts so they were understood)?
>
> What this would mean is that URLs and domain names would be used to 
> validate that the site falls into an approved category and should not be intercepted.
> This is used in enterprise gateways, what additional information do 
> you have on the above text to explain the problem if it is different 
> than what I am describing?
>
> Thank you,
> Kathleen
>
>
>>
>>
>> Linda
>>
>>
>>
>> From: Natale, Bob [mailto:[email-masked]]
>> Sent: Friday, January 30, 2015 9:29 AM
>> To: Linda Dunbar; John Strassner; Xialiang (Frank); Romascanu, Dan 
>> (Dan); Joseph Salowey
>> Cc: [email-masked]
>> Subject: Intent As The Common Interface to Network Resources (Dave
>> Lenrow)
>>
>>
>>
>> Hi folks,
>>
>>
>>
>> Apologies if you have already seen the attached, but Linda’s 
>> reference to “the HP hosted ‘Intent driven summit’” in an earlier 
>> message caused me to search it and that led me to contact Dave Lenrow 
>> of HP, who hosted it. The event happened earlier this month and they 
>> do intend to post content on the web, but that has not happened yet.
>> Dave promised to send me the URL when it’s available and I will 
>> forward it then (unless not needed by the group).
>> In the meantime, he did send the attached slides, which he used for 
>> the introductory session.
>>
>>
>>
>> Avanti,
>>
>> BobN
>>
>>
>>
>>
>> _______________________________________________
>> I2nsf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>
>
>
> --
>
> Best regards,
> Kathleen
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

-- 

Best regards,
Kathleen

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 4 Feb 2015 21:11:34 +0000

Linda,

What Pascal described is a well known unified communication problem from very early days. All the dynamic media information is written in SDP (Session Description Protocol), but FW never implemented B2BUA, so couldn't read this info from session, as it is usually encrypted.

I can definitely see other applications instructing security perimeter devices to dynamically open close ports per policies set by network administrator and intent communicated by the application. Based on this, I would argue that I2NSF should be an I2RS client that communicates to I2RS agent on the device. There is no need to have I2NSF on the device.

Dean

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 5 Feb 2015 01:08:20 +0000

Hi Dean,
I do not think I2RS covers the security service in L7. And that's why we need I2NSF to develop the security-specific interface and IM/DMs. These works are new and different from I2RS works.

B.R.
Frank

> From: I2nsf [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
> Sent: Thursday, February 05, 2015 5:12 AM
> To: Linda Dunbar
> Cc: [email-masked]; Kathleen Moriarty
> Subject: Re: [I2nsf] How did Video Conference Calls go through FW before
> Video Conference Controller can inform network to by-pass FW dynamically?
> 
> Linda,
> 
> What Pascal described is a well known unified communication problem from
> very early days. All the dynamic media information is written in SDP (Session
> Description Protocol), but FW never implemented B2BUA, so couldn't read
> this info from session, as it is usually encrypted.
> 
> I can definitely see other applications instructing security perimeter devices
> to dynamically open close ports per policies set by network administrator
> and intent communicated by the application. Based on this, I would argue
> that I2NSF should be an I2RS client that communicates to I2RS agent on the
> device. There is no need to have I2NSF on the device.
> 
> Dean
> 
> > Subject: RE: How did Video Conference Calls go through FW before Video
> Conference Controller can inform network to by-pass FW dynamically?
> >
> > We have to manually configure a wide set of port ranges for our media
> > to pass thru(ex: ports 50,000 to 50,999) if there is a firewall placed
> > in the middle of any enterprise  deployment (very common for defense
> > in depth postures) .  This causes a bigger attack surface area.  What
> > our UC SDN NBI does is create dynamic pinhole firewalls rules that are
> > only active for when the UC media session is alive. Once the session
> > is over the pinhole policy is removed
> >
> > Subject: How did Video Conference Calls go through FW before Video
> Conference Controller can inform network to by-pass FW dynamically?
> >
> > Pascal,
> >
> > During the call yesterday, you stated that you had to manually provision FW
> to let some calls by-pass FW. Therefore you need an automatic interfaces to
> dynamically change the policy to by-pass FW.
> >
> > Maybe the Skype example will be more fitting.  Although I'd be
> > interested to know how the voice and multi-media problem has been
> > solved already and what advantages are offered by doing this through
> > I2 NSF.
> >
> > Thank you,
> > Kathleen
> >
> >
> >>
> >> Myo
> >>
> >> inform the network security controller to have some specific
> >> encrypted flows by-passing some FW/IPS/IDS for a specific time span.
> >> feature of the firewall product in place.  It's not clear to me why
> >> an additional application gateway would be needed to avoid the firewall.
> >> for interception services of TLS traffic and did have the methods
> >> used in firewalls today added to the attacks on TLS drafts so they were
> understood)?
> >>
> >>> Apologies if you have already seen the attached, but Linda's
> >>> reference to "the HP hosted 'Intent driven summit'" in an earlier
> >>> message caused me to search it and that led me to contact Dave
> >>> Lenrow of HP, who hosted it. The event happened earlier this month
> >>> and they do intend to post content on the web, but that has not
> happened yet.
> >>> Dave promised to send me the URL when it's available and I will

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 5 Feb 2015 14:59:44 +0000

Frank,

You didn't understand what I was stating

example

A network device has default behavior of blocking any incoming/outgoing high UDP ports

A RTC application has to start/receive RTP stream and for that it is using high UDP ports. It has to signal to the network device to open a specific or range of UDP port(s).

On network device this is done via firewall filters or access control lists. I2RS exposes control of both constructs from the device. How the RTP application will communicate the request for network device behavior change is a question, but to the device it is either firewall filter or ACL.

This is the reason, why I2NSF is a client to I2RS agent. The intent communicated from application can/should be translated by I2NSF, as it can have much more flexible policy/intent language, and then communicate that via I2RS to the device.

Dean

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Fri, 6 Feb 2015 00:59:46 +0000

Dean,
So, what you mean is network device realizes the security control. In this scenario, I agree with your statement.
In more common scenario, I2NSF agent should be in the NSFs. Do you agree?

B.R.
Frank

> From: Dean Bogdanovic [mailto:[email-masked]]
> Sent: Thursday, February 05, 2015 11:00 PM
> To: Xialiang (Frank)
> Cc: Linda Dunbar; [email-masked]; Kathleen Moriarty
> A RTC application has to start/receive RTP stream and for that it is using high
> UDP ports. It has to signal to the network device to open a specific or range of
> UDP port(s).
> 
> On network device this is done via firewall filters or access control lists. I2RS
> exposes control of both constructs from the device. How the RTP application
> will communicate the request for network device behavior change is a
> question, but to the device it is either firewall filter or ACL.
> 
> This is the reason, why I2NSF is a client to I2RS agent. The intent
> communicated from application can/should be translated by I2NSF, as it can
> have much more flexible policy/intent language, and then communicate that
> via I2RS to the device.
> 
> Dean
> 
> > I do not think I2RS covers the security service in L7. And that's why we need
> I2NSF to develop the security-specific interface and IM/DMs. These works are
> new and different from I2RS works.
> >
> > B.R.
> > Frank
> >
> >> Subject: Re: [I2nsf] How did Video Conference Calls go through FW
> >> before Video Conference Controller can inform network to by-pass FW
> dynamically?
> >>
> >> Linda,
> >>
> >> What Pascal described is a well known unified communication problem
> >> from very early days. All the dynamic media information is written in
> >> SDP (Session Description Protocol), but FW never implemented B2BUA,
> >> so couldn't read this info from session, as it is usually encrypted.
> >>
> >> I can definitely see other applications instructing security
> >> perimeter devices to dynamically open close ports per policies set by
> >> network administrator and intent communicated by the application.
> >> Based on this, I would argue that I2NSF should be an I2RS client that
> >> communicates to I2RS agent on the device. There is no need to have I2NSF
> on the device.
> >>
> >> Dean
> >>
> >>> We have to manually configure a wide set of port ranges for our
> >>> media to pass thru(ex: ports 50,000 to 50,999) if there is a
> >>> firewall placed in the middle of any enterprise  deployment (very
> >>> common for defense in depth postures) .  This causes a bigger attack
> >>> surface area.  What our UC SDN NBI does is create dynamic pinhole
> >>> firewalls rules that are only active for when the UC media session
> >>> is alive. Once the session is over the pinhole policy is removed
> >>>
> >> to let some calls by-pass FW. Therefore you need an automatic
> >> interfaces to dynamically change the policy to by-pass FW.
> >>>
> >>> But with such high bandwidth (like you said 10G or higher rate), how
> >>> can
> >> manual setting do the job?
> >>>
> >>>> Subject: Re: [I2nsf] I2NSF to address problems discussed by IAB
> >>>> SEMI workshop (was RE: Intent As The Common Interface to Network
> >>>> Resources (Dave
> >>>> Lenrow)
> >>>>
> >>>> Kathleen,
> >>>>
> >>>> work, the explicitly do not intercept encrypted traffic destined
> >>>> for financial services organizations and this has been a long
> >>>> standing feature of the firewall product in place.  It's not clear
> >>>> to me why an additional application gateway would be needed to avoid
> the firewall.
> >>>> validate that the site falls into an approved category and should
> >>>> not be
> >> intercepted.
> >>>> you have on the above text to explain the problem if it is
> >>>> different than what I am describing?
> >>>>
> >>>> Thank you,
> >>>> Kathleen
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> Linda
> >>>>>
> >>>>>
> >>>>>
> >>>>> In the meantime, he did send the attached slides, which he used
> >>>>> for the introductory session.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Avanti,
> >>>>>
> >>>>> BobN
> >>>>>
> >>>>>
> >>>>>
> >>>>>

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 6 Feb 2015 21:37:15 +0000

Frank,

This is how I see the architecture. I2RS agent is the interface to the data plane. Both control plane and L7 apps (I consider all security applications L7 apps) communicate to the data plane via I2RS. Management app has to communicate intent to the security application and or that I2NSF is the right interface. 
It really doesn't matter if the data/control and L7 apps are physical or virtualized. The same architecture can be always applied.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Feb 2015 20:34:04 -0500

Dean: 

I agree with your point that applications instructing the security devices
should use a I2RS client that communicates with an I2RS Agent. However, I2RS
needs security expertise to determine the trust environment needed between
the user environment and the security hosts on a virtual infrastructure.
My understanding is that the vNSF would define if the trust environment
provided by a confidential session (encrypted) is sufficient, or the I2RS
client-I2RS agent must be part of a SACM endpoint model.   The sacm model
has the following

   Posture-assessment consumer --- broker repository --- posture assessment
provider 

This could be implemented as   
     
     Credential server ----------------+-------------security infrastructure
(push/pull) 
       |                                                  |
|authorization information 
       |
+----------------|-----------------------------------+           |
       |                         |  broker  box for SACM
|            |
    I2RS-client ------ |   I2rs agent   repository app  I2rs client  | ----
I2RS agent 
 
+----------------------------------------------------+

This certificates established for end credentials are established from a
credential server, and the authorization is distributed from authorization
server (AAA).   

The MIDCOM does a similar form: 
 
       I2RS Client 
       Midcom PDP
---------------------------------------------------------------+ 
                                                         |
|
 
+----------------|----------------------------------+           |
       Sip------------- |  sip proxy  box MIDCOM      |                    |
V
                                --------------------------------------  I2RS
Client |---I2RS Client 
     RTSP  ---------- | rtsp proxy   repository app|                     |
Firewall 
 
+----------------------------------------------------+       
 
The co-authors on the draft-i2rs-hares-security-arch were looking at trying
to define this for I2RS use cases, but the vNSF was still being developed by
ETSI.  Now that vNSF is developed, these concerns for the I2RS control can
be developed.  I2RS architecture implies the interaction with the AAA
servers and the certificates (the security directorate pointed out it needed
clarification in the I2RS architecture document).  

 I suspect vNSF = I2RS + Security backend (sacm or midcom or both).  The
I2RS requirements for protocols (netconf/restconf or smaller proposal you
made in I2RS) are likely to be the same. 

Should I2RS can pick up these issues or create a new WG (I2NSF)?  I2RS must
stay on track for defining the protocol requirements and the protocol
independent components (RIB/FIB), and this must be the primary focus until
May.  One option is to pick up a 3rd chair and WG secretary and run virtual
interims on this topic to process requirements for vNSF.   The IETF meetings
for I2RS would need split sessions between I2RS main and the vNSF topic to
all joint security/i2RS work.  This approach has the benefit of insuring
collaboration.    

Another option is to create a new WG and focus on a short term development
of requirements. 

 Sue Hares 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Wednesday, February 04, 2015 4:12 PM
To: Linda Dunbar
Cc: [email-masked]; Kathleen Moriarty
Subject: Re: [I2nsf] How did Video Conference Calls go through FW before

Linda,

What Pascal described is a well known unified communication problem from
very early days. All the dynamic media information is written in SDP
(Session Description Protocol), but FW never implemented B2BUA, so couldn't
read this info from session, as it is usually encrypted.

I can definitely see other applications instructing security perimeter
devices to dynamically open close ports per policies set by network
administrator and intent communicated by the application. Based on this, I
would argue that I2NSF should be an I2RS client that communicates to I2RS
agent on the device. There is no need to have I2NSF on the device.

Dean

> 
> Pascal,
> 
> During the call yesterday, you stated that you had to manually provision
FW to let some calls by-pass FW. Therefore you need an automatic interfaces
to dynamically change the policy to by-pass FW. 
understood)?
>>> and they do intend to post content on the web, but that has not happened
yet.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 10 Feb 2015 16:01:38 -0500

Frank and Dean:

Let me understand what you are stating.  The Network devices enforces or
acts upon the security control policy.  The COPS model had a PDP (policy
decision point) and a PEP (policy enforcement point).   In terms of that
model, the network device always has a PEP.  The I2NSF talks about how the
policy requests from customers turn into policy that are stored in a virtual
policy decision point.  

Did I understand what you are stating?

Sue 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
Sent: Thursday, February 05, 2015 8:00 PM
To: Dean Bogdanovic
Cc: [email-masked]; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2nsf] How did Video Conference Calls go through FW before

Dean,
So, what you mean is network device realizes the security control. In this
scenario, I agree with your statement.
In more common scenario, I2NSF agent should be in the NSFs. Do you agree?

B.R.
Frank

dynamically?
> A RTC application has to start/receive RTP stream and for that it is 
> using high UDP ports. It has to signal to the network device to open a 
> specific or range of UDP port(s).
> 
> On network device this is done via firewall filters or access control 
> lists. I2RS exposes control of both constructs from the device. How 
> the RTP application will communicate the request for network device 
> behavior change is a question, but to the device it is either firewall
filter or ACL.
> communicated from application can/should be translated by I2NSF, as it 
> can have much more flexible policy/intent language, and then 
> communicate that via I2RS to the device.
> 
> Dean
> 
> On Feb 4, 2015, at 8:08 PM, Xialiang (Frank) 
> <[email-masked]>
> wrote:
> 
> > Hi Dean,
> I2NSF to develop the security-specific interface and IM/DMs. These 
> works are new and different from I2RS works.
> >
> > B.R.
> > Frank
> >
> >> from very early days. All the dynamic media information is written 
> >> in SDP (Session Description Protocol), but FW never implemented 
> >> B2BUA, so couldn't read this info from session, as it is usually
encrypted.
> >> perimeter devices to dynamically open close ports per policies set 
> >> by network administrator and intent communicated by the application.
> >> Based on this, I would argue that I2NSF should be an I2RS client 
> >> that communicates to I2RS agent on the device. There is no need to 
> >> have I2NSF
> on the device.
> >>
> >> Dean
> >>
> >>> common for defense in depth postures) .  This causes a bigger 
> >>> attack surface area.  What our UC SDN NBI does is create dynamic 
> >>> pinhole firewalls rules that are only active for when the UC media 
> >>> session is alive. Once the session is over the pinhole policy is 
> >>> removed
> >>>
> >>> But with such high bandwidth (like you said 10G or higher rate), 
> >>> how can
> >>>> standing feature of the firewall product in place.  It's not 
> >>>> clear to me why an additional application gateway would be needed 
> >>>> to avoid
> the firewall.
> >>>> Why can't the existing methods to filter web traffic at proxies 
> >>>> be couples with the existing interception services (I'm not 
> >>>> advocating for interception services of TLS traffic and did have 
> >>>> the methods used in firewalls today added to the attacks on TLS 
> >>>> drafts so they were
> >> understood)?
> >>>>
> >>>> This is used in enterprise gateways, what additional information 
> >>>> do you have on the above text to explain the problem if it is 
> >>>>> To: Linda Dunbar; John Strassner; Xialiang (Frank); Romascanu, 
> >>>>> Dan (Dan); Joseph Salowey
> >>>>> Cc: [email-masked]
> >>>>> reference to "the HP hosted 'Intent driven summit'" in an 
> >>>>> earlier message caused me to search it and that led me to 
> >>>>> contact Dave Lenrow of HP, who hosted it. The event happened 
> >>>>> earlier this month and they do intend to post content on the 
> >>>>> web, but that has not
> >> happened yet.

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 11 Feb 2015 06:12:01 +0000

Hi Sue,
I agree with your statement and think it is about the service interface of I2NSF. 
And what I discussed with Dean is about the capability interface of I2NSF.

B.R.
Frank

> From: Susan Hares [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2015 5:02 AM
> To: Xialiang (Frank); 'Dean Bogdanovic'
> Cc: [email-masked]; 'Kathleen Moriarty'; Linda Dunbar
> Subject: RE: [I2nsf] How did Video Conference Calls go through FW before

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 11 Feb 2015 14:59:27 +0000

> |authorization information 
Your graphics didn't make it through the email. Got nicely chopped up.

> The MIDCOM does a similar form: 

I agree with you about the trust environment need for I2RS and if that is the goal, then I support it fully.
> Another option is to create a new WG and focus on a short term development

Should it be a separate WG or part of I2RS, I would vote to be part of I2RS.

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 11 Feb 2015 15:03:47 +0000

> And what I discussed with Dean is about the capability interface of I2NSF.

There are two interfaces that security application needs

north bound
to other applications that want to change security policies on the device

south bound
to the data plane, where it changes the traffic forwarding behavior

If I2NSF plans to discuss the NBI and work on that specification, I'm all for it, but SBI interface should be left to I2RS IMO and it should be defined as such

Dean

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 12 Feb 2015 09:35:14 -0500

Frank:

Frank:

Thank you for the feedback.  John's Strassner's
draft-strassner-i2nfs-info-model-00.txt has careful discussion of the layers
of the service model.   I think you have been calling the service layer the
layers above this work (as in the diagram). 

I carefully call the intent based network work the layer above. 

Sue Hares 
----------

 I2NSF clients                       Info models 
      | | intent interface  
      | |
Security policy layer ------ data models
     |  | policy to device transition                            service
layer 
     |  | ===================================================
Context-aware policy engine  --- data models    context 
    |  |
    |  |device capabilities 
Security capability layer  --- data models (yang )  

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
Sent: Wednesday, February 11, 2015 1:12 AM
To: Susan Hares; 'Dean Bogdanovic'
Cc: [email-masked]; 'Kathleen Moriarty'; Linda Dunbar
Subject: Re: [I2nsf] How did Video Conference Calls go through FW before

Hi Sue,
I agree with your statement and think it is about the service interface of
I2NSF. 
And what I discussed with Dean is about the capability interface of I2NSF.

B.R.
Frank

> Subject: RE: [I2nsf] How did Video Conference Calls go through FW 
dynamically?
> 
> Frank and Dean:
> 
> Let me understand what you are stating.  The Network devices enforces 
> or acts upon the security control policy.  The COPS model had a PDP
(policy
> model, the network device always has a PEP.  The I2NSF talks about how 
> the policy requests from customers turn into policy that are stored in 
> a virtual policy decision point.
> 
dynamically?
> 
> Dean,
> So, what you mean is network device realizes the security control. In 
> this scenario, I agree with your statement.
> > using high UDP ports. It has to signal to the network device to open 
> > a specific or range of UDP port(s).
> >
> > On network device this is done via firewall filters or access 
> > control lists. I2RS exposes control of both constructs from the 
> > device. How the RTP application will communicate the request for 
> > network device behavior change is a question, but to the device it 
> > is either firewall
> filter or ACL.
> >
> > communicated from application can/should be translated by I2NSF, as 
> > it can have much more flexible policy/intent language, and then 
> > >> What Pascal described is a well known unified communication 
> > >> problem from very early days. All the dynamic media information 
> > >> is written in SDP (Session Description Protocol), but FW never 
> > >> implemented B2BUA, so couldn't read this info from session, as it 
> > >> is usually
> encrypted.
> > >>
> > >> perimeter devices to dynamically open close ports per policies 
> > >> set by network administrator and intent communicated by the
application.
> > >> that communicates to I2RS agent on the device. There is no need 
> > >> to have I2NSF
> > on the device.
> > >>
> > >> Dean
> > >>
> > >> On Feb 4, 2015, at 1:41 PM, Linda Dunbar 
> > >> <[email-masked]>
> > >> wrote:
> > >>
> > >>> FYI
> > >>>
> > >>> firewall placed in the middle of any enterprise  deployment 
> > >>> (very common for defense in depth postures) .  This causes a 
> > >>> bigger attack surface area.  What our UC SDN NBI does is create 
> > >>> dynamic pinhole firewalls rules that are only active for when 
> > >>> the UC media session is alive. Once the session is over the 
> > >>> pinhole policy is removed
> > >>>
> > >>> From: Kathleen Moriarty 
> > >>> [mailto:[email-masked]]
> > >>>
> > >>>
> > >>> interested to know how the voice and multi-media problem has 
> > >>> been solved already and what advantages are offered by doing 
> > >>> this through
> > >>> I2 NSF.
> > >>>
> > >>> Thank you,
> > >>> Kathleen
> > >>>
> > >>>
> > >>>>
> > >>>> Myo
> > >>>>
> > >>>> SEMI workshop (was RE: Intent As The Common Interface to 
> > >>>> Network Resources (Dave
> > >>>> Lenrow)
> > >>>>
> > >>>> Kathleen,
> > >>>>
> > >>>> The example is Microsoft Skype Link Gateway needs to 
> > >>>> dynamically inform the network security controller to have some 
> > >>>> specific encrypted flows by-passing some FW/IPS/IDS for a specific
time span.
> > >>>> Otherwise, some flows can't go through the FW/IPS/IDS because 
> > >>>> the payload is encrypted.
> > >>>>
> > >>>> From: Kathleen Moriarty 
> > >>>> [mailto:[email-masked]]
> > >>>>
> > >>>>>
> > >>>>
> > >>>> Linda,
> > >>>>
> > >>>> Do you have more information on this particular example?  Where 
> > >>>> I work, the explicitly do not intercept encrypted traffic 
> > >>>> destined for financial services organizations and this has been 
> > >>>> a long standing feature of the firewall product in place.  It's 
> > >>>> not clear to me why an additional application gateway would be 
> > >>>> needed to avoid
> > the firewall.
> > >>>> advocating for interception services of TLS traffic and did 
> > >>>> have the methods used in firewalls today added to the attacks 
> > >>>> on TLS drafts so they were
> > >> understood)?
> > >>>>
> > >>>> What this would mean is that URLs and domain names would be 
> > >>>> used
> > to
> > >>>> validate that the site falls into an approved category and 
> > >>>> should not be
> > >> intercepted.
> > >>>> This is used in enterprise gateways, what additional 
> > >>>> information do you have on the above text to explain the 
> > >>>> problem if it is different than what I am describing?
> > >>>>
> > >>>> Thank you,
> > >>>> Kathleen
> > >>>>
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>> Linda
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Dave promised to send me the URL when it's available and I 
> > >>>>> will forward it then (unless not needed by the group).
> > >>>>> In the meantime, he did send the attached slides, which he 
> > >>>>> used for the introductory session.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Avanti,
> > >>>>>
> > >>>>> BobN
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 12 Feb 2015 09:43:02 -0500

Dean:

I just posted the definition from John Strassner
(draft-strassner-i2nfs-info-model) described on service layer.  I think the
context-aware policy engine to the device capabilities is definitely I2RS
with defined yang modules .  

I have placed protocol definitions into each location.  I think like you
suggested we can do both heavy weight (I2rs = netconf,  I2RS = your
proposal) at the SBI. 

Sue
----------------------------
 I2NSF clients                       Info models 
      | | intent interface  (Intent NBI) 
      | |  
Security policy layer ------ data models
     |  | policy to device transition      service layer  NBI (I2NSF)   
     |  | ===================================================  
Context-aware policy engine  --- data models    context  layer (SBI) 
    |  |
    |  |device capabilities  (I2RS + Data models)  
Security capability layer  --- data models (yang )  

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2015 10:04 AM
To: Xialiang (Frank)
Cc: Susan Hares; [email-masked]; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2nsf] How did Video Conference Calls go through FW before

I2NSF. 

north bound

south bound

If I2NSF plans to discuss the NBI and work on that specification, I'm all
for it, but SBI interface should be left to I2RS IMO and it should be
defined as such

Dean
dynamically?
(policy
>> model, the network device always has a PEP.  The I2NSF talks about 
>> how the policy requests from customers turn into policy that are 
>> stored in a virtual policy decision point.
>> 
dynamically?
>>>>> problem from very early days. All the dynamic media information is 
>>>>> written in SDP (Session Description Protocol), but FW never 
>>>>>> pinhole firewalls rules that are only active for when the UC 
>>>>>> media session is alive. Once the session is over the pinhole 
>>>>>> policy is removed
>>>>>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 12 Feb 2015 13:36:09 -0500

> suggested we can do both heavy weight (I2rs = netconf,  I2RS = your

This is good to know and helps narrow scope and gap analysis work.

Thanks.

-- 

Best regards,
Kathleen