Subject: Re: [I2nsf] Intent As The Common Interface to Network Resources (Dave Lenrow)

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 2 Feb 2015 15:06:13 +0000

Hi,

Just to express my support to the direction this discussion is taking, and to support John's comments on substituting "concrete" by "formal". I see intent-based network programming very close to general declarative programming with the specific caveat that intent-driven is so far very much focused on the network, what on the one hand narrows the application domain so the declarations are much more focused, while on the other these intents have to be mapped onto a constraining topology and, if you allow me, against a particular way of doing things.

And let me say that Bob's offer about taking care of refining our terminology is not only extremely interesting, but completely necessary: to have a clear scope we need a clear common understanding of what we have at hand. And, as Yoav noted, in security services space we have a language gap to bridge.

Be goode,

On 31 Jan 2015, at 23:03 , John Strassner <[email-masked]<mailto:[email-masked]>> wrote:

Just to clarify what Linda said:

•         For me, replace “A concrete security policy language” with “A formal security policy language” (reason: I don’t know what “concrete” means, and “formal” implies specifying the language formally using either EBNF or ABNF)
•         IFF we assume that intent-based programming is similar to declarative programming (re: my earlier post), then our scope should be to build our formal language to support this style of programming (as opposed to, for example, an imperative style of programming)
•         I don’t agree with “being a branch to this whole industry ‘Intent Driven’ initiative”. One thing that was apparent at the Intent-based Networking Summit is that there are already multiple projects with multiple different interpretations of “intent”. This is, imho, a non-starter.

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

From: Linda Dunbar
Sent: Friday, January 30, 2015 8:21 AM
To: Natale, Bob; John Strassner; Xialiang (Frank); Romascanu, Dan (Dan); Joseph Salowey
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Intent As The Common Interface to Network Resources (Dave Lenrow)

Bob,

Thank you very much for sharing the Intent Networking Summit  slides. The Intent for Network Resources has also been discussed at the  ONF NBI group.

As said in the slide, the “intent is completely abstract”. I2NSF is intended to specify a concrete Security Policy Language both at the Service Layer and Functional Layer, hopefully be a branch to this whole industry “Intent Driven” initiative.

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]<mailto:[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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 2 Feb 2015 18:01:50 +0000

What John said in other email  accurately describes the I2NSF  : to carve out a distinct space, focused on security (which the other groups are not looking at) where we can make important improvements.

One of the problem domains of I2NSF is to provide the needed “communication between the App Gateway and Security Functions” which is essential to solve the some of the problems described by the Jan 26-27 2015 IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)<https://www.iab.org/activities/workshops/semi/>.

For example:
The next problem came when users wanted to use secure protocols - most significantly, HTTPS for financial transactions on the Internet. Enterprise network ALGs couldn't analyze encrypted payloads protected by SSL/TLS, so they couldn't tell what was entering and leaving their network domains, and that was a bigger problem because the relationship between applications and transport-layer port numbers was breaking down - for instance, a server could provide any SSL/TLS-protected application on port 443, and that would be indistinguishable from online banking.

