Subject: [Spud] PCP vs. SPUD

From: Aaron Falk <[email-masked]>
Date: Wed, 25 Mar 2015 16:38:04 -0500

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

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 25 Mar 2015 22:31:06 +0000

> On 25 Mar 2015, at 16:38, Aaron Falk <[email-masked]> wrote:
> 
> 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?  
> 
SPUD can easily replace STUN as the connectivity check protocol when doing ICE without adding more packets to the “transaction”. You would do the “pinhole” functionality and open up the tube(s) with one packet. 

With PCP , I think, you would first need to talk to the FW to open the pinhole, and then you can run ICE/STUN as normal.

.-.
Pål-Erik 

> --aaron
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 26 Mar 2015 04:34:22 +0000

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:[email-masked]] On Behalf Of Aaron Falk
Sent: Thursday, March 26, 2015 3:08 AM
To: [email-masked]
Subject: [Spud] PCP vs. SPUD

--aaron

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Mar 2015 07:02:43 -0500

Aaron,

I view this stuff differently.  It's not whether an extra protocol can
do the job, but whether there can be another implicit contract built, at
least in the case of directionality.  That could be a tradeoff between
signaling delay and packet overhead, but we don't yet really know what
that packet overhead looks like.  If this is all DTLS then maybe apps
want to eat that anyway.

Eliot

---

From: Aaron Falk <[email-masked]>
Date: Thu, 26 Mar 2015 14:07:38 -0500

HI Eliot-

I don't understand your response.  Could you expand on it a little?  Are
you saying they both solve the problem but SPUD is more efficient?

--aaron

On Thu, Mar 26, 2015 at 7:02 AM, Eliot Lear <[email-masked]> wrote:

>  Aaron,
>
> I view this stuff differently.  It's not whether an extra protocol can do
> the job, but whether there can be another implicit contract built, at least
> in the case of directionality.  That could be a tradeoff between signaling
> delay and packet overhead, but we don't yet really know what that packet
> overhead looks like.  If this is all DTLS then maybe apps want to eat that
> anyway.
>
> Eliot
>
>
> Spud mailing [email-masked]://www.ietf.org/mailman/listinfo/spud
>
>
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Mar 2015 14:31:15 -0500

On 3/26/15 2:07 PM, Aaron Falk wrote:
> HI Eliot-
>
> I don't understand your response.  Could you expand on it a little? 
> Are you saying they both solve the problem but SPUD is more efficient?

There are potential efficiency tradeoffs, depending on whether the
results of the work lead to additional packet overhead or not (we cannot
yet say what that tradeoff is).  PCP requires setup but there is no
packet overhead.  The reason that SPUD doesn't require setup is that it
is implicit and observable in the same way TCP is, and the intentions
are clear to everyone.  That has been a good way to protect hosts from
some forms of attack, such as DOS/DDOS.

Eliot

---

From: <[email-masked]>
Date: Thu, 26 Mar 2015 14:06:51 +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:[email-masked]] De la part de Tirumaleswar Reddy (tireddy)
Envoyé : mercredi 25 mars 2015 23:34
À : Aaron Falk; [email-masked]
Cc : [email-masked]
Objet : Re: [pcp] [Spud] PCP vs. SPUD

-Tiru

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

--aaron

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Mar 2015 09:46:19 -0500

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, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Tiru, all,
>  
>       Protocol (PCP) feature: (PCP ANNOUNCE OPCODE, [RFC6887]).
>  
> Cheers,
> Med
>