Subject: Re: [midcom] [I2nsf] Comparing MIDCOM, PCP with I2NSF

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