This simple model started breaking down when users needed to access servers in other enterprise networks (so, their TCP connections were initiated outside those enterprise networks, and enterprise network administrators had no reason to believe there wouldn't be a problem). The response was to deploy application-level gateways (ALGs) that could look at an incoming connection request and decide it was relatively safe to allow access to a known set of internal servers using a known set of applications.

Linda

Cc: [email-masked]

Hi folks,

Avanti,
BobN

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Feb 2015 11:08:14 -0500

On Mon, Feb 2, 2015 at 1:01 PM, Linda Dunbar <[email-masked]> wrote:
> What John said in other email  accurately describes the I2NSF  : to carve
> out a distinct space, focused on security (which the other groups are not
> looking at) where we can make important improvements.
>
>
>
> One of the problem domains of I2NSF is to provide the needed “communication
> between the App Gateway and Security Functions” which is essential to solve
> the some of the problems described by the Jan 26-27 2015 IAB Workshop on
> Stack Evolution in a Middlebox Internet (SEMI).
>
>
>
> For example:
>
> The next problem came when users wanted to use secure protocols - most
> significantly, HTTPS for financial transactions on the Internet. Enterprise
> network ALGs couldn't analyze encrypted payloads protected by SSL/TLS, so
> they couldn't tell what was entering and leaving their network domains, and
> that was a bigger problem because the relationship between applications and
> transport-layer port numbers was breaking down - for instance, a server
> could provide any SSL/TLS-protected application on port 443, and that would
> be indistinguishable from online banking.
>
>
>
> This simple model started breaking down when users needed to access servers
> in other enterprise networks (so, their TCP connections were initiated
> outside those enterprise networks, and enterprise network administrators had
> no reason to believe there wouldn't be a problem). The response was to
> deploy application-level gateways (ALGs) that could look at an incoming
> connection request and decide it was relatively safe to allow access to a
> known set of internal servers using a known set of applications.
>

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

> 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
>
>
>
>
> [email-masked]

-- 

Best regards,
Kathleen

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Feb 2015 09:55:45 -0900

On 2/3/15 7:08 AM, Kathleen Moriarty wrote:
> feature of the firewall product in place. 

That's the case in every deployment I know of, but there may be
regional variations - I have no idea what's going on in China, for
example.

That said, there really is one case where this kind of thing
happens, and that's voice and real-time multimedia, but I
believe they consider this problem solved.  Also, when I worked
for Nokia they had recently had had a major compromise, and so
they were putting ssh and tls gateways on the corporate network
edge - we couldn't even ssh *out* without going through an
ALG.  But it was all pretty straightforward - whatever's being
discussed here is still far too squishy to be able to characterize
well, but it does seem to hazard increasing network complexity
more than necessary, which carries its own security risks.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Feb 2015 19:15:38 +0000

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

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

-- 

Best regards,
Kathleen

---

From: "Zarny, Myo" <[email-masked]>
Date: Tue, 3 Feb 2015 16:18:09 -0500

Hi Kathleen, Linda,

Seems to me, what I2NSF is trying to do is to come up with a standard way to express and accept policy—in this case, that certain flows follow a different path. It's not trying to alter policy/intent. So, using your example, if your current policy is to use URLs and domain names to determine your firewall insertion policy, what I2NSF would deal with is to present a standard interface to express that policy, (which in turn could be pushed out to the security devices.)

Not sure if the entity pushing the intent/policy happens to be an app gateway (or not) matters in this context.

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,

Thanks, Linda

-----Original Message-----

Linda,

Thank you,
Kathleen

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Feb 2015 16:28:29 -0500

Myo,

On Tue, Feb 3, 2015 at 4:18 PM, Zarny, Myo <[email-masked]> wrote:
> Hi Kathleen, Linda,
>
> Seems to me, what I2NSF is trying to do is to come up with a standard way to
> express and accept policy—in this case, that certain flows follow a
> different path. It's not trying to alter policy/intent. So, using your
> example, if your current policy is to use URLs and domain names to determine
> your firewall insertion policy, what I2NSF would deal with is to present a
> standard interface to express that policy, (which in turn could be pushed
> out to the security devices.)
>
> Not sure if the entity pushing the intent/policy happens to be an app
> gateway (or not) matters in this context.

Yes, thank you.  I understand and it's good to make sure this is
explicitly stated in any I2NSF documentation.  I'd also advise against
using interception of TLS session capabilities in your examples, even
if that is a possible use case as the IETF does it's best to ensure
end-to-end encrypted sessions are not intercepted.  Even though this
happens in corporate environments right now, you'd be better off to
have other dynamic configuration examples described.

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

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

-- 

Best regards,
Kathleen

---

From: "Zarny, Myo" <[email-masked]>
Date: Tue, 3 Feb 2015 16:42:09 -0500

Hi Kathleen,

Not familiar with the specific example that deals with TLS session capabilities. But I think I2NSF should be agnostic as to specific implementation [best] practices--whether that be to terminate TLS on the middle boxes or whatever else--even if they are non-optimal practices.

Two cents…

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]]
Sent: 3 February 2015 4:28 PM
To: Zarny, Myo [Tech]
Cc: Linda Dunbar; 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)

