Re: [pcp] #62: Client-driven or server-driven auth retransmissions

Rafa Marin Lopez <rafa@um.es> Thu, 25 October 2012 17:48 UTC

Return-Path: <rafa@um.es>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE0421F892C for <pcp@ietfa.amsl.com>; Thu, 25 Oct 2012 10:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXxcjMMxrxDK for <pcp@ietfa.amsl.com>; Thu, 25 Oct 2012 10:48:19 -0700 (PDT)
Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 199E221F8869 for <pcp@ietf.org>; Thu, 25 Oct 2012 10:48:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 53D104BF14; Thu, 25 Oct 2012 19:48:14 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon12.um.es
Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nFDRTVHF9qFo; Thu, 25 Oct 2012 19:48:13 +0200 (CEST)
Received: from inf-205-150.inf.um.es (inf-205-150.inf.um.es [155.54.205.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPSA id 464654BF0C; Thu, 25 Oct 2012 19:48:12 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <5087FB60.6060101@viagenie.ca>
Date: Thu, 25 Oct 2012 19:48:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BF682F6-8CD3-4EAA-A1B8-DEA50337A574@um.es>
References: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> <tslwqyggjxb.fsf@mit.edu> <5087FB60.6060101@viagenie.ca>
To: Simon Perreault <simon.perreault@viagenie.ca>
X-Mailer: Apple Mail (2.1283)
Cc: pcp@ietf.org
Subject: Re: [pcp] #62: Client-driven or server-driven auth retransmissions
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2012 17:48:20 -0000

Hi Simon:

El 24/10/2012, a las 16:29, Simon Perreault escribió:

> Le 2012-10-24 07:59, Sam Hartman a écrit :
>> We could really use input from PCP implementations about whether having
>> the authentication retransmit timer on the client is easier than the
>> server.
> 
> I can't say I understand all the technical details, but here's my view:
> 
> Without auth, only PCP clients do retransmissions. Servers only reply to packets, so that's less state and load on PCP servers. It would be nice if we could keep it the way it is.

In any case, the PCP server will have to keep a state since it will have to run an EAP authenticator state machine and a AAA client. Thus, handling a timer should not add too much (or basically nothing), specially when you already have a protocol that does that for you. 

Having said that, as far as I understand it, the side-by-side PANA solution would not touch this behavior you mention in PCP clients and PCP server implementations. At PCP level, retransmissions will work as usual: PCP clients do retransmissions. But performing authentication would be run by a different protocol which is not PCP and which already provides all the functionality required to perform with full guarantees the authentication you need.

In my opinion, using PANA to bootstrap a PCP SA is pretty straight forward. You run PANA, you get a MSK that it is used to derive a key to build the PCP SA. If during the PCP SA life, you need to refresh the key used for that, you need to perform a re-authentication to obtain a new fresh MSK and therefore a fresh PCP SA. Well, you have also that with PANA. When you do not require the key and, therefore, the PCP SA, you can terminate the PANA session and that's all.

Hope this helps.


> 
> My 2¢CAD...
> 
> Simon
> -- 
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------