IETF Logo Mail Archive

Re: [Spud] PCP vs. SPUD

<mohamed.boucadair@orange.com> Thu, 26 March 2015 14:06 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B753F1A8700; Thu, 26 Mar 2015 07:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIeFwwDIQeN8; Thu, 26 Mar 2015 07:06:54 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778581A88C8; Thu, 26 Mar 2015 07:06:53 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id EE58F3B430B; Thu, 26 Mar 2015 15:06:51 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C799927C058; Thu, 26 Mar 2015 15:06:51 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 15:06:51 +0100
From: <mohamed.boucadair@orange.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, Aaron Falk <aaron.falk@gmail.com>, "spud@ietf.org" <spud@ietf.org>
Thread-Topic: [Spud] PCP vs. SPUD
Thread-Index: AQHQZ0P9fkfGXDN/UUCaOAQAWpF0oZ0uK8OwgAChdFA=
Date: Thu, 26 Mar 2015 14:06:51 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330052DBD45@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CAD62q9XopDJ7PFA9Hz7R2nV6OcwhQA=T=oGwQAN2_0EFPZvwzg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A366D0A57@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A366D0A57@xmb-rcd-x10.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330052DBD45OPEXCLILMA3corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.3031
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/KpAzAzP7yrN7MZTrnpTIXfjjQOo>
X-Mailman-Approved-At: Fri, 27 Mar 2015 07:23:10 -0700
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [Spud] PCP vs. SPUD
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 14:06:55 -0000

Hi Tiru, all,

I would like to add that PCP solves another problem that we recorded in https://tools.ietf.org/html/draft-boucadair-transport-protocols-01

      Even if protocols encapsulated over UDP can make use of NAT
      traversal techniques, these protocols are still suffering from
      issues related to the presence of NATs and firewalls.  For
      example, there is no mechanism to notify endpoints that an entry
      is no more active in the NAT/Firewall.  Immediate notification and
      state recovery can be solved by activating specific Port Control
      Protocol (PCP) feature: (PCP ANNOUNCE OPCODE, [RFC6887<https://tools.ietf.org/html/rfc6887>])>]).

Cheers,
Med

De : pcp [mailto:pcp-bounces@ietf.org] De la part de Tirumaleswar Reddy (tireddy)
Envoyé : mercredi 25 mars 2015 23:34
À : Aaron Falk; spud@ietf.org
Cc : pcp@ietf.org
Objet : Re: [pcp] [Spud] PCP vs. SPUD

Yes, PCP can be used to communicate with middle boxes to open and close pinholes; PCP also handles attacks like attacker closing the pinholes opened by the victim or attacker opening pinholes on behalf of victim to launch DDOS attacks, allow only authorized endpoints to open/close pinholes etc.

-Tiru


From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Aaron Falk
Sent: Thursday, March 26, 2015 3:08 AM
To: spud@ietf.org<mailto:spud@ietf.org>
Subject: [Spud] PCP vs. SPUD

If we take SPUD's goals at their most minimal, as expressed by Ted, of enabling passage of encrypted traffic through middleboxes, can someone explain why PCP is not sufficient?

--aaron

v2.8.7 | Report a Bug | By Email