Subject: [pcp] Comparing MIDCOM, PCP with I2NSF

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Feb 2015 19:38:14 +0000

Melinda,

(CC'ed PCP group and MIDCOM group for wider review. )

After studying RFCs/Charter of MIDCOM and PCP, it seems to me that PCP is a lot more closely tied with MIDCOM than I2NSF.
" The PCP working group is chartered to standardize a client/server Port
Control Protocol (PCP) to enable an explicit dialog with a middlebox
such as a NAT or a firewall to open up and/or forward TCP or UDP port,
regardless of the location of that middlebox"

MIDCOM "focuses its attention on communication with firewalls and network address translators (including translation between IPv6 and IPv4)."

I  noticed that the detailed protocols developed by MIDCOM is quite different from PCP. For example, the MDCOM protocol is tied closely with the SIP agent (SIP/RTSP Proxy) to send "INVITE", respond to "180Ringing" or "Port-BIND" reply to Middle Boxes. The MIDCOM protocol is very much SIP protocol oriented, whereas the PCP is more FW/NAT device oriented.

I2NSF will focus on management of many instances of security functions (virtual security functions), i.e. the use case described by http://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecases/:

Among the 3 actions listed in the Use Case draft, I can see that  #2 below can utilize some of the mechanisms developed by PCP and MIDCOM.

   1.  Customer enrollment and cancellation of the subscription to a
      vNSF. (

   2.  Configuration of the vNSF, based on specific configurations or
      derived from common security policies defined by the operator.

   3.  Retrieve and list of the vNSF functionalities, extracted from a
      manifest or a descriptor.  The network operator management systems
      can demand this information to offer detailed information through
      the commercial channels to the customer.

What messages & protocols by MIDCOM & PCP do you see that can be used for I2NSF purpose?

Linda

---

From: Tom Taylor <[email-masked]>
Date: Mon, 09 Feb 2015 18:11:57 -0500

You might want to look at MIDCOM Semantics (RFC 5189) as a starting 
point, if you haven't already. From there:
  -- RFC 5190 gives the official solution, in terms of a MIB module
  -- RFC 4540 gives the NEC solution (SIMCO)
See section 7 of RFC 5190 for examples of each transaction type. I think 
you'll find what you have asked for below.

Tom Taylor

On 09/02/2015 2:38 PM, Linda Dunbar wrote:
> Melinda,
>
> (CC’ed PCP group and MIDCOM group for wider review. )
>
> After studying RFCs/Charter of MIDCOM and PCP, it seems to me that PCP
> is a lot more closely tied with MIDCOM than I2NSF.
>
> “ The PCP working group is chartered to standardize a client/server Port
> regardless of the location of that middlebox”
>
> MIDCOM “focuses its attention on communication with firewalls and
> network address translators (including translation between IPv6 and IPv4).”
>
> I  noticed that the detailed protocols developed by MIDCOM is quite
> different from PCP. For example, the MDCOM protocol is tied closely with
> the SIP agent (SIP/RTSP Proxy) to send “INVITE”, respond to “180Ringing”
> or “Port-BIND” reply to Middle Boxes.The MIDCOM protocol is very much
> SIP protocol oriented, whereas the PCP is more FW/NAT device oriented.
>
> I2NSF will focus on management of many instances of security functions
> (virtual security functions), i.e. the use case described
> byhttp://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecases/:
>
> Among the 3 actions listed in the Use Case draft, I can see that  #2
> below can utilize some of the mechanisms developed by PCP and MIDCOM.
>
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 9 Feb 2015 15:46:07 -0800

PCP deals with an incoming connection (with its MAP opcode) and with timeouts of a connection (with its PEER opcode).  As they are, those don't seem to help much a subscriber choosing some network services function for their traffic.  MAP does have a FILTER option, which provides some filtering (ACL) capabilities, but I expect i2nsf is looking at more advanced functionality than that?

-d

On 09-Feb-2015 11:38 AM, Linda Dunbar <[email-masked]> wrote: 
> MIDCOM “focuses its attention on communication with firewalls and network address translators (including translation between IPv6 and IPv4).”
>  
> I  noticed that the detailed protocols developed by MIDCOM is quite different from PCP. For example, the MDCOM protocol is tied closely with the SIP agent (SIP/RTSP Proxy) to send “INVITE”, respond to “180Ringing” or “Port-BIND” reply to Middle Boxes. The MIDCOM protocol is very much SIP protocol oriented, whereas the PCP is more FW/NAT device oriented.
>  
>  
> I2NSF will focus on management of many instances of security functions (virtual security functions), i.e. the use case described by http://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecases/ <http://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecases/>:
>  
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 11 Feb 2015 21:07:39 +0000

Melinda, 

Thank you very much for the detailed explanation. 

While the MIDCOM's SNMP MIB centric approach is not appropriate for I2NSF, pieces of  "two stage reservation model" might be useful for the bullet #1 of the I2NSF focused use case: http://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecases/

      vNSF. 

Will you or someone who is familiar with the "two-stage reservation" protocol write an applicability draft to show how to use this protocol for I2NSF? 

Linda

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Monday, February 09, 2015 2:38 PM
To: Linda Dunbar; [email-masked]
Cc: [email-masked]
Subject: Re: [I2nsf] Comparing MIDCOM, PCP with I2NSF

[I've removed the midcom cc: - midcom has been shut down for probably a decade, and I would guess that the majority of email addresses on that list are no longer valid.]

On 2/9/15 10:38 AM, Linda Dunbar wrote:
> different from PCP. For example, the MDCOM protocol is tied closely 
> with the SIP agent (SIP/RTSP Proxy) to send "INVITE", respond to "180Ringing"
> or "Port-BIND" reply to Middle Boxes.The MIDCOM protocol is very much 

I wouldn't say that.  It's reservation-oriented and there was an expectation that the primary deployment environment (but not the only one) would be VoIP and real-time conferencing, including SIP, H.323, and other reservation-oriented protocols.  There was an assumption that there would be some authoritative service that would have a view into endpoint sessions and be able to authorize (or not) resource allocation requests.  That is to say, there's a trust model there that may not be applicable to endpoint-driven requests without some sort of trusted authorization gizmo.

But that said, there's a specific information model applied to security devices, and security device requests, that was developed in the context of an SNMP MIB.  There's also a two-stage reservation model, which was specified in order to allow better resource management.

We had an actual use case, though, with specific customer demand from large telcos and specific product development requirements from VoIP vendors, and that constrained our problem space a bit.

Melinda

---

From: <[email-masked]>
Date: Thu, 12 Feb 2015 15:02:25 +0000

Hi Linda,

FWIW, an extension to PCP to deal with more advanced functionalities than the base PCP is available at : https://tools.ietf.org/html/draft-reddy-pcp-sdn-firewall-00. I'm not sure if that proposal meets the objectives of your task#2.

As for subscription aspects, you may check https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-protocol/ together with https://tools.ietf.org/html/rfc7297.

Cheers,
Med

De : I2nsf [mailto:[email-masked]] De la part de Linda Dunbar
Envoyé : lundi 9 février 2015 20:38
À : Melinda Shore; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : [I2nsf] Comparing MIDCOM, PCP with I2NSF

Melinda,

Linda