Myo,

On Tue, Feb 3, 2015 at 4:18 PM, Zarny, Myo <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Kathleen, Linda,
>
> Seems to me, what I2NSF is trying to do is to come up with a standard
> way to express and accept policy—in this case, that certain flows
> follow a different path. It's not trying to alter policy/intent. So,
> using your example, if your current policy is to use URLs and domain
> names to determine your firewall insertion policy, what I2NSF would
> deal with is to present a standard interface to express that policy,
> (which in turn could be pushed out to the security devices.)
>

Yes, thank you.  I understand and it's good to make sure this is explicitly stated in any I2NSF documentation.  I'd also advise against using interception of TLS session capabilities in your examples, even if that is a possible use case as the IETF does it's best to ensure end-to-end encrypted sessions are not intercepted.  Even though this happens in corporate environments right now, you'd be better off to have other dynamic configuration examples described.

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

> Cc: John Strassner; Pascal Menezes; Romascanu, Dan (Dan);
> [email-masked]<mailto:[email-masked]>; Natale, Bob; Xialiang (Frank); Joseph Salowey
> 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.
> in firewalls today added to the attacks on TLS drafts so they were understood)?
>
> 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
>>
>>
>>
>> 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).

--

Best regards,
Kathleen

---

From: <[email-masked]>
Date: Wed, 4 Feb 2015 10:17:34 +0000

+1

For me, the (simplified & high-level) case for I2NSF is an operator/administrator with a collection of network security functions (virtual & otherwise) which they wish to control with a standardised interface to implement their organisation's security policy.  Unfortunately, some of theses 'organisations' may have policies which we don't agree with.

I think some of the specific use-cases we've seen discussed (while valid) are perhaps a little too detailed for where we are right now.  Personally, I'd prefer to focus on defining the set of 'network security services' (suggested by Russ) which allow us to understand the complete set of security function capabilities which can then be used to implement any number of different policies.

Grateful for any other thoughts on this?

Joe

________________________________
From: I2nsf <[email-masked]> on behalf of Zarny, Myo <[email-masked]>
Sent: 03 February 2015 21:42
To: 'Kathleen Moriarty'
Cc: 'John Strassner'; 'Pascal Menezes'; 'Natale, Bob'; [email-masked]'; 'Linda Dunbar'; 'Romascanu, Dan (Dan)'; '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)

Hi Kathleen,

Two cents…

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]]
Sent: 3 February 2015 4:28 PM
To: Zarny, Myo [Tech]
Cc: Linda Dunbar; 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)

Myo,

Thank you,
Kathleen

--

Best regards,
Kathleen

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 4 Feb 2015 09:34:55 +0000

Hi,

I concur with Myo here. In my view, the gist of I2NSF is the fact that users (in enterprise or home environments) may decide to offload their security services to third parties that host them in the network.  I2NSF shall deal with the mechanisms to establish trust between the user environment and the hosted services, and how to manage and operate them. Virtualization techniques introduce a degree of flexibility, scalability and ability to support personalization that require to reassess the management and operation (by users and providers) of these services, of course building on already achieved results.

I agree that certain examples are really sensitive and it would be wise to avoid them. Another potentially interesting and non-sensitive example is illustrated by the post I got this morning from one of our partners in the I2NSF-related project we are involved: https://community.rapid7.com/community/metasploit/blog/2015/01/16/weekly-metasploit-wrapup In a nutshell, Google is no longer delivering security patches for Jelly Bean (versions 4.1-4.3) and earlier. According to that story and Google's own developer dashboard, release 4.4 (KitKat) has only about 40% diffusion.

Be goode,

On 3 Feb 2015, at 22:42 , Zarny, Myo <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kathleen,

Two cents…

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]]
Sent: 3 February 2015 4:28 PM
To: Zarny, Myo [Tech]
Cc: Linda Dunbar; John Strassner; Pascal Menezes; Romascanu, Dan (Dan); [email-masked]<mailto:[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)

Myo,

Thank you,
Kathleen

--

Best regards,
Kathleen

Dr Diego R. Lopez
Telefonica I+D