IETF Logo Mail Archive

Re: [Spud] PCP vs. SPUD

Phillip Hallam-Baker <hallam@gmail.com> Fri, 27 March 2015 14:46 UTC

Return-Path: <hallam@gmail.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 E93071A8834; Fri, 27 Mar 2015 07:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-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 uJBHWG0TvXer; Fri, 27 Mar 2015 07:46:46 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFDE1ACEB4; Fri, 27 Mar 2015 07:46:19 -0700 (PDT)
Received: by oifl3 with SMTP id l3so77808366oif.0; Fri, 27 Mar 2015 07:46:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2UrWVLF7biWWpgVmUNwuvFhaAwb7XPZovA5P3hLWf+4=; b=GXcf10XsxXJJLTNrtPgWz4L6h/Ux0LoWnw3T1+ojTAEQF89fVn4GNmaWdi/rm69ikF SvCD0F7+ZszqZc2+4MTlMtnNRq04PlcL5xxLFjks+SfiP7tHkASd8E0s8V3ef18sim36 USp580Zv/TPT2Tl2srjzyobuLsedfXzQzN+IRTDyPoXWfWpPIZnwAK3ZNwCXDvFn7+Yj L716EErR84Mry6drtnyQIm5zoYBuW+0X9mPsXcmKBBtzDtzXnjZ5qKbCTjKFOVC7EBnJ 7eSIYOenSDJOxgtR+IDLFGzfJpGiPcUZxYUi/YmJBSNoS5jGUuwKI63BVu4Ws0f363OU SqRg==
X-Received: by 10.60.103.116 with SMTP id fv20mr2501294oeb.2.1427467578828; Fri, 27 Mar 2015 07:46:18 -0700 (PDT)
Received: from [10.197.51.160] ([166.177.122.219]) by mx.google.com with ESMTPSA id v4sm1098074oec.7.2015.03.27.07.46.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Mar 2015 07:46:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-A473137B-C234-40A1-A143-F36613BA3251
Mime-Version: 1.0 (1.0)
From: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: iPhone Mail (12B436)
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330052DBD45@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Fri, 27 Mar 2015 09:46:19 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <1A23686B-6089-4A72-86E3-6703648B783D@gmail.com>
References: <CAD62q9XopDJ7PFA9Hz7R2nV6OcwhQA=T=oGwQAN2_0EFPZvwzg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A366D0A57@xmb-rcd-x10.cisco.com> <787AE7BB302AE849A7480A190F8B9330052DBD45@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
To: "<mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/XLkggUvwRBa0BFtrvJrJoLcspVg>
X-Mailman-Approved-At: Fri, 27 Mar 2015 07:51:36 -0700
Cc: Aaron Falk <aaron.falk@gmail.com>, "pcp@ietf.org" <pcp@ietf.org>, "Tirumaleswar Reddy \(tireddy\)" <tireddy@cisco.com>, "spud@ietf.org" <spud@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: Fri, 27 Mar 2015 14:46:49 -0000

The question I think needs to be considered is whether spud layers on Pcp or is an alternative way of obtaining that functionality

If the second, to what extent can we reuse ?

Opening inbound ports is clearly one aspect of the spud problem but only one



Sent from my difference engine


> On Mar 26, 2015, at 09:06, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
> 
> 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]).
>  
> 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
> 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
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud

v2.8.7 | Report a Bug | By Email