From mohamed.boucadair@orange.com Thu Sep 6 00:59:27 2012 Return-Path: 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 ABB3D21F84C4 for ; Thu, 6 Sep 2012 00:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 nn0e7eP9L8hI for ; Thu, 6 Sep 2012 00:59:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id F181621F8438 for ; Thu, 6 Sep 2012 00:59:26 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 55019324775 for ; Thu, 6 Sep 2012 09:59:26 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3CF61238076 for ; Thu, 6 Sep 2012 09:59:26 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 6 Sep 2012 09:59:24 +0200 From: To: "pcp@ietf.org" Date: Thu, 6 Sep 2012 09:59:24 +0200 Thread-Topic: PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MA/dZ0tIQQYf4QKO7YrZuMBIi/wAAR7Ow Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 07:59:27 -0000 Dear all, FYI, a new I-D describing the problem of referrals in NAT64 is described.=20 Comments and suggestions are welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : jeudi 6 septembre 2012 09:48 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-pcp-nat64-prefix64-option-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PREFIX64 PCP Option for NAT64 Author(s) : Mohamed Boucadair Filename : draft-boucadair-pcp-nat64-prefix64-option-00.txt Pages : 8 Date : 2012-09-06 Abstract: This document defines a new PCP option to learn the Prefix64 used by a PCP-controlled NAT64 device to build IPv4-embedded IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals (e.g., SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-nat64-prefix64-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From simon.perreault@viagenie.ca Thu Sep 6 05:36:15 2012 Return-Path: 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 BED0B21F852E for ; Thu, 6 Sep 2012 05:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 SpAT7YDPsPDJ for ; Thu, 6 Sep 2012 05:36:15 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 53AAE21F8528 for ; Thu, 6 Sep 2012 05:36:15 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:c0c6:fcc8:f214:3951]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 69746415C2 for ; Thu, 6 Sep 2012 08:36:14 -0400 (EDT) Message-ID: <504898BD.7000702@viagenie.ca> Date: Thu, 06 Sep 2012 08:36:13 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: pcp@ietf.org References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 12:36:16 -0000 Interesting... I have a question: Consider a PCP client that receives a MAP response containing a PREFIX64 option. Does the option apply a) only to the mapping contained in the MAP response, or b) to all future mappings as well? If a), how is PREFIX64 of any use to the client? If b), why include it in a MAP response? Why not DHCP or something else? What happens if the client receives two MAP responses with conflicting PREFIX64 options? Does it have to check that? 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 From mohamed.boucadair@orange.com Thu Sep 6 06:20:15 2012 Return-Path: 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 4279021F854C for ; Thu, 6 Sep 2012 06:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 5LGotqsc7g8n for ; Thu, 6 Sep 2012 06:20:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 536FB21F8508 for ; Thu, 6 Sep 2012 06:20:14 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5A6033245FE; Thu, 6 Sep 2012 15:20:13 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 404402380F2; Thu, 6 Sep 2012 15:20:13 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 6 Sep 2012 15:20:11 +0200 From: To: Simon Perreault , "pcp@ietf.org" Date: Thu, 6 Sep 2012 15:20:09 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MLDXUe1rOQ71EQfyyBaxvbFw0hwAAxtQA Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> In-Reply-To: <504898BD.7000702@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.6.104516 Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:20:15 -0000 Hi Simon, Before answering your questions, I would like to say some words about the c= ontext of this work: In fact we have ported a SIP UA implementation to be P= CP-aware and tested it IPv6-only environment + NAT64 in using both Wifi and= 3G connectivity. The challenge was=20 (1) to place successful communications between IPvx/IPvy UAs without requir= ing any particular mechanism in the SIP Proxy Server and ALG in the NAT64 (2) use PCP to control the NAT64 IPv6-only UA needs to be provisioned with the PREFIX64 used by the PCP-cont= rolled NAT64 for local synthesis of IPv4-embedded IPv6 addresses.=20 Retrieving the PREFIX64 used by the PCP-controlled NAT64 using PCP was a na= tural approach rather than mandating to support a dedicated DHCP option; ma= inly for the following reasons: * DHCPv6 is not supported by some mobile UEs * We need to correlate a PREFIX64 and a NAT64 device Below some answers. Cheers, Med =20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Simon Perreault >Envoy=E9 : jeudi 6 septembre 2012 14:36 >=C0 : pcp@ietf.org >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Interesting... I have a question: > >Consider a PCP client that receives a MAP response containing=20 >a PREFIX64=20 >option. Does the option apply a) only to the mapping contained in the=20 >MAP response, or b) to all future mappings as well? Med: I'm tempted to say the prefix will be used for all mappings associated= with the same PCP server. A record to associate a PCP server and a PREFIX6= 4 should be maintained by the client. We need to check if there are scenari= os where the same PCP Server controls NAT64s configured with distinct PREFI= X64 servicing the same IPv6-only host. =20 > >If a), how is PREFIX64 of any use to the client? Med: I'm not sure I get your question; but PREFIX64 will be used whenever n= eeded to construct IPv4-embedded IPv6 addresses. This is needed particularl= y for services which does not involve DNS64. > >If b), why include it in a MAP response? Why not DHCP or=20 >something else?=20 Med: You can include it in DHCP but for mobile terminal not supporting DHCP= v6 this may not help. >What happens if the client receives two MAP responses with conflicting=20 >PREFIX64 options? Does it have to check that? Med: If we assume a PCP Server controls only one NAT64/PREFIX64, then it i= s safe the client to check whether only one PREFIX64 is learned for each PC= P Server. > >Simon >--=20 >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 >= From simon.perreault@viagenie.ca Thu Sep 6 07:00:06 2012 Return-Path: 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 9B87B21F8546 for ; Thu, 6 Sep 2012 07:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 GhFUEt5-BEgI for ; Thu, 6 Sep 2012 07:00:06 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id F133421F8539 for ; Thu, 6 Sep 2012 07:00:05 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:c0c6:fcc8:f214:3951]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4A0D9415C2; Thu, 6 Sep 2012 10:00:04 -0400 (EDT) Message-ID: <5048AC63.50700@viagenie.ca> Date: Thu, 06 Sep 2012 10:00:03 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:00:06 -0000 Mohamed, Thanks for the very detailed answer! The background story is much clearer to me now. Le 2012-09-06 09:20, mohamed.boucadair@orange.com a écrit : >> Consider a PCP client that receives a MAP response containing a >> PREFIX64 option. Does the option apply a) only to the mapping >> contained in the MAP response, or b) to all future mappings as >> well? > > Med: I'm tempted to say the prefix will be used for all mappings > associated with the same PCP server. A record to associate a PCP > server and a PREFIX64 should be maintained by the client. We need to > check if there are scenarios where the same PCP Server controls > NAT64s configured with distinct PREFIX64 servicing the same IPv6-only > host. I still have a problem with this. The problem is that the PREFIX64 data should not be associated with a MAP request because it is global to the server. Returning it as part of a MAP response makes no sense to me. Suggestion: why not create a new opcode for querying server-global parameters? The PCP client would use this opcode once, get the PREFIX64 data in the response, then would do MAP requests separately as usual. I think this would result in clearer semantics and implementations. 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 From mohamed.boucadair@orange.com Thu Sep 6 08:04:20 2012 Return-Path: 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 CDCC521F8630 for ; Thu, 6 Sep 2012 08:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 NzohDkOTyZVt for ; Thu, 6 Sep 2012 08:04:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E57E121F8566 for ; Thu, 6 Sep 2012 08:04:19 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 82ABF26444C; Thu, 6 Sep 2012 17:04:18 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 67A2323811E; Thu, 6 Sep 2012 17:04:18 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 6 Sep 2012 17:04:16 +0200 From: To: Simon Perreault Date: Thu, 6 Sep 2012 17:04:15 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MN+pyip/7fC+xTfaMVl8xB0e06QABPrfQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> In-Reply-To: <5048AC63.50700@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.6.104516 Cc: "pcp@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:04:20 -0000 Re-, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 >Envoy=E9 : jeudi 6 septembre 2012 16:00 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : pcp@ietf.org >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Mohamed, > >Thanks for the very detailed answer! The background story is much=20 >clearer to me now. > >Le 2012-09-06 09:20, mohamed.boucadair@orange.com a =E9crit : >>> Consider a PCP client that receives a MAP response containing a >>> PREFIX64 option. Does the option apply a) only to the mapping >>> contained in the MAP response, or b) to all future mappings as >>> well? >> >> Med: I'm tempted to say the prefix will be used for all mappings >> associated with the same PCP server. A record to associate a PCP >> server and a PREFIX64 should be maintained by the client. We need to >> check if there are scenarios where the same PCP Server controls >> NAT64s configured with distinct PREFIX64 servicing the same IPv6-only >> host. > >I still have a problem with this. The problem is that the=20 >PREFIX64 data=20 >should not be associated with a MAP request because it is=20 >global to the=20 >server. Returning it as part of a MAP response makes no sense to me. Med: I see it from a distinct perspective: return it in the MAP says to the= PCP Client this is the prefix the NAT64 will use when translating received= IPv4 packets matching the instantiated entry. The question whether we can = extrapolate it to all mapping is a valid one.=20 > >Suggestion: why not create a new opcode for querying server-global=20 >parameters? The PCP client would use this opcode once, get the=20 >PREFIX64=20 >data in the response, then would do MAP requests separately as=20 >usual. I=20 >think this would result in clearer semantics and implementations. Med: I'm open to evaluate which approach is better: new opcode vs. new opti= on. We need first to agree this is valid problem to solve. > >Simon >--=20 >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 >= From simon.perreault@viagenie.ca Thu Sep 6 08:28:41 2012 Return-Path: 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 6186B21F8722 for ; Thu, 6 Sep 2012 08:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 7grHlrw21uqg for ; Thu, 6 Sep 2012 08:28:41 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8721F86FA for ; Thu, 6 Sep 2012 08:28:40 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:c0c6:fcc8:f214:3951]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4C8C3415C2; Thu, 6 Sep 2012 11:28:40 -0400 (EDT) Message-ID: <5048C127.50704@viagenie.ca> Date: Thu, 06 Sep 2012 11:28:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:28:41 -0000 Le 2012-09-06 11:04, mohamed.boucadair@orange.com a écrit : > Med: I'm open to evaluate which approach is better: new opcode vs. > new option. We need first to agree this is valid problem to solve. There is clearly a need to discover the NAT64 prefix: draft-ietf-behave-nat64-learn-analysis draft-ietf-behave-nat64-discovery-heuristic Note that the analysis draft does not consider PCP. Maybe it should. Looking at the list of pros and cons for DHCPv6, PCP would be different, and better in some aspects. Personally I would much prefer using PCP than the heuristic when PCP is available. 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 From tom.taylor.stds@gmail.com Thu Sep 6 12:48:53 2012 Return-Path: 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 8301421F8766; Thu, 6 Sep 2012 12:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 aAEZQ5+tgGTX; Thu, 6 Sep 2012 12:48:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DABC421F8745; Thu, 6 Sep 2012 12:48:52 -0700 (PDT) Received: by iabz21 with SMTP id z21so2714956iab.31 for ; Thu, 06 Sep 2012 12:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=Xp8tOe/h28kFwr2Ao0J5IAjPXjeCZuKXGq7g8bueWvs=; b=dlaD9+wEPOqs7DDvDizha4bKNxM5qoNwZHKJ/Mv2R5XN5/iu2MbTzXAVNsbWSJXgqg 7UjRfJy37z9qV29BJwHavRjq1sKZ8nq+2yVEOOkjbt/ybhcbpwrcvbz+8xBrFmYJ4k4o O8q2GlXqYlpekKxXkzdQT91ax4nLPd0JLpMBQMfalxVESsL/7nDzsMGqFIDlu+edyrd/ G8m2WrvRYIjs3WdPZUqJfBmP4v8gO0/VwKmHGlmdemtrE+zR61lPLcF8avBn5L714XHi uBKtriwCSJskNC7ku2jmU+wITW1UKTX3CQeZ9n0Bqw1tMuQa38gxiD6X37+cL3o79hk+ Qpkw== Received: by 10.50.53.199 with SMTP id d7mr4824052igp.55.1346960932369; Thu, 06 Sep 2012 12:48:52 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-40-163.tor.primus.ca. [173.206.40.163]) by mx.google.com with ESMTPS id ff4sm7350559igc.5.2012.09.06.12.48.50 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 12:48:51 -0700 (PDT) Message-ID: <5048FE21.9040006@gmail.com> Date: Thu, 06 Sep 2012 15:48:49 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "behave@ietf.org" , pcp@ietf.org References: <20120906193435.11136.29014.idtracker@ietfa.amsl.com> In-Reply-To: <20120906193435.11136.29014.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120906193435.11136.29014.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120906-0, 06/09/2012), Outbound message X-Antivirus-Status: Clean Subject: [pcp] Fwd: New Version Notification for draft-zhou-behave-syslog-nat-logging-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 19:48:53 -0000 draft-zhou-behave-syslog-nat-logging was presented in Vancouver and was the subject of a fair amount of discussion. People were not convinced that operators would want NAT logging, even if the volume of data generated is cut down by orders of magnitude through allocation of blocks of ports. There was also the question of whether operators could agree on the log contents they require. The authors have accepted this verdict, and are prepared to wait until operator demand emerges. In the meantime, the draft has been drastically rewritten to focus on the format for a SYSLOG record, with the philosophy that all parameters are optional. Each operator selects the subset most relevant to their deployment. As mentioned in the Abstract, the authors see an opportunity to expand the scope of the draft to include PCP logging. The present draft just has indications of this possibility -- the authors have not thought it through. If the draft takes that route, it would probably define multiple log types to handle the different PCP operations. Tom Taylor -------- Original Message -------- Subject: New Version Notification for draft-zhou-behave-syslog-nat-logging-01.txt Date: Thu, 06 Sep 2012 12:34:35 -0700 From: internet-drafts@ietf.org To: tom.taylor.stds@gmail.com CC: cathy.zhou@huawei.com, tina.tsou.zouting@huawei.com, 18918588897@189.cn A new version of I-D, draft-zhou-behave-syslog-nat-logging-01.txt has been successfully submitted by T. Taylor and posted to the IETF repository. Filename: draft-zhou-behave-syslog-nat-logging Revision: 01 Title: Syslog Format for NAT Logging Creation date: 2012-09-06 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-zhou-behave-syslog-nat-logging-01.txt ... Abstract: Under some circumstances operators will need to maintain a dynamic record of external address and port assignments made by a Carrier Grade NAT (CGN), and will find it feasible and convenient to create such records using SYSLOG (RFC 5424). The present document standardizes a SYSLOG format to meet that recording requirement. It specifies a number of fields that could be a part of the log report, leaving it up to operators to select the fields needed for their specific circumstances. [*** Subject to discussion*** The log format presented here may also be used by PCP server implementations to log the mappings they implement.] ... From dthaler@microsoft.com Thu Sep 6 18:21:47 2012 Return-Path: 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 770B721F86D1 for ; Thu, 6 Sep 2012 18:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.848 X-Spam-Level: X-Spam-Status: No, score=-103.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 hEjanyX5taMW for ; Thu, 6 Sep 2012 18:21:45 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id CCA0721F86C8 for ; Thu, 6 Sep 2012 18:21:43 -0700 (PDT) Received: from mail116-db3-R.bigfish.com (10.3.81.228) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 01:21:42 +0000 Received: from mail116-db3 (localhost [127.0.0.1]) by mail116-db3-R.bigfish.com (Postfix) with ESMTP id BB2DE180283 for ; Fri, 7 Sep 2012 01:21:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zzc85fh111aIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h1155h) Received-SPF: pass (mail116-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail116-db3 (localhost.localdomain [127.0.0.1]) by mail116-db3 (MessageSwitch) id 1346980900393385_31233; Fri, 7 Sep 2012 01:21:40 +0000 (UTC) Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.242]) by mail116-db3.bigfish.com (Postfix) with ESMTP id 5313A10015E for ; Fri, 7 Sep 2012 01:21:40 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 01:21:39 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 7 Sep 2012 01:21:36 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 6 Sep 2012 18:21:35 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0318.003; Thu, 6 Sep 2012 18:21:35 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: IETF 84 PCP minutes posted Thread-Index: Ac2Mlvu6Yg4hhfTdTfWUVgjieEHpAQ== Date: Fri, 7 Sep 2012 01:21:34 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7A651F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7A651FTK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] IETF 84 PCP minutes posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 01:21:47 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7A651FTK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The minutes from Vancouver are now posted at http://www.ietf.org/proceedings/84/minutes/minutes-84-pcp Please send any corrections to the chairs. Thanks again to Paul and Stuart for being our notetakers! -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B7A651FTK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The minutes from Vancouver are now posted at

http://www.ietf.org/proceedings/84/minutes/minutes-84-pcp=

 

Please send any corrections to the chairs.

 

Thanks again to Paul and Stuart for being our noteta= kers!

 

-Dave

--_000_9B57C850BB53634CACEC56EF4853FF653B7A651FTK5EX14MBXW604w_-- From mohamed.boucadair@orange.com Thu Sep 6 22:26:04 2012 Return-Path: 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 696EE21F84A0 for ; Thu, 6 Sep 2012 22:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, UNPARSEABLE_RELAY=0.001] 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 2y4F+G4MVNxs for ; Thu, 6 Sep 2012 22:26:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49D21F849C for ; Thu, 6 Sep 2012 22:26:03 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id CE70F18C1FA; Fri, 7 Sep 2012 07:26:01 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B4FFC4C063; Fri, 7 Sep 2012 07:26:01 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 7 Sep 2012 07:25:59 +0200 From: To: Simon Perreault Date: Fri, 7 Sep 2012 07:25:58 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUw Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> In-Reply-To: <5048C127.50704@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.7.43620 Cc: "pcp@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 05:26:04 -0000 Hi Simon, Perhaps it is too late to ask for including it in the analysis draft.=20 I see another place where we can ask for including it is: 464xlat v6op draf= t.=20 Cheers, Med=20 >-----Message d'origine----- >De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 >Envoy=E9 : jeudi 6 septembre 2012 17:29 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : pcp@ietf.org >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : >> Med: I'm open to evaluate which approach is better: new opcode vs. >> new option. We need first to agree this is valid problem to solve. > >There is clearly a need to discover the NAT64 prefix: >draft-ietf-behave-nat64-learn-analysis >draft-ietf-behave-nat64-discovery-heuristic > >Note that the analysis draft does not consider PCP. Maybe it should.=20 >Looking at the list of pros and cons for DHCPv6, PCP would be=20 >different,=20 >and better in some aspects. > >Personally I would much prefer using PCP than the heuristic=20 >when PCP is=20 >available. > >Simon >--=20 >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 >= From tireddy@cisco.com Thu Sep 6 23:14:21 2012 Return-Path: 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 2EF7B21E808A for ; Thu, 6 Sep 2012 23:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 qpfgyKEII1FG for ; Thu, 6 Sep 2012 23:14:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 190A321E8088 for ; Thu, 6 Sep 2012 23:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3643; q=dns/txt; s=iport; t=1346998459; x=1348208059; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=piOPQV7fItuvK9TFnTNTafi+wOMTezajFH9hkw7TYBM=; b=PtxhqFM9owEwgTx25Pr3EMaDIE3WaUNsem7bPZC4DgOObpUueY1F0tms +ejLJPKye5boZZxGR+s28XUjqIyn2SMSEVGZc7aVG4e+uZvc76MwfpOFE UnErqbHiD9DHuNvrt2IjWW3PLSBKm80bOr5MSz5NHQnyvCZhVTRjOtnSh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKGPSVCtJV2Z/2dsb2JhbABFu1GBB4IgAQEBBAEBAQ8BFEcXBAIBCBEEAQELHQcnCxQJCAIEARIIGoduC5tJoDSLEYVRYAOIG45TjSGBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="119174924" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 07 Sep 2012 06:14:18 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q876EI9W018515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 06:14:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Fri, 7 Sep 2012 01:14:18 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "Simon Perreault" , "pcp@ietf.org" Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: AQHNjGHYHk72WZPGtEa2ok3OounwPZd+ZCCA Date: Fri, 7 Sep 2012 06:14:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1479F67B@xmb-rcd-x10.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.163] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.004 x-tm-as-result: No--48.721500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 06:14:21 -0000 Hi Med - You may want to look into draft http://tools.ietf.org/html/draft-ietf-beha= ve-nat64-discovery-heuristic-11 which already addresses this problem and al= so refers to cases where multiple Pref64::/n exist. --Tiru. > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, September 06, 2012 6:50 PM > To: Simon Perreault; pcp@ietf.org > Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat= 64- > prefix64-option >=20 > Hi Simon, >=20 > Before answering your questions, I would like to say some words about the > context of this work: In fact we have ported a SIP UA implementation to b= e > PCP-aware and tested it IPv6-only environment + NAT64 in using both Wifi = and > 3G connectivity. The challenge was >=20 > (1) to place successful communications between IPvx/IPvy UAs without requ= iring > any particular mechanism in the SIP Proxy Server and ALG in the NAT64 > (2) use PCP to control the NAT64 >=20 > IPv6-only UA needs to be provisioned with the PREFIX64 used by the PCP- > controlled NAT64 for local synthesis of IPv4-embedded IPv6 addresses. >=20 > Retrieving the PREFIX64 used by the PCP-controlled NAT64 using PCP was a > natural approach rather than mandating to support a dedicated DHCP option= ; > mainly for the following reasons: >=20 > * DHCPv6 is not supported by some mobile UEs > * We need to correlate a PREFIX64 and a NAT64 device >=20 > Below some answers. >=20 > Cheers, > Med >=20 >=20 > >-----Message d'origine----- > >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la > >part de Simon Perreault > >Envoy=E9 : jeudi 6 septembre 2012 14:36 > >=C0 : pcp@ietf.org > >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: > >draft-boucadair-pcp-nat64-prefix64-option > > > >Interesting... I have a question: > > > >Consider a PCP client that receives a MAP response containing > >a PREFIX64 > >option. Does the option apply a) only to the mapping contained in the > >MAP response, or b) to all future mappings as well? >=20 > Med: I'm tempted to say the prefix will be used for all mappings associat= ed > with the same PCP server. A record to associate a PCP server and a PREFIX= 64 > should be maintained by the client. We need to check if there are scenari= os > where the same PCP Server controls NAT64s configured with distinct PREFIX= 64 > servicing the same IPv6-only host. >=20 > > > >If a), how is PREFIX64 of any use to the client? >=20 > Med: I'm not sure I get your question; but PREFIX64 will be used whenever > needed to construct IPv4-embedded IPv6 addresses. This is needed particul= arly > for services which does not involve DNS64. >=20 > > > >If b), why include it in a MAP response? Why not DHCP or > >something else? >=20 > Med: You can include it in DHCP but for mobile terminal not supporting DH= CPv6 > this may not help. >=20 > >What happens if the client receives two MAP responses with conflicting > >PREFIX64 options? Does it have to check that? >=20 > Med: If we assume a PCP Server controls only one NAT64/PREFIX64, then it= is > safe the client to check whether only one PREFIX64 is learned for each PC= P > Server. >=20 > > > >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 > > From mohamed.boucadair@orange.com Thu Sep 6 23:22:48 2012 Return-Path: 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 CF4AC21F868A for ; Thu, 6 Sep 2012 23:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 9RQcEoCiDFNq for ; Thu, 6 Sep 2012 23:22:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B7D7121F8687 for ; Thu, 6 Sep 2012 23:22:47 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E874F324367; Fri, 7 Sep 2012 08:22:46 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id CC4B227C115; Fri, 7 Sep 2012 08:22:46 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 7 Sep 2012 08:22:43 +0200 From: To: "Tirumaleswar Reddy (tireddy)" , Simon Perreault , "pcp@ietf.org" Date: Fri, 7 Sep 2012 08:22:42 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: AQHNjGHYHk72WZPGtEa2ok3OounwPZd+ZCCAgAADTYA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B0866E@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <913383AAA69FF945B8F946018B75898A1479F67B@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1479F67B@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.7.60049 Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 06:22:48 -0000 Dear Reddy, Thanks for the pointer. I'm already aware about that document. Are you arguing the heuristic should be used instead of retrieving directly= the information from the PCP server? Cheers, Med=20 >-----Message d'origine----- >De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 >Envoy=E9 : vendredi 7 septembre 2012 08:14 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault; pcp@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Hi Med - > >You may want to look into draft =20 >http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-he >uristic-11 which already addresses this problem and also=20 >refers to cases where multiple Pref64::/n exist. > >--Tiru. > >> -----Original Message----- >> From: mohamed.boucadair@orange.com=20 >[mailto:mohamed.boucadair@orange.com] >> Sent: Thursday, September 06, 2012 6:50 PM >> To: Simon Perreault; pcp@ietf.org >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64- >> prefix64-option >>=20 >> Hi Simon, >>=20 >> Before answering your questions, I would like to say some=20 >words about the >> context of this work: In fact we have ported a SIP UA=20 >implementation to be >> PCP-aware and tested it IPv6-only environment + NAT64 in=20 >using both Wifi and >> 3G connectivity. The challenge was >>=20 >> (1) to place successful communications between IPvx/IPvy UAs=20 >without requiring >> any particular mechanism in the SIP Proxy Server and ALG in the NAT64 >> (2) use PCP to control the NAT64 >>=20 >> IPv6-only UA needs to be provisioned with the PREFIX64 used=20 >by the PCP- >> controlled NAT64 for local synthesis of IPv4-embedded IPv6 addresses. >>=20 >> Retrieving the PREFIX64 used by the PCP-controlled NAT64=20 >using PCP was a >> natural approach rather than mandating to support a=20 >dedicated DHCP option; >> mainly for the following reasons: >>=20 >> * DHCPv6 is not supported by some mobile UEs >> * We need to correlate a PREFIX64 and a NAT64 device >>=20 >> Below some answers. >>=20 >> Cheers, >> Med >>=20 >>=20 >> >-----Message d'origine----- >> >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la >> >part de Simon Perreault >> >Envoy=E9 : jeudi 6 septembre 2012 14:36 >> >=C0 : pcp@ietf.org >> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp-nat64-prefix64-option >> > >> >Interesting... I have a question: >> > >> >Consider a PCP client that receives a MAP response containing >> >a PREFIX64 >> >option. Does the option apply a) only to the mapping=20 >contained in the >> >MAP response, or b) to all future mappings as well? >>=20 >> Med: I'm tempted to say the prefix will be used for all=20 >mappings associated >> with the same PCP server. A record to associate a PCP server=20 >and a PREFIX64 >> should be maintained by the client. We need to check if=20 >there are scenarios >> where the same PCP Server controls NAT64s configured with=20 >distinct PREFIX64 >> servicing the same IPv6-only host. >>=20 >> > >> >If a), how is PREFIX64 of any use to the client? >>=20 >> Med: I'm not sure I get your question; but PREFIX64 will be=20 >used whenever >> needed to construct IPv4-embedded IPv6 addresses. This is=20 >needed particularly >> for services which does not involve DNS64. >>=20 >> > >> >If b), why include it in a MAP response? Why not DHCP or >> >something else? >>=20 >> Med: You can include it in DHCP but for mobile terminal not=20 >supporting DHCPv6 >> this may not help. >>=20 >> >What happens if the client receives two MAP responses with=20 >conflicting >> >PREFIX64 options? Does it have to check that? >>=20 >> Med: If we assume a PCP Server controls only one=20 >NAT64/PREFIX64, then it is >> safe the client to check whether only one PREFIX64 is=20 >learned for each PCP >> Server. >>=20 >> > >> >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 >> > >= From tireddy@cisco.com Thu Sep 6 23:46:01 2012 Return-Path: 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 B8E2321E808E for ; Thu, 6 Sep 2012 23:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sw4y6djxUJ-w for ; Thu, 6 Sep 2012 23:46:00 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4E05F21E808C for ; Thu, 6 Sep 2012 23:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5319; q=dns/txt; s=iport; t=1347000360; x=1348209960; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Qc1f/tCaNtIZgAr+u++/3jf+UhebqHpmYp/vPGQblvM=; b=GQIJ1+1MPRkJAS6/YXrY/EuutHdBTsbwuySfCYv0yDkcMm52p3yRkGRj JLg0nG2vWAek3koCsSDJ1IcCgUur1gmjH6SDC4rCpVa/8psY12txR1uVc EdHAyNi0+W8FriglcFqb8kbTlJN9IJ3JQIR0PY7H3CuzGvj9xJovInTGj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEuXSVCtJXHB/2dsb2JhbABFu1GBB4IgAQEBAwEBAQEPARRHFwQCAQgRBAEBCx0HJwsUCQgCBAESCBqHaAYLm0ugPYsRhVFgA4gbjlONIYFngmM X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="116202290" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 07 Sep 2012 06:45:59 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q876jxlJ024430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 06:45:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Fri, 7 Sep 2012 01:45:59 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "Simon Perreault" , "pcp@ietf.org" Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: AQHNjGHYHk72WZPGtEa2ok3OounwPZd+ZCCAgAADTYCAAAPhEA== Date: Fri, 7 Sep 2012 06:45:58 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1479F744@xmb-rcd-x10.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <913383AAA69FF945B8F946018B75898A1479F67B@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36E57B0866E@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B0866E@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.163] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.004 x-tm-as-result: No--59.697000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 06:46:01 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Friday, September 07, 2012 11:53 AM > To: Tirumaleswar Reddy (tireddy); Simon Perreault; pcp@ietf.org > Subject: RE: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat= 64- > prefix64-option >=20 > Dear Reddy, >=20 > Thanks for the pointer. I'm already aware about that document. ok. >=20 > Are you arguing the heuristic should be used instead of retrieving direct= ly > the information from the PCP server ? No. This draft already deals with providing multiple Prefix64::/n. you will= have to solve the problem. I am just trying to understand scenarios where PCP server can give a correc= t answer than heuristics, which needs to be highlighted, so that implemente= rs do prefer this option in future. For e.g. using PCP Prefix64::/n lifetim= e of the prefix can be provided which is not possible with heuristics, so t= hat PCP client can learn the new Prefix64 again before expiry. --Tiru. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > >Envoy=E9 : vendredi 7 septembre 2012 08:14 > >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault; pcp@ietf.org > >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64: > >draft-boucadair-pcp-nat64-prefix64-option > > > >Hi Med - > > > >You may want to look into draft > >http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-he > >uristic-11 which already addresses this problem and also > >refers to cases where multiple Pref64::/n exist. > > > >--Tiru. > > > >> -----Original Message----- > >> From: mohamed.boucadair@orange.com > >[mailto:mohamed.boucadair@orange.com] > >> Sent: Thursday, September 06, 2012 6:50 PM > >> To: Simon Perreault; pcp@ietf.org > >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: > >draft-boucadair-pcp-nat64- > >> prefix64-option > >> > >> Hi Simon, > >> > >> Before answering your questions, I would like to say some > >words about the > >> context of this work: In fact we have ported a SIP UA > >implementation to be > >> PCP-aware and tested it IPv6-only environment + NAT64 in > >using both Wifi and > >> 3G connectivity. The challenge was > >> > >> (1) to place successful communications between IPvx/IPvy UAs > >without requiring > >> any particular mechanism in the SIP Proxy Server and ALG in the NAT64 > >> (2) use PCP to control the NAT64 > >> > >> IPv6-only UA needs to be provisioned with the PREFIX64 used > >by the PCP- > >> controlled NAT64 for local synthesis of IPv4-embedded IPv6 addresses. > >> > >> Retrieving the PREFIX64 used by the PCP-controlled NAT64 > >using PCP was a > >> natural approach rather than mandating to support a > >dedicated DHCP option; > >> mainly for the following reasons: > >> > >> * DHCPv6 is not supported by some mobile UEs > >> * We need to correlate a PREFIX64 and a NAT64 device > >> > >> Below some answers. > >> > >> Cheers, > >> Med > >> > >> > >> >-----Message d'origine----- > >> >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la > >> >part de Simon Perreault > >> >Envoy=E9 : jeudi 6 septembre 2012 14:36 > >> >=C0 : pcp@ietf.org > >> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: > >> >draft-boucadair-pcp-nat64-prefix64-option > >> > > >> >Interesting... I have a question: > >> > > >> >Consider a PCP client that receives a MAP response containing > >> >a PREFIX64 > >> >option. Does the option apply a) only to the mapping > >contained in the > >> >MAP response, or b) to all future mappings as well? > >> > >> Med: I'm tempted to say the prefix will be used for all > >mappings associated > >> with the same PCP server. A record to associate a PCP server > >and a PREFIX64 > >> should be maintained by the client. We need to check if > >there are scenarios > >> where the same PCP Server controls NAT64s configured with > >distinct PREFIX64 > >> servicing the same IPv6-only host. > >> > >> > > >> >If a), how is PREFIX64 of any use to the client? > >> > >> Med: I'm not sure I get your question; but PREFIX64 will be > >used whenever > >> needed to construct IPv4-embedded IPv6 addresses. This is > >needed particularly > >> for services which does not involve DNS64. > >> > >> > > >> >If b), why include it in a MAP response? Why not DHCP or > >> >something else? > >> > >> Med: You can include it in DHCP but for mobile terminal not > >supporting DHCPv6 > >> this may not help. > >> > >> >What happens if the client receives two MAP responses with > >conflicting > >> >PREFIX64 options? Does it have to check that? > >> > >> Med: If we assume a PCP Server controls only one > >NAT64/PREFIX64, then it is > >> safe the client to check whether only one PREFIX64 is > >learned for each PCP > >> Server. > >> > >> > > >> >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 > >> > > > From teemu.savolainen@nokia.com Fri Sep 7 00:15:04 2012 Return-Path: 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 1399821E809C for ; Fri, 7 Sep 2012 00:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 7iCE9yG1Mjzc for ; Fri, 7 Sep 2012 00:15:03 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0D63221E809F for ; Fri, 7 Sep 2012 00:15:02 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q877F0Dm018648; Fri, 7 Sep 2012 10:15:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 10:15:00 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.232]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0309.003; Fri, 7 Sep 2012 09:15:00 +0200 From: To: , Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNA= Date: Fri, 7 Sep 2012 07:14:58 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IkG58TW0g8v3pRTIa5m0oRvOwWvPPL+sw1OI592gw0w+/D3rEkeVQ4iwch1++FHcoO6ydKVeY+yCx3JcwHtjroRij1AGuFnPfkj1BKE+9amJQMLBqkOWtEyXwQcgA66Rr5fF+0nTmIq9fhFmwOM2gfVNHhve4r0QbqTjQVKTmTfd6LlB35tVQWpxV69dUtObFgw3JVNtcAwDrBbnM2Wr5OowXtvCCIa3PhLR4cmMj1tWHfI6o6eIvLmFmocxa5M0VK9vjgxt2LbmQJFRMeIhWR2HkLrNofwa3pe2qo3hym0M x-originating-ip: [10.163.19.180] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2012 07:15:00.0817 (UTC) FILETIME=[7E8D9C10:01CD8CC8] X-Nokia-AV: Clean Cc: pcp@ietf.org Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:15:04 -0000 Just quick comment also for PCP mailing (I sent separate email also to beha= ve) - maybe we need to cross post if this discussion extends. The PCP may be fine way to learn Pref64::/n, but I doubt it is possible to = generalize PCP to be always present *and* telling Pref64::/n when there is = NAT64. I.e. PCP would be similar as DHCPv6 in its pros/cons (as listed in d= raft-ietf-behave-nat64-learn-analysis) - am I right? I.e. we need the heuristic to have a general way to find out Pref64::/n, as= we cannot count PCP to be always deployed with NAT64. Best regards, Teemu > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of ext > mohamed.boucadair@orange.com > Sent: 07. syyskuuta 2012 08:26 > To: Simon Perreault > Cc: pcp@ietf.org > Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp- > nat64-prefix64-option > > Hi Simon, > > Perhaps it is too late to ask for including it in the analysis draft. > I see another place where we can ask for including it is: 464xlat v6op dr= aft. > > Cheers, > Med > > >-----Message d'origine----- > >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] > >Envoy=E9 : jeudi 6 septembre 2012 17:29 > >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > >Cc : pcp@ietf.org > >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: > >draft-boucadair-pcp-nat64-prefix64-option > > > >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : > >> Med: I'm open to evaluate which approach is better: new opcode vs. > >> new option. We need first to agree this is valid problem to solve. > > > >There is clearly a need to discover the NAT64 prefix: > >draft-ietf-behave-nat64-learn-analysis > >draft-ietf-behave-nat64-discovery-heuristic > > > >Note that the analysis draft does not consider PCP. Maybe it should. > >Looking at the list of pros and cons for DHCPv6, PCP would be > >different, and better in some aspects. > > > >Personally I would much prefer using PCP than the heuristic when PCP is > >available. > > > >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 From mohamed.boucadair@orange.com Fri Sep 7 01:08:22 2012 Return-Path: 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 448F521F8682 for ; Fri, 7 Sep 2012 01:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 lB55600h-X3i for ; Fri, 7 Sep 2012 01:08:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4347321F8592 for ; Fri, 7 Sep 2012 01:08:20 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B86273245C4; Fri, 7 Sep 2012 10:08:18 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9739E35C112; Fri, 7 Sep 2012 10:08:18 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 7 Sep 2012 10:08:16 +0200 From: To: "Tirumaleswar Reddy (tireddy)" , Simon Perreault , "pcp@ietf.org" Date: Fri, 7 Sep 2012 10:08:15 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: AQHNjGHYHk72WZPGtEa2ok3OounwPZd+ZCCAgAADTYCAAAPhEIAAFD2g Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B086FA@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <913383AAA69FF945B8F946018B75898A1479F67B@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36E57B0866E@PUEXCB1B.nanterre.francetelecom.fr> <913383AAA69FF945B8F946018B75898A1479F744@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1479F744@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.7.74524 Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:08:22 -0000 Re-, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 >Envoy=E9 : vendredi 7 septembre 2012 08:46 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault; pcp@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >> -----Original Message----- >> From: mohamed.boucadair@orange.com=20 >[mailto:mohamed.boucadair@orange.com] >> Sent: Friday, September 07, 2012 11:53 AM >> To: Tirumaleswar Reddy (tireddy); Simon Perreault; pcp@ietf.org >> Subject: RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64- >> prefix64-option >>=20 >> Dear Reddy, >>=20 >> Thanks for the pointer. I'm already aware about that document. > >ok. > >>=20 >> Are you arguing the heuristic should be used instead of=20 >retrieving directly >> the information from the PCP server ? > >No. This draft already deals with providing multiple=20 >Prefix64::/n. you will have to solve the problem. Med: I can see a justification to maintain several PREFIX64, but only one p= refix64 per PCP Server.=20 >I am just trying to understand scenarios where PCP server can=20 >give a correct answer than heuristics, which needs to be=20 >highlighted, so that implementers do prefer this option in=20 >future. Med: OK. A point which can be highlighted is: when load-balancing is used t= o distributed connected IPv6-only hosts among available stateful NAT64, dis= tinct PREFIX64 can be used to distribute the load. PCP will return the appr= opriate PREFIX64 for the assigned PCP-controlled NAT64. PCP can return a pr= efix64 used for reaching a dedicated NAT64 used during planned maintenance = operation or when the primary NAT64 fails. The change of the NAT64 (and pot= entially the PREFIX64) can be dynamically triggered by PCP while this requi= res extra effort for the heuristic. For e.g. using PCP Prefix64::/n lifetime of the prefix=20 >can be provided which is not possible with heuristics, so that=20 >PCP client can learn the new Prefix64 again before expiry. > Med: Good point. Providing the lifetime associated with prefix is encourage= d as per http://tools.ietf.org/html/rfc6250#section-3.2.1.=20 >--Tiru. > >>=20 >> Cheers, >> Med >>=20 >> >-----Message d'origine----- >> >De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >> >Envoy=E9 : vendredi 7 septembre 2012 08:14 >> >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault; pcp@ietf.org >> >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp-nat64-prefix64-option >> > >> >Hi Med - >> > >> >You may want to look into draft >> >http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-he >> >uristic-11 which already addresses this problem and also >> >refers to cases where multiple Pref64::/n exist. >> > >> >--Tiru. >> > >> >> -----Original Message----- >> >> From: mohamed.boucadair@orange.com >> >[mailto:mohamed.boucadair@orange.com] >> >> Sent: Thursday, September 06, 2012 6:50 PM >> >> To: Simon Perreault; pcp@ietf.org >> >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp-nat64- >> >> prefix64-option >> >> >> >> Hi Simon, >> >> >> >> Before answering your questions, I would like to say some >> >words about the >> >> context of this work: In fact we have ported a SIP UA >> >implementation to be >> >> PCP-aware and tested it IPv6-only environment + NAT64 in >> >using both Wifi and >> >> 3G connectivity. The challenge was >> >> >> >> (1) to place successful communications between IPvx/IPvy UAs >> >without requiring >> >> any particular mechanism in the SIP Proxy Server and ALG=20 >in the NAT64 >> >> (2) use PCP to control the NAT64 >> >> >> >> IPv6-only UA needs to be provisioned with the PREFIX64 used >> >by the PCP- >> >> controlled NAT64 for local synthesis of IPv4-embedded=20 >IPv6 addresses. >> >> >> >> Retrieving the PREFIX64 used by the PCP-controlled NAT64 >> >using PCP was a >> >> natural approach rather than mandating to support a >> >dedicated DHCP option; >> >> mainly for the following reasons: >> >> >> >> * DHCPv6 is not supported by some mobile UEs >> >> * We need to correlate a PREFIX64 and a NAT64 device >> >> >> >> Below some answers. >> >> >> >> Cheers, >> >> Med >> >> >> >> >> >> >-----Message d'origine----- >> >> >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la >> >> >part de Simon Perreault >> >> >Envoy=E9 : jeudi 6 septembre 2012 14:36 >> >> >=C0 : pcp@ietf.org >> >> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: >> >> >draft-boucadair-pcp-nat64-prefix64-option >> >> > >> >> >Interesting... I have a question: >> >> > >> >> >Consider a PCP client that receives a MAP response containing >> >> >a PREFIX64 >> >> >option. Does the option apply a) only to the mapping >> >contained in the >> >> >MAP response, or b) to all future mappings as well? >> >> >> >> Med: I'm tempted to say the prefix will be used for all >> >mappings associated >> >> with the same PCP server. A record to associate a PCP server >> >and a PREFIX64 >> >> should be maintained by the client. We need to check if >> >there are scenarios >> >> where the same PCP Server controls NAT64s configured with >> >distinct PREFIX64 >> >> servicing the same IPv6-only host. >> >> >> >> > >> >> >If a), how is PREFIX64 of any use to the client? >> >> >> >> Med: I'm not sure I get your question; but PREFIX64 will be >> >used whenever >> >> needed to construct IPv4-embedded IPv6 addresses. This is >> >needed particularly >> >> for services which does not involve DNS64. >> >> >> >> > >> >> >If b), why include it in a MAP response? Why not DHCP or >> >> >something else? >> >> >> >> Med: You can include it in DHCP but for mobile terminal not >> >supporting DHCPv6 >> >> this may not help. >> >> >> >> >What happens if the client receives two MAP responses with >> >conflicting >> >> >PREFIX64 options? Does it have to check that? >> >> >> >> Med: If we assume a PCP Server controls only one >> >NAT64/PREFIX64, then it is >> >> safe the client to check whether only one PREFIX64 is >> >learned for each PCP >> >> Server. >> >> >> >> > >> >> >Simon >> >> >-- >> >> >DTN made easy, lean, and smart -->=20 >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 >> >> > >> > >= From mohamed.boucadair@orange.com Fri Sep 7 01:27:34 2012 Return-Path: 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 252C721F8570; Fri, 7 Sep 2012 01:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, UNPARSEABLE_RELAY=0.001] 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 hfZhcoxy9jp2; Fri, 7 Sep 2012 01:27:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C7E3921F8567; Fri, 7 Sep 2012 01:27:32 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 08C572643A9; Fri, 7 Sep 2012 10:27:32 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E004827C11B; Fri, 7 Sep 2012 10:27:31 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 7 Sep 2012 10:27:29 +0200 From: To: "teemu.savolainen@nokia.com" , "simon.perreault@viagenie.ca" Date: Fri, 7 Sep 2012 10:27:28 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.7.74524 Cc: "pcp@ietf.org" , "behave@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:27:34 -0000 Hi Teemu, (behave ML cced) The point is: for PCP-enabled networks the heuristic seems to be more "comp= lex" compared to returning this information using PCP. >From an operational standpoint, the situation is as follows: * PCP is needed for NAT64 to accept incoming connections/hosting servers/re= duce keepalive messages/etc.=20 * A solution to learn the PREFIX64 is needed (e.g., IPv4 in referrals) so t= hat local address synthesis can be done by the host. * Several NAT64 can be deployed and load balancing enabled to distribute co= nnected hosts: this can be done by assigning distinct PREFIX64s. * An application/host needs to retrieve the exact PREFIX64 used for the NAT= 64 to be involved in the data path. * An exist strategy is still to be found for the heuristic method. * The heuristic method requires some tweaking in DNS. Given what listed above, wouldn't be safe to provide some guidelines to hel= p selecting which option to use in PCP-based networks or the one to prefer = when both are available?=20 Cheers, Med >-----Message d'origine----- >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 >Envoy=E9 : vendredi 7 septembre 2012 09:15 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; simon.perreault@viagenie.ca >Cc : pcp@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Just quick comment also for PCP mailing (I sent separate email=20 >also to behave) - maybe we need to cross post if this=20 >discussion extends. > >The PCP may be fine way to learn Pref64::/n, but I doubt it is=20 >possible to generalize PCP to be always present *and* telling=20 >Pref64::/n when there is NAT64. I.e. PCP would be similar as=20 >DHCPv6 in its pros/cons (as listed in=20 >draft-ietf-behave-nat64-learn-analysis) - am I right? > >I.e. we need the heuristic to have a general way to find out=20 >Pref64::/n, as we cannot count PCP to be always deployed with NAT64. > >Best regards, > > Teemu > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On=20 >Behalf Of ext >> mohamed.boucadair@orange.com >> Sent: 07. syyskuuta 2012 08:26 >> To: Simon Perreault >> Cc: pcp@ietf.org >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp- >> nat64-prefix64-option >> >> Hi Simon, >> >> Perhaps it is too late to ask for including it in the analysis draft. >> I see another place where we can ask for including it is:=20 >464xlat v6op draft. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] >> >Envoy=E9 : jeudi 6 septembre 2012 17:29 >> >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> >Cc : pcp@ietf.org >> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp-nat64-prefix64-option >> > >> >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : >> >> Med: I'm open to evaluate which approach is better: new opcode vs. >> >> new option. We need first to agree this is valid problem to solve. >> > >> >There is clearly a need to discover the NAT64 prefix: >> >draft-ietf-behave-nat64-learn-analysis >> >draft-ietf-behave-nat64-discovery-heuristic >> > >> >Note that the analysis draft does not consider PCP. Maybe it should. >> >Looking at the list of pros and cons for DHCPv6, PCP would be >> >different, and better in some aspects. >> > >> >Personally I would much prefer using PCP than the heuristic=20 >when PCP is >> >available. >> > >> >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 >= From teemu.savolainen@nokia.com Fri Sep 7 02:57:48 2012 Return-Path: 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 2847021F84EC; Fri, 7 Sep 2012 02:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 zpwCrD3jLyMz; Fri, 7 Sep 2012 02:57:47 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 965F821F84D9; Fri, 7 Sep 2012 02:57:46 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q879vLst017086; Fri, 7 Sep 2012 12:57:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 12:57:21 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.249]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0309.003; Fri, 7 Sep 2012 11:57:20 +0200 From: To: , Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4Q Date: Fri, 7 Sep 2012 09:57:19 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IkG58TW0g8v3pRTIa5m0oRvOwWvPPL+sw1OI592gw0w+/D3rEkeVQ4iwch1++FHcoO6ydKVeY+yCx3JcwHtjroRij1AGuFnPfkj1BKE+9amJQMLBqkOWtEyXwQcgA66Rr5fF+0nTmIq9fhFmwOM2gfVNHhve4r0QbqTjQVKTmTfd6LlB35tVQWpxV69dUtObFgw3JVNtcAwDrBbnM2Wr5OowXtvCCIa3PhLR4cmMj1tWHfI6o6eIvLmFmocxa5M0VK9vjgxt2LbmQJFRMeIhWR2HkLrNofwa3pe2qo3hym0M x-originating-ip: [10.163.19.180] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2012 09:57:21.0608 (UTC) FILETIME=[2C845C80:01CD8CDF] X-Nokia-AV: Clean Cc: pcp@ietf.org, behave@ietf.org Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:57:48 -0000 Hi Med, >From a host standpoint there are no guarantees to have PCP always available= when a NAT64 is present. Hence heuristic is needed anyway, but as an optim= ization/improvement it is possible to avoid heuristic in cases where PCP ha= ppens to be available. To respond to your detailed points: > * PCP is needed for NAT64 to accept incoming connections/hosting > servers/reduce keepalive messages/etc. Only if an operator chooses to provide these goodies to hosts; I have no ev= idence that says all operators who deploy NAT64 are ok to allow incoming co= nnections/hosting services/helping hosts to reduce keepalive signaling. I d= o hope PCP finds its place in networks and helps save battery etc, but it i= s not something that can be assumed to happen (always). > * A solution to learn the PREFIX64 is needed (e.g., IPv4 in referrals) so= that > local address synthesis can be done by the host. Agree:) > * Several NAT64 can be deployed and load balancing enabled to distribute > connected hosts: this can be done by assigning distinct PREFIX64s. Yes, but do you need to make an individual host use multitude of Pref64::/n= ? In a large deployment wouldn't the load balancing purposes be achieved by= some hosts using one Pref64::/n and others using another? > * An application/host needs to retrieve the exact PREFIX64 used for the > NAT64 to be involved in the data path. You plan to utilize different Pref64::/n for different IPv4 destinations? T= hat is definitely something heuristic does not support (finding out random = mappings for different IPv4 addresses would require plenty of queries :-D If this is really a hard requirement (i.e. not possible / too costly) to ro= ute all IPv4 traffic using a single Pref64::/n, then I agree you need to ha= ve a provisioning tool in place. This tool perhaps could be PCP - if this W= G thinks it is ok to extent PCP for this kind of provisioning purposes - fo= r me this sounds a bit like loading PCP with something that might fit bette= r to DHCPv6. All that I'm saying is that PCP cannot replace the need for heuristic in a = general case due availability reasons, and that I don't think it is ok to m= andate hosts to implement PCP just for Pref64::/n discovery purposes. > * An exist strategy is still to be found for the heuristic method. True (but hosts would also someday need to stop asking for Pref64::/n with = PCP). > * The heuristic method requires some tweaking in DNS. It requires hosting of a well-known IPv4-only name, such as "ipv4only.arpa"= . But no tweaking to DNS protocols or server softwares. That is much less t= weaking that implementing PCP client to hosts/applications, hosting PCP ser= ver on all NAT64 enabled networks, and supporting some PCP server discovery= mechanism (e.g. via DHCPv6 options). Best regards, Teemu > -----Original Message----- > From: ext mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: 07. syyskuuta 2012 11:27 > To: Savolainen Teemu (Nokia-NRC/Tampere); simon.perreault@viagenie.ca > Cc: pcp@ietf.org; behave@ietf.org > Subject: RE: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp- > nat64-prefix64-option >=20 > Hi Teemu, >=20 > (behave ML cced) >=20 > The point is: for PCP-enabled networks the heuristic seems to be more > "complex" compared to returning this information using PCP. >=20 > From an operational standpoint, the situation is as follows: >=20 > * PCP is needed for NAT64 to accept incoming connections/hosting > servers/reduce keepalive messages/etc. > * A solution to learn the PREFIX64 is needed (e.g., IPv4 in referrals) so= that > local address synthesis can be done by the host. > * Several NAT64 can be deployed and load balancing enabled to distribute > connected hosts: this can be done by assigning distinct PREFIX64s. > * An application/host needs to retrieve the exact PREFIX64 used for the > NAT64 to be involved in the data path. > * An exist strategy is still to be found for the heuristic method. > * The heuristic method requires some tweaking in DNS. >=20 > Given what listed above, wouldn't be safe to provide some guidelines to h= elp > selecting which option to use in PCP-based networks or the one to prefer > when both are available? >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > >Envoy=E9 : vendredi 7 septembre 2012 09:15 =C0 : BOUCADAIR Mohamed > >OLNC/NAD/TIP; simon.perreault@viagenie.ca Cc : pcp@ietf.org Objet : RE: > >[pcp] PREFIX64 PCP Option for NAT64: > >draft-boucadair-pcp-nat64-prefix64-option > > > >Just quick comment also for PCP mailing (I sent separate email also to > >behave) - maybe we need to cross post if this discussion extends. > > > >The PCP may be fine way to learn Pref64::/n, but I doubt it is possible > >to generalize PCP to be always present *and* telling Pref64::/n when > >there is NAT64. I.e. PCP would be similar as > >DHCPv6 in its pros/cons (as listed in > >draft-ietf-behave-nat64-learn-analysis) - am I right? > > > >I.e. we need the heuristic to have a general way to find out > >Pref64::/n, as we cannot count PCP to be always deployed with NAT64. > > > >Best regards, > > > > Teemu > > > >> -----Original Message----- > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > >Behalf Of ext > >> mohamed.boucadair@orange.com > >> Sent: 07. syyskuuta 2012 08:26 > >> To: Simon Perreault > >> Cc: pcp@ietf.org > >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: > >draft-boucadair-pcp- > >> nat64-prefix64-option > >> > >> Hi Simon, > >> > >> Perhaps it is too late to ask for including it in the analysis draft. > >> I see another place where we can ask for including it is: > >464xlat v6op draft. > >> > >> Cheers, > >> Med > >> > >> >-----Message d'origine----- > >> >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] > >> >Envoy=E9 : jeudi 6 septembre 2012 17:29 =C0 : BOUCADAIR Mohamed > >> >OLNC/NAD/TIP Cc : pcp@ietf.org Objet : Re: [pcp] PREFIX64 PCP Option > >> >for NAT64: > >> >draft-boucadair-pcp-nat64-prefix64-option > >> > > >> >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : > >> >> Med: I'm open to evaluate which approach is better: new opcode vs. > >> >> new option. We need first to agree this is valid problem to solve. > >> > > >> >There is clearly a need to discover the NAT64 prefix: > >> >draft-ietf-behave-nat64-learn-analysis > >> >draft-ietf-behave-nat64-discovery-heuristic > >> > > >> >Note that the analysis draft does not consider PCP. Maybe it should. > >> >Looking at the list of pros and cons for DHCPv6, PCP would be > >> >different, and better in some aspects. > >> > > >> >Personally I would much prefer using PCP than the heuristic > >when PCP is > >> >available. > >> > > >> >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 > > From mohamed.boucadair@orange.com Fri Sep 7 04:40:11 2012 Return-Path: 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 02F5D21E8034; Fri, 7 Sep 2012 04:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, UNPARSEABLE_RELAY=0.001] 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 Jj0s5Yj61+74; Fri, 7 Sep 2012 04:40:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 850D821E803C; Fri, 7 Sep 2012 04:40:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9801C2643F7; Fri, 7 Sep 2012 13:40:08 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 743BA238129; Fri, 7 Sep 2012 13:40:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 7 Sep 2012 13:40:06 +0200 From: To: "teemu.savolainen@nokia.com" , "simon.perreault@viagenie.ca" Date: Fri, 7 Sep 2012 13:40:05 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAAPxyvA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "pcp@ietf.org" , "behave@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 11:40:11 -0000 Re-, Please see inline. Cheers, Med =20 >-----Message d'origine----- >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 >Envoy=E9 : vendredi 7 septembre 2012 11:57 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; simon.perreault@viagenie.ca >Cc : pcp@ietf.org; behave@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Hi Med, > >From a host standpoint there are no guarantees to have PCP=20 >always available when a NAT64 is present.=20 Med: Yes, this is deployment-specific. Note the LSN requirements draft mand= ates to have a way to open mappings. Hence heuristic is=20 >needed anyway, but as an optimization/improvement it is=20 >possible to avoid heuristic in cases where PCP happens to be available. Med: This is what I wanted to hear. The intent was not to say PCP is better= . My initial discussion point was focusing on PCP-enabled networks and only= that case. Concretely, would it be possible to add a sentence in the sense= of your statement above?=20 > >To respond to your detailed points: > >> * PCP is needed for NAT64 to accept incoming connections/hosting >> servers/reduce keepalive messages/etc. > >Only if an operator chooses to provide these goodies to hosts;=20 >I have no evidence that says all operators who deploy NAT64=20 >are ok to allow incoming connections/hosting services/helping=20 >hosts to reduce keepalive signaling. I do hope PCP finds its=20 >place in networks and helps save battery etc, but it is not=20 >something that can be assumed to happen (always). Med: That's fair. Again, I'm exclusively positioning this discussion in con= text where PCP is deployed. > >> * A solution to learn the PREFIX64 is needed (e.g., IPv4 in=20 >referrals) so that >> local address synthesis can be done by the host. > >Agree:) > >> * Several NAT64 can be deployed and load balancing enabled=20 >to distribute >> connected hosts: this can be done by assigning distinct PREFIX64s. > >Yes, but do you need to make an individual host use multitude=20 >of Pref64::/n? In a large deployment wouldn't the load=20 >balancing purposes be achieved by some hosts using one=20 >Pref64::/n and others using another? > >> * An application/host needs to retrieve the exact PREFIX64=20 >used for the >> NAT64 to be involved in the data path. > >You plan to utilize different Pref64::/n for different IPv4=20 >destinations? That is definitely something heuristic does not=20 >support (finding out random mappings for different IPv4=20 >addresses would require plenty of queries :-D Med: This can happen if each NAT64 is servicing a portion of the IPv4 netwo= rk/internet. > >If this is really a hard requirement (i.e. not possible / too=20 >costly) to route all IPv4 traffic using a single Pref64::/n,=20 >then I agree you need to have a provisioning tool in place.=20 >This tool perhaps could be PCP - if this WG thinks it is ok to=20 >extent PCP for this kind of provisioning purposes - for me=20 >this sounds a bit like loading PCP with something that might=20 >fit better to DHCPv6. Med: I disagree: PCP is there to help NAT traversal, returning the PREFIX64= is part of that problem.=20 > >All that I'm saying is that PCP cannot replace the need for=20 >heuristic in a general case due availability reasons, and that=20 >I don't think it is ok to mandate hosts to implement PCP just=20 >for Pref64::/n discovery purposes. Med: I didn't asked for that. Sorry I was not clear: the scope of this disc= ussion is: PCP-enabled networks. > >> * An exist strategy is still to be found for the heuristic method. > >True (but hosts would also someday need to stop asking for=20 >Pref64::/n with PCP). > >> * The heuristic method requires some tweaking in DNS. > >It requires hosting of a well-known IPv4-only name, such as=20 >"ipv4only.arpa". But no tweaking to DNS protocols or server=20 >softwares. That is much less tweaking that implementing PCP=20 >client to hosts/applications, hosting PCP server on all NAT64=20 >enabled networks, and supporting some PCP server discovery=20 >mechanism (e.g. via DHCPv6 options). > >Best regards, > > Teemu > >> -----Original Message----- >> From: ext mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Sent: 07. syyskuuta 2012 11:27 >> To: Savolainen Teemu (Nokia-NRC/Tampere); simon.perreault@viagenie.ca >> Cc: pcp@ietf.org; behave@ietf.org >> Subject: RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp- >> nat64-prefix64-option >>=20 >> Hi Teemu, >>=20 >> (behave ML cced) >>=20 >> The point is: for PCP-enabled networks the heuristic seems to be more >> "complex" compared to returning this information using PCP. >>=20 >> From an operational standpoint, the situation is as follows: >>=20 >> * PCP is needed for NAT64 to accept incoming connections/hosting >> servers/reduce keepalive messages/etc. >> * A solution to learn the PREFIX64 is needed (e.g., IPv4 in=20 >referrals) so that >> local address synthesis can be done by the host. >> * Several NAT64 can be deployed and load balancing enabled=20 >to distribute >> connected hosts: this can be done by assigning distinct PREFIX64s. >> * An application/host needs to retrieve the exact PREFIX64=20 >used for the >> NAT64 to be involved in the data path. >> * An exist strategy is still to be found for the heuristic method. >> * The heuristic method requires some tweaking in DNS. >>=20 >> Given what listed above, wouldn't be safe to provide some=20 >guidelines to help >> selecting which option to use in PCP-based networks or the=20 >one to prefer >> when both are available? >>=20 >> Cheers, >> Med >>=20 >> >-----Message d'origine----- >> >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] >> >Envoy=E9 : vendredi 7 septembre 2012 09:15 =C0 : BOUCADAIR Mohamed >> >OLNC/NAD/TIP; simon.perreault@viagenie.ca Cc : pcp@ietf.org=20 >Objet : RE: >> >[pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp-nat64-prefix64-option >> > >> >Just quick comment also for PCP mailing (I sent separate=20 >email also to >> >behave) - maybe we need to cross post if this discussion extends. >> > >> >The PCP may be fine way to learn Pref64::/n, but I doubt it=20 >is possible >> >to generalize PCP to be always present *and* telling Pref64::/n when >> >there is NAT64. I.e. PCP would be similar as >> >DHCPv6 in its pros/cons (as listed in >> >draft-ietf-behave-nat64-learn-analysis) - am I right? >> > >> >I.e. we need the heuristic to have a general way to find out >> >Pref64::/n, as we cannot count PCP to be always deployed with NAT64. >> > >> >Best regards, >> > >> > Teemu >> > >> >> -----Original Message----- >> >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On >> >Behalf Of ext >> >> mohamed.boucadair@orange.com >> >> Sent: 07. syyskuuta 2012 08:26 >> >> To: Simon Perreault >> >> Cc: pcp@ietf.org >> >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp- >> >> nat64-prefix64-option >> >> >> >> Hi Simon, >> >> >> >> Perhaps it is too late to ask for including it in the=20 >analysis draft. >> >> I see another place where we can ask for including it is: >> >464xlat v6op draft. >> >> >> >> Cheers, >> >> Med >> >> >> >> >-----Message d'origine----- >> >> >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] >> >> >Envoy=E9 : jeudi 6 septembre 2012 17:29 =C0 : BOUCADAIR Mohamed >> >> >OLNC/NAD/TIP Cc : pcp@ietf.org Objet : Re: [pcp]=20 >PREFIX64 PCP Option >> >> >for NAT64: >> >> >draft-boucadair-pcp-nat64-prefix64-option >> >> > >> >> >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : >> >> >> Med: I'm open to evaluate which approach is better:=20 >new opcode vs. >> >> >> new option. We need first to agree this is valid=20 >problem to solve. >> >> > >> >> >There is clearly a need to discover the NAT64 prefix: >> >> >draft-ietf-behave-nat64-learn-analysis >> >> >draft-ietf-behave-nat64-discovery-heuristic >> >> > >> >> >Note that the analysis draft does not consider PCP.=20 >Maybe it should. >> >> >Looking at the list of pros and cons for DHCPv6, PCP would be >> >> >different, and better in some aspects. >> >> > >> >> >Personally I would much prefer using PCP than the heuristic >> >when PCP is >> >> >available. >> >> > >> >> >Simon >> >> >-- >> >> >DTN made easy, lean, and smart -->=20 >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 >> > >= From teemu.savolainen@nokia.com Fri Sep 7 06:17:21 2012 Return-Path: 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 B7E0821F841B; Fri, 7 Sep 2012 06:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 yi3Z3qf3bShM; Fri, 7 Sep 2012 06:17:21 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A13ED21F85EF; Fri, 7 Sep 2012 06:17:20 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q87DHEvU031013; Fri, 7 Sep 2012 16:17:15 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 16:17:14 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.232]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0309.003; Fri, 7 Sep 2012 15:17:14 +0200 From: To: , Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAAPxyvAAAq5H8A== Date: Fri, 7 Sep 2012 13:17:12 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620445C977@008-AM1MPN1-053.mgdnok.nokia.com> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IkG58TW0g8v3pRTIa5m0oRvOwWvPPL+sw1OI592gw0w+/D3rEkeVQ4iwch1++FHcoO6ydKVeY+yCx3JcwHtjroRij1AGuFnPfkj1BKE+9amJQMLBqkOWtEyXwQcgA66Rr5fF+0nTmIq9fhFmwOM2gfVNHhve4r0QbqTjQVKTmTfd6LlB35tVQWpxV69dUtObFgw3JVNtcAwDrBbnM2Wr5OowXtvCCIa3PhLR4cmMj1tWHfI6o6eIvLmFmocxa5M0VK9vjgxt2LbmQJFRMeIhWR2HkLrNofwa3pe2qo3hym0M x-originating-ip: [10.163.19.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2012 13:17:14.0774 (UTC) FILETIME=[19004360:01CD8CFB] X-Nokia-AV: Clean Cc: pcp@ietf.org, behave@ietf.org Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:17:21 -0000 Hi, Inline: > >From a host standpoint there are no guarantees to have PCP always > >available when a NAT64 is present. >=20 > Med: Yes, this is deployment-specific. Note the LSN requirements draft > mandates to have a way to open mappings. I hope the cellular (and other) operators actually follow the guidance once= that draft becomes RFC.=20 =20 > Med: This is what I wanted to hear. The intent was not to say PCP is bett= er. My > initial discussion point was focusing on PCP-enabled networks and only th= at > case. Concretely, would it be possible to add a sentence in the sense of = your > statement above? I think the heuristic draft is best to be kept as a standalone tool and I t= hink that it definitely should not speculate on what other tools there migh= t be available in the future (there have been other proposals as well at th= e individual I-D level). If the PREFIX64 option is adopted by the PCP WG, I think it could describe = how it will coexist with heuristic-option, e.g. saying that if a client sup= ports PCP, it SHOULD/MUST try with PREFIX64 option before performing heuris= tic procedures. Btw how do you get the IPv4 subnet->Pref64::/n mapping list with this optio= n? I quickly looked the draft and it also seemed to deliver just one Pref64= ::/n? > >Only if an operator chooses to provide these goodies to hosts; I have > >no evidence that says all operators who deploy NAT64 are ok to allow > >incoming connections/hosting services/helping hosts to reduce keepalive > >signaling. I do hope PCP finds its place in networks and helps save > >battery etc, but it is not something that can be assumed to happen > >(always). >=20 > Med: That's fair. Again, I'm exclusively positioning this discussion in c= ontext > where PCP is deployed. Good, and I definitely support deployment of PCP. > >This tool perhaps could be PCP - if this WG thinks it is ok to extent > >PCP for this kind of provisioning purposes - for me this sounds a bit > >like loading PCP with something that might fit better to DHCPv6. >=20 > Med: I disagree: PCP is there to help NAT traversal, returning the PREFIX= 64 is > part of that problem. Well, ok, I agree and changed my mind on this:) The PCP Server definitely h= as an interface to NAT64 (unlike DHCPv6 Server), and hence it could ask the= Pref64::/n from it (or provision it to NAT64, whatever you guys plan to do= ). > Med: I didn't asked for that. Sorry I was not clear: the scope of this di= scussion > is: PCP-enabled networks. Thanks, in PCP-enabled networks it is definitely ok to skip heuristics in f= avor for explicit configuration.=20 If you do go forward with explicit option, you could look if you can resolv= e the "mapping of IPv4 address ranges to IPv6 prefixes" problem. Something = better perhaps than asking from PCP Server what is the Pref64::/n for a giv= en IPv4 address.. Best regards Teemu From iesg-secretary@ietf.org Fri Sep 7 07:33:37 2012 Return-Path: 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 5A94821F85F4; Fri, 7 Sep 2012 07:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YqpjRsiVuNOf; Fri, 7 Sep 2012 07:33:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94DA21F8467; Fri, 7 Sep 2012 07:33:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907143336.16769.76297.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 07:33:36 -0700 Cc: pcp@ietf.org Subject: [pcp] PCP WG Virtual Interim Meeting, September 21, 2012 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:33:37 -0000 The PCP Working Group will hold a virtual interim meeting on Friday, Septem= ber 21, 2012, at 7AM PDT, using WebEx. Agenda and dialin information will be posted at: = http://tools.ietf.org/wg/pcp/trac/wiki From dwing@cisco.com Fri Sep 7 16:35:04 2012 Return-Path: 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 C55A221E8084; Fri, 7 Sep 2012 16:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 l7wJTyzV7mkL; Fri, 7 Sep 2012 16:35:04 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39C3F21F8581; Fri, 7 Sep 2012 16:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=966; q=dns/txt; s=iport; t=1347060904; x=1348270504; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=YLmnc2BtpIsP1eem+xPQRNum+HxcSxFl50wiMNQvu2c=; b=ECrWqHlSSZJjH5hZxbWMa2TZ2nVYATP8WIRAtgA7S+dlYZdER59ZDbxI 7eV+RYPRblYawgDtVIJHZRwJIiH179OyXmpaKecXQKiYd0DkrpH+QRomv RoYpI80s8dz3lQt8ihx3CIxn6Q4mPSQ/r6aiCZM99m42Yh1SSymdihRNl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAGyDSlCrRDoG/2dsb2JhbABFq1SPfYEHgiEBAQQICgEXED8NAwIJDzcZIxsBAQQBHReHbZsaoBiLF4YvA4hThQ6WMYFngwQ X-IronPort-AV: E=Sophos;i="4.80,388,1344211200"; d="scan'208";a="54476878" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 07 Sep 2012 23:35:03 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q87NZ3S0023869; Fri, 7 Sep 2012 23:35:03 GMT From: "Dan Wing" To: , , References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> Date: Fri, 7 Sep 2012 16:35:04 -0700 Message-ID: <04f301cd8d51$68b6cbd0$3a246370$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAB0jEWA= Content-Language: en-us Cc: pcp@ietf.org, behave@ietf.org Subject: Re: [pcp] [BEHAVE] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 23:35:04 -0000 ... > > * PCP is needed for NAT64 to accept incoming connections/hosting > > servers/reduce keepalive messages/etc. > > Only if an operator chooses to provide these goodies to hosts; I have > no evidence that says all operators who deploy NAT64 are ok to allow > incoming connections/hosting services/helping hosts to reduce keepalive > signaling. I do hope PCP finds its place in networks and helps save > battery etc, but it is not something that can be assumed to happen > (always). The MAP Opcode allows those incoming connections, which is separate from the PEER Opcode to optimize keepalives. It would be annoying to implementers, but I could imagine some network operators deploying a PCP server with PEER enabled but with MAP disabled. I would imagine the network operators that, today, find excuses to rotate their subscriber's IP addresses every day would be among those operators that will not allow MAP but might allow PEER. -d From yoshihiro.ohba@toshiba.co.jp Sun Sep 9 17:05:02 2012 Return-Path: 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 199A121F85DA for ; Sun, 9 Sep 2012 17:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.422 X-Spam-Level: X-Spam-Status: No, score=-5.422 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 zbknkAF0Sfxy for ; Sun, 9 Sep 2012 17:05:01 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5293D21F8575 for ; Sun, 9 Sep 2012 17:05:01 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q8A050ng023994 for ; Mon, 10 Sep 2012 09:05:00 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q8A050Br018141 for pcp@ietf.org; Mon, 10 Sep 2012 09:05:00 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA18140; Mon, 10 Sep 2012 09:05:00 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q8A04xDT027168 for ; Mon, 10 Sep 2012 09:05:00 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8A04xru001830; Mon, 10 Sep 2012 09:04:59 +0900 (JST) Received: from [133.196.20.88] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MA3001HMXKBDZ70@mail.po.toshiba.co.jp> for pcp@ietf.org; Mon, 10 Sep 2012 09:04:59 +0900 (JST) Date: Mon, 10 Sep 2012 09:05:01 +0900 From: Yoshihiro Ohba In-reply-to: <20120909235628.10408.47557.idtracker@ietfa.amsl.com> To: "pcp@ietf.org" Message-id: <504D2EAD.5030102@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit X-Forwarded-Message-Id: <20120909235628.10408.47557.idtracker@ietfa.amsl.com> References: <20120909235628.10408.47557.idtracker@ietfa.amsl.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: [pcp] Fwd: New Version Notification for draft-ohba-pcp-pana-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:05:02 -0000 Based on the discussion in IETF84, we revised the draft to support demultiplexing PANA and PCP on the same port. We request to discuss this draft in the interim meeting. Your feedback is appreciated. Regards, Yoshihiro Ohba -------- Original Message -------- Subject: New Version Notification for draft-ohba-pcp-pana-01.txt Date: Sun, 09 Sep 2012 16:56:28 -0700 From: internet-drafts@ietf.org To: yoshihiro.ohba@toshiba.co.jp CC: yatch@isl.rdc.toshiba.co.jp, alper.yegin@yegin.org, sdas@appcomsci.com A new version of I-D, draft-ohba-pcp-pana-01.txt has been successfully submitted by Yoshihiro Ohba and posted to the IETF repository. Filename: draft-ohba-pcp-pana Revision: 01 Title: Provisioning Message Authentication Key for PCP using PANA Creation date: 2012-09-10 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-ohba-pcp-pana-01.txt Status: http://datatracker.ietf.org/doc/draft-ohba-pcp-pana Htmlized: http://tools.ietf.org/html/draft-ohba-pcp-pana-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ohba-pcp-pana-01 Abstract: This document specifies a mechanism for provisioning PCP (Port Control Protocol) message authentication key using PANA (Protocol for carrying Authentication for Network Access). The IETF Secretariat From mohamed.boucadair@orange.com Tue Sep 11 02:50:11 2012 Return-Path: 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 0D39F21F8769; Tue, 11 Sep 2012 02:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 MqY-C-MAjCcr; Tue, 11 Sep 2012 02:50:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 260C221F8764; Tue, 11 Sep 2012 02:50:09 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id D40052640EB; Tue, 11 Sep 2012 11:50:08 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B3DA94C0C8; Tue, 11 Sep 2012 11:50:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 11 Sep 2012 11:50:04 +0200 From: To: "teemu.savolainen@nokia.com" , "simon.perreault@viagenie.ca" Date: Tue, 11 Sep 2012 11:50:03 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAAPxyvAAAq5H8ADA9/qg Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10BF4F@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620445C977@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620445C977@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "pcp@ietf.org" , "behave@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 09:50:11 -0000 Hi Teemu, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 >Envoy=E9 : vendredi 7 septembre 2012 15:17 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; simon.perreault@viagenie.ca >Cc : pcp@ietf.org; behave@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Hi, [...] > >> Med: I didn't asked for that. Sorry I was not clear: the=20 >scope of this discussion >> is: PCP-enabled networks. > >Thanks, in PCP-enabled networks it is definitely ok to skip=20 >heuristics in favor for explicit configuration.=20 > >If you do go forward with explicit option, you could look if=20 >you can resolve the "mapping of IPv4 address ranges to IPv6=20 >prefixes" problem. Something better perhaps than asking from=20 >PCP Server what is the Pref64::/n for a given IPv4 address.. Med: Thanks. I have just submited a new version which takes into account th= is comment. An OpCode is now supported to convey a list of {IPv4 subnet, P= refix64::/n}. The new version is available at: http://tools.ietf.org/html/d= raft-boucadair-pcp-nat64-prefix64-option-01 > >Best regards > > Teemu >= From mohamed.boucadair@orange.com Tue Sep 11 02:53:12 2012 Return-Path: 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 7129421F84B6 for ; Tue, 11 Sep 2012 02:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 qrbtxmLs7Zl4 for ; Tue, 11 Sep 2012 02:53:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BA66821F876A for ; Tue, 11 Sep 2012 02:53:11 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id A7A8D3B4349; Tue, 11 Sep 2012 11:53:10 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8A2AE35C0E5; Tue, 11 Sep 2012 11:53:10 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 11 Sep 2012 11:53:06 +0200 From: To: Simon Perreault Date: Tue, 11 Sep 2012 11:53:05 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgDvpJXw Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10BF57@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> In-Reply-To: <5048C127.50704@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.1.82415 Cc: "pcp@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 09:53:12 -0000 Hi Simon, I updated the draft with a new OpCode to retrieve the list of PREFIX64. The= new version is available at:=20 http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option-01=20 The new version includes also some comments from Reddy. Please feel free to comment the new version of the draft.=20 Cheers, Med >-----Message d'origine----- >De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 >Envoy=E9 : jeudi 6 septembre 2012 17:29 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : pcp@ietf.org >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : >> Med: I'm open to evaluate which approach is better: new opcode vs. >> new option. We need first to agree this is valid problem to solve. > >There is clearly a need to discover the NAT64 prefix: >draft-ietf-behave-nat64-learn-analysis >draft-ietf-behave-nat64-discovery-heuristic > >Note that the analysis draft does not consider PCP. Maybe it should.=20 >Looking at the list of pros and cons for DHCPv6, PCP would be=20 >different,=20 >and better in some aspects. > >Personally I would much prefer using PCP than the heuristic=20 >when PCP is=20 >available. > >Simon >--=20 >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 >= From dwing@cisco.com Tue Sep 11 10:08:02 2012 Return-Path: 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 AE59821F876A for ; Tue, 11 Sep 2012 10:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 tvtqvHqdozzs for ; Tue, 11 Sep 2012 10:08:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C9ED121F8738 for ; Tue, 11 Sep 2012 10:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2556; q=dns/txt; s=iport; t=1347383281; x=1348592881; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=qflSH7NthQuGSabdVaB0fV55I2GUxYqEDeL9OrrBGb4=; b=R4D6giEdKcITgm637nfVyfO0JyI0q21DU6A3vlbqJTU47pxlvkGq1wJJ 0GzPVyMV2N5VC+kWDgoj5gryRTmw7YnQ+Qx1pzMIQS6Xy/CtnYXoLiyoJ b4fY1CQFrqLMRYcq8IAkz4+AXy+rsmMI3vahySySOhlmiwu/NDAp07jtr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFADBvT1CrRDoI/2dsb2JhbABFq1mPeIEHgiABAQEDAQEBAQUKARQDRAsFBwEDAgkPAgQBASgHGQ4VCgkIAQEEARILF4doBQybI6BRixCGJgOIIDWFDokQjSKBZ4MG X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="55355037" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 11 Sep 2012 17:08:01 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8BH81am022652; Tue, 11 Sep 2012 17:08:01 GMT From: "Dan Wing" To: , "'Simon Perreault'" References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E5A10BF57@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5A10BF57@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 11 Sep 2012 10:08:00 -0700 Message-ID: <074001cd903f$ffc7b570$ff572050$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgDvpJXwAA8wn6A= Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:08:02 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Tuesday, September 11, 2012 2:53 AM > To: Simon Perreault > Cc: pcp@ietf.org > Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp- > nat64-prefix64-option >=20 > Hi Simon, >=20 > I updated the draft with a new OpCode to retrieve the list of = PREFIX64. > The new version is available at: > http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option- > 01 >=20 > The new version includes also some comments from Reddy. >=20 > Please feel free to comment the new version of the draft. Thanks for the draft showing both choices. The message flow for the new PCP Opcode implies there is always an additional round trip. There is only an additional round-trip if MAP (or PEER) is used. If, on the other hand, the host only needed to learn the NAT64 prefix (and then it set up a TCP=20 connection), the number of messages on the network is exactly the same for the MAP option or the new Opcode, assuming the PCP client simply leaves the dangling MAP-created mapping until its Lifetime expires. -d > Cheers, > Med >=20 >=20 > >-----Message d'origine----- > >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] > >Envoy=E9 : jeudi 6 septembre 2012 17:29 > >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > >Cc : pcp@ietf.org > >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: > >draft-boucadair-pcp-nat64-prefix64-option > > > >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : > >> Med: I'm open to evaluate which approach is better: new opcode vs. > >> new option. We need first to agree this is valid problem to solve. > > > >There is clearly a need to discover the NAT64 prefix: > >draft-ietf-behave-nat64-learn-analysis > >draft-ietf-behave-nat64-discovery-heuristic > > > >Note that the analysis draft does not consider PCP. Maybe it should. > >Looking at the list of pros and cons for DHCPv6, PCP would be > >different, > >and better in some aspects. > > > >Personally I would much prefer using PCP than the heuristic > >when PCP is > >available. > > > >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 From simon.perreault@viagenie.ca Tue Sep 11 10:12:44 2012 Return-Path: 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 DCF0C21F84B9 for ; Tue, 11 Sep 2012 10:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 67vrlRkkM8Lj for ; Tue, 11 Sep 2012 10:12:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4187B21F8498 for ; Tue, 11 Sep 2012 10:12:44 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:1d7c:5db4:d43e:122c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 64AB445BCC; Tue, 11 Sep 2012 13:12:38 -0400 (EDT) Message-ID: <504F7105.6010108@viagenie.ca> Date: Tue, 11 Sep 2012 13:12:37 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Dan Wing References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E5A10BF57@PUEXCB1B.nanterre.francetelecom.fr> <074001cd903f$ffc7b570$ff572050$@com> In-Reply-To: <074001cd903f$ffc7b570$ff572050$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:12:45 -0000 Le 2012-09-11 13:08, Dan Wing a écrit : > The message flow for the new PCP Opcode implies there is always > an additional round trip. There is only an additional round-trip > if MAP (or PEER) is used. If, on the other hand, the host only > needed to learn the NAT64 prefix (and then it set up a TCP > connection), the number of messages on the network is exactly > the same for the MAP option or the new Opcode, assuming the PCP > client simply leaves the dangling MAP-created mapping until its > Lifetime expires. Can't the two opcodes be sent simultaneously? No need to wait for one request to finish before starting another one... 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 From dwing@cisco.com Tue Sep 11 10:26:33 2012 Return-Path: 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 0F31721F87CB for ; Tue, 11 Sep 2012 10:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 r+CJi721VMGw for ; Tue, 11 Sep 2012 10:26:31 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C19AF21F87DC for ; Tue, 11 Sep 2012 10:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1348; q=dns/txt; s=iport; t=1347384391; x=1348593991; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=KkHlFoq19R2kjSxiBhbX/p56phChaNwm9s798Rsrn70=; b=W6BqkopHdEQUJGXISIvtn+RPnepz7xuzPbAYxN3OEfmm1ELHpBfkQQDl U0xPyAn0YAAfHBMOjM5CX3Ovn549g84w0bG6TwXpIeIWVNw42GwS39e3x VUONhfjxOjjfPF0HBrj2+q48h2UWVnzdZZiq0qtbTQ8ZGbC/rujK87HpS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAItzT1CrRDoI/2dsb2JhbABFq1mPeIEHgiABAQEDAQgKARQDQwwFBwEDAgkPAgQBASgHGSMKCQgBAQQTCxeHaAWbLaBUixCGJgOIIDWFDokQjSKBZ4MG X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="57855758" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 11 Sep 2012 17:26:31 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8BHQVTL031289; Tue, 11 Sep 2012 17:26:31 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E5A10BF57@PUEXCB1B.nanterre.francetelecom.fr> <074001cd903f$ffc7b570$ff572050$@com> <504F7105.6010108@viagenie.ca> In-Reply-To: <504F7105.6010108@viagenie.ca> Date: Tue, 11 Sep 2012 10:26:30 -0700 Message-ID: <074f01cd9042$955ddbd0$c0199370$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2QQKci+B2cVOFFTv66XA5CYpjtWwAAaSQw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:26:33 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Tuesday, September 11, 2012 10:13 AM > To: Dan Wing > Cc: mohamed.boucadair@orange.com; pcp@ietf.org > Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp- > nat64-prefix64-option >=20 > Le 2012-09-11 13:08, Dan Wing a =E9crit : > > The message flow for the new PCP Opcode implies there is always > > an additional round trip. There is only an additional round-trip > > if MAP (or PEER) is used. If, on the other hand, the host only > > needed to learn the NAT64 prefix (and then it set up a TCP > > connection), the number of messages on the network is exactly > > the same for the MAP option or the new Opcode, assuming the PCP > > client simply leaves the dangling MAP-created mapping until its > > Lifetime expires. >=20 > Can't the two opcodes be sent simultaneously? No need to wait for one > request to finish before starting another one... Good point. Learning the PREFIX64 can actually be deferred, as=20 knowing the PREFIX64 is not time critical to sending the SIP INVITE. -d > 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 From mohamed.boucadair@orange.com Tue Sep 11 22:17:45 2012 Return-Path: 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 4F09121E8054 for ; Tue, 11 Sep 2012 22:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 iq4DP+FcXUTD for ; Tue, 11 Sep 2012 22:17:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6321E8051 for ; Tue, 11 Sep 2012 22:17:43 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 296DD3B43F7; Wed, 12 Sep 2012 07:17:39 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0CAE623808D; Wed, 12 Sep 2012 07:17:39 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 12 Sep 2012 07:17:34 +0200 From: To: Dan Wing , 'Simon Perreault' Date: Wed, 12 Sep 2012 07:17:32 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgDvpJXwAA8wn6AAGWeaIA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10C1AD@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E5A10BF57@PUEXCB1B.nanterre.francetelecom.fr> <074001cd903f$ffc7b570$ff572050$@com> In-Reply-To: <074001cd903f$ffc7b570$ff572050$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.12.40324 Cc: "pcp@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 05:17:45 -0000 Hi Dan,=20 Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Dan Wing [mailto:dwing@cisco.com]=20 >Envoy=E9 : mardi 11 septembre 2012 19:08 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Simon Perreault' >Cc : pcp@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Tuesday, September 11, 2012 2:53 AM >> To: Simon Perreault >> Cc: pcp@ietf.org >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp- >> nat64-prefix64-option >>=20 >> Hi Simon, >>=20 >> I updated the draft with a new OpCode to retrieve the list=20 >of PREFIX64. >> The new version is available at: >> =20 >http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option- >> 01 >>=20 >> The new version includes also some comments from Reddy. >>=20 >> Please feel free to comment the new version of the draft. > >Thanks for the draft showing both choices. > >The message flow for the new PCP Opcode implies there is always >an additional round trip. Med: This is only an example for this particular case. I added a new flow e= xample when no MAP is needed. There is only an additional round-trip >if MAP (or PEER) is used. If, on the other hand, the host only >needed to learn the NAT64 prefix (and then it set up a TCP=20 >connection), the number of messages on the network is exactly >the same for the MAP option or the new Opcode, assuming the PCP >client simply leaves the dangling MAP-created mapping until its >Lifetime expires. Med: Fully agree. Note another order may be followed to send the requests i= n the examples of the draft. The purpose is to show how it works not to com= pare the opcode vs option at this stage.=20 > >-d > > > >> Cheers, >> Med >>=20 >>=20 >> >-----Message d'origine----- >> >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] >> >Envoy=E9 : jeudi 6 septembre 2012 17:29 >> >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> >Cc : pcp@ietf.org >> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: >> >draft-boucadair-pcp-nat64-prefix64-option >> > >> >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a =E9crit : >> >> Med: I'm open to evaluate which approach is better: new opcode vs. >> >> new option. We need first to agree this is valid problem to solve. >> > >> >There is clearly a need to discover the NAT64 prefix: >> >draft-ietf-behave-nat64-learn-analysis >> >draft-ietf-behave-nat64-discovery-heuristic >> > >> >Note that the analysis draft does not consider PCP. Maybe it should. >> >Looking at the list of pros and cons for DHCPv6, PCP would be >> >different, >> >and better in some aspects. >> > >> >Personally I would much prefer using PCP than the heuristic >> >when PCP is >> >available. >> > >> >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 > >= From mohamed.boucadair@orange.com Tue Sep 11 22:20:58 2012 Return-Path: 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 9BA2321E8082 for ; Tue, 11 Sep 2012 22:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 h9WXawdY-oLa for ; Tue, 11 Sep 2012 22:20:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9E79621E8064 for ; Tue, 11 Sep 2012 22:20:57 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 1D64C324538; Wed, 12 Sep 2012 07:20:56 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 02CE84C027; Wed, 12 Sep 2012 07:20:56 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 12 Sep 2012 07:20:51 +0200 From: To: Simon Perreault , Dan Wing Date: Wed, 12 Sep 2012 07:20:49 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2QQKPFgvBkc+cXSMeqKN1bVU5WqAAZVIjQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10C1B0@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E5A10BF57@PUEXCB1B.nanterre.francetelecom.fr> <074001cd903f$ffc7b570$ff572050$@com> <504F7105.6010108@viagenie.ca> In-Reply-To: <504F7105.6010108@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.12.40324 Cc: "pcp@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 05:20:58 -0000 Hi Simon, You are right. There is no need to wait. Another order to issue the request= s can be used in the flow examples.=20 I added a note to the draft. Cheers, Med >-----Message d'origine----- >De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 >Envoy=E9 : mardi 11 septembre 2012 19:13 >=C0 : Dan Wing >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >Le 2012-09-11 13:08, Dan Wing a =E9crit : >> The message flow for the new PCP Opcode implies there is always >> an additional round trip. There is only an additional round-trip >> if MAP (or PEER) is used. If, on the other hand, the host only >> needed to learn the NAT64 prefix (and then it set up a TCP >> connection), the number of messages on the network is exactly >> the same for the MAP option or the new Opcode, assuming the PCP >> client simply leaves the dangling MAP-created mapping until its >> Lifetime expires. > >Can't the two opcodes be sent simultaneously? No need to wait for one=20 >request to finish before starting another one... > >Simon >--=20 >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 >= From mohamed.boucadair@orange.com Wed Sep 12 00:28:12 2012 Return-Path: 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 D1E6E21F8581 for ; Wed, 12 Sep 2012 00:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 PFvT5NEO05f7 for ; Wed, 12 Sep 2012 00:28:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 129E221F856D for ; Wed, 12 Sep 2012 00:28:11 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id CCFB02641FF; Wed, 12 Sep 2012 09:28:10 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id ADCE44C0EE; Wed, 12 Sep 2012 09:28:10 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 12 Sep 2012 09:28:05 +0200 From: To: Dan Wing , 'Simon Perreault' Date: Wed, 12 Sep 2012 09:28:04 +0200 Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac2QQKci+B2cVOFFTv66XA5CYpjtWwAAaSQwAB1FNSA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10C231@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E5A10BF57@PUEXCB1B.nanterre.francetelecom.fr> <074001cd903f$ffc7b570$ff572050$@com> <504F7105.6010108@viagenie.ca> <074f01cd9042$955ddbd0$c0199370$@com> In-Reply-To: <074f01cd9042$955ddbd0$c0199370$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.12.55416 Cc: "pcp@ietf.org" Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 07:28:12 -0000 Re-, I updated the draft with these changes: * Add new flow example showing a TCP session * clarify the requests can be sent using another order. FWIW, the diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-bo= ucadair-pcp-nat64-prefix64-option-02. If the WG accepts to work on this draft, I plan to remove all the flow exam= ples from the draft and focus on the specification part. Cheers Med=20 >-----Message d'origine----- >De : Dan Wing [mailto:dwing@cisco.com]=20 >Envoy=E9 : mardi 11 septembre 2012 19:27 >=C0 : 'Simon Perreault' >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp-nat64-prefix64-option > >> -----Original Message----- >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >> Sent: Tuesday, September 11, 2012 10:13 AM >> To: Dan Wing >> Cc: mohamed.boucadair@orange.com; pcp@ietf.org >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64:=20 >draft-boucadair-pcp- >> nat64-prefix64-option >>=20 >> Le 2012-09-11 13:08, Dan Wing a =E9crit : >> > The message flow for the new PCP Opcode implies there is always >> > an additional round trip. There is only an additional round-trip >> > if MAP (or PEER) is used. If, on the other hand, the host only >> > needed to learn the NAT64 prefix (and then it set up a TCP >> > connection), the number of messages on the network is exactly >> > the same for the MAP option or the new Opcode, assuming the PCP >> > client simply leaves the dangling MAP-created mapping until its >> > Lifetime expires. >>=20 >> Can't the two opcodes be sent simultaneously? No need to wait for one >> request to finish before starting another one... > >Good point. Learning the PREFIX64 can actually be deferred, as=20 >knowing the PREFIX64 is not time critical to sending the SIP INVITE. > >-d > > >> 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 > >= From tireddy@cisco.com Wed Sep 12 07:06:54 2012 Return-Path: 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 5A0D121F862B for ; Wed, 12 Sep 2012 07:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] 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 87pAszs4++cc for ; Wed, 12 Sep 2012 07:06:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D656721F860E for ; Wed, 12 Sep 2012 07:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7388; q=dns/txt; s=iport; t=1347458807; x=1348668407; h=from:to:cc:subject:date:message-id:mime-version; bh=oRFohQnOEBMlDdL5oxQn/WZo1gV+3zAQfPBWz3OqZ5M=; b=gSJSB09PPy1rPmfu0zDwl/g2lJ0u70PAZt9SX10yiz9hqqoHljAjyQ8D HaQJJQzfpvsKeybuwOeOmDRSX1WmQfB7EQ5/dAtsyYU0BegZZqZEPp3R9 g0suG6faTXN33MFpkKSbokq82iAoZyEyD3irbaA/107UXzv3N6GpSc0Bf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOyVUFCtJV2Y/2dsb2JhbABFgku4dYEHgiIBBBIBGkwSASpWJgEEDg0ah2ucL6BEkHJgA6QVgWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208,217";a="120834089" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 12 Sep 2012 14:06:47 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8CE6lak007093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 14:06:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 09:06:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" Thread-Topic: Review of draft-ietf-pcp-upnp-igd-interworking Thread-Index: Ac2Q79Y6YXBrvo9gTweL2JiIKG8WUg== Date: Wed, 12 Sep 2012 14:06:45 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147A3B2F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.28.146] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005 x-tm-as-result: No--35.283800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A147A3B2Fxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:06:54 -0000 --_000_913383AAA69FF945B8F946018B75898A147A3B2Fxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Med - [1] Section 5.8 If the port is not in use, the mapping will be created by the PCP Server and a positive response will be sent back to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay a negative message to the UPnP Control Point indicating NoSuchEntryInArray as error code. Comment> Should the IGD-PCP IWF delete the MAP binding after this operation= ? [2] Section 5.9 A PCP MAP delete response is sent back if the removal of the correspondin= g entry was successful; if not, a PCP Error is sent back to the IGD-PCP Interworking Function including the corresponding error cause (See Section 4.3). comment > you may want to conclude that the corresponding success/error cod= es will be returned to the UPnP Control Point. [3]Section 5.9 It is unlikely to encounter a problem in the PCP leg because the IWF has verified authorization rights and also the presence of the mapping in the local table. Comment> Just a corner case, What if the PCP server crashes or loses its st= ate after only processing the first request ? [4]Section 5.10 In case an error is encountered during mapping renewal, the IGD-PCP Interworking Function has no means to inform the UPnP CP. Comment > why not set PortMappingLeaseDuration to the lifetime value return= ed by the PCP server ? [5] For Security considerations - If the UPnP supports PCP interworking fun= ction then it should block internal hosts from sending PCP requests to the = PCP server directly. Generic error cases : [6] What if NAT2 just supports or permits PEER and not MAP request ? [7] what will IGD-PCP do if it receives ANNOUNCE from NAT2 ? --Tiru. --_000_913383AAA69FF945B8F946018B75898A147A3B2Fxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Med –

 

[1] Section 5.8

   If the port is not in use, the mapping = will be

   created by the PCP Server and a positiv= e response will be sent back

   to the IGD-PCP IWF.  Once received= by the IGD-PCP IWF, it MUST relay

   a negative message to the UPnP Control = Point indicating

   NoSuchEntryInArray as error code.<= /o:p>

 

Comment> Should the IGD-PCP IWF delete the MAP bi= nding after this operation ?

 

[2] Section 5.9

  A PCP MAP delete response is sent back if the= removal of the corresponding

  entry was successful; if not, a PCP Error is = sent back to the IGD-PCP

  Interworking Function including the correspon= ding error cause (See

  Section 4.3).

 

comment > you may want to conclude that the corre= sponding success/error codes will be returned to the UPnP Control Point.

 

[3]Section 5.9

 

      It is unlikely to enc= ounter a problem in the PCP leg

      because the IWF has v= erified authorization rights and also the

      presence of the mappi= ng in the local table.

 

Comment> Just a corner case, What if the PCP serv= er crashes or loses its state after only processing the first request ?

 

[4]Section 5.10

 

   In case an error is encountered during = mapping renewal, the IGD-PCP

   Interworking Function has no means to i= nform the UPnP CP.

 

Comment > why not set PortMappingLeaseDuration to= the lifetime value returned by the PCP server ?

 

[5] For Security considerations - If the UPnP suppor= ts PCP interworking function then it should block internal hosts from sendi= ng PCP requests to the PCP server directly.

 

Generic error cases :

 

[6] What if NAT2 just supports or permits PEER and n= ot MAP request ?

[7] what will IGD-PCP do if it receives ANNOUNCE fro= m NAT2 ?

 

--Tiru.

--_000_913383AAA69FF945B8F946018B75898A147A3B2Fxmbrcdx10ciscoc_-- From mohamed.boucadair@orange.com Wed Sep 12 08:08:08 2012 Return-Path: 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 45FD621F855E for ; Wed, 12 Sep 2012 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] 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 PbZNcAOrZMwA for ; Wed, 12 Sep 2012 08:08:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DAA6121F854E for ; Wed, 12 Sep 2012 08:08:06 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 9A2C918C494; Wed, 12 Sep 2012 17:08:05 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7EC9735C120; Wed, 12 Sep 2012 17:08:05 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 12 Sep 2012 17:08:00 +0200 From: To: "Tirumaleswar Reddy (tireddy)" Date: Wed, 12 Sep 2012 17:07:59 +0200 Thread-Topic: Review of draft-ietf-pcp-upnp-igd-interworking Thread-Index: Ac2Q79Y6YXBrvo9gTweL2JiIKG8WUgAAhB6Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10C498@PUEXCB1B.nanterre.francetelecom.fr> References: <913383AAA69FF945B8F946018B75898A147A3B2F@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A147A3B2F@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E5A10C498PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.1.82415 Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:08:08 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5A10C498PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Reddy, Thanks for the review. Please see inline. Cheers, Med ________________________________ De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : mercredi 12 septembre 2012 16:07 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : pcp@ietf.org Objet : Review of draft-ietf-pcp-upnp-igd-interworking Hi Med - [1] Section 5.8 If the port is not in use, the mapping will be created by the PCP Server and a positive response will be sent back to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay a negative message to the UPnP Control Point indicating NoSuchEntryInArray as error code. Comment> Should the IGD-PCP IWF delete the MAP binding after this operation= ? [Med] No. the IGD CP is supposed to issue AddPortMapping() for that specifi= c mapping. The request will be honored by the PCP server (after being relay= ed by the IWF). The behaviour of the IGD CP is out of scope. There is a not= e about this in the draft: Note: According to some experiments, some UPnP 1.0 implementations, e.g., uTorrent, simply try the same external port X times (usually 4 times) and then fail. Also note that some applications uses GetSpecificPortMapping() to check whether a mapping exists. Do you think the note need be updated? [2] Section 5.9 A PCP MAP delete response is sent back if the removal of the correspondin= g entry was successful; if not, a PCP Error is sent back to the IGD-PCP Interworking Function including the corresponding error cause (See Section 4.3). comment > you may want to conclude that the corresponding success/error cod= es will be returned to the UPnP Control Point. [Med] The behaviour of the iwf is already captured in "and notifies the UP= nP Control Point about the result of the removal operation.". [3]Section 5.9 It is unlikely to encounter a problem in the PCP leg because the IWF has verified authorization rights and also the presence of the mapping in the local table. Comment> Just a corner case, What if the PCP server crashes or loses its st= ate after only processing the first request ? [Med] In that case, the server will return SUCCESS as the mapping does not = exist. [4]Section 5.10 In case an error is encountered during mapping renewal, the IGD-PCP Interworking Function has no means to inform the UPnP CP. Comment > why not set PortMappingLeaseDuration to the lifetime value return= ed by the PCP server ? [Med] this variable state must have the same value as the one included in a= ddportmapping() action issued by the CP. [5] For Security considerations - If the UPnP supports PCP interworking fun= ction then it should block internal hosts from sending PCP requests to the = PCP server directly. [Med] Do you mean the UPnP CP? Generic error cases : [6] What if NAT2 just supports or permits PEER and not MAP request ? [Med] the IWF will fail to open mappings. I can add a sentence like "This s= pecification assumes the PCP Server is configured to accept MAP OpCode". Do= we need to say more? [7] what will IGD-PCP do if it receives ANNOUNCE from NAT2 ? [Med] The question can be extended to other failure cases. We have some te= xts spread in several I-Ds: http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#section-2.6 or adapt the text from http://tools.ietf.org/html/draft-boucadair-pcp-failu= re-04#section-2.7.6.2 We have two options: (1) mention ANNOUNCE handling is out of scope and cover this in detail in t= he failure draft (2) add a section to specify the behaviour in the draft. Which option do you prefer? --Tiru. --_000_94C682931C08B048B7A8645303FDC9F36E5A10C498PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Reddy,
 
Thanks for the review.
 
Please see inline.
 
Cheers,
Med

De : Tirumaleswar Reddy (tireddy= )=20 [mailto:tireddy@cisco.com]
Envoy=E9 : mercredi 12 septemb= re 2012=20 16:07
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc := =20 pcp@ietf.org
Objet : Review of=20 draft-ietf-pcp-upnp-igd-interworking

Hi Med =96

 

[1] Section 5.8

   If the port is not in use, the mapping = will=20 be

   created by the PCP Server and a positiv= e=20 response will be sent back

   to the IGD-PCP IWF.  Once received= by the=20 IGD-PCP IWF, it MUST relay

   a negative message to the UPnP Control = Point=20 indicating

   NoSuchEntryInArray as error=20 code.

 

Comment> Should the IGD-PCP IWF delete the MAP bi= nding=20 after this operation ?
[Med] No. the IGD CP is supposed to is= sue=20 AddPortMapping() for that specific mapping. The request will be honored b= y the=20 PCP server (after being relayed by the IWF). The behaviour of the IGD CP = is=20 out of scope. There is a note about this in the draft:

 

      Note: According to some=20 experiments, some UPnP 1.0
      implementati= ons,=20 e.g., uTorrent, simply try the same external=20 port
      X times (usually 4 times) and then= =20 fail.  Also note that some
      applica= tions=20 uses GetSpecificPortMapping() to check whether=20 a
      mapping exists.

 

= Do you think the note need = be=20 updated?

 

[2] Section 5.9

  A PCP MAP delete response is sent back if the= =20 removal of the corresponding

  entry was successful; if not, a PCP Error is = sent=20 back to the IGD-PCP

  Interworking Function including the correspon= ding=20 error cause (See

  Section 4.3).

 

comment > you may want to conclude that the=20 corresponding success/error codes will be returned to the UPnP Control=20 Point.
[Med]  The behaviour of the iwf = is=20 already captured in "and notifies the UPnP Control Point about the result= of=20 the
   removal operation.".

 

[3]Section 5.9

 

      It is unlikely to enc= ounter=20 a problem in the PCP leg

      because the IWF has v= erified=20 authorization rights and also the

      presence of the mappi= ng in=20 the local table.

 

Comment> Just a corner case, What if the PCP serv= er=20 crashes or loses its state after only processing the first request ?
<= SPAN=20 class=3D615292114-12092012>[Med] In that case, the server will return SUCC= ESS as=20 the mapping does not exist.   

 

[4]Section 5.10

 

   In case an error is encountered during = mapping=20 renewal, the IGD-PCP

   Interworking Function has no means to i= nform=20 the UPnP CP.

 

Comment > why not set PortMappingLeaseDuration to= the=20 lifetime value returned by the PCP server ?
[Med]=20 this variable state must have the same value as the one included in=20 addportmapping() action issued by the CP.

 

[5] For Security considerations - If the UPnP suppor= ts PCP=20 interworking function then it should block internal hosts from sending PC= P=20 requests to the PCP server directly.
= [Med] Do you mean the = UPnP=20 CP? 

 

Generic error cases :

 

[6] What if NAT2 just supports or permits PEER and n= ot MAP=20 request ?
[Med] the IWF will fail to open mappings. I can= add a=20 sentence like "This specification assumes the PCP Server is configured to= =20 accept MAP OpCode". Do we need to say more?

 <= /o:p>

[7] what will IGD-PCP do if it receives ANNOUNCE fro= m NAT2=20 ?
[Med]  The question can be extended to other fa= ilure=20 cases. We have some texts spread in several I-Ds:

http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#section-2.6=

or adapt the text from http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#section= -2.7.6.2

 

We have=20 two options:

(1) mention ANNOUNCE handling is out of scope a= nd=20 cover this in detail in the failure draft

(2) add a section to specify the behaviour in t= he=20 draft.

 

Which option do you prefer?

 

 

--Tiru.

--_000_94C682931C08B048B7A8645303FDC9F36E5A10C498PUEXCB1Bnante_-- From tireddy@cisco.com Wed Sep 12 11:05:08 2012 Return-Path: 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 2727C21F8554 for ; Wed, 12 Sep 2012 11:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] 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 GfmxAV+Xojrd for ; Wed, 12 Sep 2012 11:04:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 12D8521F8533 for ; Wed, 12 Sep 2012 11:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20535; q=dns/txt; s=iport; t=1347473099; x=1348682699; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=upWwBjZ0dcdAoq8FM3wo/XrMLSJ8rf+myiuSg8BWorE=; b=g6YJfzSjea0nEbCkSYWH/jEGcJFlgCHkhEhNV2aUaw3s3/ORsiiwY0HO sDGcnYGiYInGwefDTa7kaRiRkp8I0i+RDMCMjHhC8AzAj+c1us1IUsZSB SRw+mWAANWopHzbSEYAuJ7EInzLqC9YOP8cYacTSKysad6s1gzcZXenOX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOfNUFCtJXHB/2dsb2JhbABFgkuwLAGIVoEHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAEBBA4FCBqHawubeKAwixCFYmADiCCOU40igWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208,217";a="120905499" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 12 Sep 2012 18:04:58 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8CI4wn2005692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 18:04:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 13:04:57 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" Thread-Topic: Review of draft-ietf-pcp-upnp-igd-interworking Thread-Index: Ac2Q79Y6YXBrvo9gTweL2JiIKG8WUgAAhB6QAAan4mA= Date: Wed, 12 Sep 2012 18:04:56 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147A40BC@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A147A3B2F@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36E5A10C498@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5A10C498@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.84.98] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005 x-tm-as-result: No--55.059900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A147A40BCxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 18:05:08 -0000 --_000_913383AAA69FF945B8F946018B75898A147A40BCxmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med - Please see inline [Tiru] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, September 12, 2012 8:38 PM To: Tirumaleswar Reddy (tireddy) Cc: pcp@ietf.org Subject: RE: Review of draft-ietf-pcp-upnp-igd-interworking Hi Reddy, Thanks for the review. Please see inline. Cheers, Med ________________________________ De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : mercredi 12 septembre 2012 16:07 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : pcp@ietf.org Objet : Review of draft-ietf-pcp-upnp-igd-interworking Hi Med - [1] Section 5.8 If the port is not in use, the mapping will be created by the PCP Server and a positive response will be sent back to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay a negative message to the UPnP Control Point indicating NoSuchEntryInArray as error code. Comment> Should the IGD-PCP IWF delete the MAP binding after this operation= ? [Med] No. the IGD CP is supposed to issue AddPortMapping() for that specifi= c mapping. The request will be honored by the PCP server (after being relay= ed by the IWF). The behaviour of the IGD CP is out of scope. There is a not= e about this in the draft: [Tiru] For failure case of PCP cannot allocate external port, PCP will r= eturn error code CANNOT_PROVIDE_EXTERNAL, and IGD-PCP IWF is supposed to re= turn negative message NoSuchEntryInArray. Probably you may want to say "Once CANNOT_PROVIDE_EXTERNAL is received by t= he IGD-PCP IWF..." Note: According to some experiments, some UPnP 1.0 implementations, e.g., uTorrent, simply try the same external port X times (usually 4 times) and then fail. Also note that some applications uses GetSpecificPortMapping() to check whether a mapping exists. Do you think the note need be updated? [Tiru] No [2] Section 5.9 A PCP MAP delete response is sent back if the removal of the correspondin= g entry was successful; if not, a PCP Error is sent back to the IGD-PCP Interworking Function including the corresponding error cause (See Section 4.3). comment > you may want to conclude that the corresponding success/error cod= es will be returned to the UPnP Control Point. [Med] The behaviour of the iwf is already captured in "and notifies the UP= nP Control Point about the result of the removal operation.". [Tiru] ok [3]Section 5.9 It is unlikely to encounter a problem in the PCP leg because the IWF has verified authorization rights and also the presence of the mapping in the local table. Comment> Just a corner case, What if the PCP server crashes or loses its st= ate after only processing the first request ? [Med] In that case, the server will return SUCCESS as the mapping does not = exist. [Tiru] ok [4]Section 5.10 In case an error is encountered during mapping renewal, the IGD-PCP Interworking Function has no means to inform the UPnP CP. Comment > why not set PortMappingLeaseDuration to the lifetime value return= ed by the PCP server ? [Med] this variable state must have the same value as the one included in a= ddportmapping() action issued by the CP. [Tiru] ok [5] For Security considerations - If the UPnP supports PCP interworking fun= ction then it should block internal hosts from sending PCP requests to the = PCP server directly. [Med] Do you mean the UPnP CP? [Tiru] yes Generic error cases : [6] What if NAT2 just supports or permits PEER and not MAP request ? [Med] the IWF will fail to open mappings. I can add a sentence like "This s= pecification assumes the PCP Server is configured to accept MAP OpCode". Do= we need to say more? [Tiru] This is fine. [7] what will IGD-PCP do if it receives ANNOUNCE from NAT2 ? [Med] The question can be extended to other failure cases. We have some te= xts spread in several I-Ds: http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#section-2.6 or adapt the text from http://tools.ietf.org/html/draft-boucadair-pcp-failu= re-04#section-2.7.6.2 We have two options: (1) mention ANNOUNCE handling is out of scope and cover this in detail in t= he failure draft (2) add a section to specify the behaviour in the draft. Which option do you prefer? [Tiru] If you are planning to address it in failure draft, I am fine with = both options. --Tiru. --_000_913383AAA69FF945B8F946018B75898A147A40BCxmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med –

 

Please see inline [Tir= u]

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, September 12, 2012 8:38 PM
To: Tirumaleswar Reddy (tireddy)
Cc: pcp@ietf.org
Subject: RE: Review of draft-ietf-pcp-upnp-igd-interworking

 

Hi Reddy,

 

Thanks for the review.

 

Please see inline.

 

Cheers,

Med

 

De : Tirumaleswar Reddy (tire= ddy) [mailto:tireddy@cisco.com]
Envoy=E9 : mercredi 12 septembre 2012 16:07
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : pcp@ietf.org
Objet : Review of draft-ietf-pcp-upnp-igd-interworking

Hi Med –

 

[1] Section 5.8

   If the port is not in use, the mapping = will be

   created by the PCP Server and a positiv= e response will be sent back

   to the IGD-PCP IWF.  Once received= by the IGD-PCP IWF, it MUST relay

   a negative message to the UPnP Control = Point indicating

   NoSuchEntryInArray as error code.<= /o:p>

 

Comment> Should the IGD-PCP IWF delete the MAP bi= nding after this operation ?
[Med] No. the IGD CP is supposed to issue AddPortMapping() for th= at specific mapping. The request will be honored by the PCP server (after b= eing relayed by the IWF). The behaviour of the IGD CP is out of scope. There is a note about this in the draft:

 

 [Tiru]  For= failure case of PCP cannot allocate  external port, PCP will return e= rror code CANNOT_PROVIDE_EXTERNAL, and IGD-PCP IWF is supposed to return ne= gative message NoSuchEntryInArray.

Probably you may want = to say “Once CANNOT_PROVIDE_EXTERNAL is received by the IG= D-PCP IWF…”

 

 

      Note: According to some experime= nts, some UPnP 1.0
      implementations, e.g., uTorrent, simply try = the same external port
      X times (usually 4 times) and then fail.&nbs= p; Also note that some
      applications uses GetSpecificPortMapping() t= o check whether a
      mapping exists.

 <= /p>

Do you think the note need be updated?

[Tiru] No

 

[2] Section 5.9

  A PCP MAP delete response is sent back if the= removal of the corresponding

  entry was successful; if not, a PCP Error is = sent back to the IGD-PCP

  Interworking Function including the correspon= ding error cause (See

  Section 4.3).

 

comment > you may want to conclude that the corre= sponding success/error codes will be returned to the UPnP Control Point. [Med]  The behaviour of the iwf is already capture= d in "and notifies the UPnP Control Point about the result of the
   removal operation.".

[Tiru] ok

 

[3]Section 5.9

 

      It is unlikely to enc= ounter a problem in the PCP leg

      because the IWF has v= erified authorization rights and also the

      presence of the mappi= ng in the local table.

 

Comment> Just a corner case, What if the PCP serv= er crashes or loses its state after only processing the first request ?
[Med] In that case, the server will return SUCCESS as the mapping= does not exist.   

[Tiru] ok

 

[4]Section 5.10

 

   In case an error is encountered during = mapping renewal, the IGD-PCP

   Interworking Function has no means to i= nform the UPnP CP.

 

Comment > why not set PortMappingLeaseDuration to= the lifetime value returned by the PCP server ?
[Med] this variable state must have the same value as the one included= in addportmapping() action issued by the CP.

[Tiru] ok

 

[5] For Security considerations - If the UPnP suppor= ts PCP interworking function then it should block internal hosts from sendi= ng PCP requests to the PCP server directly.
[Med] Do you mean the UPnP CP? 

[Tiru] yes<= /span>

 

Generic error cases :

 

[6] What if NAT2 just supports or permits PEER and n= ot MAP request ?
[Med] the IWF will fail to open mappings. I can add a sentence li= ke "This specification assumes the PCP Server is configured to accept = MAP OpCode". Do we need to say more?

[Tiru] This is fine.

 

[7] what will IGD-PCP do if it receives ANNOUNCE fro= m NAT2 ?
[Med]  The question can be extended to other failure cases. We ha= ve some texts spread in several I-Ds:

http://tools.ietf.org/html/draft-boucadair-pcp-failure-0= 4#section-2.6

or adapt the text from http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#section-2.7.6.2

 

We have two options:

(1) mention ANNOUNCE handling is out of scope and cover th= is in detail in the failure draft

(2) add a section to specify the behaviour in the draft.

 

Which option do you prefer?

 [Tiru] If you ar= e planning to address it in failure draft, I am fine with both options.

 

--Tiru.

--_000_913383AAA69FF945B8F946018B75898A147A40BCxmbrcdx10ciscoc_-- From dthaler@microsoft.com Wed Sep 12 15:48:12 2012 Return-Path: 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 042B821F853F for ; Wed, 12 Sep 2012 15:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.815 X-Spam-Level: X-Spam-Status: No, score=-103.815 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 QEe-nhnJ60Qc for ; Wed, 12 Sep 2012 15:48:09 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 76E2421F84FD for ; Wed, 12 Sep 2012 15:48:08 -0700 (PDT) Received: from mail36-am1-R.bigfish.com (10.3.201.226) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Sep 2012 22:48:07 +0000 Received: from mail36-am1 (localhost [127.0.0.1]) by mail36-am1-R.bigfish.com (Postfix) with ESMTP id 6207734006F for ; Wed, 12 Sep 2012 22:48:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VS-35(zz98dI9371Ic85fh1432Id6eah604Tzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh1155h) Received-SPF: pass (mail36-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail36-am1 (localhost.localdomain [127.0.0.1]) by mail36-am1 (MessageSwitch) id 1347490085704297_415; Wed, 12 Sep 2012 22:48:05 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.236]) by mail36-am1.bigfish.com (Postfix) with ESMTP id A9EEB300069 for ; Wed, 12 Sep 2012 22:48:05 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Sep 2012 22:48:04 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 12 Sep 2012 22:48:02 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 12 Sep 2012 15:48:02 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0318.003; Wed, 12 Sep 2012 15:48:02 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WG status on PCP authentication Thread-Index: Ac2ROKfBXzEGHHwwTde0XiHvgVohmQ== Date: Wed, 12 Sep 2012 22:48:01 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7B205ATK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] WG status on PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 22:48:12 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7B205ATK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to circle back on this now that the minutes are posted. Relevant snippets from the minutes: > Francis Dupont: How does this compare to just running PCP over DTLS? > > Margaret Wasserman: There is currently no draft written to specify how it > would work. You can't "just run" anything over DTLS. It's not that si= mple. Summary: we have not explicitly called a question about DTLS. Mainly because there's no proposal on the table. Lacking one with real support, the WG will go ahead with a proposal that has energy/interest behind it. > Alain Durand called for show of hands: > For single port: 23 > For two separate ports: 0 Clear consensus within the room, and I've seen no indication on the list th= at this consensus can't be considered confirmed based on the list discussion thus f= ar. > Alain Durand called for show of hands: > PCP-specific messages (PCP-specific encoding of authentication informatio= n): 5 > Tunneled PANA (embed PANA data within PCP options): 6/7 > Side-by-side (multiplex raw PANA packets and PCP packets over same port):= 5/6 > Don't care: 15 Room was basically evenly split between the approaches above, so no consensus yet, but only about half the WG cares. > Alain Durand called for show of hands: > PCP-specific encoding of authentication information: 5 > Some kind of PANA encapsulation: 10 or 11 In my view there was a rough consensus of the room, and so far the list dis= cussion hasn't changed this ratio in my view. > Dan Wing: request an interim meeting to discuss solutions, once they've b= een > fleshed out a little And that's the step we're doing next. The main comparison point we know a= bout is between Tunneled PANA vs Side-by-side PANA/PCP. We can also compare PCP-specific though it appears to already be in the minority. If there are= other new proposals to consider (DTLS or whatever) by then, we can, but so far the in= ertia seems to be primarily between the PANA variants. There does seem to be uncertainty about how they would actually work, so it's important that they= be fleshed out in enough detail that we can have informed discussion at the in= terim meeting. -Dave From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Alper= Yegin Sent: Friday, August 17, 2012 1:09 AM To: Margaret Wasserman Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote: Hi Dacheng, The conclusion from the meeting was that we will document all three approac= hes in our document: Could the chairs please declare what the meeting conclusions and next steps= are. Thanks. Alper - PCP Specific - PANA Encapsulated in PCP - PANA Demultiplexed with PCP on the same port Then, we will have an interim PCP conference call to discuss the trade-offs= and hopefully decide between them. Margaret On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: Have we got any conclusions on two approaches? Or we can just support the = two options in the draft for the moment and briefly compare their pros and = cons, can we? Cheers Dcheng From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Margaret Wass= erman Sent: Friday, August 10, 2012 3:21 AM To: Dan Wing Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: If I'm updating security policy on a firewall I want to be able to audit whether that actually happened. That requires authentication. You are saying a PCP client would only want to update firewall policies if the PCP server supports authentication, otherwise it would tell the user that it cannot enable the webcam, Internet-connected NAS, Internet-connected printer, etc.? I wont presume to guess what Sam is thinking... However, I am thinking that there will be some clients that are configured= to perform authentication for every request. For example, there is no rea= son for a PCP proxy, running in an environment where authentication is requ= ired to do a THIRD-PARTY request, to perform a useless round-trip for every= THIRD-PARTY request it issues. Margaret _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp --_000_9B57C850BB53634CACEC56EF4853FF653B7B205ATK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just to circle back on th= is now that the minutes are posted.

 <= /p>

Relevant snippets from th= e minutes:

> Francis Dupont: How = does this compare to just running PCP over DTLS?

> 

> Margaret Wasserman: = There is currently no draft written to specify how it

>    wo= uld work.  You can't "just run" anything over DTLS. It's not= that simple.

 <= /p>

Summary: we have not expl= icitly called a question about DTLS.   Mainly

because there’s no = proposal on the table.   Lacking one with real support,

the WG will go ahead with= a proposal that has energy/interest behind it.

 <= /p>

> Alain Durand called = for show of hands:

> For single port: 23<= o:p>

> For two separate por= ts: 0

 <= /p>

Clear consensus within th= e room, and I’ve seen no indication on the list that this<= /span>

consensus can’t be = considered confirmed based on the list discussion thus far.

 <= /p>

> Alain Durand called = for show of hands:

> PCP-specific message= s (PCP-specific encoding of authentication information): 5

> Tunneled PANA (embed= PANA data within PCP options): 6/7

> Side-by-side (multip= lex raw PANA packets and PCP packets over same port): 5/6=

> Don't care: 15<= /o:p>

 <= /p>

Room was basically evenly= split between the approaches above, so no

consensus yet, but only a= bout half the WG cares.

 <= /p>

> Alain Durand called = for show of hands:

> PCP-specific encodin= g of authentication information: 5

> Some kind of PANA en= capsulation: 10 or 11

 <= /p>

In my view there was a ro= ugh consensus of the room, and so far the list discussion

hasn’t changed this= ratio in my view.

 <= /p>

> Dan Wing: request an= interim meeting to discuss solutions, once they've been<= /p>

>    fl= eshed out a little

 <= /p>

And that’s the step= we’re doing next.   The main comparison point we know abou= t

is between Tunneled PANA = vs Side-by-side PANA/PCP.   We can also compare=

PCP-specific though it ap= pears to already be in the minority.  If there are other new

proposals to consider (DT= LS or whatever) by then, we can, but so far the inertia

seems to be primarily bet= ween the PANA variants.   There does seem to be

uncertainty about how the= y would actually work, so it’s important that they be

fleshed out in enough det= ail that we can have informed discussion at the interim

meeting.

 <= /p>

-Dave

 <= /p>

From: pcp-boun= ces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Friday, August 17, 2012 1:09 AM
To: Margaret Wasserman
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP authentication

 

 

On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrot= e:



 

 

Hi Dacheng,

 

The conclusion from the meeting was that we will doc= ument all three approaches in our document:

 

 

Could the chairs please declare what the meeting con= clusions and next steps are.

 

Thanks.

 

Alper

 

 

 



- PCP Specific

- PANA Encapsulated in PCP

- PANA Demultiplexed with PCP on the same port<= /o:p>

 

Then, we will have an interim PCP conference call to= discuss the trade-offs and hopefully decide between them.

 

Margaret

 

 

 

On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng)= wrote:



From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Margaret W= asserman
Sent: Friday, Augu= st 10, 2012 3:21 AM
To: Dan Wing
Cc: pcp@ietf.org
Subject: Re: [pcp]= Comparison of PCP authentication

 

 

On Aug 9,= 2012, at 2:32 PM, Dan Wing wrote:

 

If I'm up= dating security policy on a firewall I want to be able to=

audit whe= ther that actually happened.  That requires authentication.=


You are saying a PCP client would only want to update firewall policies 
if the PCP server supports authentication, otherwise it would tell the
user that it cannot enable the webcam, Internet-connected NAS, 
Internet-connected printer, etc.?

 

I wont pr= esume to guess what Sam is thinking...

 

However, = I am thinking that there will be some clients  that are configured to = perform authentication for every request.  For example, there is no re= ason for a PCP proxy, running in an environment where authentication is required to do a THIRD-PARTY request, to perform a= useless round-trip for every THIRD-PARTY request it issues.  

 

Margaret<= o:p>

 

 

 

_______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/= mailman/listinfo/pcp

 

--_000_9B57C850BB53634CACEC56EF4853FF653B7B205ATK5EX14MBXW604w_-- From mohamed.boucadair@orange.com Wed Sep 12 22:32:24 2012 Return-Path: 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 6EB8221E804B for ; Wed, 12 Sep 2012 22:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] 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 F5qZ75O3MUiT for ; Wed, 12 Sep 2012 22:32:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DABF721E803C for ; Wed, 12 Sep 2012 22:32:22 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6A507324610; Thu, 13 Sep 2012 07:32:21 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4AB394C113; Thu, 13 Sep 2012 07:32:21 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 13 Sep 2012 07:32:15 +0200 From: To: "Tirumaleswar Reddy (tireddy)" Date: Thu, 13 Sep 2012 07:32:13 +0200 Thread-Topic: Review of draft-ietf-pcp-upnp-igd-interworking Thread-Index: Ac2Q79Y6YXBrvo9gTweL2JiIKG8WUgAAhB6QAAan4mAAGPXfYA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10C533@PUEXCB1B.nanterre.francetelecom.fr> References: <913383AAA69FF945B8F946018B75898A147A3B2F@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36E5A10C498@PUEXCB1B.nanterre.francetelecom.fr> <913383AAA69FF945B8F946018B75898A147A40BC@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A147A40BC@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E5A10C533PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.13.40336 Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 05:32:24 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5A10C533PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I updated the draft with the point agreed so far. For the two remaining points: * IWF to block internal host to send PCP requests directly to the PCP serve= r: the IWF behave as a PCP client and not a PCP server. If the IWF is co-lo= cated with a PCP proxy, PCP requests from internal hosts will be relayed ot= herwise this will be silently dropped. IMHO, this is out of scope of the IW= F spec. * For the discussion on failure: I added an informative ref to the failure = draft. Cheers, Med ________________________________ De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : mercredi 12 septembre 2012 20:05 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : pcp@ietf.org Objet : RE: Review of draft-ietf-pcp-upnp-igd-interworking Hi Med - Please see inline [Tiru] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, September 12, 2012 8:38 PM To: Tirumaleswar Reddy (tireddy) Cc: pcp@ietf.org Subject: RE: Review of draft-ietf-pcp-upnp-igd-interworking Hi Reddy, Thanks for the review. Please see inline. Cheers, Med ________________________________ De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : mercredi 12 septembre 2012 16:07 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : pcp@ietf.org Objet : Review of draft-ietf-pcp-upnp-igd-interworking Hi Med - [1] Section 5.8 If the port is not in use, the mapping will be created by the PCP Server and a positive response will be sent back to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay a negative message to the UPnP Control Point indicating NoSuchEntryInArray as error code. Comment> Should the IGD-PCP IWF delete the MAP binding after this operation= ? [Med] No. the IGD CP is supposed to issue AddPortMapping() for that specifi= c mapping. The request will be honored by the PCP server (after being relay= ed by the IWF). The behaviour of the IGD CP is out of scope. There is a not= e about this in the draft: [Tiru] For failure case of PCP cannot allocate external port, PCP will r= eturn error code CANNOT_PROVIDE_EXTERNAL, and IGD-PCP IWF is supposed to re= turn negative message NoSuchEntryInArray. Probably you may want to say "Once CANNOT_PROVIDE_EXTERNAL is received by t= he IGD-PCP IWF..." Note: According to some experiments, some UPnP 1.0 implementations, e.g., uTorrent, simply try the same external port X times (usually 4 times) and then fail. Also note that some applications uses GetSpecificPortMapping() to check whether a mapping exists. Do you think the note need be updated? [Tiru] No [2] Section 5.9 A PCP MAP delete response is sent back if the removal of the correspondin= g entry was successful; if not, a PCP Error is sent back to the IGD-PCP Interworking Function including the corresponding error cause (See Section 4.3). comment > you may want to conclude that the corresponding success/error cod= es will be returned to the UPnP Control Point. [Med] The behaviour of the iwf is already captured in "and notifies the UP= nP Control Point about the result of the removal operation.". [Tiru] ok [3]Section 5.9 It is unlikely to encounter a problem in the PCP leg because the IWF has verified authorization rights and also the presence of the mapping in the local table. Comment> Just a corner case, What if the PCP server crashes or loses its st= ate after only processing the first request ? [Med] In that case, the server will return SUCCESS as the mapping does not = exist. [Tiru] ok [4]Section 5.10 In case an error is encountered during mapping renewal, the IGD-PCP Interworking Function has no means to inform the UPnP CP. Comment > why not set PortMappingLeaseDuration to the lifetime value return= ed by the PCP server ? [Med] this variable state must have the same value as the one included in a= ddportmapping() action issued by the CP. [Tiru] ok [5] For Security considerations - If the UPnP supports PCP interworking fun= ction then it should block internal hosts from sending PCP requests to the = PCP server directly. [Med] Do you mean the UPnP CP? [Tiru] yes Generic error cases : [6] What if NAT2 just supports or permits PEER and not MAP request ? [Med] the IWF will fail to open mappings. I can add a sentence like "This s= pecification assumes the PCP Server is configured to accept MAP OpCode". Do= we need to say more? [Tiru] This is fine. [7] what will IGD-PCP do if it receives ANNOUNCE from NAT2 ? [Med] The question can be extended to other failure cases. We have some te= xts spread in several I-Ds: http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#section-2.6 or adapt the text from http://tools.ietf.org/html/draft-boucadair-pcp-failu= re-04#section-2.7.6.2 We have two options: (1) mention ANNOUNCE handling is out of scope and cover this in detail in t= he failure draft (2) add a section to specify the behaviour in the draft. Which option do you prefer? [Tiru] If you are planning to address it in failure draft, I am fine with = both options. --Tiru. --_000_94C682931C08B048B7A8645303FDC9F36E5A10C533PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Re-,
 
I updated the draft with the point agreed so = far.=20
 
For the two remaining points: <= /DIV>
 
* IWF to block internal host to send PCP requ= ests=20 directly to the PCP server: the IWF behave as a PCP client and not a PCP se= rver.=20 If the IWF is co-located with a PCP proxy, PCP requests from internal hosts= will=20 be relayed otherwise this will be silently dropped. IMHO, this is out of sc= ope=20 of the IWF spec.
 
* For the discussion on failure: I added an=20 informative ref to the failure draft.
 
Cheers,
Med

De : Tirumaleswar Reddy (tireddy= )=20 [mailto:tireddy@cisco.com]
Envoy=E9 : mercredi 12 septemb= re 2012=20 20:05
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc := =20 pcp@ietf.org
Objet : RE: Review of=20 draft-ietf-pcp-upnp-igd-interworking

Hi Med =96=

 

Please see inline=20 [Tiru]

 

From:=20 mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20
Sent: Wednesday, September 12, 2012 8:38 PM
To:=20 Tirumaleswar Reddy (tireddy)
Cc: pcp@ietf.org
Subject: RE:=20 Review of=20 draft-ietf-pcp-upnp-igd-interworking

 

Hi=20 Reddy,

 <= o:p>

Thanks= for=20 the review.

 <= o:p>

Please= see=20 inline.

 <= o:p>

Cheers= ,

Med

=  

De :=20 Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20
Envoy=E9 : mercredi 12 septembre 2012 16:07
=C0&n= bsp;:=20 BOUCADAIR Mohamed OLNC/NAD/TIP
Cc :=20 pcp@ietf.org
Objet : Review of=20 draft-ietf-pcp-upnp-igd-interworking

Hi Med =96

 

[1] Section 5.8

   If the port is not in use, the mappin= g will=20 be

   created by the PCP Server and a posit= ive=20 response will be sent back

   to the IGD-PCP IWF.  Once receiv= ed by=20 the IGD-PCP IWF, it MUST relay

   a negative message to the UPnP Contro= l Point=20 indicating

   NoSuchEntryInArray as error=20 code.

 

Comment> Should the IGD-PCP IWF delete the MAP = binding=20 after this operation ?
[Med= ] No.=20 the IGD CP is supposed to issue AddPortMapping() for that specific mapp= ing.=20 The request will be honored by the PCP server (after being relayed by t= he=20 IWF). The behaviour of the IGD CP is out of scope. There is a note abou= t=20 this in the draft:

 

 [Tiru]  = For=20 failure case of PCP cannot allocate  external port, PCP will retur= n=20 error code CANNOT_PROVIDE_EXTERNAL, and IGD-PCP IWF is supposed to retu= rn=20 negative message NoSuchEntryInArray.

Probably you may wa= nt to say=20 =93Once CANNOT_PROVIDE_EXTERNAL i= s=20 received by the IGD-PCP IWF=85=94

 

 

&nbs= p;    =20 Note: According to some experiments, some UPnP=20 1.0
      implementations, e.g., uTorrent,= =20 simply try the same external port
      X t= imes=20 (usually 4 times) and then fail.  Also note that=20 some
      applications uses=20 GetSpecificPortMapping() to check whether=20 a
      mapping exists.

 

Do y= ou=20 think the note need be updated?

[Tiru]=20 No

 

[2] Section 5.9

  A PCP MAP delete response is sent back if t= he=20 removal of the corresponding

  entry was successful; if not, a PCP Error i= s sent=20 back to the IGD-PCP

  Interworking Function including the corresp= onding=20 error cause (See

  Section 4.3).

 

comment > you may want to conclude that the=20 corresponding success/error codes will be returned to the UPnP Control= =20 Point.
[Med= ]  The=20 behaviour of the iwf is already captured in "and notifies the= UPnP=20 Control Point about the result of the
   removal=20 operation.".

[Tiru]=20 ok

 

[3]Section 5.9

 

      It is unlikely to=20 encounter a problem in the PCP leg

      because the IWF has= =20 verified authorization rights and also the

      presence of the map= ping in=20 the local table.

 

Comment> Just a corner case, What if the PCP se= rver=20 crashes or loses its state after only processing the first request=20 ?
[Med= ] In=20 that case, the server will return SUCCESS as the mapping does not=20 exist.   

[Tiru]=20 ok

 

[4]Section 5.10

 

   In case an error is encountered durin= g=20 mapping renewal, the IGD-PCP

   Interworking Function has no means to= inform=20 the UPnP CP.

 

Comment > why not set PortMappingLeaseDuration = to the=20 lifetime value returned by the PCP server ?
[Med= ] this=20 variable state must have the same value as the one included in=20 addportmapping() action issued by the CP.

[Tiru]=20 ok

 

[5] For Security considerations - If the UPnP supp= orts=20 PCP interworking function then it should block internal hosts from send= ing=20 PCP requests to the PCP server directly.
[Med= ] Do=20 you mean the UPnP CP? 

[Tiru]=20 yes

 

Generic error cases :

 

[6] What if NAT2 just supports or permits PEER and= not=20 MAP request ?
[Med= ] the=20 IWF will fail to open mappings. I can add a sentence like "This=20 specification assumes the PCP Server is configured to accept MAP OpCode= ". Do=20 we need to say more?

[Tiru] This is=20 fine.

 

[7] what will IGD-PCP do if it receives ANNOUNCE f= rom=20 NAT2 ?
[Med= ] =20 The question can be extended to other failure cases. We have some = texts=20 spread in several I-Ds:

http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#section-2= .6

or a= dapt=20 the text from http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#secti= on-2.7.6.2

 

We h= ave two=20 options:

(1)= =20 mention ANNOUNCE handling is out of scope and cover this in detail= in=20 the failure draft

(2) = add a=20 section to specify the behaviour in the draft.

 

Whic= h=20 option do you prefer?

 [Tiru] If you= are=20 planning to address it in failure draft, I am fine with both=20 options.

 

--Tiru.

--_000_94C682931C08B048B7A8645303FDC9F36E5A10C533PUEXCB1Bnante_-- From alper.yegin@yegin.org Thu Sep 13 02:14:04 2012 Return-Path: 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 913C721F8554 for ; Thu, 13 Sep 2012 02:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 eOHjwafvu6bT for ; Thu, 13 Sep 2012 02:14:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8A221F8508 for ; Thu, 13 Sep 2012 02:13:32 -0700 (PDT) Received: from [172.20.10.2] ([46.221.39.88]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MCLMH-1TKZnS0aR7-0094uq; Thu, 13 Sep 2012 05:13:31 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_919934D3-BD06-4BCA-8AFF-CB9B56C53F4C" From: Alper Yegin In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 13 Sep 2012 12:13:24 +0300 Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:ZOzDeYc47KiTnSQ4so8t1AvwUbHC6HPnZZofAcRaWug 2eICwYs+tm5uapaFwadL9+sgr3eOhEeVazXqlUO5gyWSKeoy29 08If7YC8RxQF4BIy7i5CXsb6HAuBaJCZ8XtBCN0EtxHYfhT4BQ psqHDn83sQUZmiZgo0ZGq154ZYRNd1OpdNN1vhEpz8dUw1xUUj uZUzdZZ5Cu3PJ8XgN1NGH+ol+ow2gs4HhB6AoVtFpHcgUkUjFl 9IU4I/3PsKFIfIIgftJN1igcCTA34O2p6sYB+f1OOkPtsTPjzk xLpEuHPjyNmUmCKVepkG52XEX9B6hqguVKBXiCjyHTXsLeXxkS gLxjF7QP6B07ZeRPTzX8fhUGV7/nHbCOIUEfpVNnk Cc: "pcp@ietf.org" Subject: Re: [pcp] WG status on PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 09:14:04 -0000 --Apple-Mail=_919934D3-BD06-4BCA-8AFF-CB9B56C53F4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dave, Thank you for the summary. > The main comparison point we know about > is between Tunneled PANA vs Side-by-side PANA/PCP. Yoshi and I had an offline discussion and concluded that the so-called = side-by-side PANA/PCP (or, running PANA over PCP port) is simple and = straightforward, compared to tunneled PANA (carrying PANA header and = payloads as PCP options -- more like PANA over PCP). So, we diverted our = energy to the former and produced = http://tools.ietf.org/html/draft-ohba-pcp-pana-02.=20 I don't see problems with PANA over PCP port, or benefits with PANA over = PCP to motivate me to work the details of PANA over PCP.=20 Does anyone see?=20 If not, then we'd only have PANA over PCP port to show people in the = call. Alper On Sep 13, 2012, at 1:48 AM, Dave Thaler wrote: > Just to circle back on this now that the minutes are posted. > =20 > Relevant snippets from the minutes: > > Francis Dupont: How does this compare to just running PCP over DTLS? > >=20 > > Margaret Wasserman: There is currently no draft written to specify = how it > > would work. You can't "just run" anything over DTLS. It's not = that simple. > =20 > Summary: we have not explicitly called a question about DTLS. Mainly > because there=92s no proposal on the table. Lacking one with real = support, > the WG will go ahead with a proposal that has energy/interest behind = it. > =20 > > Alain Durand called for show of hands: > > For single port: 23 > > For two separate ports: 0 > =20 > Clear consensus within the room, and I=92ve seen no indication on the = list that this > consensus can=92t be considered confirmed based on the list discussion = thus far. > =20 > > Alain Durand called for show of hands: > > PCP-specific messages (PCP-specific encoding of authentication = information): 5 > > Tunneled PANA (embed PANA data within PCP options): 6/7 > > Side-by-side (multiplex raw PANA packets and PCP packets over same = port): 5/6 > > Don't care: 15 > =20 > Room was basically evenly split between the approaches above, so no > consensus yet, but only about half the WG cares. > =20 > > Alain Durand called for show of hands: > > PCP-specific encoding of authentication information: 5 > > Some kind of PANA encapsulation: 10 or 11 > =20 > In my view there was a rough consensus of the room, and so far the = list discussion > hasn=92t changed this ratio in my view. > =20 > > Dan Wing: request an interim meeting to discuss solutions, once = they've been > > fleshed out a little > =20 > And that=92s the step we=92re doing next. The main comparison point = we know about > is between Tunneled PANA vs Side-by-side PANA/PCP. We can also = compare > PCP-specific though it appears to already be in the minority. If = there are other new > proposals to consider (DTLS or whatever) by then, we can, but so far = the inertia > seems to be primarily between the PANA variants. There does seem to = be > uncertainty about how they would actually work, so it=92s important = that they be > fleshed out in enough detail that we can have informed discussion at = the interim > meeting. > =20 > -Dave > =20 > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Alper Yegin > Sent: Friday, August 17, 2012 1:09 AM > To: Margaret Wasserman > Cc: pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication > =20 > =20 > On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote: >=20 >=20 > =20 > =20 > Hi Dacheng, > =20 > The conclusion from the meeting was that we will document all three = approaches in our document: > =20 > =20 > Could the chairs please declare what the meeting conclusions and next = steps are. > =20 > Thanks. > =20 > Alper > =20 > =20 > =20 >=20 >=20 > - PCP Specific > - PANA Encapsulated in PCP > - PANA Demultiplexed with PCP on the same port > =20 > Then, we will have an interim PCP conference call to discuss the = trade-offs and hopefully decide between them. > =20 > Margaret > =20 > =20 > =20 > On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: >=20 >=20 > Have we got any conclusions on two approaches? Or we can just support = the two options in the draft for the moment and briefly compare their = pros and cons, can we? > =20 > Cheers > =20 > Dcheng > =20 > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Margaret Wasserman > Sent: Friday, August 10, 2012 3:21 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication > =20 > =20 > On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: > =20 > If I'm updating security policy on a firewall I want to be able to > audit whether that actually happened. That requires authentication. >=20 > You are saying a PCP client would only want to update firewall = policies=20 > if the PCP server supports authentication, otherwise it would tell the > user that it cannot enable the webcam, Internet-connected NAS,=20 > Internet-connected printer, etc.? > =20 > I wont presume to guess what Sam is thinking... > =20 > However, I am thinking that there will be some clients that are = configured to perform authentication for every request. For example, = there is no reason for a PCP proxy, running in an environment where = authentication is required to do a THIRD-PARTY request, to perform a = useless round-trip for every THIRD-PARTY request it issues. =20 > =20 > Margaret > =20 > =20 > =20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > =20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail=_919934D3-BD06-4BCA-8AFF-CB9B56C53F4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Dave,

Thank you for the = summary.

The = main comparison point we know about
is between Tunneled PANA vs = Side-by-side = PANA/PCP.


<= /div>

Yoshi and I had an offline discussion and = concluded that the so-called side-by-side PANA/PCP (or, running PANA = over PCP port) is simple and straightforward, compared to tunneled PANA = (carrying PANA header and payloads as PCP options -- more like PANA over = PCP). So, we diverted our energy to the former and produced http://tools.ie= tf.org/html/draft-ohba-pcp-pana-02. 

I = don't see problems with PANA over PCP port, or benefits with PANA over = PCP to motivate me to work the details of PANA over = PCP. 
Does anyone see? 
If not, then we'd = only have PANA over PCP port to show people in the = call.


Alper






<= div>
On Sep 13, 2012, at 1:48 AM, Dave Thaler = wrote:

Just = to circle back on this now that the minutes are = posted.
> Francis Dupont: How does = this compare to just running PCP over DTLS?
> = Margaret Wasserman: There is currently no draft written to specify how = it
because there=92s no proposal on the = table.   Lacking one with real = support,
the = WG will go ahead with a proposal that has energy/interest behind = it.
> = Alain Durand called for show of hands:
> For single port: = 23
> For = two separate ports: 0
 
Clear consensus within the room, = and I=92ve seen no indication on the list that = this
consensus = can=92t be considered confirmed based on the list discussion thus = far.
> = Alain Durand called for show of hands:
> PCP-specific messages = (PCP-specific encoding of authentication information): = 5
> = Tunneled PANA (embed PANA data within PCP options): = 6/7
> = Side-by-side (multiplex raw PANA packets and PCP packets over same = port): 5/6
> = Don't care: 15
Room = was basically evenly split between the approaches above, so = no
consensus = yet, but only about half the WG cares.
> = Alain Durand called for show of hands:
> PCP-specific encoding of = authentication information: 5
> Some kind of PANA = encapsulation: 10 or 11
 
In my view there was a rough = consensus of the room, and so far the list = discussion
> = Dan Wing: request an interim meeting to discuss solutions, once they've = been
And = that=92s the step we=92re doing next.   The main comparison = point we know about
is between Tunneled PANA vs Side-by-side = PANA/PCP.   We can also compare
PCP-specific though it appears to = already be in the minority.  If there are other = new
proposals = to consider (DTLS or whatever) by then, we can, but so far the = inertia
seems = to be primarily between the PANA variants.   There does seem = to be
 pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org]=  On Behalf Of Alper = Yegin
Sent: Friday, August 17, 2012 = 1:09 AM
To: Margaret = Wasserman
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP = authentication
 
On Aug 16, 2012, at 2:38 = PM, Margaret Wasserman wrote:


 
 
Hi Dacheng,
 
The conclusion from the meeting was that we will = document all three approaches in our = document:
Could the chairs please = declare what the meeting conclusions and next steps = are.
- PCP = Specific
- PANA Encapsulated in = PCP
- PANA Demultiplexed with = PCP on the same port
Then, we will have an = interim PCP conference call to discuss the trade-offs and hopefully = decide between them.
On Aug 15, 2012, at 10:47 = PM, Zhangdacheng (Dacheng) wrote:


Have we got any conclusions on = two approaches?  Or we can just support the two options in the = draft for the moment and briefly compare their pros and cons, can = we?
From: [mailto:pcp-bounces@ietf.org] On Behalf Of Margaret = Wasserman
Sent: Friday, August 10, 2012 = 3:21 AM
To: Dan Wing
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP = authentication
=
 
On Aug 9, 2012, at 2:32 PM, Dan Wing = wrote:
If I'm updating security policy on a firewall I = want to be able to
audit whether that actually happened.  That = requires = authentication.

You are saying a PCP client would only want = to update firewall policies 
if the PCP server = supports authentication, otherwise it would tell the
user that it = cannot enable the webcam, Internet-connected NAS, 
Internet-connected = printer, etc.?
I wont presume to guess what Sam is = thinking...
However, I am thinking that there will be some = clients  that are configured to perform authentication for every = request.  For example, there is no reason for a PCP proxy, running = in an environment where authentication is required to do a THIRD-PARTY = request, to perform a useless round-trip for every THIRD-PARTY request = it issues.  
 
_______________________________________________
pcp = mailing list
pcp@ietf.org
Subject: Re: [pcp] WG status on PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 11:07:08 -0000 --Apple-Mail-20--139968371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alper, I understand that you and Yoshi have done some analysis amongst = yourselves and come to a conclusion, but my understanding of the = direction from IETF 84 was that the WG wanted to go through this = analysis together and come to a conclusion about which approach was = preferred. Could you share your reasoning with the rest of us, instead of just your = conclusions? What do you see as the points in favor of the side-by-side = (demultiplexing) approach vs. the tunneled PANA (AKA encapsulation) = approach? Are there weaknesses to the encapsulation approach that make = the demultiplexing approach more desirable? Thanks, Margaret On Sep 13, 2012, at 5:13 AM, Alper Yegin wrote: > Hi Dave, >=20 > Thank you for the summary. >=20 >> The main comparison point we know about >> is between Tunneled PANA vs Side-by-side PANA/PCP. >=20 >=20 >=20 > Yoshi and I had an offline discussion and concluded that the so-called = side-by-side PANA/PCP (or, running PANA over PCP port) is simple and = straightforward, compared to tunneled PANA (carrying PANA header and = payloads as PCP options -- more like PANA over PCP). So, we diverted our = energy to the former and produced = http://tools.ietf.org/html/draft-ohba-pcp-pana-02.=20 >=20 > I don't see problems with PANA over PCP port, or benefits with PANA = over PCP to motivate me to work the details of PANA over PCP.=20 > Does anyone see?=20 > If not, then we'd only have PANA over PCP port to show people in the = call. >=20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Sep 13, 2012, at 1:48 AM, Dave Thaler wrote: >=20 >> Just to circle back on this now that the minutes are posted. >> =20 >> Relevant snippets from the minutes: >> > Francis Dupont: How does this compare to just running PCP over = DTLS? >> >=20 >> > Margaret Wasserman: There is currently no draft written to specify = how it >> > would work. You can't "just run" anything over DTLS. It's not = that simple. >> =20 >> Summary: we have not explicitly called a question about DTLS. = Mainly >> because there=92s no proposal on the table. Lacking one with real = support, >> the WG will go ahead with a proposal that has energy/interest behind = it. >> =20 >> > Alain Durand called for show of hands: >> > For single port: 23 >> > For two separate ports: 0 >> =20 >> Clear consensus within the room, and I=92ve seen no indication on the = list that this >> consensus can=92t be considered confirmed based on the list = discussion thus far. >> =20 >> > Alain Durand called for show of hands: >> > PCP-specific messages (PCP-specific encoding of authentication = information): 5 >> > Tunneled PANA (embed PANA data within PCP options): 6/7 >> > Side-by-side (multiplex raw PANA packets and PCP packets over same = port): 5/6 >> > Don't care: 15 >> =20 >> Room was basically evenly split between the approaches above, so no >> consensus yet, but only about half the WG cares. >> =20 >> > Alain Durand called for show of hands: >> > PCP-specific encoding of authentication information: 5 >> > Some kind of PANA encapsulation: 10 or 11 >> =20 >> In my view there was a rough consensus of the room, and so far the = list discussion >> hasn=92t changed this ratio in my view. >> =20 >> > Dan Wing: request an interim meeting to discuss solutions, once = they've been >> > fleshed out a little >> =20 >> And that=92s the step we=92re doing next. The main comparison point = we know about >> is between Tunneled PANA vs Side-by-side PANA/PCP. We can also = compare >> PCP-specific though it appears to already be in the minority. If = there are other new >> proposals to consider (DTLS or whatever) by then, we can, but so far = the inertia >> seems to be primarily between the PANA variants. There does seem to = be >> uncertainty about how they would actually work, so it=92s important = that they be >> fleshed out in enough detail that we can have informed discussion at = the interim >> meeting. >> =20 >> -Dave >> =20 >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Alper Yegin >> Sent: Friday, August 17, 2012 1:09 AM >> To: Margaret Wasserman >> Cc: pcp@ietf.org >> Subject: Re: [pcp] Comparison of PCP authentication >> =20 >> =20 >> On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote: >>=20 >>=20 >> =20 >> =20 >> Hi Dacheng, >> =20 >> The conclusion from the meeting was that we will document all three = approaches in our document: >> =20 >> =20 >> Could the chairs please declare what the meeting conclusions and next = steps are. >> =20 >> Thanks. >> =20 >> Alper >> =20 >> =20 >> =20 >>=20 >>=20 >> - PCP Specific >> - PANA Encapsulated in PCP >> - PANA Demultiplexed with PCP on the same port >> =20 >> Then, we will have an interim PCP conference call to discuss the = trade-offs and hopefully decide between them. >> =20 >> Margaret >> =20 >> =20 >> =20 >> On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: >>=20 >>=20 >> Have we got any conclusions on two approaches? Or we can just = support the two options in the draft for the moment and briefly compare = their pros and cons, can we? >> =20 >> Cheers >> =20 >> Dcheng >> =20 >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Margaret Wasserman >> Sent: Friday, August 10, 2012 3:21 AM >> To: Dan Wing >> Cc: pcp@ietf.org >> Subject: Re: [pcp] Comparison of PCP authentication >> =20 >> =20 >> On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: >> =20 >> If I'm updating security policy on a firewall I want to be able to >> audit whether that actually happened. That requires authentication. >>=20 >> You are saying a PCP client would only want to update firewall = policies=20 >> if the PCP server supports authentication, otherwise it would tell = the >> user that it cannot enable the webcam, Internet-connected NAS,=20 >> Internet-connected printer, etc.? >> =20 >> I wont presume to guess what Sam is thinking... >> =20 >> However, I am thinking that there will be some clients that are = configured to perform authentication for every request. For example, = there is no reason for a PCP proxy, running in an environment where = authentication is required to do a THIRD-PARTY request, to perform a = useless round-trip for every THIRD-PARTY request it issues. =20 >> =20 >> Margaret >> =20 >> =20 >> =20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >> =20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail-20--139968371 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi = Dave,

Thank you for the = summary.

The = main comparison point we know about
is between Tunneled PANA vs = Side-by-side = PANA/PCP.





<= div>
On Sep 13, 2012, at 1:48 AM, Dave Thaler = wrote:

Just = to circle back on this now that the minutes are = posted.
> Francis Dupont: How does = this compare to just running PCP over DTLS?
> = Margaret Wasserman: There is currently no draft written to specify how = it
because there=92s no proposal on the = table.   Lacking one with real = support,
the = WG will go ahead with a proposal that has energy/interest behind = it.
> = Alain Durand called for show of hands:
> For single port: = 23
> For = two separate ports: 0
 
Clear consensus within the room, = and I=92ve seen no indication on the list that = this
consensus = can=92t be considered confirmed based on the list discussion thus = far.
> = Alain Durand called for show of hands:
> PCP-specific messages = (PCP-specific encoding of authentication information): = 5
> = Tunneled PANA (embed PANA data within PCP options): = 6/7
> = Side-by-side (multiplex raw PANA packets and PCP packets over same = port): 5/6
> = Don't care: 15
Room = was basically evenly split between the approaches above, so = no
consensus = yet, but only about half the WG cares.
> = Alain Durand called for show of hands:
> PCP-specific encoding of = authentication information: 5
> Some kind of PANA = encapsulation: 10 or 11
 
In my view there was a rough = consensus of the room, and so far the list = discussion
> = Dan Wing: request an interim meeting to discuss solutions, once they've = been
And = that=92s the step we=92re doing next.   The main comparison = point we know about
is between Tunneled PANA vs Side-by-side = PANA/PCP.   We can also compare
PCP-specific though it appears to = already be in the minority.  If there are other = new
proposals = to consider (DTLS or whatever) by then, we can, but so far the = inertia
seems = to be primarily between the PANA variants.   There does seem = to be
 pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org]=  On Behalf Of Alper = Yegin
Sent: Friday, August 17, 2012 = 1:09 AM
To: Margaret = Wasserman
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP = authentication
 
On Aug 16, 2012, at 2:38 = PM, Margaret Wasserman wrote:


 
 
Hi Dacheng,
 
The conclusion from the meeting was that we will = document all three approaches in our = document:
Could the chairs please = declare what the meeting conclusions and next steps = are.
- PCP = Specific
- PANA Encapsulated in = PCP
- PANA Demultiplexed with = PCP on the same port
Then, we will have an = interim PCP conference call to discuss the trade-offs and hopefully = decide between them.
On Aug 15, 2012, at 10:47 = PM, Zhangdacheng (Dacheng) wrote:


Have we got any conclusions on = two approaches?  Or we can just support the two options in the = draft for the moment and briefly compare their pros and cons, can = we?
From: [mailto:pcp-bounces@ietf.org] On Behalf Of Margaret = Wasserman
Sent: Friday, August 10, 2012 = 3:21 AM
To: Dan Wing
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP = authentication
=
 
On Aug 9, 2012, at 2:32 PM, Dan Wing = wrote:
If I'm updating security policy on a firewall I = want to be able to
audit whether that actually happened.  That = requires = authentication.

You are saying a PCP client would only want = to update firewall policies 
if the PCP server = supports authentication, otherwise it would tell the
user that it = cannot enable the webcam, Internet-connected NAS, 
Internet-connected = printer, etc.?
I wont presume to guess what Sam is = thinking...
However, I am thinking that there will be some = clients  that are configured to perform authentication for every = request.  For example, there is no reason for a PCP proxy, running = in an environment where authentication is required to do a THIRD-PARTY = request, to perform a useless round-trip for every THIRD-PARTY request = it issues.  
 
_______________________________________________
pcp = mailing list
pcp@ietf.org
pcp@ietf.org
https://www.ietf.org/mail= man/listinfo/pcp

= --Apple-Mail-20--139968371-- From internet-drafts@ietf.org Thu Sep 13 05:22:41 2012 Return-Path: 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 DCDED21F8498; Thu, 13 Sep 2012 05:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OaCokzZGoLLg; Thu, 13 Sep 2012 05:22:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94121F8504; Thu, 13 Sep 2012 05:22:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120913122241.30065.89906.idtracker@ietfa.amsl.com> Date: Thu, 13 Sep 2012 05:22:41 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dhcp-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:22:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : DHCP Options for the Port Control Protocol (PCP) Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-dhcp-05.txt Pages : 9 Date : 2012-09-13 Abstract: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server names. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-dhcp-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Thu Sep 13 05:37:22 2012 Return-Path: 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 D2A1B21F8596 for ; Thu, 13 Sep 2012 05:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 tUQ2S7ksusPQ for ; Thu, 13 Sep 2012 05:37:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E09CA21F8587 for ; Thu, 13 Sep 2012 05:37:21 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id A7B5D2DC367 for ; Thu, 13 Sep 2012 14:37:20 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9005127C088 for ; Thu, 13 Sep 2012 14:37:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 13 Sep 2012 14:37:15 +0200 From: To: "pcp@ietf.org" Date: Thu, 13 Sep 2012 14:37:13 +0200 Thread-Topic: I-D Action: draft-ietf-pcp-dhcp-05.txt Thread-Index: Ac2RqoKgb7cVf4uURainNrS/jrU1igAAS8oQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10C95F@PUEXCB1B.nanterre.francetelecom.fr> References: <20120913122241.30065.89906.idtracker@ietfa.amsl.com> In-Reply-To: <20120913122241.30065.89906.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.13.94527 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-dhcp-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:37:22 -0000 Dear all, This is an updated version to take into account this note from IETF#84 (see= the minutes): "Chairs directs author of DHCP document to move multihoming to a separate d= ocument." Cheers, Med >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] De la part de=20 >internet-drafts@ietf.org >Envoy=E9 : jeudi 13 septembre 2012 14:23 >=C0 : i-d-announce@ietf.org >Cc : pcp@ietf.org >Objet : I-D Action: draft-ietf-pcp-dhcp-05.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Port Control Protocol=20 >Working Group of the IETF. > > Title : DHCP Options for the Port Control=20 >Protocol (PCP) > Author(s) : Mohamed Boucadair > Reinaldo Penno > Dan Wing > Filename : draft-ietf-pcp-dhcp-05.txt > Pages : 9 > Date : 2012-09-13 > >Abstract: > This document specifies DHCP (IPv4 and IPv6) options to configure > hosts with Port Control Protocol (PCP) Server names. The use of > DHCPv4 or DHCPv6 depends on the PCP deployment scenario. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-dhcp-05 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-dhcp-05 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >= From mohamed.boucadair@orange.com Thu Sep 13 05:40:21 2012 Return-Path: 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 9E0F221F854F for ; Thu, 13 Sep 2012 05:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 Y9eUXyM9ddRj for ; Thu, 13 Sep 2012 05:40:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6D921F851E for ; Thu, 13 Sep 2012 05:40:20 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id BB81E18C5EF for ; Thu, 13 Sep 2012 14:40:19 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A448727C088 for ; Thu, 13 Sep 2012 14:40:19 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 13 Sep 2012 14:40:14 +0200 From: To: "pcp@ietf.org" Date: Thu, 13 Sep 2012 14:40:13 +0200 Thread-Topic: PCP Server Selection (draft-boucadair-pcp-server-selection) Thread-Index: Ac2Rq21ko9d/Awa+RXyuUNlocs/JMwAASVxQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10C962@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.13.94527 Subject: [pcp] PCP Server Selection (draft-boucadair-pcp-server-selection) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:40:21 -0000 Re-, This draft is a copy/paste of Section 6 of draft-ietf-pcp-dhcp-04 which has= been removed from draft-ietf-pcp-dhcp-05. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : jeudi 13 septembre 2012 14:29 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-pcp-server-selection-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PCP Server Selection Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-boucadair-pcp-server-selection-00.txt Pages : 7 Date : 2012-09-13 Abstract: This document specifies the behavior to be followed by the PCP Client to contact its PCP Server(s) when one or several PCP Names are configured. Multiple Names may be configured to a PCP Client in some deployment contexts such as multi-homing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-server-selection There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-server-selection-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From hartmans@mit.edu Thu Sep 13 07:57:52 2012 Return-Path: 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 B5A9921F8504 for ; Thu, 13 Sep 2012 07:57:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Missing required header field: "Date" X-Spam-Flag: NO X-Spam-Score: 4.29 X-Spam-Level: **** X-Spam-Status: No, score=4.29 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, MISSING_DATE=0.001, MISSING_MID=0.001, RDNS_DYNAMIC=0.1] 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 FHE+NuUrojK4 for ; Thu, 13 Sep 2012 07:57:52 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4D54921F84D6 for ; Thu, 13 Sep 2012 07:57:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A4B682010F for ; Thu, 13 Sep 2012 10:57:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 42CB64149; Thu, 13 Sep 2012 10:57:34 -0400 (EDT) Resent-To: pcp@ietf.org Resent-From: Sam Hartman Resent-Date: Thu, 13 Sep 2012 10:57:34 -0400 Resent-Message-ID: X-From-Line: nobody Thu Sep 13 09:24:50 2012 From: Sam Hartman To: pcp@ietf.org User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 29 Subject: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 13 Sep 2012 14:57:52 -0000 X-List-Received-Date: Thu, 13 Sep 2012 14:57:52 -0000 hi. So, as I mentioned earlier I'm either in the camp of strongly preferring PCP-specific authentication or in the camp of not caring much at all. I'd kind of like to find out which camp I'm in by the 21st. My nervousness is about implementation complexity. I would like to see PCP authentication be something that can easily be implemented with open-source libraries. I know how to do that if we use an EAP library directly. I've managed projects doing something quite similar and I understand the implementation complexity. Would people familiar with PANA implementation be willing to suggest which implementation I should look at? I'd prefer to look at one, but if there's disagreement I'd be happy to look at two. I'm sure you've done your analysis on this point but I'll feel more comfortable if I do my own. I'll be happy to share my conclusions as I suspect that there are other WG participants who care about implementation complexity. If there are open-source PCP servers I'd be happy to glance at those just to see how things like memory management, event loop and state management line up. --Sam From hannes.tschofenig@gmx.net Thu Sep 13 08:26:16 2012 Return-Path: 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 68C8F21F859B for ; Thu, 13 Sep 2012 08:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 lQKQZsmdCh2h for ; Thu, 13 Sep 2012 08:26:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7C4C121F852D for ; Thu, 13 Sep 2012 08:26:15 -0700 (PDT) Received: (qmail invoked by alias); 13 Sep 2012 15:26:13 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.111]) [88.115.216.191] by mail.gmx.net (mp035) with SMTP; 13 Sep 2012 17:26:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+fQm9KuBmfvqEFn2wXKSSf7C94LeDBauWkTY/TnQ HB9kf5edtlQJvi Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20120913145755.6952gmx1@mx075.gmx.net> Date: Thu, 13 Sep 2012 18:26:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1B150C40-51A4-4BD9-8915-2F9BC54B5BB9@gmx.net> References: <20120913145755.6952gmx1@mx075.gmx.net> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 15:26:16 -0000 Hi Sam,=20 I wonder why you care about PCP at all. You are neither someone who = ships operating systems nor someone who provides network equipment (like = a NAT or a firewall).=20 You seem to be willing to spend a lot of time on that topic and I am = curious where this interest comes from.=20 Ciao Hannes On Sep 13, 2012, at 5:57 PM, Sam Hartman wrote: >=20 >=20 > hi. > So, as I mentioned earlier I'm either in the camp of strongly > preferring PCP-specific authentication or in the camp of not caring = much > at all. >=20 > I'd kind of like to find out which camp I'm in by the 21st. >=20 > My nervousness is about implementation complexity. I would like to see > PCP authentication be something that can easily be implemented with > open-source libraries. I know how to do that if we use an EAP library > directly. I've managed projects doing something quite similar and I > understand the implementation complexity. >=20 > Would people familiar with PANA implementation be willing to suggest > which implementation I should look at? I'd prefer to look at one, but = if > there's disagreement I'd be happy to look at two. > I'm sure you've done your analysis on this point but I'll feel more > comfortable if I do my own. >=20 > I'll be happy to share my conclusions as I suspect that there are = other > WG participants who care about implementation complexity. >=20 > If there are open-source PCP servers I'd be happy to glance at those > just to see how things like memory management, event loop and state > management line up. >=20 > --Sam > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From hartmans@painless-security.com Thu Sep 13 08:47:53 2012 Return-Path: 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 6094921F849D for ; Thu, 13 Sep 2012 08:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.289 X-Spam-Level: **** X-Spam-Status: No, score=4.289 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 iL-fBsofZR1V for ; Thu, 13 Sep 2012 08:47:53 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id E94E521F849B for ; Thu, 13 Sep 2012 08:47:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 01A862010F; Thu, 13 Sep 2012 11:47:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6258C4149; Thu, 13 Sep 2012 11:47:35 -0400 (EDT) From: Sam Hartman To: Hannes Tschofenig References: <20120913145755.6952gmx1@mx075.gmx.net> <1B150C40-51A4-4BD9-8915-2F9BC54B5BB9@gmx.net> Date: Thu, 13 Sep 2012 11:47:35 -0400 In-Reply-To: <1B150C40-51A4-4BD9-8915-2F9BC54B5BB9@gmx.net> (Hannes Tschofenig's message of "Thu, 13 Sep 2012 18:26:11 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 15:47:53 -0000 >>>>> "Hannes" == Hannes Tschofenig writes: Hi Hannes. At one level, I'm confused why it matters. In general within the IETF we accept help where we can find it. However your question is easy to answer so I'm happy to do so. Hannes> Hi Sam, I wonder why you care about PCP at all. You are Hannes> neither someone who ships operating systems nor someone who Hannes> provides network equipment (like a NAT or a firewall). Hi. draft-ietf-pcp-authentication-00 is missing a funding acknowledgment. Unfortunately, for silly contractual reasons, we'll need to wait until the next version of the draft to add that. It should be obvious from the author list of draft-ietf-pcp-authentication who Painless Security's client is in this instance. More generally, Painless Security has worked on NAT and firewall implementations and has worked with OS vendors such as Debian and Ubuntu to maintain software in their operating systems. We tend to be quite interested in areas where we are funded by a client or where we are doing ongoing product development ourselves. From hannes.tschofenig@gmx.net Thu Sep 13 08:53:59 2012 Return-Path: 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 9FFA921F857E for ; Thu, 13 Sep 2012 08:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 iTgRTURc+FW2 for ; Thu, 13 Sep 2012 08:53:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1F0D021F855B for ; Thu, 13 Sep 2012 08:53:57 -0700 (PDT) Received: (qmail invoked by alias); 13 Sep 2012 15:53:57 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.111]) [88.115.216.191] by mail.gmx.net (mp039) with SMTP; 13 Sep 2012 17:53:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/p80JaOLLp7x2LEi4P/O6Yf61slDcpHIg78oFiH8 dXr7j0tYdtGACx Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 13 Sep 2012 18:53:54 +0300 Content-Transfer-Encoding: 7bit Message-Id: <2F5680CC-7183-4000-B227-B7E7CCD76099@gmx.net> References: <20120913145755.6952gmx1@mx075.gmx.net> <1B150C40-51A4-4BD9-8915-2F9BC54B5BB9@gmx.net> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 15:54:00 -0000 Thanks, Sam. Makes sense. On Sep 13, 2012, at 6:47 PM, Sam Hartman wrote: >>>>>> "Hannes" == Hannes Tschofenig writes: > Hi Hannes. > At one level, I'm confused why it matters. In general within the IETF we > accept help where we can find it. > However your question is easy to answer so I'm happy to do so. > > Hannes> Hi Sam, I wonder why you care about PCP at all. You are > Hannes> neither someone who ships operating systems nor someone who > Hannes> provides network equipment (like a NAT or a firewall). > > Hi. > draft-ietf-pcp-authentication-00 is missing a funding acknowledgment. > Unfortunately, for silly contractual reasons, we'll need to wait until > the next version of the draft to add that. > It should be obvious from the author list of > draft-ietf-pcp-authentication who Painless Security's client is in this > instance. > > More generally, Painless Security has worked on NAT and firewall > implementations and has worked with OS vendors such as Debian and Ubuntu > to maintain software in their operating systems. > > We tend to be quite interested in areas where we are funded by a client > or where we are doing ongoing product development ourselves. From dwing@cisco.com Thu Sep 13 09:42:38 2012 Return-Path: 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 CEF3021F8518 for ; Thu, 13 Sep 2012 09:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 hqc6CBVjpsDo for ; Thu, 13 Sep 2012 09:42:38 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0248D21F84F8 for ; Thu, 13 Sep 2012 09:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2418; q=dns/txt; s=iport; t=1347554558; x=1348764158; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=dooPwRyd7EYsQZV0vpvl7i3XcyvLbUu1uly7cZ3FpCg=; b=kntc5EDZMSPetew24xIN8/Rz7PSLigQKRpRL/F5ICTjne8RCu3MR4mFO +0w+4eNU6qmN4Ao/YQ11H//XZ1kLz5IB57ICW3cTnlOk9VEAvxNDkpc1o cfBoo5TyH3trmxBWTPCnS2LTM0cr42AIb1lHWge45GVgn0yJ72ixYtmmS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHYMUlCrRDoJ/2dsb2JhbABFrAaPcoEHgiABAQEDAQEBAQUKARUCEDQLBQcBAwIJDwIEAQEBJwcZDhUKCQgBAQQBEgsXh2UFDJs0oC0EixCGNwOIVYUPljSBaYMG X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="58151662" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 13 Sep 2012 16:42:37 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8DGgbFF025243; Thu, 13 Sep 2012 16:42:37 GMT From: "Dan Wing" To: "'Hannes Tschofenig'" , "'Sam Hartman'" References: <20120913145755.6952gmx1@mx075.gmx.net> <1B150C40-51A4-4BD9-8915-2F9BC54B5BB9@gmx.net> In-Reply-To: <1B150C40-51A4-4BD9-8915-2F9BC54B5BB9@gmx.net> Date: Thu, 13 Sep 2012 09:42:37 -0700 Message-ID: <00e001cd91ce$c88ee1b0$59aca510$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2RxCQqjpHMIihbRZCJhUP1L3Ua3AACg+dA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 16:42:39 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Thursday, September 13, 2012 8:26 AM > To: Sam Hartman > Cc: pcp@ietf.org > Subject: Re: [pcp] PANA implementatinos to consider > > Hi Sam, > > I wonder why you care about PCP at all. You are neither someone who > ships operating systems nor someone who provides network equipment > (like a NAT or a firewall). > > You seem to be willing to spend a lot of time on that topic and I am > curious where this interest comes from. Curiosity is fine, and it was nice of Sam to answer. However, I hope the IETF continues to welcome technical input, even if the person has no "skin in the game" or cannot publicly explain their funding source. -d > Ciao > Hannes > > On Sep 13, 2012, at 5:57 PM, Sam Hartman wrote: > > > > > > > hi. > > So, as I mentioned earlier I'm either in the camp of strongly > > preferring PCP-specific authentication or in the camp of not caring > much > > at all. > > > > I'd kind of like to find out which camp I'm in by the 21st. > > > > My nervousness is about implementation complexity. I would like to > see > > PCP authentication be something that can easily be implemented with > > open-source libraries. I know how to do that if we use an EAP library > > directly. I've managed projects doing something quite similar and I > > understand the implementation complexity. > > > > Would people familiar with PANA implementation be willing to suggest > > which implementation I should look at? I'd prefer to look at one, but > if > > there's disagreement I'd be happy to look at two. > > I'm sure you've done your analysis on this point but I'll feel more > > comfortable if I do my own. > > > > I'll be happy to share my conclusions as I suspect that there are > other > > WG participants who care about implementation complexity. > > > > If there are open-source PCP servers I'd be happy to glance at those > > just to see how things like memory management, event loop and state > > management line up. > > > > --Sam > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From yoshihiro.ohba@toshiba.co.jp Thu Sep 13 10:50:14 2012 Return-Path: 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 347EF21F860E for ; Thu, 13 Sep 2012 10:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.089 X-Spam-Level: X-Spam-Status: No, score=-8.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 quQz9X1jBr-P for ; Thu, 13 Sep 2012 10:50:13 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id DF62721F860D for ; Thu, 13 Sep 2012 10:50:12 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8DHoBJg028065; Fri, 14 Sep 2012 02:50:11 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8DHoBOt012813; Fri, 14 Sep 2012 02:50:11 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id CAA12812; Fri, 14 Sep 2012 02:50:10 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8DHoAbE025245; Fri, 14 Sep 2012 02:50:10 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8DHoAqp027098; Fri, 14 Sep 2012 02:50:10 +0900 (JST) Received: from [133.199.16.161] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAA003KMUVKMCH0@mail.po.toshiba.co.jp>; Fri, 14 Sep 2012 02:50:10 +0900 (JST) Date: Fri, 14 Sep 2012 02:50:13 +0900 From: Yoshihiro Ohba In-reply-to: <201209131457.q8DEvsAR032525@mi500.tsb.2iij.net> To: Sam Hartman Message-id: <50521CD5.9080901@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <201209131457.q8DEvsAR032525@mi500.tsb.2iij.net> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 17:50:14 -0000 Sam, There are two open source PANA implementations that are actively maintained: cpana: http://sourceforge.net/projects/cpana/ openpana: http://sourceforge.net/projects/openpana/ (cpana is implemented by Toshiba, and openpana is implemented by University of Murcia, Spain. I know implementors of both projects.) In addition to open source implementations, several ZigBee IP vendors implemented PANA as well and they inter-operate with each other. Although I have not heard a complainment from those vendors about complexity of PANA, I am happy to hear your analysis on the open source implementations. I would expect open source implementors are smart to accommodate your feedback. Regards, Yoshihiro Ohba (2012/09/13 23:57), Sam Hartman wrote: > > > hi. > So, as I mentioned earlier I'm either in the camp of strongly > preferring PCP-specific authentication or in the camp of not caring much > at all. > > I'd kind of like to find out which camp I'm in by the 21st. > > My nervousness is about implementation complexity. I would like to see > PCP authentication be something that can easily be implemented with > open-source libraries. I know how to do that if we use an EAP library > directly. I've managed projects doing something quite similar and I > understand the implementation complexity. > > Would people familiar with PANA implementation be willing to suggest > which implementation I should look at? I'd prefer to look at one, but if > there's disagreement I'd be happy to look at two. > I'm sure you've done your analysis on this point but I'll feel more > comfortable if I do my own. > > I'll be happy to share my conclusions as I suspect that there are other > WG participants who care about implementation complexity. > > If there are open-source PCP servers I'd be happy to glance at those > just to see how things like memory management, event loop and state > management line up. > > --Sam > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From hannes.tschofenig@gmx.net Thu Sep 13 11:03:21 2012 Return-Path: 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 A0F9921F8504 for ; Thu, 13 Sep 2012 11:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Y6hXKn3DHku9 for ; Thu, 13 Sep 2012 11:03:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id AB63A21F84F6 for ; Thu, 13 Sep 2012 11:03:20 -0700 (PDT) Received: (qmail invoked by alias); 13 Sep 2012 18:03:19 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.111]) [88.115.216.191] by mail.gmx.net (mp034) with SMTP; 13 Sep 2012 20:03:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19NqKtFMlpN1DWIayrzLP21TJ8gClOkF/aFTQ90R4 WzmMcc3PIrZfVH Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <00e001cd91ce$c88ee1b0$59aca510$@com> Date: Thu, 13 Sep 2012 21:03:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <276FC888-007C-4F76-BB36-F919F2904431@gmx.net> References: <20120913145755.6952gmx1@mx075.gmx.net> <1B150C40-51A4-4BD9-8915-2F9BC54B5BB9@gmx.net> <00e001cd91ce$c88ee1b0$59aca510$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 18:03:21 -0000 Hey Dan,=20 On Sep 13, 2012, at 7:42 PM, Dan Wing wrote: > However, I hope > the IETF continues to welcome technical input, even if the person has > no "skin in the game" or cannot publicly explain their funding source. Definitely. I would love to see more persons involved who are purely = driven by their desire to make the Internet work better.=20 (I fear we get a bit off topic but I had to respond to avoid creating a = wrong impression.) Ciao Hannes PS: Just in case that this statement above gets misinterpreted; I am not = saying that those who deploy technology are not welcome either...= From yoshihiro.ohba@toshiba.co.jp Thu Sep 13 23:51:35 2012 Return-Path: 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 827A821F85F0 for ; Thu, 13 Sep 2012 23:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=-2.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_25=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 phVAxQ5bc-qw for ; Thu, 13 Sep 2012 23:51:30 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2B04121F85DA for ; Thu, 13 Sep 2012 23:51:29 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q8E6pS1C025610 for ; Fri, 14 Sep 2012 15:51:28 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q8E6pShj026363 for pcp@ietf.org; Fri, 14 Sep 2012 15:51:28 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id RAA26361; Fri, 14 Sep 2012 15:51:28 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q8E6pR8b001237 for ; Fri, 14 Sep 2012 15:51:28 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8E6pRks001836; Fri, 14 Sep 2012 15:51:27 +0900 (JST) Received: from [133.199.18.176] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAB009VDV1QL1B0@mail.po.toshiba.co.jp> for pcp@ietf.org; Fri, 14 Sep 2012 15:51:27 +0900 (JST) Date: Fri, 14 Sep 2012 15:51:31 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <5052D3F3.8000605@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: Re: [pcp] WG status on PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 06:51:35 -0000 Last month I posted a rough comparison on the two PANA approaches to the PCP ML. I would like to update the comparison after working in detail on the demultiplexing approach as follows: Encapsulation/tunneling approach: - Pros: ??? - Cons: -- Encapsulation overhead -- Tight coupling of PCP and PANA is needed. One issue is that some workaround is needed to carry a PCI (PANA-Client-Initiation) message which does not fit PCP's request-response type messaging. Another issue is that double integrity protection can happen after establishing a PCP SA, where a PANA message carried in the PCP message is protected by a PANA AUTH AVP and the PCP message itself is protected by a PCP Authentication Tag. Double integrity protection can be considered as overhead. Demultiplexing/port-sharing approach: - Pros: -- No encapsulation overhead -- Loose coupling of PCP and PANA - Cons: ??? Yoshihiro Ohba (2012/09/13 20:06), Margaret Wasserman wrote: > > Hi Alper, > > I understand that you and Yoshi have done some analysis amongst > yourselves and come to a conclusion, but my understanding of the > direction from IETF 84 was that the WG wanted to go through this > analysis together and come to a conclusion about which approach was > preferred. > > Could you share your reasoning with the rest of us, instead of just > your conclusions? What do you see as the points in favor of the > side-by-side (demultiplexing) approach vs. the tunneled PANA (AKA > encapsulation) approach? Are there weaknesses to the encapsulation > approach that make the demultiplexing approach more desirable? > > Thanks, > Margaret > > > On Sep 13, 2012, at 5:13 AM, Alper Yegin wrote: > >> Hi Dave, >> >> Thank you for the summary. >> >>> The main comparison point we know about >>> is between Tunneled PANA vs Side-by-side PANA/PCP. >> >> >> >> Yoshi and I had an offline discussion and concluded that the >> so-called side-by-side PANA/PCP (or, running PANA over PCP port) is >> simple and straightforward, compared to tunneled PANA (carrying PANA >> header and payloads as PCP options -- more like PANA over PCP). So, >> we diverted our energy to the former and produced >> http://tools.ietf.org/html/draft-ohba-pcp-pana-02. >> >> I don't see problems with PANA over PCP port, or benefits with PANA >> over PCP to motivate me to work the details of PANA over PCP. >> Does anyone see? >> If not, then we'd only have PANA over PCP port to show people in the >> call. >> >> >> Alper >> >> >> >> >> >> >> >> On Sep 13, 2012, at 1:48 AM, Dave Thaler wrote: >> >>> Just to circle back on this now that the minutes are posted. >>> Relevant snippets from the minutes: >>> > Francis Dupont: How does this compare to just running PCP over DTLS? >>> > >>> > Margaret Wasserman: There is currently no draft written to specify how it >>> > would work. You can't "just run" anything over DTLS. It's not that simple. >>> Summary: we have not explicitly called a question about DTLS. Mainly >>> because there$B!G(Bs no proposal on the table. Lacking one with real >>> support, >>> the WG will go ahead with a proposal that has energy/interest >>> behind it. >>> > Alain Durand called for show of hands: >>> > For single port: 23 >>> > For two separate ports: 0 >>> Clear consensus within the room, and I$B!G(Bve seen no indication on the >>> list that this >>> consensus can$B!G(Bt be considered confirmed based on the list >>> discussion thus far. >>> > Alain Durand called for show of hands: >>> > PCP-specific messages (PCP-specific encoding of authentication information): 5 >>> > Tunneled PANA (embed PANA data within PCP options): 6/7 >>> > Side-by-side (multiplex raw PANA packets and PCP packets over same port): 5/6 >>> > Don't care: 15 >>> Room was basically evenly split between the approaches above, so no >>> consensus yet, but only about half the WG cares. >>> > Alain Durand called for show of hands: >>> > PCP-specific encoding of authentication information: 5 >>> > Some kind of PANA encapsulation: 10 or 11 >>> In my view there was a rough consensus of the room, and so far the >>> list discussion >>> hasn$B!G(Bt changed this ratio in my view. >>> > Dan Wing: request an interim meeting to discuss solutions, once they've been >>> > fleshed out a little >>> And that$B!G(Bs the step we$B!G(Bre doing next. The main comparison point >>> we know about >>> is between Tunneled PANA vs Side-by-side PANA/PCP. We can also >>> compare >>> PCP-specific though it appears to already be in the minority. If >>> there are other new >>> proposals to consider (DTLS or whatever) by then, we can, but so >>> far the inertia >>> seems to be primarily between the PANA variants. There does seem >>> to be >>> uncertainty about how they would actually work, so it$B!G(Bs important >>> that they be >>> fleshed out in enough detail that we can have informed discussion >>> at the interim >>> meeting. >>> -Dave >>> *From:*pcp-bounces@ietf.org >>> [mailto:pcp-bounces@ietf.org]*On >>> Behalf Of*Alper Yegin >>> *Sent:*Friday, August 17, 2012 1:09 AM >>> *To:*Margaret Wasserman >>> *Cc:*pcp@ietf.org >>> *Subject:*Re: [pcp] Comparison of PCP authentication >>> On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote: >>> >>> >>> Hi Dacheng, >>> The conclusion from the meeting was that we will document all three >>> approaches in our document: >>> Could the chairs please declare what the meeting conclusions and >>> next steps are. >>> Thanks. >>> Alper >>> >>> >>> - PCP Specific >>> - PANA Encapsulated in PCP >>> - PANA Demultiplexed with PCP on the same port >>> Then, we will have an interim PCP conference call to discuss the >>> trade-offs and hopefully decide between them. >>> Margaret >>> On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: >>> >>> >>> Have we got any conclusions on two approaches? Or we can just >>> support the two options in the draft for the moment and briefly >>> compare their pros and cons, can we? >>> Cheers >>> Dcheng >>> *From:*pcp-bounces@ietf.org >>> [mailto:pcp-bounces@ietf.org] >>> *On Behalf Of*Margaret Wasserman >>> *Sent:*Friday, August 10, 2012 3:21 AM >>> *To:*Dan Wing >>> *Cc:*pcp@ietf.org >>> *Subject:*Re: [pcp] Comparison of PCP authentication >>> On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: >>> >>> If I'm updating security policy on a firewall I want to be >>> able to >>> >>> audit whether that actually happened. That requires >>> authentication. >>> >>> >>> You are saying a PCP client would only want to update firewall >>> policies >>> if the PCP server supports authentication, otherwise it would >>> tell the >>> user that it cannot enable the webcam, Internet-connected NAS, >>> Internet-connected printer, etc.? >>> >>> I wont presume to guess what Sam is thinking... >>> However, I am thinking that there will be some clients that are >>> configured to perform authentication for every request. For >>> example, there is no reason for a PCP proxy, running in an >>> environment where authentication is required to do a THIRD-PARTY >>> request, to perform a useless round-trip for every THIRD-PARTY >>> request it issues. >>> Margaret >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From alper.yegin@yegin.org Thu Sep 13 23:52:40 2012 Return-Path: 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 4859D21F84F8 for ; Thu, 13 Sep 2012 23:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 nnnih0CkNlfU for ; Thu, 13 Sep 2012 23:52:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 414C221F84F1 for ; Thu, 13 Sep 2012 23:52:38 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MSuJ3-1T4x7f0f37-00RqEh; Fri, 14 Sep 2012 02:52:37 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> Date: Fri, 14 Sep 2012 09:52:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:mFHzZ2ZWn4wWeXKF18o7K+W6vTcmsddnYTmI5l7L8s2 GkmWA4yQHhp2eD80K0wLVpSDQ1fm58lR/tbVAtfaglEuDj4AnV xzJBufmTuve9E309arSrF+DCbDzCG/kHGaZqldSh2VreCg0LMy bLt942KtE2Y9ezQVju0veoMDwWP/JHrV0snv+LY+2VYjmubrdh tahWS38MmYfYiuYgbQU9n5Aw/I2gEOiTafFdl/JOwYJhRu6/9u q+jek6InUzBq8cV73uyIyzTc/ig10rJmQl3fPNxZ40gfb5pTQ6 Gv6TDLx21e4XvcSCiDAVt4yO0Miu7zYVni7qyHFypF9BRUe0hI PxgL9hRtKcYZoPIjwcOru8ahsP2sLwgiTdO83Fs32T4zs3L+nf YaLmr5ZMRJtNA== Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 06:52:40 -0000 Hi Sam, >=20 >=20 > hi. > So, as I mentioned earlier I'm either in the camp of strongly > preferring PCP-specific authentication or in the camp of not caring = much > at all. >=20 > I'd kind of like to find out which camp I'm in by the 21st. >=20 > My nervousness is about implementation complexity. Is that the only one? Or do you have other concerns as well?=20 As for the implementation complexity, I don't quite understand why PANA = (which is basically EAP over UDP) would ever be more complicated then = to-be-designed "EAP over UDP within PCP framework". While I don't see a = reason for former being more complicated, I see reasons for seeing the = latter being more complicated, as the whole thing now needs to live = within another protocol framework (read: format, flow, state machine = harmonization between the two). > I would like to see > PCP authentication be something that can easily be implemented with > open-source libraries. I know how to do that if we use an EAP library > directly. Would there be any difference between PANA and EAPoverUDP/PCP when it = comes to using EAP libraries? I don't think so. Alper > I've managed projects doing something quite similar and I > understand the implementation complexity. >=20 > Would people familiar with PANA implementation be willing to suggest > which implementation I should look at? I'd prefer to look at one, but = if > there's disagreement I'd be happy to look at two. > I'm sure you've done your analysis on this point but I'll feel more > comfortable if I do my own. >=20 > I'll be happy to share my conclusions as I suspect that there are = other > WG participants who care about implementation complexity. >=20 > If there are open-source PCP servers I'd be happy to glance at those > just to see how things like memory management, event loop and state > management line up. >=20 > --Sam > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Fri Sep 14 00:03:22 2012 Return-Path: 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 D993721F85DA for ; Fri, 14 Sep 2012 00:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_28=0.6, USER_IN_WHITELIST=-100] 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 vIDqhgb2t2Kt for ; Fri, 14 Sep 2012 00:03:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id F369621F85E6 for ; Fri, 14 Sep 2012 00:03:21 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MCbwQ-1TKhO32mIM-009aEC; Fri, 14 Sep 2012 03:03:13 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-2022-jp From: Alper Yegin In-Reply-To: <5052D3F3.8000605@toshiba.co.jp> Date: Fri, 14 Sep 2012 10:02:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <52B4EAD8-7B6A-452D-8738-72C59E357519@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5052D3F3.8000605@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:3ic7sALoxw6j5NzlkQ5jnwPjoO9pmUjiw4iDUoyNp3w 5I9Nq4gDzOytzVQtLVfkpKAa+oCcq1G71Db9R7k0sdresKZSxI gjPwGJ3Gg0pD70Z0ZlqPCzK8CaSZoZI0aRh08Z/0cz6SlcxeUA qmYr6R4v/f+UD/SzllcctCCFvVtT41Z4cYtCMRYSEV9XJJ//hm 2aiICqjLLO8UEd7lF33lO2pY+cQ1T2+gMMceJmAVCvaNMKZgpG +yKkLqS7iclctMHZGnfbEdlb7C9T3NiK8TGU6JNCdutb2LOiFR JPaUZz5i/UTxFvhssdR7a2U3PgRUWf7sKjSk6YYK3+qEtlgL7T lY3ny7z4O91XuWgierVjwOUuUfE1uCuWCQ8Te1mbk8/9OL2bQJ jPyIGDzol7waQ== Cc: pcp@ietf.org Subject: Re: [pcp] WG status on PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 07:03:23 -0000 Let me add few other things as well. > Last month I posted a rough comparison on the two PANA approaches to > the PCP ML. I would like to update the comparison after working in > detail on the demultiplexing approach as follows: >=20 > Encapsulation/tunneling approach: > - Pros: ??? > - Cons: > -- Encapsulation overhead > -- Tight coupling of PCP and PANA is needed. One issue is that some > workaround is needed to carry a PCI (PANA-Client-Initiation) message > which does not fit PCP's request-response type messaging. > Another issue is that double integrity protection can happen after > establishing a PCP SA, where a PANA message carried in the PCP message > is protected by a PANA AUTH AVP and the PCP message itself is > protected by a PCP Authentication Tag. Double integrity protection > can be considered as overhead. >=20 - PANA state machine is aligned (in fact, designed in accordance with) = EAP state machine. Now if we mix PCP into that, is PCP state machine aligned with EAP state = machine? This probably would impact the PCP design. - Defining how PANA header and payloads get encapsulated within PCP (as = opposed to over UDP) would require changes to the PANA spec. And those = changes are certainly more than simple assignment of few reserved bits = as we are doing for the port-sharing approach. > Demultiplexing/port-sharing approach: > - Pros: > -- No encapsulation overhead > -- Loose coupling of PCP and PANA >=20 In fact, there has to be a strong justification to invent protocol = nesting when the two natively runs separately and do the job already. > - Cons: ??? >=20 Alper > Yoshihiro Ohba >=20 >=20 > (2012/09/13 20:06), Margaret Wasserman wrote: >>=20 >> Hi Alper, >>=20 >> I understand that you and Yoshi have done some analysis amongst=20 >> yourselves and come to a conclusion, but my understanding of the=20 >> direction from IETF 84 was that the WG wanted to go through this=20 >> analysis together and come to a conclusion about which approach was=20= >> preferred. >>=20 >> Could you share your reasoning with the rest of us, instead of just=20= >> your conclusions? What do you see as the points in favor of the=20 >> side-by-side (demultiplexing) approach vs. the tunneled PANA (AKA=20 >> encapsulation) approach? Are there weaknesses to the encapsulation=20= >> approach that make the demultiplexing approach more desirable? >>=20 >> Thanks, >> Margaret >>=20 >>=20 >> On Sep 13, 2012, at 5:13 AM, Alper Yegin wrote: >>=20 >>> Hi Dave, >>>=20 >>> Thank you for the summary. >>>=20 >>>> The main comparison point we know about >>>> is between Tunneled PANA vs Side-by-side PANA/PCP. >>>=20 >>>=20 >>>=20 >>> Yoshi and I had an offline discussion and concluded that the=20 >>> so-called side-by-side PANA/PCP (or, running PANA over PCP port) is=20= >>> simple and straightforward, compared to tunneled PANA (carrying PANA=20= >>> header and payloads as PCP options -- more like PANA over PCP). So,=20= >>> we diverted our energy to the former and produced=20 >>> http://tools.ietf.org/html/draft-ohba-pcp-pana-02. >>>=20 >>> I don't see problems with PANA over PCP port, or benefits with PANA=20= >>> over PCP to motivate me to work the details of PANA over PCP. >>> Does anyone see? >>> If not, then we'd only have PANA over PCP port to show people in the=20= >>> call. >>>=20 >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Sep 13, 2012, at 1:48 AM, Dave Thaler wrote: >>>=20 >>>> Just to circle back on this now that the minutes are posted. >>>> Relevant snippets from the minutes: >>>>> Francis Dupont: How does this compare to just running PCP over = DTLS? >>>>>=20 >>>>> Margaret Wasserman: There is currently no draft written to specify = how it >>>>> would work. You can't "just run" anything over DTLS. It's not = that simple. >>>> Summary: we have not explicitly called a question about DTLS. = Mainly >>>> because there=1B$B!G=1B(Bs no proposal on the table. Lacking one = with real=20 >>>> support, >>>> the WG will go ahead with a proposal that has energy/interest=20 >>>> behind it. >>>>> Alain Durand called for show of hands: >>>>> For single port: 23 >>>>> For two separate ports: 0 >>>> Clear consensus within the room, and I=1B$B!G=1B(Bve seen no = indication on the=20 >>>> list that this >>>> consensus can=1B$B!G=1B(Bt be considered confirmed based on the = list=20 >>>> discussion thus far. >>>>> Alain Durand called for show of hands: >>>>> PCP-specific messages (PCP-specific encoding of authentication = information): 5 >>>>> Tunneled PANA (embed PANA data within PCP options): 6/7 >>>>> Side-by-side (multiplex raw PANA packets and PCP packets over same = port): 5/6 >>>>> Don't care: 15 >>>> Room was basically evenly split between the approaches above, so no >>>> consensus yet, but only about half the WG cares. >>>>> Alain Durand called for show of hands: >>>>> PCP-specific encoding of authentication information: 5 >>>>> Some kind of PANA encapsulation: 10 or 11 >>>> In my view there was a rough consensus of the room, and so far the=20= >>>> list discussion >>>> hasn=1B$B!G=1B(Bt changed this ratio in my view. >>>>> Dan Wing: request an interim meeting to discuss solutions, once = they've been >>>>> fleshed out a little >>>> And that=1B$B!G=1B(Bs the step we=1B$B!G=1B(Bre doing next. The = main comparison point=20 >>>> we know about >>>> is between Tunneled PANA vs Side-by-side PANA/PCP. We can also=20 >>>> compare >>>> PCP-specific though it appears to already be in the minority. If=20= >>>> there are other new >>>> proposals to consider (DTLS or whatever) by then, we can, but so=20 >>>> far the inertia >>>> seems to be primarily between the PANA variants. There does seem=20= >>>> to be >>>> uncertainty about how they would actually work, so it=1B$B!G=1B(Bs = important=20 >>>> that they be >>>> fleshed out in enough detail that we can have informed discussion=20= >>>> at the interim >>>> meeting. >>>> -Dave >>>> *From:*pcp-bounces@ietf.org=20 >>>> [mailto:pcp-bounces@ietf.org]*On=20 >>>> Behalf Of*Alper Yegin >>>> *Sent:*Friday, August 17, 2012 1:09 AM >>>> *To:*Margaret Wasserman >>>> *Cc:*pcp@ietf.org >>>> *Subject:*Re: [pcp] Comparison of PCP authentication >>>> On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote: >>>>=20 >>>>=20 >>>> Hi Dacheng, >>>> The conclusion from the meeting was that we will document all three=20= >>>> approaches in our document: >>>> Could the chairs please declare what the meeting conclusions and=20 >>>> next steps are. >>>> Thanks. >>>> Alper >>>>=20 >>>>=20 >>>> - PCP Specific >>>> - PANA Encapsulated in PCP >>>> - PANA Demultiplexed with PCP on the same port >>>> Then, we will have an interim PCP conference call to discuss the=20 >>>> trade-offs and hopefully decide between them. >>>> Margaret >>>> On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: >>>>=20 >>>>=20 >>>> Have we got any conclusions on two approaches? Or we can just=20 >>>> support the two options in the draft for the moment and briefly=20 >>>> compare their pros and cons, can we? >>>> Cheers >>>> Dcheng >>>> *From:*pcp-bounces@ietf.org=20 >>>> [mailto:pcp-bounces@ietf.org]=20 >>>> *On Behalf Of*Margaret = Wasserman >>>> *Sent:*Friday, August 10, 2012 3:21 AM >>>> *To:*Dan Wing >>>> *Cc:*pcp@ietf.org >>>> *Subject:*Re: [pcp] Comparison of PCP authentication >>>> On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: >>>>=20 >>>> If I'm updating security policy on a firewall I want to be >>>> able to >>>>=20 >>>> audit whether that actually happened. That requires >>>> authentication. >>>>=20 >>>>=20 >>>> You are saying a PCP client would only want to update firewall >>>> policies >>>> if the PCP server supports authentication, otherwise it would >>>> tell the >>>> user that it cannot enable the webcam, Internet-connected NAS, >>>> Internet-connected printer, etc.? >>>>=20 >>>> I wont presume to guess what Sam is thinking... >>>> However, I am thinking that there will be some clients that are=20 >>>> configured to perform authentication for every request. For=20 >>>> example, there is no reason for a PCP proxy, running in an=20 >>>> environment where authentication is required to do a THIRD-PARTY=20 >>>> request, to perform a useless round-trip for every THIRD-PARTY=20 >>>> request it issues. >>>> Margaret >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >>=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From zhangzhongjian@huawei.com Fri Sep 14 01:19:01 2012 Return-Path: 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 B7C2721F85F4 for ; Fri, 14 Sep 2012 01:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 NWgtk3Llsn9d for ; Fri, 14 Sep 2012 01:19:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BACB421F85F0 for ; Fri, 14 Sep 2012 01:19:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJQ86255; Fri, 14 Sep 2012 08:18:59 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 09:18:23 +0100 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 09:18:26 +0100 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Fri, 14 Sep 2012 16:17:02 +0800 From: "Zhangzongjian (Thomas)" To: "pcp@ietf.org" Thread-Topic: PCP mapping for 5350 and 5351 ports Thread-Index: AQHNklFQfx9YznzFZkayNVvmBYxVuQ== Date: Fri, 14 Sep 2012 08:17:01 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC74BF@szxeml524-mbs.china.huawei.com> References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5052D3F3.8000605@toshiba.co.jp> <52B4EAD8-7B6A-452D-8738-72C59E357519@yegin.org> In-Reply-To: <52B4EAD8-7B6A-452D-8738-72C59E357519@yegin.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [pcp] PCP mapping for 5350 and 5351 ports X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 08:19:01 -0000 Dear all In charter 11.3 of draft draft-ietf-pcp-base-26, it said:=20 The PCP server MUST NOT create mappings for the PCP ports themselves (5350 and 5351), and SHOULD have a policy control to deny mappings for other ports. In these cases, the error NOT_AUTHORIZED SHOULD be returned. We need to clarify:=20 1. What kinds port that 5350 and 5351 ports must not be used for mapping? Int= ernal ports , external ports or both? 2. What kinds protocol that the ports must not be used for mapping? UDP and o= thers? 3. It also seems that different scenarios have different result. Such as, PCP= server knows public interfaces and private interfaces in box, Only PCP se= rver in a box or both PCP server and PCP client. Regards Thomas From zhangdacheng@huawei.com Fri Sep 14 01:31:23 2012 Return-Path: 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 BE46A21F853E for ; Fri, 14 Sep 2012 01:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_28=0.6, 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 4N5R5qLFp2q9 for ; Fri, 14 Sep 2012 01:31:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B78F021F853C for ; Fri, 14 Sep 2012 01:31:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJQ87402; Fri, 14 Sep 2012 08:31:19 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 09:30:45 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 09:30:54 +0100 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.156]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Fri, 14 Sep 2012 16:30:44 +0800 From: "Zhangdacheng (Dacheng)" To: Yoshihiro Ohba , "pcp@ietf.org" Thread-Topic: [pcp] WG status on PCP authentication Thread-Index: Ac2ROKfBXzEGHHwwTde0XiHvgVohmQAFFD0AAAP3XgAAKV60gAAUGNtQ Date: Fri, 14 Sep 2012 08:30:44 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5052D3F3.8000605@toshiba.co.jp> In-Reply-To: <5052D3F3.8000605@toshiba.co.jp> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] WG status on PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 08:31:24 -0000 Hi, Yoshihiro: I remember that in one of your previous emails you mentioned that a con of = the de-multiplexing approach is its Impact on PANA specification (an Update= of RFC 5191 is needed on the use of "Reserved" field.). But you didn't men= tioned it here. Maybe I have missed some important discussion. Could you pl= ease tell me whether you have find some way to avoid it? Cheers Dacheng > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Yoshihiro Ohba > Sent: Friday, September 14, 2012 2:52 PM > To: pcp@ietf.org > Subject: Re: [pcp] WG status on PCP authentication >=20 > Last month I posted a rough comparison on the two PANA approaches to > the PCP ML. I would like to update the comparison after working in > detail on the demultiplexing approach as follows: >=20 > Encapsulation/tunneling approach: > - Pros: ??? > - Cons: > -- Encapsulation overhead > -- Tight coupling of PCP and PANA is needed. One issue is that some > workaround is needed to carry a PCI (PANA-Client-Initiation) message > which does not fit PCP's request-response type messaging. > Another issue is that double integrity protection can happen after > establishing a PCP SA, where a PANA message carried in the PCP message > is protected by a PANA AUTH AVP and the PCP message itself is > protected by a PCP Authentication Tag. Double integrity protection > can be considered as overhead. >=20 > Demultiplexing/port-sharing approach: > - Pros: > -- No encapsulation overhead > -- Loose coupling of PCP and PANA >=20 > - Cons: ??? >=20 > Yoshihiro Ohba >=20 >=20 > (2012/09/13 20:06), Margaret Wasserman wrote: > > > > Hi Alper, > > > > I understand that you and Yoshi have done some analysis amongst > > yourselves and come to a conclusion, but my understanding of the > > direction from IETF 84 was that the WG wanted to go through this > > analysis together and come to a conclusion about which approach was > > preferred. > > > > Could you share your reasoning with the rest of us, instead of just > > your conclusions? What do you see as the points in favor of the > > side-by-side (demultiplexing) approach vs. the tunneled PANA (AKA > > encapsulation) approach? Are there weaknesses to the encapsulation > > approach that make the demultiplexing approach more desirable? > > > > Thanks, > > Margaret > > > > > > On Sep 13, 2012, at 5:13 AM, Alper Yegin wrote: > > > >> Hi Dave, > >> > >> Thank you for the summary. > >> > >>> The main comparison point we know about > >>> is between Tunneled PANA vs Side-by-side PANA/PCP. > >> > >> > >> > >> Yoshi and I had an offline discussion and concluded that the > >> so-called side-by-side PANA/PCP (or, running PANA over PCP port) is > >> simple and straightforward, compared to tunneled PANA (carrying PANA > >> header and payloads as PCP options -- more like PANA over PCP). So, > >> we diverted our energy to the former and produced > >> http://tools.ietf.org/html/draft-ohba-pcp-pana-02. > >> > >> I don't see problems with PANA over PCP port, or benefits with PANA > >> over PCP to motivate me to work the details of PANA over PCP. > >> Does anyone see? > >> If not, then we'd only have PANA over PCP port to show people in the > >> call. > >> > >> > >> Alper > >> > >> > >> > >> > >> > >> > >> > >> On Sep 13, 2012, at 1:48 AM, Dave Thaler wrote: > >> > >>> Just to circle back on this now that the minutes are posted. > >>> Relevant snippets from the minutes: > >>> > Francis Dupont: How does this compare to just running PCP over DTLS= ? > >>> > > >>> > Margaret Wasserman: There is currently no draft written to specify = how > it > >>> > would work. You can't "just run" anything over DTLS. It's not t= hat > simple. > >>> Summary: we have not explicitly called a question about DTLS. Mainl= y > >>> because there's no proposal on the table. Lacking one with real > >>> support, > >>> the WG will go ahead with a proposal that has energy/interest > >>> behind it. > >>> > Alain Durand called for show of hands: > >>> > For single port: 23 > >>> > For two separate ports: 0 > >>> Clear consensus within the room, and I've seen no indication on the > >>> list that this > >>> consensus can't be considered confirmed based on the list > >>> discussion thus far. > >>> > Alain Durand called for show of hands: > >>> > PCP-specific messages (PCP-specific encoding of authentication > information): 5 > >>> > Tunneled PANA (embed PANA data within PCP options): 6/7 > >>> > Side-by-side (multiplex raw PANA packets and PCP packets over same > port): 5/6 > >>> > Don't care: 15 > >>> Room was basically evenly split between the approaches above, so no > >>> consensus yet, but only about half the WG cares. > >>> > Alain Durand called for show of hands: > >>> > PCP-specific encoding of authentication information: 5 > >>> > Some kind of PANA encapsulation: 10 or 11 > >>> In my view there was a rough consensus of the room, and so far the > >>> list discussion > >>> hasn't changed this ratio in my view. > >>> > Dan Wing: request an interim meeting to discuss solutions, once the= y've > been > >>> > fleshed out a little > >>> And that's the step we're doing next. The main comparison point > >>> we know about > >>> is between Tunneled PANA vs Side-by-side PANA/PCP. We can also > >>> compare > >>> PCP-specific though it appears to already be in the minority. If > >>> there are other new > >>> proposals to consider (DTLS or whatever) by then, we can, but so > >>> far the inertia > >>> seems to be primarily between the PANA variants. There does seem > >>> to be > >>> uncertainty about how they would actually work, so it's important > >>> that they be > >>> fleshed out in enough detail that we can have informed discussion > >>> at the interim > >>> meeting. > >>> -Dave > >>> *From:*pcp-bounces@ietf.org > >>> [mailto:pcp-bounces@ietf.org]*On > >>> Behalf Of*Alper Yegin > >>> *Sent:*Friday, August 17, 2012 1:09 AM > >>> *To:*Margaret Wasserman > >>> *Cc:*pcp@ietf.org > >>> *Subject:*Re: [pcp] Comparison of PCP authentication > >>> On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote: > >>> > >>> > >>> Hi Dacheng, > >>> The conclusion from the meeting was that we will document all three > >>> approaches in our document: > >>> Could the chairs please declare what the meeting conclusions and > >>> next steps are. > >>> Thanks. > >>> Alper > >>> > >>> > >>> - PCP Specific > >>> - PANA Encapsulated in PCP > >>> - PANA Demultiplexed with PCP on the same port > >>> Then, we will have an interim PCP conference call to discuss the > >>> trade-offs and hopefully decide between them. > >>> Margaret > >>> On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: > >>> > >>> > >>> Have we got any conclusions on two approaches? Or we can just > >>> support the two options in the draft for the moment and briefly > >>> compare their pros and cons, can we? > >>> Cheers > >>> Dcheng > >>> *From:*pcp-bounces@ietf.org > >>> [mailto:pcp-bounces@ietf.org] > >>> *On Behalf Of*Margaret > Wasserman > >>> *Sent:*Friday, August 10, 2012 3:21 AM > >>> *To:*Dan Wing > >>> *Cc:*pcp@ietf.org > >>> *Subject:*Re: [pcp] Comparison of PCP authentication > >>> On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: > >>> > >>> If I'm updating security policy on a firewall I want to be > >>> able to > >>> > >>> audit whether that actually happened. That requires > >>> authentication. > >>> > >>> > >>> You are saying a PCP client would only want to update firewall > >>> policies > >>> if the PCP server supports authentication, otherwise it would > >>> tell the > >>> user that it cannot enable the webcam, Internet-connected NAS, > >>> Internet-connected printer, etc.? > >>> > >>> I wont presume to guess what Sam is thinking... > >>> However, I am thinking that there will be some clients that are > >>> configured to perform authentication for every request. For > >>> example, there is no reason for a PCP proxy, running in an > >>> environment where authentication is required to do a THIRD-PARTY > >>> request, to perform a useless round-trip for every THIRD-PARTY > >>> request it issues. > >>> Margaret > >>> _______________________________________________ > >>> pcp mailing list > >>> pcp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pcp > >>> _______________________________________________ > >>> pcp mailing list > >>> pcp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pcp > >> > >> _______________________________________________ > >> pcp mailing list > >> pcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From margaretw42@gmail.com Fri Sep 14 02:50:13 2012 Return-Path: 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 A45C321F85A0 for ; Fri, 14 Sep 2012 02:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0grfCwOCVgZW for ; Fri, 14 Sep 2012 02:50:13 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF4CA21F8584 for ; Fri, 14 Sep 2012 02:50:12 -0700 (PDT) Received: by qafi29 with SMTP id i29so4145705qaf.10 for ; Fri, 14 Sep 2012 02:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fcNk/Kni2PUTYrgXX5Ez+h93MdyWlGQEfE8+q3K/RQA=; b=GjNv8kGVZ3MZdTflsIJ2C9eTkwW4IEsMATH0eSn7Sy58jLnI7ldHdmcQMlwknMr/ZQ Q1W1bZsOhYtBArhlEzhsry+ZGAnwCIE7iXFH4YuqWRfTR+VDBoj1h/E5S/jcuXw8PscQ 8ALEY23HhmIIAFchkFa6ZowEn3vLbtKT6KXj3N7Ur88hB1ZeE/Pr2PiH+gtaMYVf9tIp 9iNivgRGnsBzJHXjhUjWBy60mtD/HCAR+z1uxe7qfkrQ+7mXFsYAjkDo/msujAWXB9Ro zsvozp4A8OEZc6G6JLOVSve5Zy9se4HqYD4p9DGdgnslnAxtheuLvjMdab/i9ZBF2CXX 8Rsg== Received: by 10.224.178.4 with SMTP id bk4mr5969411qab.38.1347616212308; Fri, 14 Sep 2012 02:50:12 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id ff2sm1821592qab.9.2012.09.14.02.50.07 (version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 02:50:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Fri, 14 Sep 2012 05:50:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 09:50:13 -0000 Hi Alper, On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: > As for the implementation complexity, I don't quite understand why = PANA (which is basically EAP over UDP) would ever be more complicated = then to-be-designed "EAP over UDP within PCP framework". While I don't = see a reason for former being more complicated, I see reasons for seeing = the latter being more complicated, as the whole thing now needs to live = within another protocol framework (read: format, flow, state machine = harmonization between the two). I don't understand how you get away from coupling PANA and PCP, even in = the demultiplexing case where they run side-by-side on the same port. I = think a number of details are being glossed over in your latest document = when you refer to a need for an "API" between PANA and PCP... Let's start with a simple case where the PCP Client wants to initiate = and authenticated PCP request... The Client needs to ask the PANA Client to initiate authentication. = How? Will that request include any details about the mapping request = that is being made? i.e. will the PANA Client be asking for = authentication _and authorization_ to perform a particular action? Or = do we assume that a PCP client is authenticated via PANA, and that = authorization for a particular action is a separate step that is = performed as part of PCP? If they are separate, do we need a new set of = PCP error codes for the situation where an authenticated PCP client = performs an unauthorized action, or is that already covered in the PCP = spec? When the PCP Client asks the PANA Client to perform authentication, what = are the possible results that can be returned from that request, and how = are they communicated back to the PCP Client? You have only described = the success case in your document. How does this work in the case where the PCP Server is not running a = PANA Server? I _think_ that if a PCP Client asks its PANA Client to = perform authentication, and the PCP Server does support authentication, = some sort of "unsupported version" error code will be returned to the = _PCP Client_ (due to the details of your proposed demultiplexing = scheme), and that nothing will be returned to the PANA Client, at all. = We would need to make sure that secure PCP clients are specified to = handle an "unsupported version" error differently when the PANA Client = is in this particular state, but how does the PCP Client know that this = is why that error was returned? If this does happen, how does the PCP = client inform the PANA Client that it should stop trying to perform = authentication with that particular PCP Server? =20 Also, how does the PCP Client know when the _PCP Server_ is ready to = receive its request? Are we assuming that the PANA Server will not = return an indication to the PANA Client that the client has been = authenticated until _after_ it has provisioned the necessary SA on the = PANA Server? =20 What if an additional application on the same PCP Client system wants to = perform an authenticated request with the same PCP Server in the = meantime? Will that second request result in a second (interleaved) = PANA negotiation, or will the PCP Client be told that a PANA negotiation = is already pending? If the latter, how will the second PCP Client = thread by informed when the PANA negotiation has completed? (Note: The = right answer here depends heavily on whether the PANA authentication = depends, in any way, on the contents of a specific PCP request -- the = authentication vs. authentication/authorization question above). All of these questions will need to be answered, IMO, in a full = specification of the PCP/PANA demultiplexing mechanism, precisely = _because_ PCP and PANA are running separately. The "API" is where this = coupling is provided between the two "state machines", as you refer to = them. Why is this any simpler if PANA and PCP are running side-by side = than if we run PANA encapsulated in PCP? (or, if we run PCP directly = over EAP, for that matter) Margaret From margaretw42@gmail.com Fri Sep 14 02:54:52 2012 Return-Path: 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 3037A21F853A for ; Fri, 14 Sep 2012 02:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Oj0jquhcQKeW for ; Fri, 14 Sep 2012 02:54:51 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E021F8505 for ; Fri, 14 Sep 2012 02:54:51 -0700 (PDT) Received: by qcac10 with SMTP id c10so3108496qca.31 for ; Fri, 14 Sep 2012 02:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=f/saiwtQUcbohf1kA878TBZjuoPfAGB538bDWPG8/LU=; b=cLofyhsbAdWHkTgljdP1VSWxw9fWSJHolQGKBPaqmTULlk0vxuZ78R7dB7aRdlElrB ScfKBeIJnerTN5rRkqa9LUdeBPobTYI/y7G+A44xvjj/y+GJgO+SG0eCyH05mmRp+xOu j7PXEmTW99i/S1X0Rcxw2XdSlVW7iDRWS+4d7n9+0UiQLtDa9dFJkEj6SUrwokyOOGh0 O8x9Jcdpo4na/27wTRWOOMkDP4C4VFlllILTx1flHXxE0+SYgpvpJxbjkhoRKd+Q9JwS XufpwFZr05cidZN1VhXUsxPrvzxRXhC1e8cH9Fi09g1XSd6qS/iYlDevfRXFePjl3Jul +5cg== Received: by 10.224.168.83 with SMTP id t19mr6066667qay.8.1347616491003; Fri, 14 Sep 2012 02:54:51 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id fl3sm1841576qab.3.2012.09.14.02.54.45 (version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 02:54:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-21--57902247 From: Margaret Wasserman In-Reply-To: Date: Fri, 14 Sep 2012 05:54:45 -0400 Message-Id: <9E7B01DA-81BD-4F67-A2AE-68CAAD6F0376@lilacglade.org> References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> To: Margaret Wasserman X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 09:54:52 -0000 --Apple-Mail-21--57902247 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I made one important typo here that I should fix: On Sep 14, 2012, at 5:50 AM, Margaret Wasserman wrote: >=20 > How does this work in the case where the PCP Server is not running a = PANA Server? I _think_ that if a PCP Client asks its PANA Client to = perform authentication, and the PCP Server does support authentication, = some sort of "unsupported version" error code will be returned to the = _PCP Client_ (due to the details of your proposed s/PCP Server does support authentication/PCP Server _doesn't_ support = authentication > demultiplexing scheme), and that nothing will be returned to the PANA = Client, at all. We would need to make sure that secure PCP clients are = specified to handle an "unsupported version" error differently when the = PANA Client is in this particular state, but how does the PCP Client = know that this is why that error was returned? If this does happen, how = does the PCP client inform the PANA Client that it should stop trying to = perform authentication with that particular PCP Server? =20 Margaret --Apple-Mail-21--57902247 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

How does this = work in the case where the PCP Server is not running a PANA Server? =  I _think_ that if a PCP Client asks its PANA Client to perform = authentication, and the PCP Server does support authentication, some = sort of "unsupported version" error code will be returned to the _PCP = Client_ (due to the details of your proposed =

s/PCP Server does support = authentication/PCP Server _doesn't_ support = authentication

demultiplexing= scheme), and that nothing will be returned to the PANA Client, at all. =  We would need to make sure that secure PCP clients are specified = to handle an "unsupported version" error differently when the PANA = Client is in this particular state, but how does the PCP Client know = that this is why that error was returned?  If this does happen, how = does the PCP client inform the PANA Client that it should stop trying to = perform authentication with that particular PCP Server? =  

Margaret

= --Apple-Mail-21--57902247-- From margaretw42@gmail.com Fri Sep 14 02:58:18 2012 Return-Path: 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 378B321F854E for ; Fri, 14 Sep 2012 02:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 4wAnGVES9VLJ for ; Fri, 14 Sep 2012 02:58:17 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85A0921F853A for ; Fri, 14 Sep 2012 02:58:17 -0700 (PDT) Received: by qcac10 with SMTP id c10so3110551qca.31 for ; Fri, 14 Sep 2012 02:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=EyjHCQEVHUfRCPGYVyfpqi0mrdyulN6uyMNE6cb/w0w=; b=sfe6SPB3cLPEmSgVI2gIePPnFg0Twp5V2Ig6ArlfBehPXle6egO7fBkQv0FczgMfcQ zHeJcu/BBiunN/79sEWxzmuP3r2RDVPO1acnZkIRQ4KxkF3axmId5BoboefN+H7o5f/5 7PR8msX/tV++7SxSlAcofeYdbHlDSbdE51morhpMf2Eh/wGMlHDyhu8c5S8z4F1io35w 7a1xGjbuUPEPPjPNVb3AVszdg/2jpl6kYd88LRr+/obw/VGZPlbSna8avhMYs0nSUsOQ gRRXLXtYNCo3eBpzaTKmHuJW9ZEg8mUJv93kNWDJAJGi+p23OKavWzfhxsa9jbOSxNYG oHjw== Received: by 10.224.178.4 with SMTP id bk4mr6007252qab.38.1347616696957; Fri, 14 Sep 2012 02:58:16 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id dw9sm1843811qab.7.2012.09.14.02.58.15 (version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 02:58:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Fri, 14 Sep 2012 05:58:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> To: Margaret Wasserman X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 09:58:18 -0000 And another typo that I should clarify (sorry, it's early here... :-)): On Sep 14, 2012, at 5:50 AM, Margaret Wasserman wrote: > Also, how does the PCP Client know when the _PCP Server_ is ready to = receive its request? Are we assuming that the PANA Server will not = return an indication to the PANA Client that the client has been = authenticated until _after_ it has provisioned the necessary SA on the = PANA Server? s/SA on the PANA Server/SA on the PCP Server Margaret= From yoshihiro.ohba@toshiba.co.jp Fri Sep 14 05:29:56 2012 Return-Path: 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 ADB3421F84D5 for ; Fri, 14 Sep 2012 05:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.622 X-Spam-Level: X-Spam-Status: No, score=-6.622 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_25=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 1RhZPHFW2uuI for ; Fri, 14 Sep 2012 05:29:55 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA9A21F84B8 for ; Fri, 14 Sep 2012 05:29:55 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8ECTqOh006349; Fri, 14 Sep 2012 21:29:52 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8ECTqlM027058; Fri, 14 Sep 2012 21:29:52 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id XAA27057; Fri, 14 Sep 2012 21:29:52 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8ECTqin028909; Fri, 14 Sep 2012 21:29:52 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8ECTqb5013226; Fri, 14 Sep 2012 21:29:52 +0900 (JST) Received: from [133.199.17.78] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAC009H5APQL4H0@mail.po.toshiba.co.jp>; Fri, 14 Sep 2012 21:29:51 +0900 (JST) Date: Fri, 14 Sep 2012 21:29:57 +0900 From: Yoshihiro Ohba In-reply-to: To: "Zhangdacheng (Dacheng)" Message-id: <50532345.4060109@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5052D3F3.8000605@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] WG status on PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 12:29:56 -0000 Hi Dacheng, A good question. Actually both approaches has some impact on RFC 5191 to allow PANA to run over a non-PANA port (which would require updating RFC 5191). This made me think that the need for updating RFC 5191 to use the Reserved field in the demultiplexing approach is not considered as a cons. Regards, Yoshihiro Ohba (2012/09/14 17:30), Zhangdacheng (Dacheng) wrote: > Hi, Yoshihiro: > > I remember that in one of your previous emails you mentioned that a con of the de-multiplexing approach is its Impact on PANA specification (an Update of RFC 5191 is needed on the use of "Reserved" field.). But you didn't mentioned it here. Maybe I have missed some important discussion. Could you please tell me whether you have find some way to avoid it? > > Cheers > > Dacheng > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> Yoshihiro Ohba >> Sent: Friday, September 14, 2012 2:52 PM >> To: pcp@ietf.org >> Subject: Re: [pcp] WG status on PCP authentication >> >> Last month I posted a rough comparison on the two PANA approaches to >> the PCP ML. I would like to update the comparison after working in >> detail on the demultiplexing approach as follows: >> >> Encapsulation/tunneling approach: >> - Pros: ??? >> - Cons: >> -- Encapsulation overhead >> -- Tight coupling of PCP and PANA is needed. One issue is that some >> workaround is needed to carry a PCI (PANA-Client-Initiation) message >> which does not fit PCP's request-response type messaging. >> Another issue is that double integrity protection can happen after >> establishing a PCP SA, where a PANA message carried in the PCP message >> is protected by a PANA AUTH AVP and the PCP message itself is >> protected by a PCP Authentication Tag. Double integrity protection >> can be considered as overhead. >> >> Demultiplexing/port-sharing approach: >> - Pros: >> -- No encapsulation overhead >> -- Loose coupling of PCP and PANA >> >> - Cons: ??? >> >> Yoshihiro Ohba >> >> >> (2012/09/13 20:06), Margaret Wasserman wrote: >>> >>> Hi Alper, >>> >>> I understand that you and Yoshi have done some analysis amongst >>> yourselves and come to a conclusion, but my understanding of the >>> direction from IETF 84 was that the WG wanted to go through this >>> analysis together and come to a conclusion about which approach was >>> preferred. >>> >>> Could you share your reasoning with the rest of us, instead of just >>> your conclusions? What do you see as the points in favor of the >>> side-by-side (demultiplexing) approach vs. the tunneled PANA (AKA >>> encapsulation) approach? Are there weaknesses to the encapsulation >>> approach that make the demultiplexing approach more desirable? >>> >>> Thanks, >>> Margaret >>> >>> >>> On Sep 13, 2012, at 5:13 AM, Alper Yegin wrote: >>> >>>> Hi Dave, >>>> >>>> Thank you for the summary. >>>> >>>>> The main comparison point we know about >>>>> is between Tunneled PANA vs Side-by-side PANA/PCP. >>>> >>>> >>>> >>>> Yoshi and I had an offline discussion and concluded that the >>>> so-called side-by-side PANA/PCP (or, running PANA over PCP port) is >>>> simple and straightforward, compared to tunneled PANA (carrying PANA >>>> header and payloads as PCP options -- more like PANA over PCP). So, >>>> we diverted our energy to the former and produced >>>> http://tools.ietf.org/html/draft-ohba-pcp-pana-02. >>>> >>>> I don't see problems with PANA over PCP port, or benefits with PANA >>>> over PCP to motivate me to work the details of PANA over PCP. >>>> Does anyone see? >>>> If not, then we'd only have PANA over PCP port to show people in the >>>> call. >>>> >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sep 13, 2012, at 1:48 AM, Dave Thaler wrote: >>>> >>>>> Just to circle back on this now that the minutes are posted. >>>>> Relevant snippets from the minutes: >>>>>> Francis Dupont: How does this compare to just running PCP over DTLS? >>>>>> >>>>>> Margaret Wasserman: There is currently no draft written to specify how >> it >>>>>> would work. You can't "just run" anything over DTLS. It's not that >> simple. >>>>> Summary: we have not explicitly called a question about DTLS. Mainly >>>>> because there's no proposal on the table. Lacking one with real >>>>> support, >>>>> the WG will go ahead with a proposal that has energy/interest >>>>> behind it. >>>>>> Alain Durand called for show of hands: >>>>>> For single port: 23 >>>>>> For two separate ports: 0 >>>>> Clear consensus within the room, and I've seen no indication on the >>>>> list that this >>>>> consensus can't be considered confirmed based on the list >>>>> discussion thus far. >>>>>> Alain Durand called for show of hands: >>>>>> PCP-specific messages (PCP-specific encoding of authentication >> information): 5 >>>>>> Tunneled PANA (embed PANA data within PCP options): 6/7 >>>>>> Side-by-side (multiplex raw PANA packets and PCP packets over same >> port): 5/6 >>>>>> Don't care: 15 >>>>> Room was basically evenly split between the approaches above, so no >>>>> consensus yet, but only about half the WG cares. >>>>>> Alain Durand called for show of hands: >>>>>> PCP-specific encoding of authentication information: 5 >>>>>> Some kind of PANA encapsulation: 10 or 11 >>>>> In my view there was a rough consensus of the room, and so far the >>>>> list discussion >>>>> hasn't changed this ratio in my view. >>>>>> Dan Wing: request an interim meeting to discuss solutions, once they've >> been >>>>>> fleshed out a little >>>>> And that's the step we're doing next. The main comparison point >>>>> we know about >>>>> is between Tunneled PANA vs Side-by-side PANA/PCP. We can also >>>>> compare >>>>> PCP-specific though it appears to already be in the minority. If >>>>> there are other new >>>>> proposals to consider (DTLS or whatever) by then, we can, but so >>>>> far the inertia >>>>> seems to be primarily between the PANA variants. There does seem >>>>> to be >>>>> uncertainty about how they would actually work, so it's important >>>>> that they be >>>>> fleshed out in enough detail that we can have informed discussion >>>>> at the interim >>>>> meeting. >>>>> -Dave >>>>> *From:*pcp-bounces@ietf.org >>>>> [mailto:pcp-bounces@ietf.org]*On >>>>> Behalf Of*Alper Yegin >>>>> *Sent:*Friday, August 17, 2012 1:09 AM >>>>> *To:*Margaret Wasserman >>>>> *Cc:*pcp@ietf.org >>>>> *Subject:*Re: [pcp] Comparison of PCP authentication >>>>> On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote: >>>>> >>>>> >>>>> Hi Dacheng, >>>>> The conclusion from the meeting was that we will document all three >>>>> approaches in our document: >>>>> Could the chairs please declare what the meeting conclusions and >>>>> next steps are. >>>>> Thanks. >>>>> Alper >>>>> >>>>> >>>>> - PCP Specific >>>>> - PANA Encapsulated in PCP >>>>> - PANA Demultiplexed with PCP on the same port >>>>> Then, we will have an interim PCP conference call to discuss the >>>>> trade-offs and hopefully decide between them. >>>>> Margaret >>>>> On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: >>>>> >>>>> >>>>> Have we got any conclusions on two approaches? Or we can just >>>>> support the two options in the draft for the moment and briefly >>>>> compare their pros and cons, can we? >>>>> Cheers >>>>> Dcheng >>>>> *From:*pcp-bounces@ietf.org >>>>> [mailto:pcp-bounces@ietf.org] >>>>> *On Behalf Of*Margaret >> Wasserman >>>>> *Sent:*Friday, August 10, 2012 3:21 AM >>>>> *To:*Dan Wing >>>>> *Cc:*pcp@ietf.org >>>>> *Subject:*Re: [pcp] Comparison of PCP authentication >>>>> On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: >>>>> >>>>> If I'm updating security policy on a firewall I want to be >>>>> able to >>>>> >>>>> audit whether that actually happened. That requires >>>>> authentication. >>>>> >>>>> >>>>> You are saying a PCP client would only want to update firewall >>>>> policies >>>>> if the PCP server supports authentication, otherwise it would >>>>> tell the >>>>> user that it cannot enable the webcam, Internet-connected NAS, >>>>> Internet-connected printer, etc.? >>>>> >>>>> I wont presume to guess what Sam is thinking... >>>>> However, I am thinking that there will be some clients that are >>>>> configured to perform authentication for every request. For >>>>> example, there is no reason for a PCP proxy, running in an >>>>> environment where authentication is required to do a THIRD-PARTY >>>>> request, to perform a useless round-trip for every THIRD-PARTY >>>>> request it issues. >>>>> Margaret >>>>> _______________________________________________ >>>>> pcp mailing list >>>>> pcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pcp >>>>> _______________________________________________ >>>>> pcp mailing list >>>>> pcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pcp >>>> >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>> >>> >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>> >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > From internet-drafts@ietf.org Fri Sep 14 06:01:50 2012 Return-Path: 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 9E67921F8523; Fri, 14 Sep 2012 06:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] 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 wiL9bWSNxKGd; Fri, 14 Sep 2012 06:01:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4315C21F851A; Fri, 14 Sep 2012 06:01:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120914130150.12326.27384.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 06:01:50 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:01:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : Universal Plug and Play (UPnP) Internet Gateway Device (= IGD)-Port Control Protocol (PCP) Interworking Function Author(s) : Mohamed Boucadair Francis Dupont Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-upnp-igd-interworking-03.txt Pages : 23 Date : 2012-09-14 Abstract: This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. An UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP (Customer Premises) routers to allow for transparent NAT control in environments where UPnP IGD is used in the LAN side and PCP in the external side of the CP router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-upnp-igd-interworking-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-upnp-igd-interworking-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yoshihiro.ohba@toshiba.co.jp Fri Sep 14 06:22:38 2012 Return-Path: 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 87A4321F84A5 for ; Fri, 14 Sep 2012 06:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.289 X-Spam-Level: X-Spam-Status: No, score=-7.289 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 LW4DmWPAyD20 for ; Fri, 14 Sep 2012 06:22:37 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 42F3721F8470 for ; Fri, 14 Sep 2012 06:22:37 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8EDMVwY016361 for ; Fri, 14 Sep 2012 22:22:31 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8EDMVNS014468 for pcp@ietf.org; Fri, 14 Sep 2012 22:22:31 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA14467; Fri, 14 Sep 2012 22:22:31 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8EDMU3R009705 for ; Fri, 14 Sep 2012 22:22:31 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8EDMU0p009827; Fri, 14 Sep 2012 22:22:30 +0900 (JST) Received: from [133.199.17.78] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAC0091CD5HL1K0@mail.po.toshiba.co.jp> for pcp@ietf.org; Fri, 14 Sep 2012 22:22:30 +0900 (JST) Date: Fri, 14 Sep 2012 22:22:35 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <50532F9B.9030104@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:22:38 -0000 Hi Margaret, I agree that there is a room to specify more details in the pana-pcp draft to address your comments. In general some interactions are needed between an "AKM (Authentication and Key Management) function" and the base PCP funtion. On the other hand, if my understanding is correct, the needed set of interactions between an AKM function and the base PCP functions are not much different regardless of whether the AKM function is PANA or PCP-specific, and therefore I think the interactions do not have to be considered as a disadvantage of PANA-based approaches. Please correct me if my understanding is wrong. Yoshihiro Ohba (2012/09/14 18:50), Margaret Wasserman wrote: > > Hi Alper, > > On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: >> As for the implementation complexity, I don't quite understand why PANA (which is basically EAP over UDP) would ever be more complicated then to-be-designed "EAP over UDP within PCP framework". While I don't see a reason for former being more complicated, I see reasons for seeing the latter being more complicated, as the whole thing now needs to live within another protocol framework (read: format, flow, state machine harmonization between the two). > > I don't understand how you get away from coupling PANA and PCP, even in the demultiplexing case where they run side-by-side on the same port. I think a number of details are being glossed over in your latest document when you refer to a need for an "API" between PANA and PCP... > > Let's start with a simple case where the PCP Client wants to initiate and authenticated PCP request... > > The Client needs to ask the PANA Client to initiate authentication. How? Will that request include any details about the mapping request that is being made? i.e. will the PANA Client be asking for authentication _and authorization_ to perform a particular action? Or do we assume that a PCP client is authenticated via PANA, and that authorization for a particular action is a separate step that is performed as part of PCP? If they are separate, do we need a new set of PCP error codes for the situation where an authenticated PCP client performs an unauthorized action, or is that already covered in the PCP spec? > > When the PCP Client asks the PANA Client to perform authentication, what are the possible results that can be returned from that request, and how are they communicated back to the PCP Client? You have only described the success case in your document. > > How does this work in the case where the PCP Server is not running a PANA Server? I _think_ that if a PCP Client asks its PANA Client to perform authentication, and the PCP Server does support authentication, some sort of "unsupported version" error code will be returned to the _PCP Client_ (due to the details of your proposed demultiplexing scheme), and that nothing will be returned to the PANA Client, at all. We would need to make sure that secure PCP clients are specified to handle an "unsupported version" error differently when the PANA Client is in this particular state, but how does the PCP Client know that this is why that error was returned? If this does happen, how does the PCP client inform the PANA Client that it should stop trying to perform authentication with that particular PCP Server? > > Also, how does the PCP Client know when the _PCP Server_ is ready to receive its request? Are we assuming that the PANA Server will not return an indication to the PANA Client that the client has been authenticated until _after_ it has provisioned the necessary SA on the PANA Server? > > What if an additional application on the same PCP Client system wants to perform an authenticated request with the same PCP Server in the meantime? Will that second request result in a second (interleaved) PANA negotiation, or will the PCP Client be told that a PANA negotiation is already pending? If the latter, how will the second PCP Client thread by informed when the PANA negotiation has completed? (Note: The right answer here depends heavily on whether the PANA authentication depends, in any way, on the contents of a specific PCP request -- the authentication vs. authentication/authorization question above). > > All of these questions will need to be answered, IMO, in a full specification of the PCP/PANA demultiplexing mechanism, precisely _because_ PCP and PANA are running separately. The "API" is where this coupling is provided between the two "state machines", as you refer to them. Why is this any simpler if PANA and PCP are running side-by side than if we run PANA encapsulated in PCP? (or, if we run PCP directly over EAP, for that matter) > > Margaret > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From alper.yegin@yegin.org Fri Sep 14 06:38:40 2012 Return-Path: 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 9C40321F8496 for ; Fri, 14 Sep 2012 06:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qXMUvx2lW1tf for ; Fri, 14 Sep 2012 06:38:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD5E21F84F6 for ; Fri, 14 Sep 2012 06:38:39 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M2t4w-1TUsGP2g4s-00sgmf; Fri, 14 Sep 2012 09:38:36 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Fri, 14 Sep 2012 16:38:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6657E02B-2D08-40BE-A567-F8AB976F2741@yegin.org> References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:P7RqW3c3dIiFSBXZzEwiQL/ggW0N8tIAkfNIZ+m8qCH KL28YvOmmlY86LHvcIPjXXn5RtqUycOAZQEvJW4dK4QTDlveTV pe0v+R6YqoXLKvfgo2AX0NP3DusQy4EJQlZ04W33f47XXrUFuq NB2zNBb0kIP6rQtORhKc3rnVCJJH69Jkpbw8PJvRb0s4CW7xhe 3Mzj025dyKhnm6SkuwvyRs8Y5T7EPQXpjdgijvsO2CoY2Jz/n2 X57TAc/xIE3LO0jwQrcCzBuvotZj+/pJYZvjJ8hZMpo7Qv+Bn1 RZXxh+BDbY7uSFfBKRBQvEdnxDDOIjvJE2jxurJUcSlZ0CoRpU O8X4H1FDcemmru21CbKbdbYshZRhkrcA5F5UZIv6x/b+yggHs0 sBTqnue/TIzPA== Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:38:40 -0000 Hi Margaret, Your below questions are implementation specific.=20 Let me answer them to describe how this can be implemented in one way. = Certainly there are other ways to implement them. >=20 > On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: >> As for the implementation complexity, I don't quite understand why = PANA (which is basically EAP over UDP) would ever be more complicated = then to-be-designed "EAP over UDP within PCP framework". While I don't = see a reason for former being more complicated, I see reasons for seeing = the latter being more complicated, as the whole thing now needs to live = within another protocol framework (read: format, flow, state machine = harmonization between the two). >=20 > I don't understand how you get away from coupling PANA and PCP, even = in the demultiplexing case where they run side-by-side on the same port. = I think a number of details are being glossed over in your latest = document when you refer to a need for an "API" between PANA and PCP=85 >=20 Association or binding of state between PANA and PCP is common on both. But there are different degrees of "coupling". Or where you couple them. = Are we coupling the state generated/maintained between the two, or are = we coupling the protocols themselves. You could say, a host configures a care-of address using DHCP, and uses = that IP address with Mobile IP, hence DHCP and Mobile IP are coupled. Or, you could invent carrying DHCP over Mobile IP, and call that = coupling too. Another more relevant example: Running IKE for IPsec, or running IKE = over IPsec (however you do it). > Let's start with a simple case where the PCP Client wants to initiate = and authenticated PCP request... >=20 > The Client needs to ask the PANA Client to initiate authentication. = How? =20 PCP software triggers the PaC to perform authentication.=20 Like how IKE gets triggered when IPsec SA needs to be setup. > Will that request include any details about the mapping request that = is being made? i.e. will the PANA Client be asking for authentication = _and authorization_ to perform a particular action? Or do we assume = that a PCP client is authenticated via PANA, and that authorization for = a particular action is a separate step that is performed as part of PCP? = If they are separate, do we need a new set of PCP error codes for the = situation where an authenticated PCP client performs an unauthorized = action, or is that already covered in the PCP spec? That trigger I mentioned above will include two pieces of information: = 1. Indication that this is an auth/authz for PCP, 2. IP address of the = PAA (which is same as the PCP server). > When the PCP Client asks the PANA Client to perform authentication, = what are the possible results that can be returned from that request, = and how are they communicated back to the PCP Client? You have only = described the success case in your document. PANA already generates success and failure results. This result will be = conveyed to the PCP client via the API. If the result is success, also the PCP_AUTH_KEY and PANA Session ID and = PANA Key ID need to be passed via that interface.=20 >=20 > How does this work in the case where the PCP Server is not running a = PANA Server? I _think_ that if a PCP Client asks its PANA Client to = perform authentication, and the PCP Server does support authentication, = some sort of "unsupported version" error code will be returned to the = _PCP Client_ (due to the details of your proposed demultiplexing = scheme), and that nothing will be returned to the PANA Client, at all. = We would need to make sure that secure PCP clients are specified to = handle an "unsupported version" error differently when the PANA Client = is in this particular state, but how does the PCP Client know that this = is why that error was returned? If this does happen, how does the PCP = client inform the PANA Client that it should stop trying to perform = authentication with that particular PCP Server? =20 >=20 I'd like to first understand how the client-side decides when to use = authentication, and when not to? Can you, or someone, explain that? Once I understand the scenarios we = are trying to cover, I can come back and answer your question. > Also, how does the PCP Client know when the _PCP Server_ is ready to = receive its request? Are we assuming that the PANA Server will not = return an indication to the PANA Client that the client has been = authenticated until _after_ it has provisioned the necessary SA on the = PANA Server? =20 >=20 The order of events is: 1. PANA is executed 2. PaC provides the results to the PCP client 3. PCP client contacts PCP server, using authentication tag generated = with the SA from step 2. 4. Upon encountering new SA, PCP server contacts the PAA to obtain the = matching parameters (or, the PAA had already pushed those params to PCP = server after 1. These are different implementation choices=85..) > What if an additional application on the same PCP Client system wants = to perform an authenticated request with the same PCP Server in the = meantime? Will that second request result in a second (interleaved) = PANA negotiation, or will the PCP Client be told that a PANA negotiation = is already pending? If the latter, how will the second PCP Client = thread by informed when the PANA negotiation has completed? (Note: The = right answer here depends heavily on whether the PANA authentication = depends, in any way, on the contents of a specific PCP request -- the = authentication vs. authentication/authorization question above). >=20 Second API call can be told that there is already an ongoing = authentication and wait for the result. Or, maybe it says "OK" but does not generate a second PANA session = because the same PANA session (or, more specifically the security = association generated by it) can be used with both PCP requests. > All of these questions will need to be answered, IMO, in a full = specification of the PCP/PANA demultiplexing mechanism, precisely = _because_ PCP and PANA are running separately. =20 Errr, I don't think so. None of these are impacting the over-the-wire = behavior (i.e., the "protocol"), but they are all about implementation = -- not something we need to put in the protocol specs.=20 If we were to use EAP over PCP, do you think we need to define how EAP = methods interface with EAP which interfaces with PCP. How one triggers = the other and gets the results back. I don't think so.=20 > The "API" is where this coupling is provided between the two "state = machines", as you refer to them. Why is this any simpler if PANA and = PCP are running side-by side than if we run PANA encapsulated in PCP? = (or, if we run PCP directly over EAP, for that matter) >=20 Please see the top part about my "coupling" response.=20 If you run two protocols side by side, you point how one can trigger the = other. And ideally, triggers target meaningful states. E.g., one = protocol triggers other to run, and at the end of execution the result = is returned (PCP triggers PANA to execute). If you run one protocol inside another, then you have to nest their = state machines, and unless you are purely lucky, that cannot work = automatically w/o aligning their state machines. (Like I said, PANA = state machine is designed the way it is in accordance with the EAP state = machine.) Alper > Margaret >=20 >=20 From repenno@cisco.com Fri Sep 14 06:54:51 2012 Return-Path: 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 27C6321F851A for ; Fri, 14 Sep 2012 06:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 9Ze3AE4nl7pk for ; Fri, 14 Sep 2012 06:54:50 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E7FD221F84F9 for ; Fri, 14 Sep 2012 06:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8914; q=dns/txt; s=iport; t=1347630890; x=1348840490; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hlERgKrITJMgL+3EhSXWokVHHkKFMBQ7wehCDevlJA0=; b=FLPxNqn8zg4rdXShbbVOkSjWh2BZDPjlbpy33tXA73rIBaRdNoif2zFV E8fT3YgCS3kVD+1Sfc2lseSm9GavWzZ2mEhQWJ8B77mOj9Q/4/BCgPyWN QoPQSkW9XudC/63OgCRm2jkEp17zcAkTFjirxUr62T3RmL/GWQN7f5eBu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwGANw2U1CtJV2b/2dsb2JhbABFt1iEJYEHgiABAQEEAQEBDwFbCwwGAQgRAwECAU8GCx0IAgQBDQUih1wDDAubF5Y2DYlPBIoyY4ZoA5QMgVWLF4MhgWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="121633801" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 14 Sep 2012 13:54:49 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8EDsnTu003018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Sep 2012 13:54:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 08:54:48 -0500 From: "Reinaldo Penno (repenno)" To: Alper Yegin , Margaret Wasserman Thread-Topic: [pcp] PANA implementatinos to consider Thread-Index: AQHNkn4yjZ2M1VBAI0utcSTd+o7QS5eJunqA Date: Fri, 14 Sep 2012 13:54:48 +0000 Message-ID: In-Reply-To: <6657E02B-2D08-40BE-A567-F8AB976F2741@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.94.79] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004 x-tm-as-result: No--48.410300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <75208AB89B6EFB48A7CF32720742A340@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:54:51 -0000 I've been following this discussion and my preference would be to avoid having a design that requires a 'control protocol' between PCP and something else. We should reuse other IETF standards whenever possible but I would prefer everything to be part of a single protocol. Having a separate protocol would mean significant more test and effort for productization due to interactions, new CLIs, unforeseen state machine issues, etc.=20 We will certainly even face all kinds of backward/forward compatibility issues between PCP, PANA (as an example) and whatever control protocol will run between them due to different features and evolution timeline. Although one can argue that PCP and PANA will run together as one entity the next step would be somebody asking for them to be decoupled and able to run anywhere. This train is never late. -----Original Message----- From: Alper Yegin Date: Fri, 14 Sep 2012 16:38:17 +0300 To: Margaret Wasserman Cc: Subject: Re: [pcp] PANA implementatinos to consider >Hi Margaret, > >Your below questions are implementation specific. >Let me answer them to describe how this can be implemented in one way. >Certainly there are other ways to implement them. > >>=20 >> On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: >>> As for the implementation complexity, I don't quite understand why >>>PANA (which is basically EAP over UDP) would ever be more complicated >>>then to-be-designed "EAP over UDP within PCP framework". While I don't >>>see a reason for former being more complicated, I see reasons for >>>seeing the latter being more complicated, as the whole thing now needs >>>to live within another protocol framework (read: format, flow, state >>>machine harmonization between the two). >>=20 >> I don't understand how you get away from coupling PANA and PCP, even in >>the demultiplexing case where they run side-by-side on the same port. I >>think a number of details are being glossed over in your latest document >>when you refer to a need for an "API" between PANA and PCP=8A >>=20 > >Association or binding of state between PANA and PCP is common on both. >But there are different degrees of "coupling". Or where you couple them. >Are we coupling the state generated/maintained between the two, or are we >coupling the protocols themselves. > >You could say, a host configures a care-of address using DHCP, and uses >that IP address with Mobile IP, hence DHCP and Mobile IP are coupled. >Or, you could invent carrying DHCP over Mobile IP, and call that coupling >too. > >Another more relevant example: Running IKE for IPsec, or running IKE over >IPsec (however you do it). > > >> Let's start with a simple case where the PCP Client wants to initiate >>and authenticated PCP request... >>=20 >> The Client needs to ask the PANA Client to initiate authentication. >>How? =20 > >PCP software triggers the PaC to perform authentication. >Like how IKE gets triggered when IPsec SA needs to be setup. > > >> Will that request include any details about the mapping request that is >>being made? i.e. will the PANA Client be asking for authentication _and >>authorization_ to perform a particular action? Or do we assume that a >>PCP client is authenticated via PANA, and that authorization for a >>particular action is a separate step that is performed as part of PCP? >>If they are separate, do we need a new set of PCP error codes for the >>situation where an authenticated PCP client performs an unauthorized >>action, or is that already covered in the PCP spec? > > >That trigger I mentioned above will include two pieces of information: 1. >Indication that this is an auth/authz for PCP, 2. IP address of the PAA >(which is same as the PCP server). > > >> When the PCP Client asks the PANA Client to perform authentication, >>what are the possible results that can be returned from that request, >>and how are they communicated back to the PCP Client? You have only >>described the success case in your document. > >PANA already generates success and failure results. This result will be >conveyed to the PCP client via the API. >If the result is success, also the PCP_AUTH_KEY and PANA Session ID and >PANA Key ID need to be passed via that interface. > > > >>=20 >> How does this work in the case where the PCP Server is not running a >>PANA Server? I _think_ that if a PCP Client asks its PANA Client to >>perform authentication, and the PCP Server does support authentication, >>some sort of "unsupported version" error code will be returned to the >>_PCP Client_ (due to the details of your proposed demultiplexing >>scheme), and that nothing will be returned to the PANA Client, at all. >>We would need to make sure that secure PCP clients are specified to >>handle an "unsupported version" error differently when the PANA Client >>is in this particular state, but how does the PCP Client know that this >>is why that error was returned? If this does happen, how does the PCP >>client inform the PANA Client that it should stop trying to perform >>authentication with that particular PCP Server? >>=20 > >I'd like to first understand how the client-side decides when to use >authentication, and when not to? >Can you, or someone, explain that? Once I understand the scenarios we are >trying to cover, I can come back and answer your question. > > >> Also, how does the PCP Client know when the _PCP Server_ is ready to >>receive its request? Are we assuming that the PANA Server will not >>return an indication to the PANA Client that the client has been >>authenticated until _after_ it has provisioned the necessary SA on the >>PANA Server? =20 >>=20 > >The order of events is: > >1. PANA is executed >2. PaC provides the results to the PCP client >3. PCP client contacts PCP server, using authentication tag generated >with the SA from step 2. >4. Upon encountering new SA, PCP server contacts the PAA to obtain the >matching parameters (or, the PAA had already pushed those params to PCP >server after 1. These are different implementation choices=8A..) > > > >> What if an additional application on the same PCP Client system wants >>to perform an authenticated request with the same PCP Server in the >>meantime? Will that second request result in a second (interleaved) >>PANA negotiation, or will the PCP Client be told that a PANA negotiation >>is already pending? If the latter, how will the second PCP Client >>thread by informed when the PANA negotiation has completed? (Note: The >>right answer here depends heavily on whether the PANA authentication >>depends, in any way, on the contents of a specific PCP request -- the >>authentication vs. authentication/authorization question above). >>=20 > >Second API call can be told that there is already an ongoing >authentication and wait for the result. >Or, maybe it says "OK" but does not generate a second PANA session >because the same PANA session (or, more specifically the security >association generated by it) can be used with both PCP requests. > > >> All of these questions will need to be answered, IMO, in a full >>specification of the PCP/PANA demultiplexing mechanism, precisely >>_because_ PCP and PANA are running separately. > >Errr, I don't think so. None of these are impacting the over-the-wire >behavior (i.e., the "protocol"), but they are all about implementation -- >not something we need to put in the protocol specs. > > >If we were to use EAP over PCP, do you think we need to define how EAP >methods interface with EAP which interfaces with PCP. How one triggers >the other and gets the results back. I don't think so. > > > >> The "API" is where this coupling is provided between the two "state >>machines", as you refer to them. Why is this any simpler if PANA and >>PCP are running side-by side than if we run PANA encapsulated in PCP? >>(or, if we run PCP directly over EAP, for that matter) >>=20 > > >Please see the top part about my "coupling" response. > >If you run two protocols side by side, you point how one can trigger the >other. And ideally, triggers target meaningful states. E.g., one protocol >triggers other to run, and at the end of execution the result is returned >(PCP triggers PANA to execute). >If you run one protocol inside another, then you have to nest their state >machines, and unless you are purely lucky, that cannot work automatically >w/o aligning their state machines. (Like I said, PANA state machine is >designed the way it is in accordance with the EAP state machine.) > >Alper > > > > > > > > > > >> Margaret >>=20 >>=20 > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From margaretw42@gmail.com Fri Sep 14 06:58:13 2012 Return-Path: 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 BCCD821F8528 for ; Fri, 14 Sep 2012 06:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gofmn90iFJnL for ; Fri, 14 Sep 2012 06:58:11 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4DB721F84DF for ; Fri, 14 Sep 2012 06:58:10 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so5397320vbb.31 for ; Fri, 14 Sep 2012 06:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=lMH9fNte4Ab6t0Ntd+VVgPZm18+wTIKqapzm4FJGTEk=; b=WVj7XC1DbR/gM69pOO0bB1n39fZEqIlW3LOS/3wF7+GvdD329YkLZh9JtDiGqln48W 3UmuFZPJjujk3+bvnfbYDcDdMGkoGsvsNpLSsIOw4JdoeKIVO5dT6+Ckw+7yaRyPaJMR xumSEXOzRfg4Qoe3RGoTZpZxNneigPrjTJGMnMBmXFy79afOCbqjeC5fAfCttrYcVOo2 VVsTsi/gd3JCuEzju0Tkv/9M1dH8D6u+dx073lOeL/M572gVoajlCElw6EheRj8Hau/b StkHPHCdLAYho/wNAIfR0AI98+rP2bmulQ0umKbl9DqdDewkhXWDfXUBl3Ap3TKlOlgT 4T8w== Received: by 10.221.0.138 with SMTP id nm10mr2201876vcb.38.1347631085111; Fri, 14 Sep 2012 06:58:05 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id j13sm272371vej.3.2012.09.14.06.58.03 (version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 06:58:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <50532F9B.9030104@toshiba.co.jp> Date: Fri, 14 Sep 2012 09:58:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0923263C-0A11-4399-BDF9-6C4648E94344@lilacglade.org> References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> <50532F9B.9030104@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:58:13 -0000 Hi Yoshi, On Sep 14, 2012, at 9:22 AM, Yoshihiro Ohba wrote: > On the other hand, if my understanding is correct, the needed set of > interactions between an AKM function and the base PCP functions are > not much different regardless of whether the AKM function is PANA or > PCP-specific, and therefore I think the interactions do not have to be > considered as a disadvantage of PANA-based approaches. I agree with you -- the need for integration of the authentication and = PCP functions is effectively the same in all of the approaches we've = considered. I was responding to Alper's assertion that this sort of = integration was not needed in the side-by-side (or demux) approach. There are some things (like how we handle authentication requests to PCP = Servers that don't implement PANA) that will work better in either = encapsulation approach than in the demux approach. There are other = things (like the need to check that the fields in the PCP header match = corresponding fields in the PANA packet that are specific to the PANA = encapsulation approach). And there are other issues (like the need to = respecify and re-implement some functions already included in PANA) that = will be specific to a PCP-Specific approach. These are the things that = the WG needs to understand and decide between, IMO. To understand these = things, we need to understand each of the PANA-based approaches in more = detail than is currently documented. Margaret From wim.henderickx@alcatel-lucent.com Fri Sep 14 07:00:11 2012 Return-Path: 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 CDFF421F851E for ; Fri, 14 Sep 2012 07:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 k9JJ6bPtUyv6 for ; Fri, 14 Sep 2012 07:00:10 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA1721F84F1 for ; Fri, 14 Sep 2012 07:00:10 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8EDvD96032326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Sep 2012 16:00:01 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 14 Sep 2012 15:59:28 +0200 From: "Henderickx, Wim (Wim)" To: "'repenno@cisco.com'" , "'alper.yegin@yegin.org'" , "'margaretw42@gmail.com'" Date: Fri, 14 Sep 2012 15:59:27 +0200 Thread-Topic: [pcp] PANA implementatinos to consider Thread-Index: AQHNkn4yjZ2M1VBAI0utcSTd+o7QS5eJunqAgAAi2B0= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "'pcp@ietf.org'" Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:00:11 -0000 KzEgYWxsIEkgaGF2ZSBzZWVuIHNvIGZhciBpcyB2ZXJ5IGNvbXBsZXggZm9yIHNpbXBsZSBhdXRo ZW50aWNhdGlvbiBvZiBwY3AuIExldCdzIGVtYmVkIGl0IGludG8gcGNwLg0KDQpDaGVlcnMsDQpX aW0NCl9fX19fX19fX19fX19fX19fDQpzZW50IGZyb20gYmxhY2tiZXJyeQ0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykgW21haWx0 bzpyZXBlbm5vQGNpc2NvLmNvbV0NClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE0LCAyMDEyIDAz OjU0IFBNClRvOiBBbHBlciBZZWdpbiA8YWxwZXIueWVnaW5AeWVnaW4ub3JnPjsgTWFyZ2FyZXQg V2Fzc2VybWFuIDxtYXJnYXJldHc0MkBnbWFpbC5jb20+DQpDYzogcGNwQGlldGYub3JnIDxwY3BA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3BjcF0gUEFOQSBpbXBsZW1lbnRhdGlub3MgdG8gY29u c2lkZXINCg0KSSd2ZSBiZWVuIGZvbGxvd2luZyB0aGlzIGRpc2N1c3Npb24gYW5kIG15IHByZWZl cmVuY2Ugd291bGQgYmUgdG8gYXZvaWQNCmhhdmluZyBhIGRlc2lnbiB0aGF0IHJlcXVpcmVzIGEg J2NvbnRyb2wgcHJvdG9jb2wnIGJldHdlZW4gUENQIGFuZA0Kc29tZXRoaW5nIGVsc2UuIFdlIHNo b3VsZCByZXVzZSBvdGhlciBJRVRGIHN0YW5kYXJkcyB3aGVuZXZlciBwb3NzaWJsZSBidXQNCkkg d291bGQgcHJlZmVyIGV2ZXJ5dGhpbmcgdG8gYmUgcGFydCBvZiBhIHNpbmdsZSBwcm90b2NvbC4g SGF2aW5nIGENCnNlcGFyYXRlIHByb3RvY29sIHdvdWxkIG1lYW4gc2lnbmlmaWNhbnQgbW9yZSB0 ZXN0IGFuZCBlZmZvcnQgZm9yDQpwcm9kdWN0aXphdGlvbiBkdWUgdG8gaW50ZXJhY3Rpb25zLCBu ZXcgQ0xJcywgdW5mb3Jlc2VlbiBzdGF0ZSBtYWNoaW5lDQppc3N1ZXMsIGV0Yy4gDQoNCldlIHdp bGwgY2VydGFpbmx5IGV2ZW4gZmFjZSBhbGwga2luZHMgb2YgYmFja3dhcmQvZm9yd2FyZCBjb21w YXRpYmlsaXR5DQppc3N1ZXMgYmV0d2VlbiBQQ1AsIFBBTkEgKGFzIGFuIGV4YW1wbGUpIGFuZCB3 aGF0ZXZlciBjb250cm9sIHByb3RvY29sDQp3aWxsIHJ1biBiZXR3ZWVuIHRoZW0gZHVlIHRvIGRp ZmZlcmVudCBmZWF0dXJlcyBhbmQgZXZvbHV0aW9uIHRpbWVsaW5lLg0KDQpBbHRob3VnaCBvbmUg Y2FuIGFyZ3VlIHRoYXQgUENQIGFuZCBQQU5BIHdpbGwgcnVuIHRvZ2V0aGVyIGFzIG9uZSBlbnRp dHkNCnRoZSBuZXh0IHN0ZXAgd291bGQgYmUgc29tZWJvZHkgYXNraW5nIGZvciB0aGVtIHRvIGJl IGRlY291cGxlZCBhbmQgYWJsZQ0KdG8gcnVuIGFueXdoZXJlLiBUaGlzIHRyYWluIGlzIG5ldmVy IGxhdGUuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFscGVyIFllZ2lu IDxhbHBlci55ZWdpbkB5ZWdpbi5vcmc+DQpEYXRlOiBGcmksIDE0IFNlcCAyMDEyIDE2OjM4OjE3 ICswMzAwDQpUbzogTWFyZ2FyZXQgV2Fzc2VybWFuIDxtYXJnYXJldHc0MkBnbWFpbC5jb20+DQpD YzogPHBjcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcGNwXSBQQU5BIGltcGxlbWVudGF0aW5v cyB0byBjb25zaWRlcg0KDQo+SGkgTWFyZ2FyZXQsDQo+DQo+WW91ciBiZWxvdyBxdWVzdGlvbnMg YXJlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLg0KPkxldCBtZSBhbnN3ZXIgdGhlbSB0byBkZXNj cmliZSBob3cgdGhpcyBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gb25lIHdheS4NCj5DZXJ0YWlubHkg dGhlcmUgYXJlIG90aGVyIHdheXMgdG8gaW1wbGVtZW50IHRoZW0uDQo+DQo+PiANCj4+IE9uIFNl cCAxNCwgMjAxMiwgYXQgMjo1MiBBTSwgQWxwZXIgWWVnaW4gd3JvdGU6DQo+Pj4gQXMgZm9yIHRo ZSBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LCBJIGRvbid0IHF1aXRlIHVuZGVyc3RhbmQgd2h5 DQo+Pj5QQU5BICh3aGljaCBpcyBiYXNpY2FsbHkgRUFQIG92ZXIgVURQKSB3b3VsZCBldmVyIGJl IG1vcmUgY29tcGxpY2F0ZWQNCj4+PnRoZW4gdG8tYmUtZGVzaWduZWQgIkVBUCBvdmVyIFVEUCB3 aXRoaW4gUENQIGZyYW1ld29yayIuIFdoaWxlIEkgZG9uJ3QNCj4+PnNlZSBhIHJlYXNvbiBmb3Ig Zm9ybWVyIGJlaW5nIG1vcmUgY29tcGxpY2F0ZWQsIEkgc2VlIHJlYXNvbnMgZm9yDQo+Pj5zZWVp bmcgdGhlIGxhdHRlciBiZWluZyBtb3JlIGNvbXBsaWNhdGVkLCBhcyB0aGUgd2hvbGUgdGhpbmcg bm93IG5lZWRzDQo+Pj50byBsaXZlIHdpdGhpbiBhbm90aGVyIHByb3RvY29sIGZyYW1ld29yayAo cmVhZDogZm9ybWF0LCBmbG93LCBzdGF0ZQ0KPj4+bWFjaGluZSBoYXJtb25pemF0aW9uIGJldHdl ZW4gdGhlIHR3bykuDQo+PiANCj4+IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgeW91IGdldCBhd2F5 IGZyb20gY291cGxpbmcgUEFOQSBhbmQgUENQLCBldmVuIGluDQo+PnRoZSBkZW11bHRpcGxleGlu ZyBjYXNlIHdoZXJlIHRoZXkgcnVuIHNpZGUtYnktc2lkZSBvbiB0aGUgc2FtZSBwb3J0LiAgSQ0K Pj50aGluayBhIG51bWJlciBvZiBkZXRhaWxzIGFyZSBiZWluZyBnbG9zc2VkIG92ZXIgaW4geW91 ciBsYXRlc3QgZG9jdW1lbnQNCj4+d2hlbiB5b3UgcmVmZXIgdG8gYSBuZWVkIGZvciBhbiAiQVBJ IiBiZXR3ZWVuIFBBTkEgYW5kIFBDUMWgDQo+PiANCj4NCj5Bc3NvY2lhdGlvbiBvciBiaW5kaW5n IG9mIHN0YXRlIGJldHdlZW4gUEFOQSBhbmQgUENQIGlzIGNvbW1vbiBvbiBib3RoLg0KPkJ1dCB0 aGVyZSBhcmUgZGlmZmVyZW50IGRlZ3JlZXMgb2YgImNvdXBsaW5nIi4gT3Igd2hlcmUgeW91IGNv dXBsZSB0aGVtLg0KPkFyZSB3ZSBjb3VwbGluZyB0aGUgc3RhdGUgZ2VuZXJhdGVkL21haW50YWlu ZWQgYmV0d2VlbiB0aGUgdHdvLCBvciBhcmUgd2UNCj5jb3VwbGluZyB0aGUgcHJvdG9jb2xzIHRo ZW1zZWx2ZXMuDQo+DQo+WW91IGNvdWxkIHNheSwgYSBob3N0IGNvbmZpZ3VyZXMgYSBjYXJlLW9m IGFkZHJlc3MgdXNpbmcgREhDUCwgYW5kIHVzZXMNCj50aGF0IElQIGFkZHJlc3Mgd2l0aCBNb2Jp bGUgSVAsIGhlbmNlIERIQ1AgYW5kIE1vYmlsZSBJUCBhcmUgY291cGxlZC4NCj5PciwgeW91IGNv dWxkIGludmVudCBjYXJyeWluZyBESENQIG92ZXIgTW9iaWxlIElQLCBhbmQgY2FsbCB0aGF0IGNv dXBsaW5nDQo+dG9vLg0KPg0KPkFub3RoZXIgbW9yZSByZWxldmFudCBleGFtcGxlOiBSdW5uaW5n IElLRSBmb3IgSVBzZWMsIG9yIHJ1bm5pbmcgSUtFIG92ZXINCj5JUHNlYyAoaG93ZXZlciB5b3Ug ZG8gaXQpLg0KPg0KPg0KPj4gTGV0J3Mgc3RhcnQgd2l0aCBhIHNpbXBsZSBjYXNlIHdoZXJlIHRo ZSBQQ1AgQ2xpZW50IHdhbnRzIHRvIGluaXRpYXRlDQo+PmFuZCBhdXRoZW50aWNhdGVkIFBDUCBy ZXF1ZXN0Li4uDQo+PiANCj4+IFRoZSBDbGllbnQgbmVlZHMgdG8gYXNrIHRoZSBQQU5BIENsaWVu dCB0byBpbml0aWF0ZSBhdXRoZW50aWNhdGlvbi4NCj4+SG93PyAgDQo+DQo+UENQIHNvZnR3YXJl IHRyaWdnZXJzIHRoZSBQYUMgdG8gcGVyZm9ybSBhdXRoZW50aWNhdGlvbi4NCj5MaWtlIGhvdyBJ S0UgZ2V0cyB0cmlnZ2VyZWQgd2hlbiBJUHNlYyBTQSBuZWVkcyB0byBiZSBzZXR1cC4NCj4NCj4N Cj4+IFdpbGwgdGhhdCByZXF1ZXN0IGluY2x1ZGUgYW55IGRldGFpbHMgYWJvdXQgdGhlIG1hcHBp bmcgcmVxdWVzdCB0aGF0IGlzDQo+PmJlaW5nIG1hZGU/ICBpLmUuIHdpbGwgdGhlIFBBTkEgQ2xp ZW50IGJlIGFza2luZyBmb3IgYXV0aGVudGljYXRpb24gX2FuZA0KPj5hdXRob3JpemF0aW9uXyB0 byBwZXJmb3JtIGEgcGFydGljdWxhciBhY3Rpb24/ICBPciBkbyB3ZSBhc3N1bWUgdGhhdCBhDQo+ PlBDUCBjbGllbnQgaXMgYXV0aGVudGljYXRlZCB2aWEgUEFOQSwgYW5kIHRoYXQgYXV0aG9yaXph dGlvbiBmb3IgYQ0KPj5wYXJ0aWN1bGFyIGFjdGlvbiBpcyBhIHNlcGFyYXRlIHN0ZXAgdGhhdCBp cyBwZXJmb3JtZWQgYXMgcGFydCBvZiBQQ1A/DQo+PklmIHRoZXkgYXJlIHNlcGFyYXRlLCBkbyB3 ZSBuZWVkIGEgbmV3IHNldCBvZiBQQ1AgZXJyb3IgY29kZXMgZm9yIHRoZQ0KPj5zaXR1YXRpb24g d2hlcmUgYW4gYXV0aGVudGljYXRlZCBQQ1AgY2xpZW50IHBlcmZvcm1zIGFuIHVuYXV0aG9yaXpl ZA0KPj5hY3Rpb24sIG9yIGlzIHRoYXQgYWxyZWFkeSBjb3ZlcmVkIGluIHRoZSBQQ1Agc3BlYz8N Cj4NCj4NCj5UaGF0IHRyaWdnZXIgSSBtZW50aW9uZWQgYWJvdmUgd2lsbCBpbmNsdWRlIHR3byBw aWVjZXMgb2YgaW5mb3JtYXRpb246IDEuDQo+SW5kaWNhdGlvbiB0aGF0IHRoaXMgaXMgYW4gYXV0 aC9hdXRoeiBmb3IgUENQLCAyLiBJUCBhZGRyZXNzIG9mIHRoZSBQQUENCj4od2hpY2ggaXMgc2Ft ZSBhcyB0aGUgUENQIHNlcnZlcikuDQo+DQo+DQo+PiBXaGVuIHRoZSBQQ1AgQ2xpZW50IGFza3Mg dGhlIFBBTkEgQ2xpZW50IHRvIHBlcmZvcm0gYXV0aGVudGljYXRpb24sDQo+PndoYXQgYXJlIHRo ZSBwb3NzaWJsZSByZXN1bHRzIHRoYXQgY2FuIGJlIHJldHVybmVkIGZyb20gdGhhdCByZXF1ZXN0 LA0KPj5hbmQgaG93IGFyZSB0aGV5IGNvbW11bmljYXRlZCBiYWNrIHRvIHRoZSBQQ1AgQ2xpZW50 PyAgWW91IGhhdmUgb25seQ0KPj5kZXNjcmliZWQgdGhlIHN1Y2Nlc3MgY2FzZSBpbiB5b3VyIGRv Y3VtZW50Lg0KPg0KPlBBTkEgYWxyZWFkeSBnZW5lcmF0ZXMgc3VjY2VzcyBhbmQgZmFpbHVyZSBy ZXN1bHRzLiBUaGlzIHJlc3VsdCB3aWxsIGJlDQo+Y29udmV5ZWQgdG8gdGhlIFBDUCBjbGllbnQg dmlhIHRoZSBBUEkuDQo+SWYgdGhlIHJlc3VsdCBpcyBzdWNjZXNzLCBhbHNvIHRoZSBQQ1BfQVVU SF9LRVkgYW5kIFBBTkEgU2Vzc2lvbiBJRCBhbmQNCj5QQU5BIEtleSBJRCBuZWVkIHRvIGJlIHBh c3NlZCB2aWEgdGhhdCBpbnRlcmZhY2UuDQo+DQo+DQo+DQo+PiANCj4+IEhvdyBkb2VzIHRoaXMg d29yayBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgUENQIFNlcnZlciBpcyBub3QgcnVubmluZyBhDQo+ PlBBTkEgU2VydmVyPyAgSSBfdGhpbmtfIHRoYXQgaWYgYSBQQ1AgQ2xpZW50IGFza3MgaXRzIFBB TkEgQ2xpZW50IHRvDQo+PnBlcmZvcm0gYXV0aGVudGljYXRpb24sIGFuZCB0aGUgUENQIFNlcnZl ciBkb2VzIHN1cHBvcnQgYXV0aGVudGljYXRpb24sDQo+PnNvbWUgc29ydCBvZiAidW5zdXBwb3J0 ZWQgdmVyc2lvbiIgZXJyb3IgY29kZSB3aWxsIGJlIHJldHVybmVkIHRvIHRoZQ0KPj5fUENQIENs aWVudF8gKGR1ZSB0byB0aGUgZGV0YWlscyBvZiB5b3VyIHByb3Bvc2VkIGRlbXVsdGlwbGV4aW5n DQo+PnNjaGVtZSksIGFuZCB0aGF0IG5vdGhpbmcgd2lsbCBiZSByZXR1cm5lZCB0byB0aGUgUEFO QSBDbGllbnQsIGF0IGFsbC4NCj4+V2Ugd291bGQgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBzZWN1 cmUgUENQIGNsaWVudHMgYXJlIHNwZWNpZmllZCB0bw0KPj5oYW5kbGUgYW4gInVuc3VwcG9ydGVk IHZlcnNpb24iIGVycm9yIGRpZmZlcmVudGx5IHdoZW4gdGhlIFBBTkEgQ2xpZW50DQo+PmlzIGlu IHRoaXMgcGFydGljdWxhciBzdGF0ZSwgYnV0IGhvdyBkb2VzIHRoZSBQQ1AgQ2xpZW50IGtub3cg dGhhdCB0aGlzDQo+PmlzIHdoeSB0aGF0IGVycm9yIHdhcyByZXR1cm5lZD8gIElmIHRoaXMgZG9l cyBoYXBwZW4sIGhvdyBkb2VzIHRoZSBQQ1ANCj4+Y2xpZW50IGluZm9ybSB0aGUgUEFOQSBDbGll bnQgdGhhdCBpdCBzaG91bGQgc3RvcCB0cnlpbmcgdG8gcGVyZm9ybQ0KPj5hdXRoZW50aWNhdGlv biB3aXRoIHRoYXQgcGFydGljdWxhciBQQ1AgU2VydmVyPw0KPj4gDQo+DQo+SSdkIGxpa2UgdG8g Zmlyc3QgdW5kZXJzdGFuZCBob3cgdGhlIGNsaWVudC1zaWRlIGRlY2lkZXMgd2hlbiB0byB1c2UN Cj5hdXRoZW50aWNhdGlvbiwgYW5kIHdoZW4gbm90IHRvPw0KPkNhbiB5b3UsIG9yIHNvbWVvbmUs IGV4cGxhaW4gdGhhdD8gT25jZSBJIHVuZGVyc3RhbmQgdGhlIHNjZW5hcmlvcyB3ZSBhcmUNCj50 cnlpbmcgdG8gY292ZXIsIEkgY2FuIGNvbWUgYmFjayBhbmQgYW5zd2VyIHlvdXIgcXVlc3Rpb24u DQo+DQo+DQo+PiBBbHNvLCBob3cgZG9lcyB0aGUgUENQIENsaWVudCBrbm93IHdoZW4gdGhlIF9Q Q1AgU2VydmVyXyBpcyByZWFkeSB0bw0KPj5yZWNlaXZlIGl0cyByZXF1ZXN0PyAgQXJlIHdlIGFz c3VtaW5nIHRoYXQgdGhlIFBBTkEgU2VydmVyIHdpbGwgbm90DQo+PnJldHVybiBhbiBpbmRpY2F0 aW9uIHRvIHRoZSBQQU5BIENsaWVudCB0aGF0IHRoZSBjbGllbnQgaGFzIGJlZW4NCj4+YXV0aGVu dGljYXRlZCB1bnRpbCBfYWZ0ZXJfIGl0IGhhcyBwcm92aXNpb25lZCB0aGUgbmVjZXNzYXJ5IFNB IG9uIHRoZQ0KPj5QQU5BIFNlcnZlcj8gIA0KPj4gDQo+DQo+VGhlIG9yZGVyIG9mIGV2ZW50cyBp czoNCj4NCj4xLiBQQU5BIGlzIGV4ZWN1dGVkDQo+Mi4gUGFDIHByb3ZpZGVzIHRoZSByZXN1bHRz IHRvIHRoZSBQQ1AgY2xpZW50DQo+My4gUENQIGNsaWVudCBjb250YWN0cyBQQ1Agc2VydmVyLCB1 c2luZyAgYXV0aGVudGljYXRpb24gdGFnIGdlbmVyYXRlZA0KPndpdGggdGhlIFNBIGZyb20gc3Rl cCAyLg0KPjQuIFVwb24gZW5jb3VudGVyaW5nIG5ldyBTQSwgUENQIHNlcnZlciBjb250YWN0cyB0 aGUgUEFBIHRvIG9idGFpbiB0aGUNCj5tYXRjaGluZyBwYXJhbWV0ZXJzIChvciwgdGhlIFBBQSBo YWQgYWxyZWFkeSBwdXNoZWQgdGhvc2UgcGFyYW1zIHRvIFBDUA0KPnNlcnZlciBhZnRlciAxLiBU aGVzZSBhcmUgZGlmZmVyZW50IGltcGxlbWVudGF0aW9uIGNob2ljZXPFoC4uKQ0KPg0KPg0KPg0K Pj4gV2hhdCBpZiBhbiBhZGRpdGlvbmFsIGFwcGxpY2F0aW9uIG9uIHRoZSBzYW1lIFBDUCBDbGll bnQgc3lzdGVtIHdhbnRzDQo+PnRvIHBlcmZvcm0gYW4gYXV0aGVudGljYXRlZCByZXF1ZXN0IHdp dGggdGhlIHNhbWUgUENQIFNlcnZlciBpbiB0aGUNCj4+bWVhbnRpbWU/ICBXaWxsIHRoYXQgc2Vj b25kIHJlcXVlc3QgcmVzdWx0IGluIGEgc2Vjb25kIChpbnRlcmxlYXZlZCkNCj4+UEFOQSBuZWdv dGlhdGlvbiwgb3Igd2lsbCB0aGUgUENQIENsaWVudCBiZSB0b2xkIHRoYXQgYSBQQU5BIG5lZ290 aWF0aW9uDQo+PmlzIGFscmVhZHkgcGVuZGluZz8gIElmIHRoZSBsYXR0ZXIsIGhvdyB3aWxsIHRo ZSBzZWNvbmQgUENQIENsaWVudA0KPj50aHJlYWQgYnkgaW5mb3JtZWQgd2hlbiB0aGUgUEFOQSBu ZWdvdGlhdGlvbiBoYXMgY29tcGxldGVkPyAgKE5vdGU6ICBUaGUNCj4+cmlnaHQgYW5zd2VyIGhl cmUgZGVwZW5kcyBoZWF2aWx5IG9uIHdoZXRoZXIgdGhlIFBBTkEgYXV0aGVudGljYXRpb24NCj4+ ZGVwZW5kcywgaW4gYW55IHdheSwgb24gdGhlIGNvbnRlbnRzIG9mIGEgc3BlY2lmaWMgUENQIHJl cXVlc3QgLS0gdGhlDQo+PmF1dGhlbnRpY2F0aW9uIHZzLiBhdXRoZW50aWNhdGlvbi9hdXRob3Jp emF0aW9uIHF1ZXN0aW9uIGFib3ZlKS4NCj4+IA0KPg0KPlNlY29uZCBBUEkgY2FsbCBjYW4gYmUg dG9sZCB0aGF0IHRoZXJlIGlzIGFscmVhZHkgYW4gb25nb2luZw0KPmF1dGhlbnRpY2F0aW9uIGFu ZCB3YWl0IGZvciB0aGUgcmVzdWx0Lg0KPk9yLCBtYXliZSBpdCBzYXlzICJPSyIgYnV0IGRvZXMg bm90IGdlbmVyYXRlIGEgc2Vjb25kIFBBTkEgc2Vzc2lvbg0KPmJlY2F1c2UgdGhlIHNhbWUgUEFO QSBzZXNzaW9uIChvciwgbW9yZSBzcGVjaWZpY2FsbHkgdGhlIHNlY3VyaXR5DQo+YXNzb2NpYXRp b24gZ2VuZXJhdGVkIGJ5IGl0KSBjYW4gYmUgdXNlZCB3aXRoIGJvdGggUENQIHJlcXVlc3RzLg0K Pg0KPg0KPj4gQWxsIG9mIHRoZXNlIHF1ZXN0aW9ucyB3aWxsIG5lZWQgdG8gYmUgYW5zd2VyZWQs IElNTywgaW4gYSBmdWxsDQo+PnNwZWNpZmljYXRpb24gb2YgdGhlIFBDUC9QQU5BIGRlbXVsdGlw bGV4aW5nIG1lY2hhbmlzbSwgcHJlY2lzZWx5DQo+Pl9iZWNhdXNlXyBQQ1AgYW5kIFBBTkEgYXJl IHJ1bm5pbmcgc2VwYXJhdGVseS4NCj4NCj5FcnJyLCBJIGRvbid0IHRoaW5rIHNvLiBOb25lIG9m IHRoZXNlIGFyZSBpbXBhY3RpbmcgdGhlIG92ZXItdGhlLXdpcmUNCj5iZWhhdmlvciAoaS5lLiwg dGhlICJwcm90b2NvbCIpLCBidXQgdGhleSBhcmUgYWxsIGFib3V0IGltcGxlbWVudGF0aW9uIC0t DQo+bm90IHNvbWV0aGluZyB3ZSBuZWVkIHRvIHB1dCBpbiB0aGUgcHJvdG9jb2wgc3BlY3MuDQo+ DQo+DQo+SWYgd2Ugd2VyZSB0byB1c2UgRUFQIG92ZXIgUENQLCBkbyB5b3UgdGhpbmsgd2UgbmVl ZCB0byBkZWZpbmUgaG93IEVBUA0KPm1ldGhvZHMgaW50ZXJmYWNlIHdpdGggRUFQIHdoaWNoIGlu dGVyZmFjZXMgd2l0aCBQQ1AuIEhvdyBvbmUgdHJpZ2dlcnMNCj50aGUgb3RoZXIgYW5kIGdldHMg dGhlIHJlc3VsdHMgYmFjay4gSSBkb24ndCB0aGluayBzby4NCj4NCj4NCj4NCj4+IFRoZSAiQVBJ IiBpcyB3aGVyZSB0aGlzIGNvdXBsaW5nIGlzIHByb3ZpZGVkIGJldHdlZW4gdGhlIHR3byAic3Rh dGUNCj4+bWFjaGluZXMiLCBhcyB5b3UgcmVmZXIgdG8gdGhlbS4gIFdoeSBpcyB0aGlzIGFueSBz aW1wbGVyIGlmIFBBTkEgYW5kDQo+PlBDUCBhcmUgcnVubmluZyBzaWRlLWJ5IHNpZGUgdGhhbiBp ZiB3ZSBydW4gUEFOQSBlbmNhcHN1bGF0ZWQgaW4gUENQPw0KPj4ob3IsIGlmIHdlIHJ1biBQQ1Ag ZGlyZWN0bHkgb3ZlciBFQVAsIGZvciB0aGF0IG1hdHRlcikNCj4+IA0KPg0KPg0KPlBsZWFzZSBz ZWUgdGhlIHRvcCBwYXJ0IGFib3V0IG15ICJjb3VwbGluZyIgcmVzcG9uc2UuDQo+DQo+SWYgeW91 IHJ1biB0d28gcHJvdG9jb2xzIHNpZGUgYnkgc2lkZSwgeW91IHBvaW50IGhvdyBvbmUgY2FuIHRy aWdnZXIgdGhlDQo+b3RoZXIuIEFuZCBpZGVhbGx5LCB0cmlnZ2VycyB0YXJnZXQgbWVhbmluZ2Z1 bCBzdGF0ZXMuIEUuZy4sIG9uZSBwcm90b2NvbA0KPnRyaWdnZXJzIG90aGVyIHRvIHJ1biwgYW5k IGF0IHRoZSBlbmQgb2YgZXhlY3V0aW9uIHRoZSByZXN1bHQgaXMgcmV0dXJuZWQNCj4oUENQIHRy aWdnZXJzIFBBTkEgdG8gZXhlY3V0ZSkuDQo+SWYgeW91IHJ1biBvbmUgcHJvdG9jb2wgaW5zaWRl IGFub3RoZXIsIHRoZW4geW91IGhhdmUgdG8gbmVzdCB0aGVpciBzdGF0ZQ0KPm1hY2hpbmVzLCBh bmQgdW5sZXNzIHlvdSBhcmUgcHVyZWx5IGx1Y2t5LCB0aGF0IGNhbm5vdCB3b3JrIGF1dG9tYXRp Y2FsbHkNCj53L28gYWxpZ25pbmcgdGhlaXIgc3RhdGUgbWFjaGluZXMuIChMaWtlIEkgc2FpZCwg UEFOQSBzdGF0ZSBtYWNoaW5lIGlzDQo+ZGVzaWduZWQgdGhlIHdheSBpdCBpcyBpbiBhY2NvcmRh bmNlIHdpdGggdGhlIEVBUCBzdGF0ZSBtYWNoaW5lLikNCj4NCj5BbHBlcg0KPg0KPg0KPg0KPg0K Pg0KPg0KPg0KPg0KPg0KPg0KPj4gTWFyZ2FyZXQNCj4+IA0KPj4gDQo+DQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5wY3AgbWFpbGluZyBsaXN0DQo+ cGNwQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY3AN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBjcCBt YWlsaW5nIGxpc3QNCnBjcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wY3ANCg== From yoshihiro.ohba@toshiba.co.jp Fri Sep 14 07:19:22 2012 Return-Path: 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 8D04021F84C5 for ; Fri, 14 Sep 2012 07:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 j9UbIwTWcZBY for ; Fri, 14 Sep 2012 07:19:22 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id D39B721F84B5 for ; Fri, 14 Sep 2012 07:19:21 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8EEJJT7025257; Fri, 14 Sep 2012 23:19:19 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8EEJJcI029187; Fri, 14 Sep 2012 23:19:19 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id ZAA29186; Fri, 14 Sep 2012 23:19:19 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8EEJItJ019113; Fri, 14 Sep 2012 23:19:18 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8EEJIkD004067; Fri, 14 Sep 2012 23:19:18 +0900 (JST) Received: from [133.199.17.130] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAC009AKFS5L4I0@mail.po.toshiba.co.jp>; Fri, 14 Sep 2012 23:19:18 +0900 (JST) Date: Fri, 14 Sep 2012 23:19:23 +0900 From: Yoshihiro Ohba In-reply-to: <0923263C-0A11-4399-BDF9-6C4648E94344@lilacglade.org> To: Margaret Wasserman Message-id: <50533CEB.7090309@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> <50532F9B.9030104@toshiba.co.jp> <0923263C-0A11-4399-BDF9-6C4648E94344@lilacglade.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:19:22 -0000 Hi Margaret, We can work out in details on the needed interactions, but my point is that this does not mean that we cannot decide on one approach until the interactions are fully defined, especially because they are common to all approaches. We can work out details after we agree on one approach. Yoshihiro Ohba (2012/09/14 22:58), Margaret Wasserman wrote: > > Hi Yoshi, > > On Sep 14, 2012, at 9:22 AM, Yoshihiro Ohba wrote: >> On the other hand, if my understanding is correct, the needed set of >> interactions between an AKM function and the base PCP functions are >> not much different regardless of whether the AKM function is PANA or >> PCP-specific, and therefore I think the interactions do not have to be >> considered as a disadvantage of PANA-based approaches. > > I agree with you -- the need for integration of the authentication and PCP functions is effectively the same in all of the approaches we've considered. I was responding to Alper's assertion that this sort of integration was not needed in the side-by-side (or demux) approach. > > There are some things (like how we handle authentication requests to PCP Servers that don't implement PANA) that will work better in either encapsulation approach than in the demux approach. There are other things (like the need to check that the fields in the PCP header match corresponding fields in the PANA packet that are specific to the PANA encapsulation approach). And there are other issues (like the need to respecify and re-implement some functions already included in PANA) that will be specific to a PCP-Specific approach. These are the things that the WG needs to understand and decide between, IMO. To understand these things, we need to understand each of the PANA-based approaches in more detail than is currently documented. > > Margaret > > > > From margaretw42@gmail.com Fri Sep 14 07:26:40 2012 Return-Path: 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 AAA9421F84DF for ; Fri, 14 Sep 2012 07:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Xpcdzx3P4Yr0 for ; Fri, 14 Sep 2012 07:26:40 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5B421F84D8 for ; Fri, 14 Sep 2012 07:26:40 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so5437256vbb.31 for ; Fri, 14 Sep 2012 07:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Cm4Zx0AaJPAGgH9QV574PAVL2GYQk1DwGXIXxlTNWbg=; b=naX4Xrw4OCV4AisH9nWMGtF31UuDVVAOqbZnEGKyid68dhIAGzAppAni3EZ7yadGnH /d0xosH5mBfWsRx9dBQl11Pvz07oMY4CCz89ZmAvXmT9LHnC4QmykgP25gaFQ2EncPri EYXIccBi6CO1V1ZTZch3abH1LP2D3Gyl5Z0S/k225FoNz9k5zVB3AAQp5tGuJ05SY8j5 23MPJbGDC7PxCv6IZgIxUmiycnUNus00bpjzZMGutvIlE+M4Dm2n9bs53b4/ERSVR/r9 NTZAyGmCq/0RTRIWPiLRZdzv5epHi9KF1fR1m8DKXLjDXTpRmtgyCfdFUzsncJ+NIi67 9+CQ== Received: by 10.220.152.4 with SMTP id e4mr2351758vcw.9.1347632799316; Fri, 14 Sep 2012 07:26:39 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id w10sm323957vef.5.2012.09.14.07.26.36 (version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 07:26:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <50533CEB.7090309@toshiba.co.jp> Date: Fri, 14 Sep 2012 10:26:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> <50532F9B.9030104@toshiba.co.jp> <0923263C-0A11-4399-BDF9-6C4648E94344@lilacglade.org> <50533CEB.7090309@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:26:40 -0000 Hi Yoshi, On Sep 14, 2012, at 10:19 AM, Yoshihiro Ohba wrote: > We can work out in details on the needed interactions, but my point is > that this does not mean that we cannot decide on one approach until > the interactions are fully defined, especially because they are common > to all approaches. We can work out details after we agree on one > approach. I agree. We only really need to fully understand what the key = differences are between the different approaches, right now, so we can = make an informed choice. I continue to believe, as I said in Vancouver, that _all_ of the = approaches we are discussing are reasonable approaches that _will work_. = They all use the same underlying security mechanism (EAP), and they are = far more alike than different because of that. We just have to decide = which way of using EAP is best for our needs, and fully specify it. Margaret From hartmans@painless-security.com Fri Sep 14 07:27:01 2012 Return-Path: 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 62EE421F84DF for ; Fri, 14 Sep 2012 07:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.539 X-Spam-Level: **** X-Spam-Status: No, score=4.539 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_ABOUTYOU=0.5, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 Xzx02B4ok96c for ; Fri, 14 Sep 2012 07:27:01 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id E691421F84D8 for ; Fri, 14 Sep 2012 07:27:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A19D12010D; Fri, 14 Sep 2012 10:26:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 477FC4149; Fri, 14 Sep 2012 10:26:41 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5052D3F3.8000605@toshiba.co.jp> <50532345.4060109@toshiba.co.jp> Date: Fri, 14 Sep 2012 10:26:41 -0400 In-Reply-To: <50532345.4060109@toshiba.co.jp> (Yoshihiro Ohba's message of "Fri, 14 Sep 2012 21:29:57 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "pcp@ietf.org" Subject: Re: [pcp] WG status on PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:27:01 -0000 Yoshihiro> Hi Dacheng, A good question. Actually both approaches Yoshihiro> has some impact on RFC 5191 to allow PANA to run over a Yoshihiro> non-PANA port (which would require updating RFC 5191). Yoshihiro> This made me think that the need for updating RFC 5191 to Yoshihiro> use the Reserved field in the demultiplexing approach is Yoshihiro> not considered as a cons. Hi. I have two questions about your comparison: 1) How the encapsulation approach requires tight coupling 2) Why tight coupling is a bad thing given that we've ruled relays out of scope. --Sam From margaretw42@gmail.com Fri Sep 14 07:54:21 2012 Return-Path: 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 E84B421F851A for ; Fri, 14 Sep 2012 07:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eLKYoNvQqeVE for ; Fri, 14 Sep 2012 07:54:21 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E36D21F84A5 for ; Fri, 14 Sep 2012 07:54:21 -0700 (PDT) Received: by qafi29 with SMTP id i29so4380560qaf.10 for ; Fri, 14 Sep 2012 07:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=epQjM/MXldzLxxFaguffiPuXXM8UY2XZZ2AmNT7Kk7w=; b=fzeHujzCx8j0TAlKMHb04UEpXOFEqiXfzop12yVPjS4erkcNOKSBAoaqr9zAsj0yfl 1ixTKpno7Ut2oBYobBTYC1jSQ2Bg9gX+TvFF4Gh7Lo+CXQSE7/VxFxSrP2iDegW8BrHT tZcy2E5Pkgp08YHsbSJyw/+rOjNtRvzxuD70RdltStEPEx3hfDrtUgwrR1/mfJZ3noHT epkWspcwN8Vt11GK+RYOZv6ir9IaanOWez9Tf8ZINAclMrcHlodpxKtZuhcfRriAoOs9 XlFV7ypJ1ms2mW12xLsEVfC4VOf2jFDraw/d4OJ6p+hk9tr2K5sNwwT4Zu6za4KGeXTs uztg== Received: by 10.224.221.206 with SMTP id id14mr7710503qab.66.1347634460839; Fri, 14 Sep 2012 07:54:20 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id y18sm2683908qaa.15.2012.09.14.07.54.16 (version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 07:54:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <6657E02B-2D08-40BE-A567-F8AB976F2741@yegin.org> Date: Fri, 14 Sep 2012 10:54:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F4080C4-A6E2-4FC0-9D3E-61992E86C22F@gmail.com> References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> <6657E02B-2D08-40BE-A567-F8AB976F2741@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] PANA implementatinos to consider X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:54:22 -0000 On Sep 14, 2012, at 9:38 AM, Alper Yegin wrote: >> How does this work in the case where the PCP Server is not running a = PANA Server? I _think_ that if a PCP Client asks its PANA Client to = perform authentication, and the PCP Server does support authentication, = some sort of "unsupported version" error code will be returned to the = _PCP Client_ (due to the details of your proposed demultiplexing = scheme), and that nothing will be returned to the PANA Client, at all. = We would need to make sure that secure PCP clients are specified to = handle an "unsupported version" error differently when the PANA Client = is in this particular state, but how does the PCP Client know that this = is why that error was returned? If this does happen, how does the PCP = client inform the PANA Client that it should stop trying to perform = authentication with that particular PCP Server? =20 >>=20 >=20 > I'd like to first understand how the client-side decides when to use = authentication, and when not to? > Can you, or someone, explain that? Once I understand the scenarios we = are trying to cover, I can come back and answer your question. There are two cases we have considered where PCP clients may send = authenticated PCP requests: (1) Cases where the client sends an unauthenticated request and is told = that authentication is required, so it retries with an authenticated = request. =20 (2) Cases where the client initially attempts to send an authenticated = request. In the first case, the PCP Server will (we hope :-)) not return the = "authentication required" error if it doesn't actually support = authentication. But, in the second case, a client may try to send an = authenticated request to a PCP Server that does not support = authentication. Obviously, an error will result, be we want to be = certain that the error can be properly detected and returned to the = user, so that the user can understand what went wrong. Margaret From yoshihiro.ohba@toshiba.co.jp Fri Sep 14 08:03:00 2012 Return-Path: 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 3B7ED21F8532 for ; Fri, 14 Sep 2012 08:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.306 X-Spam-Level: X-Spam-Status: No, score=-7.306 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 9n+zL5qrA7Cu for ; Fri, 14 Sep 2012 08:02:59 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 880D821F8523 for ; Fri, 14 Sep 2012 08:02:59 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8EF2uWM000745; Sat, 15 Sep 2012 00:02:56 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8EF2ufC007965; Sat, 15 Sep 2012 00:02:56 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id AAA07964; Sat, 15 Sep 2012 00:02:56 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8EF2tY1024956; Sat, 15 Sep 2012 00:02:55 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8EF2tWd011708; Sat, 15 Sep 2012 00:02:55 +0900 (JST) Received: from [133.199.17.52] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAC009Q5HSUL1K0@mail.po.toshiba.co.jp>; Sat, 15 Sep 2012 00:02:55 +0900 (JST) Date: Sat, 15 Sep 2012 00:03:00 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <50534724.3050602@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5052D3F3.8000605@toshiba.co.jp> <50532345.4060109@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] WG status on PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:03:00 -0000 (2012/09/14 23:26), Sam Hartman wrote: > > Yoshihiro> Hi Dacheng, A good question. Actually both approaches > Yoshihiro> has some impact on RFC 5191 to allow PANA to run over a > Yoshihiro> non-PANA port (which would require updating RFC 5191). > Yoshihiro> This made me think that the need for updating RFC 5191 to > Yoshihiro> use the Reserved field in the demultiplexing approach is > Yoshihiro> not considered as a cons. > > > Hi. > I have two questions about your comparison: > > 1) How the encapsulation approach requires tight coupling As I mentioned in my comparison, I see the following two issues: "One issue is that some workaround is needed to carry a PCI (PANA-Client-Initiation) message which does not fit PCP's request-response type messaging. Another issue is that double integrity protection can happen after establishing a PCP SA, where a PANA message carried in the PCP message is protected by a PANA AUTH AVP and the PCP message itself is protected by a PCP Authentication Tag. Double integrity protection can be considered as overhead." To add more to the 2nd issue, tight coupling of PCP and PANA would be needed to avoid double integrity protection (e.g., omitting AUTH AVP when there is a PCP Authentication Tag, etc...) > > 2) Why tight coupling is a bad thing given that we've ruled relays out > of scope. As far as I understand, we ruled out relays to deal with EAP channel binding without need to tightly couple PCP and PANA (such as carrying PCP-specific information in a PANA message). Tight coupling is better to avoid, IMO. Yoshihiro Ohba > > --Sam > From dwing@cisco.com Fri Sep 14 10:41:21 2012 Return-Path: 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 03E5121F8533 for ; Fri, 14 Sep 2012 10:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 suZUhdqsNpT9 for ; Fri, 14 Sep 2012 10:41:20 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 087A221F851E for ; Fri, 14 Sep 2012 10:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4274; q=dns/txt; s=iport; t=1347644480; x=1348854080; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=BUMJFftRSzIIktQNlqo4HWqen/+uMtFb228MQDGFuFs=; b=UJplRfqNOuaLaB7sVF7UartmuxPEVqjO2C4bfoJqXf/vAM7YKEXCSx5M 1altBp1WcMCGgZpvoO+JbYvkxpafMYAu2Rs0PF+EUuG7adKBlUl9uUKd1 /gxS00llGMBnMMs8nX8/5nL7cwANTzDdVKvf/KzCXG6rJuyg0NqkI5PSJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABZsU1CrRDoJ/2dsb2JhbABFrAyPdoEHgiABAQEDAQEBAQUKARcQNBcBAwIJDwIEAQEoBxkOFQoJCAIEARILF4dlBQybR6AdBIsVhmgDiFaFD5Y0gWmDBg X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="55692985" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 Sep 2012 17:41:12 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8EHfC4v029844; Fri, 14 Sep 2012 17:41:12 GMT From: "Dan Wing" To: "'Zhangzongjian \(Thomas\)'" , References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5052D3F3.8000605@toshiba.co.jp> <52B4EAD8-7B6A-452D-8738-72C59E357519@yegin.org> <0B2F754289D27B449F7F1B95456B77544EDC74BF@szxeml524-mbs.china.huawei.com> In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC74BF@szxeml524-mbs.china.huawei.com> Date: Fri, 14 Sep 2012 10:41:12 -0700 Message-ID: <071d01cd92a0$21e179e0$65a46da0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNklFQfx9YznzFZkayNVvmBYxVuZeKGsQg Content-Language: en-us Subject: Re: [pcp] PCP mapping for 5350 and 5351 ports X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 17:41:21 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Zhangzongjian (Thomas) > Sent: Friday, September 14, 2012 1:17 AM > To: pcp@ietf.org > Subject: [pcp] PCP mapping for 5350 and 5351 ports > > Dear all > > In charter 11.3 of draft draft-ietf-pcp-base-26, it said: > > The PCP server MUST NOT create mappings for the PCP ports themselves > (5350 and 5351), and SHOULD have a policy control to deny mappings > for other ports. In these cases, the error NOT_AUTHORIZED SHOULD be > returned. > > We need to clarify: > 1. > What kinds port that 5350 and 5351 ports must not be used for mapping? > Internal ports , external ports or both? > > 2. > What kinds protocol that the ports must not be used for mapping? UDP > and others? > > 3. > It also seems that different scenarios have different result. Such as, > PCP server knows public interfaces and private interfaces in box, Only > PCP server in a box or both PCP server and PCP client. During review, this confusion was pointed out. In -27, the above is rewritten into a much more general and clear format, and reads as follows. I highlighted the specific text regarding the PCP ports numbers (5350, 5351), and the rest of the new text should clarify your questions (2) and (3). If the new text is still inadequate, please let me know. If no mapping exists for the Internal Address, Protocol, and Port, and the PCP server is able to create a mapping using the Suggested External Address and Port, it SHOULD do so. This is beneficial for re-establishing state lost in the PCP server (e.g., due to a reboot). There are, however, cases where the PCP server is not able to create a new mapping using the Suggested External Address and Port: o The Suggested External Address, Protocol, and Port is already assigned to another existing explicit or implicit mapping (i.e., is already forwarding traffic to some other internal address and port). o The Suggested External Address, Protocol, and Port is already used by the NAT gateway for one of its own services. For example, TCP port 80 for the NAT gateway's own configuration web pages, or UDP ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT ................................................^^^^^^^^^^^^^^^^^^^^^ create client mappings for External UDP ports 5350 or 5351. ......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ o The Suggested External Address, Protocol, and Port is otherwise prohibited by the PCP server's policy. o The Suggested External Address, Protocol, or Port is invalid (e.g., External Address 127.0.0.1, ::1, a multicast address, or the port is not valid for the indicated protocol). o The Suggested External Address does not belong to the NAT gateway. o The Suggested External Address is not configured to be used as an external address of the firewall or NAT gateway. If the PCP server cannot assign the Suggested External Address, Protocol, and Port, then: o If the request contained the PREFER_FAILURE Option, then the PCP server MUST return CANNOT_PROVIDE_EXTERNAL. o If the request did not contain the PREFER_FAILURE Option, and the PCP server can assign some other External Address and Port for that protocol, then the PCP server MUST do so and return the newly assigned External Address and Port in the response. In no case is the client penalized for a 'poor' choice of Suggested External Address and Port. The Suggested External Address and Port may be used by the server to guide its choice of what External Address and Port to assign, but in no case do they cause the server to fail to allocate an External Address and Port where otherwise it would have succeeded. The presence of a non-zero Suggested External Address or Port is merely a hint; it never does any harm. -d > > > Regards > Thomas > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From ebiederm@xmission.com Sat Sep 15 07:25:49 2012 Return-Path: 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 0D53721F84DD for ; Sat, 15 Sep 2012 07:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ox0Oa5Ofid-b for ; Sat, 15 Sep 2012 07:25:48 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id 93C8F21F84D6 for ; Sat, 15 Sep 2012 07:25:48 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1TCtJa-0007Ya-JQ for pcp@ietf.org; Sat, 15 Sep 2012 08:25:48 -0600 Received: from [98.207.153.68] (helo=eric-ThinkPad-X220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1TCtJY-0003os-1V for pcp@ietf.org; Sat, 15 Sep 2012 08:25:46 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: pcp@ietf.org Date: Sat, 15 Sep 2012 07:25:35 -0700 Message-ID: <877grv5pnk.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=; ; ; mid=; ; ; hst=in02.mta.xmission.com; ; ; ip=98.207.153.68; ; ; frm=ebiederm@xmission.com; ; ; spf=neutral X-XM-AID: U2FsdGVkX1+SasQ0GNxJHd/9lnbm3XrLt4JI3JNTx8U= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;pcp@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Subject: [pcp] To change a mapping does the pcp source port need remain the same? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 14:25:49 -0000 I have just been reading through draft-ietf-pcp-base-26.txt and figuring out what it would take to implement. In the normal non-authenticated case a pcp client will pick a randomized source port and use that one port to create and refresh mappings. Would it be an error for a pcp server to require pcp clients to use the same source port that a mapping was established with to change that mapping? As a trivial way to keep different clients from stepping on each other by accident I would certainly require the source port to remain constant to change a mapping. Eric From hartmans@painless-security.com Sun Sep 16 09:38:43 2012 Return-Path: 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 20A7121F8523 for ; Sun, 16 Sep 2012 09:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.651 X-Spam-Level: **** X-Spam-Status: No, score=4.651 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_23=0.6, RDNS_DYNAMIC=0.1] 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 c+cfhIHbaiYb for ; Sun, 16 Sep 2012 09:38:30 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09C21F845E for ; Sun, 16 Sep 2012 09:38:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 56CA820200 for ; Sun, 16 Sep 2012 12:38:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 877974149; Sun, 16 Sep 2012 12:38:05 -0400 (EDT) From: Sam Hartman To: pcp@ietf.org Date: Sun, 16 Sep 2012 12:38:05 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 16:38:43 -0000 So, I've done a few hours of implementation analysis and come to a conclusion. Before I get to my conclusion, and my analysis, I'd like to discuss how I think this fits into the WG process. The IETF doesn't really deal with implementation issues except in so far as they impact the standardization process. I claim it's entirely reasonable for WG participants to factor in the question of which of the three approaches we're considering would be easiest to implement into their decision of which approach to standardize. "Hey, it's easy to build x and not y," seems like a fine reason within the IETF process to prefer x and not y. That's what I'm doing here; I'm presenting my opinion on what's easy to build as a rationale for my opinion on which option to standardize. I hope to convince you to agree with me about which option to standardize. However, we're not coming to consensus on which option is easiest to build; the IETF doesn't reach consensus on implementation issues. I'm presenting my reasoning only so you can judge how valuable my opinion is. If I got something factually wrong--for example I missed a capability of an implementation--point it out. If you disagree with the tradeoffs that are important to me, it's probably better for you to post your own analysis based on your own tradeoffs than to try and convince me my tradeoffs are "wrong." My goal: I think that we have a lot of open-source security tools around. I want it to be easy for people to add authentication to PCP implementations. For that reason I would strongly prefer us to standardize a solution where people can pick up existing libraries, integrate them into their PCP servers and clients, and have authentication. My conclusion: Based on the existing open-source tools and libraries, I think it would be much cheaper and simpler for me to integrate a PCP-specific authentication approach into PCP than to integrate either PANA encapsulation or demultiplexing. Even if you have proprietary PANA implementations, some of the issues I identify below may apply. That said, I agree with Margaret that all the approaches are technically viable and with enough work any of the three approaches will work. In terms of what they provide, they are very similar. Since they are similar, simplicity and cost are important factors in my decision criteria. Even if you skip the detailed comparison below, I recommend reading the "General Notes" section at the end. All three approaches have some components in common. The PCP client will need an EAP supplicant library; for the PCP-specific approach this will be used directly. For the PANA approaches, the EAP supplicant will be used indirectly via the PAC. the PCP server will need a RADIUS library, an EAP server library or both. The RADIUS library is valuable if you're integrating into a corporate or ISP infrastructure. the EAP server is valuable if you're trying to provide authentication for a simple home gateway that integrates into nothing else. Again, for a PCP-specific approach, these libraries will be used directly; for a PANA approach, they will be used by the PAA. One factor to consider in evaluating these components is whether the library in question provides access to the EAP methods that your customers need. I'd want a library that exposed a couple of tunnel methods from the set (EAP-FAST, EAP-TTLS, EAP-PEAP, EAP-LEAP) and a couple of inner methods from the set (EAP-MSCHAPv2, EAP-PAP, EAP-PSK, EAP-GPSK) and possibly EAP-TLS. One EAP implementation we'll run into a couple of times below is the one from hostap/wpa_supplicant (http://w1.fi/). Your product may already be using this or parts of it for 802.11i. It's a actively developed very cross-platform library. You can use it as anything from an EAP library directly all the way up through an 802.11i implementation. It includes EAP client, EAP server and RADIUS. BSD licensed. PCP-Specific Approach I've managed a project where we added EAP authentication to an application (well really set of applications) using a protocol specific to our application. We were implementing draft-ietf-abfab-gss-eap. In effect we were build an application security mechanism based on top of raw EAP. As such we got experience with an EAP-specific approach ported to Linux, Windows and Mac. The Windows port is heavily integrated into the operating system, including providing a security support provider integrated into the local security authority. We have not yet ported this to mobile or embedded environments. We used the wpa_supplicant EAP library. Because of requirements that applied to our project but not PCP, we ended up funding development of a new RADIUS library (we wanted support for RADIUS over TLS which is still in development). For PCP, we could have used the RADIUS support in the wpa_supplicant stack, or a number of existing RADIUS libraries. See the eapGSSSMInitAuthenticate function in http://www.project-moonshot.org/gitweb?p=mech_eap.git;a=blob;f=mech_eap/init_sec_context.c;h=9da9f4f7cffd68c4c77a8efdbecaa1e87b0865f5;hb=65b06d7e720738acf873c20933e36fae0fe857fd for how we integrate EAP into the client. See eapGSSSMAcceptAuthenticate function in http://www.project-moonshot.org/gitweb?p=mech_eap.git;a=blob;f=mech_eap/accept_sec_context.c;h=aeba1b4d8e5b4b50128c4c04470f9c778117dbda;hb=65b06d7e720738acf873c20933e36fae0fe857fd for how we integrate RADIUS into the server. The biggest challenges on the EAP side were adding configuration to the applications to choose the right username, password and where appropriate TLS certificate for the server were connecting to. There were also some minor build challenges for wpa_supplicant. The library code is well isolated, but their build system doesn't do a great job of building shared libraries/dlls components for other projects to re-use. A wide selection of EAP methods are available. On the RADIUS side, we actually spent a lot of time, almost all of that was because of special things our project is doing with RADIUS. There was an early prototype that had an integrated EAP server and a bit later that used a stock RADIUS library. Both of those ended up being fairly simple. We did get the library re-use we expected. As I recall, We needed to make no changes to wpa_supplicant code to use it. We did change their build system a bit. As I recall, we submitted a couple of small bug fixes to the stock RADIUS library when we used that, but those bug fixes were quickly accepted upstream. We were lucky that the state machine we were dealing with ended up supporting multiple round trips already. One potential complexity in integrating PCP-specific authentication into a PCP server is that EAP exchanges will take multiple round trips, so multiple PCP messages may be sent in response to an application requesting a mapping if an authentication session is not set up. In many cases, existing retransmission strategies will already include this complexity in the client state machine. On the server, if RADIUS is used, then responding to an incoming PCP authentication request will require waiting for the RADIUS response; this may complicate the server state machine. CPANA See http://sf.net/projects/cpana At first glance, CPANA looks promising. It's designed as a library for others to integrate PANA into their environments. CPANA is distributed under the BSD license. Unfortunately, I quickly decided that CPANA was not a credible start point in my opinion. The project has received 11 code commits over its entire lifetime; I think 1 or 2 commits this year. Despite claims that "docs are coming soon," in 2010, I was able to find no documentation. There doesn't seem to be good separation of what is a public interface from what is an internal interface; cpana.h includes all the internal header files. The example applications don't separate example-specific functionality like reading config files well from using the library, so I wasn't able to get a feel for what it would be like to use the library in a non-sample application. On a positive note, there did seem to be an abstraction around where responses went; it might be easier-than-expected to use CPANA in an encapsulation or demultiplexing approach. There's one additional huge problem with CPANA. It includes its own rather limited EAP library which does not appear to support any of the tunnel methods. On the server there appears to be no RADIUS support. If I were writing a PANA library I planned to maintain for years, I'd seriously evaluate taking chunks of code from CPANA. If CPANA gets significant new development effort it may turn into something interesting. I like the goal of separating library from application. OpenPANA Took a look at http://sf.net/projects/openpana. OpenPANA is under significantly more active development than CPANA. One initial concern is the GPL3 license. Depending on the license of your PCP product, this may not be a viable starting point. OpenPANA used wpa_supplicant as an EAP stack; this is good. The code has fairly reasonable doxygen markup. The website and source distribution do not include pre-built doxygen output. OpenPANA's description claims that it includes libraries and applications. This is true, but the libraries are at the level of parsing PANA messages and utilitiy functions. Much of the guts of the PANA implementation is built into the applications. The applications are specific to network access; as an example there are commits dealing with fixing situations that work on a wired NIC but not on a laptop. OpenPANA assumes a threaded execution model. If your PCP product is asynchronous event based, this would be a significant integration concern. OpenPANA is an application; it uses malloc and other C library memory management functions directly. Turning that into a library can be painful for some environments. Regardless of wich PANA approach we pick, you'd need to do some common work to OpenPANA to make it useful for PCP. You would need to remove the network access code and replace the configuration parsing. For the encapsulation approach, you'd need to make fairly major changes. You'd want OpenPANA to run as a library. Also, it really wants to handle sending the messages itself. Structures have a sockaddr_in (or sockaddr_in6) to which messages are sent. You would instead need to restructure all that as callbacks or similar. You'd also need to consider the comments I made about aligning the PCP state machines on client and server with authentication when discussing the PCP-specific approach. Parts of the demultiplexing approach look simpler. You could run a PAA and PAC as separate processes. If the PCP server received an authentication request it could forward it to the PAA over a local socket. You'd need to make a slight change so that the return address could be preserved. In this mode, the PCP server would not need to change its state machine to wait for authentication. Except then it gets complicated, because you need coordination between PCP and the PAC/PAA. You need to design an implementation-specific protocol to: * Trigger authentications on the PAC when PCP wants to talk to a server * update the PCP client on authentication state including session ID,key ID, and negotiated algorithms * Provide error feedback from the PAC to PCP server so the user gets a consistent error reporting experience * Update the PCP server on new authentication sessions at the PAA including IDs, keys and algorithm identifiers If you do all that work you're going to end up with a fork of OpenPANA, not just get a library you can use and potentially refresh for new products/product releases. Security analysis will be different especially for things like denial of service. I'm quite certain making the necessary changes to OpenPANA would be more complex and likely to be more expensive than integrating a PCP-specific approach. General notes When you glue technologies together, you add complexity. Some of that complexity is inherent--for example adding multi-round-trip authentication to PCP simply will add complexity. Some of that complexity is in the implementation domain. There are EAP and RADIUS libraries out there that have been designed to work well with applications. They tend to interface to the existing event loops, tend to allow the application to supply memory allocators, that sort of thing. They tend to support the application providing configuration information. Even so, the EAP library is going to bring along its own session management and message reassembly. All the options we're discussing involve that complexity. Pana is yet another framework on top of EAP. The PANA specifications are scoped for network access; however we're not directly doing network access. The changes to PANA specs between network access and application authentication are not very large. However we still need to consider the benefits especially at an implementation layer. The PANA implementations I've looked at aren't all that thin. They include session layers on top of the EAP session layer. They are not as mature as the EAP implementations; they will place more constraints on things like event loops and execution models. OpenPANA brings along its own alarm linked lists and retransmission infrastructure on top of what exists in the EAP library. It brings along its own PRF+, AES and CMAC implementations. Yet, it's easy to see a PCP server or client duplicating a lot of this too. PCP's going to need a session and retransmission layer; it's going to need some cryptographic function (probably a hash-based MAC) for integrity. PCP already has its own approach to liveness duplicating what PANA does. Yes, if you re-use an existing EAP library and are not making significant customizations then there will be duplication between EAP and PCP. However PANA introduces significantly more duplication at the implementation layer. My opinion is that when I consider the extra effort to use PANA and the extra code it brings along, I don't see what value it brings. You could argue we could save even more by dropping EAP completely and doing something so PCP-specific that it didn't re-use a security framework at all. that would be a hard sell for the security area and would provide less value to our users because they could not re-use existing infrastructure. From zhangzhongjian@huawei.com Mon Sep 17 00:47:12 2012 Return-Path: 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 B5AD521F84FD for ; Mon, 17 Sep 2012 00:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 xPdr9gDxkRfD for ; Mon, 17 Sep 2012 00:47:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 37B0121F8495 for ; Mon, 17 Sep 2012 00:47:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKS77313; Mon, 17 Sep 2012 07:47:10 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 08:46:50 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 08:47:07 +0100 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Mon, 17 Sep 2012 15:46:06 +0800 From: "Zhangzongjian (Thomas)" To: Dan Wing , "pcp@ietf.org" Thread-Topic: [pcp] PCP mapping for 5350 and 5351 ports Thread-Index: AQHNklFQfx9YznzFZkayNVvmBYxVuZeKGsQggAP5YiA= Date: Mon, 17 Sep 2012 07:46:05 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC79B2@szxeml524-mbs.china.huawei.com> References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5052D3F3.8000605@toshiba.co.jp> <52B4EAD8-7B6A-452D-8738-72C59E357519@yegin.org> <0B2F754289D27B449F7F1B95456B77544EDC74BF@szxeml524-mbs.china.huawei.com> <071d01cd92a0$21e179e0$65a46da0$@com> In-Reply-To: <071d01cd92a0$21e179e0$65a46da0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] PCP mapping for 5350 and 5351 ports X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 07:47:12 -0000 > o The Suggested External Address, Protocol, and Port is already used > by the NAT gateway for one of its own services. For example, TCP > port 80 for the NAT gateway's own configuration web pages, or UDP > ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT > ................................................^^^^^^^^^^^^^^^^^^^^^ > create client mappings for External UDP ports 5350 or 5351. > ......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 1. Internal UPD ports 5350 or 5351 can't be used. (1) PCP client and NAT-PMP client use 5350 and 5351 for PCP or NAT-PMP p= rotocol. They will not send a PCP/NAT-PMP mapping request use UDP 5350 or 5= 351 as internal port. Of cause PCP server can ignore this since no such a r= equest. For security we must not permit use the UDP 5350 and 5351 as intern= al port in Mapping entry. The attacker behind CGN may send a PCP or NAT-PMP= map request with 5350 or 5351 as internal port. If PCP server or NAT-PMP s= erver create a mapping use the 5350 or 5351 as internal UDP port, mass Data= packets from public network will be send PCP client or NAT-PMP client. (2) As for UPnP, UDP ports 5350 or 5351 may be used as the internal port= in UPnP MAP request. UPnP-PCP interworking send the PCP request with inte= rnal UDP port 5350 or 5351 to PCP server and a mapping entry is created by = PCP server. Data packet sent to UPnP client from remote will be forward to = UPnP-PCP interworking function. The data packets will be discarded by UPnP-= PCP interworking device. 2. we can specify the case that Port is already used by the NAT gateway for= one of its own services. PCP server usually know which interface is internal (from which interface= the PCP request is received and private network is behind this interface) = or external, such as PCP server in CGN. That is to say (1) When only PCP server in NAT gateway, PCP server only listen on UDP port= 5351 at internal interfaces. UDP 5350 or 5351 can be used as the external = port. (2)When both PCP server and PCP client in NAT gateway, PCP server will list= en on UDP port 5351 at internal interfaces and PCP client will listen on UD= P port 5351 and 5350 at external interfaces. UDP 5350 or 5351 can't be used= as the external port. (3)When PCP proxy or UPnP-PCP interworking in NAT gate way, UDP 5350 or 535= 1 can't be used as the external port. (This out scope of draft-PCP-base) > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Saturday, September 15, 2012 1:41 AM > To: Zhangzongjian (Thomas); pcp@ietf.org > Subject: RE: [pcp] PCP mapping for 5350 and 5351 ports >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Zhangzongjian (Thomas) > > Sent: Friday, September 14, 2012 1:17 AM > > To: pcp@ietf.org > > Subject: [pcp] PCP mapping for 5350 and 5351 ports > > > > Dear all > > > > In charter 11.3 of draft draft-ietf-pcp-base-26, it said: > > > > The PCP server MUST NOT create mappings for the PCP ports themselves > > (5350 and 5351), and SHOULD have a policy control to deny mappings > > for other ports. In these cases, the error NOT_AUTHORIZED SHOULD > be > > returned. > > > > We need to clarify: > > 1. > > What kinds port that 5350 and 5351 ports must not be used for mapping? > > Internal ports , external ports or both? > > > > 2. > > What kinds protocol that the ports must not be used for mapping? UDP > > and others? > > > > 3. > > It also seems that different scenarios have different result. Such as, > > PCP server knows public interfaces and private interfaces in box, Only > > PCP server in a box or both PCP server and PCP client. >=20 > During review, this confusion was pointed out. In -27, the above > is rewritten into a much more general and clear format, and reads > as follows. I highlighted the specific text regarding the PCP > ports numbers (5350, 5351), and the rest of the new text should > clarify your questions (2) and (3). If the new text is still > inadequate, please let me know. >=20 >=20 > If no mapping exists for the Internal Address, Protocol, and Port, > and the PCP server is able to create a mapping using the Suggested > External Address and Port, it SHOULD do so. This is beneficial for > re-establishing state lost in the PCP server (e.g., due to a reboot). > There are, however, cases where the PCP server is not able to create > a new mapping using the Suggested External Address and Port: >=20 > o The Suggested External Address, Protocol, and Port is already > assigned to another existing explicit or implicit mapping (i.e., > is already forwarding traffic to some other internal address and > port). >=20 > o The Suggested External Address, Protocol, and Port is already used > by the NAT gateway for one of its own services. For example, TCP > port 80 for the NAT gateway's own configuration web pages, or UDP > ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT > ................................................^^^^^^^^^^^^^^^^^^^^^ > create client mappings for External UDP ports 5350 or 5351. > ......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > o The Suggested External Address, Protocol, and Port is otherwise > prohibited by the PCP server's policy. >=20 > o The Suggested External Address, Protocol, or Port is invalid > (e.g., External Address 127.0.0.1, ::1, a multicast address, or > the port is not valid for the indicated protocol). >=20 > o The Suggested External Address does not belong to the NAT gateway. >=20 > o The Suggested External Address is not configured to be used as an > external address of the firewall or NAT gateway. >=20 > If the PCP server cannot assign the Suggested External Address, > Protocol, and Port, then: >=20 > o If the request contained the PREFER_FAILURE Option, then the PCP > server MUST return CANNOT_PROVIDE_EXTERNAL. >=20 > o If the request did not contain the PREFER_FAILURE Option, and the > PCP server can assign some other External Address and Port for > that protocol, then the PCP server MUST do so and return the newly > assigned External Address and Port in the response. In no case is > the client penalized for a 'poor' choice of Suggested External > Address and Port. The Suggested External Address and Port may be > used by the server to guide its choice of what External Address > and Port to assign, but in no case do they cause the server to > fail to allocate an External Address and Port where otherwise it > would have succeeded. The presence of a non-zero Suggested > External Address or Port is merely a hint; it never does any harm. >=20 >=20 > -d >=20 >=20 > > > > > > Regards > > Thomas > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Mon Sep 17 01:02:48 2012 Return-Path: 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 A6A9E21F846E for ; Mon, 17 Sep 2012 01:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XIvn3WRDhmj2 for ; Mon, 17 Sep 2012 01:02:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 78F7521F846D for ; Mon, 17 Sep 2012 01:02:47 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MRGkB-1T5VYE0XvT-00U7n1; Mon, 17 Sep 2012 04:02:45 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <6F4080C4-A6E2-4FC0-9D3E-61992E86C22F@gmail.com> Date: Mon, 17 Sep 2012 11:02:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <040C6F6B-1884-49FD-B51C-E82F9F9772F4@yegin.org> References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> <6657E02B-2D08-40BE-A567-F8AB976F2741@yegin.org> <6F4080C4-A6E2-4FC0-9D3E-61992E86C22F@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:OI5/CAP9UtnlVp0PqjIwaSDXB9OCk9ev8Pspdie5VNR Fbt7D45JLm6VDpkea/k3CklwwXFMVOeVzQHUhjQThIwVprya1D Tz3/712DjxOCpZfcbDblnf7hlkdwnXY0IycdZGKWSRrVBQLmq0 JHkc/sHiTPYmSZSTW80WkhZEgSYgb+xc4KuZCxrW7GfUpLzjYF 69tvpxCDLB9cY+fneMOPowViu8KMVOpUYq7bnWLx0zhGi6sr88 fk/L434rDEKp+YG/KaGGAyzZeokvnKxSXqFkXcB/GhpwwWGQlM fJfx1nAd/VpdSs7G5yGC3TjgkuXKWw4J6+UwJVbnhI91cP1WGB 4jSIsuP6Rr9zoUsaV+WbrMO/eKuX+6ZsaJI6fhplsM6VjRrI30 de98NTK/raXOg== Cc: pcp@ietf.org Subject: [pcp] Authentication scenarios (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 08:02:48 -0000 >> I'd like to first understand how the client-side decides when to use = authentication, and when not to? >> Can you, or someone, explain that? Once I understand the scenarios we = are trying to cover, I can come back and answer your question. >=20 > There are two cases we have considered where PCP clients may send = authenticated PCP requests: >=20 > (1) Cases where the client sends an unauthenticated request and is = told that authentication is required, so it retries with an = authenticated request. =20 >=20 > (2) Cases where the client initially attempts to send an authenticated = request. >=20 > In the first case, the PCP Server will (we hope :-)) not return the = "authentication required" error if it doesn't actually support = authentication. But, in the second case, a client may try to send an = authenticated request to a PCP Server that does not support = authentication. Obviously, an error will result, be we want to be = certain that the error can be properly detected and returned to the = user, so that the user can understand what went wrong. >=20 Few questions: - Why is there an unauthenticated case? Or, under what real-life = scenarios would authentication be necessary? And under what real-life = scenarios would authentication be unnecessary?=20 - If authentication is optional, is it client's preference to use it, or = network's? Would client ever attempt to use it w/o knowing network's = preference? Would it bail out if network does not support/use it?=20 - Are we talking about optional to use or optional to implement? You = mentioned "PCP Server that does not support authentication". Thanks. Alper > Margaret >=20 >=20 From alper.yegin@yegin.org Mon Sep 17 01:32:11 2012 Return-Path: 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 C559921F853E for ; Mon, 17 Sep 2012 01:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1rrSO0NvHMRD for ; Mon, 17 Sep 2012 01:32:10 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9180C21F8495 for ; Mon, 17 Sep 2012 01:32:10 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LdYhm-1Tunzf1ToQ-00igr8; Mon, 17 Sep 2012 04:32:07 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Mon, 17 Sep 2012 11:31:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:KQ6YR06kSMPh9omcle6TwqgMuJ+AwvviF6kyiL0TqlF 0bT4qWYSdyAG3ThiwkFOGb6MFvaDCiEw5F8/f15uS5sK1taA74 47gWBe6XkI6JYbedz4UdQ5vk8Zto8oLBR1HOFmvf0HpcydpbNS OzGitI+e2Gx47LxHIVMnZiw4Jt+Xlrse0wmMh1uiVj5mXGNMtc QDuH3b8M9/xPac6sRocjFivb9/OPlD28hzE8ZUEkM0g6hRE6qG E6SSe69QgNRGfZ8T3KCGlYvO3AQb54U9SW/3mN9LY38eR+OarX YwpLc4JIcndsD7hfE0UW3Un5vLsdQ8/rMZv95FEAG0aq0UJO4Z AWJHRrYhdsF8sfWtJ0mgSxGc9tTY+O7nMQ8c/ZWGqZQnx5Nil/ J5Uc6xC56wIoA== Cc: "'pcp@ietf.org'" Subject: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 08:32:11 -0000 > +1 all I have seen so far is very complex for simple authentication of = pcp. Let's embed it into pcp. >=20 It does not get simplified because you put one inside the other. In = fact, it gets more complicated. Please see below. >=20 > I've been following this discussion and my preference would be to = avoid > having a design that requires a 'control protocol' between PCP and > something else. We should reuse other IETF standards whenever possible = but > I would prefer everything to be part of a single protocol. This is so un-IETF to me. Here we have two distinct pieces of work (PCP = and key management), that can be satisfied using two protocols, we are = talking about cobbling them together.=20 Like that was done in the PPP-era, and like it's done in GTP (of 3GPP). = Lot of pain with both... I'd understand how other SDOs would think that way, but their priorities = are different. But for IETF, we design protocols, and cobbling up = protocols unnecessarily gets in the way of modularity, which is very = essential to IETF. Right? More on this below... > Having a > separate protocol would mean significant more test and effort for > productization due to interactions, new CLIs, unforeseen state machine > issues, etc.=20 Just the opposite.=20 Inventing new EAP-over-UDP as part of PCP is a brand-new design with = brand-new code. PANA is a standard with multiple interoperating = implementations.=20 It's obviously more stable then the to-be-designed EAP-over-UDP/PCP.=20 State machines is one of the issues with cobbling up protocols. Two = separate protocols, living side by side, the state machines have nothing = to conflict. If you put on inside the other, then problems arise. Specifically in this case: The direction of PCP flow and EAP flow are = just the opposite. PCP is host-side driven req/rsp. EAP is network-side = driven req/rsp. So, now PCP state machine has to change to support that = too. And, EAP can generate asynchronous requests at any time from the = network side (re-authentication). Exact same issue that we had with the = EAP-over-DHCP (in fact this whole discussion has the same pattern=85.) And I have yet to hear someone saying yes EAP-over-PCP satisfies the EAP = lower layer requirements. I had raised this issue 3 times, and don't see = anyone doing the work. It's not as simple as defining a container to = ship EAP payloads back and forth.=20 >=20 > We will certainly even face all kinds of backward/forward = compatibility > issues between PCP, PANA (as an example) and whatever control protocol > will run between them due to different features and evolution = timeline. >=20 Again, situation is the opposite.=20 Having them separate will allow them to evolve independently.=20 Adding new features to a revision or extension of PANA is better than = adding it to N different protocols which chose to embed equivalent of = PANA. > Although one can argue that PCP and PANA will run together as one = entity > the next step would be somebody asking for them to be decoupled and = able > to run anywhere. This train is never late. >=20 They are running separately. They are de-coupled as "protocols". What we = are coupling is the "state" generated/used by PANA and PCP. This decoupling is a feature for "protocols", not a bug. Using state = generated from one protocol in another is a "architecture design" or = "implementation". Alper >=20 > -----Original Message----- > From: Alper Yegin > Date: Fri, 14 Sep 2012 16:38:17 +0300 > To: Margaret Wasserman > Cc: > Subject: Re: [pcp] PANA implementatinos to consider >=20 >> Hi Margaret, >>=20 >> Your below questions are implementation specific. >> Let me answer them to describe how this can be implemented in one = way. >> Certainly there are other ways to implement them. >>=20 >>>=20 >>> On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: >>>> As for the implementation complexity, I don't quite understand why >>>> PANA (which is basically EAP over UDP) would ever be more = complicated >>>> then to-be-designed "EAP over UDP within PCP framework". While I = don't >>>> see a reason for former being more complicated, I see reasons for >>>> seeing the latter being more complicated, as the whole thing now = needs >>>> to live within another protocol framework (read: format, flow, = state >>>> machine harmonization between the two). >>>=20 >>> I don't understand how you get away from coupling PANA and PCP, even = in >>> the demultiplexing case where they run side-by-side on the same = port. I >>> think a number of details are being glossed over in your latest = document >>> when you refer to a need for an "API" between PANA and PCP=8A >>>=20 >>=20 >> Association or binding of state between PANA and PCP is common on = both. >> But there are different degrees of "coupling". Or where you couple = them. >> Are we coupling the state generated/maintained between the two, or = are we >> coupling the protocols themselves. >>=20 >> You could say, a host configures a care-of address using DHCP, and = uses >> that IP address with Mobile IP, hence DHCP and Mobile IP are coupled. >> Or, you could invent carrying DHCP over Mobile IP, and call that = coupling >> too. >>=20 >> Another more relevant example: Running IKE for IPsec, or running IKE = over >> IPsec (however you do it). >>=20 >>=20 >>> Let's start with a simple case where the PCP Client wants to = initiate >>> and authenticated PCP request... >>>=20 >>> The Client needs to ask the PANA Client to initiate authentication. >>> How? =20 >>=20 >> PCP software triggers the PaC to perform authentication. >> Like how IKE gets triggered when IPsec SA needs to be setup. >>=20 >>=20 >>> Will that request include any details about the mapping request that = is >>> being made? i.e. will the PANA Client be asking for authentication = _and >>> authorization_ to perform a particular action? Or do we assume that = a >>> PCP client is authenticated via PANA, and that authorization for a >>> particular action is a separate step that is performed as part of = PCP? >>> If they are separate, do we need a new set of PCP error codes for = the >>> situation where an authenticated PCP client performs an unauthorized >>> action, or is that already covered in the PCP spec? >>=20 >>=20 >> That trigger I mentioned above will include two pieces of = information: 1. >> Indication that this is an auth/authz for PCP, 2. IP address of the = PAA >> (which is same as the PCP server). >>=20 >>=20 >>> When the PCP Client asks the PANA Client to perform authentication, >>> what are the possible results that can be returned from that = request, >>> and how are they communicated back to the PCP Client? You have only >>> described the success case in your document. >>=20 >> PANA already generates success and failure results. This result will = be >> conveyed to the PCP client via the API. >> If the result is success, also the PCP_AUTH_KEY and PANA Session ID = and >> PANA Key ID need to be passed via that interface. >>=20 >>=20 >>=20 >>>=20 >>> How does this work in the case where the PCP Server is not running a >>> PANA Server? I _think_ that if a PCP Client asks its PANA Client to >>> perform authentication, and the PCP Server does support = authentication, >>> some sort of "unsupported version" error code will be returned to = the >>> _PCP Client_ (due to the details of your proposed demultiplexing >>> scheme), and that nothing will be returned to the PANA Client, at = all. >>> We would need to make sure that secure PCP clients are specified to >>> handle an "unsupported version" error differently when the PANA = Client >>> is in this particular state, but how does the PCP Client know that = this >>> is why that error was returned? If this does happen, how does the = PCP >>> client inform the PANA Client that it should stop trying to perform >>> authentication with that particular PCP Server? >>>=20 >>=20 >> I'd like to first understand how the client-side decides when to use >> authentication, and when not to? >> Can you, or someone, explain that? Once I understand the scenarios we = are >> trying to cover, I can come back and answer your question. >>=20 >>=20 >>> Also, how does the PCP Client know when the _PCP Server_ is ready to >>> receive its request? Are we assuming that the PANA Server will not >>> return an indication to the PANA Client that the client has been >>> authenticated until _after_ it has provisioned the necessary SA on = the >>> PANA Server? =20 >>>=20 >>=20 >> The order of events is: >>=20 >> 1. PANA is executed >> 2. PaC provides the results to the PCP client >> 3. PCP client contacts PCP server, using authentication tag = generated >> with the SA from step 2. >> 4. Upon encountering new SA, PCP server contacts the PAA to obtain = the >> matching parameters (or, the PAA had already pushed those params to = PCP >> server after 1. These are different implementation choices=8A..) >>=20 >>=20 >>=20 >>> What if an additional application on the same PCP Client system = wants >>> to perform an authenticated request with the same PCP Server in the >>> meantime? Will that second request result in a second (interleaved) >>> PANA negotiation, or will the PCP Client be told that a PANA = negotiation >>> is already pending? If the latter, how will the second PCP Client >>> thread by informed when the PANA negotiation has completed? (Note: = The >>> right answer here depends heavily on whether the PANA authentication >>> depends, in any way, on the contents of a specific PCP request -- = the >>> authentication vs. authentication/authorization question above). >>>=20 >>=20 >> Second API call can be told that there is already an ongoing >> authentication and wait for the result. >> Or, maybe it says "OK" but does not generate a second PANA session >> because the same PANA session (or, more specifically the security >> association generated by it) can be used with both PCP requests. >>=20 >>=20 >>> All of these questions will need to be answered, IMO, in a full >>> specification of the PCP/PANA demultiplexing mechanism, precisely >>> _because_ PCP and PANA are running separately. >>=20 >> Errr, I don't think so. None of these are impacting the over-the-wire >> behavior (i.e., the "protocol"), but they are all about = implementation -- >> not something we need to put in the protocol specs. >>=20 >>=20 >> If we were to use EAP over PCP, do you think we need to define how = EAP >> methods interface with EAP which interfaces with PCP. How one = triggers >> the other and gets the results back. I don't think so. >>=20 >>=20 >>=20 >>> The "API" is where this coupling is provided between the two "state >>> machines", as you refer to them. Why is this any simpler if PANA = and >>> PCP are running side-by side than if we run PANA encapsulated in = PCP? >>> (or, if we run PCP directly over EAP, for that matter) >>>=20 >>=20 >>=20 >> Please see the top part about my "coupling" response. >>=20 >> If you run two protocols side by side, you point how one can trigger = the >> other. And ideally, triggers target meaningful states. E.g., one = protocol >> triggers other to run, and at the end of execution the result is = returned >> (PCP triggers PANA to execute). >> If you run one protocol inside another, then you have to nest their = state >> machines, and unless you are purely lucky, that cannot work = automatically >> w/o aligning their state machines. (Like I said, PANA state machine = is >> designed the way it is in accordance with the EAP state machine.) >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> Margaret >>>=20 >>>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Mon Sep 17 02:24:53 2012 Return-Path: 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 92DA221F84CF for ; Mon, 17 Sep 2012 02:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.179 X-Spam-Level: X-Spam-Status: No, score=-102.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] 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 tNUOrpPT5qCE for ; Mon, 17 Sep 2012 02:24:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0025521F84B5 for ; Mon, 17 Sep 2012 02:24:51 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LcAWr-1TuXQx1qOD-00je2b; Mon, 17 Sep 2012 05:24:50 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Mon, 17 Sep 2012 12:24:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> References: To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:u/gfqsFfghXBPTYhDBgjzQyIDxOVCuMlLNSuKhdFsUf RJQrW0qz3mhOLVctr0vpmL/t74lMx/otgPPsXU/r45KJ3a4NXQ trkcjzR/7+n7PAcoi9JsZG4PK3UUl53eiowgc+HfkMWx7kexq4 LXvGLD2lyrKMHhb050L3VIDUiDJbq5AEDkdTdIs2W2R0K2AT0b lv+d8QVJ9umJ1aP0IoQiK9wNX7BZUYiwzZL3pzFK6ggvyoIF/y 0BGRob3C+YL/nTgFIG9AtTadOLQf0GBY2ZwlsEFsTCfWweOdY5 D7zG6xyrqKXkShqTFQHExWWKnJktsib3rZMiUlaQ04MFRWmO9Z RlhV1srtkcg9vtiIYPph9xy/C3Jt1ul/pW8YVQXdEfa88JIYsz PSUgYhcbQ3/Lw== Cc: pcp@ietf.org Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 09:24:53 -0000 On Sep 16, 2012, at 7:38 PM, Sam Hartman wrote: > So, I've done a few hours of implementation analysis and come to a > conclusion. Before I get to my conclusion, and my analysis, I'd like = to > discuss how I think this fits into the WG process. >=20 > The IETF doesn't really deal with implementation issues except in so = far > as they impact the standardization process. I claim it's entirely > reasonable for WG participants to factor in the question of which of = the > three approaches we're considering would be easiest to implement into > their decision of which approach to standardize. "Hey, it's easy to > build x and not y," seems like a fine reason within the IETF process = to > prefer x and not y. > That's what I'm doing here; I'm presenting my opinion on what's easy = to > build as a rationale for my opinion on which option to standardize. > I hope to convince you to agree with me about which option to > standardize. >=20 > However, we're not coming to consensus on which option is easiest to > build; the IETF doesn't reach consensus on implementation issues. > I'm presenting my reasoning only so you can judge how valuable my > opinion is. If I got something factually wrong--for example I missed a > capability of an implementation--point it out. If you disagree with = the > tradeoffs that are important to me, it's probably better for you to = post > your own analysis based on your own tradeoffs than to try and convince > me my tradeoffs are "wrong." > My goal: > I think that we have a lot of open-source security tools around. I = want > it to be easy for people to add authentication to PCP > implementations. For that reason I would strongly prefer us to > standardize a solution where people can pick up existing libraries, > integrate them into their PCP servers and clients, and have > authentication. >=20 Good goal. >=20 > My conclusion: > Based on the existing open-source tools and libraries, I think it = would > be much cheaper and simpler for me to integrate a PCP-specific > authentication approach into PCP than to integrate either PANA > encapsulation or demultiplexing. > Even if you have proprietary PANA implementations, some of the issues = I > identify below may apply. >=20 > That said, I agree with Margaret that all the approaches are = technically > viable and with enough work any of the three approaches will work. In > terms of what they provide, they are very similar. Since they are > similar, simplicity and cost are important factors in my decision > criteria. >=20 > Even if you skip the detailed comparison below, I recommend reading = the > "General Notes" section at the end. >=20 > All three approaches have some components in common. The PCP client > will need an EAP supplicant library; for the PCP-specific approach = this > will be used directly. For the PANA approaches, the EAP supplicant = will > be used indirectly via the PAC. the PCP server will need a RADIUS > library, an EAP server library or both. The RADIUS library is valuable > if you're integrating into a corporate or ISP infrastructure. the EAP > server is valuable if you're trying to provide authentication for a > simple home gateway that integrates into nothing else. Again, for a > PCP-specific approach, these libraries will be used directly; for a = PANA > approach, they will be used by the PAA. One factor to consider in > evaluating these components is whether the library in question = provides > access to the EAP methods that your customers need. I'd want a library > that exposed a couple of tunnel methods from the set (EAP-FAST, > EAP-TTLS, EAP-PEAP, EAP-LEAP) and a couple of inner methods from the = set > (EAP-MSCHAPv2, EAP-PAP, EAP-PSK, EAP-GPSK) and possibly EAP-TLS. One > EAP implementation we'll run into a couple of times below is the one > from hostap/wpa_supplicant (http://w1.fi/). Your product may already = be > using this or parts of it for 802.11i. It's a actively developed very > cross-platform library. You can use it as anything from an EAP library > directly all the way up through an 802.11i implementation. It includes > EAP client, EAP server and RADIUS. > BSD licensed. There's a distinction between "analyzing a specific implementation of = Foo" vs "analyzing implementation of Foo". You better point out which one this analysis is about. And it has to be an apple-to-apple comparison (not specific = implementations of one [PANA] vs conceptual implementations of the other = [EAP-over-UDP/PCP]) =20 Use of EAP methods is not impacted by which protocol is the EAP lower = layer (PANA, PPP, IKEv2, 802.1X).=20 >=20 > PCP-Specific Approach >=20 > I've managed a project where we added EAP authentication to an > application (well really set of applications) using a protocol = specific > to our application. We were implementing draft-ietf-abfab-gss-eap. In > effect we were build an application security mechanism based on top of > raw EAP. As such we got experience with an EAP-specific approach = ported > to Linux, Windows and Mac. The Windows port is heavily integrated = into > the operating system, including providing a security support provider > integrated into the local security authority. > We have not yet ported this to mobile or embedded environments. > We used the wpa_supplicant EAP library. > Because of requirements that applied to our project but not PCP, we > ended up funding development of a new RADIUS library (we wanted = support > for RADIUS over TLS which is still in development). For PCP, we could > have used the RADIUS support in the wpa_supplicant stack, or a number = of > existing RADIUS libraries. >=20 >=20 > See the eapGSSSMInitAuthenticate function in > = http://www.project-moonshot.org/gitweb?p=3Dmech_eap.git;a=3Dblob;f=3Dmech_= eap/init_sec_context.c;h=3D9da9f4f7cffd68c4c77a8efdbecaa1e87b0865f5;hb=3D6= 5b06d7e720738acf873c20933e36fae0fe857fd > for how we integrate EAP into the client. See > eapGSSSMAcceptAuthenticate function in > = http://www.project-moonshot.org/gitweb?p=3Dmech_eap.git;a=3Dblob;f=3Dmech_= eap/accept_sec_context.c;h=3Daeba1b4d8e5b4b50128c4c04470f9c778117dbda;hb=3D= 65b06d7e720738acf873c20933e36fae0fe857fd > for how we integrate RADIUS into the server. >=20 >=20 > The biggest challenges on the EAP side were adding configuration to = the > applications to choose the right username, password and where > appropriate TLS certificate for the server were connecting to. > There were also some minor build challenges for wpa_supplicant. The > library code is well isolated, but their build system doesn't do a > great job of building shared libraries/dlls components for other > projects to re-use. > A wide selection of EAP methods are available. >=20 > On the RADIUS side, we actually spent a lot of time, almost all of = that > was because of special things our project is doing with RADIUS. There > was an early prototype that had an integrated EAP server and a bit = later > that used a stock RADIUS library. > Both of those ended up being fairly simple. >=20 > We did get the library re-use we expected. As I recall, We needed to = make no changes > to wpa_supplicant code to use it. We did change their build system a > bit. As I recall, we submitted a couple of small bug fixes to the = stock > RADIUS library when we used that, but those bug fixes were quickly > accepted upstream. >=20 > We were lucky that the state machine we were dealing with ended up > supporting multiple round trips already. One potential complexity in > integrating PCP-specific authentication into a PCP server is that EAP > exchanges will take multiple round trips, And the direction of req/rsp is opposite. > so multiple PCP messages may > be sent in response to an application requesting a mapping if an > authentication session is not set up. In many cases, existing > retransmission strategies will already include this complexity in the > client state machine. > On the server, if RADIUS is used, then responding to an incoming PCP > authentication request will require waiting for the RADIUS response; > this may complicate the server state machine. >=20 Right. Port-sharing does not have this problem as EAP/PANA is run = independently. PANA tunneling and EAP-over-PCP has this issue. > CPANA >=20 > See http://sf.net/projects/cpana >=20 > At first glance, CPANA looks promising. It's designed as a library for > others to integrate PANA into their environments. > CPANA is distributed under the BSD license. >=20 > Unfortunately, I quickly decided that CPANA was not a credible start > point in my opinion. The project has received 11 code commits over its > entire lifetime; I think 1 or 2 commits this year. > Despite claims that "docs are coming soon," in 2010, I was able to = find > no documentation. There doesn't seem to be good separation of what is = a > public interface from what is an internal interface; cpana.h includes > all the internal header files. > The example applications don't separate example-specific functionality > like reading config files well from using the library, so I wasn't = able > to get a feel for what it would be like to use the library in a > non-sample application. > On a positive note, there did seem to be an abstraction around where > responses went; it might be easier-than-expected to use CPANA in an > encapsulation or demultiplexing approach. >=20 > There's one additional huge problem with CPANA. It includes its own > rather limited EAP library which does not appear to support any of the > tunnel methods. On the server there appears to be no RADIUS support. > If I were writing a PANA library I planned to maintain for years, I'd > seriously evaluate taking chunks of code from CPANA. > If CPANA gets significant new development effort it may turn into > something interesting. I like the goal of separating library from = application. >=20 > OpenPANA >=20 > Took a look at http://sf.net/projects/openpana. > OpenPANA is under significantly more active development than CPANA. > One initial concern is the GPL3 license. Depending on the license of > your PCP product, this may not be a viable starting point. >=20 > OpenPANA used wpa_supplicant as an EAP stack; this is good. The code = has > fairly reasonable doxygen markup. The website and source distribution = do > not include pre-built doxygen output. >=20 > OpenPANA's description claims that it includes libraries and > applications. This is true, but the libraries are at the level of > parsing PANA messages and utilitiy functions. Much of the guts of the > PANA implementation is built into the applications. > The applications are specific to network access; as an example there = are > commits dealing with fixing situations that work on a wired NIC but = not > on a laptop. >=20 > OpenPANA assumes a threaded execution model. If your PCP product is > asynchronous event based, this would be a significant integration > concern. OpenPANA is an application; it uses malloc and other C = library > memory management functions directly. Turning that into a library can = be > painful for some environments. >=20 > Regardless of wich PANA approach we pick, you'd need to do some = common > work to OpenPANA to make it useful for PCP. You would need to remove = the > network access code and replace the configuration parsing. >=20 Instead of removing the code, we just not use that code-path when PANA = is executing for PCP. > For the encapsulation approach, you'd need to make fairly major > changes. You'd want OpenPANA to run as a library. Also, it really = wants > to handle sending the messages itself. Structures have a sockaddr_in = (or > sockaddr_in6) to which messages are sent. You would instead need to > restructure all that as callbacks or similar. You'd also need to > consider the comments I made about aligning the PCP state machines on > client and server with authentication when discussing the PCP-specific > approach. >=20 > Parts of the demultiplexing approach look simpler. You could run a PAA > and PAC as separate processes. If the PCP server received an > authentication request it could forward it to the PAA over a local > socket. You'd need to make a slight change so that the return address > could be preserved. In this mode, the PCP server would not need to > change its state machine to wait for authentication.=20 > Except then it gets complicated, because you need coordination between > PCP and the PAC/PAA. You need to design an implementation-specific > protocol to: >=20 > * Trigger authentications on the PAC when PCP wants to talk to a = server >=20 Yes, we'd need to add a new trigger (PCP trigger). > * update the PCP client on authentication state including session = ID,key > ID, and negotiated algorithms >=20 > * Provide error feedback from the PAC to PCP server so the user gets a > consistent error reporting experience >=20 We do not send error codes in PANA. Not sure which error reporting you = are referring to. > * Update the PCP server on new authentication sessions at the PAA > including IDs, keys and algorithm identifiers >=20 > If you do all that work you're going to end up with a fork of = OpenPANA, > not just get a library you can use and potentially refresh for new > products/product releases. Security analysis will be different > especially for things like denial of service. Can you expand on this "DoS"? >=20 > I'm quite certain making the necessary changes to OpenPANA would be = more > complex and likely to be more expensive than integrating a = PCP-specific > approach. >=20 > General notes >=20 > When you glue technologies together, you add complexity. Some of that > complexity is inherent--for example adding multi-round-trip > authentication to PCP simply will add complexity. > Some of that complexity is in the implementation domain. >=20 > There are EAP and RADIUS libraries out there that have been designed = to > work well with applications. They tend to interface to the existing > event loops, tend to allow the application to supply memory = allocators, > that sort of thing. They tend to support the application providing > configuration information. > Even so, the EAP library is going to bring along its own session > management and message reassembly. > All the options we're discussing involve that complexity. >=20 > Pana is yet another framework on top of EAP. > The PANA specifications are scoped for network access; however we're = not > directly doing network access. The changes to PANA specs between = network > access and application authentication are not very large. However we > still need to consider the benefits especially at an implementation > layer. >=20 > The PANA implementations I've looked at aren't all that thin. They > include session layers on top of the EAP session layer. Yep, they are implementing "EAP lower layers". "EAP-over-UDP/PCP" is an = EAP lower-layer and it'll have the same thing (once people realize it's = more than defining a EAP container to qualify as a "working" and = "compliant" EAP lower layer). > They are not as > mature as the EAP implementations; they will place more constraints on > things like event loops and execution models. OpenPANA brings along = its > own alarm linked lists and retransmission infrastructure on top of = what > exists in the EAP library. It brings along its own PRF+, AES and CMAC > implementations. So will any EAP lower layer. >=20 > Yet, it's easy to see a PCP server or client duplicating a lot of this > too. PCP's going to need a session and retransmission layer; it's = going > to need some cryptographic function (probably a hash-based MAC) for > integrity. Yes, for its own "PCP" needs. > PCP already has its own approach to liveness duplicating what PANA = does. >=20 OK, PCP can rely on PANA ping instead then. > Yes, if you re-use an existing EAP library and are not making > significant customizations then there will be duplication between EAP > and PCP. However PANA introduces significantly more duplication at the > implementation layer. >=20 ?? PRF, AES, CMAC=85. are used all over the stack by many protocols for = their own needs. Use libraries for them. But seeing protocols as = redundant because they are using these common bits does not make sense = to me. > My opinion is that when I consider the extra effort to use PANA and = the > extra code it brings along, I don't see what value it brings. >=20 The main flaw with this "analysis" is you or anyone else has not seen = the "EAP-over-UDP/PCP" implementation. And in fact, we have not even seen the "complete, working, and = compliant" EAP-over-UDP/PCP "protocol".=20 So, something that's not designed/implemented is "always simpler!" :-) >=20 > You could argue we could save even more by dropping EAP completely and > doing something so PCP-specific that it didn't re-use a security > framework at all. that would be a hard sell for the security area and > would provide less value to our users because they could not re-use > existing infrastructure. Alper > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From wim.henderickx@alcatel-lucent.com Mon Sep 17 03:06:40 2012 Return-Path: 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 A2A7F21F85C6 for ; Mon, 17 Sep 2012 03:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 CGARUmDDz3sL for ; Mon, 17 Sep 2012 03:06:39 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id D07C921F85C4 for ; Mon, 17 Sep 2012 03:06:34 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8HA3bRM030271 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Sep 2012 12:06:25 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 17 Sep 2012 12:05:57 +0200 From: "Henderickx, Wim (Wim)" To: Alper Yegin Date: Mon, 17 Sep 2012 12:05:53 +0200 Thread-Topic: Side-by-side or nested protocols (was Re: [pcp] PANA implementatinos to consider) Thread-Index: Ac2UrvH/rem/UUZlSKOmHn+iiW2gfwADOfuA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E1A69B56@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 10:06:40 -0000 I have a different perspective and the pains you listed in PPP/GTP from an = implementation are very straightfwd and implemented by many people so far. = I don't see the difficulties you highlight. Can you please indicate what is= the issue with them as I am not getting it? -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 Sent: maandag 17 september 2012 10:32 To: Henderickx, Wim (Wim) Cc: 'repenno@cisco.com'; 'margaretw42@gmail.com'; 'pcp@ietf.org' Subject: Side-by-side or nested protocols (was Re: [pcp] PANA implementatin= os to consider) > +1 all I have seen so far is very complex for simple authentication of pc= p. Let's embed it into pcp. >=20 It does not get simplified because you put one inside the other. In fact, i= t gets more complicated. Please see below. >=20 > I've been following this discussion and my preference would be to avoid > having a design that requires a 'control protocol' between PCP and > something else. We should reuse other IETF standards whenever possible bu= t > I would prefer everything to be part of a single protocol. This is so un-IETF to me. Here we have two distinct pieces of work (PCP and= key management), that can be satisfied using two protocols, we are talking= about cobbling them together.=20 Like that was done in the PPP-era, and like it's done in GTP (of 3GPP). Lot= of pain with both... I'd understand how other SDOs would think that way, but their priorities ar= e different. But for IETF, we design protocols, and cobbling up protocols u= nnecessarily gets in the way of modularity, which is very essential to IETF= . Right? More on this below... > Having a > separate protocol would mean significant more test and effort for > productization due to interactions, new CLIs, unforeseen state machine > issues, etc.=20 Just the opposite.=20 Inventing new EAP-over-UDP as part of PCP is a brand-new design with brand-= new code. PANA is a standard with multiple interoperating implementations.= =20 It's obviously more stable then the to-be-designed EAP-over-UDP/PCP.=20 State machines is one of the issues with cobbling up protocols. Two separat= e protocols, living side by side, the state machines have nothing to confli= ct. If you put on inside the other, then problems arise. Specifically in this case: The direction of PCP flow and EAP flow are just = the opposite. PCP is host-side driven req/rsp. EAP is network-side driven r= eq/rsp. So, now PCP state machine has to change to support that too. And, E= AP can generate asynchronous requests at any time from the network side (re= -authentication). Exact same issue that we had with the EAP-over-DHCP (in f= act this whole discussion has the same pattern..) And I have yet to hear someone saying yes EAP-over-PCP satisfies the EAP lo= wer layer requirements. I had raised this issue 3 times, and don't see anyo= ne doing the work. It's not as simple as defining a container to ship EAP p= ayloads back and forth.=20 >=20 > We will certainly even face all kinds of backward/forward compatibility > issues between PCP, PANA (as an example) and whatever control protocol > will run between them due to different features and evolution timeline. >=20 Again, situation is the opposite.=20 Having them separate will allow them to evolve independently.=20 Adding new features to a revision or extension of PANA is better than addin= g it to N different protocols which chose to embed equivalent of PANA. > Although one can argue that PCP and PANA will run together as one entity > the next step would be somebody asking for them to be decoupled and able > to run anywhere. This train is never late. >=20 They are running separately. They are de-coupled as "protocols". What we ar= e coupling is the "state" generated/used by PANA and PCP. This decoupling is a feature for "protocols", not a bug. Using state genera= ted from one protocol in another is a "architecture design" or "implementat= ion". Alper >=20 > -----Original Message----- > From: Alper Yegin > Date: Fri, 14 Sep 2012 16:38:17 +0300 > To: Margaret Wasserman > Cc: > Subject: Re: [pcp] PANA implementatinos to consider >=20 >> Hi Margaret, >>=20 >> Your below questions are implementation specific. >> Let me answer them to describe how this can be implemented in one way. >> Certainly there are other ways to implement them. >>=20 >>>=20 >>> On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: >>>> As for the implementation complexity, I don't quite understand why >>>> PANA (which is basically EAP over UDP) would ever be more complicated >>>> then to-be-designed "EAP over UDP within PCP framework". While I don't >>>> see a reason for former being more complicated, I see reasons for >>>> seeing the latter being more complicated, as the whole thing now needs >>>> to live within another protocol framework (read: format, flow, state >>>> machine harmonization between the two). >>>=20 >>> I don't understand how you get away from coupling PANA and PCP, even in >>> the demultiplexing case where they run side-by-side on the same port. = I >>> think a number of details are being glossed over in your latest documen= t >>> when you refer to a need for an "API" between PANA and PCP=A9 >>>=20 >>=20 >> Association or binding of state between PANA and PCP is common on both. >> But there are different degrees of "coupling". Or where you couple them. >> Are we coupling the state generated/maintained between the two, or are w= e >> coupling the protocols themselves. >>=20 >> You could say, a host configures a care-of address using DHCP, and uses >> that IP address with Mobile IP, hence DHCP and Mobile IP are coupled. >> Or, you could invent carrying DHCP over Mobile IP, and call that couplin= g >> too. >>=20 >> Another more relevant example: Running IKE for IPsec, or running IKE ove= r >> IPsec (however you do it). >>=20 >>=20 >>> Let's start with a simple case where the PCP Client wants to initiate >>> and authenticated PCP request... >>>=20 >>> The Client needs to ask the PANA Client to initiate authentication. >>> How? =20 >>=20 >> PCP software triggers the PaC to perform authentication. >> Like how IKE gets triggered when IPsec SA needs to be setup. >>=20 >>=20 >>> Will that request include any details about the mapping request that is >>> being made? i.e. will the PANA Client be asking for authentication _an= d >>> authorization_ to perform a particular action? Or do we assume that a >>> PCP client is authenticated via PANA, and that authorization for a >>> particular action is a separate step that is performed as part of PCP? >>> If they are separate, do we need a new set of PCP error codes for the >>> situation where an authenticated PCP client performs an unauthorized >>> action, or is that already covered in the PCP spec? >>=20 >>=20 >> That trigger I mentioned above will include two pieces of information: 1= . >> Indication that this is an auth/authz for PCP, 2. IP address of the PAA >> (which is same as the PCP server). >>=20 >>=20 >>> When the PCP Client asks the PANA Client to perform authentication, >>> what are the possible results that can be returned from that request, >>> and how are they communicated back to the PCP Client? You have only >>> described the success case in your document. >>=20 >> PANA already generates success and failure results. This result will be >> conveyed to the PCP client via the API. >> If the result is success, also the PCP_AUTH_KEY and PANA Session ID and >> PANA Key ID need to be passed via that interface. >>=20 >>=20 >>=20 >>>=20 >>> How does this work in the case where the PCP Server is not running a >>> PANA Server? I _think_ that if a PCP Client asks its PANA Client to >>> perform authentication, and the PCP Server does support authentication, >>> some sort of "unsupported version" error code will be returned to the >>> _PCP Client_ (due to the details of your proposed demultiplexing >>> scheme), and that nothing will be returned to the PANA Client, at all. >>> We would need to make sure that secure PCP clients are specified to >>> handle an "unsupported version" error differently when the PANA Client >>> is in this particular state, but how does the PCP Client know that this >>> is why that error was returned? If this does happen, how does the PCP >>> client inform the PANA Client that it should stop trying to perform >>> authentication with that particular PCP Server? >>>=20 >>=20 >> I'd like to first understand how the client-side decides when to use >> authentication, and when not to? >> Can you, or someone, explain that? Once I understand the scenarios we ar= e >> trying to cover, I can come back and answer your question. >>=20 >>=20 >>> Also, how does the PCP Client know when the _PCP Server_ is ready to >>> receive its request? Are we assuming that the PANA Server will not >>> return an indication to the PANA Client that the client has been >>> authenticated until _after_ it has provisioned the necessary SA on the >>> PANA Server? =20 >>>=20 >>=20 >> The order of events is: >>=20 >> 1. PANA is executed >> 2. PaC provides the results to the PCP client >> 3. PCP client contacts PCP server, using authentication tag generated >> with the SA from step 2. >> 4. Upon encountering new SA, PCP server contacts the PAA to obtain the >> matching parameters (or, the PAA had already pushed those params to PCP >> server after 1. These are different implementation choices=A9..) >>=20 >>=20 >>=20 >>> What if an additional application on the same PCP Client system wants >>> to perform an authenticated request with the same PCP Server in the >>> meantime? Will that second request result in a second (interleaved) >>> PANA negotiation, or will the PCP Client be told that a PANA negotiatio= n >>> is already pending? If the latter, how will the second PCP Client >>> thread by informed when the PANA negotiation has completed? (Note: Th= e >>> right answer here depends heavily on whether the PANA authentication >>> depends, in any way, on the contents of a specific PCP request -- the >>> authentication vs. authentication/authorization question above). >>>=20 >>=20 >> Second API call can be told that there is already an ongoing >> authentication and wait for the result. >> Or, maybe it says "OK" but does not generate a second PANA session >> because the same PANA session (or, more specifically the security >> association generated by it) can be used with both PCP requests. >>=20 >>=20 >>> All of these questions will need to be answered, IMO, in a full >>> specification of the PCP/PANA demultiplexing mechanism, precisely >>> _because_ PCP and PANA are running separately. >>=20 >> Errr, I don't think so. None of these are impacting the over-the-wire >> behavior (i.e., the "protocol"), but they are all about implementation -= - >> not something we need to put in the protocol specs. >>=20 >>=20 >> If we were to use EAP over PCP, do you think we need to define how EAP >> methods interface with EAP which interfaces with PCP. How one triggers >> the other and gets the results back. I don't think so. >>=20 >>=20 >>=20 >>> The "API" is where this coupling is provided between the two "state >>> machines", as you refer to them. Why is this any simpler if PANA and >>> PCP are running side-by side than if we run PANA encapsulated in PCP? >>> (or, if we run PCP directly over EAP, for that matter) >>>=20 >>=20 >>=20 >> Please see the top part about my "coupling" response. >>=20 >> If you run two protocols side by side, you point how one can trigger the >> other. And ideally, triggers target meaningful states. E.g., one protoco= l >> triggers other to run, and at the end of execution the result is returne= d >> (PCP triggers PANA to execute). >> If you run one protocol inside another, then you have to nest their stat= e >> machines, and unless you are purely lucky, that cannot work automaticall= y >> w/o aligning their state machines. (Like I said, PANA state machine is >> designed the way it is in accordance with the EAP state machine.) >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> Margaret >>>=20 >>>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Sep 17 04:27:02 2012 Return-Path: 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 86EF121F862A for ; Mon, 17 Sep 2012 04:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 Gz7csn-02UyR for ; Mon, 17 Sep 2012 04:27:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A84FB21F8628 for ; Mon, 17 Sep 2012 04:27:01 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1986118C409 for ; Mon, 17 Sep 2012 13:27:00 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id F3ACB4C07D for ; Mon, 17 Sep 2012 13:26:59 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 17 Sep 2012 13:26:59 +0200 From: To: "pcp@ietf.org" Date: Mon, 17 Sep 2012 13:26:58 +0200 Thread-Topic: DESCRIPTION Option Thread-Index: Ac2Ux1m008btMKN5TYGgLLdL5dq1ew== Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A40CB0E@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E5A40CB0EPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [pcp] DESCRIPTION Option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 11:27:02 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5A40CB0EPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, In the Paris meeting (http://www.ietf.org/proceedings/83/minutes/minutes-83= -pcp.txt), there was a suggestion to start discussion on the options define= d in draft-boucadair-pcp-extensions. I will start the discussion with two o= ptions from that draft: DESCRIPTION and CAPABILITY Options. I will send a s= eparate e-mail for the CAPABILITY Option. This message is to initiate discussion on DESCRIPTION Option: http://tools.ietf.org/html/draft-boucadair-pcp-description-option-00 The document indicates the code used for this option by implementations I'm= aware of. Comments on the DESCRIPTION option are more than welcome. If you think the working group should spent or no effort on this specificat= ion, this is also a useful comment. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E5A40CB0EPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
I= n the Paris=20 meeting (http= ://www.ietf.org/proceedings/83/minutes/minutes-83-pcp.txt),=20 there was a suggestion to start discussion on the options defined in=20 draft-boucadair-pcp-extensions. I will start the discussion with two option= s=20 from that draft: DESCRIPTION and CAPABILITY Options. I will send a separate= =20 e-mail for the CAPABILITY Option.
T= his message=20 is to initiate discussion on DESCRIPTION Option:
 
 http://tools.ietf.org/html/draft-boucadair-pcp-description-option= -00
 
T= he document=20 indicates the code used for this option by implementations I'm aware=20 of.
 
C= omments on=20 the DESCRIPTION option are more than welcome.
 
I= f you think=20 the working group should spent or no effort on this specification, thi= s is=20 also a useful comment.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F36E5A40CB0EPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Mon Sep 17 04:32:48 2012 Return-Path: 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 2707421F8525 for ; Mon, 17 Sep 2012 04:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 8293OGiFkAt2 for ; Mon, 17 Sep 2012 04:32:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC9721F8602 for ; Mon, 17 Sep 2012 04:32:47 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 423D3324081 for ; Mon, 17 Sep 2012 13:32:44 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1E55927C053 for ; Mon, 17 Sep 2012 13:32:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 17 Sep 2012 13:32:43 +0200 From: To: "pcp@ietf.org" Date: Mon, 17 Sep 2012 13:32:43 +0200 Thread-Topic: CAPABILITY Option Thread-Index: Ac2UyCcvpinpZYfzQ2ufDGrkWZrYaw== Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A40CB16@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E5A40CB16PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [pcp] CAPABILITY Option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 11:32:48 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5A40CB16PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, In the Paris meeting (http://www.ietf.org/proceedings/83/minutes/minutes-83= -pcp.txt), there was a suggestion to start discussion on the options defined i= n draft-boucadair-pcp-extensions. I will start the discussion with two opti= ons from that draft: DESCRIPTION and CAPABILITY Options. I sent a separate message for the DESCRIPTION Option. This message is to initiate discussion on CAPABILITY Option: http://tools.i= etf.org/html/draft-boucadair-pcp-capability-00 Comments on the CAPABILITY option are more than welcome. If you think the working group should spent or no effort on this specificat= ion, this is also a useful comment. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E5A40CB16PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
<= SPAN=20 class=3D489252711-17092012>Re-,
<= SPAN=20 class=3D489252711-17092012> <= /DIV>
I= n the Paris=20 meeting (http://www.ietf.org/proceedings/83/minutes/minutes-83-= pcp.txt), there was a suggestion to start discussion= on the=20 options defined in draft-boucadair-pcp-extensions. I will start the discuss= ion=20 with two options from that draft: DESCRIPTION and CAPABILITY Options.=20
 
<= SPAN=20 class=3D214191511-17092012>I sent a separate message for the DESCRIPTION Option.= =20
 
 = http://tools.ietf.org/html/draft-boucadair-pcp-capability-00<= /FONT>
 
C= omments on=20 the CAPABILITY option are more= than=20 welcome.
 
I= f you think=20 the working group should spent or no effort on this specification, thi= s is=20 also a useful comment.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F36E5A40CB16PUEXCB1Bnante_-- From praspati@cisco.com Mon Sep 17 05:50:53 2012 Return-Path: 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 3538521F8605 for ; Mon, 17 Sep 2012 05:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 uxFI4xuLzd48 for ; Mon, 17 Sep 2012 05:50:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1791D21F85C3 for ; Mon, 17 Sep 2012 05:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1629; q=dns/txt; s=iport; t=1347886252; x=1349095852; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=0x7cpt/BfD8G6kWtlvLogRiivmdUCCsFLzoTpg/SnIA=; b=SsjszfL/Sh7PTQKiPIUEGaAeCsQ1IQ+JdZhNbvUEtnzxiuu5/23XhD3B Xuv5omJ0AmoW8Oh1WyT16aaz3YL5HpnT/20DbwTkOEE5SfSC52xN0Zn+l 1ukXiC/qMt44t2LFXIu3rMGMzmLpfhxw/CChUcnLpGfoiAPWNgyWOpDPF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAF8cV1CtJXG//2dsb2JhbABEvBWBB4IgAQIEEgEnPRQBCDZCGwEGAwIEEwkSB4deC5lRgSifTZIJA5VigRSNJIFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="122307902" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 17 Sep 2012 12:50:47 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8HCol8t016256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Sep 2012 12:50:47 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.136]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 07:50:47 -0500 From: "Prashanth Patil (praspati)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-rpcw-pcp-pmipv6-serv-discovery-01.txt Thread-Index: AQHNk/Imf0N8/hHr1UujZHgF8PwympePLjeA Date: Mon, 17 Sep 2012 12:50:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [173.39.28.45] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--31.244700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-rpcw-pcp-pmipv6-serv-discovery-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 12:50:53 -0000 This is an updated version after accommodating review comments. Comments and suggestions welcome. -Prashanth > >On 31/08/12 8:53 PM, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-rpcw-pcp-pmipv6-serv-discovery-01.txt >>has been successfully submitted by Prashanth Patil and posted to the >>IETF repository. >> >>Filename: draft-rpcw-pcp-pmipv6-serv-discovery >>Revision: 01 >>Title: PCP Server Discovery with IPv4 traffic offload for Proxy Mobile >>IPv6 >>Creation date: 2012-08-31 >>WG ID: Individual Submission >>Number of pages: 13 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-rpcw-pcp-pmipv6-serv-discovery- >>0 >>1.txt >>Status: =20 >>http://datatracker.ietf.org/doc/draft-rpcw-pcp-pmipv6-serv-discovery >>Htmlized: =20 >>http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-serv-discovery-01 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-rpcw-pcp-pmipv6-serv-discovery-0= 1 >> >>Abstract: >> This document proposes a solution to PCP Server Discovery problems in >> Proxy Mobile IPv6 (PMIPv6) networks when both home network traffic >> and traffic off-loaded to local access network require traversing a >> gateway implementing NAT and/or Firewall. This draft proposes >> enhancements to DHCPv4 Relay Agent by introducing a new sub-option >> under DHCPv4 Relay Option and to PMIPv6 signaling through additional >> options to Proxy Binding Update/Acknowledgement messages. >> >> =20 >> =20 >> >> >>The IETF Secretariat >> > From margaretw42@gmail.com Mon Sep 17 05:55:48 2012 Return-Path: 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 EA84021F8557 for ; Mon, 17 Sep 2012 05:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 DAllRREP716d for ; Mon, 17 Sep 2012 05:55:48 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D47521F8554 for ; Mon, 17 Sep 2012 05:55:48 -0700 (PDT) Received: by ghbg10 with SMTP id g10so1208758ghb.31 for ; Mon, 17 Sep 2012 05:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=atI9F+8zye0Wh2sMSUtAhOVHLhyHgUaTlQEfR7FDQFI=; b=LIJO3Yw/mzbpIN6BsD11gpGlqv8hAuZZ2fYc1+nhFOTOeSI5Sn0FYJ9PCRtbcDZ5sY Cn8tadUwB3RrKqunFHS7/Qmar/mQdlfBtzjw1dqmgumFS/OoUtUdEnb1iEqKV8j5qnE7 s4SWIghjdTeQBGYfClWHFxXHvKbdoCSErsI4w855b9LF6uH9uRSqKZynP8y2SnJAW5v/ 8RcGixuGyDAJzJZ2rQFAt3M8Kc+cNSJ0346pUT0Rz+Qywdol+eb63CJhgKzlsa6iQ60k GI0+yPDDbkt0Dh7nOvSG2ZbzPS4g+ciCbIqcxWf1rvAkqjqitfi2utnyx9PivZCzMAyV s6dw== Received: by 10.236.189.68 with SMTP id b44mr11193898yhn.82.1347886547707; Mon, 17 Sep 2012 05:55:47 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id o5sm8946353anm.17.2012.09.17.05.55.43 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 05:55:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <040C6F6B-1884-49FD-B51C-E82F9F9772F4@yegin.org> Date: Mon, 17 Sep 2012 08:55:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> <6657E02B-2D08-40BE-A567-F8AB976F2741@yegin.org> <6F4080C4-A6E2-4FC0-9D3E-61992E86C22F@gmail.com> <040C6F6B-1884-49FD-B51C-E82F9F9772F4@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Authentication scenarios (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 12:55:49 -0000 Hi Alper, On Sep 17, 2012, at 4:02 AM, Alper Yegin wrote: > Few questions: >=20 > - Why is there an unauthenticated case? Or, under what real-life = scenarios would authentication be necessary? And under what real-life = scenarios would authentication be unnecessary?=20 >=20 > - If authentication is optional, is it client's preference to use it, = or network's? Would client ever attempt to use it w/o knowing network's = preference? Would it bail out if network does not support/use it?=20 >=20 > - Are we talking about optional to use or optional to implement? You = mentioned "PCP Server that does not support authentication". The scenarios under which authentication is needed are described in the = Security Considerations section of the PCP base spec, and are reiterated = at the beginning of draft-ietf-pcp-authentiction. This authentication mechanism will be both optional to use and optional = to implement -- the only mandatory-to-implement security mechanism is = the "simple security model" described in the base spec Security = Considerations section. The PCP base spec is currently with the IESG, = about to be approved as a standards track RFC. There have been several = PCP base spec implementations tested at interop events, and we expect = that there will be many PCP implementations that support the base PCP = spec and do not support this (optional) authentication mechanism. =20 So, our PCP authentication spec needs to consider the case where a PCP = client that implements (and attempts to use) the authentication = mechanism is talking to a server that doesn't even implement it. The = client needs to get a clear error in that case, so that it can pass a = useful error to the user and/or take appropriate action. If we go with a demux approach, the PCP server will receive a packet on = the PCP port that appears to contain a PCP version number that isn't = implemented by the server. It would be interesting to know what = existing PCP servers do in this case... If they return a "unsupported = version" error to the client, will the error message that is returned = contain the version number from the original header sent in the client's = request? Or will it contain the server's highest supported PCP version? = In the latter case, the error would not be returned to the PANA client, = it would be returned to the PCP Client (due to the overloading nature of = your proposed demux scheme), and we need to explain how the PCP client = will distinguish between the PCP server not implementing PANA and a real = PCP version mismatch. It is also quite unfortunate that the PCP Server = is likely to log a "version mismatch" error, when that isn't an accurate = reflection of what happened. This type of problem is typical of cases = where we overload fields in existing protocols to perform additional = functions. Margaret From simon.perreault@viagenie.ca Mon Sep 17 06:36:03 2012 Return-Path: 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 08CA321F84F1 for ; Mon, 17 Sep 2012 06:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 mK9e3zts3jzP for ; Mon, 17 Sep 2012 06:36:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E65E21F863F for ; Mon, 17 Sep 2012 06:36:02 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:6c52:66b:8aa8:775f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E67BD400AB for ; Mon, 17 Sep 2012 09:36:01 -0400 (EDT) Message-ID: <50572741.4020802@viagenie.ca> Date: Mon, 17 Sep 2012 09:36:01 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: pcp@ietf.org References: <877grv5pnk.fsf@xmission.com> In-Reply-To: <877grv5pnk.fsf@xmission.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] To change a mapping does the pcp source port need remain the same? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 13:36:03 -0000 Le 2012-09-15 10:25, Eric W. Biederman a écrit : > Would it be an error for a pcp server to require pcp clients to use > the same source port that a mapping was established with to change > that mapping? Yes it would. > As a trivial way to keep different clients from stepping on each other > by accident I would certainly require the source port to remain constant > to change a mapping. Two issues I see: - It would only be a convenience, not secure, because it would be trivial to guess and spoof. - With long-lived mappings it becomes hard to guarantee that the same port will be used for all requests. 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 From alper.yegin@yegin.org Mon Sep 17 07:16:56 2012 Return-Path: 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 F1C4421F867F for ; Mon, 17 Sep 2012 07:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tHPseeJGu-Yv for ; Mon, 17 Sep 2012 07:16:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7203621F850D for ; Mon, 17 Sep 2012 07:16:54 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lnh6V-1Tip500DMN-00hvnS; Mon, 17 Sep 2012 10:16:52 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-2 From: Alper Yegin In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702E1A69B56@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Mon, 17 Sep 2012 17:16:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <168F3276-3B97-4C7A-A7AF-0F9E7993887C@yegin.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D6702E1A69B56@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:bZEqlqtf4UUlyugz4i968VddRHYKV4cYm8x7N2+zIyp +6mL7DAQr6cf0zyWCYWSpf8DVm+2EktrYyXryRVbS4AuVVeu8N CqyYFAHiqyg8KKAHhEnyb9uon/XiXm75EitIJbvvYTI5zTIlFV 5/N8Pj4YauGjQQRdoPRcU2bypt0QtJwlUtqmyRuC3h73evVkTe SQeI53bHCHM7tP1g9fgL+C9N8Y+w9WvC/cD6RxZp1Qm6/pMjyb pu13OjAm86qIlnecPfsdgl1s538rA2qZdaJML462zeg2XWIaV8 ESEoV1qQS61FSA3sM7m61GZCwBg/rLojgbfu4IAsRSfZ9DuoqO eev9qi7DX7cbTFqQZfma2MzZxWXaLGdjkrGTYowdYhar9J+tPB 548wlmIqnpv/w== Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 14:16:56 -0000 Hi Wim, > I have a different perspective and the pains you listed in PPP/GTP = from an implementation are very straightfwd and implemented by many = people so far. I don't see the difficulties you highlight. Can you = please indicate what is the issue with them as I am not getting it? Both PPP and GTP, even though each is called a "protocol", are in fact = more like "a collection of protocols that are bundled up inside another = protocol". One mother protocol, whose main or ancillary role is to encapsulate = multiple protocols for multiple tasks. PPP/GTP perform things like encapsulation, data-path setup, mobility = management, QoS, configuration management, authentication, so on and so = forth. Single "protocol" doing all, sounds mind boggling, right? In fact, each of these tasks call for a dedicated protocol. And in fact = each is handled by a child protocol inside the mother protocol. PPP is a legacy protocol from dial-up era. It also made its way into = 3GPP2 due to lack of alternatives at that time. In both cases, over the time limitation of this "all in one" design got = in the way in different ways, and both architectures moved/moving away = from PPP.=20 Instead, each essential need is now being performed by a dedicated = "protocol" in the latest specs.=20 GTP, on the other hand, seems to be firmly lodged in the 3GPP = architecture. Not only because of its technical merits, but other = business reasons. In fact, many attempts were made by folks, backed by IETF work, to = replace GTP with separate standalone protocols, but that didn't work so = far. So, the direction and pressure is to move away from such bundling = approaches (for the very reasons I've been writing about).=20 There was even an attempt to go back in that "PPP" way when people = proposed to bundled up EAP with DHCP, that didn't fly in IETF. (It'd = have flew in other SDOs if they had the power -- again, it's a different = ball game here and there). Alper >=20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: maandag 17 september 2012 10:32 > To: Henderickx, Wim (Wim) > Cc: 'repenno@cisco.com'; 'margaretw42@gmail.com'; 'pcp@ietf.org' > Subject: Side-by-side or nested protocols (was Re: [pcp] PANA = implementatinos to consider) >=20 >=20 >> +1 all I have seen so far is very complex for simple authentication = of pcp. Let's embed it into pcp. >>=20 >=20 > It does not get simplified because you put one inside the other. In = fact, it gets more complicated. Please see below. >=20 >>=20 >> I've been following this discussion and my preference would be to = avoid >> having a design that requires a 'control protocol' between PCP and >> something else. We should reuse other IETF standards whenever = possible but >> I would prefer everything to be part of a single protocol. >=20 > This is so un-IETF to me. Here we have two distinct pieces of work = (PCP and key management), that can be satisfied using two protocols, we = are talking about cobbling them together.=20 > Like that was done in the PPP-era, and like it's done in GTP (of = 3GPP). Lot of pain with both... > I'd understand how other SDOs would think that way, but their = priorities are different. But for IETF, we design protocols, and = cobbling up protocols unnecessarily gets in the way of modularity, which = is very essential to IETF. Right? >=20 > More on this below... >=20 >=20 >> Having a >> separate protocol would mean significant more test and effort for >> productization due to interactions, new CLIs, unforeseen state = machine >> issues, etc.=20 >=20 > Just the opposite.=20 > Inventing new EAP-over-UDP as part of PCP is a brand-new design with = brand-new code. PANA is a standard with multiple interoperating = implementations.=20 > It's obviously more stable then the to-be-designed EAP-over-UDP/PCP.=20= >=20 > State machines is one of the issues with cobbling up protocols. Two = separate protocols, living side by side, the state machines have nothing = to conflict. >=20 > If you put on inside the other, then problems arise. >=20 > Specifically in this case: The direction of PCP flow and EAP flow are = just the opposite. PCP is host-side driven req/rsp. EAP is network-side = driven req/rsp. So, now PCP state machine has to change to support that = too. And, EAP can generate asynchronous requests at any time from the = network side (re-authentication). Exact same issue that we had with the = EAP-over-DHCP (in fact this whole discussion has the same pattern..) >=20 > And I have yet to hear someone saying yes EAP-over-PCP satisfies the = EAP lower layer requirements. I had raised this issue 3 times, and don't = see anyone doing the work. It's not as simple as defining a container to = ship EAP payloads back and forth.=20 >=20 >=20 >>=20 >> We will certainly even face all kinds of backward/forward = compatibility >> issues between PCP, PANA (as an example) and whatever control = protocol >> will run between them due to different features and evolution = timeline. >>=20 >=20 > Again, situation is the opposite.=20 > Having them separate will allow them to evolve independently.=20 > Adding new features to a revision or extension of PANA is better than = adding it to N different protocols which chose to embed equivalent of = PANA. >=20 >=20 >=20 >> Although one can argue that PCP and PANA will run together as one = entity >> the next step would be somebody asking for them to be decoupled and = able >> to run anywhere. This train is never late. >>=20 >=20 > They are running separately. They are de-coupled as "protocols". What = we are coupling is the "state" generated/used by PANA and PCP. > This decoupling is a feature for "protocols", not a bug. Using state = generated from one protocol in another is a "architecture design" or = "implementation". >=20 > Alper >=20 >=20 >=20 >=20 >=20 >>=20 >> -----Original Message----- >> From: Alper Yegin >> Date: Fri, 14 Sep 2012 16:38:17 +0300 >> To: Margaret Wasserman >> Cc: >> Subject: Re: [pcp] PANA implementatinos to consider >>=20 >>> Hi Margaret, >>>=20 >>> Your below questions are implementation specific. >>> Let me answer them to describe how this can be implemented in one = way. >>> Certainly there are other ways to implement them. >>>=20 >>>>=20 >>>> On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: >>>>> As for the implementation complexity, I don't quite understand why >>>>> PANA (which is basically EAP over UDP) would ever be more = complicated >>>>> then to-be-designed "EAP over UDP within PCP framework". While I = don't >>>>> see a reason for former being more complicated, I see reasons for >>>>> seeing the latter being more complicated, as the whole thing now = needs >>>>> to live within another protocol framework (read: format, flow, = state >>>>> machine harmonization between the two). >>>>=20 >>>> I don't understand how you get away from coupling PANA and PCP, = even in >>>> the demultiplexing case where they run side-by-side on the same = port. I >>>> think a number of details are being glossed over in your latest = document >>>> when you refer to a need for an "API" between PANA and PCP=A9 >>>>=20 >>>=20 >>> Association or binding of state between PANA and PCP is common on = both. >>> But there are different degrees of "coupling". Or where you couple = them. >>> Are we coupling the state generated/maintained between the two, or = are we >>> coupling the protocols themselves. >>>=20 >>> You could say, a host configures a care-of address using DHCP, and = uses >>> that IP address with Mobile IP, hence DHCP and Mobile IP are = coupled. >>> Or, you could invent carrying DHCP over Mobile IP, and call that = coupling >>> too. >>>=20 >>> Another more relevant example: Running IKE for IPsec, or running IKE = over >>> IPsec (however you do it). >>>=20 >>>=20 >>>> Let's start with a simple case where the PCP Client wants to = initiate >>>> and authenticated PCP request... >>>>=20 >>>> The Client needs to ask the PANA Client to initiate authentication. >>>> How? =20 >>>=20 >>> PCP software triggers the PaC to perform authentication. >>> Like how IKE gets triggered when IPsec SA needs to be setup. >>>=20 >>>=20 >>>> Will that request include any details about the mapping request = that is >>>> being made? i.e. will the PANA Client be asking for authentication = _and >>>> authorization_ to perform a particular action? Or do we assume = that a >>>> PCP client is authenticated via PANA, and that authorization for a >>>> particular action is a separate step that is performed as part of = PCP? >>>> If they are separate, do we need a new set of PCP error codes for = the >>>> situation where an authenticated PCP client performs an = unauthorized >>>> action, or is that already covered in the PCP spec? >>>=20 >>>=20 >>> That trigger I mentioned above will include two pieces of = information: 1. >>> Indication that this is an auth/authz for PCP, 2. IP address of the = PAA >>> (which is same as the PCP server). >>>=20 >>>=20 >>>> When the PCP Client asks the PANA Client to perform authentication, >>>> what are the possible results that can be returned from that = request, >>>> and how are they communicated back to the PCP Client? You have = only >>>> described the success case in your document. >>>=20 >>> PANA already generates success and failure results. This result will = be >>> conveyed to the PCP client via the API. >>> If the result is success, also the PCP_AUTH_KEY and PANA Session ID = and >>> PANA Key ID need to be passed via that interface. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> How does this work in the case where the PCP Server is not running = a >>>> PANA Server? I _think_ that if a PCP Client asks its PANA Client = to >>>> perform authentication, and the PCP Server does support = authentication, >>>> some sort of "unsupported version" error code will be returned to = the >>>> _PCP Client_ (due to the details of your proposed demultiplexing >>>> scheme), and that nothing will be returned to the PANA Client, at = all. >>>> We would need to make sure that secure PCP clients are specified to >>>> handle an "unsupported version" error differently when the PANA = Client >>>> is in this particular state, but how does the PCP Client know that = this >>>> is why that error was returned? If this does happen, how does the = PCP >>>> client inform the PANA Client that it should stop trying to perform >>>> authentication with that particular PCP Server? >>>>=20 >>>=20 >>> I'd like to first understand how the client-side decides when to use >>> authentication, and when not to? >>> Can you, or someone, explain that? Once I understand the scenarios = we are >>> trying to cover, I can come back and answer your question. >>>=20 >>>=20 >>>> Also, how does the PCP Client know when the _PCP Server_ is ready = to >>>> receive its request? Are we assuming that the PANA Server will not >>>> return an indication to the PANA Client that the client has been >>>> authenticated until _after_ it has provisioned the necessary SA on = the >>>> PANA Server? =20 >>>>=20 >>>=20 >>> The order of events is: >>>=20 >>> 1. PANA is executed >>> 2. PaC provides the results to the PCP client >>> 3. PCP client contacts PCP server, using authentication tag = generated >>> with the SA from step 2. >>> 4. Upon encountering new SA, PCP server contacts the PAA to obtain = the >>> matching parameters (or, the PAA had already pushed those params to = PCP >>> server after 1. These are different implementation choices=A9..) >>>=20 >>>=20 >>>=20 >>>> What if an additional application on the same PCP Client system = wants >>>> to perform an authenticated request with the same PCP Server in the >>>> meantime? Will that second request result in a second = (interleaved) >>>> PANA negotiation, or will the PCP Client be told that a PANA = negotiation >>>> is already pending? If the latter, how will the second PCP Client >>>> thread by informed when the PANA negotiation has completed? (Note: = The >>>> right answer here depends heavily on whether the PANA = authentication >>>> depends, in any way, on the contents of a specific PCP request -- = the >>>> authentication vs. authentication/authorization question above). >>>>=20 >>>=20 >>> Second API call can be told that there is already an ongoing >>> authentication and wait for the result. >>> Or, maybe it says "OK" but does not generate a second PANA session >>> because the same PANA session (or, more specifically the security >>> association generated by it) can be used with both PCP requests. >>>=20 >>>=20 >>>> All of these questions will need to be answered, IMO, in a full >>>> specification of the PCP/PANA demultiplexing mechanism, precisely >>>> _because_ PCP and PANA are running separately. >>>=20 >>> Errr, I don't think so. None of these are impacting the = over-the-wire >>> behavior (i.e., the "protocol"), but they are all about = implementation -- >>> not something we need to put in the protocol specs. >>>=20 >>>=20 >>> If we were to use EAP over PCP, do you think we need to define how = EAP >>> methods interface with EAP which interfaces with PCP. How one = triggers >>> the other and gets the results back. I don't think so. >>>=20 >>>=20 >>>=20 >>>> The "API" is where this coupling is provided between the two "state >>>> machines", as you refer to them. Why is this any simpler if PANA = and >>>> PCP are running side-by side than if we run PANA encapsulated in = PCP? >>>> (or, if we run PCP directly over EAP, for that matter) >>>>=20 >>>=20 >>>=20 >>> Please see the top part about my "coupling" response. >>>=20 >>> If you run two protocols side by side, you point how one can trigger = the >>> other. And ideally, triggers target meaningful states. E.g., one = protocol >>> triggers other to run, and at the end of execution the result is = returned >>> (PCP triggers PANA to execute). >>> If you run one protocol inside another, then you have to nest their = state >>> machines, and unless you are purely lucky, that cannot work = automatically >>> w/o aligning their state machines. (Like I said, PANA state machine = is >>> designed the way it is in accordance with the EAP state machine.) >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Margaret >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 From hartmans@painless-security.com Mon Sep 17 07:51:37 2012 Return-Path: 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 B84DF21F869D for ; Mon, 17 Sep 2012 07:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.398 X-Spam-Level: **** X-Spam-Status: No, score=4.398 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 01H5OOKbUoa0 for ; Mon, 17 Sep 2012 07:51:37 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id F1D5F21F8688 for ; Mon, 17 Sep 2012 07:51:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 31B452003E; Mon, 17 Sep 2012 10:51:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 099514149; Mon, 17 Sep 2012 10:51:11 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Mon, 17 Sep 2012 10:51:11 -0400 In-Reply-To: (Alper Yegin's message of "Mon, 17 Sep 2012 11:31:46 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'pcp@ietf.org'" Subject: Re: [pcp] [ Side-by-side or nested protocols X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 14:51:37 -0000 >> +1 all I have seen so far is very complex for simple >> authentication of pcp. Let's embed it into pcp. >> >> >> I've been following this discussion and my preference would be to >> avoid having a design that requires a 'control protocol' between >> PCP and something else. We should reuse other IETF standards >> whenever possible but I would prefer everything to be part of a >> single protocol. Alper> This is so un-IETF to me. Here we have two distinct pieces of Alper> work (PCP and key management), that can be satisfied using Alper> two protocols, we are talking about cobbling them together. Alper> Like that was done in the PPP-era, and like it's done in GTP Alper> (of 3GPP). Lot of pain with both... I'd understand how other Alper> SDOs would think that way, but their priorities are Alper> different. But for IETF, we design protocols, and cobbling up Alper> protocols unnecessarily gets in the way of modularity, which Alper> is very essential to IETF. Right? Hi. I haven't been working in the internet area that long, but I have been working in the security area of the IETF and following the apps area's security for a while. I think I have some experience with what's ietf and un-ietf in those contexts. There are two related questions here: 1) To what extent should security frameworks be re-used. 2) Whether key management should run in-band with the managed protocol. Both of these issues have been hotly discussed. There was actually an IAB document--I think draft-iab-authmech or similar--that tried to rule out any stacking of frameworks. For example you could not use GSS-API within SASL or EAP within PANA in a context where both were appropriate. This generated rather a lot of comment, and it doesn't look like that document was ever published as an RFC in part because the IAB was having trouble getting consensus around the strong negative statements against frameworks. While I think that document went too far, the general concerns about protocol layering it raised are real. Additional protocol layers does add all the forms of complexity that Wim discusses. If you get re-use of code or re-use of platform infrastructure then it can be worth that additional complexity. If you get re-use of security analysis then it can be worth the complexity. The question of in-band vs out-of-band has also been a hot question in the security area. The most recent huge instance of that discussion I'm aware of was the KARP working group. Many security participants were arguing that tight integration of key management into routing protocols would ease security analysis and make it much more likely that we got things right. In that instance, the implementor community for the routing protocols said that tight integration (in-bind) was an unacceptable implementation strategy for reasons specific to the routing protocols. Really, there are a lot of factors to consider; let me give you a few examples. Many applications have decided that authentication needs to be tightly integrated but that confidentiality and integrity should be re-used from TLS at arms length. These include IMAP, SMTP, LDAP, POP, XMPP and HTTP. Several of these have a seldom-used but sometimes important facility to more tightly integrate confidentiality and integrity. All protocols are run in-band with encapsulation. Ssh designed ssh-specific protocols for everything and runs everything in-band. IPsec uses an out-of-band separate key-management protocol. Network access uses EAP often as a out-of-band key management protocol with a separate security association protocol. >> Having a separate protocol would mean significant more test and >> effort for productization due to interactions, new CLIs, >> unforeseen state machine issues, etc. Alper> Just the opposite. Inventing new EAP-over-UDP as part of PCP Alper> is a brand-new design with brand-new code. PANA is a standard Alper> with multiple interoperating implementations. It's obviously Alper> more stable then the to-be-designed EAP-over-UDP/PCP. I actually agree with Wim. I've seen a lot of complexity gluing protocols together. Even given that I do tend to be a fan of security frameworks, but I have to admit that there are huge costs. If there is not a strong value proposition in terms of new capabilities users get, it may not be worth it. Alper> State machines is one of the issues with cobbling up Alper> protocols. Two separate protocols, living side by side, the Alper> state machines have nothing to conflict. Alper> If you put on inside the other, then problems arise. Actually, state machine alignment simply gets messy. As you point out you need to deal with the fact that the direction is different for PCP and EAP. However, in the demultiplexing case, we also have state machine issues. On the client, the state machine now needs to wait while authentication is happening. That is we're introducing a waiting-for-PANA state into the PCP client. Also, I've seen complex interactions between protocol state machines in distributed systems. The first time I ran into state machine issues was a distributed filesystem protocol called AFS. There were two very modular protocols, one for metadata access and one for accessing files. Unfortunately, they could interact with each other and delays in the metadata protocol could cause ever-increasing delays in the file service protocol. That was far more painful to debug than a single integrated protocol would have been. Alper> And I have yet to hear someone saying yes EAP-over-PCP Alper> satisfies the EAP lower layer requirements. I had raised this Alper> issue 3 times, and don't see anyone doing the work. It's not Alper> as simple as defining a container to ship EAP payloads back Alper> and forth. We've made a specific proposal that we believe satisfies the requirements of an EAP lower layer. We'd certainly appreciate your technical comments on that proposal. If we missed something please let us know. From alper.yegin@yegin.org Mon Sep 17 08:01:59 2012 Return-Path: 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 9CD6E21F86E2 for ; Mon, 17 Sep 2012 08:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3sPt726a01QN for ; Mon, 17 Sep 2012 08:01:59 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id AA3E721F86E1 for ; Mon, 17 Sep 2012 08:01:58 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MSdem-1T3lST2hW8-00SFKR; Mon, 17 Sep 2012 11:01:54 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 17 Sep 2012 18:01:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> <6657E02B-2D08-40BE-A567-F8AB976F2741@yegin.org> <6F4080C4-A6E2-4FC0-9D3E-61992E86C22F@gmail.com> <040C6F6B-1884-49FD-B51C-E82F9F9772F4@yegin.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:1xvqHNyoi80ZYL3Y3g1yhcPSEDHYBzcg03fQLSNW7sn mdilgDsb3GaQTxzXIzobTB7rdOW3AYjT+9o7T0tjoZ15M+BO9Y rvjffDve1KTyQxuaK8Cs2X+LaiBaemQcPbEukDHyfF7e9GznnI 72wppP/TChNysMkIfzdjEsZM1lfLo7ASQLtWuV0atXDIm9abbI kkRJVAOa+z5sUchFVe21YnJNg6UBEEw4B0EGPW/rRA61exEDpi Ex/NJeAH1Kdwz/mWBHFrOi3NnkXIdf4dXztN+apRO3xYGtiHP/ 3JVur0dNvTbtn7aUK7Wev23tI/A/gyj/IfIrvkYIODBwFKPMx+ EvqOnY/k/2Bj6FPApUyLpBMdAIHvIklNC0A5nbwGxErKMIL67g es8fG5RfoUf9w== Cc: pcp@ietf.org Subject: Re: [pcp] Authentication scenarios (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 15:01:59 -0000 Hi Margaret, The simplest solution is to discover security policy along with the IP = address of the PCP server. After that point on, the client-side knows whether to engage = authentication or not. Alper On Sep 17, 2012, at 3:55 PM, Margaret Wasserman wrote: >=20 > Hi Alper, >=20 > On Sep 17, 2012, at 4:02 AM, Alper Yegin wrote: >> Few questions: >>=20 >> - Why is there an unauthenticated case? Or, under what real-life = scenarios would authentication be necessary? And under what real-life = scenarios would authentication be unnecessary?=20 >>=20 >> - If authentication is optional, is it client's preference to use it, = or network's? Would client ever attempt to use it w/o knowing network's = preference? Would it bail out if network does not support/use it?=20 >>=20 >> - Are we talking about optional to use or optional to implement? You = mentioned "PCP Server that does not support authentication". >=20 > The scenarios under which authentication is needed are described in = the Security Considerations section of the PCP base spec, and are = reiterated at the beginning of draft-ietf-pcp-authentiction. >=20 > This authentication mechanism will be both optional to use and = optional to implement -- the only mandatory-to-implement security = mechanism is the "simple security model" described in the base spec = Security Considerations section. The PCP base spec is currently with the = IESG, about to be approved as a standards track RFC. There have been = several PCP base spec implementations tested at interop events, and we = expect that there will be many PCP implementations that support the base = PCP spec and do not support this (optional) authentication mechanism. =20= >=20 > So, our PCP authentication spec needs to consider the case where a PCP = client that implements (and attempts to use) the authentication = mechanism is talking to a server that doesn't even implement it. The = client needs to get a clear error in that case, so that it can pass a = useful error to the user and/or take appropriate action. >=20 > If we go with a demux approach, the PCP server will receive a packet = on the PCP port that appears to contain a PCP version number that isn't = implemented by the server. It would be interesting to know what = existing PCP servers do in this case... If they return a "unsupported = version" error to the client, will the error message that is returned = contain the version number from the original header sent in the client's = request? Or will it contain the server's highest supported PCP version? = In the latter case, the error would not be returned to the PANA client, = it would be returned to the PCP Client (due to the overloading nature of = your proposed demux scheme), and we need to explain how the PCP client = will distinguish between the PCP server not implementing PANA and a real = PCP version mismatch. It is also quite unfortunate that the PCP Server = is likely to log a "version mismatch" error, when that isn't an accurate = reflection of what happened. This type of problem is typical of cases = where we overload fields in existing protocols to perform additional = functions. >=20 > Margaret >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From hartmans@painless-security.com Mon Sep 17 08:06:36 2012 Return-Path: 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 3594221F86F9 for ; Mon, 17 Sep 2012 08:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.68 X-Spam-Level: **** X-Spam-Status: No, score=4.68 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_23=0.6, RDNS_DYNAMIC=0.1] 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 BBjJKsV5O5BP for ; Mon, 17 Sep 2012 08:06:35 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id A5B3421F86F7 for ; Mon, 17 Sep 2012 08:06:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 039D42003E; Mon, 17 Sep 2012 11:06:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C7E004149; Mon, 17 Sep 2012 11:06:09 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> Date: Mon, 17 Sep 2012 11:06:09 -0400 In-Reply-To: <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> (Alper Yegin's message of "Mon, 17 Sep 2012 12:24:32 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 15:06:36 -0000 >>>>> "Alper" == Alper Yegin writes: >> Parts of the demultiplexing approach look simpler. You could run >> a PAA and PAC as separate processes. If the PCP server received >> an authentication request it could forward it to the PAA over a >> local socket. You'd need to make a slight change so that the >> return address could be preserved. In this mode, the PCP server >> would not need to change its state machine to wait for >> authentication. Except then it gets complicated, because you >> need coordination between PCP and the PAC/PAA. You need to >> design an implementation-specific protocol to: >> >> * Trigger authentications on the PAC when PCP wants to talk to a >> server >> >Yes, we'd need to add a new trigger (PCP trigger). >> * update the PCP client on authentication state including session >> ID,key ID, and negotiated algorithms >> >> * Provide error feedback from the PAC to PCP server so the user >> gets a consistent error reporting experience >> >We do not send error codes in PANA. Not sure which error reporting you are referring to. Margaret has gone into this detail somewhat. The issue is that you want a consistent experience for the client. So, you need to do things like map PANA failures because the server doesn't support PANA into authentication not supported PCP errors. You need to log PANA and PCP errors in the same place. You need to provide consistent tools for looking at them. These are implementation not protocol issues. >> * Update the PCP server on new authentication sessions at the PAA >> including IDs, keys and algorithm identifiers >> >> If you do all that work you're going to end up with a fork of >> OpenPANA, not just get a library you can use and potentially >> refresh for new products/product releases. Security analysis >> will be different especially for things like denial of service. Alper> Can you expand on this "DoS"? Sure. So, even in the demultiplexing case, we're coupling the state machines together. As an example we're creating a new PCP client state that is basically waiting for PANA. We need to do the security analysis for that. One of the simpler issues is a question like can an malicious server cause a PCP client to block indefinitely by swapping back and forth between PCP and PANA. --Sam From repenno@cisco.com Mon Sep 17 08:10:02 2012 Return-Path: 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 C119221F86F7 for ; Mon, 17 Sep 2012 08:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_43=1, RCVD_IN_DNSWL_HI=-8] 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 SdJR25QD3cUD for ; Mon, 17 Sep 2012 08:10:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3E46021F86F8 for ; Mon, 17 Sep 2012 08:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14124; q=dns/txt; s=iport; t=1347894601; x=1349104201; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Rl8dQi9EpTn5FegtWXk2vR7r2GZvnRjO0LoAacPuf/M=; b=Do5cHCdXTXgdI4Qkm4L9pjsypapgX3Y6uVDAgtBAshNEGPt0AIRAvSg1 qtJ1HED+EfAwvzTpuCKaNPFiMAY6yOxImsK8jkFT3x5s5PU6eaCVuKH+y akS03+7bM94re50XPl8BQPcKHgj3uOvoyPDgSGSaFK4FwF88r18ty/mFe 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIHALY8V1CtJV2Y/2dsb2JhbABEt2mELIEHgiABAQEEAQEBDwEURwsMBgEIEQECAQIBTwYLFwYIAgQOBRsHh08DDAuacJYDDYlPBIo+Y4ZoA5IxgVyBVYsXgyGBaYJmghc X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="122362238" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 17 Sep 2012 15:10:00 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8HFA0NV001011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 15:10:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 10:10:00 -0500 From: "Reinaldo Penno (repenno)" To: Alper Yegin , "Henderickx, Wim (Wim)" Thread-Topic: Side-by-side or nested protocols (was Re: [pcp] PANA implementatinos to consider) Thread-Index: AQHNlK7vlZXBAt5m0kamo0nw+r8wLpeOghkA Date: Mon, 17 Sep 2012 15:09:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.146.38] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--62.457300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 15:10:02 -0000 -----Original Message----- From: Alper Yegin Date: Mon, 17 Sep 2012 11:31:46 +0300 To: "Henderickx, Wim (Wim)" Cc: Reinaldo Penno , "'margaretw42@gmail.com'" , "'pcp@ietf.org'" Subject: Side-by-side or nested protocols (was Re: [pcp] PANA implementatinos to consider) > >> +1 all I have seen so far is very complex for simple authentication of >>pcp. Let's embed it into pcp. >>=20 > >It does not get simplified because you put one inside the other. In fact, >it gets more complicated. Please see below. > >>=20 >> I've been following this discussion and my preference would be to avoid >> having a design that requires a 'control protocol' between PCP and >> something else. We should reuse other IETF standards whenever possible >>but >> I would prefer everything to be part of a single protocol. > >This is so un-IETF to me. Here we have two distinct pieces of work (PCP >and key management), that can be satisfied using two protocols, we are >talking about cobbling them together. >Like that was done in the PPP-era, and like it's done in GTP (of 3GPP). >Lot of pain with both... >I'd understand how other SDOs would think that way, but their priorities >are different. But for IETF, we design protocols, and cobbling up >protocols unnecessarily gets in the way of modularity, which is very >essential to IETF. Right? > >More on this below... > > >> Having a >> separate protocol would mean significant more test and effort for >> productization due to interactions, new CLIs, unforeseen state machine >> issues, etc.=20 > >Just the opposite. >Inventing new EAP-over-UDP as part of PCP is a brand-new design with >brand-new code. PANA is a standard with multiple interoperating >implementations.=20 >It's obviously more stable then the to-be-designed EAP-over-UDP/PCP. I posit that the effort to productize PANA or a yet to be defined EAP-over-UDP (or something else) is almost the same. Unless the vendor that is implementing PCP Server has PANA in production but I'm not aware of any. >=20 > >State machines is one of the issues with cobbling up protocols. Two >separate protocols, living side by side, the state machines have nothing >to conflict. Conflict is not the right word. You are low balling this issue. Synching two state machines that depend on each other can be tricky. > >If you put on inside the other, then problems arise. > >Specifically in this case: The direction of PCP flow and EAP flow are >just the opposite. PCP is host-side driven req/rsp. EAP is network-side >driven req/rsp. So, now PCP state machine has to change to support that >too. And, EAP can generate asynchronous requests at any time from the >network side (re-authentication). Exact same issue that we had with the >EAP-over-DHCP (in fact this whole discussion has the same pattern....) PCP is capable of sending unsolicited messages (both multicast and unicast). So, we are good here. > >And I have yet to hear someone saying yes EAP-over-PCP satisfies the EAP >lower layer requirements. I had raised this issue 3 times, and don't see >anyone doing the work. It's not as simple as defining a container to ship >EAP payloads back and forth. > > >>=20 >> We will certainly even face all kinds of backward/forward compatibility >> issues between PCP, PANA (as an example) and whatever control protocol >> will run between them due to different features and evolution timeline. >>=20 > >Again, situation is the opposite. >Having them separate will allow them to evolve independently. If PANA (and PANA<->PCP) are not there then this is a non-issue. Moreover, If PANA is an integral part of PCP 'feature' then if PANA evolves, that means PCP feature needs to be fully tested, regressed, etc. >=20 >Adding new features to a revision or extension of PANA is better than >adding it to N different protocols which chose to embed equivalent of >PANA. > The final solution with a PCP specific method might look different than PANA. > > >> Although one can argue that PCP and PANA will run together as one entity >> the next step would be somebody asking for them to be decoupled and able >> to run anywhere. This train is never late. >>=20 > >They are running separately. They are de-coupled as "protocols". What we >are coupling is the "state" generated/used by PANA and PCP. >This decoupling is a feature for "protocols", not a bug. Using state >generated from one protocol in another is a "architecture design" or >"implementation". You are missing the point here. The implementation complexity of your proposal is considerable because you will have: - PANA=20 - PCP - PANA <-> PCP protocol But a case in point: I have experience with H.248Ia and Diameter-like to do session control through NATs. Something similar to what we are trying to achieve. Parallel to H.248 we had an authentication protocol. Dealing with those two state machines was complex and can not be ignored. > >Alper > > > > > >>=20 >> -----Original Message----- >> From: Alper Yegin >> Date: Fri, 14 Sep 2012 16:38:17 +0300 >> To: Margaret Wasserman >> Cc: >> Subject: Re: [pcp] PANA implementatinos to consider >>=20 >>> Hi Margaret, >>>=20 >>> Your below questions are implementation specific. >>> Let me answer them to describe how this can be implemented in one way. >>> Certainly there are other ways to implement them. >>>=20 >>>>=20 >>>> On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: >>>>> As for the implementation complexity, I don't quite understand why >>>>> PANA (which is basically EAP over UDP) would ever be more complicated >>>>> then to-be-designed "EAP over UDP within PCP framework". While I >>>>>don't >>>>> see a reason for former being more complicated, I see reasons for >>>>> seeing the latter being more complicated, as the whole thing now >>>>>needs >>>>> to live within another protocol framework (read: format, flow, state >>>>> machine harmonization between the two). >>>>=20 >>>> I don't understand how you get away from coupling PANA and PCP, even >>>>in >>>> the demultiplexing case where they run side-by-side on the same port. >>>> I >>>> think a number of details are being glossed over in your latest >>>>document >>>> when you refer to a need for an "API" between PANA and PCP=A9 >>>>=20 >>>=20 >>> Association or binding of state between PANA and PCP is common on both. >>> But there are different degrees of "coupling". Or where you couple >>>them. >>> Are we coupling the state generated/maintained between the two, or are >>>we >>> coupling the protocols themselves. >>>=20 >>> You could say, a host configures a care-of address using DHCP, and uses >>> that IP address with Mobile IP, hence DHCP and Mobile IP are coupled. >>> Or, you could invent carrying DHCP over Mobile IP, and call that >>>coupling >>> too. >>>=20 >>> Another more relevant example: Running IKE for IPsec, or running IKE >>>over >>> IPsec (however you do it). >>>=20 >>>=20 >>>> Let's start with a simple case where the PCP Client wants to initiate >>>> and authenticated PCP request... >>>>=20 >>>> The Client needs to ask the PANA Client to initiate authentication. >>>> How? =20 >>>=20 >>> PCP software triggers the PaC to perform authentication. >>> Like how IKE gets triggered when IPsec SA needs to be setup. >>>=20 >>>=20 >>>> Will that request include any details about the mapping request that >>>>is >>>> being made? i.e. will the PANA Client be asking for authentication >>>>_and >>>> authorization_ to perform a particular action? Or do we assume that a >>>> PCP client is authenticated via PANA, and that authorization for a >>>> particular action is a separate step that is performed as part of PCP? >>>> If they are separate, do we need a new set of PCP error codes for the >>>> situation where an authenticated PCP client performs an unauthorized >>>> action, or is that already covered in the PCP spec? >>>=20 >>>=20 >>> That trigger I mentioned above will include two pieces of information: >>>1. >>> Indication that this is an auth/authz for PCP, 2. IP address of the PAA >>> (which is same as the PCP server). >>>=20 >>>=20 >>>> When the PCP Client asks the PANA Client to perform authentication, >>>> what are the possible results that can be returned from that request, >>>> and how are they communicated back to the PCP Client? You have only >>>> described the success case in your document. >>>=20 >>> PANA already generates success and failure results. This result will be >>> conveyed to the PCP client via the API. >>> If the result is success, also the PCP_AUTH_KEY and PANA Session ID and >>> PANA Key ID need to be passed via that interface. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> How does this work in the case where the PCP Server is not running a >>>> PANA Server? I _think_ that if a PCP Client asks its PANA Client to >>>> perform authentication, and the PCP Server does support >>>>authentication, >>>> some sort of "unsupported version" error code will be returned to the >>>> _PCP Client_ (due to the details of your proposed demultiplexing >>>> scheme), and that nothing will be returned to the PANA Client, at all. >>>> We would need to make sure that secure PCP clients are specified to >>>> handle an "unsupported version" error differently when the PANA Client >>>> is in this particular state, but how does the PCP Client know that >>>>this >>>> is why that error was returned? If this does happen, how does the PCP >>>> client inform the PANA Client that it should stop trying to perform >>>> authentication with that particular PCP Server? >>>>=20 >>>=20 >>> I'd like to first understand how the client-side decides when to use >>> authentication, and when not to? >>> Can you, or someone, explain that? Once I understand the scenarios we >>>are >>> trying to cover, I can come back and answer your question. >>>=20 >>>=20 >>>> Also, how does the PCP Client know when the _PCP Server_ is ready to >>>> receive its request? Are we assuming that the PANA Server will not >>>> return an indication to the PANA Client that the client has been >>>> authenticated until _after_ it has provisioned the necessary SA on the >>>> PANA Server? =20 >>>>=20 >>>=20 >>> The order of events is: >>>=20 >>> 1. PANA is executed >>> 2. PaC provides the results to the PCP client >>> 3. PCP client contacts PCP server, using authentication tag generated >>> with the SA from step 2. >>> 4. Upon encountering new SA, PCP server contacts the PAA to obtain the >>> matching parameters (or, the PAA had already pushed those params to PCP >>> server after 1. These are different implementation choices=A9..) >>>=20 >>>=20 >>>=20 >>>> What if an additional application on the same PCP Client system wants >>>> to perform an authenticated request with the same PCP Server in the >>>> meantime? Will that second request result in a second (interleaved) >>>> PANA negotiation, or will the PCP Client be told that a PANA >>>>negotiation >>>> is already pending? If the latter, how will the second PCP Client >>>> thread by informed when the PANA negotiation has completed? (Note: >>>>The >>>> right answer here depends heavily on whether the PANA authentication >>>> depends, in any way, on the contents of a specific PCP request -- the >>>> authentication vs. authentication/authorization question above). >>>>=20 >>>=20 >>> Second API call can be told that there is already an ongoing >>> authentication and wait for the result. >>> Or, maybe it says "OK" but does not generate a second PANA session >>> because the same PANA session (or, more specifically the security >>> association generated by it) can be used with both PCP requests. >>>=20 >>>=20 >>>> All of these questions will need to be answered, IMO, in a full >>>> specification of the PCP/PANA demultiplexing mechanism, precisely >>>> _because_ PCP and PANA are running separately. >>>=20 >>> Errr, I don't think so. None of these are impacting the over-the-wire >>> behavior (i.e., the "protocol"), but they are all about implementation >>>-- >>> not something we need to put in the protocol specs. >>>=20 >>>=20 >>> If we were to use EAP over PCP, do you think we need to define how EAP >>> methods interface with EAP which interfaces with PCP. How one triggers >>> the other and gets the results back. I don't think so. >>>=20 >>>=20 >>>=20 >>>> The "API" is where this coupling is provided between the two "state >>>> machines", as you refer to them. Why is this any simpler if PANA and >>>> PCP are running side-by side than if we run PANA encapsulated in PCP? >>>> (or, if we run PCP directly over EAP, for that matter) >>>>=20 >>>=20 >>>=20 >>> Please see the top part about my "coupling" response. >>>=20 >>> If you run two protocols side by side, you point how one can trigger >>>the >>> other. And ideally, triggers target meaningful states. E.g., one >>>protocol >>> triggers other to run, and at the end of execution the result is >>>returned >>> (PCP triggers PANA to execute). >>> If you run one protocol inside another, then you have to nest their >>>state >>> machines, and unless you are purely lucky, that cannot work >>>automatically >>> w/o aligning their state machines. (Like I said, PANA state machine is >>> designed the way it is in accordance with the EAP state machine.) >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Margaret >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp From yoshihiro.ohba@toshiba.co.jp Mon Sep 17 15:46:59 2012 Return-Path: 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 1313121E808C for ; Mon, 17 Sep 2012 15:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 7gwFdY-ZGQVg for ; Mon, 17 Sep 2012 15:46:57 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4D72D21E8063 for ; Mon, 17 Sep 2012 15:46:56 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8HMksX4014464 for ; Tue, 18 Sep 2012 07:46:54 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8HMksAl021565 for pcp@ietf.org; Tue, 18 Sep 2012 07:46:54 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id HAA21563; Tue, 18 Sep 2012 07:46:54 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8HMknlJ005340 for ; Tue, 18 Sep 2012 07:46:54 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8HMkmNO013159; Tue, 18 Sep 2012 07:46:49 +0900 (JST) Received: from [133.199.16.52] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAI00EFXN9Z4320@mail.po.toshiba.co.jp> for pcp@ietf.org; Tue, 18 Sep 2012 07:46:48 +0900 (JST) Date: Tue, 18 Sep 2012 07:46:47 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <5057A857.10203@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:46:59 -0000 Sam, Thank you for your detailed implementation analysis. As I already mentioned, I would expect open source implementors are smart to accommodate your feedback, or they may even say more if you are missing something. I keep recommending to use something that is well defined and interoperable instead of trying to re-invent the wheel, especially where there is an agreement that all three approaches are similar in functionality. Given that all implementation points you made look minor. IMO, the major difference is whether a solution re-uses an existing work or duplicates the work. Duplicating the existing work is in general a bad idea. It would be a nightmare if each protocol has its own EAP over UDP variants and implementers need to implement each of them, and PCP is not an exception. Regards, Yoshihiro Ohba (2012/09/17 1:38), Sam Hartman wrote: > So, I've done a few hours of implementation analysis and come to a > conclusion. Before I get to my conclusion, and my analysis, I'd like to > discuss how I think this fits into the WG process. > > The IETF doesn't really deal with implementation issues except in so far > as they impact the standardization process. I claim it's entirely > reasonable for WG participants to factor in the question of which of the > three approaches we're considering would be easiest to implement into > their decision of which approach to standardize. "Hey, it's easy to > build x and not y," seems like a fine reason within the IETF process to > prefer x and not y. > That's what I'm doing here; I'm presenting my opinion on what's easy to > build as a rationale for my opinion on which option to standardize. > I hope to convince you to agree with me about which option to > standardize. > > However, we're not coming to consensus on which option is easiest to > build; the IETF doesn't reach consensus on implementation issues. > I'm presenting my reasoning only so you can judge how valuable my > opinion is. If I got something factually wrong--for example I missed a > capability of an implementation--point it out. If you disagree with the > tradeoffs that are important to me, it's probably better for you to post > your own analysis based on your own tradeoffs than to try and convince > me my tradeoffs are "wrong." > My goal: > I think that we have a lot of open-source security tools around. I want > it to be easy for people to add authentication to PCP > implementations. For that reason I would strongly prefer us to > standardize a solution where people can pick up existing libraries, > integrate them into their PCP servers and clients, and have > authentication. > > > My conclusion: > Based on the existing open-source tools and libraries, I think it would > be much cheaper and simpler for me to integrate a PCP-specific > authentication approach into PCP than to integrate either PANA > encapsulation or demultiplexing. > Even if you have proprietary PANA implementations, some of the issues I > identify below may apply. > > That said, I agree with Margaret that all the approaches are technically > viable and with enough work any of the three approaches will work. In > terms of what they provide, they are very similar. Since they are > similar, simplicity and cost are important factors in my decision > criteria. > > Even if you skip the detailed comparison below, I recommend reading the > "General Notes" section at the end. > > All three approaches have some components in common. The PCP client > will need an EAP supplicant library; for the PCP-specific approach this > will be used directly. For the PANA approaches, the EAP supplicant will > be used indirectly via the PAC. the PCP server will need a RADIUS > library, an EAP server library or both. The RADIUS library is valuable > if you're integrating into a corporate or ISP infrastructure. the EAP > server is valuable if you're trying to provide authentication for a > simple home gateway that integrates into nothing else. Again, for a > PCP-specific approach, these libraries will be used directly; for a PANA > approach, they will be used by the PAA. One factor to consider in > evaluating these components is whether the library in question provides > access to the EAP methods that your customers need. I'd want a library > that exposed a couple of tunnel methods from the set (EAP-FAST, > EAP-TTLS, EAP-PEAP, EAP-LEAP) and a couple of inner methods from the set > (EAP-MSCHAPv2, EAP-PAP, EAP-PSK, EAP-GPSK) and possibly EAP-TLS. One > EAP implementation we'll run into a couple of times below is the one > from hostap/wpa_supplicant (http://w1.fi/). Your product may already be > using this or parts of it for 802.11i. It's a actively developed very > cross-platform library. You can use it as anything from an EAP library > directly all the way up through an 802.11i implementation. It includes > EAP client, EAP server and RADIUS. > BSD licensed. > > PCP-Specific Approach > > I've managed a project where we added EAP authentication to an > application (well really set of applications) using a protocol specific > to our application. We were implementing draft-ietf-abfab-gss-eap. In > effect we were build an application security mechanism based on top of > raw EAP. As such we got experience with an EAP-specific approach ported > to Linux, Windows and Mac. The Windows port is heavily integrated into > the operating system, including providing a security support provider > integrated into the local security authority. > We have not yet ported this to mobile or embedded environments. > We used the wpa_supplicant EAP library. > Because of requirements that applied to our project but not PCP, we > ended up funding development of a new RADIUS library (we wanted support > for RADIUS over TLS which is still in development). For PCP, we could > have used the RADIUS support in the wpa_supplicant stack, or a number of > existing RADIUS libraries. > > > See the eapGSSSMInitAuthenticate function in > http://www.project-moonshot.org/gitweb?p=mech_eap.git;a=blob;f=mech_eap/init_sec_context.c;h=9da9f4f7cffd68c4c77a8efdbecaa1e87b0865f5;hb=65b06d7e720738acf873c20933e36fae0fe857fd > for how we integrate EAP into the client. See > eapGSSSMAcceptAuthenticate function in > http://www.project-moonshot.org/gitweb?p=mech_eap.git;a=blob;f=mech_eap/accept_sec_context.c;h=aeba1b4d8e5b4b50128c4c04470f9c778117dbda;hb=65b06d7e720738acf873c20933e36fae0fe857fd > for how we integrate RADIUS into the server. > > > The biggest challenges on the EAP side were adding configuration to the > applications to choose the right username, password and where > appropriate TLS certificate for the server were connecting to. > There were also some minor build challenges for wpa_supplicant. The > library code is well isolated, but their build system doesn't do a > great job of building shared libraries/dlls components for other > projects to re-use. > A wide selection of EAP methods are available. > > On the RADIUS side, we actually spent a lot of time, almost all of that > was because of special things our project is doing with RADIUS. There > was an early prototype that had an integrated EAP server and a bit later > that used a stock RADIUS library. > Both of those ended up being fairly simple. > > We did get the library re-use we expected. As I recall, We needed to make no changes > to wpa_supplicant code to use it. We did change their build system a > bit. As I recall, we submitted a couple of small bug fixes to the stock > RADIUS library when we used that, but those bug fixes were quickly > accepted upstream. > > We were lucky that the state machine we were dealing with ended up > supporting multiple round trips already. One potential complexity in > integrating PCP-specific authentication into a PCP server is that EAP > exchanges will take multiple round trips, so multiple PCP messages may > be sent in response to an application requesting a mapping if an > authentication session is not set up. In many cases, existing > retransmission strategies will already include this complexity in the > client state machine. > On the server, if RADIUS is used, then responding to an incoming PCP > authentication request will require waiting for the RADIUS response; > this may complicate the server state machine. > > CPANA > > See http://sf.net/projects/cpana > > At first glance, CPANA looks promising. It's designed as a library for > others to integrate PANA into their environments. > CPANA is distributed under the BSD license. > > Unfortunately, I quickly decided that CPANA was not a credible start > point in my opinion. The project has received 11 code commits over its > entire lifetime; I think 1 or 2 commits this year. > Despite claims that "docs are coming soon," in 2010, I was able to find > no documentation. There doesn't seem to be good separation of what is a > public interface from what is an internal interface; cpana.h includes > all the internal header files. > The example applications don't separate example-specific functionality > like reading config files well from using the library, so I wasn't able > to get a feel for what it would be like to use the library in a > non-sample application. > On a positive note, there did seem to be an abstraction around where > responses went; it might be easier-than-expected to use CPANA in an > encapsulation or demultiplexing approach. > > There's one additional huge problem with CPANA. It includes its own > rather limited EAP library which does not appear to support any of the > tunnel methods. On the server there appears to be no RADIUS support. > If I were writing a PANA library I planned to maintain for years, I'd > seriously evaluate taking chunks of code from CPANA. > If CPANA gets significant new development effort it may turn into > something interesting. I like the goal of separating library from application. > > OpenPANA > > Took a look at http://sf.net/projects/openpana. > OpenPANA is under significantly more active development than CPANA. > One initial concern is the GPL3 license. Depending on the license of > your PCP product, this may not be a viable starting point. > > OpenPANA used wpa_supplicant as an EAP stack; this is good. The code has > fairly reasonable doxygen markup. The website and source distribution do > not include pre-built doxygen output. > > OpenPANA's description claims that it includes libraries and > applications. This is true, but the libraries are at the level of > parsing PANA messages and utilitiy functions. Much of the guts of the > PANA implementation is built into the applications. > The applications are specific to network access; as an example there are > commits dealing with fixing situations that work on a wired NIC but not > on a laptop. > > OpenPANA assumes a threaded execution model. If your PCP product is > asynchronous event based, this would be a significant integration > concern. OpenPANA is an application; it uses malloc and other C library > memory management functions directly. Turning that into a library can be > painful for some environments. > > Regardless of wich PANA approach we pick, you'd need to do some common > work to OpenPANA to make it useful for PCP. You would need to remove the > network access code and replace the configuration parsing. > > For the encapsulation approach, you'd need to make fairly major > changes. You'd want OpenPANA to run as a library. Also, it really wants > to handle sending the messages itself. Structures have a sockaddr_in (or > sockaddr_in6) to which messages are sent. You would instead need to > restructure all that as callbacks or similar. You'd also need to > consider the comments I made about aligning the PCP state machines on > client and server with authentication when discussing the PCP-specific > approach. > > Parts of the demultiplexing approach look simpler. You could run a PAA > and PAC as separate processes. If the PCP server received an > authentication request it could forward it to the PAA over a local > socket. You'd need to make a slight change so that the return address > could be preserved. In this mode, the PCP server would not need to > change its state machine to wait for authentication. > Except then it gets complicated, because you need coordination between > PCP and the PAC/PAA. You need to design an implementation-specific > protocol to: > > * Trigger authentications on the PAC when PCP wants to talk to a server > > * update the PCP client on authentication state including session ID,key > ID, and negotiated algorithms > > * Provide error feedback from the PAC to PCP server so the user gets a > consistent error reporting experience > > * Update the PCP server on new authentication sessions at the PAA > including IDs, keys and algorithm identifiers > > If you do all that work you're going to end up with a fork of OpenPANA, > not just get a library you can use and potentially refresh for new > products/product releases. Security analysis will be different > especially for things like denial of service. > > I'm quite certain making the necessary changes to OpenPANA would be more > complex and likely to be more expensive than integrating a PCP-specific > approach. > > General notes > > When you glue technologies together, you add complexity. Some of that > complexity is inherent--for example adding multi-round-trip > authentication to PCP simply will add complexity. > Some of that complexity is in the implementation domain. > > There are EAP and RADIUS libraries out there that have been designed to > work well with applications. They tend to interface to the existing > event loops, tend to allow the application to supply memory allocators, > that sort of thing. They tend to support the application providing > configuration information. > Even so, the EAP library is going to bring along its own session > management and message reassembly. > All the options we're discussing involve that complexity. > > Pana is yet another framework on top of EAP. > The PANA specifications are scoped for network access; however we're not > directly doing network access. The changes to PANA specs between network > access and application authentication are not very large. However we > still need to consider the benefits especially at an implementation > layer. > > The PANA implementations I've looked at aren't all that thin. They > include session layers on top of the EAP session layer. They are not as > mature as the EAP implementations; they will place more constraints on > things like event loops and execution models. OpenPANA brings along its > own alarm linked lists and retransmission infrastructure on top of what > exists in the EAP library. It brings along its own PRF+, AES and CMAC > implementations. > > Yet, it's easy to see a PCP server or client duplicating a lot of this > too. PCP's going to need a session and retransmission layer; it's going > to need some cryptographic function (probably a hash-based MAC) for > integrity. > PCP already has its own approach to liveness duplicating what PANA does. > > Yes, if you re-use an existing EAP library and are not making > significant customizations then there will be duplication between EAP > and PCP. However PANA introduces significantly more duplication at the > implementation layer. > > My opinion is that when I consider the extra effort to use PANA and the > extra code it brings along, I don't see what value it brings. > > > You could argue we could save even more by dropping EAP completely and > doing something so PCP-specific that it didn't re-use a security > framework at all. that would be a hard sell for the security area and > would provide less value to our users because they could not re-use > existing infrastructure. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From yoshihiro.ohba@toshiba.co.jp Mon Sep 17 16:15:02 2012 Return-Path: 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 94F7521F845D for ; Mon, 17 Sep 2012 16:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.004 X-Spam-Level: X-Spam-Status: No, score=-5.004 tagged_above=-999 required=5 tests=[AWL=-1.915, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_BACKHAIR_43=1, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 szsNsv-XViV2 for ; Mon, 17 Sep 2012 16:15:01 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id EFEB221F844F for ; Mon, 17 Sep 2012 16:15:00 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q8HNExPL027045 for ; Tue, 18 Sep 2012 08:14:59 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q8HNExw9009459 for pcp@ietf.org; Tue, 18 Sep 2012 08:14:59 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA09458; Tue, 18 Sep 2012 08:14:59 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q8HNExtK002449 for ; Tue, 18 Sep 2012 08:14:59 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8HNEx5Q000623; Tue, 18 Sep 2012 08:14:59 +0900 (JST) Received: from [133.199.16.52] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAI00EY8OKY4320@mail.po.toshiba.co.jp> for pcp@ietf.org; Tue, 18 Sep 2012 08:14:59 +0900 (JST) Date: Tue, 18 Sep 2012 08:14:58 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <5057AEF2.9080803@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 8BIT References: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 23:15:02 -0000 Both PANA and PCP have well defined state machines, and those help defining interactions between PCP and PANA state machines in the same as interactions between EAP and PANA, and PCP and PANA can evolve independently as long as the interactions do not change. Or am I missing something? Yoshihiro Ohba (2012/09/18 0:09), Reinaldo Penno (repenno) wrote: > > > -----Original Message----- > From: Alper Yegin > Date: Mon, 17 Sep 2012 11:31:46 +0300 > To: "Henderickx, Wim (Wim)" > Cc: Reinaldo Penno , "'margaretw42@gmail.com'" > , "'pcp@ietf.org'" > Subject: Side-by-side or nested protocols (was Re: [pcp] PANA > implementatinos to consider) > >> >>> +1 all I have seen so far is very complex for simple authentication of >>> pcp. Let's embed it into pcp. >>> >> >> It does not get simplified because you put one inside the other. In fact, >> it gets more complicated. Please see below. >> >>> >>> I've been following this discussion and my preference would be to avoid >>> having a design that requires a 'control protocol' between PCP and >>> something else. We should reuse other IETF standards whenever possible >>> but >>> I would prefer everything to be part of a single protocol. >> >> This is so un-IETF to me. Here we have two distinct pieces of work (PCP >> and key management), that can be satisfied using two protocols, we are >> talking about cobbling them together. >> Like that was done in the PPP-era, and like it's done in GTP (of 3GPP). >> Lot of pain with both... >> I'd understand how other SDOs would think that way, but their priorities >> are different. But for IETF, we design protocols, and cobbling up >> protocols unnecessarily gets in the way of modularity, which is very >> essential to IETF. Right? >> >> More on this below... >> >> >>> Having a >>> separate protocol would mean significant more test and effort for >>> productization due to interactions, new CLIs, unforeseen state machine >>> issues, etc. >> >> Just the opposite. >> Inventing new EAP-over-UDP as part of PCP is a brand-new design with >> brand-new code. PANA is a standard with multiple interoperating >> implementations. >> It's obviously more stable then the to-be-designed EAP-over-UDP/PCP. > > I posit that the effort to productize PANA or a yet to be defined > EAP-over-UDP (or something else) is almost the same. Unless the vendor > that is implementing > PCP Server has PANA in production but I'm not aware of any. > > >> >> >> State machines is one of the issues with cobbling up protocols. Two >> separate protocols, living side by side, the state machines have nothing >> to conflict. > > > Conflict is not the right word. You are low balling this issue. Synching > two state machines that depend on each other can be tricky. > > >> >> If you put on inside the other, then problems arise. > >> >> Specifically in this case: The direction of PCP flow and EAP flow are >> just the opposite. PCP is host-side driven req/rsp. EAP is network-side >> driven req/rsp. So, now PCP state machine has to change to support that >> too. And, EAP can generate asynchronous requests at any time from the >> network side (re-authentication). Exact same issue that we had with the >> EAP-over-DHCP (in fact this whole discussion has the same pattern....) > > > PCP is capable of sending unsolicited messages (both multicast and > unicast). So, we are good here. > >> >> And I have yet to hear someone saying yes EAP-over-PCP satisfies the EAP >> lower layer requirements. I had raised this issue 3 times, and don't see >> anyone doing the work. It's not as simple as defining a container to ship >> EAP payloads back and forth. >> >> >>> >>> We will certainly even face all kinds of backward/forward compatibility >>> issues between PCP, PANA (as an example) and whatever control protocol >>> will run between them due to different features and evolution timeline. >>> >> >> Again, situation is the opposite. >> Having them separate will allow them to evolve independently. > > If PANA (and PANA<->PCP) are not there then this is a non-issue. Moreover, > If PANA is an integral part of PCP 'feature' then if PANA evolves, that > means PCP feature needs to be fully tested, regressed, etc. > >> >> Adding new features to a revision or extension of PANA is better than >> adding it to N different protocols which chose to embed equivalent of >> PANA. >> > > The final solution with a PCP specific method might look different than > PANA. > >> >> >>> Although one can argue that PCP and PANA will run together as one entity >>> the next step would be somebody asking for them to be decoupled and able >>> to run anywhere. This train is never late. >>> >> >> They are running separately. They are de-coupled as "protocols". What we >> are coupling is the "state" generated/used by PANA and PCP. >> This decoupling is a feature for "protocols", not a bug. Using state >> generated from one protocol in another is a "architecture design" or >> "implementation". > > You are missing the point here. The implementation complexity of your > proposal is considerable because you will have: > > - PANA > - PCP > - PANA <-> PCP protocol > > > But a case in point: I have experience with H.248Ia and Diameter-like to > do session control through NATs. Something similar to what we are trying > to achieve. Parallel to H.248 we had an authentication protocol. Dealing > with those two state machines was complex and can not be ignored. > > > >> >> Alper >> >> >> >> >> >>> >>> -----Original Message----- >>> From: Alper Yegin >>> Date: Fri, 14 Sep 2012 16:38:17 +0300 >>> To: Margaret Wasserman >>> Cc: >>> Subject: Re: [pcp] PANA implementatinos to consider >>> >>>> Hi Margaret, >>>> >>>> Your below questions are implementation specific. >>>> Let me answer them to describe how this can be implemented in one way. >>>> Certainly there are other ways to implement them. >>>> >>>>> >>>>> On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: >>>>>> As for the implementation complexity, I don't quite understand why >>>>>> PANA (which is basically EAP over UDP) would ever be more complicated >>>>>> then to-be-designed "EAP over UDP within PCP framework". While I >>>>>> don't >>>>>> see a reason for former being more complicated, I see reasons for >>>>>> seeing the latter being more complicated, as the whole thing now >>>>>> needs >>>>>> to live within another protocol framework (read: format, flow, state >>>>>> machine harmonization between the two). >>>>> >>>>> I don't understand how you get away from coupling PANA and PCP, even >>>>> in >>>>> the demultiplexing case where they run side-by-side on the same port. >>>>> I >>>>> think a number of details are being glossed over in your latest >>>>> document >>>>> when you refer to a need for an "API" between PANA and PCPÅ  >>>>> >>>> >>>> Association or binding of state between PANA and PCP is common on both. >>>> But there are different degrees of "coupling". Or where you couple >>>> them. >>>> Are we coupling the state generated/maintained between the two, or are >>>> we >>>> coupling the protocols themselves. >>>> >>>> You could say, a host configures a care-of address using DHCP, and uses >>>> that IP address with Mobile IP, hence DHCP and Mobile IP are coupled. >>>> Or, you could invent carrying DHCP over Mobile IP, and call that >>>> coupling >>>> too. >>>> >>>> Another more relevant example: Running IKE for IPsec, or running IKE >>>> over >>>> IPsec (however you do it). >>>> >>>> >>>>> Let's start with a simple case where the PCP Client wants to initiate >>>>> and authenticated PCP request... >>>>> >>>>> The Client needs to ask the PANA Client to initiate authentication. >>>>> How? >>>> >>>> PCP software triggers the PaC to perform authentication. >>>> Like how IKE gets triggered when IPsec SA needs to be setup. >>>> >>>> >>>>> Will that request include any details about the mapping request that >>>>> is >>>>> being made? i.e. will the PANA Client be asking for authentication >>>>> _and >>>>> authorization_ to perform a particular action? Or do we assume that a >>>>> PCP client is authenticated via PANA, and that authorization for a >>>>> particular action is a separate step that is performed as part of PCP? >>>>> If they are separate, do we need a new set of PCP error codes for the >>>>> situation where an authenticated PCP client performs an unauthorized >>>>> action, or is that already covered in the PCP spec? >>>> >>>> >>>> That trigger I mentioned above will include two pieces of information: >>>> 1. >>>> Indication that this is an auth/authz for PCP, 2. IP address of the PAA >>>> (which is same as the PCP server). >>>> >>>> >>>>> When the PCP Client asks the PANA Client to perform authentication, >>>>> what are the possible results that can be returned from that request, >>>>> and how are they communicated back to the PCP Client? You have only >>>>> described the success case in your document. >>>> >>>> PANA already generates success and failure results. This result will be >>>> conveyed to the PCP client via the API. >>>> If the result is success, also the PCP_AUTH_KEY and PANA Session ID and >>>> PANA Key ID need to be passed via that interface. >>>> >>>> >>>> >>>>> >>>>> How does this work in the case where the PCP Server is not running a >>>>> PANA Server? I _think_ that if a PCP Client asks its PANA Client to >>>>> perform authentication, and the PCP Server does support >>>>> authentication, >>>>> some sort of "unsupported version" error code will be returned to the >>>>> _PCP Client_ (due to the details of your proposed demultiplexing >>>>> scheme), and that nothing will be returned to the PANA Client, at all. >>>>> We would need to make sure that secure PCP clients are specified to >>>>> handle an "unsupported version" error differently when the PANA Client >>>>> is in this particular state, but how does the PCP Client know that >>>>> this >>>>> is why that error was returned? If this does happen, how does the PCP >>>>> client inform the PANA Client that it should stop trying to perform >>>>> authentication with that particular PCP Server? >>>>> >>>> >>>> I'd like to first understand how the client-side decides when to use >>>> authentication, and when not to? >>>> Can you, or someone, explain that? Once I understand the scenarios we >>>> are >>>> trying to cover, I can come back and answer your question. >>>> >>>> >>>>> Also, how does the PCP Client know when the _PCP Server_ is ready to >>>>> receive its request? Are we assuming that the PANA Server will not >>>>> return an indication to the PANA Client that the client has been >>>>> authenticated until _after_ it has provisioned the necessary SA on the >>>>> PANA Server? >>>>> >>>> >>>> The order of events is: >>>> >>>> 1. PANA is executed >>>> 2. PaC provides the results to the PCP client >>>> 3. PCP client contacts PCP server, using authentication tag generated >>>> with the SA from step 2. >>>> 4. Upon encountering new SA, PCP server contacts the PAA to obtain the >>>> matching parameters (or, the PAA had already pushed those params to PCP >>>> server after 1. These are different implementation choicesÅ ..) >>>> >>>> >>>> >>>>> What if an additional application on the same PCP Client system wants >>>>> to perform an authenticated request with the same PCP Server in the >>>>> meantime? Will that second request result in a second (interleaved) >>>>> PANA negotiation, or will the PCP Client be told that a PANA >>>>> negotiation >>>>> is already pending? If the latter, how will the second PCP Client >>>>> thread by informed when the PANA negotiation has completed? (Note: >>>>> The >>>>> right answer here depends heavily on whether the PANA authentication >>>>> depends, in any way, on the contents of a specific PCP request -- the >>>>> authentication vs. authentication/authorization question above). >>>>> >>>> >>>> Second API call can be told that there is already an ongoing >>>> authentication and wait for the result. >>>> Or, maybe it says "OK" but does not generate a second PANA session >>>> because the same PANA session (or, more specifically the security >>>> association generated by it) can be used with both PCP requests. >>>> >>>> >>>>> All of these questions will need to be answered, IMO, in a full >>>>> specification of the PCP/PANA demultiplexing mechanism, precisely >>>>> _because_ PCP and PANA are running separately. >>>> >>>> Errr, I don't think so. None of these are impacting the over-the-wire >>>> behavior (i.e., the "protocol"), but they are all about implementation >>>> -- >>>> not something we need to put in the protocol specs. >>>> >>>> >>>> If we were to use EAP over PCP, do you think we need to define how EAP >>>> methods interface with EAP which interfaces with PCP. How one triggers >>>> the other and gets the results back. I don't think so. >>>> >>>> >>>> >>>>> The "API" is where this coupling is provided between the two "state >>>>> machines", as you refer to them. Why is this any simpler if PANA and >>>>> PCP are running side-by side than if we run PANA encapsulated in PCP? >>>>> (or, if we run PCP directly over EAP, for that matter) >>>>> >>>> >>>> >>>> Please see the top part about my "coupling" response. >>>> >>>> If you run two protocols side by side, you point how one can trigger >>>> the >>>> other. And ideally, triggers target meaningful states. E.g., one >>>> protocol >>>> triggers other to run, and at the end of execution the result is >>>> returned >>>> (PCP triggers PANA to execute). >>>> If you run one protocol inside another, then you have to nest their >>>> state >>>> machines, and unless you are purely lucky, that cannot work >>>> automatically >>>> w/o aligning their state machines. (Like I said, PANA state machine is >>>> designed the way it is in accordance with the EAP state machine.) >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Margaret >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From zhangzhongjian@huawei.com Mon Sep 17 19:17:10 2012 Return-Path: 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 BC4B721F850C for ; Mon, 17 Sep 2012 19:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 lCFqjiMtK+Tu for ; Mon, 17 Sep 2012 19:17:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3439521F8504 for ; Mon, 17 Sep 2012 19:17:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKT51586; Tue, 18 Sep 2012 02:17:07 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 03:16:47 +0100 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 03:17:06 +0100 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Tue, 18 Sep 2012 10:14:54 +0800 From: "Zhangzongjian (Thomas)" To: Dan Wing Thread-Topic: [pcp] PCP mapping for 5350 and 5351 ports Thread-Index: AQHNklFQfx9YznzFZkayNVvmBYxVuZeKGsQggAP5YiCAALcOcIAAjJfA Date: Tue, 18 Sep 2012 02:14:54 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC7B32@szxeml524-mbs.china.huawei.com> References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5052D3F3.8000605@toshiba.co.jp> <52B4EAD8-7B6A-452D-8738-72C59E357519@yegin.org> <0B2F754289D27B449F7F1B95456B77544EDC74BF@szxeml524-mbs.china.huawei.com> <071d01cd92a0$21e179e0$65a46da0$@com> <0B2F754289D27B449F7F1B95456B77544EDC79B2@szxeml524-mbs.china.huawei.com> <03f201cd951c$653dbc20$2fb93460$@com> In-Reply-To: <03f201cd951c$653dbc20$2fb93460$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP mapping for 5350 and 5351 ports X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 02:17:10 -0000 Sorry.=20 Disagreed. Explanation refers to my last mail. The text to be replaced: > o The Suggested External Address, Protocol, and Port is already used > by the NAT gateway for one of its own services. For example, TCP > port 80 for the NAT gateway's own configuration web pages, or UDP > ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT=20 > ................................................^^^^^^^^^^^^^^^^^^^^^ > create client mappings for External UDP ports 5350 or 5351. > ......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The suggested text is : The Suggested External Address, Protocol, and Port is already used by the N= AT gateway for one of its own services. For example, TCP port 80 for the N= AT gateway's own configuration web pages, or UDP ports 5350 and 5351, used = by PCP itself. A PCP server MUST NOT create client mappings for External U= DP ports 5350 or 5351. If PCP server knows it's internal (from which interf= ace the PCP request is received and private network is behind this interfac= e) and external interfaces, and there only PCP server lies in NAT gateway, = PCP server can create mappings for External UDP ports 5350 or 5351 The UDP ports 5350 or 5351 may be used by PCP client, PCP proxy, UPnP-PCP i= nterworking, it is suggested that the UPD ports 5350 or 5351 MUST NOT be us= ed for creating mapping as the internal UDP port. =20 Regards Thomas > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, September 18, 2012 5:35 AM > To: Zhangzongjian (Thomas) > Subject: RE: [pcp] PCP mapping for 5350 and 5351 ports >=20 > I don't understand if you are agreeing with the text, or disagreeing with > the text. >=20 > Can you explain what change you want in the text? >=20 > -d >=20 >=20 > > -----Original Message----- > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > Sent: Monday, September 17, 2012 12:46 AM > > To: Dan Wing; pcp@ietf.org > > Subject: RE: [pcp] PCP mapping for 5350 and 5351 ports > > > > > o The Suggested External Address, Protocol, and Port is already > > used > > > by the NAT gateway for one of its own services. For example, > > TCP > > > port 80 for the NAT gateway's own configuration web pages, or > > UDP > > > ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT > > > ................................................^^^^^^^^^^^^^^^^^^^^^ > > > create client mappings for External UDP ports 5350 or 5351. > > > ......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^ > > > > > > > 1. Internal UPD ports 5350 or 5351 can't be used. > > (1) PCP client and NAT-PMP client use 5350 and 5351 for PCP or NAT- > > PMP protocol. They will not send a PCP/NAT-PMP mapping request use UDP > > 5350 or 5351 as internal port. Of cause PCP server can ignore this > > since no such a request. For security we must not permit use the UDP > > 5350 and 5351 as internal port in Mapping entry. The attacker behind > > CGN may send a PCP or NAT-PMP map request with 5350 or 5351 as internal > > port. If PCP server or NAT-PMP server create a mapping use the 5350 or > > 5351 as internal UDP port, mass Data packets from public network will > > be send PCP client or NAT-PMP client. > > (2) As for UPnP, UDP ports 5350 or 5351 may be used as the internal > > port in UPnP MAP request. UPnP-PCP interworking send the PCP request > > with internal UDP port 5350 or 5351 to PCP server and a mapping entry > > is created by PCP server. Data packet sent to UPnP client from remote > > will be forward to UPnP-PCP interworking function. The data packets > > will be discarded by UPnP-PCP interworking device. > > > > 2. we can specify the case that Port is already used by the NAT gateway > > for one of its own services. > > PCP server usually know which interface is internal (from which > > interface the PCP request is received and private network is behind > > this interface) or external, such as PCP server in CGN. That is to say > > (1) When only PCP server in NAT gateway, PCP server only listen on UDP > > port 5351 at internal interfaces. UDP 5350 or 5351 can be used as the > > external port. > > (2)When both PCP server and PCP client in NAT gateway, PCP server will > > listen on UDP port 5351 at internal interfaces and PCP client will > > listen on UDP port 5351 and 5350 at external interfaces. UDP 5350 or > > 5351 can't be used as the external port. > > (3)When PCP proxy or UPnP-PCP interworking in NAT gate way, UDP 5350 or > > 5351 can't be used as the external port. (This out scope of draft-PCP- > > base) > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Saturday, September 15, 2012 1:41 AM > > > To: Zhangzongjian (Thomas); pcp@ietf.org > > > Subject: RE: [pcp] PCP mapping for 5350 and 5351 ports > > > > > > > -----Original Message----- > > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf > > Of > > > > Zhangzongjian (Thomas) > > > > Sent: Friday, September 14, 2012 1:17 AM > > > > To: pcp@ietf.org > > > > Subject: [pcp] PCP mapping for 5350 and 5351 ports > > > > > > > > Dear all > > > > > > > > In charter 11.3 of draft draft-ietf-pcp-base-26, it said: > > > > > > > > The PCP server MUST NOT create mappings for the PCP ports > > themselves > > > > (5350 and 5351), and SHOULD have a policy control to deny > > mappings > > > > for other ports. In these cases, the error NOT_AUTHORIZED > > SHOULD > > > be > > > > returned. > > > > > > > > We need to clarify: > > > > 1. > > > > What kinds port that 5350 and 5351 ports must not be used for > > mapping? > > > > Internal ports , external ports or both? > > > > > > > > 2. > > > > What kinds protocol that the ports must not be used for mapping? > > UDP > > > > and others? > > > > > > > > 3. > > > > It also seems that different scenarios have different result. Such > > as, > > > > PCP server knows public interfaces and private interfaces in box, > > Only > > > > PCP server in a box or both PCP server and PCP client. > > > > > > During review, this confusion was pointed out. In -27, the above > > > is rewritten into a much more general and clear format, and reads > > > as follows. I highlighted the specific text regarding the PCP > > > ports numbers (5350, 5351), and the rest of the new text should > > > clarify your questions (2) and (3). If the new text is still > > > inadequate, please let me know. > > > > > > > > > If no mapping exists for the Internal Address, Protocol, and Port, > > > and the PCP server is able to create a mapping using the Suggested > > > External Address and Port, it SHOULD do so. This is beneficial > > for > > > re-establishing state lost in the PCP server (e.g., due to a > > reboot). > > > There are, however, cases where the PCP server is not able to > > create > > > a new mapping using the Suggested External Address and Port: > > > > > > o The Suggested External Address, Protocol, and Port is already > > > assigned to another existing explicit or implicit mapping > > (i.e., > > > is already forwarding traffic to some other internal address > > and > > > port). > > > > > > o The Suggested External Address, Protocol, and Port is already > > used > > > by the NAT gateway for one of its own services. For example, > > TCP > > > port 80 for the NAT gateway's own configuration web pages, or > > UDP > > > ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT > > > ................................................^^^^^^^^^^^^^^^^^^^^^ > > > create client mappings for External UDP ports 5350 or 5351. > > > ......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^ > > > > > > o The Suggested External Address, Protocol, and Port is otherwise > > > prohibited by the PCP server's policy. > > > > > > o The Suggested External Address, Protocol, or Port is invalid > > > (e.g., External Address 127.0.0.1, ::1, a multicast address, or > > > the port is not valid for the indicated protocol). > > > > > > o The Suggested External Address does not belong to the NAT > > gateway. > > > > > > o The Suggested External Address is not configured to be used as > > an > > > external address of the firewall or NAT gateway. > > > > > > If the PCP server cannot assign the Suggested External Address, > > > Protocol, and Port, then: > > > > > > o If the request contained the PREFER_FAILURE Option, then the > > PCP > > > server MUST return CANNOT_PROVIDE_EXTERNAL. > > > > > > o If the request did not contain the PREFER_FAILURE Option, and > > the > > > PCP server can assign some other External Address and Port for > > > that protocol, then the PCP server MUST do so and return the > > newly > > > assigned External Address and Port in the response. In no case > > is > > > the client penalized for a 'poor' choice of Suggested External > > > Address and Port. The Suggested External Address and Port may > > be > > > used by the server to guide its choice of what External Address > > > and Port to assign, but in no case do they cause the server to > > > fail to allocate an External Address and Port where otherwise > > it > > > would have succeeded. The presence of a non-zero Suggested > > > External Address or Port is merely a hint; it never does any > > harm. > > > > > > > > > -d > > > > > > > > > > > > > > > > > > Regards > > > > Thomas > > > > > > > > > > > > _______________________________________________ > > > > pcp mailing list > > > > pcp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/pcp From yatch@isl.rdc.toshiba.co.jp Mon Sep 17 22:38:48 2012 Return-Path: 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 255E221E80B0 for ; Mon, 17 Sep 2012 22:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 sw0a1corb25J for ; Mon, 17 Sep 2012 22:38:47 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4576021E804A for ; Mon, 17 Sep 2012 22:38:46 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q8I5cjpt005355 for ; Tue, 18 Sep 2012 14:38:45 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q8I5cjBY006515 for pcp@ietf.org; Tue, 18 Sep 2012 14:38:45 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id QAA06502; Tue, 18 Sep 2012 14:38:45 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q8I5ciuC011426 for ; Tue, 18 Sep 2012 14:38:44 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q8I5ciqi005144; Tue, 18 Sep 2012 14:38:44 +0900 (JST) Received: from [133.196.16.99] (ncg-dhcp99.isl.rdc.toshiba.co.jp [133.196.16.99]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 5F85497CCA; Tue, 18 Sep 2012 14:38:44 +0900 (JST) Message-ID: <505808E4.60609@isl.rdc.toshiba.co.jp> Date: Tue, 18 Sep 2012 14:38:44 +0900 From: Yasuyuki Tanaka User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: hartmans@painless-security.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 05:38:48 -0000 Hi, I'm an implementor of CPANA. I have two additions to your analysis. Firstly, you can add RADIUS support to CPANA by using FreeBSD's libradius. For this purpose, we provide the option, "--with-libradius", for the "configure" script of CPANA. Secondly, you can also adapt third-party EAP implementations to CPANA, though I've never tried. Hope this helps. Best regards, Yasuyuki Tanaka > CPANA > > See http://sf.net/projects/cpana > > At first glance, CPANA looks promising. It's designed as a library for > others to integrate PANA into their environments. > CPANA is distributed under the BSD license. > > Unfortunately, I quickly decided that CPANA was not a credible start > point in my opinion. The project has received 11 code commits over its > entire lifetime; I think 1 or 2 commits this year. > Despite claims that "docs are coming soon," in 2010, I was able to find > no documentation. There doesn't seem to be good separation of what is a > public interface from what is an internal interface; cpana.h includes > all the internal header files. > The example applications don't separate example-specific functionality > like reading config files well from using the library, so I wasn't able > to get a feel for what it would be like to use the library in a > non-sample application. > On a positive note, there did seem to be an abstraction around where > responses went; it might be easier-than-expected to use CPANA in an > encapsulation or demultiplexing approach. > There's one additional huge problem with CPANA. It includes its own > rather limited EAP library which does not appear to support any of the > tunnel methods. On the server there appears to be no RADIUS support. > If I were writing a PANA library I planned to maintain for years, I'd > seriously evaluate taking chunks of code from CPANA. > If CPANA gets significant new development effort it may turn into > something interesting. I like the goal of separating library from application. From mohamed.boucadair@orange.com Mon Sep 17 23:34:12 2012 Return-Path: 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 4932821E80B9 for ; Mon, 17 Sep 2012 23:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 tVrYntiGy6Om for ; Mon, 17 Sep 2012 23:34:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5929521F8518 for ; Mon, 17 Sep 2012 23:34:11 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8990822C4D7 for ; Tue, 18 Sep 2012 08:34:10 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6704D2380E9 for ; Tue, 18 Sep 2012 08:34:10 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 18 Sep 2012 08:34:10 +0200 From: To: "pcp@ietf.org" Date: Tue, 18 Sep 2012 08:34:08 +0200 Thread-Topic: DESCRIPTION Option Thread-Index: Ac2Ux1m008btMKN5TYGgLLdL5dq1ewAoBkhw Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A40CD5B@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40CB0E@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5A40CB0E@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E5A40CD5BPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.18.55414 Subject: Re: [pcp] DESCRIPTION Option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 06:34:12 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5A40CD5BPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I updated the text to include some of the comments I received off line. The new version is available at: http://tools.ietf.org/html/draft-boucadair= -pcp-description-option-01 FWIW, a diff is also available here: http://www.ietf.org/rfcdiff?url2=3Ddra= ft-boucadair-pcp-description-option-01 Cheers, Med ________________________________ De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de moham= ed.boucadair@orange.com Envoy=E9 : lundi 17 septembre 2012 13:27 =C0 : pcp@ietf.org Objet : [pcp] DESCRIPTION Option Dear all, In the Paris meeting (http://www.ietf.org/proceedings/83/minutes/minutes-83= -pcp.txt), there was a suggestion to start discussion on the options define= d in draft-boucadair-pcp-extensions. I will start the discussion with two o= ptions from that draft: DESCRIPTION and CAPABILITY Options. I will send a s= eparate e-mail for the CAPABILITY Option. This message is to initiate discussion on DESCRIPTION Option: http://tools.ietf.org/html/draft-boucadair-pcp-description-option-00 The document indicates the code used for this option by implementations I'm= aware of. Comments on the DESCRIPTION option are more than welcome. If you think the working group should spent or no effort on this specificat= ion, this is also a useful comment. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E5A40CD5BPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Re-,
 
I updated the text to include some of the commen= ts I=20 received off line.
 
The new version is available at: http://tools.ietf.org/html/draft-boucadair-pcp-description-option= -01
 
FWIW, a diff is also available here: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-descripti= on-option-01
 
Cheers,
Med

De : pcp-bounces@ietf.org=20 [mailto:pcp-bounces@ietf.org] De la part de=20 mohamed.boucadair@orange.com
Envoy=E9 : lundi 17 septembre= 2012=20 13:27
=C0 : pcp@ietf.org
Objet : [pcp] DESC= RIPTION=20 Option

Dear=20 all,
 
In the=20 Paris meeting (ht= tp://www.ietf.org/proceedings/83/minutes/minutes-83-pcp.txt),=20 there was a suggestion to start discussion on the options defined in=20 draft-boucadair-pcp-extensions. I will start the discussion with two opti= ons=20 from that draft: DESCRIPTION and CAPABILITY Options. I will send a separa= te=20 e-mail for the CAPABILITY Option.
 
This=20 message is to initiate discussion on DESCRIPTION Option:
 
 http://tools.ietf.org/html/draft-boucadair-pcp-description-opti= on-00
 
The=20 document indicates the code used for this option by implementations I'm a= ware=20 of.
 
Comments=20 on the DESCRIPTION option are more than welcome.
 
If you=20 think the working group should spent or no effort on this specificat= ion,=20 this is also a useful comment.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F36E5A40CD5BPUEXCB1Bnante_-- From alper.yegin@yegin.org Mon Sep 17 23:58:25 2012 Return-Path: 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 8159A11E808D for ; Mon, 17 Sep 2012 23:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 4MdePyNV1ZKs for ; Mon, 17 Sep 2012 23:58:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDDE11E808A for ; Mon, 17 Sep 2012 23:58:24 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MNaHi-1T7mxH1hEI-007OMk; Tue, 18 Sep 2012 02:58:21 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Tue, 18 Sep 2012 09:58:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:4PWTrNMsteEY81or0VYKA5y18UKl5Kuj+yIjLh7tiuw nHRd2qemln2Nj8KTRpCtzdF+6DxtWN+W6cjgdyr8AqVyGs/0bN Wh4gdDwOSo5QQzWVUJm93wOsCD50hS/9+pi7FS6TMuINyW2oPO s7GDEagcLyCVw1hIACXqX+tczmUOggBYQVoQPJ80aMDApFPXgB XIF/Dnp9r/mlpNRoNl+3495gpcemHQo0TE2RZ+8HaG0DD2u8j1 b/2dqMlks1mv+SfFQTgWmW1qKZkj3UM+tcOhjv7t5qPPrMw5Dc 9I2scsQxJP+aahk9Rrj6BjR3DnLUSVcNfvU9FJUE6tzOyZ9sgB quKT1tBPh90ZeieHM4cpuEAoLLQIEyIOAEZhtgy6BSkQ2cszqX yQi+/gquZ/X/Q== Cc: "'pcp@ietf.org'" Subject: Re: [pcp] [ Side-by-side or nested protocols X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 06:58:25 -0000 > Alper> This is so un-IETF to me. Here we have two distinct pieces = of > Alper> work (PCP and key management), that can be satisfied using > Alper> two protocols, we are talking about cobbling them together. > Alper> Like that was done in the PPP-era, and like it's done in GTP > Alper> (of 3GPP). Lot of pain with both... I'd understand how = other > Alper> SDOs would think that way, but their priorities are > Alper> different. But for IETF, we design protocols, and cobbling = up > Alper> protocols unnecessarily gets in the way of modularity, which > Alper> is very essential to IETF. Right? >=20 > Hi. > I haven't been working in the internet area that long, but I have been > working in the security area of the IETF and following the apps area's > security for a while. > I think I have some experience with what's ietf and un-ietf in those > contexts. >=20 > There are two related questions here: >=20 > 1) To what extent should security frameworks be re-used. >=20 > 2) Whether key management should run in-band with the managed = protocol. >=20 > Both of these issues have been hotly discussed. There was actually an > IAB document--I think draft-iab-authmech or similar--that tried to = rule > out any stacking of frameworks. For example you could not use GSS-API > within SASL or EAP within PANA in a context where both were = appropriate. That's an odd thing. EAP needs a lower-layer to get transported, as = defined in RFC 3748. It's not going to fly on its own. > This generated rather a lot of comment, and it doesn't look like that > document was ever published as an RFC in part because the IAB was = having > trouble getting consensus around the strong negative statements = against > frameworks. >=20 What's a "framework"?=20 > While I think that document went too far, the general concerns about > protocol layering it raised are real. Additional protocol layers does > add all the forms of complexity that Wim discusses. =20 I'm confused. It is the EAP-over-PCP that's creating the additional = layering, not PANA. It's carrying equivalent of PANA over PCP (layering!) vs using PANA and = PCP side-by-side. > If you get re-use > of code or re-use of platform infrastructure then it can be worth that > additional complexity. If you get re-use of security analysis then it > can be worth the complexity. >=20 Again, I'm confused. With PANA, you get re-use of spec, implementation, = security analysis.=20 Which one of these do you get with yet-to-be specified EAP-over-PCP? > The question of in-band vs out-of-band has also been a hot question in > the security area. The most recent huge instance of that discussion = I'm > aware of was the KARP working group. > Many security participants were arguing that tight integration of key > management into routing protocols would ease security analysis and = make > it much more likely that we got things right. > In that instance, the implementor community for the routing protocols > said that tight integration (in-bind) was an unacceptable = implementation > strategy for reasons specific to the routing protocols. >=20 I'm not surprised at all. Embedding a protocol inside another is never a = drag-and-drop activity. > Really, there are a lot of factors to consider; let me give you a few > examples. >=20 > Many applications have decided that authentication needs to be tightly > integrated but that confidentiality and integrity should be re-used = from > TLS at arms length. These include IMAP, SMTP, LDAP, POP, XMPP and > HTTP. Several of these have a seldom-used but sometimes important > facility to more tightly integrate confidentiality and integrity. All > protocols are run in-band with encapsulation. >=20 To have more clarity, we need to use more specific terms, such as = end-point authentication, data origin authentication (integrity+replay = protection), data confidentiality.=20 With the mention of TLS, let me note that there are three distinct = approaches: 1. Transport layer security (e.g., TLS) TLS encapsulates the subject protocol End-point auth, data origin auth, data confidentiality provided by TLS 2. Separate key management (e.g., IKE, EAP transports) End-point authentication provided by the key management protocol Data origin auth, data confidentiality provided by subject protocol = using the keys from the key management protocol. 3. All-in-one (e.g., PPP, EAP-over-PCP) End-point auth, data origin auth, data confidentiality provided by the = subject protocol.=20 >=20 > Ssh designed ssh-specific protocols for everything and runs everything > in-band. >=20 > IPsec uses an out-of-band separate key-management protocol. >=20 > Network access uses EAP often as a out-of-band key management protocol > with a separate security association protocol. >=20 >>> Having a separate protocol would mean significant more test and >>> effort for productization due to interactions, new CLIs, >>> unforeseen state machine issues, etc. >=20 > Alper> Just the opposite. Inventing new EAP-over-UDP as part of = PCP > Alper> is a brand-new design with brand-new code. PANA is a = standard > Alper> with multiple interoperating implementations. It's = obviously > Alper> more stable then the to-be-designed EAP-over-UDP/PCP. >=20 > I actually agree with Wim. > I've seen a lot of complexity gluing protocols together. > Even given that I do tend to be a fan of security frameworks, but I = have > to admit that there are huge costs. > If there is not a strong value proposition in terms of new = capabilities > users get, it may not be worth it. >=20 > Alper> State machines is one of the issues with cobbling up > Alper> protocols. Two separate protocols, living side by side, the > Alper> state machines have nothing to conflict. >=20 > Alper> If you put on inside the other, then problems arise. >=20 > Actually, state machine alignment simply gets messy. > As you point out you need to deal with the fact that the direction is > different for PCP and EAP. >=20 > However, in the demultiplexing case, we also have state machine = issues. > On the client, the state machine now needs to wait while = authentication > is happening. > That is we're introducing a waiting-for-PANA state into the PCP = client. >=20 Is this an "issue"? > Also, I've seen complex interactions between protocol state machines = in > distributed systems. The first time I ran into state machine issues = was > a distributed filesystem protocol called AFS. There were two very > modular protocols, one for metadata access and one for accessing = files. > Unfortunately, they could interact with each other and delays in the > metadata protocol could cause ever-increasing delays in the file = service > protocol. >=20 > That was far more painful to debug than a single integrated protocol > would have been. >=20 > Alper> And I have yet to hear someone saying yes EAP-over-PCP > Alper> satisfies the EAP lower layer requirements. I had raised = this > Alper> issue 3 times, and don't see anyone doing the work. It's not > Alper> as simple as defining a container to ship EAP payloads back > Alper> and forth. >=20 >=20 > We've made a specific proposal that we believe satisfies the > requirements of an EAP lower layer. We'd certainly appreciate your > technical comments on that proposal. If we missed something please = let > us know. I'll spin off a separate thread for this one. Alper From alper.yegin@yegin.org Tue Sep 18 00:30:33 2012 Return-Path: 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 9AD4C21F8589 for ; Tue, 18 Sep 2012 00:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, J_BACKHAIR_43=1, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] 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 ifqofowv8R4Z for ; Tue, 18 Sep 2012 00:30:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F621F85EA for ; Tue, 18 Sep 2012 00:30:31 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MbOgO-1SxRs21DXQ-00JVV4; Tue, 18 Sep 2012 03:30:28 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-2 From: Alper Yegin In-Reply-To: Date: Tue, 18 Sep 2012 10:30:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6A210C2E-B490-47A2-B956-585EA078D22F@yegin.org> References: To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:Ip9rJ0DHPK/WH4fLpzNIkB4xSf1ydtTumMtuTAY1sjh TyKNgFntxHP3IWaTVDc8qyHjkkbrfkWqk7dsbz8Z+EGBd0jBLV GGfZ9mJY4jmXen3F+pmx1nqxQQiUejnBuV/DdzxXd/59RZVwfm m8jKGrXtkED3I+nVOxBPBSvahLs3xlD7CERxK5DWogii8NQbs/ nzEfFp/eBkhSH731z4LWYom5lFSyYLXIYSu4XDth2BarYJEeKP JCfyG78xmoxhhvDjfpjtCji/RSMsshUfmhK4T5DqacWPEkbT1A D1LqkBQUq6H2WcdZ/21iVrzPLUtvrxa4+IZnoChWmb7xLGqrqx TeCUPZJVM5MEQQp3P8b9ZSFDQjvRXzWYYEQdIJwTxU3N0xoua/ CAHfG0vC3PgEA== Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 07:30:33 -0000 Hi Reinaldo, >>=20 >>> +1 all I have seen so far is very complex for simple authentication = of >>> pcp. Let's embed it into pcp. >>>=20 >>=20 >> It does not get simplified because you put one inside the other. In = fact, >> it gets more complicated. Please see below. >>=20 >>>=20 >>> I've been following this discussion and my preference would be to = avoid >>> having a design that requires a 'control protocol' between PCP and >>> something else. We should reuse other IETF standards whenever = possible >>> but >>> I would prefer everything to be part of a single protocol. >>=20 >> This is so un-IETF to me. Here we have two distinct pieces of work = (PCP >> and key management), that can be satisfied using two protocols, we = are >> talking about cobbling them together. >> Like that was done in the PPP-era, and like it's done in GTP (of = 3GPP). >> Lot of pain with both... >> I'd understand how other SDOs would think that way, but their = priorities >> are different. But for IETF, we design protocols, and cobbling up >> protocols unnecessarily gets in the way of modularity, which is very >> essential to IETF. Right? >>=20 >> More on this below... >>=20 >>=20 >>> Having a >>> separate protocol would mean significant more test and effort for >>> productization due to interactions, new CLIs, unforeseen state = machine >>> issues, etc.=20 >>=20 >> Just the opposite. >> Inventing new EAP-over-UDP as part of PCP is a brand-new design with >> brand-new code. PANA is a standard with multiple interoperating >> implementations.=20 >> It's obviously more stable then the to-be-designed EAP-over-UDP/PCP. >=20 > I posit that the effort to productize PANA or a yet to be defined > EAP-over-UDP (or something else) is almost the same. Unless the vendor > that is implementing > PCP Server has PANA in production but I'm not aware of any. >=20 So, if I the vendor do not have the protocol implemented in front of me, = it makes sense to go back to square one and design my own wheel, get it = through IETF standardization (spend lot of engineering cycles), get it = interop'ed, get it open-source implemented. Does this make sense? But more interestingly, you said you are not aware of any PANA = implementations in production. As we said before, PANA is adopted into Zigbee Smart Energy Profile 2.0 And it passed several interop events, with 10 implementations. Are you sure you don't have it in Cisco platforms? >=20 >>=20 >>=20 >> State machines is one of the issues with cobbling up protocols. Two >> separate protocols, living side by side, the state machines have = nothing >> to conflict. >=20 >=20 > Conflict is not the right word. You are low balling this issue. = Synching > two state machines that depend on each other can be tricky. >=20 Yes, it could be tricky, if we had a funky relationship between the two = protocols. But in this case, it's a clean separation. PCP needs keys to = run, it triggers PANA to generate the keys, PANA does its job and gives = back the keys, PCP runs with the keys. This is how separate "key = management" works. Natural fit. But, if we embed one protocol inside the other, then you have to combine = the state machines. And that combining is not a simple jump back and = forth like in the above case. More specifically, within the PCP state = machine, now you have to account for server-side retransmissions, = server-side asynchronous requests, etc. >=20 >>=20 >> If you put on inside the other, then problems arise. >=20 >>=20 >> Specifically in this case: The direction of PCP flow and EAP flow are >> just the opposite. PCP is host-side driven req/rsp. EAP is = network-side >> driven req/rsp. So, now PCP state machine has to change to support = that >> too. And, EAP can generate asynchronous requests at any time from the >> network side (re-authentication). Exact same issue that we had with = the >> EAP-over-DHCP (in fact this whole discussion has the same = pattern....) >=20 >=20 > PCP is capable of sending unsolicited messages (both multicast and > unicast). So, we are good here. You are referring to "announcements" right? They are one-way notifications. What you need is a server-initiated, multi-round-trip req/rsp exchanges = -- to have a working EAP lower-layer. >=20 >>=20 >> And I have yet to hear someone saying yes EAP-over-PCP satisfies the = EAP >> lower layer requirements. I had raised this issue 3 times, and don't = see >> anyone doing the work. It's not as simple as defining a container to = ship >> EAP payloads back and forth. >>=20 >>=20 >>>=20 >>> We will certainly even face all kinds of backward/forward = compatibility >>> issues between PCP, PANA (as an example) and whatever control = protocol >>> will run between them due to different features and evolution = timeline. >>>=20 >>=20 >> Again, situation is the opposite. >> Having them separate will allow them to evolve independently. >=20 > If PANA (and PANA<->PCP) are not there then this is a non-issue. = Moreover, > If PANA is an integral part of PCP 'feature' then if PANA evolves, = that > means PCP feature needs to be fully tested, regressed, etc. When an enhancement is identified to the "end-point authentication and = key management" aspect, then PANA gets revised/extended. PANA revision/extension gets tested, you be done with it.=20 If you go with EAP-over-PCP approach, then you gotta test both the = EAP-over-PCP and the whole PCP as well. Since they are well-integrated = (not isolated like above), you have to make sure you didn't mess up PCP. = (Depending on the type of change, we probably also need to = revise/extend/test PANA for its other use as well.) OK, this is simple modular design, protocol re-use, and their benefits. >=20 >>=20 >> Adding new features to a revision or extension of PANA is better than >> adding it to N different protocols which chose to embed equivalent of >> PANA. >>=20 >=20 > The final solution with a PCP specific method might look different = than > PANA. >=20 How much? It's going to carry EAP, it's going to carry it over UDP, it's = going to be a EAP lower-layer. Where's the delta? >>=20 >>=20 >>> Although one can argue that PCP and PANA will run together as one = entity >>> the next step would be somebody asking for them to be decoupled and = able >>> to run anywhere. This train is never late. >>>=20 >>=20 >> They are running separately. They are de-coupled as "protocols". What = we >> are coupling is the "state" generated/used by PANA and PCP. >> This decoupling is a feature for "protocols", not a bug. Using state >> generated from one protocol in another is a "architecture design" or >> "implementation". >=20 > You are missing the point here. The implementation complexity of your > proposal is considerable because you will have: >=20 > - PANA=20 > - PCP > - PANA <-> PCP protocol >=20 The interaction between the PANA and PCP is not governed by a protocol, = but an API. They are on the same stack. With PANA, you need to deal with how two protocols implemented on the = same stack interacts. With EAP-over-PCP, you need to deal with how two separate parts of the = same protocol interact with each other. How you implement these depend on your implementation environment. I personally don't see an issue here that'd justify the re-invention of = the wheel for IETF and causing complexity for PCP design and = implementation. >=20 > But a case in point: I have experience with H.248Ia and Diameter-like = to > do session control through NATs. Something similar to what we are = trying > to achieve. Parallel to H.248 we had an authentication protocol. = Dealing > with those two state machines was complex and can not be ignored. >=20 Cheers, Alper >=20 >=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> -----Original Message----- >>> From: Alper Yegin >>> Date: Fri, 14 Sep 2012 16:38:17 +0300 >>> To: Margaret Wasserman >>> Cc: >>> Subject: Re: [pcp] PANA implementatinos to consider >>>=20 >>>> Hi Margaret, >>>>=20 >>>> Your below questions are implementation specific. >>>> Let me answer them to describe how this can be implemented in one = way. >>>> Certainly there are other ways to implement them. >>>>=20 >>>>>=20 >>>>> On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote: >>>>>> As for the implementation complexity, I don't quite understand = why >>>>>> PANA (which is basically EAP over UDP) would ever be more = complicated >>>>>> then to-be-designed "EAP over UDP within PCP framework". While I >>>>>> don't >>>>>> see a reason for former being more complicated, I see reasons for >>>>>> seeing the latter being more complicated, as the whole thing now >>>>>> needs >>>>>> to live within another protocol framework (read: format, flow, = state >>>>>> machine harmonization between the two). >>>>>=20 >>>>> I don't understand how you get away from coupling PANA and PCP, = even >>>>> in >>>>> the demultiplexing case where they run side-by-side on the same = port. >>>>> I >>>>> think a number of details are being glossed over in your latest >>>>> document >>>>> when you refer to a need for an "API" between PANA and PCP=A9 >>>>>=20 >>>>=20 >>>> Association or binding of state between PANA and PCP is common on = both. >>>> But there are different degrees of "coupling". Or where you couple >>>> them. >>>> Are we coupling the state generated/maintained between the two, or = are >>>> we >>>> coupling the protocols themselves. >>>>=20 >>>> You could say, a host configures a care-of address using DHCP, and = uses >>>> that IP address with Mobile IP, hence DHCP and Mobile IP are = coupled. >>>> Or, you could invent carrying DHCP over Mobile IP, and call that >>>> coupling >>>> too. >>>>=20 >>>> Another more relevant example: Running IKE for IPsec, or running = IKE >>>> over >>>> IPsec (however you do it). >>>>=20 >>>>=20 >>>>> Let's start with a simple case where the PCP Client wants to = initiate >>>>> and authenticated PCP request... >>>>>=20 >>>>> The Client needs to ask the PANA Client to initiate = authentication. >>>>> How? =20 >>>>=20 >>>> PCP software triggers the PaC to perform authentication. >>>> Like how IKE gets triggered when IPsec SA needs to be setup. >>>>=20 >>>>=20 >>>>> Will that request include any details about the mapping request = that >>>>> is >>>>> being made? i.e. will the PANA Client be asking for = authentication >>>>> _and >>>>> authorization_ to perform a particular action? Or do we assume = that a >>>>> PCP client is authenticated via PANA, and that authorization for a >>>>> particular action is a separate step that is performed as part of = PCP? >>>>> If they are separate, do we need a new set of PCP error codes for = the >>>>> situation where an authenticated PCP client performs an = unauthorized >>>>> action, or is that already covered in the PCP spec? >>>>=20 >>>>=20 >>>> That trigger I mentioned above will include two pieces of = information: >>>> 1. >>>> Indication that this is an auth/authz for PCP, 2. IP address of the = PAA >>>> (which is same as the PCP server). >>>>=20 >>>>=20 >>>>> When the PCP Client asks the PANA Client to perform = authentication, >>>>> what are the possible results that can be returned from that = request, >>>>> and how are they communicated back to the PCP Client? You have = only >>>>> described the success case in your document. >>>>=20 >>>> PANA already generates success and failure results. This result = will be >>>> conveyed to the PCP client via the API. >>>> If the result is success, also the PCP_AUTH_KEY and PANA Session ID = and >>>> PANA Key ID need to be passed via that interface. >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> How does this work in the case where the PCP Server is not running = a >>>>> PANA Server? I _think_ that if a PCP Client asks its PANA Client = to >>>>> perform authentication, and the PCP Server does support >>>>> authentication, >>>>> some sort of "unsupported version" error code will be returned to = the >>>>> _PCP Client_ (due to the details of your proposed demultiplexing >>>>> scheme), and that nothing will be returned to the PANA Client, at = all. >>>>> We would need to make sure that secure PCP clients are specified = to >>>>> handle an "unsupported version" error differently when the PANA = Client >>>>> is in this particular state, but how does the PCP Client know that >>>>> this >>>>> is why that error was returned? If this does happen, how does the = PCP >>>>> client inform the PANA Client that it should stop trying to = perform >>>>> authentication with that particular PCP Server? >>>>>=20 >>>>=20 >>>> I'd like to first understand how the client-side decides when to = use >>>> authentication, and when not to? >>>> Can you, or someone, explain that? Once I understand the scenarios = we >>>> are >>>> trying to cover, I can come back and answer your question. >>>>=20 >>>>=20 >>>>> Also, how does the PCP Client know when the _PCP Server_ is ready = to >>>>> receive its request? Are we assuming that the PANA Server will = not >>>>> return an indication to the PANA Client that the client has been >>>>> authenticated until _after_ it has provisioned the necessary SA on = the >>>>> PANA Server? =20 >>>>>=20 >>>>=20 >>>> The order of events is: >>>>=20 >>>> 1. PANA is executed >>>> 2. PaC provides the results to the PCP client >>>> 3. PCP client contacts PCP server, using authentication tag = generated >>>> with the SA from step 2. >>>> 4. Upon encountering new SA, PCP server contacts the PAA to obtain = the >>>> matching parameters (or, the PAA had already pushed those params to = PCP >>>> server after 1. These are different implementation choices=A9..) >>>>=20 >>>>=20 >>>>=20 >>>>> What if an additional application on the same PCP Client system = wants >>>>> to perform an authenticated request with the same PCP Server in = the >>>>> meantime? Will that second request result in a second = (interleaved) >>>>> PANA negotiation, or will the PCP Client be told that a PANA >>>>> negotiation >>>>> is already pending? If the latter, how will the second PCP Client >>>>> thread by informed when the PANA negotiation has completed? = (Note: >>>>> The >>>>> right answer here depends heavily on whether the PANA = authentication >>>>> depends, in any way, on the contents of a specific PCP request -- = the >>>>> authentication vs. authentication/authorization question above). >>>>>=20 >>>>=20 >>>> Second API call can be told that there is already an ongoing >>>> authentication and wait for the result. >>>> Or, maybe it says "OK" but does not generate a second PANA session >>>> because the same PANA session (or, more specifically the security >>>> association generated by it) can be used with both PCP requests. >>>>=20 >>>>=20 >>>>> All of these questions will need to be answered, IMO, in a full >>>>> specification of the PCP/PANA demultiplexing mechanism, precisely >>>>> _because_ PCP and PANA are running separately. >>>>=20 >>>> Errr, I don't think so. None of these are impacting the = over-the-wire >>>> behavior (i.e., the "protocol"), but they are all about = implementation >>>> -- >>>> not something we need to put in the protocol specs. >>>>=20 >>>>=20 >>>> If we were to use EAP over PCP, do you think we need to define how = EAP >>>> methods interface with EAP which interfaces with PCP. How one = triggers >>>> the other and gets the results back. I don't think so. >>>>=20 >>>>=20 >>>>=20 >>>>> The "API" is where this coupling is provided between the two = "state >>>>> machines", as you refer to them. Why is this any simpler if PANA = and >>>>> PCP are running side-by side than if we run PANA encapsulated in = PCP? >>>>> (or, if we run PCP directly over EAP, for that matter) >>>>>=20 >>>>=20 >>>>=20 >>>> Please see the top part about my "coupling" response. >>>>=20 >>>> If you run two protocols side by side, you point how one can = trigger >>>> the >>>> other. And ideally, triggers target meaningful states. E.g., one >>>> protocol >>>> triggers other to run, and at the end of execution the result is >>>> returned >>>> (PCP triggers PANA to execute). >>>> If you run one protocol inside another, then you have to nest their >>>> state >>>> machines, and unless you are purely lucky, that cannot work >>>> automatically >>>> w/o aligning their state machines. (Like I said, PANA state machine = is >>>> designed the way it is in accordance with the EAP state machine.) >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Margaret >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >=20 From alper.yegin@yegin.org Tue Sep 18 00:41:48 2012 Return-Path: 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 56CBD21F8658 for ; Tue, 18 Sep 2012 00:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] 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 CgZqXTX2HeEo for ; Tue, 18 Sep 2012 00:41:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B28D321F8644 for ; Tue, 18 Sep 2012 00:41:47 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lp4oe-1TjvOc2HYa-00euYh; Tue, 18 Sep 2012 03:41:45 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Tue, 18 Sep 2012 10:41:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <162F9DEB-572F-46D9-A34E-7C8576916F5F@yegin.org> References: <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:f1fcDw9Hw5vuyKmKrE0YqAu93oZMhP8stXyYqiG9zu3 +UWWUZghNX0Dem6qNGsIyEJhoEmz2fRYfzzqb2xTXD3BUPJq9d 3oVU8q4BYZtSUt5vBpTdwtBoy0Pl1ooO6crTUS10zuElZLV5Hd tIdRSzjFHXSQwkIfSiNxLiSA/e8DagM4hzyoEFJkRqFI/BcBxW SNHdcKGP19zm9ZAsgWiZO4z+KK24FojBKcZBQDYAyUnfmCzL+v uRrDIMpQNrJbMacaqH/UsjLZYJ97QR0Symnylz9GdhXTHyWTER BoW15Eo2xva1VT82KgLVQ4K7itq0tRwvfpsgQBozJyggP2+qqp kysrYQbJdB3wnxCCCdpYBEd348P9gp4Sp0mIr/Xe3TaxPwgq6x 0C2HhLN6CWIQw== Cc: pcp@ietf.org Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 07:41:48 -0000 On Sep 17, 2012, at 6:06 PM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >>> Parts of the demultiplexing approach look simpler. You could run >>> a PAA and PAC as separate processes. If the PCP server received >>> an authentication request it could forward it to the PAA over a >>> local socket. You'd need to make a slight change so that the >>> return address could be preserved. In this mode, the PCP server >>> would not need to change its state machine to wait for >>> authentication. Except then it gets complicated, because you >>> need coordination between PCP and the PAC/PAA. You need to >>> design an implementation-specific protocol to: >>>=20 >>> * Trigger authentications on the PAC when PCP wants to talk to a >>> server >>>=20 >=20 >> Yes, we'd need to add a new trigger (PCP trigger). >=20 >=20 >>> * update the PCP client on authentication state including session >>> ID,key ID, and negotiated algorithms >>>=20 >>> * Provide error feedback from the PAC to PCP server so the user >>> gets a consistent error reporting experience >>>=20 >=20 >> We do not send error codes in PANA. Not sure which error reporting = you are referring to. >=20 > Margaret has gone into this detail somewhat. > The issue is that you want a consistent experience for the client. > So, you need to do things like map PANA failures because the server > doesn't support PANA into authentication not supported PCP errors. > You need to log PANA and PCP errors in the same place. > You need to provide consistent tools for looking at them. > These are implementation not protocol issues. >=20 Right, these are implementation considerations. Logging with the proper info, whether it's coming from PCP or PANA is = what we need. So that tools can parse them properly. >=20 >=20 >>> * Update the PCP server on new authentication sessions at the PAA >>> including IDs, keys and algorithm identifiers >>>=20 >>> If you do all that work you're going to end up with a fork of >>> OpenPANA, not just get a library you can use and potentially >>> refresh for new products/product releases. Security analysis >>> will be different especially for things like denial of service. >=20 > Alper> Can you expand on this "DoS"? >=20 >=20 > Sure. > So, even in the demultiplexing case, we're coupling the state machines > together. > As an example we're creating a new PCP client state that is basically > waiting for PANA. > We need to do the security analysis for that. >=20 That state is "retrieve security parameters" for PCP. Those parameters could be: - retrieved from a configuration file (static) - retrieved from dynamic store (from last unexpired authentication) - if both are empty, then PANA is triggered to generate fresh parameters Given that PANA is already analyzed, not sure what other threats might = be in here. (on the other hand, if you want to re-invent PANA within PCP from = scratch, you've got lot of security analysis to make. That's a lot of = work.) > One of the simpler issues is a question like can an malicious server > cause a PCP client to block indefinitely by swapping back and forth > between PCP and PANA. >=20 Not sure if I understand the scenario=85 Can you elaborate? Alper > --Sam From alper.yegin@yegin.org Tue Sep 18 01:41:13 2012 Return-Path: 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 4D47021F8752 for ; Tue, 18 Sep 2012 01:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 GW6nzoeU4nVQ for ; Tue, 18 Sep 2012 01:41:12 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id B608321F877E for ; Tue, 18 Sep 2012 01:41:12 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lgq1W-1TtE7m1yz8-00nVrR; Tue, 18 Sep 2012 04:41:11 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA335E8F-D5B1-4F4C-A6F8-220153EAE97B" From: Alper Yegin In-Reply-To: Date: Tue, 18 Sep 2012 11:40:54 +0300 Message-Id: <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:pIXR0gDfMXx6lfSX/LJr0wL7fNeoDIqrRv+QsGPAVwn PsBEyJO59oTl4yNUHnrsoayc9eqiLYcwWgsp1D3oZ+L9Nl5Ptx 9555MPwBNOUc8UK15stDQ5sjsOc4M/Vvc+7RZbsN7j28CjOvMv +IDeYPvgesAOhgzmUNOAh6JTn/7qxBHcvQwXjcNb/TDoybQ7hB cfig6fOsNtRWw+syhE/8TvU6A4NaWRTsbbRp3EiY+3mNs9IDbW AQzt4kg3OApBf0IdeaDih5OwO7Tk/KiZw+Z8No08js33htuhVn SbmEIKi+qy7Funn3/9uYSc/JLKywnl58Om2yyJGijoduG7CEE0 5lGLmDKbpNcMWsPtght7tdiqzSbK4/4V3swgMrC8X5aPtuC6Ye ObZ1qVggyvftA== Cc: "'pcp@ietf.org'" Subject: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 08:41:13 -0000 --Apple-Mail=_EA335E8F-D5B1-4F4C-A6F8-220153EAE97B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I went back to reading your draft again. I gotta tell you, it felt like reading PANA!=20 Most of the design is direct adaptation of PANA design. Earlier version of the I-D had softly acknowledged that: Some of the ideas in this document were adopted from PANA[RFC5191]. Interestingly, this statement disappeared in the latest doc. "Some" is a major understatement btw. The most striking difference between PANA and your design is in the = terminology, and making it (look like) part of PCP. But actually, on that last note, this does not look like PCP at all = either. PCP is a host-driven req/rsp protocol, plus server-side one-way = notifications. That dictates its state machine. Your design includes: - client side one way message (PCC-Initiation) - server-driven req/rsp - one-way acks (PA-Ack) from client, wedged into req/rsp sequence This is so different than PCP. Forcing the base PCP protocol to have a = state machine to support both its native needs and this new "extension" = is not trivial.=20 If you folks revert the terminology back to PANA's, we can be done :-) Alper --Apple-Mail=_EA335E8F-D5B1-4F4C-A6F8-220153EAE97B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
   Some of the ideas in this =
document were adopted from PANA[RFC5191].

The most striking difference between PANA = and your design is in the terminology, and making it (look like) part of = PCP.

But actually, on that last note, this does = not look like PCP at all either.

PCP is a = host-driven req/rsp protocol, plus server-side one-way notifications. = That dictates its state machine.

Your design = includes:
- client side one way message = (PCC-Initiation)
- server-driven req/rsp
- one-way = acks (PA-Ack) from client, wedged into req/rsp = sequence

This is so different than PCP. Forcing = the base PCP protocol to have a state machine to support both its native = needs and this new "extension" is not = trivial. 

If you folks revert the = terminology back to PANA's, we can be done = :-)

Alper









= --Apple-Mail=_EA335E8F-D5B1-4F4C-A6F8-220153EAE97B-- From rafa@um.es Tue Sep 18 02:28:38 2012 Return-Path: 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 0B59721F878B for ; Tue, 18 Sep 2012 02:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 gy5NmI7ydmFK for ; Tue, 18 Sep 2012 02:28:36 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD9A21F8555 for ; Tue, 18 Sep 2012 02:28:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id E9FB65D4D1; Tue, 18 Sep 2012 11:28:34 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DRPGuJjAFOk4; Tue, 18 Sep 2012 11:28:34 +0200 (CEST) Received: from inf-205-95.inf.um.es (inf-205-95.inf.um.es [155.54.205.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPSA id B4B4D5D4A1; Tue, 18 Sep 2012 11:28:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Rafa Marin Lopez In-Reply-To: Date: Tue, 18 Sep 2012 11:28:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1278) Cc: pcp@ietf.org Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 09:28:38 -0000 Hi Sam: First of all, thank you very much for this analysis. OpenPANA team = really appreciate it. I would like to give my 0.02 cents about this discussion and then give = specific comments related with OpenPANA. Transporting EAP in any protocol to provide authentication and network = access is a general idea which we have seen several times. Basically, = this has meant to design a new EAP lower-layer for EAP (or to force a = protocol for one purpose to be an EAP lower-layer).=20 In any case, you need to start the process of designing this EAP = lower-layer seeing what it is needed in terms of any EAP lower-layer = requirements should be accomplished and its interactions with EAP state = machine. This path was already covered with the design of PANA.=20 Now it seems that PCP with a specific purpose wants to be adapted to be = an EAP lower-layer. Then, presumably, people will have to cover a = similar path as PANA did to cover all interactions with EAP sm, = retransmissions, etc... (which basically have been the outcome of an = IETF WG). So, my expectation of the final outcome in the PCP-Specific = Approach is something which is, in essence, (let's say) 90% PANA-alike = with small modifications for adapting it to the peculiarities in this = scenario. In fact PCP-Specific Approach seems to inherit things that I = have already seen in PANA (which seems a logic consequence of what I am = saying) Going this way is possible, but there is also another way: covering = (let's say) 10% of the path to adapt PANA to the particularities of the = scenario because 90% of the work of designing a EAP lower-layer is = already designed in PANA.=20 So, at first sight, and from my experience on designing a new EAP = lower-layer (and the great effort of doing it) I would take the PANA = option since, simply, most of the work is already done. Obviously, this = is just my opinion if I would have to do the job. Having said that, I = understand that WG should determine what path to cover. Regarding OpenPANA, I have a few comments once I have been commenting = this with OpenPANA developers (I am simply the supervisor of OpenPANA = project), and in general we do not see major problems to carry out the = different changes that you propose. In fact, we think that we would not = base this difficult decision in the existing open source = implementations. After all, they are not final products (at least in the = OpenPANA case) > OpenPANA >=20 > Took a look at http://sf.net/projects/openpana. > OpenPANA is under significantly more active development than CPANA. > One initial concern is the GPL3 license. Depending on the license of > your PCP product, this may not be a viable starting point. This is easy to fix. No problem to change this. >=20 > OpenPANA used wpa_supplicant as an EAP stack; this is good. The code = has > fairly reasonable doxygen markup. The website and source distribution = do > not include pre-built doxygen output. That should not be a problem. >=20 > OpenPANA's description claims that it includes libraries and > applications. This is true, but the libraries are at the level of > parsing PANA messages and utilitiy functions. Much of the guts of the > PANA implementation is built into the applications. That is correct. However, this should not represent a major issue. In = fact, we already have some experience on the scheme you propose. An = example is our IKEv2 implementation (http://openikev2.sourceforge.net) > The applications are specific to network access; as an example there = are > commits dealing with fixing situations that work on a wired NIC but = not > on a laptop. It has already tested in wireless interfaces. So it should not be a = problem either. >=20 > OpenPANA assumes a threaded execution model. If your PCP product is > asynchronous event based, this would be a significant integration > concern. Our very preliminary versions was based in a non-threaded model. In = fact, we have implemented a PANA client for Contiki SO in smart objects = (PANATIKI) as part of OpenPANA project, which uses a model based on = events.=20 Note that even when we are using threads, we have been able to run = OpenPANA (PAA) in Linksys Access Router with OpenWrt.=20 In any case, as I mentioned, this is not a final product. This is just a = modest open source implementation :). > OpenPANA is an application; it uses malloc and other C library > memory management functions directly. Turning that into a library can = be > painful for some environments. >=20 > Regardless of wich PANA approach we pick, you'd need to do some = common > work to OpenPANA to make it useful for PCP. You would need to remove = the > network access code and replace the configuration parsing. Replacing that should not be a major problem. In fact, internally, we = have already used OpenPANA to bootstrap other security associations not = related with network access. It is fairly easy. =20 >=20 > For the encapsulation approach, you'd need to make fairly major > changes. You'd want OpenPANA to run as a library. Also, it really = wants > to handle sending the messages itself. Structures have a sockaddr_in = (or > sockaddr_in6) to which messages are sent. You would instead need to > restructure all that as callbacks or similar. You'd also need to > consider the comments I made about aligning the PCP state machines on > client and server with authentication when discussing the PCP-specific > approach. This is correct, but the reason is simple: PANA was originally = transported in UDP. So following the standard, this is the way to carry = PANA. If a new transport for PANA is designed/standardized this should = be reflected in the implementation. Obviously. But I think that if we = were able to develop OpenPANA, we could achieve also this. >=20 > Parts of the demultiplexing approach look simpler. Personally, I like this approach more. > You could run a PAA > and PAC as separate processes. If the PCP server received an > authentication request it could forward it to the PAA over a local > socket. You'd need to make a slight change so that the return address > could be preserved. In this mode, the PCP server would not need to > change its state machine to wait for authentication.=20 > Except then it gets complicated, because you need coordination between > PCP and the PAC/PAA. You need to design an implementation-specific > protocol to: Yes, you need design an interface which coordinates the PCP SA with PANA = authentication. That is right. In fact, this interface is already = considered in PANA State machine RFC = (http://tools.ietf.org/html/rfc5609). In fact, we have used rfc5609 as a = reference for developing OpenPANA. In any case, as I mentioned we have already played with other types of = SAs not related with network access control. >=20 > * Trigger authentications on the PAC when PCP wants to talk to a = server >=20 > * update the PCP client on authentication state including session = ID,key > ID, and negotiated algorithms >=20 > * Provide error feedback from the PAC to PCP server so the user gets a > consistent error reporting experience >=20 > * Update the PCP server on new authentication sessions at the PAA > including IDs, keys and algorithm identifiers This interface with this functionality you describe was more or less = defined some time ago (e.g. variable AUTH_USER to trigger the PaC, = authorize() function to enforce a state, etc...) . Most probably it may = be improved but somehow it is already there. Moreover it is worth noting = section 9.1 in RFC5609 where some comments are made about this interface >=20 > If you do all that work you're going to end up with a fork of = OpenPANA, It would really be nice to have that fork :)... > not just get a library you can use and potentially refresh for new > products/product releases. ...but having a library is also fine. I guess it is a matter of need. If = people need it, it would be a matter of doing it :). It should not be a = major issue. As I say we already have some experience on having this = kind of libraries. > Security analysis will be different > especially for things like denial of service. >=20 > I'm quite certain making the necessary changes to OpenPANA would be = more > complex and likely to be more expensive than integrating a = PCP-specific > approach. I cannot tell about how a PCP-specific approach implementation will be. = However, as I commented, under design point of view I envisage a long = and hard path on having a new PCP EAP lower-layer. By the simple fact = that it is not an easy task to design a correct EAP lower-layer = following all the requirements.=20 Regarding OpenPANA implementation, from the discussions I have = maintained with the main developers, I can conclude that it requires = work (as everything), yes, but "complex and expensive" would not be the = terms we would use. =20 More comments below. >=20 > General notes >=20 > When you glue technologies together, you add complexity. Some of that > complexity is inherent--for example adding multi-round-trip > authentication to PCP simply will add complexity. > Some of that complexity is in the implementation domain. >=20 > There are EAP and RADIUS libraries out there that have been designed = to > work well with applications. They tend to interface to the existing > event loops, tend to allow the application to supply memory = allocators, > that sort of thing. They tend to support the application providing > configuration information. > Even so, the EAP library is going to bring along its own session > management and message reassembly. > All the options we're discussing involve that complexity. >=20 > Pana is yet another framework on top of EAP. > The PANA specifications are scoped for network access; however we're = not > directly doing network access. The changes to PANA specs between = network > access and application authentication are not very large. However we > still need to consider the benefits especially at an implementation > layer. >=20 > The PANA implementations I've looked at aren't all that thin. They > include session layers on top of the EAP session layer. They are not = as > mature as the EAP implementations; they will place more constraints on > things like event loops and execution models. > OpenPANA brings along its > own alarm linked lists and retransmission infrastructure on top of = what > exists in the EAP library. Yes. The reason is that PANA has their own retransmission mechanism = different than EAP.=20 > It brings along its own PRF+, AES and CMAC > implementations. AES CMAC were added because OpenPANA includes support for a PaC for = Contiki (PANATIKI, included in OpenPANA project). This kind of = cryptography was required in the PAA to support certain particularities = when PANATIKI PaC was installed in smart objects. This is a long story = but it is not related with this discussion :). In fact, PANA RFC does = not mention anything about AES or CMAC.=20 >=20 > Yet, it's easy to see a PCP server or client duplicating a lot of this > too. PCP's going to need a session and retransmission layer; it's = going > to need some cryptographic function (probably a hash-based MAC) for > integrity. > PCP already has its own approach to liveness duplicating what PANA = does. As I commented at the beginning of this e-mail most probably, most of = the same road covered with PANA will be again covered when designing a = PCP-native approach.=20 >=20 > Yes, if you re-use an existing EAP library and are not making > significant customizations then there will be duplication between EAP > and PCP. However PANA introduces significantly more duplication at the > implementation layer. Not sure if I understand where the "more" duplication is. >=20 > My opinion is that when I consider the extra effort to use PANA and = the > extra code it brings along, I don't see what value it brings. To me, it brings the value of saving the amount of cycles that will be = required to design a new EAP lower-layer. Apart from the fact that we = would not expect major problems on extending OpenPANA (or any existing = PANA implementation) following your recommendations.=20 Best regards and many thanks for your expert insight, it can really help = us to improve OpenPANA in the future!. >=20 > You could argue we could save even more by dropping EAP completely and > doing something so PCP-specific that it didn't re-use a security > framework at all. that would be a hard sell for the security area and > would provide less value to our users because they could not re-use > existing infrastructure. > _______________________________________________ > 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 ------------------------------------------------------- From zhangdacheng@huawei.com Tue Sep 18 02:37:09 2012 Return-Path: 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 A57E021E8043 for ; Tue, 18 Sep 2012 02:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lv6mLtnRCn8X for ; Tue, 18 Sep 2012 02:37:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 391C221F87D5 for ; Tue, 18 Sep 2012 02:37:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKT86451; Tue, 18 Sep 2012 09:37:05 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 10:36:03 +0100 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 10:36:23 +0100 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.156]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 18 Sep 2012 17:35:13 +0800 From: "Zhangdacheng (Dacheng)" To: Alper Yegin , Sam Hartman Thread-Topic: [pcp] EAP-over-PCP Thread-Index: AQHNlXlhs2GUiDYww0eGZW/mTWwbnZeP0mfw Date: Tue, 18 Sep 2012 09:35:11 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> In-Reply-To: <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E39E397DDszxeml528mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'pcp@ietf.org'" Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 09:37:09 -0000 --_000_C72CBD9FE3CA604887B1B3F1D145D05E39E397DDszxeml528mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Alper: I am not surprised that you have that feeling. If you could check the disc= ussion during the IETF 83 in Paris, we have clarified the PCP based authent= ication mechanism adopted the idea of PANA (but only the useful part). Also= , in that meeting, people started discussing whether we need an integrated = or an separated authentication mechanism. I think the most important proble= m we are discussing now is whether we need to use PCP or PANA to transport = EAP, right? Please refer to the following link for more information: http://www.ietf.or= g/mail-archive/web/pcp/current/msg01930.html From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Alper= Yegin Sent: Tuesday, September 18, 2012 4:41 PM To: Sam Hartman Cc: 'pcp@ietf.org' Subject: [pcp] EAP-over-PCP I went back to reading your draft again. I gotta tell you, it felt like reading PANA! Most of the design is direct adaptation of PANA design. Earlier version of the I-D had softly acknowledged that: Some of the ideas in this document were adopted from PANA[RFC5191]. Interestingly, this statement disappeared in the latest doc. "Some" is a major understatement btw. The most striking difference between PANA and your design is in the termino= logy, and making it (look like) part of PCP. But actually, on that last note, this does not look like PCP at all either. PCP is a host-driven req/rsp protocol, plus server-side one-way notificatio= ns. That dictates its state machine. Your design includes: - client side one way message (PCC-Initiation) - server-driven req/rsp - one-way acks (PA-Ack) from client, wedged into req/rsp sequence This is so different than PCP. Forcing the base PCP protocol to have a stat= e machine to support both its native needs and this new "extension" is not = trivial. If you folks revert the terminology back to PANA's, we can be done :-) Alper --_000_C72CBD9FE3CA604887B1B3F1D145D05E39E397DDszxeml528mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Alper:=

 = ;

I am not s= urprised that you have  that feeling. If you could check the discussio= n during the IETF 83 in Paris, we have clarified the PCP based authentication mechanism adopted the idea of PANA (but only the useful par= t). Also, in that meeting, people started discussing whether we need an int= egrated or an separated authentication mechanism. I think the most importan= t problem we are discussing now is whether we need to use PCP or PANA to transport EAP, right?<= /span>

 = ;

Please ref= er to the following link for more information: http://www.ietf.org/mail-arc= hive/web/pcp/current/msg01930.html

 = ;

From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Tuesday, September 18, 2012 4:41 PM
To: Sam Hartman
Cc: 'pcp@ietf.org'
Subject: [pcp] EAP-over-PCP

 

I went back to reading your dra= ft again.

 

I gotta tell you, it felt like = reading PANA! 

Most of the design is direct ad= aptation of PANA design.

Earlier version of the I-D had = softly acknowledged that:

 

   Some of the ideas in this document were adopted f=
rom PANA[RFC5191].

 

Interestingly, this statement d= isappeared in the latest doc.

"Some" is a major und= erstatement btw.

 

The most striking difference be= tween PANA and your design is in the terminology, and making it (look like)= part of PCP.

 

But actually, on that last note= , this does not look like PCP at all either.

 

PCP is a host-driven req/rsp pr= otocol, plus server-side one-way notifications. That dictates its state mac= hine.

 

Your design includes:

- client side one way message (= PCC-Initiation)

- server-driven req/rsp

- one-way acks (PA-Ack) from cl= ient, wedged into req/rsp sequence

 

This is so different than PCP. = Forcing the base PCP protocol to have a state machine to support both its n= ative needs and this new "extension" is not trivial. 

 

If you folks revert the termino= logy back to PANA's, we can be done :-)

 

Alper

 

 

 

 

 

 

 

 

 

--_000_C72CBD9FE3CA604887B1B3F1D145D05E39E397DDszxeml528mbxchi_-- From margaretw42@gmail.com Tue Sep 18 03:29:52 2012 Return-Path: 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 30F8821E8064 for ; Tue, 18 Sep 2012 03:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bg5rrI3osimx for ; Tue, 18 Sep 2012 03:29:51 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 916F021F8717 for ; Tue, 18 Sep 2012 03:29:51 -0700 (PDT) Received: by qafi29 with SMTP id i29so2395818qaf.10 for ; Tue, 18 Sep 2012 03:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Oq5u/HXLIo+jghczuevpO+RyZr86VstgEHYzsseIHvE=; b=xS+upDikWKE9lyP5DH2PgJpEaM0FgFHCRWMC1fYrjHWecKYIx2xnQu9lv6lkoWf1rX 8jV2gGSTdGHl5lxge30Dkbrx8D0B/KtpyoefxviDfp+AfHBL2JSeOWX/ncbcinqLnMpY KDKJTHoaF8cl0nM63PjfwCU9xj2FdfosORZX8/vr6CAn0ktcPKhcjSZV3SkckU3UD1YW +mDwAnvLo/x30T7K9h2DJ2mKeCkh7v45E0jX3XcEn0+XYFEjaqNR+amQRxW0IeXU8rzM 0u7SvUFlKJpxWqYrXv2rlKCCkoRYx/zOzMb2OqqMIwR8l0sTFbotnWoYZhTtXPxrpqby LAPw== Received: by 10.224.209.8 with SMTP id ge8mr637988qab.0.1347964190856; Tue, 18 Sep 2012 03:29:50 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id o10sm18992116qaj.4.2012.09.18.03.29.45 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 03:29:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Tue, 18 Sep 2012 06:29:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: "'pcp@ietf.org'" Subject: Re: [pcp] [ Side-by-side or nested protocols X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 10:29:52 -0000 Hi Alper, On Sep 18, 2012, at 2:58 AM, Alper Yegin wrote: > Again, I'm confused. With PANA, you get re-use of spec, = implementation, security analysis.=20 > Which one of these do you get with yet-to-be specified EAP-over-PCP? Just to clarify -- you only get "implementation re-use" if you are able = to use an existing PANA implementation on your platform. That would = require that the existing implementations: - exist - integrate well with your PCP implementation - support the features that you require People should read the long message that Sam Hartman sent to the list = about existing PANA implementations, and make their own determination = about whether one of the existing PANA implementations would work for = them. Two issues that are important here, IMO, are:=20 - whether PANA brings in more complexity than is needed in the PCP case, = because it is designed for the (more complex) network access case. - whether the limitations of the existing PANA implementations (i.e. = limited EAP methods support) are acceptable for PCP If you won't be able to reuse an existing PANA implementation, then the = "implementation re-use" benefit doesn't exist. I don't understand how we can re-use the security analysis, since the = PCP case is very different from a network access case. In fact, the = security requirements for PCP are very unusual, and quite specific to = PCP. Code reuse is also very desirable. In any of our proposed cases, we = could get code-reuse for the EAP portion on systems that use 802.11 = security mechanisms or use EAP for other reasons. It is potentially = possible that you could get additional code-reuse in the PANA case, if = systems end up using PANA for more than one purpose. Right now, though, = there isn't much overlap between the types of systems that use PANA and = the types of systems that are likely to use PCP. None of this reuse is valuable at all, though (again, IMO), if it = presents the user with an unintegrated experience and/or results in a = hard-to-support or hard-to-maintain product. Running two different = protocols side-by-side and trying to present them as a single function = to end-users and administrators presents various system design = challenges that need to be weighed against the complexity of performing = in-band PCP key management. Margaret From margaretw42@gmail.com Tue Sep 18 03:50:32 2012 Return-Path: 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 B65A421F87D5 for ; Tue, 18 Sep 2012 03:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bmPoFF7wkMPA for ; Tue, 18 Sep 2012 03:50:31 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8660721F8794 for ; Tue, 18 Sep 2012 03:50:31 -0700 (PDT) Received: by qcac10 with SMTP id c10so6158189qca.31 for ; Tue, 18 Sep 2012 03:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=EeVZiXHIeL1N/EO3910i1Xz7JpzXTUYjuNfsWTZ0BrU=; b=E16lUzQ/8kAheVrJ0xS6aYoDse2nrsQlLrC50LPoYGiPz7s9eOWhxqPyHjHi7hdVoe GVfv/E7DCA2C2kv18o/c14o52BfHIvgQGYG16rhykkNH7HXbpXwKj5PdMlVhkTwKKY9L oOuMfptEoS4oRpPAwN5WXCO90gc5b1d9NM/laeU5IQZDlgVojRd79iPd+KUSfstlMRYG SIJO5PLf3isr4ngAVPP/pNZRqn0Ru3CJ4Ohvt3XSlp8MHv4/8dLXT1bZRWU3aeSZNY/i DLN5lELW/xEfeJJA+ldgk1kCLtUkDhNerQU5On03YpJlWxDHmX2vP818vudSR5yIhm86 lHig== Received: by 10.224.196.73 with SMTP id ef9mr657683qab.36.1347965429718; Tue, 18 Sep 2012 03:50:29 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id e5sm19049086qao.11.2012.09.18.03.50.26 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 03:50:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <6A210C2E-B490-47A2-B956-585EA078D22F@yegin.org> Date: Tue, 18 Sep 2012 06:50:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <733EEA93-C216-4C1B-B38A-F8682188FA1A@gmail.com> References: <6A210C2E-B490-47A2-B956-585EA078D22F@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 10:50:32 -0000 Hi Alper, On Sep 18, 2012, at 3:30 AM, Alper Yegin wrote: > But more interestingly, you said you are not aware of any PANA = implementations in production. > As we said before, PANA is adopted into Zigbee Smart Energy Profile = 2.0 > And it passed several interop events, with 10 implementations. Do you actually think that any nodes that implement SEP 2.0 will = implement PCP? [For those unfamiliar with Zigbee SEP 2.0, it is one of the standards = (the only IP-based one, I think) proposed for use in the Smart Grid, = specifically for appliances, sensors and other embedded devices to = integrate with a home energy management system (EMS) and/or electric = meter (Smart Meter) on the in-home side of the Smart Energy universe. = Implementations of SEP 2.0 are most often provided in ASICs, for = integration into embedded devices with very limited system requirements. = These devices run on a dedicated Zigbee networks within the home, and = do not generally communicate outside the home, at all.] > Yes, it could be tricky, if we had a funky relationship between the = two protocols. But in this case, it's a clean separation. PCP needs keys = to run, it triggers PANA to generate the keys, PANA does its job and = gives back the keys, PCP runs with the keys. This is how separate "key = management" works. Natural fit. The success case in the side-by-side approach appears to work very = smoothly, it is the error cases that I am more concerned about. Also, = you haven't explained how you would deal with all of the things you list = below... If PCP has a simple request/response API with PANA, how are = things like "asynchronous requests" handled in that model? What is an = "asynchronous request" in this context and when/why would it happen, = BTW? I understand that, in PANA, it is possible for network access to = be renegotiated, or for Ip addresses to be reallocated. There is no = equivalent notion in PCP, though. > But, if we embed one protocol inside the other, then you have to = combine the state machines. And that combining is not a simple jump back = and forth like in the above case. More specifically, within the PCP = state machine, now you have to account for server-side retransmissions, = server-side asynchronous requests, etc. You keep claiming that there will be problems with "combining the state = machines" of PCP and PANA in the encapsulation case that aren't there in = the side-by-side case, but I'm still not sure what you mean by this. = Could you give a concrete example? >> PCP is capable of sending unsolicited messages (both multicast and >> unicast). So, we are good here. >=20 > You are referring to "announcements" right? > They are one-way notifications. > What you need is a server-initiated, multi-round-trip req/rsp = exchanges -- to have a working EAP lower-layer. How do we get this in a model that you have described as: "PCP needs = keys to run, it triggers PANA to generate the keys, PANA does its job = and gives back the keys, PCP runs with the keys. " Won't this notion = (of server-initiated messages) need to be integrated into the API = between PCP and PANA somehow? When would these messages ever happen in = the PCP context? Margaret From margaretw42@gmail.com Tue Sep 18 03:52:32 2012 Return-Path: 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 B40A921F87E6 for ; Tue, 18 Sep 2012 03:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Cmm-PWZKPain for ; Tue, 18 Sep 2012 03:52:32 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5A26421F87E4 for ; Tue, 18 Sep 2012 03:52:31 -0700 (PDT) Received: by qadz3 with SMTP id z3so2404186qad.10 for ; Tue, 18 Sep 2012 03:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=B2MF6IiYl/jejCJ8O/BJcEjXBRZ5zMma7ea1PeF5660=; b=cCKtG/AJXlaUkw1QrSpmDFfpmRx6v9UJdLx/dMY0JJt8/Qp19Tyu2aksrOMg5KwK4T m1ChYLKMu7q8zr8tesxwIBt2rgAiM3DUqjMuIPUPcGQ4vj56vpD/km4XTKkzIX4LLhAW Cj9p78BqetcmpRk1kBldA5y1tSvmXe8bNc5BmHf4du233TF/xsQm12EueLbAkwEIZFUz snScybddGdO+SQYFrxXDfQyxvFt3PbPqhpkynqIHRZZ+BoFotKq0wonUz31Fk7S52xE6 RjlQ0JtwfsYdBnINnorDwKlCl9byDP+Uw4Dnfp47Pet/4Z2Vz4EhhQW43YQg7cSDzxmr 9YKQ== Received: by 10.224.100.200 with SMTP id z8mr552806qan.75.1347965550870; Tue, 18 Sep 2012 03:52:30 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id fl3sm19057852qab.3.2012.09.18.03.52.23 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 03:52:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <162F9DEB-572F-46D9-A34E-7C8576916F5F@yegin.org> Date: Tue, 18 Sep 2012 06:52:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04A79DE5-B4DB-4E3B-BC65-1D47A7E24F75@lilacglade.org> References: <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> <162F9DEB-572F-46D9-A34E-7C8576916F5F@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 10:52:32 -0000 On Sep 18, 2012, at 3:41 AM, Alper Yegin wrote: > Right, these are implementation considerations. > Logging with the proper info, whether it's coming from PCP or PANA is = what we need. > So that tools can parse them properly. Actually, I would argue that these are protocol design issues, not = implementation issues. Good protocol design makes it easy for = implementation to get this sort of thing right. Bad protocol design can = make it much harder, or in some cases impossible, for implementations to = provide a good experience to end-users. Margaret From margaretw42@gmail.com Tue Sep 18 04:12:28 2012 Return-Path: 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 A833521F85C4 for ; Tue, 18 Sep 2012 04:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 p5HQdS4JMcTs for ; Tue, 18 Sep 2012 04:12:28 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id C825C21F8422 for ; Tue, 18 Sep 2012 04:12:27 -0700 (PDT) Received: by qadz3 with SMTP id z3so2418815qad.10 for ; Tue, 18 Sep 2012 04:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=exdHMi2Iddq+fQ5vgnnqwzwGBZic0qv7lcoPA9n0HCk=; b=MIBXCrJxaIE1Pbm/npljwKBMJ/fLVWC8uaa7HpMQKNy9yGka+a+1AfltWBxbVcrjBJ Hbj6NWe3cPY3DT5CVkw/OMn/mmRGzF5Ks16f8qUqHsXjBglxwZgZYjx8GNfIoF+0cPP0 okbMfZY2/LQw7/WUj8cf5lDvkydKZV7P//zX+PVWxRhWGmBa7fL2J6gXTGLST5kV1ZHq 83GnAo1ubythT/UL90OsZQQheOOsts7eeQSIuhd7qIvJdmyy7U47K7M7ov1wP1ifSpae LJAVr2NpJ9IXkjM9mpXVsQYBnd6NnhD/uOVWclqC5UXAVPyNXh9Jj5uS5qhYjluc1ajI mXTQ== Received: by 10.229.137.68 with SMTP id v4mr9203764qct.51.1347966747240; Tue, 18 Sep 2012 04:12:27 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id fl3sm19121394qab.3.2012.09.18.04.12.24 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 04:12:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12-292355293 From: Margaret Wasserman In-Reply-To: <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> Date: Tue, 18 Sep 2012 07:12:22 -0400 Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:12:28 -0000 --Apple-Mail-12-292355293 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 18, 2012, at 4:40 AM, Alper Yegin wrote: > Earlier version of the I-D had softly acknowledged that: >=20 > Some of the ideas in this document were adopted from PANA[RFC5191]. >=20 > Interestingly, this statement disappeared in the latest doc Um, the latest doc describes two solutions, one of which _is_ PANA = (encapsulated in PCP), so it would seem a bit strange to claim the ideas = were "adapted from" PANA... > If you folks revert the terminology back to PANA's, we can be done :-) Both mechanisms described in the current draft are encapsulation = mechanisms, and I was under the impression that you were arguing that a = demultiplexing (side-by-side) mechanism was substantially preferable... = Am I missing something? The PCP-Specific mechanism is very similar to an encapsulated PANA = mechanism with certain specific differences: - It is a simplified protocol, because it doesn't need to handle things = like address reallocation that are specific to the Network Access case. - It is fully integrated with the PCP header, so there are no = overlapping fields that need to be check for consistency, etc. So, if we re-titled our initial PCP-Specific proposal to be called = "Simplified PANA Authentication for PCP", would that resolve all of your = concerns? I don't have a strong personal preference between these two approaches, = because they aren't very different. If we do end-up defining an = encapsulated PANA mechanism, our draft will need to describe what subset = of PANA needs to be implemented/supported for use with PCP, and it will = need to explain how to consistency-check the PANA packet against fields = in the PCP header. So, we'll end up with a protocol that uses (a subset = of) PANA and requires a bit more run-time processing and a few more = error cases than a PCP-Specific solution (for the consistency checking), = but one that is otherwise very similar. As I have said over and over, all of these solutions have far more in = common (conceptually, functionally and even in the bits they will send = on the wire) than their differences. Margaret --Apple-Mail-12-292355293 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Earlier version of the I-D had softly = acknowledged that:

 =
  Some of the ideas in this document were adopted from PANA[RFC5191].

If you folks revert = the terminology back to PANA's, we can be done = :-)

Both mechanisms described in = the current draft are encapsulation mechanisms, and I was under the = impression that you were arguing that a demultiplexing (side-by-side) = mechanism was substantially preferable...  Am I missing = something?

The = PCP-Specific mechanism is very similar to an encapsulated PANA mechanism = with certain specific differences:

- It is a = simplified protocol, because it doesn't need to handle things like = address reallocation that are specific to the Network Access = case.
- It is fully integrated with the PCP header, so there = are no overlapping fields that need to be check for consistency, = etc.

So, if we re-titled our initial = PCP-Specific proposal to be called "Simplified PANA Authentication for = PCP", would that resolve all of your = concerns?

I don't have a strong personal = preference between these two approaches, because they aren't very = different.  If we do end-up defining an encapsulated PANA = mechanism, our draft will need to describe what subset of PANA needs to = be implemented/supported for use with PCP, and it will need to explain = how to consistency-check the PANA packet against fields in the PCP = header.  So, we'll end up with a protocol that uses (a subset of) = PANA and requires a bit more run-time processing and a few more error = cases than a PCP-Specific solution (for the consistency checking), but = one that is otherwise very similar.

As I have = said over and over, all of these solutions have far more in common = (conceptually, functionally and even in the bits they will send on the = wire) than their = differences.

Margaret

= --Apple-Mail-12-292355293-- From tireddy@cisco.com Tue Sep 18 05:03:21 2012 Return-Path: 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 A6C2221E80BC for ; Tue, 18 Sep 2012 05:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 jCMBKShECaPj for ; Tue, 18 Sep 2012 05:03:17 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA7921F8629 for ; Tue, 18 Sep 2012 05:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2038; q=dns/txt; s=iport; t=1347969797; x=1349179397; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=CVUSyqkD2y+YD4/19398iJIQMdN97vZ+k2biWp07mJc=; b=GcQTDs/loeN/0wVuy+LBxxs7xctlTHXPzK8ZmCG3OhDQVQcP/QlQbAL7 ymF7uuniK9xPWMrrz1PV6e1NhXYS/jvgTxu1uXBeM95X7ahCRov7J9fDj zcHLOeY3fQuM/ky65XdMifcJmwl7IXefKJ3QdC9jXHjinz0t7nsgMf3UH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIViWFCtJV2a/2dsb2JhbABFhge1N3WBB4IgAQEBBBIBEBFDDgYBCBEEAQEDAgYdAwIEMBQBBgEBBQUEEwgBGYdeC5hXgSiNG5MYgSGKAIVWMmADlnaNJIFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="122743677" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 18 Sep 2012 12:03:16 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8IC3GtV015388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Sep 2012 12:03:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 07:03:15 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-reddy-pcp-optimize-keepalives-00.txt Thread-Index: AQHNlDUV2PzbvqPf1UGi+zpfs45av5eP+tYA Date: Tue, 18 Sep 2012 12:03:15 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147AB957@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.29.82] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--29.538300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-reddy-pcp-optimize-keepalives-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 12:03:21 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIG5ldyBkcmFmdCB0aGF0IGRlc2NyaWJlcyBo b3cgUG9ydCBDb250cm9sIFByb3RvY29sIGlzIHVzZWZ1bCB0byByZWR1Y2UgTkFUIGFuZCBmaXJl d2FsbCBrZWVwYWxpdmUgbWVzc2FnZXMgZm9yIGEgdmFyaWV0eSBvZiBhcHBsaWNhdGlvbnMuIENv bW1lbnRzIGFuZCBzdWdnZXN0aW9ucyB3ZWxjb21lLg0KDQpSZWdhcmRzLA0KVGlydS4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTdW5kYXksIFNlcHRlbWJl ciAxNiwgMjAxMiAxMTozMCBQTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNj OiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgRGFuIFdpbmcgKGR3aW5nKTsgbWFya3VzLmlz b21ha2lAbm9raWEuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXJlZGR5LXBjcC1vcHRpbWl6ZS1rZWVwYWxpdmVzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1yZWRkeS1wY3Atb3B0aW1pemUta2VlcGFsaXZlcy0wMC50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJlZGR5IGFuZCBw b3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtcmVkZHkt cGNwLW9wdGltaXplLWtlZXBhbGl2ZXMNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIE9wdGltaXpp bmcgTkFUIGFuZCBGaXJld2FsbCBLZWVwYWxpdmVzIFVzaW5nIFBvcnQgQ29udHJvbCBQcm90b2Nv bCAoUENQKQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDktMTYNCldHIElEOgkJIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMg0KVVJMOiAgICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS1wY3Atb3B0aW1pemUta2Vl cGFsaXZlcy0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1yZWRkeS1wY3Atb3B0aW1pemUta2VlcGFsaXZlcw0KSHRtbGl6ZWQ6ICAg ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1wY3Atb3B0aW1pemUt a2VlcGFsaXZlcy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg aG93IFBvcnQgQ29udHJvbCBQcm90b2NvbCBpcyB1c2VmdWwgdG8gcmVkdWNlDQogICBOQVQgYW5k IGZpcmV3YWxsIGtlZXBhbGl2ZSBtZXNzYWdlcyBmb3IgYSB2YXJpZXR5IG9mIGFwcGxpY2F0aW9u cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From hartmans@mit.edu Tue Sep 18 06:05:33 2012 Return-Path: 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 A051521F8783 for ; Tue, 18 Sep 2012 06:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.41 X-Spam-Level: **** X-Spam-Status: No, score=4.41 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 2J-BodcQWDB3 for ; Tue, 18 Sep 2012 06:05:33 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2D56021F877E for ; Tue, 18 Sep 2012 06:05:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 403D220180; Tue, 18 Sep 2012 09:05:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4C26F4149; Tue, 18 Sep 2012 09:05:05 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> Date: Tue, 18 Sep 2012 09:05:05 -0400 In-Reply-To: <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> (Alper Yegin's message of "Tue, 18 Sep 2012 11:40:54 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'pcp@ietf.org'" Subject: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 13:05:33 -0000 Hi, Alper. Thanks for your review. We're glad that we were able in your eyes to successfully re-use a lot of the work that went into PANA design. We really appreciated being able to look at previous lower-layer work including PANA and draft-ietf-abfab-gss-eap to make our job easier. If the WG believes terminology realignment would be beneficial here, then we can work towards that goal. I'd appreciate comments from PCP implementors on the state machine integration issue that Alper brings up. Depending on what's easy for PCP implementations we have a number of options. In RFC 3748 the conversation is conceptually server driven. However, there is typically a client (lower layer) indication to get things started. However, the only reason that the conversation is server-driven iss retransmissions. If you take a look at section 2 of RFC 3748 you note that the protocol is lockstep. The server cannot send a new request until the client has responded to the previous one. If you take a look at section 4.3, a lower layer may sent the retransmission timeout to infinite. In this mode, the server will never generate an unsolicited request. So, it's entirely possible to view things as a client-server protocol with client-driven retransmissions if that makes things easier for PCP implementations. That's the approach we took in draft-ietf-abfab-gss-eap. That spec is an approved EAP lower layer in the RFC editor queue. That spec treats EAP as a simple lock-step client-server protocol. We lose a half round trip because we ask the server to get started and it then asks us for our identity. We came up with mechanisms for including our identity in the first request, trimming a half round trip. The decision of that working group was that the complexity was not worth it, but that optimization is available if it helps with PCP. so, feedback from people with PCP state machines would be really helpful about which of these issues matter to you. From yoshihiro.ohba@toshiba.co.jp Tue Sep 18 08:21:18 2012 Return-Path: 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 1730D21E80DB for ; Tue, 18 Sep 2012 08:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.291 X-Spam-Level: X-Spam-Status: No, score=-5.291 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 Ba4N1xrNR+Ry for ; Tue, 18 Sep 2012 08:21:16 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id A512621F866E for ; Tue, 18 Sep 2012 08:21:16 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q8IFLFPF024493 for ; Wed, 19 Sep 2012 00:21:15 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q8IFLFef015950 for pcp@ietf.org; Wed, 19 Sep 2012 00:21:15 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id AAA15949; Wed, 19 Sep 2012 00:21:15 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q8IFLFfj005871 for ; Wed, 19 Sep 2012 00:21:15 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8IFLFHN010241; Wed, 19 Sep 2012 00:21:15 +0900 (JST) Received: from [133.199.16.234] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAJ00IOBXBE0760@mail.po.toshiba.co.jp> for pcp@ietf.org; Wed, 19 Sep 2012 00:21:15 +0900 (JST) Date: Wed, 19 Sep 2012 00:21:15 +0900 From: Yoshihiro Ohba In-reply-to: <733EEA93-C216-4C1B-B38A-F8682188FA1A@gmail.com> To: "pcp@ietf.org" Message-id: <5058916B.2050409@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <6A210C2E-B490-47A2-B956-585EA078D22F@yegin.org> <733EEA93-C216-4C1B-B38A-F8682188FA1A@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 15:21:18 -0000 Margaret, > Do you actually think that any nodes that implement SEP 2.0 will implement PCP? > Yes. A home EMS that is part of SEP2.0 may implement PCP client for its external broadband connections. Since a home EMS is a typically a constrained device, it would be a burden to implement two different protocols both carrying EAP over UDP. By using PANA over PCP, such a device can significantly benefit from code-sharing to carry EAP over UDP for network access authentication inside 802.15.4 HAN and for doing PCP for broadband connections. This also shows why re-inventing the wheel is a bad idea. Regards, Yoshihiro Ohba From dthaler@microsoft.com Tue Sep 18 15:53:47 2012 Return-Path: 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 A6DA411E808D for ; Tue, 18 Sep 2012 15:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.103 X-Spam-Level: X-Spam-Status: No, score=-105.103 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KOxLsdqlLAzf for ; Tue, 18 Sep 2012 15:53:45 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 49DCB11E809A for ; Tue, 18 Sep 2012 15:53:45 -0700 (PDT) Received: from mail103-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Sep 2012 22:53:44 +0000 Received: from mail103-tx2 (localhost [127.0.0.1]) by mail103-tx2-R.bigfish.com (Postfix) with ESMTP id 94E363002A0 for ; Tue, 18 Sep 2012 22:53:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -7 X-BigFish: VS-7(zz9371I617I15bfKc85fhd6f1izz1202h1d1ah1d2ahzz17326ah8275bh8275dh5eeeKz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh1155h) Received-SPF: pass (mail103-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail103-tx2 (localhost.localdomain [127.0.0.1]) by mail103-tx2 (MessageSwitch) id 1348008822484897_31509; Tue, 18 Sep 2012 22:53:42 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.246]) by mail103-tx2.bigfish.com (Postfix) with ESMTP id 712CF2E0171 for ; Tue, 18 Sep 2012 22:53:42 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Sep 2012 22:53:38 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 18 Sep 2012 22:53:38 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 18 Sep 2012 15:53:37 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0318.003; Tue, 18 Sep 2012 15:53:37 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WebEx info for Friday's interim meeting Thread-Index: Ac2V8EF1GP7J1iQCTiCLRsqinh7xJw== Date: Tue, 18 Sep 2012 22:53:37 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7BB57F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7BB57FTK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] WebEx info for Friday's interim meeting X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 22:53:47 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7BB57FTK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will also post this on the wiki but in the meantime... Connection information is below. -Dave Topic: PCP Interim Meeting Date: Friday, September 21, 2012 Time: 7:30 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Num= ber: 304 269 309 Password: pcp ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D203266498&UID= =3D486507482&PW=3DNYmQwMDU2YjVj&RT=3DMiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: pcp 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Global call-in numbers: https://ciscosales.webex.com/ciscosales/globalcalli= n.php?serviceType=3DMC&ED=3D203266498&tollFree=3D1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:304 269 309 --_000_9B57C850BB53634CACEC56EF4853FF653B7BB57FTK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will also post this on the wiki but in the meantim= e…

Connection information is below.

 

-Dave

 

Topic: PCP Interim Meeting

Date: Friday, September 21, 2012

Time: 7:30 am, Pacific Daylight Time (San Francis= co, GMT-07:00) Meeting Number: 304 269 309

Password: pcp

 

-------------------------------------------------= ------

To join the meeting online(Now from mobile device= s!)

-------------------------------------------------= ------

1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D203266498&UID=3D4865= 07482&PW=3DNYmQwMDU2YjVj&RT=3DMiM0

2. If requested, enter your name and email addres= s.

3. If a password is required, enter the meeting p= assword: pcp

4. Click "Join".

5. If the meeting includes a teleconference, foll= ow the instructions that appear on your screen.

 

-------------------------------------------------= ------

To join the audio conference only

-------------------------------------------------= ------

To receive a call back, provide your phone number= when you join the meeting, or call the number below and enter the access c= ode.

Call-in toll-free number (US/Canada): +1-866-= 432-9903

Call-in toll number (US/Canada): +1-408-525-6= 800

Global call-in numbers: https://ciscosales.webex.com/ciscosales/globalcallin.php?serviceType=3DMC&a= mp;ED=3D203266498&tollFree=3D1

 

Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

 

Access code:304 269 309

 

--_000_9B57C850BB53634CACEC56EF4853FF653B7BB57FTK5EX14MBXW604w_-- From alper.yegin@yegin.org Wed Sep 19 00:30:39 2012 Return-Path: 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 626B721F8647 for ; Wed, 19 Sep 2012 00:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 5WHSAyuY7-UB for ; Wed, 19 Sep 2012 00:30:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5029421F8653 for ; Wed, 19 Sep 2012 00:30:38 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lon6B-1ThF1n36hn-00gATl; Wed, 19 Sep 2012 03:30:36 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_8E90C54D-D1E1-43F3-AEAE-BD519DCE78BA" From: Alper Yegin In-Reply-To: Date: Wed, 19 Sep 2012 10:30:18 +0300 Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:MwSHc3X5QiGwLPlpNdeA1zcLOM8LGxoAkTZFpp9o3Od Xzeoasa7pzlxBTqkrgijRlnVGCD6bz7LwMDpvRBmNj5xlr4G/4 EpM7fchZAeay7kRhywhHU9GWxFxeccROWOOso6pJcaD4WzYzL8 NQyuXvC6wAuvzERQuLVnSBQE6GpDKfA4AM52doyd8b+RbHvKd/ pnL/Ux3zQtYNxe9a01wwzsRm+5QX4c27IfaB2hPM8KWXpadzkf hQTyyoeElyAxd2OcjibHqEfxHwheE6bH2SEq505CN0mgu5CUN0 r2VgOrm0Ob7qvvMme0p5ZkpfVi6fjvAnwz6WRZrRZH5Ke0yMpb /FS5uPsf5OQIPGLbCSvSryxRebtJtuMB/z/aRbRzo3aRr4+3Ro lOmZ1lGAyXl3g== Cc: pcp@ietf.org Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 07:30:39 -0000 --Apple-Mail=_8E90C54D-D1E1-43F3-AEAE-BD519DCE78BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Margaret, >> Earlier version of the I-D had softly acknowledged that: >>=20 >> Some of the ideas in this document were adopted from = PANA[RFC5191]. >>=20 >> Interestingly, this statement disappeared in the latest doc >=20 > Um, the latest doc describes two solutions, one of which _is_ PANA = (encapsulated in PCP), so it would seem a bit strange to claim the ideas = were "adapted from" PANA... >=20 The above statement, which existed in the previous version of the doc, = is referring to EAP-over-PCP design. It's that design that's adopted = from PANA, and that's still in the document. >> If you folks revert the terminology back to PANA's, we can be done = :-) >=20 > Both mechanisms described in the current draft are encapsulation = mechanisms, and I was under the impression that you were arguing that a = demultiplexing (side-by-side) mechanism was substantially preferable... = Am I missing something? >=20 Yes, that's what I'm arguing. > The PCP-Specific mechanism is very similar to an encapsulated PANA = mechanism with certain specific differences: >=20 > - It is a simplified protocol, because it doesn't need to handle = things like address reallocation that are specific to the Network Access = case. Address reallocation as supported by PANA base spec is nothing more than = the PAA conveying a configuration parameter using a single bit.=20 If that bit is not needed for PCP, then we just say it's not used for = PCP.=20 > - It is fully integrated with the PCP header, so there are no = overlapping fields that need to be check for consistency, etc. >=20 Yes, using the PCP header. But that's all when it comes to "integration = into PCP" (plus the common terminology, which is editorial). Otherwise, = pcp-auth is a totally different protocol with its new messages, flow, = state machine. PANA-based solution is allocating three bits out of its reserved bits = for PCP use for the sake using operating on the same port. (Honestly, I don't know why PANA and PCP must operate on the same port. = If someone can explain, I'd appreciate. Is it for saving ports? For = firewall traversal? For some misconception about "binding"? At any rate, = current solution is trivial, but I'm curious why people chose the "same = port".) > So, if we re-titled our initial PCP-Specific proposal to be called = "Simplified PANA Authentication for PCP", would that resolve all of your = concerns? >=20 My point is,=20 - EAP-over-PCP design is not fundamentally PCP-based (using the same = terminology and header, but anything else is different -- more essential = things like the messages, flows, state machine). So, it's a cosmetic = similarity. - in it's essence, it's PANA.=20 - So, why re-invent the wheel. If you can identify the parts of PANA that appears to be extra, we can = discuss if they are really not needed, and how we can go about not using = them. So far, this "IP address reconfig" is mentioned and it's a trivial = feature that's easy not to use. =20 > I don't have a strong personal preference between these two = approaches, because they aren't very different. If we do end-up = defining an encapsulated PANA mechanism, our draft will need to describe = what subset of PANA needs to be implemented/supported for use with PCP, = and it will need to explain how to consistency-check the PANA packet = against fields in the PCP header. =20 We already described the use of those now-assigned three bits in the = I-D. > So, we'll end up with a protocol that uses (a subset of) PANA and = requires a bit more run-time processing and a few more error cases than = a PCP-Specific solution (for the consistency checking), but one that is = otherwise very similar. >=20 > As I have said over and over, all of these solutions have far more in = common (conceptually, functionally and even in the bits they will send = on the wire) than their differences. >=20 Because EAP-over-PCP is re-invented PANA. Not in the vacuum, but = specifically importing the design from PANA. As much as we are humbled = about this, we are still wondering why not use PANA instead of creating = a cosmetically-changed clone. Alper > Margaret >=20 --Apple-Mail=_8E90C54D-D1E1-43F3-AEAE-BD519DCE78BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Earlier version of = the I-D had softly acknowledged that:

 =
  Some of the ideas in this document were adopted from PANA[RFC5191].


The = above statement, which existed in the previous version of the doc, is = referring to EAP-over-PCP design. It's that design that's adopted from = PANA, and that's still in the = document.


If you folks revert = the terminology back to PANA's, we can be done = :-)

Both mechanisms described in = the current draft are encapsulation mechanisms, and I was under the = impression that you were arguing that a demultiplexing (side-by-side) = mechanism was substantially preferable...  Am I missing = something?

<= div>
Yes, that's what I'm = arguing.


The PCP-Specific mechanism = is very similar to an encapsulated PANA mechanism with certain specific = differences:

- It is a simplified protocol, = because it doesn't need to handle things like address reallocation that = are specific to the Network Access = case.

Address reallocation = as supported by PANA base spec is nothing more than the PAA conveying a = configuration parameter using a single bit. 
If that bit = is not needed for PCP, then we just say it's not used for = PCP. 


- It is fully = integrated with the PCP header, so there are no overlapping fields that = need to be check for consistency, = etc.


Yes, = using the PCP header. But that's all when it comes to "integration into = PCP" (plus the common terminology, which is editorial). Otherwise, = pcp-auth is a totally different protocol with its new messages, flow, = state machine.

PANA-based solution is = allocating three bits out of its reserved bits for PCP use for the sake = using operating on the same port.
(Honestly, I don't know why = PANA and PCP must operate on the same port. If someone can explain, I'd = appreciate. Is it for saving ports? For firewall traversal? For some = misconception about "binding"? At any rate, current solution is trivial, = but I'm curious why people chose the "same = port".)



So, if we = re-titled our initial PCP-Specific proposal to be called "Simplified = PANA Authentication for PCP", would that resolve all of your = concerns?


My point is, 
- EAP-over-PCP design is not fundamentally = PCP-based (using the same terminology and header, but anything else is = different -- more essential things like the messages, flows, state = machine). So, it's a cosmetic similarity.
- in it's essence, = it's PANA. 
- So, why re-invent the = wheel.

If you can identify the parts of PANA = that appears to be extra, we can discuss if they are really not needed, = and how we can go about not using them.
So far, this "IP = address reconfig" is mentioned and it's a trivial feature that's easy = not to use.   


I don't have a = strong personal preference between these two approaches, because they = aren't very different.  If we do end-up defining an encapsulated = PANA mechanism, our draft will need to describe what subset of PANA = needs to be implemented/supported for use with PCP, and it will need to = explain how to consistency-check the PANA packet against fields in the = PCP header.  

We = already described the use of those now-assigned three bits in the = I-D.


So, we'll end up with a = protocol that uses (a subset of) PANA and requires a bit more run-time = processing and a few more error cases than a PCP-Specific solution (for = the consistency checking), but one that is otherwise very = similar.

As I have said over and over, all of = these solutions have far more in common (conceptually, functionally and = even in the bits they will send on the wire) than their = differences.


Because EAP-over-PCP is re-invented PANA. Not in the vacuum, = but specifically importing the design from PANA. As much as we are = humbled about this, we are still wondering why not use PANA instead of = creating a cosmetically-changed = clone.


Alper

<= div>

Margaret


= --Apple-Mail=_8E90C54D-D1E1-43F3-AEAE-BD519DCE78BA-- From alper.yegin@yegin.org Wed Sep 19 00:40:01 2012 Return-Path: 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 1196D21F86AB for ; Wed, 19 Sep 2012 00:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 cXWZtXOy6U2P for ; Wed, 19 Sep 2012 00:40:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 75A8921F86AA for ; Wed, 19 Sep 2012 00:40:00 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LoErp-1Tggx034NF-00gf0C; Wed, 19 Sep 2012 03:39:58 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Wed, 19 Sep 2012 10:39:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:P4tFH0J6OZ61dUd+lozqLnAgeyy4Uxt4k2yqihnOEF1 Ql4mTQWxxewlRHLnmbhi3gPbXQOjpxnejrr5ROYIeH9x+kdblC Y41Sgz+q/TC1UtLJlrD11JIPLcHMpluOahqY0EffOmZlpdR7vz vG/2MhLJo+4fJz5TCNFfPxDhzX/8VQ25PhUuVM9h7j1ePgjv9b 2/HsIR/Ukp8M84IP2k1lTBOFi3LMVONb4D5tZNFnoYrXUP6+b/ eEiDHe33+QicHFQXQ5Zo94oG9KjFof/uxkRN0atSatzcunKhWn wluUM9K9vACWb1jyOY6fwxYAvTRlie27/NxVgyFRynP+CX16LT EVlDiqXiDsk7/sZsyg2zEVU9zOElyMcwCuUc95JGz6UWeds1LH YybKhg7Sa+3MQ== Cc: "'pcp@ietf.org'" Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 07:40:01 -0000 Hi Sam, >=20 >=20 > Hi, Alper. > Thanks for your review. > We're glad that we were able in your eyes to successfully re-use a lot > of the work that went into PANA design. > We really appreciated being able to look at previous lower-layer work > including PANA and draft-ietf-abfab-gss-eap to make our job easier. >=20 >=20 > If the WG believes terminology realignment would be beneficial here, > then we can work towards that goal. >=20 > I'd appreciate comments from PCP implementors on the state machine > integration issue that Alper brings up. >=20 > Depending on what's easy for PCP implementations we have a number of > options. >=20 > In RFC 3748 the conversation is conceptually server driven. > However, there is typically a client (lower layer) indication to get > things started. >=20 > However, the only reason that the conversation is server-driven iss > retransmissions. If you take a look at section 2 of RFC 3748 you note > that the protocol is lockstep. The server cannot send a new request > until the client has responded to the previous one. If you take a = look > at section 4.3, a lower layer may sent the retransmission timeout to > infinite. In this mode, the server will never generate an unsolicited > request. > So, it's entirely possible to view things as a client-server protocol > with client-driven retransmissions if that makes things easier for PCP > implementations. >=20 I don't understand how this works. EAP authenticator performs rexmits.=20 So, if it does not get a response, it'll keep rexmitting. So, how can = you achieve "server will never generate an unsolicited request"? And, furthermore, there'd be EAP re-authentication which can be = initiated by the client or server. This is another reason for having to = support server-side requests. Alper > That's the approach we took in draft-ietf-abfab-gss-eap. That spec is = an > approved EAP lower layer in the RFC editor queue. That spec treats EAP > as a simple lock-step client-server protocol. We lose a half round = trip > because we ask the server to get started and it then asks us for our > identity. We came up with mechanisms for including our identity in the > first request, trimming a half round trip. The decision of that = working > group was that the complexity was not worth it, but that optimization = is > available if it helps with PCP. >=20 > so, feedback from people with PCP state machines would be really = helpful > about which of these issues matter to you. From alper.yegin@yegin.org Wed Sep 19 00:58:16 2012 Return-Path: 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 9C52B21F875D for ; Wed, 19 Sep 2012 00:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 yT2XDQfe4s9F for ; Wed, 19 Sep 2012 00:58:16 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id DF3A021F8754 for ; Wed, 19 Sep 2012 00:58:15 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M39ax-1TXHvT323T-00svX4; Wed, 19 Sep 2012 03:58:15 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <733EEA93-C216-4C1B-B38A-F8682188FA1A@gmail.com> Date: Wed, 19 Sep 2012 10:57:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6A210C2E-B490-47A2-B956-585EA078D22F@yegin.org> <733EEA93-C216-4C1B-B38A-F8682188FA1A@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:cSP/jXH05BLA++fKD/UPrpn1Pdk3A4exWlC2i+n6flu ZyVnhy/EnLCQhUaB5fNqZEzLcTRP6ErdSL/B8FPnc5we7WPOVL qLCcVzGXDqlN8cNL1Bcv+2+vyc1G3ouC1cuJxKpeA89XgHsNwE b7cL5TiY9yaq3+CkgQokQK1oY7v5hse68enIWkAnxRvsc46s3L 1RqgZexyBsZfVlWljrb4UuKPShfU/4JFSmQBEkR/TyyWmX2ryR pw28Jl79g/CGk1YyMDRJp4ya/UY6NSMb09KDxDsERMhEZ7LEJO Djus6iPFusoZmz92GQi/W/SGPus3YVnJ0tiWjiIQs3sXStkXBC yCjqFPpIgL51zNFjjvoF7i47Jtb4gdeR30Xx+CG+VDb7fKrsL8 ZJsYl/NIhfplA== Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 07:58:16 -0000 Hi Margaret, >=20 > On Sep 18, 2012, at 3:30 AM, Alper Yegin wrote: >> But more interestingly, you said you are not aware of any PANA = implementations in production. >> As we said before, PANA is adopted into Zigbee Smart Energy Profile = 2.0 >> And it passed several interop events, with 10 implementations. >=20 > Do you actually think that any nodes that implement SEP 2.0 will = implement PCP? >=20 First, let's recognize different types of "re-use": - spec re-use - source code re-use - binary re-use Your question is specifically about the last one. I think the answer to = the first two are clear, and that by itself goes a long way. Even binary re-use is a possibility, like Yoshi explained, and also = considering the possibility of integrated gateways. > [For those unfamiliar with Zigbee SEP 2.0, it is one of the standards = (the only IP-based one, I think) proposed for use in the Smart Grid, = specifically for appliances, sensors and other embedded devices to = integrate with a home energy management system (EMS) and/or electric = meter (Smart Meter) on the in-home side of the Smart Energy universe. = Implementations of SEP 2.0 are most often provided in ASICs, for = integration into embedded devices with very limited system requirements. = These devices run on a dedicated Zigbee networks within the home, and = do not generally communicate outside the home, at all.] >=20 >> Yes, it could be tricky, if we had a funky relationship between the = two protocols. But in this case, it's a clean separation. PCP needs keys = to run, it triggers PANA to generate the keys, PANA does its job and = gives back the keys, PCP runs with the keys. This is how separate "key = management" works. Natural fit. >=20 > The success case in the side-by-side approach appears to work very = smoothly, it is the error cases that I am more concerned about. =20 Which specific error cases? You raised one about auth capability = mismatch and I already responded to that. > Also, you haven't explained how you would deal with all of the things = you list below... If PCP has a simple request/response API with PANA, = how are things like "asynchronous requests" handled in that model? What = is an "asynchronous request" in this context and when/why would it = happen, BTW? I understand that, in PANA, it is possible for network = access to be renegotiated, or for Ip addresses to be reallocated. There = is no equivalent notion in PCP, though. >=20 EAP re-authentication can be initiated by either party at any time. We = need to support that. >> But, if we embed one protocol inside the other, then you have to = combine the state machines. And that combining is not a simple jump back = and forth like in the above case. More specifically, within the PCP = state machine, now you have to account for server-side retransmissions, = server-side asynchronous requests, etc. >=20 > You keep claiming that there will be problems with "combining the = state machines" of PCP and PANA in the encapsulation case that aren't = there in the side-by-side case, but I'm still not sure what you mean by = this. Could you give a concrete example? Please see my email with EAP-over-PCP subject line. As you see, the = state machines and flows of PCP and EAP-over-PCP are not compatible. If = you try to fit the latter into the former, it won't work -- = incompatible. Exact same issue with EAP-over-DHCP. I (naively?) assumed = you'd not want to impact the PCP design hence this compatibility issue = is a problem.=20 >=20 >>> PCP is capable of sending unsolicited messages (both multicast and >>> unicast). So, we are good here. >>=20 >> You are referring to "announcements" right? >> They are one-way notifications. >> What you need is a server-initiated, multi-round-trip req/rsp = exchanges -- to have a working EAP lower-layer. >=20 > How do we get this in a model that you have described as: "PCP needs = keys to run, it triggers PANA to generate the keys, PANA does its job = and gives back the keys, PCP runs with the keys. " Won't this notion = (of server-initiated messages) need to be integrated into the API = between PCP and PANA somehow? When would these messages ever happen in = the PCP context? >=20 Whether the client-side or the server-side initiated the re-auth, = EAP/PANA is executed and new security association is generated. The new = parameters are stored in the data structures where the PCP client picks = them up next time it needs to send a request.=20 Alper > Margaret >=20 >=20 From margaretw42@gmail.com Wed Sep 19 03:06:33 2012 Return-Path: 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 ADE2F21F86E2 for ; Wed, 19 Sep 2012 03:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 kw4cZcTi3YE6 for ; Wed, 19 Sep 2012 03:06:33 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26A8A21F86BA for ; Wed, 19 Sep 2012 03:06:33 -0700 (PDT) Received: by qcac10 with SMTP id c10so745511qca.31 for ; Wed, 19 Sep 2012 03:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NjgV0VCItm7baBp/xf+1VqE9V2IMO4uNxO8Km5f/M5Q=; b=cAWoqtPdJbPMuLLLI6IAPNJ+6pfhq1teAWrbDZc7E5fKNI22WbFafII3CfthAXVyhA 5yxdbXsD+jwaTLfREVNo3Icy7OlLbVlbbOUFNPUfoNyz/PCRSTRChVMzVejgD6p0nVrs 5GAbI1AWL5876X0hJW03RdpFxLyllB4cIBbEIAvzDBDlY62wacz2m9zpk07fEtlwt3Xu AFHhC+t11LSMqDjrgzFA1esA5Mts7Fwmff+p1i8CZj3zCZdTSezeHPwVfiA0Wlx3BnkT tX8sW7rAeTWo2f82mN1xXjFzGC+vGiT+XLL2el/SDfTfW//BbhOuaUy1F6LneXosVSW8 FYAw== Received: by 10.224.221.84 with SMTP id ib20mr5927411qab.50.1348049192485; Wed, 19 Sep 2012 03:06:32 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id bh14sm3411723qab.2.2012.09.19.03.06.29 (version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 03:06:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> Date: Wed, 19 Sep 2012 06:06:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: "'pcp@ietf.org'" Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 10:06:33 -0000 Hi Alper, On Sep 19, 2012, at 3:39 AM, Alper Yegin wrote: > I don't understand how this works. > EAP authenticator performs rexmits.=20 > So, if it does not get a response, it'll keep rexmitting. So, how can = you achieve "server will never generate an unsolicited request"? A retransmission is not an unsolicited request... I'm not sure what you = mean by this. > And, furthermore, there'd be EAP re-authentication which can be = initiated by the client or server. This is another reason for having to = support server-side requests. Why do you think that we need to support EAP re-authentication?=20 Margaret From margaretw42@gmail.com Wed Sep 19 03:11:11 2012 Return-Path: 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 467E821F86AD for ; Wed, 19 Sep 2012 03:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VhSClXXm27sT for ; Wed, 19 Sep 2012 03:11:10 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id AB40221F856D for ; Wed, 19 Sep 2012 03:11:10 -0700 (PDT) Received: by qadz3 with SMTP id z3so868361qad.10 for ; Wed, 19 Sep 2012 03:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1/6ZhdZOHELqMNp8eNOiKj23HJggnLpPUiPoKMYbcOw=; b=UDnf2XbNz525KSMpqaYy4ipjPX9b+/ur1IqhhevfJpUBAgKsn0f/53Mb/6flcdQ3Oo 2pvHN0AkZHkerFAQEYv9nN5/2a82x1vWpAYziw6rX/vkX3t16KUkBoXMEZbqKvIkhI7D VjALGelgZTGAedFdJIn/KKedRzDFiB6LcFsLKyWJVhuMGmtvY7BscWrRx0A0lfqg5+ot 6YU0MONRjoPyKYpGIaxx2z5+1CnhSO/js0Rcd3YD/v1zuI6tyxh9ioJUWiFXo1+9x8ow eBbi1AqwprMA/OE1COFNWppvF2lS9B2RDB8Sz68FKFRZvLr/xsGsKagdZ19hkjR7CWhS Pqhw== Received: by 10.224.78.197 with SMTP id m5mr4966403qak.36.1348049470244; Wed, 19 Sep 2012 03:11:10 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id fl3sm3424287qab.3.2012.09.19.03.11.06 (version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 03:11:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> Date: Wed, 19 Sep 2012 06:11:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <70154AB6-F7B5-47B0-B721-811EA5DF9926@lilacglade.org> References: <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 10:11:11 -0000 Hi Alper, On Sep 17, 2012, at 5:24 AM, Alper Yegin wrote: > Yep, they are implementing "EAP lower layers". "EAP-over-UDP/PCP" is = an EAP lower-layer and it'll have the same thing (once people realize = it's more than defining a EAP container to qualify as a "working" and = "compliant" EAP lower layer). You have mentioned this several times, but you haven't provided any = specifics. What do you think is missing from the PCP-specific approach, = as document, that would need to be added to make it a "working" and = "compliant" EAP lower layer? Is there an RFC that specifies the = requirements that the PCP-Specific approach is failing to meet?=20 Margaret From repenno@cisco.com Wed Sep 19 05:03:27 2012 Return-Path: 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 4B70F21F8714 for ; Wed, 19 Sep 2012 05:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ugOdf9wuNUPY for ; Wed, 19 Sep 2012 05:03:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ADA2821F8505 for ; Wed, 19 Sep 2012 05:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5871; q=dns/txt; s=iport; t=1348056205; x=1349265805; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=T9L2BXrIX6kli10ulaYmWoOBCxyTEyysw8Nq+sDRa2E=; b=eXe/V4hdRR4sPyQZhocZpRdRZLgCnUaDa+qJZOHIFJ62mq+C/+jIpk+H Rqq/9PVI07R1tcFqFfjLAnrN84A52ThHQaQiacLDmPQjIT4kIVZWJmQPJ EFGsCwfYqm8nZs+DR/d/Xikh4BhjxGTx6thanIT4src2ta3yNCfimxzcO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEOzWVCtJXG+/2dsb2JhbABFvEyBCIIgAQEBBBIBJzgHDAYBCBEDAQIBFQkxER0IAgQBDQUihW+BYAMMmleWPA2JU4o6YhSDAoMrA5QPgVWLF4MhgWmCZoFaCTQ X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="123111769" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 19 Sep 2012 12:03:19 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8JC3J6r017861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 12:03:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 07:03:19 -0500 From: "Reinaldo Penno (repenno)" To: Alper Yegin , Margaret Wasserman Thread-Topic: Side-by-side or nested protocols (was Re: [pcp] PANA implementatinos to consider) Thread-Index: AQHNlK7vlZXBAt5m0kamo0nw+r8wLpeOghkAgALNmROAACLkAA== Date: Wed, 19 Sep 2012 12:03:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.145.207] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19192.002 x-tm-as-result: No--49.029000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 12:03:27 -0000 -----Original Message----- From: Alper Yegin Date: Wed, 19 Sep 2012 10:57:37 +0300 To: Margaret Wasserman Cc: Reinaldo Penno , "Henderickx, Wim (Wim)" , "'pcp@ietf.org'" Subject: Re: Side-by-side or nested protocols (was Re: [pcp] PANA implementatinos to consider) >Hi Margaret, >>=20 >> On Sep 18, 2012, at 3:30 AM, Alper Yegin wrote: >>> But more interestingly, you said you are not aware of any PANA >>>implementations in production. >>> As we said before, PANA is adopted into Zigbee Smart Energy Profile 2.0 >>> And it passed several interop events, with 10 implementations. >>=20 >> Do you actually think that any nodes that implement SEP 2.0 will >>implement PCP? >>=20 > >First, let's recognize different types of "re-use": >- spec re-use >- source code re-use >- binary re-use > >Your question is specifically about the last one. I think the answer to >the first two are clear, and that by itself goes a long way. I do not think it is clear. The devices implementing PCP Server (routers, FW, CGNs, CPEs, etc) will most likely not be able to reuse source code from Zigbee. There are threading considerations, 64 vs. 32 bit, memory management, configuration, events. The list goes on and on. My experience with protocol code reuse between such different platforms is not very rosy. > >Even binary re-use is a possibility, like Yoshi explained, and also >considering the possibility of integrated gateways. Like getting PANA binary from Zigbee and running on a CGN, CPE/High end Firewall running on a different NPU type without rewriting almost from scratch, recompilation, integration with CLI, debug, etc ? Please excuse my skepticism when I doubt this. But to be fair, please point me to your best candidate for this reuse and I will see if we can look into it if WG thinks it will help the process. > > >> [For those unfamiliar with Zigbee SEP 2.0, it is one of the standards >>(the only IP-based one, I think) proposed for use in the Smart Grid, >>specifically for appliances, sensors and other embedded devices to >>integrate with a home energy management system (EMS) and/or electric >>meter (Smart Meter) on the in-home side of the Smart Energy universe. >>Implementations of SEP 2.0 are most often provided in ASICs, for >>integration into embedded devices with very limited system requirements. >> These devices run on a dedicated Zigbee networks within the home, and >>do not generally communicate outside the home, at all.] >>=20 >>> Yes, it could be tricky, if we had a funky relationship between the >>>two protocols. But in this case, it's a clean separation. PCP needs >>>keys to run, it triggers PANA to generate the keys, PANA does its job >>>and gives back the keys, PCP runs with the keys. This is how separate >>>"key management" works. Natural fit. >>=20 >> The success case in the side-by-side approach appears to work very >>smoothly, it is the error cases that I am more concerned about. > >Which specific error cases? You raised one about auth capability mismatch >and I already responded to that. > > >> Also, you haven't explained how you would deal with all of the things >>you list below... If PCP has a simple request/response API with PANA, >>how are things like "asynchronous requests" handled in that model? What >>is an "asynchronous request" in this context and when/why would it >>happen, BTW? I understand that, in PANA, it is possible for network >>access to be renegotiated, or for Ip addresses to be reallocated. There >>is no equivalent notion in PCP, though. >>=20 > >EAP re-authentication can be initiated by either party at any time. We >need to support that. > >>> But, if we embed one protocol inside the other, then you have to >>>combine the state machines. And that combining is not a simple jump >>>back and forth like in the above case. More specifically, within the >>>PCP state machine, now you have to account for server-side >>>retransmissions, server-side asynchronous requests, etc. >>=20 >> You keep claiming that there will be problems with "combining the state >>machines" of PCP and PANA in the encapsulation case that aren't there in >>the side-by-side case, but I'm still not sure what you mean by this. >>Could you give a concrete example? > >Please see my email with EAP-over-PCP subject line. As you see, the state >machines and flows of PCP and EAP-over-PCP are not compatible. If you try >to fit the latter into the former, it won't work -- incompatible. Exact >same issue with EAP-over-DHCP. I (naively?) assumed you'd not want to >impact the PCP design hence this compatibility issue is a problem. > > >>=20 >>>> PCP is capable of sending unsolicited messages (both multicast and >>>> unicast). So, we are good here. >>>=20 >>> You are referring to "announcements" right? >>> They are one-way notifications. >>> What you need is a server-initiated, multi-round-trip req/rsp >>>exchanges -- to have a working EAP lower-layer. >>=20 >> How do we get this in a model that you have described as: "PCP needs >>keys to run, it triggers PANA to generate the keys, PANA does its job >>and gives back the keys, PCP runs with the keys. " Won't this notion >>(of server-initiated messages) need to be integrated into the API >>between PCP and PANA somehow? When would these messages ever happen in >>the PCP context? >>=20 > >Whether the client-side or the server-side initiated the re-auth, >EAP/PANA is executed and new security association is generated. The new >parameters are stored in the data structures where the PCP client picks >them up next time it needs to send a request. > >Alper > > > > > >> Margaret >>=20 >>=20 > From hartmans@painless-security.com Wed Sep 19 06:54:26 2012 Return-Path: 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 E0EE921F861D for ; Wed, 19 Sep 2012 06:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.395 X-Spam-Level: **** X-Spam-Status: No, score=4.395 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 TjwCSP7BvS-9 for ; Wed, 19 Sep 2012 06:54:26 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3C11021F8620 for ; Wed, 19 Sep 2012 06:54:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A649120178; Wed, 19 Sep 2012 09:54:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6060C4149; Wed, 19 Sep 2012 09:53:55 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> Date: Wed, 19 Sep 2012 09:53:55 -0400 In-Reply-To: <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> (Alper Yegin's message of "Wed, 19 Sep 2012 10:39:40 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'pcp@ietf.org'" Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 13:54:27 -0000 >>>>> "Alper" == Alper Yegin writes: >> Depending on what's easy for PCP implementations we have a number >> of options. >> >> In RFC 3748 the conversation is conceptually server driven. >> However, there is typically a client (lower layer) indication to >> get things started. >> >> However, the only reason that the conversation is server-driven >> iss retransmissions. If you take a look at section 2 of RFC 3748 >> you note that the protocol is lockstep. The server cannot send a >> new request until the client has responded to the previous one. >> If you take a look at section 4.3, a lower layer may sent the >> retransmission timeout to infinite. In this mode, the server will >> never generate an unsolicited request. So, it's entirely >> possible to view things as a client-server protocol with >> client-driven retransmissions if that makes things easier for PCP >> implementations. >> Alper>I don't understand how this works. Alper> EAP authenticator performs rexmits. So, if it does not get a Alper> response, it'll keep rexmitting. So, how can you achieve Alper> "server will never generate an unsolicited request"? There are three aspects to this: why does it work in practice, why does it comply with the spec, and why do I think it's been reviewed adequately to suggest it? For the first, EAP libraries tend to have a way to ignore retransmits or set the retransmission timeout to infinite. Consider what happens in an AAA server. There, your EAP server cannot (and is not supposed to) handle retransmits. RADIUS at least is a lock-step protocol. Ignoring things like COA, a RADIUS server cannot send an unsolicited response to a client. So any EAP server library basically has to have a way to disable retransmits. I guess it's possible that you could have a passthrough authenticator library that doesn't pull this off. IN practice we've not run into this problem; see below for why. Also, as I understand it (without close reading) the IKEv2 EAP support works this way as well. So, why does it comply with the spec? Take a look at RFC 3748 section 4.3. That section points out a lower layer can set the retransmit timeout to infinite if it is reliable itself. Why do I think the whole idea of assuming you'll never get an unsolicited server request has been adequately reviewed? It's part of draft-ietf-abfab-gss-eap, which has already been approved and is waiting publication. I've personally walked through what we were doing with Bernard; I know Joe is familiar with the work enough that he understands our state machine constraints. Klaas is one of the chairs; he also has a lot of EAP experience. Josh Howlett, my co-author has many more years of EAP experience than I do. So, I believe that this idea has received adequate review that if I were somehow misreading the base EAP spec we would have noticed it. Alper> And, furthermore, there'd be EAP re-authentication which can Alper> be initiated by the client or server. This is another reason Alper> for having to support server-side requests. I'm not entirely sure what you're talking about when you say EAP re-authentication. Do you mean the EAP re-authentication protocol (the one done in HOKEY?) The base EAP spec mentions re-authentication once or twice but does not define it. My best reading of that text is that they simply mean there can be later EAP conversations if you want to access a new resource or the like, or the network wants to re-key, or prove fresh access to tokens or whatever. When you look at the peer state machine in RFC 4137, you note that the success state is a final state. It's going to require lower layer interactions to get out of that state. If you look at the commen open-source supplicants (all I have access to) you see that tends to be how people implement things. You expect a disassociation or something else to trigger new authentication. And when that happens, yes, depending on who's doing the trigger and what's going on, the first *EAP* message may be from the server. In our proposal, PCP is the same way. A server can throw away a session and give a client an error that they must authenticate again if it wants an EAP exchange. This is intended to deal with wanting to expire sessions or servers that lose state. However it also deals with a server wanting to confirm freshness, or getting a re-authentication demand via some complex AAA infrastructure that seems unlikely to be used with PCP in practice. From yoshihiro.ohba@toshiba.co.jp Wed Sep 19 07:46:48 2012 Return-Path: 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 890E021F8688 for ; Wed, 19 Sep 2012 07:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.171 X-Spam-Level: X-Spam-Status: No, score=-5.171 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 dXeDG7aK5M55 for ; Wed, 19 Sep 2012 07:46:47 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADE921F8658 for ; Wed, 19 Sep 2012 07:46:47 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q8JEkklT017277 for ; Wed, 19 Sep 2012 23:46:46 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q8JEkkOU001473 for pcp@ietf.org; Wed, 19 Sep 2012 23:46:46 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA01472; Wed, 19 Sep 2012 23:46:46 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q8JEkkge024340 for ; Wed, 19 Sep 2012 23:46:46 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8JEkkU8007738; Wed, 19 Sep 2012 23:46:46 +0900 (JST) Received: from [133.199.17.204] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAL001ENQDXZ410@mail.po.toshiba.co.jp> for pcp@ietf.org; Wed, 19 Sep 2012 23:46:45 +0900 (JST) Date: Wed, 19 Sep 2012 23:46:47 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <5059DAD7.2030507@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 14:46:48 -0000 (2012/09/19 21:03), Reinaldo Penno (repenno) wrote: (snip) >> >> Even binary re-use is a possibility, like Yoshi explained, and also >> considering the possibility of integrated gateways. > > > Like getting PANA binary from Zigbee and running on a CGN, CPE/High end > Firewall running on a different NPU type without rewriting almost from > scratch, recompilation, integration with CLI, debug, etc ? Please excuse > my skepticism when I doubt this. But to be fair, please point me to your > best candidate for this reuse and I will see if we can look into it if WG > thinks it will help the process. I suggest taking a look at the open source implementations that I pointed and Sam analyzed, and send comments to this list as Sam did. You would have some points, and your comments will be valuable to improve the quality of the open source implementations, Yoshihiro Ohba > > >> >> >>> [For those unfamiliar with Zigbee SEP 2.0, it is one of the standards >>> (the only IP-based one, I think) proposed for use in the Smart Grid, >>> specifically for appliances, sensors and other embedded devices to >>> integrate with a home energy management system (EMS) and/or electric >>> meter (Smart Meter) on the in-home side of the Smart Energy universe. >>> Implementations of SEP 2.0 are most often provided in ASICs, for >>> integration into embedded devices with very limited system requirements. >>> These devices run on a dedicated Zigbee networks within the home, and >>> do not generally communicate outside the home, at all.] >>> >>>> Yes, it could be tricky, if we had a funky relationship between the >>>> two protocols. But in this case, it's a clean separation. PCP needs >>>> keys to run, it triggers PANA to generate the keys, PANA does its job >>>> and gives back the keys, PCP runs with the keys. This is how separate >>>> "key management" works. Natural fit. >>> >>> The success case in the side-by-side approach appears to work very >>> smoothly, it is the error cases that I am more concerned about. >> >> Which specific error cases? You raised one about auth capability mismatch >> and I already responded to that. >> >> >>> Also, you haven't explained how you would deal with all of the things >>> you list below... If PCP has a simple request/response API with PANA, >>> how are things like "asynchronous requests" handled in that model? What >>> is an "asynchronous request" in this context and when/why would it >>> happen, BTW? I understand that, in PANA, it is possible for network >>> access to be renegotiated, or for Ip addresses to be reallocated. There >>> is no equivalent notion in PCP, though. >>> >> >> EAP re-authentication can be initiated by either party at any time. We >> need to support that. >> >>>> But, if we embed one protocol inside the other, then you have to >>>> combine the state machines. And that combining is not a simple jump >>>> back and forth like in the above case. More specifically, within the >>>> PCP state machine, now you have to account for server-side >>>> retransmissions, server-side asynchronous requests, etc. >>> >>> You keep claiming that there will be problems with "combining the state >>> machines" of PCP and PANA in the encapsulation case that aren't there in >>> the side-by-side case, but I'm still not sure what you mean by this. >>> Could you give a concrete example? >> >> Please see my email with EAP-over-PCP subject line. As you see, the state >> machines and flows of PCP and EAP-over-PCP are not compatible. If you try >> to fit the latter into the former, it won't work -- incompatible. Exact >> same issue with EAP-over-DHCP. I (naively?) assumed you'd not want to >> impact the PCP design hence this compatibility issue is a problem. >> >> >>> >>>>> PCP is capable of sending unsolicited messages (both multicast and >>>>> unicast). So, we are good here. >>>> >>>> You are referring to "announcements" right? >>>> They are one-way notifications. >>>> What you need is a server-initiated, multi-round-trip req/rsp >>>> exchanges -- to have a working EAP lower-layer. >>> >>> How do we get this in a model that you have described as: "PCP needs >>> keys to run, it triggers PANA to generate the keys, PANA does its job >>> and gives back the keys, PCP runs with the keys. " Won't this notion >>> (of server-initiated messages) need to be integrated into the API >>> between PCP and PANA somehow? When would these messages ever happen in >>> the PCP context? >>> >> >> Whether the client-side or the server-side initiated the re-auth, >> EAP/PANA is executed and new security association is generated. The new >> parameters are stored in the data structures where the PCP client picks >> them up next time it needs to send a request. >> >> Alper >> >> >> >> >> >>> Margaret >>> >>> >> > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From hartmans@painless-security.com Wed Sep 19 08:45:07 2012 Return-Path: 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 D9D6D21F8705 for ; Wed, 19 Sep 2012 08:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.383 X-Spam-Level: **** X-Spam-Status: No, score=4.383 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 WHNXQ1cc+A5a for ; Wed, 19 Sep 2012 08:45:07 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7255221F86F7 for ; Wed, 19 Sep 2012 08:45:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A4025202A9; Wed, 19 Sep 2012 11:44:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5AA524149; Wed, 19 Sep 2012 11:44:36 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <5059DAD7.2030507@toshiba.co.jp> Date: Wed, 19 Sep 2012 11:44:36 -0400 In-Reply-To: <5059DAD7.2030507@toshiba.co.jp> (Yoshihiro Ohba's message of "Wed, 19 Sep 2012 23:46:47 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Side-by-side or nested protocols X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:45:08 -0000 Yoshihiro> I suggest taking a look at the open source Yoshihiro> implementations that I pointed and Sam analyzed, and send Yoshihiro> comments to this list as Sam did. You would have some Yoshihiro> points, and your comments will be valuable to improve the Yoshihiro> quality of the open source implementations, I couldn't agree more. We've had a lot of discussion, but ultimately we need to hear more from PCP implementors. From dthaler@microsoft.com Wed Sep 19 14:54:55 2012 Return-Path: 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 F198621E80BC for ; Wed, 19 Sep 2012 14:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.038 X-Spam-Level: X-Spam-Status: No, score=-104.038 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 2UUhMeU5uDzR for ; Wed, 19 Sep 2012 14:54:55 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD8D21E80BB for ; Wed, 19 Sep 2012 14:54:52 -0700 (PDT) Received: from mail2-am1-R.bigfish.com (10.3.201.238) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 21:54:50 +0000 Received: from mail2-am1 (localhost [127.0.0.1]) by mail2-am1-R.bigfish.com (Postfix) with ESMTP id EE63B1A01AF for ; Wed, 19 Sep 2012 21:54:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzc85fh4015Izz1202h1d1ah1d2ahzz1033IL172d07h17326ah8275bh8275dh17598diz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh1155h) Received-SPF: pass (mail2-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail2-am1 (localhost.localdomain [127.0.0.1]) by mail2-am1 (MessageSwitch) id 1348091688266735_29646; Wed, 19 Sep 2012 21:54:48 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.235]) by mail2-am1.bigfish.com (Postfix) with ESMTP id 32F1320064 for ; Wed, 19 Sep 2012 21:54:48 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 21:54:47 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 19 Sep 2012 21:54:43 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0318.003; Wed, 19 Sep 2012 14:54:43 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Call for slides for Friday's interim meeting Thread-Index: Ac2WqZnbzyCdXYg8TKaVtsV/xLfahA== Date: Wed, 19 Sep 2012 21:54:42 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7BE7C7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7BE7C7TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] Call for slides for Friday's interim meeting X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 21:54:56 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7BE7C7TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've posted the agenda and dialin info at http://www.ietf.org/proceedings/interim/2012/09/21/pcp/proceedings.html if you click on Agenda at the top. (I'm not sure what the meeting materials link is but the same content shoul= d be there too if someone can find it). If you want to present something on the security topic, please send me slid= es. Thanks, -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B7BE7C7TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve posted the agenda and dialin info at=

http://www.ietf.org/proceedings/interim/201= 2/09/21/pcp/proceedings.html

if you click on Agenda at the top.

(I’m not sure what the meeting materials link = is but the same content should be there too if someone can find it).

 

If you want to present something on the security top= ic, please send me slides.

 

Thanks,

-Dave

--_000_9B57C850BB53634CACEC56EF4853FF653B7BE7C7TK5EX14MBXW604w_-- From dthaler@microsoft.com Wed Sep 19 15:14:14 2012 Return-Path: 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 E6AE111E808E for ; Wed, 19 Sep 2012 15:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.716 X-Spam-Level: X-Spam-Status: No, score=-103.716 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 cipmWkWNVHnh for ; Wed, 19 Sep 2012 15:14:12 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1882C11E8099 for ; Wed, 19 Sep 2012 15:14:12 -0700 (PDT) Received: from mail80-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 22:14:11 +0000 Received: from mail80-va3 (localhost [127.0.0.1]) by mail80-va3-R.bigfish.com (Postfix) with ESMTP id 32F0BE022E for ; Wed, 19 Sep 2012 22:14:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I617I15bfKc85fhd6eahd6f1izz1202h1d1ah1d2ahz31iz1033IL17326ah8275bh8275dh5eeeKz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh1155h) Received-SPF: pass (mail80-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail80-va3 (localhost.localdomain [127.0.0.1]) by mail80-va3 (MessageSwitch) id 1348092848861699_12769; Wed, 19 Sep 2012 22:14:08 +0000 (UTC) Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.249]) by mail80-va3.bigfish.com (Postfix) with ESMTP id C509160238 for ; Wed, 19 Sep 2012 22:14:08 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 22:14:07 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 19 Sep 2012 22:14:05 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 19 Sep 2012 15:14:04 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0318.003; Wed, 19 Sep 2012 15:14:04 -0700 From: Dave Thaler To: "'pcp@ietf.org'" Thread-Topic: WebEx info for Friday's interim meeting Thread-Index: Ac2V8EF1GP7J1iQCTiCLRsqinh7xJwAw4lOw Date: Wed, 19 Sep 2012 22:14:04 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7BE885@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B7BB57F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7BB57F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7BE885TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] WebEx info for Friday's interim meeting X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 22:14:15 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7BE885TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The previous email below contained a typo where it incorrectly stated the i= nterim was at 07:30 PDT. The correct time, as originally announced, is 07:00 PDT (GMT-0= 7:00). -Dave From: Dave Thaler Sent: Tuesday, September 18, 2012 3:54 PM To: pcp@ietf.org Subject: WebEx info for Friday's interim meeting I will also post this on the wiki but in the meantime... Connection information is below. -Dave Topic: PCP Interim Meeting Date: Friday, September 21, 2012 Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Num= ber: 304 269 309 Password: pcp ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D203266498&UID= =3D486507482&PW=3DNYmQwMDU2YjVj&RT=3DMiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: pcp 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Global call-in numbers: https://ciscosales.webex.com/ciscosales/globalcalli= n.php?serviceType=3DMC&ED=3D203266498&tollFree=3D1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:304 269 309 --_000_9B57C850BB53634CACEC56EF4853FF653B7BE885TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The previous email bel= ow contained a typo where it incorrectly stated the interim was at

07:30 PDT.  = The correct time, as originally announced, is 07:00 PDT (GMT-07:00).<= /o:p>

 

-Dave

 

From: Dave Tha= ler
Sent: Tuesday, September 18, 2012 3:54 PM
To: pcp@ietf.org
Subject: WebEx info for Friday's interim meeting

 

I will also post this on the wiki but in the meantim= e…

Connection information is below.

 

-Dave

 

Topic: PCP Interim Meeting

Date: Friday, September 21, 2012

Time: 7:00 a= m, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 304 269= 309

Password: pcp

 

-------------------------------------------------= ------

To join the meeting online(Now from mobile device= s!)

-------------------------------------------------= ------

1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D203266498&UID=3D4865= 07482&PW=3DNYmQwMDU2YjVj&RT=3DMiM0

2. If requested, enter your name and email addres= s.

3. If a password is required, enter the meeting p= assword: pcp

4. Click "Join".

5. If the meeting includes a teleconference, foll= ow the instructions that appear on your screen.

 

-------------------------------------------------= ------

To join the audio conference only

-------------------------------------------------= ------

To receive a call back, provide your phone number= when you join the meeting, or call the number below and enter the access c= ode.

Call-in toll-free number (US/Canada): +1-866-= 432-9903

Call-in toll number (US/Canada): +1-408-525-6= 800

Global call-in numbers: https://ciscosales.webex.com/ciscosales/globalcallin.php?serviceType=3DMC&a= mp;ED=3D203266498&tollFree=3D1

 

Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

 

Access code:304 269 309

 

--_000_9B57C850BB53634CACEC56EF4853FF653B7BE885TK5EX14MBXW604w_-- From alper.yegin@yegin.org Thu Sep 20 01:45:33 2012 Return-Path: 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 97CC921F86FD for ; Thu, 20 Sep 2012 01:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OXrey7RNZeUY for ; Thu, 20 Sep 2012 01:45:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1F321F847D for ; Thu, 20 Sep 2012 01:45:32 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MHItv-1TIkys1xUB-00Du6r; Thu, 20 Sep 2012 04:45:30 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <70154AB6-F7B5-47B0-B721-811EA5DF9926@lilacglade.org> Date: Thu, 20 Sep 2012 11:45:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <97AF094F-ABD8-4B50-80B7-30D8E2F34567@yegin.org> References: <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> <70154AB6-F7B5-47B0-B721-811EA5DF9926@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:VQcijeVsWmWsMPF7dCisVezDtqydB+CC1gh1yQg+U0F enBEVJHtPFa+dYEpvuZO4HVj/7RWXbHDr/v17+aLascvGCOXu+ UaIfQN/5jUSIVIDLZEr9Y1uuUpqGmiuzfZL1/XLDxnJBOUmOeB qq4ohseFQcEcYKDhhplGQvCtrg/k8Yg9vXlps+k8w7Bp+xM7lU Nk5KHZr7+w3WtqK1YmY9Tih5/bDy+f82tW5kKsKADvplqxGR2b ZEehT9pM5opJ5drwl5VfRPvglK42W2V1Cf2+zNdcMmw1G140gG LhCmr1EkadqUjq6dDaitxewaMZUkVq1D0izmnoiNcjvfduzx0H 0R8KuvJHqCqVePIMoqPUA+fdkbArNqMuj8W94uAKogskkxA4VA VeKsesRCDdhAA== Cc: pcp@ietf.org Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:45:33 -0000 Hi Margaret, On Sep 19, 2012, at 1:11 PM, Margaret Wasserman wrote: >=20 > Hi Alper, >=20 > On Sep 17, 2012, at 5:24 AM, Alper Yegin wrote: >> Yep, they are implementing "EAP lower layers". "EAP-over-UDP/PCP" is = an EAP lower-layer and it'll have the same thing (once people realize = it's more than defining a EAP container to qualify as a "working" and = "compliant" EAP lower layer). >=20 > You have mentioned this several times, but you haven't provided any = specifics. What do you think is missing from the PCP-specific approach, = as document, that would need to be added to make it a "working" and = "compliant" EAP lower layer? Is there an RFC that specifies the = requirements that the PCP-Specific approach is failing to meet?=20 The major missing piece is the support for EAP re-authentication. It's = totally omitted. Security considerations section is too light on content. Please see = PANA's. We need to see a thorough analysis to conclude that the design = is complete. For example, there's a mention of DoS resilience, but it's = not sufficient. Please refer back to PANA to see how DoS resilience is = achieved with EAP lower-layer. Also, I don't see the message validity checks (again, see PANA). It's = not possible to get a standard state machine w/o that (either in a = dedicated section like in RFC 5191, or captured in a distributed way in = the document). Alper From alper.yegin@yegin.org Thu Sep 20 01:49:11 2012 Return-Path: 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 CC71621F84C5 for ; Thu, 20 Sep 2012 01:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6CHy4A+2jwWb for ; Thu, 20 Sep 2012 01:49:11 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id EFDF321F84A1 for ; Thu, 20 Sep 2012 01:49:10 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M2Kui-1TX7GR34qq-00rvIv; Thu, 20 Sep 2012 04:49:07 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Thu, 20 Sep 2012 11:48:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F36817E-6F17-4B59-AF9B-CD97EACF2726@yegin.org> References: To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:I7IuJfna5crB3J/CzgtHXiGCn6nyqFxbdXri6+rH6rP CPC+9uGa31YxFR8maQiYHFUhlJZX4AzEpoO+KZwivguwhWHe+x tKK7F9iHESPExZBb6dOvGQS98Z1AED2dUBbtOUX2T6j63sFf3f hu18xMsUFmq9Z6opRTdoZJigiBwp2HYPSp3uG0Qbj4tHHWAH6U MgqaJAf5dVA5xMzQ7qxvHL3JsaHsxFSnXBOJo8IzGJ8pg8O+no QKg0rPwYJdS9JoJQjI3HdQ1i5lwtqJ5cHOIkgEjb0UN2wM4TwX niAdcCjRzHqjtg4Tq5iYqJPrGIWnz4TjA+JLeHmyZbRyURnzOw iLAyu/pW5N6m5t2FvgNqANRDAzxju71VwHnmG4jtPruG7GTqZk gV14SgS7r13ag== Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:49:11 -0000 Hi Reinaldo, >>> On Sep 18, 2012, at 3:30 AM, Alper Yegin wrote: >>>> But more interestingly, you said you are not aware of any PANA >>>> implementations in production. >>>> As we said before, PANA is adopted into Zigbee Smart Energy Profile = 2.0 >>>> And it passed several interop events, with 10 implementations. >>>=20 >>> Do you actually think that any nodes that implement SEP 2.0 will >>> implement PCP? >>>=20 >>=20 >> First, let's recognize different types of "re-use": >> - spec re-use >> - source code re-use >> - binary re-use >>=20 >> Your question is specifically about the last one. I think the answer = to >> the first two are clear, and that by itself goes a long way. >=20 >=20 > I do not think it is clear. The devices implementing PCP Server = (routers, > FW, CGNs, CPEs, etc) will most likely not be able to reuse source code > from Zigbee. There are threading considerations, 64 vs. 32 bit, memory > management, configuration, events. The list goes on and on. My = experience > with protocol code reuse between such different platforms is not very = rosy. >=20 There may be platforms that cannot share the same code. Yes, I = acknowledge that. But, that's not the norm, but an exception. >=20 >>=20 >> Even binary re-use is a possibility, like Yoshi explained, and also >> considering the possibility of integrated gateways. >=20 >=20 > Like getting PANA binary from Zigbee and running on a CGN, CPE/High = end > Firewall running on a different NPU type without rewriting almost from > scratch, recompilation, integration with CLI, debug, etc ? Please = excuse > my skepticism when I doubt this. But to be fair, please point me to = your > best candidate for this reuse and I will see if we can look into it if = WG > thinks it will help the process. >=20 I was referring to "integrated gateways". Broadband modem implementing = Zigbee as well.=20 They are on the same platform. Alper >=20 >>=20 >>=20 >>> [For those unfamiliar with Zigbee SEP 2.0, it is one of the = standards >>> (the only IP-based one, I think) proposed for use in the Smart Grid, >>> specifically for appliances, sensors and other embedded devices to >>> integrate with a home energy management system (EMS) and/or electric >>> meter (Smart Meter) on the in-home side of the Smart Energy = universe. >>> Implementations of SEP 2.0 are most often provided in ASICs, for >>> integration into embedded devices with very limited system = requirements. >>> These devices run on a dedicated Zigbee networks within the home, = and >>> do not generally communicate outside the home, at all.] >>>=20 >>>> Yes, it could be tricky, if we had a funky relationship between the >>>> two protocols. But in this case, it's a clean separation. PCP needs >>>> keys to run, it triggers PANA to generate the keys, PANA does its = job >>>> and gives back the keys, PCP runs with the keys. This is how = separate >>>> "key management" works. Natural fit. >>>=20 >>> The success case in the side-by-side approach appears to work very >>> smoothly, it is the error cases that I am more concerned about. >>=20 >> Which specific error cases? You raised one about auth capability = mismatch >> and I already responded to that. >>=20 >>=20 >>> Also, you haven't explained how you would deal with all of the = things >>> you list below... If PCP has a simple request/response API with = PANA, >>> how are things like "asynchronous requests" handled in that model? = What >>> is an "asynchronous request" in this context and when/why would it >>> happen, BTW? I understand that, in PANA, it is possible for network >>> access to be renegotiated, or for Ip addresses to be reallocated. = There >>> is no equivalent notion in PCP, though. >>>=20 >>=20 >> EAP re-authentication can be initiated by either party at any time. = We >> need to support that. >>=20 >>>> But, if we embed one protocol inside the other, then you have to >>>> combine the state machines. And that combining is not a simple jump >>>> back and forth like in the above case. More specifically, within = the >>>> PCP state machine, now you have to account for server-side >>>> retransmissions, server-side asynchronous requests, etc. >>>=20 >>> You keep claiming that there will be problems with "combining the = state >>> machines" of PCP and PANA in the encapsulation case that aren't = there in >>> the side-by-side case, but I'm still not sure what you mean by this. >>> Could you give a concrete example? >>=20 >> Please see my email with EAP-over-PCP subject line. As you see, the = state >> machines and flows of PCP and EAP-over-PCP are not compatible. If you = try >> to fit the latter into the former, it won't work -- incompatible. = Exact >> same issue with EAP-over-DHCP. I (naively?) assumed you'd not want to >> impact the PCP design hence this compatibility issue is a problem. >>=20 >>=20 >>>=20 >>>>> PCP is capable of sending unsolicited messages (both multicast and >>>>> unicast). So, we are good here. >>>>=20 >>>> You are referring to "announcements" right? >>>> They are one-way notifications. >>>> What you need is a server-initiated, multi-round-trip req/rsp >>>> exchanges -- to have a working EAP lower-layer. >>>=20 >>> How do we get this in a model that you have described as: "PCP = needs >>> keys to run, it triggers PANA to generate the keys, PANA does its = job >>> and gives back the keys, PCP runs with the keys. " Won't this = notion >>> (of server-initiated messages) need to be integrated into the API >>> between PCP and PANA somehow? When would these messages ever happen = in >>> the PCP context? >>>=20 >>=20 >> Whether the client-side or the server-side initiated the re-auth, >> EAP/PANA is executed and new security association is generated. The = new >> parameters are stored in the data structures where the PCP client = picks >> them up next time it needs to send a request. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>> Margaret >>>=20 >>>=20 >>=20 >=20 From alper.yegin@yegin.org Thu Sep 20 02:02:06 2012 Return-Path: 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 111E921F8745 for ; Thu, 20 Sep 2012 02:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 h-82n6PhWdHM for ; Thu, 20 Sep 2012 02:02:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC721F8743 for ; Thu, 20 Sep 2012 02:02:05 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LdpDn-1TwEnm1rmt-00j0MU; Thu, 20 Sep 2012 05:02:03 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_8BFD6915-7077-4B41-9DF3-226663DBDC9C" From: Alper Yegin In-Reply-To: <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> Date: Thu, 20 Sep 2012 12:01:43 +0300 Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:4FgYT4Ass85MSW7ljypaBgFCT9UVj1bINCB54o8cgHP pjBDZwFVrNugEkLsEVZT8PvMavET84/zXfMEPbdtmJhtab/4vX 9pp3gj0gsYrMEfhIrT3iUw5OG7mfSODW5T45lt5peqvZ0gd0Es GDUovVVLZHO4v/tWAMJrbo0YOqZroeY9nPOmFapcP3W6MeqgoG 52sA6eXB84VDE3q1zyaYjsq1u8rRS9I1ZfGpfP+s0bY+MdMod/ 4+Df0Uce2+60FZ5MxN1baRKrulSeNgdw3wsyzxMjwqZYwrp6TU wklBarFbDSIPXkWGDIS9UxQiwB9fBItpWDoACVopaxKkEKOXC/ ZL2ByxUj6sUtuzQeyy70t+a55AnEa3xUWxFWZcsgHpOCZyQkRi Ycj6VwUlyL3ig== Cc: "'pcp@ietf.org'" Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 09:02:06 -0000 --Apple-Mail=_8BFD6915-7077-4B41-9DF3-226663DBDC9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> I don't understand how this works. >> EAP authenticator performs rexmits.=20 >> So, if it does not get a response, it'll keep rexmitting. So, how can = you achieve "server will never generate an unsolicited request"? >=20 > A retransmission is not an unsolicited request... I'm not sure what = you mean by this. If the EAP authenticator does not receive a response on time, it'd = re-xmit the EAP request. Which in turn will be transmitted by the PCP server to the PCP client. That transmission is not "solicited by the PCP client". >=20 >> And, furthermore, there'd be EAP re-authentication which can be = initiated by the client or server. This is another reason for having to = support server-side requests. >=20 > Why do you think that we need to support EAP re-authentication?=20 >=20 EAP re-authentication is one of the EAP events, and any EAP lower-layer = has to support that. Otherwise, what? Your sessions have infinite lifetime? Authorization = never changes? Never need to re-key? Never need to challenge the = end-point again? These are the things that call for "re-authenticaiton", and why EAP has = that, and why EAP lower-layers need to support that. Alper > Margaret >=20 >=20 --Apple-Mail=_8BFD6915-7077-4B41-9DF3-226663DBDC9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I don't = understand how this works.
EAP = authenticator performs rexmits.
So, if it does not get a response, it'll keep rexmitting. = So, how can you achieve "server will never generate an unsolicited = request"?

A retransmission is not an unsolicited = request...  I'm not sure what you mean by = this.

If the EAP authenticator = does not receive a response on time, it'd re-xmit the EAP = request.
Which in turn will be transmitted by the PCP server = to the PCP client.
That transmission is not "solicited by the = PCP client".


And, furthermore, there'd be EAP re-authentication which = can be initiated by the client or server. This is another reason for = having to support server-side requests.

Why do you = think that we need to support EAP re-authentication? =


EAP re-authentication is = one of the EAP events, and any EAP lower-layer has to support = that.
Otherwise, what? Your sessions have infinite lifetime? = Authorization never changes? Never need to re-key? Never need to = challenge the end-point again?
These are the things that call = for "re-authenticaiton", and why EAP has that, and why EAP lower-layers = need to support = that.

Alper







Margaret



= --Apple-Mail=_8BFD6915-7077-4B41-9DF3-226663DBDC9C-- From alper.yegin@yegin.org Thu Sep 20 02:39:11 2012 Return-Path: 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 B7BDC21F8745 for ; Thu, 20 Sep 2012 02:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.187 X-Spam-Level: X-Spam-Status: No, score=-102.187 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, USER_IN_WHITELIST=-100] 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 5PIUJ6WHIlQP for ; Thu, 20 Sep 2012 02:39:10 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7551121F873B for ; Thu, 20 Sep 2012 02:39:10 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MHIpn-1TIk4x260h-00E5Th; Thu, 20 Sep 2012 05:39:09 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_27A01A29-7DE3-4BA7-A249-B26784551B00" From: Alper Yegin In-Reply-To: Date: Thu, 20 Sep 2012 12:38:50 +0300 Message-Id: <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:Bosp3KH0SK/WrR/5BnlZ4nJ8ruqkTeFpLV42mt7VfLc 1lpNZUWEz1S4096XM/yX9ZcQoUnZ0y5ATw4Xl1X53hIRYdJbnY RbhhMJDG/zAza7ld028ruut7Q+HBVqGXZxEiQcB+m/q5orm/WF RzjIAUTwJHHRE+7Z7l+mH+1Lna+CNRZQzMHQMURhnhf7RDuCOt WoaPf7iFTTrLob88SBgAhLGJNc2+tR31gQNBCLR+GlxG5UycFN 0//bYX4IMkx0ZF/h2P/Ro5F7PIMGOhrg2aXkfzvIoNkwgJci8e HE9AFFkVro0kgdzj6tW9Ye7jdNN7V+omRH3dMKCnEgXywv22YQ NsD7sztSahNxpGdDSZXiuJkGRYihFvykcSUEGBy/R0HEyyQuV6 BuNo78p2GAKgQ== Cc: "'pcp@ietf.org'" Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 09:39:11 -0000 --Apple-Mail=_27A01A29-7DE3-4BA7-A249-B26784551B00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> Depending on what's easy for PCP implementations we have a number >>> of options. >>>=20 >>> In RFC 3748 the conversation is conceptually server driven. >>> However, there is typically a client (lower layer) indication to >>> get things started. >>>=20 >>> However, the only reason that the conversation is server-driven >>> iss retransmissions. If you take a look at section 2 of RFC 3748 >>> you note that the protocol is lockstep. The server cannot send a >>> new request until the client has responded to the previous one. >>> If you take a look at section 4.3, a lower layer may sent the >>> retransmission timeout to infinite. In this mode, the server will >>> never generate an unsolicited request. So, it's entirely >>> possible to view things as a client-server protocol with >>> client-driven retransmissions if that makes things easier for PCP >>> implementations. >>>=20 >=20 > Alper>I don't understand how this works. > Alper> EAP authenticator performs rexmits. So, if it does not get = a > Alper> response, it'll keep rexmitting. So, how can you achieve > Alper> "server will never generate an unsolicited request"? >=20 > There are three aspects to this: why does it work in practice, why = does > it comply with the spec, and why do I think it's been reviewed > adequately to suggest it? >=20 > For the first, EAP libraries tend to have a way to ignore retransmits > or set the retransmission timeout to infinite. You mean the "EAP layer"?=20 When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer.=20 Only when run over a reliable EAP lower layer, the EAP layer sets the = timeout to infinity. So, whether the rexmit is handled by the EAP layer, or the EAP lower = layer, the PCP server will be sending retransmissions in your case. > Consider what happens in an AAA server. There, your EAP server cannot > (and is not supposed to) handle retransmits. > RADIUS at least is a lock-step protocol. Ignoring things like COA, Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an unsolicited = message, more specifically for starting EAP re-authentication. So, let's not ignore that. > a > RADIUS server cannot send an unsolicited response to a client. > So any EAP server library basically has to have a way to disable > retransmits. > I guess it's possible that you could have a passthrough authenticator > library that doesn't pull this off. Rexmit is the responsibility of the "EAP passthru authenticator". > IN practice we've not run into this problem; see below for why. >=20 > Also, as I understand it (without close reading) the IKEv2 EAP support > works this way as well. >=20 > So, why does it comply with the spec? > Take a look at RFC 3748 section 4.3. That section points out a lower > layer can set the retransmit timeout to infinite if it is reliable > itself. >=20 True. But see my explanations above. > Why do I think the whole idea of assuming you'll never get an > unsolicited server request has been adequately reviewed? It's part of > draft-ietf-abfab-gss-eap, which has already been approved and is = waiting > publication. I've personally walked through what we were doing with > Bernard; I know Joe is familiar with the work enough that he = understands > our state machine constraints. Klaas is one of the chairs; he also has = a > lot of EAP experience. Josh Howlett, my co-author has many more years = of > EAP experience than I do. So, I believe that this idea has received > adequate review that if I were somehow misreading the base EAP spec we > would have noticed it. >=20 Sam, you are claiming "it's entirely possible to view things as a = client-server protocol with client-driven retransmissions if that makes = things easier for PCP implementations." I don't see how it works from your technical explanations here.=20 You are referring to a past work, which I was not involved. Unless I go = back and read that spec, and email archives, I cannot know why/how/what = happened, and if it's applicable to here. So, why don't you just explain us how it'd work, better yet show us on = your document. Bottom line is,=20 EAP is server driven. PCP is client driven.=20 How do you stack them up against each other? >=20 > Alper> And, furthermore, there'd be EAP re-authentication which can > Alper> be initiated by the client or server. This is another reason > Alper> for having to support server-side requests. >=20 >=20 > I'm not entirely sure what you're talking about when you say EAP > re-authentication. > Do you mean the EAP re-authentication protocol (the one done in = HOKEY?) No, not that. That's just an optimized re-authentication. Re-authentication is executing EAP again. > The base EAP spec mentions re-authentication once or twice but does = not > define it. > My best reading of that text is that they simply mean there can be = later > EAP conversations if you want to access a new resource or the like, or > the network wants to re-key, or prove fresh access to tokens or > whatever. >=20 You got it. >=20 > When you look at the peer state machine in RFC 4137, you note that the > success state is a final state. > It's going to require lower layer interactions to get out of that = state. > If you look at the commen open-source supplicants (all I have access = to) > you see that tends to be how people implement things. > You expect a disassociation or something else to trigger new > authentication. You want service continuity. So, you don't use disassociation. EAP = re-authentication is performed while the existing EAP session is still = good and other layers are still using the unexpired security = association. > And when that happens, yes, depending on who's doing the trigger and > what's going on, the first *EAP* message may be from the server. >=20 There you go. > In our proposal, PCP is the same way. A server can throw away a = session > and give a client an error that they must authenticate again if it = wants > an EAP exchange. This is intended to deal with wanting to expire > sessions or servers that lose state. However it also deals with a > server wanting to confirm freshness, or getting a re-authentication > demand via some complex AAA infrastructure that seems unlikely to be > used with PCP in practice. First of all, this is not in your document.=20 Secondly, this is a bad design. As soon as the network side decides to = re-auth, it's should be able to do so. It shouldn't have to wait for the = client to make the next contact. Alper --Apple-Mail=_27A01A29-7DE3-4BA7-A249-B26784551B00 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Depending on what's easy for PCP = implementations we have a = number
of options.

In RFC 3748 the conversation is = conceptually server driven.
However, there is typically a = client (lower layer) indication = to
get things = started.

However, the only reason that = the conversation is = server-driven
iss retransmissions. If you take = a look at section 2 of RFC 3748
you note that the protocol is = lockstep. The server cannot send = a
new request until the client has responded to the previous = one.
If you take a look at section 4.3, a lower layer may sent = the
retransmission timeout to infinite. In this mode, the = server will
never generate an unsolicited = request.  So, it's = entirely
possible to view things as a = client-server protocol with
client-driven retransmissions if = that makes things easier for = PCP
implementations.


Alper>I don't = understand how this works.
   Alper> EAP = authenticator performs rexmits.  So, if it does not get a
=    Alper> response, it'll keep rexmitting. So, how can = you achieve
   Alper> "server will never generate = an unsolicited request"?

There are three aspects to this: why = does it work in practice, why does
it comply with the spec, and why = do I think  it's been reviewed
adequately to suggest = it?

For the first, EAP libraries tend to have a way to ignore =  retransmits
or set the retransmission timeout to = infinite.

You mean the "EAP = layer"? 

  When run over a reliable lower layer =
(e.g., EAP over ISAKMP/TCP, as
   within [PIC]), the authenticator retransmission timer SHOULD =
be set
   to an infinite value, so that retransmissions do not occur at the EAP
   layer.

Only when run over a = reliable EAP lower layer, the EAP layer sets the timeout to = infinity.
So, whether the rexmit is handled by the EAP layer, = or the EAP lower layer, the PCP server will be sending retransmissions = in your case.


Consider what happens in an AAA server. There, your = EAP server cannot
(and is not supposed to) handle = retransmits.
RADIUS at least is a lock-step protocol. Ignoring things = like COA,

Ah, "ignoring CoA". CoA = is the RADIUS' tool to generate an unsolicited message, more = specifically for starting EAP re-authentication.
So, let's not = ignore that.


a
RADIUS server cannot send an unsolicited = response to a client.
So any EAP server library basically has to have = a way to disable
retransmits.
I guess it's possible that you could = have a passthrough authenticator
library that doesn't pull this = off.

Rexmit is the = responsibility of the "EAP passthru = authenticator".


IN = practice we've not run into this problem; see below for = why.

Also, as I understand it (without close reading) the IKEv2 = EAP support
works this way as well.

So, why does it comply = with the spec?
Take a look at RFC 3748 section 4.3. That section = points out a lower
layer can set the retransmit timeout to infinite = if it is = reliable
itself.


True. = But see my explanations above.


Why do I think the whole idea of assuming you'll = never get an
unsolicited server request has been adequately reviewed? = It's part of
draft-ietf-abfab-gss-eap, which has already been = approved and is waiting
publication. I've personally walked through = what we were doing with
Bernard; I know Joe is familiar with the work = enough that he understands
our state machine constraints. Klaas is = one of the chairs; he also has a
lot of EAP experience. Josh Howlett, = my co-author has many more years of
EAP experience than I do. =  So, I believe that this idea has received
adequate review that = if I were somehow misreading the base EAP spec we
would have noticed = it.


Sam, you are claiming = "it's entirely possible to view things as a client-server protocol = with client-driven retransmissions if that makes things easier for = PCP implementations."
I don't see how it works from your = technical explanations here. 
You are referring to a past = work, which I was not involved. Unless I go back and read that spec, and = email archives, I cannot know why/how/what happened, and if it's = applicable to here.

So, why don't you just = explain us how it'd work, better yet show us on your = document.

Bottom line is, 
EAP = is server driven.
PCP is client driven. 
How do = you stack them up against each = other?



   Alper> And, furthermore, = there'd be EAP re-authentication which can
=    Alper> be initiated by the client or server. This = is another reason
   Alper> for having to support = server-side requests.


I'm not entirely sure what you're = talking about when you say = EAP
re-authentication.
Do you mean the EAP re-authentication protocol (the = one done in HOKEY?)

No, not = that. That's just an optimized = re-authentication.
Re-authentication is executing EAP = again.

The base EAP spec = mentions re-authentication once or twice  but does not
define = it.
My best reading of that text is that they simply mean there can = be later
EAP conversations if you want to access a new resource or = the like, or
the network wants to re-key, or prove fresh access to = tokens or
whatever.


You = got it.


When you look at the = peer state machine in RFC 4137, you note that the
success state is a = final state.
It's going to require lower layer interactions to get = out of that state.
If you look at the commen open-source supplicants = (all I have access to)
you see that tends to be how people implement = things.
You expect a disassociation or something else to trigger = new
authentication.

You = want service continuity. So, you don't use disassociation. EAP = re-authentication is performed while the existing EAP session is still = good and other layers are still using the unexpired security = association.


And when that happens, yes, depending on who's doing = the trigger and
what's going on, the first *EAP* message may be from = the server.


There you = go.

In our proposal, PCP is the = same way.  A server can throw away a session
and give a client = an error that they must authenticate again if it wants
an EAP = exchange.  This is intended to deal with wanting to = expire
sessions or servers that lose state.  However it also = deals with a
server wanting to confirm freshness, or getting a = re-authentication
demand via some complex AAA infrastructure that = seems unlikely to be
used with PCP in = practice.

First of all, this is not = in your document. 
Secondly, this is a bad design. As = soon as the network side decides to re-auth, it's should be able to do = so. It shouldn't have to wait for the client to make the next = contact.

Alper



= --Apple-Mail=_27A01A29-7DE3-4BA7-A249-B26784551B00-- From margaretw42@gmail.com Thu Sep 20 03:28:32 2012 Return-Path: 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 7C16221F84AF for ; Thu, 20 Sep 2012 03:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XryJtARNOjMj for ; Thu, 20 Sep 2012 03:28:31 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E12A121F84FC for ; Thu, 20 Sep 2012 03:28:25 -0700 (PDT) Received: by qcac10 with SMTP id c10so1819886qca.31 for ; Thu, 20 Sep 2012 03:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DBU2aQa7mVsDTW2gPfWhwQMzjmwp8omLkn7s/mLsGBo=; b=S1Ywk2QZ8q7bP4WfCHYnmBSmhOsBGltTvM75JAr7LuV22tHiyYK2vwsdbwsVyoBl+w pXB0szNBJhr51fWLxLV6c7YnxR1ljBb7cEhhh7VYTadmj4i5XsFuj/0Dr6xmv+tqOS00 BjHJ0fpsGKeClg4XcG3Zu2vm+qnCZeEoHVVGTTAy61GogppDrwARU65bBl88j86YkcS4 uuKhp7DoU7K+cHRSXbjc8GuUzZOHyH+9NTY9bkaP6S3P+rFAD5nrzJFK7R+H/InPzLEy cXFPqco/ZBkJofrt4Hca2PJEWArXdlT7zVdir0KJozim5PaoFNTUZmRQiwB67yDLb8dn 8NLg== Received: by 10.224.183.146 with SMTP id cg18mr3754514qab.7.1348136905267; Thu, 20 Sep 2012 03:28:25 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id j2sm7655234qaj.14.2012.09.20.03.28.22 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 03:28:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> Date: Thu, 20 Sep 2012 06:28:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: "'pcp@ietf.org'" Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 10:28:32 -0000 Hi Alper, >> Consider what happens in an AAA server. There, your EAP server cannot >> (and is not supposed to) handle retransmits. >> RADIUS at least is a lock-step protocol. Ignoring things like COA, >=20 > Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an unsolicited = message, more specifically for starting EAP re-authentication. > So, let's not ignore that. Have you answered my question about why you think EAP re-authentication = is needed for PCP, or even applies to PCP? This is an optional part of = EAP, and it's my understanding that it isn't widely used... =20 Also if you do support re-authentication (after telling me what it would = mean for PCP), how do you avoid exposing this paradigm to PCP, = regardless of the which of the three you use? It is no more aligned = with a request-response protocol for an API to wake it up asynchronously = and do re-authentication than it is for that to happen in a PCP message. This _could_ be an argument for not using EAP, I suppose, but I don't = think there has been much dissent about using an EAP-based mechanism. I = certainly don't see why we couldn't make the same simplifying = assumptions in PCP that are made in GSS-EAP. If using PANA will stand = in the way of that, maybe that's a reason not to use PANA? Margaret >=20 >=20 >> a >> RADIUS server cannot send an unsolicited response to a client. >> So any EAP server library basically has to have a way to disable >> retransmits. >> I guess it's possible that you could have a passthrough authenticator >> library that doesn't pull this off. >=20 > Rexmit is the responsibility of the "EAP passthru authenticator". >=20 >=20 >> IN practice we've not run into this problem; see below for why. >>=20 >> Also, as I understand it (without close reading) the IKEv2 EAP = support >> works this way as well. >>=20 >> So, why does it comply with the spec? >> Take a look at RFC 3748 section 4.3. That section points out a lower >> layer can set the retransmit timeout to infinite if it is reliable >> itself. >>=20 >=20 > True. But see my explanations above. >=20 >=20 >> Why do I think the whole idea of assuming you'll never get an >> unsolicited server request has been adequately reviewed? It's part of >> draft-ietf-abfab-gss-eap, which has already been approved and is = waiting >> publication. I've personally walked through what we were doing with >> Bernard; I know Joe is familiar with the work enough that he = understands >> our state machine constraints. Klaas is one of the chairs; he also = has a >> lot of EAP experience. Josh Howlett, my co-author has many more years = of >> EAP experience than I do. So, I believe that this idea has received >> adequate review that if I were somehow misreading the base EAP spec = we >> would have noticed it. >>=20 >=20 > Sam, you are claiming "it's entirely possible to view things as a = client-server protocol with client-driven retransmissions if that makes = things easier for PCP implementations." > I don't see how it works from your technical explanations here.=20 > You are referring to a past work, which I was not involved. Unless I = go back and read that spec, and email archives, I cannot know = why/how/what happened, and if it's applicable to here. >=20 > So, why don't you just explain us how it'd work, better yet show us on = your document. >=20 > Bottom line is,=20 > EAP is server driven. > PCP is client driven.=20 > How do you stack them up against each other? >=20 >=20 >>=20 >> Alper> And, furthermore, there'd be EAP re-authentication which = can >> Alper> be initiated by the client or server. This is another = reason >> Alper> for having to support server-side requests. >>=20 >>=20 >> I'm not entirely sure what you're talking about when you say EAP >> re-authentication. >> Do you mean the EAP re-authentication protocol (the one done in = HOKEY?) >=20 > No, not that. That's just an optimized re-authentication. > Re-authentication is executing EAP again. >=20 >> The base EAP spec mentions re-authentication once or twice but does = not >> define it. >> My best reading of that text is that they simply mean there can be = later >> EAP conversations if you want to access a new resource or the like, = or >> the network wants to re-key, or prove fresh access to tokens or >> whatever. >>=20 >=20 > You got it. >=20 >>=20 >> When you look at the peer state machine in RFC 4137, you note that = the >> success state is a final state. >> It's going to require lower layer interactions to get out of that = state. >> If you look at the commen open-source supplicants (all I have access = to) >> you see that tends to be how people implement things. >> You expect a disassociation or something else to trigger new >> authentication. >=20 > You want service continuity. So, you don't use disassociation. EAP = re-authentication is performed while the existing EAP session is still = good and other layers are still using the unexpired security = association. >=20 >=20 >> And when that happens, yes, depending on who's doing the trigger and >> what's going on, the first *EAP* message may be from the server. >>=20 >=20 > There you go. >=20 >> In our proposal, PCP is the same way. A server can throw away a = session >> and give a client an error that they must authenticate again if it = wants >> an EAP exchange. This is intended to deal with wanting to expire >> sessions or servers that lose state. However it also deals with a >> server wanting to confirm freshness, or getting a re-authentication >> demand via some complex AAA infrastructure that seems unlikely to be >> used with PCP in practice. >=20 > First of all, this is not in your document.=20 > Secondly, this is a bad design. As soon as the network side decides to = re-auth, it's should be able to do so. It shouldn't have to wait for the = client to make the next contact. >=20 > Alper >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From margaretw42@gmail.com Thu Sep 20 03:31:35 2012 Return-Path: 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 92EE721F84FC for ; Thu, 20 Sep 2012 03:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 dF9va-3P5otD for ; Thu, 20 Sep 2012 03:31:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0888321F84A7 for ; Thu, 20 Sep 2012 03:31:34 -0700 (PDT) Received: by qcac10 with SMTP id c10so1822101qca.31 for ; Thu, 20 Sep 2012 03:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UHQ3zvScfEnNAlxxVBAP78uPywOxa7VExZwF/ZQznd0=; b=VjNwbSCqkvXXBuMxTZRu62LBBgnFCv5HgYac+r8sNjtQ9gXBl+tPaaRmuZHZJtmI5o nbkhrohekG3aCdT5HfSTH37eYUFlX4XIrkz6gr5pnp2Kj1kPrbYwqsxnBYTny/krMhAb BrdA32aHoSR6Cns95av58aj6TO7XwZaqCgX173QOZM/3jf9TpvBunqjRNYewrSMuZiy7 FNDGLyF0xT8hFQiE+UjG/SiPqmvcpziyhTeX2G7ah2HQ0m+rDotyuAsYWhf6v+aRbTCV Lwll4OYDVXsOhoIdI5Nnrr9LLpHaUnBd/4XDohCaY+6GgfrxQVmDep+V6Oyz2umBikFg GUGA== Received: by 10.224.59.129 with SMTP id l1mr3428574qah.97.1348137094468; Thu, 20 Sep 2012 03:31:34 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id y18sm7666886qaa.15.2012.09.20.03.31.29 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 03:31:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <97AF094F-ABD8-4B50-80B7-30D8E2F34567@yegin.org> Date: Thu, 20 Sep 2012 06:31:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0036D504-A478-483D-9EF0-D58CDAAF5BEE@gmail.com> References: <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> <70154AB6-F7B5-47B0-B721-811EA5DF9926@lilacglade.org> <97AF094F-ABD8-4B50-80B7-30D8E2F34567@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 10:31:35 -0000 Hi Alper, On Sep 20, 2012, at 4:45 AM, Alper Yegin wrote: > The major missing piece is the support for EAP re-authentication. It's = totally omitted. See my other message about that. >=20 > Security considerations section is too light on content. Please see = PANA's. We need to see a thorough analysis to conclude that the design = is complete. For example, there's a mention of DoS resilience, but it's = not sufficient. Please refer back to PANA to see how DoS resilience is = achieved with EAP lower-layer. >=20 > Also, I don't see the message validity checks (again, see PANA). It's = not possible to get a standard state machine w/o that (either in a = dedicated section like in RFC 5191, or captured in a distributed way in = the document). Thanks for this feedback. I will take it into account, as appropriate, = depending on how we decide to go forward tomorrow. Margaret From margaretw42@gmail.com Thu Sep 20 04:09:22 2012 Return-Path: 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 C9E7E21F8751 for ; Thu, 20 Sep 2012 04:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 O-k0WvIPGn8M for ; Thu, 20 Sep 2012 04:09:22 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15EAF21F8778 for ; Thu, 20 Sep 2012 04:09:21 -0700 (PDT) Received: by qaec10 with SMTP id c10so272461qae.10 for ; Thu, 20 Sep 2012 04:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ltRXLjR1uX4ajAnrnV7gmpvnswkai4xgDvGuggLkhsA=; b=hkuh+GCl9vatW5W0OjCEsFMQlCFNfWoYzh3WY2npFhwU8/VJlNOjEZHukIONBEbmxS 7iGTnihnCVDwTy5aVWKpJBqaEqi9ZMBUysl9ARU/Fq80eChZYR3HI1ecaIrTfIDi1Um+ 7LYeKJDFGWz0lDQhZXvL2oegk4yKf4TJc07+HNC96+tO12g1XMIatovWiYjtb2hcMZAB dschUR/UQmITXqPp+i/efs7SRzFmNeM4qtZkR4X0cIGo9Plu0pY+K0yxfqrycTl/lyCV 6rKAZYfX7YX5zeqZ/7MhJP/lXYS+pLfOc2M1qtOhZFIwi1lQRYOW1XwKElr13VzxQrzp U/Jw== Received: by 10.224.31.210 with SMTP id z18mr3671031qac.95.1348139361572; Thu, 20 Sep 2012 04:09:21 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id et6sm7783620qab.8.2012.09.20.04.09.17 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 04:09:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Thu, 20 Sep 2012 07:09:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: "'pcp@ietf.org'" Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 11:09:22 -0000 Hi Alper, On Sep 20, 2012, at 5:01 AM, Alper Yegin wrote: >> Why do you think that we need to support EAP re-authentication?=20 >>=20 >=20 > EAP re-authentication is one of the EAP events, and any EAP = lower-layer has to support that. > Otherwise, what? Your sessions have infinite lifetime? Authorization = never changes? Never need to re-key? Never need to challenge the = end-point again? > These are the things that call for "re-authenticaiton", and why EAP = has that, and why EAP lower-layers need to support that. Sorry, I didn't see this response before I asked the question again... EAP re-authentication is an optional extension to EAP -- it isn't part = of the base EAP spec. I understand why it is useful, in general, but it = is not inherently part of EAP. It has always been possible to start EAP = over again from the beginning to do a new round of authentication, and = that can be done periodically, as desired. In other words, support for = EAP re-authentication is not required to support re-keying or = non-infinite lifetimes. _Because_ PCP is a request/response protocol, it would be possible for = either end to periodically throw away the existing authentication = information for a peer, and perform/request a new round of = authentication for the next request. EAP re-authentication is not = necessary for that purpose and, in fact, wouldn't be all that useful for = that purpose with PCP -- we wouldn't want "sessions" to attempt to = re-key repeatedly if there were no requests being sent back and forth, = would we? Please remember that PCP is a UDP request/response protocol, = and the server may keep mappings open long after the client computers = have gone home... So, there is no hard concept of a PCP "session" that = has a specific session lifetime. Authentication may be required (in = secure deployments) to create a mapping, but there is no notion that an = authenticated session has to remain active for the mapping to remain in = place for it's indicated lifetime. In fact, it would be undesirable to = create such a dependency, especially in the THIRD_PARTY/proxy case, = because we would not want to create a situation where communication = between two other nodes depends on the reliability/reachability of the = PCP proxy. You have asserted several times that EAP lower layers need to support = retransmission and reauthentication, and Sam has asserted several times = that they do not. How do we resolve this disagreement? Sam has pointed to an example of a recently approved EAP lower layer = (more recent than PANA), gss-eap, that is simpler than PANA, supports a = request/response model similar to PCP, and does not include those = things. So, it does not seem that the IETF (either the security area, = or the IESG) currently enforces the rules that you are asserting. Can = you point to an RFC or some other reference that indicates that support = for these things is required? Or is it just your opinion that it is = desirable to support these things for PCP? If so, could you explain = what benefits PCP would get from supporting them? Could you perhaps look at gss-eap and consider whether a similar model = could apply to PCP? Would it be possible to achieve a similar model = using PANA? If so, what updates would be need to the PANA specification = in order to do that? Margaret From alper.yegin@yegin.org Thu Sep 20 05:45:08 2012 Return-Path: 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 E394321F8804 for ; Thu, 20 Sep 2012 05:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 GhFkl+JgBxnQ for ; Thu, 20 Sep 2012 05:45:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFAF21F8802 for ; Thu, 20 Sep 2012 05:45:08 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LmrMC-1TiWAL3Dxs-00gy4U; Thu, 20 Sep 2012 08:45:06 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> Date: Thu, 20 Sep 2012 15:44:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <96BCC10E-E085-4292-B8E2-ED593BCD0ACE@yegin.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:fWhmh+zfAy8jfrMnOitVhTRYJc8fBxP1UdE760a7n92 h4GZv2y0ZeQWn4hUhEK/RwU2WQlYVldVBZKjqHDdWCb5DyKx1f R1ROW3tas49PQ3tGoS/LzKgPwo4HefZC6J/GFzpYN51LwB8aK8 L//vnuWVCkFtojo+tEmlODRJEK/CMh7xK/StS4prM0boeYrqJD 7EN8UoFIgPimof4oxebcwA/CQ2QAGQoDL9LakZDCHcH5DN5+Rs emhN6gVJMbvK0dD5TibZmH+PSLPKnOHTlh5DkkoC/6m6DQt5Is PYR7whFbnypKThvR/vJ+MfhNHoZ2UNiAbBDSXKBgLCLLiinQRY c/eR/krd8jf7wmzBwQh6K9aLYvqXGmt0JY+BJtcB9m8dV4rmyQ P13EnE5X/BBeQ== Cc: "'pcp@ietf.org'" Subject: Re: [pcp] EAP-over-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 12:45:09 -0000 >>=20 >> EAP re-authentication is one of the EAP events, and any EAP = lower-layer has to support that. >> Otherwise, what? Your sessions have infinite lifetime? Authorization = never changes? Never need to re-key? Never need to challenge the = end-point again? >> These are the things that call for "re-authenticaiton", and why EAP = has that, and why EAP lower-layers need to support that. >=20 > Sorry, I didn't see this response before I asked the question again... >=20 > EAP re-authentication is an optional extension to EAP -- it isn't part = of the base EAP spec. =20 It's not an extension, it's not an option. It's merely executing EAP again, whether initiated by the EAP peer or = the EAP authenticator -- for the reasons Sam and I listed before = (rekeying, reautz, etc). What it means for the EAP lower layer is that it shall be able to = transport unsolicited payloads from each side, including the = server-side. Which you are lacking right now. And I suspect you are = resisting that addition because EAP-o-PCP would look even less like PCP = once you add that. > I understand why it is useful, in general, but it is not inherently = part of EAP. Running EAP again, or n-times, is naturally part of EAP.=20 EAP initiation on the server side is the "EAP standard". > It has always been possible to start EAP over again from the = beginning to do a new round of authentication, and that can be done = periodically, as desired. =20 Yes, that's right. Also realize that this can be initiated by the client = side or the network side. That's all I'm saying. > In other words, support for EAP re-authentication is not required to = support re-keying or non-infinite lifetimes. >=20 Confusing, what's that mean now? Once you perform re-auth, you get new = keys and a new lifetime. Getting fresh keys and extending the lifetime = are two of the reasons for performing re-auth. > _Because_ PCP is a request/response protocol, it would be possible for = either end to periodically throw away the existing authentication = information for a peer, and perform/request a new round of = authentication for the next request. =20 How does the "server" side do that? That's the question. You need to = define a message that can be transmitted from the server side to = initiate re-auth. It's not rocket science. It's doable. Just define it in EAP-o-PCP. I'm = saying you are missing it. (but, I'm also saying your EAP-o-PCP is = totally different than PCP). > EAP re-authentication is not necessary for that purpose and, in fact, = wouldn't be all that useful for that purpose with PCP -- we wouldn't = want "sessions" to attempt to re-key repeatedly if there were no = requests being sent back and forth, would we? =20 EAP, and in fact any authenticated session, always comes with a finite = lifetime. Even if you were sitting idle, you need to re-auth and extend = the lifetime sometime before the current lifetime expires. Gotta do = that. > Please remember that PCP is a UDP request/response protocol, and the = server may keep mappings open long after the client computers have gone = home... So, there is no hard concept of a PCP "session" that has a = specific session lifetime. =20 Really??? I hope not. If a client disappears, is your NAT/firewall going = to keep the state "forever"?=20 > Authentication may be required (in secure deployments) to create a = mapping, but there is no notion that an authenticated session has to = remain active for the mapping to remain in place for it's indicated = lifetime. =20 That's right. But next time a PCP message needs to be sent/received = related to a session, there better be a live SA. If there is no live SA, = then one needs to "re-auth!" to get a live one. > In fact, it would be undesirable to create such a dependency, = especially in the THIRD_PARTY/proxy case, because we would not want to = create a situation where communication between two other nodes depends = on the reliability/reachability of the PCP proxy. >=20 > You have asserted several times that EAP lower layers need to support = retransmission and reauthentication, and Sam has asserted several times = that they do not. How do we resolve this disagreement? >=20 Umm, he didn't explain why reauth/rexmit is not needed. Technical = explanation is a good starting point, or a EAP-clueful person looks at = this and makes a comment.=20 > Sam has pointed to an example of a recently approved EAP lower layer = (more recent than PANA), gss-eap, that is simpler than PANA, supports a = request/response model similar to PCP, and does not include those = things. So, it does not seem that the IETF (either the security area, = or the IESG) currently enforces the rules that you are asserting. Can = you point to an RFC or some other reference that indicates that support = for these things is required? Or is it just your opinion that it is = desirable to support these things for PCP? If so, could you explain = what benefits PCP would get from supporting them? >=20 We did explain that already, right? Even Sam made references to = re-keying, lifetime, authorization change, etc. I mean, this is one of the most basic things with security design.=20 If we were in a security-specific group, you'd be the one explaining how = you can get away w/o ever supporting re-auth. If you guys think you have a magic to turn a server-driven protocol = (EAP) into a client-drive protocol, and a magic to totally eliminate = re-auth and yet still be have a secure solution with unconstrained = applicability, please explain how you do that to us.=20 > Could you perhaps look at gss-eap and consider whether a similar model = could apply to PCP? =20 I could look at it. And I guess now I have to. A simple technical = explanation from Sam could be better than I having to read and digest = that spec. > Would it be possible to achieve a similar model using PANA? If so, = what updates would be need to the PANA specification in order to do = that? >=20 Confused. What updates to PANA for what purpose? PANA already supports = re-auth.=20 Alper From hartmans@mit.edu Thu Sep 20 05:49:17 2012 Return-Path: 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 A075821F8805 for ; Thu, 20 Sep 2012 05:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.384 X-Spam-Level: **** X-Spam-Status: No, score=4.384 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 R3QOY13EfjyR for ; Thu, 20 Sep 2012 05:49:17 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCEF21F87F4 for ; Thu, 20 Sep 2012 05:49:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5930320167; Thu, 20 Sep 2012 08:49:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E5D6A414A; Thu, 20 Sep 2012 08:48:43 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> Date: Thu, 20 Sep 2012 08:48:43 -0400 In-Reply-To: <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> (Alper Yegin's message of "Thu, 20 Sep 2012 12:38:50 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'pcp@ietf.org'" Subject: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 12:49:17 -0000 I wanted to give the WG some final thoughts on the conversation Alper and I have been having. This will probably be my last message on the topic as I think we're basically at the point of diminishing returns. >>>>> "Alper" == Alper Yegin writes: On the topic of retransmits, we agree that under section 4.3 of RFC 3748, you can set the transmit timer to infinite. I think we agree that this moves retransmits from within the EAP layer to the EAP lower layer. Alper> When run over a reliable lower layer (e.g., EAP over Alper> ISAKMP/TCP, as within [PIC]), the authenticator Alper> retransmission timer SHOULD be set to an infinite value, so Alper> that retransmissions do not occur at the EAP layer. Alper> Only when run over a reliable EAP lower layer, the EAP layer Alper> sets the timeout to infinity. So, whether the rexmit is Alper> handled by the EAP layer, or the EAP lower layer, the PCP Alper> server will be sending retransmissions in your case. It's actually fairly easy to move which side generates the retransmission once you move it into the lower layer. Note that the PCP server still needs to maintain the state of what EAP request to send, but whether to send that can be based on what the client sends. That is, if the PCP state machine works better with client-driven retransmits, we can achieve that. We do need authentication-session state in the server, and part of that state is the unacknowledged eap-request if there is one. With regard to re-authentication: >> Consider what happens in an AAA server. There, your EAP >> server cannot (and is not supposed to) handle retransmits. >> RADIUS at least is a lock-step protocol. Ignoring things like Alper> COA, Alper> Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an Alper> unsolicited message, more specifically for starting EAP I'd like to draw the WG's attention to RFC 5176, which defines COA. Section 4 explicitly mentions that COA cannot be used for starting re-authentication. Section 1.1 is an applicability statement explaining why COA is not standards-track because of security and semantic concerns. As best I can tell only diameter has AAA support for re-authentication. So, I'd like to draw our attention to RFC 4005, section 3.3 which defines rules for diameter re-authentication. That section explicitly calls out re-authentication must be supported *if the underlying service supports it*. That is, re-authentication is OPTIONAL for a given service like PCP, but if a given PCP server supports re-authentication and diameter, then it needs to support re-authentication via diameter. Section 3 of RFC 4072 (diameter over eap) confirms the guidelines of RFC 4005 apply. Re-authentication being optional is definitely consistent with my implementation experience. I have no experience with diameter, but do have a lot of experience with EAP implementations that consider re-authentication optional. This is all great news for the PCP community. We can choose the retransmission strategy that best meets the PCP implementations. we can choose to support re-authentication if it is useful, or decline to support it if it is not. If we don't choose to support re-authentication then we can avoid the complexity. From alper.yegin@yegin.org Thu Sep 20 06:18:01 2012 Return-Path: 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 A1D4921F847C for ; Thu, 20 Sep 2012 06:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 D7ozM6xlRnZs for ; Thu, 20 Sep 2012 06:18:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADE721F8460 for ; Thu, 20 Sep 2012 06:18:01 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MBW50-1TO42f0rQ6-00AiWA; Thu, 20 Sep 2012 09:17:59 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> Date: Thu, 20 Sep 2012 16:17:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6569B9B2-0B82-450A-A328-D023EFC732DA@yegin.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> To: Margaret Wasserman , Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:qczyicbkaxFvEfQiq+tkpvLlsbPSksufLCcJjziOWUc RuxHL1Z8K6d1S3BPRGOg6dIc3kJFheHViRfqtbv+s4Hp1uODLV SP0i2/BroIc22f3ryIo723z2dOlz1v5upxWOc6HHYTnaA0ZqPO ZCcNYyx2HvkH5kuvs9RSwzDMaUPHxepbzuhR6hZnEmF7NqqfDV LU/AdaIbbQ3efNz2fxNAyx7wmj+hd5LRoa5qn/I5opd7HjK+RN rQ3FRw3eVvEHj0+IP+yLv8+UOmuFyAHA8o5Sxba6bJAd5P7iLR nWU0QC6zx5nhiCbjFTIdW0RXgQJcxV3nPnV/PBTlRitsx+Ok/i 7zfZMzJISZwaNKnRyqM1K0EPeIfyeOxELA/Q/DRLv7Qd+Gubcz tXM7uUrxhYbQw== Cc: pcp@ietf.org Subject: [pcp] gss-eap X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 13:18:01 -0000 So, I looked at this spec. This, too, is server-driven. Like EAP is, unlike PCP is.=20 Retransmission do happen, not at the EAP layer but at the EAP-lower = layer. Yep, there's no re-auth. It's absence is confirmed! :-) - What happens if server-side needs to re-key, extend lifetime, change = authorization, re-challenge the client?=20 Say, the acceptor receives a RADIUS CoA with EAP-Request, what's going = to do with it? Sorry folks, gss-eap as an EAP lower layer spec is incomplete. Whether = you recognize and accept this today, or later when you start building = complete architectures/systems with it. No worries, you can always add = it. Alper From yoshihiro.ohba@toshiba.co.jp Thu Sep 20 08:27:33 2012 Return-Path: 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 894D021F86F0 for ; Thu, 20 Sep 2012 08:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.073 X-Spam-Level: X-Spam-Status: No, score=-5.073 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 ay4c6T7+1soG for ; Thu, 20 Sep 2012 08:27:32 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 995C621F86EC for ; Thu, 20 Sep 2012 08:27:32 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q8KFRVRb021552 for ; Fri, 21 Sep 2012 00:27:31 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q8KFRV01021131 for pcp@ietf.org; Fri, 21 Sep 2012 00:27:31 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id AAA21130; Fri, 21 Sep 2012 00:27:31 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q8KFRV2B027679 for ; Fri, 21 Sep 2012 00:27:31 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8KFRUhl003814; Fri, 21 Sep 2012 00:27:30 +0900 (JST) Received: from [133.199.16.78] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAN007K2MXTGT90@mail.po.toshiba.co.jp> for pcp@ietf.org; Fri, 21 Sep 2012 00:27:30 +0900 (JST) Date: Fri, 21 Sep 2012 00:27:32 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <505B35E4.5020108@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: Re: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 15:27:33 -0000 I believe Alper and Sam are discussing EAP re-authentication in the context of RFC 3748 and RFC 5247 and not specifically in the context of RFC 5296 (ERP). Let's not confuse ourselves. EAP re-authentication in the context of RFC 3748 and RFC 5247 is supported by most known lower-layers, including 802.1X and PANA, for re-keying lower layer SA. While I agree that ERP is definitely not needed for PCP, but I think unsupporting EAP re-authentication in the context of RFC 3748 and RFC 5247 is NOT a good idea, because it enables smooth migration from old SA to new SA. Without supporting EAP re-authentication in the context of RFC 3748 and RFC 5247, communications disruptions can happen during rekey, i.e., communication quality of PCP and data traffic controlled by PCP can affect in our case. Also, it seems that there is some desire to change PCP-specific authentication design to be based on client-initiated request so that it fits the PCP-base design. This just shows that this is an issue with the current design of PCP-specific authentication. Regarding client-initiated request support for EAP lower layer, I also have the same doubt as Alper has. Whether it works with acceptable complexity really depends on detailed characteristics of the targeted lower layer. Showing examples of EAP-GSS and IKEv2 does not help for PCP. I can say that EAP over DHCP that was rejected by IETF, one major reason was that is was considered to be difficult to fit EAP into DHCP's client-initiated request model (I forgot why it is difficult, I suggest to read the entire email discussion in DHC WG on this). Having said that I cannot really judge until and unless a complete solution for the design change is shown. I suggest not to spend too much time for justifying or promoting re-invented designs which can easily contain flaws and disadvantages that were already taken care of in the original design that successfully went through critical evaluation by a large community (IETF). Yoshihiro Ohba (2012/09/20 21:48), Sam Hartman wrote: > > I wanted to give the WG some final thoughts on the conversation Alper > and I have been having. > This will probably be my last message on the topic as I think we're > basically at the point of diminishing returns. > >>>>>> "Alper" == Alper Yegin g> writes: > > On the topic of retransmits, we agree that under section 4.3 of RFC > 3748, you can set the transmit timer to infinite. > I think we agree that this moves retransmits from within the EAP layer > to the EAP lower layer. > > > Alper> When run over a reliable lower layer (e.g., EAP over > Alper> ISAKMP/TCP, as within [PIC]), the authenticator > Alper> retransmission timer SHOULD be set to an infinite value, so > Alper> that retransmissions do not occur at the EAP layer. > > > Alper> Only when run over a reliable EAP lower layer, the EAP layer > Alper> sets the timeout to infinity. So, whether the rexmit is > Alper> handled by the EAP layer, or the EAP lower layer, the PCP > Alper> server will be sending retransmissions in your case. > > It's actually fairly easy to move which side generates the > retransmission once you move it into the lower layer. > Note that the PCP server still needs to maintain the state of what EAP > request to send, but whether to send that can be based on what the > client sends. > That is, if the PCP state machine works better with client-driven > retransmits, > we can achieve that. > We do need authentication-session state in the server, and part of that > state is the unacknowledged eap-request if there is one. > > > With regard to re-authentication: > >>> Consider what happens in an AAA server. There, your EAP >>> server cannot (and is not supposed to) handle retransmits. >>> RADIUS at least is a lock-step protocol. Ignoring things like > Alper> COA, > > > Alper> Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an > Alper> unsolicited message, more specifically for starting EAP > > I'd like to draw the WG's attention to RFC 5176, which defines COA. > Section 4 explicitly mentions that COA cannot be used for starting > re-authentication. Section 1.1 is an applicability statement explaining > why COA is not standards-track because of security and semantic > concerns. > > As best I can tell only diameter has AAA support for re-authentication. > So, I'd like to draw our attention to RFC 4005, section 3.3 which > defines rules for diameter re-authentication. That section explicitly > calls out re-authentication must be supported *if the underlying service > supports it*. That is, re-authentication is OPTIONAL for a given > service like PCP, but if a given PCP server supports re-authentication > and diameter, then it needs to support re-authentication via diameter. > Section 3 of RFC 4072 (diameter over eap) confirms the guidelines of RFC > 4005 apply. > > Re-authentication being optional is definitely consistent with my > implementation experience. I have no experience with diameter, but do > have a lot of experience with EAP implementations that consider > re-authentication optional. > > > This is all great news for the PCP community. We can choose the > retransmission strategy that best meets the PCP implementations. we can > choose to support re-authentication if it is useful, or decline to > support it if it is not. If we don't choose to support > re-authentication then we can avoid the complexity. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From hartmans@painless-security.com Thu Sep 20 08:33:22 2012 Return-Path: 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 1895F21F87B2 for ; Thu, 20 Sep 2012 08:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.377 X-Spam-Level: **** X-Spam-Status: No, score=4.377 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 jxMNJql4sxcb for ; Thu, 20 Sep 2012 08:33:21 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42921F87E7 for ; Thu, 20 Sep 2012 08:33:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5BF7220167; Thu, 20 Sep 2012 11:33:11 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 91FA7414A; Thu, 20 Sep 2012 11:32:48 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> <505B35E4.5020108@toshiba.co.jp> Date: Thu, 20 Sep 2012 11:32:48 -0400 In-Reply-To: <505B35E4.5020108@toshiba.co.jp> (Yoshihiro Ohba's message of "Fri, 21 Sep 2012 00:27:32 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 15:33:22 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> While I agree that ERP is definitely not needed for PCP, Yoshihiro> but I think unsupporting EAP re-authentication in the Yoshihiro> context of RFC 3748 and RFC 5247 is NOT a good idea, Yoshihiro> because it enables smooth migration from old SA to new Yoshihiro> SA. Without supporting EAP re-authentication in the Yoshihiro> context of RFC 3748 and RFC 5247, communications Yoshihiro> disruptions can happen during rekey, i.e., communication Yoshihiro> quality of PCP and data traffic controlled by PCP can Yoshihiro> affect in our case. I'd like to hear from PCP implementors about whether smoothe SA migration is even desirable. My assumption would be that it would be entirely not worth the complexity for PCP. Yoshihiro> Also, it seems that there is some desire to change Yoshihiro> PCP-specific authentication design to be based on Yoshihiro> client- Actually, I didn't propose a change; I simply pointed out that you can do it either way depending on what is easiest for PCP implementations; we should pick, but what we pick should be based on the needs of the PCP community. It's my experience that security solutions are best when they provide a good user experience and are easy to implement. I'm hoping to accomplish that here. --Sam From yoshihiro.ohba@toshiba.co.jp Thu Sep 20 09:12:40 2012 Return-Path: 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 5D9AB21F8775 for ; Thu, 20 Sep 2012 09:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.991 X-Spam-Level: X-Spam-Status: No, score=-4.991 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 c6CHJVRSzsgs for ; Thu, 20 Sep 2012 09:12:39 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8984421F873E for ; Thu, 20 Sep 2012 09:12:39 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q8KGCcGv002019; Fri, 21 Sep 2012 01:12:38 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q8KGCcS1014344; Fri, 21 Sep 2012 01:12:38 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id BAA14343; Fri, 21 Sep 2012 01:12:37 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q8KGCbL6010238; Fri, 21 Sep 2012 01:12:37 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8KGCb4S008525; Fri, 21 Sep 2012 01:12:37 +0900 (JST) Received: from [133.199.17.158] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAN007FEP0ZGRA0@mail.po.toshiba.co.jp>; Fri, 21 Sep 2012 01:12:37 +0900 (JST) Date: Fri, 21 Sep 2012 01:12:39 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <505B4077.3030802@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> <505B35E4.5020108@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: pcp@ietf.org Subject: Re: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:12:40 -0000 Sam, (2012/09/21 0:32), Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > > Yoshihiro> While I agree that ERP is definitely not needed for PCP, > Yoshihiro> but I think unsupporting EAP re-authentication in the > Yoshihiro> context of RFC 3748 and RFC 5247 is NOT a good idea, > Yoshihiro> because it enables smooth migration from old SA to new > Yoshihiro> SA. Without supporting EAP re-authentication in the > Yoshihiro> context of RFC 3748 and RFC 5247, communications > Yoshihiro> disruptions can happen during rekey, i.e., communication > Yoshihiro> quality of PCP and data traffic controlled by PCP can > Yoshihiro> affect in our case. > > I'd like to hear from PCP implementors about whether smoothe SA > migration is even desirable. > My assumption would be that it would be entirely not worth the > complexity for PCP. I have to say that this matters for users of PCP. PCP implementors have to implement what PCP users want. As a user of PCP, I don't want my established WebEx session for the interim meeting to get disrupted by rekey ;) > > Yoshihiro> Also, it seems that there is some desire to change > Yoshihiro> PCP-specific authentication design to be based on > Yoshihiro> client- > > Actually, I didn't propose a change; I simply pointed out that you can > do it either way depending on what is easiest for PCP implementations; > we should pick, but what we pick should be based on the needs of the PCP > community. I would rather consider this as the major disadvantage of tight coupling EAP and PCP. It is much easier to run PANA and PCP side-by-side which achieves loose coupling of EAP and PCP. > > It's my experience that security solutions are best when they provide a > good user experience and are easy to implement. I'm hoping to accomplish > that here. Then EAP re-authentication needs to be supported. Yoshihiro Ohba > > --Sam > From hartmans@painless-security.com Thu Sep 20 09:22:55 2012 Return-Path: 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 4223321F865B for ; Thu, 20 Sep 2012 09:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.37 X-Spam-Level: **** X-Spam-Status: No, score=4.37 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 deR3UwfJQdV5 for ; Thu, 20 Sep 2012 09:22:54 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7E13721F84B5 for ; Thu, 20 Sep 2012 09:22:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EA82220167; Thu, 20 Sep 2012 12:22:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 82C39414A; Thu, 20 Sep 2012 12:22:09 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> <505B35E4.5020108@toshiba.co.jp> <505B4077.3030802@toshiba.co.jp> Date: Thu, 20 Sep 2012 12:22:09 -0400 In-Reply-To: <505B4077.3030802@toshiba.co.jp> (Yoshihiro Ohba's message of "Fri, 21 Sep 2012 01:12:39 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:22:55 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> I have to say that this matters for users of PCP. PCP Yoshihiro> implementors have to implement what PCP users want. As a Yoshihiro> user of PCP, I don't want my established WebEx session Yoshihiro> for the interim meeting to get disrupted by rekey ;) We're agreed on that. However as Margaret has pointed out you don't need seemless SA migration to get that in PCP. Session expire does not mean mapping expire. From margaretw42@gmail.com Thu Sep 20 09:45:17 2012 Return-Path: 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 C7BFB21F87DD for ; Thu, 20 Sep 2012 09:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 pBxC4raa1N3Q for ; Thu, 20 Sep 2012 09:45:16 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23B3E21F847C for ; Thu, 20 Sep 2012 09:45:06 -0700 (PDT) Received: by qcac10 with SMTP id c10so2170748qca.31 for ; Thu, 20 Sep 2012 09:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FPLWVcOxM8cuICv5D/dCACQCMS3zfg+kWg396hq3y3w=; b=G7KX80duyd4YWbf13Hl+tIiVb1f/YJtXivBRIg6tRnu7us1Qrkp4HJAwyYwsTiYU7E yGEQ/x56AzdBSXO07VMS2eZfxX8fx0ui1RQZC1dnaMHsRvxlOetcHeTxOW5ZMCs5ZH5o tkPuxxeL3IqvSTha0HfWv+sPqKw9FCVqQkGGNVKF+Ywipq5ugo0FwrOuGNMSslUVWY68 oSNF1va5Gm1bF9m/0DAIQIKTDLzicbueZPmZbmxirSNEdbV4AUR+lib0P3Avuz1EJHgx HE2MW0CKeyUY5CSVPzvTXpv6vgEnHF29qVeRCOm2cQ9zxVjq0rtaQPrFqFNKShT2CrpP IA8Q== Received: by 10.224.222.13 with SMTP id ie13mr5899148qab.69.1348159506381; Thu, 20 Sep 2012 09:45:06 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id bh14sm8841354qab.2.2012.09.20.09.45.02 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 09:45:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <505B4077.3030802@toshiba.co.jp> Date: Thu, 20 Sep 2012 12:45:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6CDC61E8-2811-4D44-959E-0F01BEA5C7EF@lilacglade.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> <505B35E4.5020108@toshiba.co.jp> <505B4077.3030802@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:45:18 -0000 On Sep 20, 2012, at 12:12 PM, Yoshihiro Ohba wrote: >> Actually, I didn't propose a change; I simply pointed out that you = can >> do it either way depending on what is easiest for PCP = implementations; >> we should pick, but what we pick should be based on the needs of the = PCP >> community. >=20 > I would rather consider this as the major disadvantage of tight > coupling EAP and PCP. It is much easier to run PANA and PCP > side-by-side which achieves loose coupling of EAP and PCP.=3D The problem is that running PCP and PANA side-by-side doesn't really = change anything... Either we change PCP to have a notion of a "session" that is associated = with every mapping, and to understand to understand that external events = can cause an asynchronous event of some sort that invalidates all of = those mappings, or we don't... I greatly prefer a model where the a client is authenticated and = authorized to create a mapping, at the time that the mapping is created, = and there is no presumption that the mapping is tied to any sort of = ongoing client authentication/authorization. Otherwise, I suppose we could _claim_ to support re-authentication, but = what does it mean if PANA performs re-authentication and there is no = meaningful way to communicate a re-authentication success, or more = importantly perhaps, a re-authentication failure to PCP. How are you imagining this would work in the side-by-side case -- = re-authentication occurs, and then what? Margaret From yoshihiro.ohba@toshiba.co.jp Thu Sep 20 10:24:09 2012 Return-Path: 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 2F6F521F881F for ; Thu, 20 Sep 2012 10:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[AWL=1.168, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 h9pnB65meiSX for ; Thu, 20 Sep 2012 10:24:08 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 64B7021F8816 for ; Thu, 20 Sep 2012 10:24:07 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8KHO4a9022576; Fri, 21 Sep 2012 02:24:04 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8KHO4dS004599; Fri, 21 Sep 2012 02:24:04 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id CAA04598; Fri, 21 Sep 2012 02:24:04 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8KHO45R014736; Fri, 21 Sep 2012 02:24:04 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8KHNxYv028009; Fri, 21 Sep 2012 02:23:59 +0900 (JST) Received: from [133.199.16.197] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAN007IOSBYGTA0@mail.po.toshiba.co.jp>; Fri, 21 Sep 2012 02:23:59 +0900 (JST) Date: Fri, 21 Sep 2012 02:24:01 +0900 From: Yoshihiro Ohba In-reply-to: <6CDC61E8-2811-4D44-959E-0F01BEA5C7EF@lilacglade.org> To: Margaret Wasserman Message-id: <505B5131.3000400@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> <505B35E4.5020108@toshiba.co.jp> <505B4077.3030802@toshiba.co.jp> <6CDC61E8-2811-4D44-959E-0F01BEA5C7EF@lilacglade.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: pcp@ietf.org Subject: Re: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:24:09 -0000 Margaret, (2012/09/21 1:45), Margaret Wasserman wrote: > > On Sep 20, 2012, at 12:12 PM, Yoshihiro Ohba wrote: >>> Actually, I didn't propose a change; I simply pointed out that you can >>> do it either way depending on what is easiest for PCP implementations; >>> we should pick, but what we pick should be based on the needs of the PCP >>> community. >> >> I would rather consider this as the major disadvantage of tight >> coupling EAP and PCP. It is much easier to run PANA and PCP >> side-by-side which achieves loose coupling of EAP and PCP.= > > The problem is that running PCP and PANA side-by-side doesn't really change anything... > > Either we change PCP to have a notion of a "session" that is associated with every mapping, and to understand to understand that external events can cause an asynchronous event of some sort that invalidates all of those mappings, or we don't... > > I greatly prefer a model where the a client is authenticated and authorized to create a mapping, at the time that the mapping is created, and there is no presumption that the mapping is tied to any sort of ongoing client authentication/authorization. > I disagree. Loose coupling of authentication/authorization and states associated with authorization creates a security issue. Loose coupling makes it difficult for service providers to strictly enforce their services based on the authentication/authorization. > Otherwise, I suppose we could _claim_ to support re-authentication, but what does it mean if PANA performs re-authentication and there is no meaningful way to communicate a re-authentication success, or more importantly perhaps, a re-authentication failure to PCP. > > How are you imagining this would work in the side-by-side case -- re-authentication occurs, and then what? > I suggest you to take a look at RFC 5609 on how it can work. Completion of initial authentication and re-authentication calls Authorize() upon success and Disconnect() upon failure which are typically implemented as a callback. " void Disconnect() A procedure to delete the PANA session as well as the corresponding EAP session and authorization state. boolean Authorize() A procedure to create or modify authorization state. It returns TRUE if authorization is successful. Otherwise, it returns FALSE. It is assumed that Authorize() procedure of PaC state machine always returns TRUE. In the case that a non-key-generating EAP method is used but a PANA SA is required after successful authentication (generate_pana_sa() returns TRUE), Authorize() procedure must return FALSE. " If you find some issue, we can work on revising RFC 5609 if something is missing for PCP needs, which would be more productive IMO. Yoshihiro Ohba > Margaret > > > From hartmans@painless-security.com Thu Sep 20 10:33:41 2012 Return-Path: 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 67E5221F869A for ; Thu, 20 Sep 2012 10:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.365 X-Spam-Level: **** X-Spam-Status: No, score=4.365 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 ACZQY8d33Gac for ; Thu, 20 Sep 2012 10:33:40 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id A064121F8682 for ; Thu, 20 Sep 2012 10:33:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 146DB20167; Thu, 20 Sep 2012 13:33:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 369DC414A; Thu, 20 Sep 2012 13:33:07 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> <505B35E4.5020108@toshiba.co.jp> <505B4077.3030802@toshiba.co.jp> <6CDC61E8-2811-4D44-959E-0F01BEA5C7EF@lilacglade.org> <505B5131.3000400@toshiba.co.jp> Date: Thu, 20 Sep 2012 13:33:07 -0400 In-Reply-To: <505B5131.3000400@toshiba.co.jp> (Yoshihiro Ohba's message of "Fri, 21 Sep 2012 02:24:01 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:33:41 -0000 One thing to consider is that in many cases, PCP users will not be using authentication; they will be using unauthenticated PCP. So, especially for PCP, it seems undesirable to tie authorization to authentication. If an authorization revocation event happens--that is, a service provider wants to stop providing service to a customer--they will typically want to drop both unauthenticated and authenticated mappings. The sort of things that might trigger this are administrative action (customer account suspended for immediate cause), address renumbering, or lease expire. For PCP it seems much more likely that these events will be tied to a provisioning/authorization system than any event in an authentication system. Tieing this to authentication seems like it will miss important PCP use cases. Duplicating the same logic both for authentication and authorization seems to introduce complexity that PCP does not need. --Sam From yoshihiro.ohba@toshiba.co.jp Thu Sep 20 11:18:25 2012 Return-Path: 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 86A8821F880C for ; Thu, 20 Sep 2012 11:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.005 X-Spam-Level: X-Spam-Status: No, score=-7.005 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 1tCdwJlZz8jn for ; Thu, 20 Sep 2012 11:18:25 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id CD99721F8803 for ; Thu, 20 Sep 2012 11:18:24 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8KIIMNu006330; Fri, 21 Sep 2012 03:18:22 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8KIIMGA024014; Fri, 21 Sep 2012 03:18:22 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id DAA24011; Fri, 21 Sep 2012 03:18:21 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8KIILoj000520; Fri, 21 Sep 2012 03:18:21 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8KIILqk028942; Fri, 21 Sep 2012 03:18:21 +0900 (JST) Received: from [133.199.16.196] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAN007FPUUJGRB0@mail.po.toshiba.co.jp>; Fri, 21 Sep 2012 03:18:20 +0900 (JST) Date: Fri, 21 Sep 2012 03:18:23 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <505B5DEF.8030801@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> <505B35E4.5020108@toshiba.co.jp> <505B4077.3030802@toshiba.co.jp> <6CDC61E8-2811-4D44-959E-0F01BEA5C7EF@lilacglade.org> <505B5131.3000400@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: pcp@ietf.org Subject: Re: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:18:25 -0000 Sam, Since PCP authentication is not part of base specification, authentication is already optional, which is fine. But when authentication is used it needs to be tied with authorization. Yoshihiro Ohba (2012/09/21 2:33), Sam Hartman wrote: > One thing to consider is that in many cases, PCP users will not be using > authentication; they will be using unauthenticated PCP. So, especially > for PCP, it seems undesirable to tie authorization to authentication. > > If an authorization revocation event happens--that is, a service > provider wants to stop providing service to a customer--they will > typically want to drop both unauthenticated and authenticated mappings. > The sort of things that might trigger this are administrative action > (customer account suspended for immediate cause), address renumbering, > or lease expire. > > For PCP it seems much more likely that these events will be tied to a > provisioning/authorization system than any event in an authentication > system. > > Tieing this to authentication seems like it will miss important PCP use > cases. > Duplicating the same logic both for authentication and authorization > seems to introduce complexity that PCP does not need. > > --Sam > From internet-drafts@ietf.org Thu Sep 20 11:34:13 2012 Return-Path: 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 D46ED21E8063; Thu, 20 Sep 2012 11:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 VWxwguUT7-PB; Thu, 20 Sep 2012 11:34:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F0421F8748; Thu, 20 Sep 2012 11:34:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120920183413.20726.19181.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2012 11:34:13 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-base-27.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:34:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : Port Control Protocol (PCP) Author(s) : Dan Wing Stuart Cheshire Mohamed Boucadair Reinaldo Penno Paul Selkirk Filename : draft-ietf-pcp-base-27.txt Pages : 107 Date : 2012-09-20 Abstract: The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-base There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-base-27 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-27 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dwing@cisco.com Thu Sep 20 11:35:42 2012 Return-Path: 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 478A321E8064 for ; Thu, 20 Sep 2012 11:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 oYWA0lcq5DiR for ; Thu, 20 Sep 2012 11:35:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8931B21F8749 for ; Thu, 20 Sep 2012 11:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2572; q=dns/txt; s=iport; t=1348166141; x=1349375741; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=XXFn8DXSl1QqMUHO/l+A2Y7Xt/ZgHHrJXtHxY8GQEfE=; b=jOiT6GRyCLQl49uvf1T2gY7CK0Wqay0Xds8LWgDRPqGAjitKXJXvGoBN LAcwAGtZO8AtPVxh6zudkLthfj3oTpOOhys8kgOh3CDaztRQSecXW+GIR EePIG/wDQKXvn7mjJ17iGH04886maT2h4vSmIPlHmXypzwrx48d7oDQGa c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAHNhW1CtJV2c/2dsb2JhbABFrSWQBYEIgicICgEXED8NBRhQIxwBBBwCF4dhC5oPoBSLNoMIgyADiFaFEIkSjSSBaYMHgUM X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="123716932" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 20 Sep 2012 18:35:41 +0000 Received: from dwingWS ([10.32.240.198]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8KIZe7O010436; Thu, 20 Sep 2012 18:35:40 GMT From: "Dan Wing" To: Date: Thu, 20 Sep 2012 11:35:41 -0700 Message-ID: <11bf01cd975e$bd023190$370694b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2XXryEzk+BLRymTgWW27uh+Z/beA== Content-Language: en-us Cc: pcp-chairs@tools.ietf.org Subject: [pcp] pcp-base-27: Mapping Nonce change X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:35:42 -0000 Based on IESG feedback and coordinating these changes with draft-ietf-behave-lsn-requirements, an updated version of pcp-base has been posted. The proposed change to Mapping Nonce was announced on August 17, "strengthening PCP with Mapping Nonce", http://www.ietf.org/mail-archive/web/pcp/current/msg02229.html. The significant changes are: 1. Once a MAP or PEER opcode is processed by the PCP server, subsequent changes to that mapping have to use the same Mapping Nonce. This closes the attack that led to REQ-9-A in draft-ietf-behave-lsn-requirements-09. However, this change has a side-effect of disabling two previous MAP features: (a) the ability of a PCP client to delete (clear) PCP mappings created by a previous PCP client using the same IP address, and (b) ability for a PCP client to delete all of the mappings it created by sending one MAP message. To accommodate the loss of (a), pcp-base-27 recommends that when a host joins a network, the network device that allowed the device to join the network should flush PCP-created mappings and non-PCP-created mappings (e.g., DHCP, 802.1x, PPPoE). Towards that end, Stuart has written draft-cheshire-pcp-expire, and there are many other ways to clear PCP and implicit mapping state in NATs and firewalls when a device joins a network. (b) was just an optimization; the PCP client can delete MAP created mappings by issuing separate requests, similar to how it issued separate MAP requests to create the mappings. 2. Clarified that PEER can reduce a mapping lifetime to the same lifetime as active, bi-directional traffic. This allows PEER to extend lifetime of a mapping, then later using the same Mapping Nonce, PEER can rescind (revert) that lifetime extension so the mapping is treated as if PEER was never used. Another significant change, unrelated to Mapping Nonce, is that Mapping Update is now required. This means the PCP server now MUST inform the PCP client of any changes to a mapping; earlier versions of the specification said this was merely a SHOULD. This change makes PCP a more reliable protocol. There are a lot of other minor changes from IESG feedback and from other reviewers. See the changelog in Section B.1, or the side-by-side diffs. URL: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-27.txt Status: http://datatracker.ietf.org/doc/draft-ietf-pcp-base Htmlized: http://tools.ietf.org/html/draft-ietf-pcp-base-27 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-27 -d From dthaler@microsoft.com Thu Sep 20 16:37:24 2012 Return-Path: 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 8C31A11E80A2 for ; Thu, 20 Sep 2012 16:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.465 X-Spam-Level: X-Spam-Status: No, score=-105.465 tagged_above=-999 required=5 tests=[AWL=1.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 h5aYo1l5eGm2 for ; Thu, 20 Sep 2012 16:37:24 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id CD3F111E8099 for ; Thu, 20 Sep 2012 16:37:23 -0700 (PDT) Received: from mail39-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Sep 2012 23:37:23 +0000 Received: from mail39-tx2 (localhost [127.0.0.1]) by mail39-tx2-R.bigfish.com (Postfix) with ESMTP id 022C418015A; Thu, 20 Sep 2012 23:37:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zz9371I542M154dM1432Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah1155h) Received-SPF: pass (mail39-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail39-tx2 (localhost.localdomain [127.0.0.1]) by mail39-tx2 (MessageSwitch) id 1348184240229888_9073; Thu, 20 Sep 2012 23:37:20 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.236]) by mail39-tx2.bigfish.com (Postfix) with ESMTP id 262DE3C0047; Thu, 20 Sep 2012 23:37:20 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Sep 2012 23:37:19 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 20 Sep 2012 23:37:04 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0318.003; Thu, 20 Sep 2012 16:37:04 -0700 From: Dave Thaler To: Dan Wing , "pcp@ietf.org" Thread-Topic: pcp-base-27: Mapping Nonce change Thread-Index: Ac2XXryEzk+BLRymTgWW27uh+Z/beAAKX6wA Date: Thu, 20 Sep 2012 23:37:03 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7C0A8A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <11bf01cd975e$bd023190$370694b0$@com> In-Reply-To: <11bf01cd975e$bd023190$370694b0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] pcp-base-27: Mapping Nonce change X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:37:24 -0000 Thanks Dan for the nice summary. Hopefully we can have a good discussion on the call tomorrow, primarily on #1 (the security point). -Dave > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, September 20, 2012 11:36 AM > To: pcp@ietf.org > Cc: pcp-chairs@tools.ietf.org > Subject: pcp-base-27: Mapping Nonce change >=20 > Based on IESG feedback and coordinating these changes with draft-ietf- > behave-lsn-requirements, an updated version of pcp-base has been posted. > The proposed change to Mapping Nonce was announced on August 17, > "strengthening PCP with Mapping Nonce", http://www.ietf.org/mail- > archive/web/pcp/current/msg02229.html. >=20 >=20 > The significant changes are: >=20 > 1. Once a MAP or PEER opcode is processed by the PCP server, subsequent > changes to that mapping have to use the same Mapping Nonce. This closes > the attack that led to REQ-9-A in draft-ietf-behave-lsn-requirements-09. >=20 > However, this change has a side-effect of disabling two previous MAP > features: (a) the ability of a PCP client to delete (clear) PCP mappings > created by a previous PCP client using the same IP address, and (b) abili= ty for > a PCP client to delete all of the mappings it created by sending one MAP > message. To accommodate the loss of (a), pcp-base-27 recommends that > when a host joins a network, the network device that allowed the device t= o > join the network should flush PCP-created mappings and non-PCP-created > mappings (e.g., DHCP, 802.1x, PPPoE). Towards that end, Stuart has writt= en > draft-cheshire-pcp-expire, and there are many other ways to clear PCP and > implicit mapping state in NATs and firewalls when a device joins a networ= k. > (b) was just an optimization; the PCP client can delete MAP created mappi= ngs > by issuing separate requests, similar to how it issued separate MAP reque= sts > to create the mappings. >=20 > 2. Clarified that PEER can reduce a mapping lifetime to the same lifetime= as > active, bi-directional traffic. This allows PEER to extend lifetime of a > mapping, then later using the same Mapping Nonce, PEER can rescind > (revert) that lifetime extension so the mapping is treated as if PEER was > never used. >=20 >=20 > Another significant change, unrelated to Mapping Nonce, is that Mapping > Update is now required. This means the PCP server now MUST inform the > PCP client of any changes to a mapping; earlier versions of the specifica= tion > said this was merely a SHOULD. This change makes PCP a more reliable > protocol. >=20 >=20 > There are a lot of other minor changes from IESG feedback and from other > reviewers. See the changelog in Section B.1, or the side-by-side diffs. >=20 >=20 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-27.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-pcp-base > Htmlized: http://tools.ietf.org/html/draft-ietf-pcp-base-27 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-2= 7 >=20 > -d From dthaler@microsoft.com Thu Sep 20 20:40:00 2012 Return-Path: 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 3296221F8512 for ; Thu, 20 Sep 2012 20:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.013 X-Spam-Level: X-Spam-Status: No, score=-104.013 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gA6syZgBO08Q for ; Thu, 20 Sep 2012 20:39:59 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2C31E21F850D for ; Thu, 20 Sep 2012 20:39:59 -0700 (PDT) Received: from mail127-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Sep 2012 03:39:57 +0000 Received: from mail127-am1 (localhost [127.0.0.1]) by mail127-am1-R.bigfish.com (Postfix) with ESMTP id AE3A98C00AA; Fri, 21 Sep 2012 03:39:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -8 X-BigFish: VS-8(zzc85fhzz1202h1d1ah1d2ahzz17326ah8275bh8275dh186M5eeeKz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1155h) Received-SPF: pass (mail127-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail127-am1 (localhost.localdomain [127.0.0.1]) by mail127-am1 (MessageSwitch) id 1348198796269534_24726; Fri, 21 Sep 2012 03:39:56 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.231]) by mail127-am1.bigfish.com (Postfix) with ESMTP id 364711000048; Fri, 21 Sep 2012 03:39:56 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Sep 2012 03:39:54 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 21 Sep 2012 03:39:41 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0318.003; Thu, 20 Sep 2012 20:39:41 -0700 From: Dave Thaler To: "draft-ietf-pcp-authentication@tools.ietf.org" Thread-Topic: Comments on draft-ietf-pcp-authentication-00 Thread-Index: Ac2XqlrsVa07B2R8SsCQbgeJj/Hesw== Date: Fri, 21 Sep 2012 03:39:40 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7C1040@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7C1040TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" Subject: [pcp] Comments on draft-ietf-pcp-authentication-00 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 03:40:00 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7C1040TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read through both authentication drafts today so they'd be fresh in my mi= nd for the meeting. My comments on draft-ietf-pcp-authentication-00 are in the marked up copy a= t http://research.microsoft.com/~dthaler/draft-ietf-pcp-authentication-00.pdf -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B7C1040TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I read through both authentication drafts today so t= hey’d be fresh in my mind for the meeting.

My comments on draft-ietf-pcp-authentication-00 are = in the marked up copy at

http://research.microsoft.com/~dthaler/= draft-ietf-pcp-authentication-00.pdf

 

-Dave

--_000_9B57C850BB53634CACEC56EF4853FF653B7C1040TK5EX14MBXW604w_-- From zhangdacheng@huawei.com Thu Sep 20 23:30:08 2012 Return-Path: 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 8349211E809C for ; Thu, 20 Sep 2012 23:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 F+PWNcf0+8gv for ; Thu, 20 Sep 2012 23:30:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8E11E808A for ; Thu, 20 Sep 2012 23:30:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKX16042; Fri, 21 Sep 2012 06:30:06 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 07:29:29 +0100 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 07:30:04 +0100 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.156]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 14:29:11 +0800 From: "Zhangdacheng (Dacheng)" To: Dave Thaler , "draft-ietf-pcp-authentication@tools.ietf.org" Thread-Topic: Comments on draft-ietf-pcp-authentication-00 Thread-Index: Ac2XqlrsVa07B2R8SsCQbgeJj/HeswAF/7tA Date: Fri, 21 Sep 2012 06:29:11 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B7C1040@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7C1040@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E39E39EEDszxeml528mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-authentication-00 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 06:30:08 -0000 --_000_C72CBD9FE3CA604887B1B3F1D145D05E39E39EEDszxeml528mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Dave. Your comments are useful for us to update the draft. From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dave = Thaler Sent: Friday, September 21, 2012 11:40 AM To: draft-ietf-pcp-authentication@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] Comments on draft-ietf-pcp-authentication-00 I read through both authentication drafts today so they'd be fresh in my mi= nd for the meeting. My comments on draft-ietf-pcp-authentication-00 are in the marked up copy a= t http://research.microsoft.com/~dthaler/draft-ietf-pcp-authentication-00.pdf -Dave --_000_C72CBD9FE3CA604887B1B3F1D145D05E39E39EEDszxeml528mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Dave. Your comments are useful for us to update the draft.=

 

From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: Friday, September 21, 2012 11:40 AM
To: draft-ietf-pcp-authentication@tools.ietf.org
Cc: pcp@ietf.org
Subject: [pcp] Comments on draft-ietf-pcp-authentication-00

 

I read through both authenticat= ion drafts today so they’d be fresh in my mind for the meeting.<= /o:p>

My comments on draft-ietf-pcp-a= uthentication-00 are in the marked up copy at

http://research.mi= crosoft.com/~dthaler/draft-ietf-pcp-authentication-00.pdf

 

-Dave

--_000_C72CBD9FE3CA604887B1B3F1D145D05E39E39EEDszxeml528mbxchi_-- From alper.yegin@yegin.org Fri Sep 21 04:05:28 2012 Return-Path: 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 2A93F21F873C for ; Fri, 21 Sep 2012 04:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 kfBCGiZFAaIC for ; Fri, 21 Sep 2012 04:05:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2A021F8734 for ; Fri, 21 Sep 2012 04:05:27 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M7p5U-1TSIfn2MMq-00vD50; Fri, 21 Sep 2012 07:05:18 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <505B5DEF.8030801@toshiba.co.jp> Date: Fri, 21 Sep 2012 14:04:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <30CCA552-891E-41AB-959C-2356198B7D1D@yegin.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> <505B35E4.5020108@toshiba.co.jp> <505B4077.3030802@toshiba.co.jp> <6CDC61E8-2811-4D44-959E-0F01BEA5C7EF@lilacglade.org> <505B5131.3000400@toshiba.co.jp> <505B5DEF.8030801@toshiba.co.jp> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:YvdENb0LdnxZCTqIH13evlA1fHC+YojOiD/BqOTLhqa zqqHeAV12BHuYYnEDCxJtUCERPgFy78tgWaN+zM8AyMRvtEuCg yP2xQrfHe060xTEzt9W5G9EYQFukUcBlT9x/odx6lkW3DPvJJ+ Z0DipDBcjXRSeePmsxZIv5z43Dhs1G43l9cn7oXITvU6EjWasR RFo5KMYqzb4h/x9BCEftlivrjqE+jWZIr6RYEF6OFBD5qBhdpA O9Ux3Yf4OtCjz1HVB+7/urJE/eGeKTaMA1d9AXQQAErhlaVg5+ m17pv8w18L5Siya4vABKk6qgIMqVuF7Jkh8DT2oQE/1mIgoFRN l9UVywIekGCR5e54xfJsEiW6XxbowH+eGW9H0v8qT7CfL8QV0d 8atTLkTL+VJ+w== Cc: pcp@ietf.org Subject: Re: [pcp] EAP retransmits and re-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 11:05:28 -0000 Sam, This whole trying to decouple authentication from authorization couldn't = more more wrong. Non-PCP-specific background: Authentication is done for the sake of authorization. The server = (whether it's the PCP server, or Foo server) does not really care if you = are really "Bob". They care what you are authorized to access. It's the = backend policy server (e.g., RADIUS server) that knows Bob --> = authorization parameters mapping.=20 So, when PCP Client is authenticated as "Bob's PC", PCP server also = learns the authorization parameters "allow him to use X ports for Y = minutes". In AAA systems, authorization always has finite lifetime (for = better resource management). Bob needs to "re-authenticate" before Y = minutes passes, otherwise his authorization is yanked. Ports are closed. = Whatever state PCP server has created/allocated for "Bob's PC" are = freed. That's it. As soon as authorized lifetime expires, PCP server stops serving the = client. That's the meaning of "lifetime" in AAA systems. You have to re-authenticate before that happens. This is how it's for any EAP-based system, this is how it's for any AAA = (RADIUS/Diameter)-based system.=20 How can you think PCP does not need re-authentication?=20 Alper On Sep 20, 2012, at 9:18 PM, Yoshihiro Ohba wrote: > Sam, >=20 > Since PCP authentication is not part of base specification, > authentication is already optional, which is fine. But when > authentication is used it needs to be tied with authorization. >=20 > Yoshihiro Ohba >=20 >=20 > (2012/09/21 2:33), Sam Hartman wrote: >> One thing to consider is that in many cases, PCP users will not be = using >> authentication; they will be using unauthenticated PCP. So, = especially >> for PCP, it seems undesirable to tie authorization to authentication. >>=20 >> If an authorization revocation event happens--that is, a service >> provider wants to stop providing service to a customer--they will >> typically want to drop both unauthenticated and authenticated = mappings. >> The sort of things that might trigger this are administrative action >> (customer account suspended for immediate cause), address = renumbering, >> or lease expire. >>=20 >> For PCP it seems much more likely that these events will be tied to a >> provisioning/authorization system than any event in an authentication >> system. >>=20 >> Tieing this to authentication seems like it will miss important PCP = use >> cases. >> Duplicating the same logic both for authentication and authorization >> seems to introduce complexity that PCP does not need. >>=20 >> --Sam >>=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Fri Sep 21 04:26:48 2012 Return-Path: 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 63B0421F878A for ; Fri, 21 Sep 2012 04:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UkRC4zOQLokS for ; Fri, 21 Sep 2012 04:26:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B357C21F8783 for ; Fri, 21 Sep 2012 04:26:47 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M3zCs-1TXEgh0xJy-00riGi; Fri, 21 Sep 2012 07:26:47 -0400 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Sep 2012 14:26:31 +0300 Message-Id: <37B8C491-AF34-42B6-9DB3-F69E2F02DE02@yegin.org> To: pcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:QujTGJPAM8MkjEw/rTr/0BllsbSj9bUAbu5SOqygn2Y tlW0hejxQbDZuXYtaat1VX1Odag+Y6UTpsmAuoV16UYucoNOh5 mYZXVTljPAhsYlsfuOvTHv8Ve0KTBRe+Pgf9U7c4MNobBmDK6p QsSCBoO4tGsASC9dNNjj3kZcQEJcIL5qZufAhcZLT7eu+DCsBw /mlJfzPUeh5MZwZwzgLEga2wqw51q1rWLwyACecMxvAZfsVdKe 9Zr4mw+S/9mYPHC/bGs5V9oiWdNuCMwxgiVeh2rQptJTqe4+JM 9Iukh3TjF42mxFi8My1rosGP/xi6isYJS7wZIIXiZ4ap/MeOGT IGi5OO7QCgUHsO3jt6sUdl22ICpbEoTMetaBFgZcCnF7xYZbIh uPwVE+2Eedp5A== Subject: [pcp] PANA vs. EAP-o-PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 11:26:48 -0000 Let me summarize why I think the WG should continue with its current = selection of PANA. + PANA is an RFC that is already adopted by other SDOs (Zigbee Alliance, = ETSI M2M, ATIS IPTV), with 2 open-source, and multiple interoperating = production implementations. + PANA already serves the need with a minor update to PANA (allocation = of 3 bits from Reserved ones), or no update at all if the WG agrees to = allow its use on native PANA port. + The only extra PANA feature that is currently not needed for PCP is = the IP Address Reconfiguration, which is a mere bit setting. So, the = protocol is lean enough. On the other hand: - EAP-o-PCP is a half-cooked clone of PANA. There's no clear = justification why it's needed when PANA is already available. It's a = half-way re-invented wheel. Why not re-use?=20 - EAP-o-PCP is an incomplete EAP lower-layer. It's not supporting = re-authentication. - The state machine and message flows of EAP-o-PCP are fundamentally = different than PCP's. It's not PCP compatible. It's in fact another = protocol that is burrowing PCP header and PCP port. That's it. It's not = going to simplify PCP, it's going to complicate PCP.=20 This story is unfolding exactly like what we had with EAP-o-DHCP, even = with the technical characteristics (state-machine mismatch, opposite = message flows, continued desire to use one's own design instead of = IETF's good-old "reuse" approach, etc.). At the end, it became such a = big waste of time/effort for anyone. Alper From alper.yegin@yegin.org Fri Sep 21 09:37:04 2012 Return-Path: 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 6D3E221F877C for ; Fri, 21 Sep 2012 09:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 csp30x2X3DC0 for ; Fri, 21 Sep 2012 09:37:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 370D521F8777 for ; Fri, 21 Sep 2012 09:37:03 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lj0D8-1TlPZH2fra-00dN5i; Fri, 21 Sep 2012 12:37:01 -0400 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Sep 2012 19:36:43 +0300 Message-Id: <12D3A1D0-1F9F-4453-BC6A-D4AD3DEFCABA@yegin.org> To: Stuart Cheshire , Dave Thaler Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:1P9xlyEUwJh+jujLfn+POqdFdLREYdm7xtqYO4Wxwzw b/zndm37ity513wNIfXWEHmlYYoVWsp23B3Oa2Z1mWz+Db78zR l/4KoQqw8fMR3kzHNWk1GKwOG+vZRa1svn3v64rDp0Xtf9fOBz 8OPmr7Wu7X2+yxx8iCnpukH9zyam9Ys3VP+WuNZr6PLcB6zGO0 mqbE89IPLk3IfNDTkJv8GGGG6hRg63XoluzH6cqWI1Ottjf+VW hTF2oS/HT69CLfPbX8gO8rzUPsnN5A5cI373oZD2zf+eFf05OU COVizZozjovg4Xl3cBsMIpIEmUqvEkywUU7o+dj02JH/3egk/K IOMYVamOp53KA6dSOQE2pQ8p3DX6qGI/c3j3JJa0aX2jPvOgYB XDzGiSybR0fbQ== Cc: pcp@ietf.org Subject: [pcp] Same vs different port X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 16:37:04 -0000 Hello, I didn't want to use precious CC time on this, but I'm under the = impression that the reasons used for ruling out running PANA and PCP = over their dedicated ports are not plausible.=20 I wasn't on the jabber at previous IETF, so maybe I missed some of the = discussions. But from today's discussion, here's what I heard: Following points were raised about running PANA and PCP over their = dedicated ports (as opposed to running both over the PCP port): 1. Binding 2. Server discovery 3. Management=20 Anything else? For (1) binding, whether it's crypto-binding, or state-binding, whatever = you call it -- one does not have to run the two protocols on the same = port to achieve any of that. In fact, it is achieved thru use of common = identifiers. The authenticated entity is provided a "session id" which = gets used over PCP to indicate who the sender is.=20 Using the same port is irrelevant. For (2) server discovery, we're going with the PAA and PCP Server = running on the same node assumption. However PCP server is discovered = automatically reveals where the PAA is. Using the same port does not add = any value here. For (3) Stuart made a reference to complications, but I'd appreciate = some more elaboration.=20 =20 Comments appreciated. Alper From internet-drafts@ietf.org Sun Sep 23 23:08:07 2012 Return-Path: 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 4953021F8574; Sun, 23 Sep 2012 23:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] 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 pzUjf0Xd8OFX; Sun, 23 Sep 2012 23:08:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938A021F84F3; Sun, 23 Sep 2012 23:08:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120924060806.14521.65231.idtracker@ietfa.amsl.com> Date: Sun, 23 Sep 2012 23:08:06 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-04.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 06:08:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : Universal Plug and Play (UPnP) Internet Gateway Device (= IGD)-Port Control Protocol (PCP) Interworking Function Author(s) : Mohamed Boucadair Francis Dupont Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-upnp-igd-interworking-04.txt Pages : 24 Date : 2012-09-23 Abstract: This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. An UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP (Customer Premises) routers to allow for transparent NAT control in environments where UPnP IGD is used in the LAN side and PCP in the external side of the CP router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-upnp-igd-interworking-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-upnp-igd-interworking-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Mon Sep 24 05:14:43 2012 Return-Path: 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 B8DF821F860E for ; Mon, 24 Sep 2012 05:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 TGm9MqNoxCVO for ; Mon, 24 Sep 2012 05:14:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 07AA521F85EF for ; Mon, 24 Sep 2012 05:14:43 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 17A083B443C for ; Mon, 24 Sep 2012 14:14:42 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id F1938238076 for ; Mon, 24 Sep 2012 14:14:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 24 Sep 2012 14:14:41 +0200 From: To: "pcp@ietf.org" Date: Mon, 24 Sep 2012 14:14:41 +0200 Thread-Topic: draft-boucadair-pcp-nat64-experiments Thread-Index: Ac2aSy37fcbQQydoRI2D0m677paobwAAFg1w Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B123A13@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.24.101516 Cc: AIT ABDESSELAM Mehdi RD-CORE , QUEIROZ Jaqueline RD-CORE Subject: [pcp] draft-boucadair-pcp-nat64-experiments X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 12:14:43 -0000 Dear all, We submitted this new I-D.=20 Comments and questions are welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : lundi 24 septembre 2012 13:53 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-pcp-nat64-experiments-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PCP NAT64 Experiments Author(s) : Mehdi Ait Abdesselam Mohamed Boucadair Amina Hasnaoui Jaqueline Queiroz Filename : draft-boucadair-pcp-nat64-experiments-00.txt Pages : 23 Date : 2012-09-24 Abstract: This memo documents a set of PCP experiments conducted in NAT64 environment. Two services are detailed in the document: access to a video server behind NAT64 and SIP-based sessions. Both 3G and Wi-Fi IPv6-only connectivity have been used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-nat64-experiments There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From yoshihiro.ohba@toshiba.co.jp Mon Sep 24 16:52:41 2012 Return-Path: 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 E39D721F8809 for ; Mon, 24 Sep 2012 16:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.345 X-Spam-Level: X-Spam-Status: No, score=-4.345 tagged_above=-999 required=5 tests=[AWL=-1.745, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 W9uo4+fXWrF8 for ; Mon, 24 Sep 2012 16:52:41 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 396B021F8807 for ; Mon, 24 Sep 2012 16:52:40 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q8ONqdXg003665 for ; Tue, 25 Sep 2012 08:52:39 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q8ONqdDx009974 for pcp@ietf.org; Tue, 25 Sep 2012 08:52:39 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA09966; Tue, 25 Sep 2012 08:52:38 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q8ONqXw0003255 for ; Tue, 25 Sep 2012 08:52:33 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8ONqX5u027536; Tue, 25 Sep 2012 08:52:33 +0900 (JST) Received: from [133.196.20.74] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAV00FD8OZL4W20@mail.po.toshiba.co.jp> for pcp@ietf.org; Tue, 25 Sep 2012 08:52:33 +0900 (JST) Date: Tue, 25 Sep 2012 08:52:35 +0900 From: Yoshihiro Ohba To: "pcp@ietf.org" Message-id: <5060F243.6080804@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: [pcp] PCP Version 0 header format X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 23:52:42 -0000 While I am working on writing a new I-D for encapsulation approach after the last interim meeting, I would like to also update side-by-side approach (draft-ohba-pcp-pana) if any update is needed. Is Version 0 of PCP already implemented in shipped products? If so, what is the header format (especially the first 16 bits) being used for them? Regards, Yoshihiro Ohba From dthaler@microsoft.com Mon Sep 24 16:56:27 2012 Return-Path: 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 C3B1D1F042B for ; Mon, 24 Sep 2012 16:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.997 X-Spam-Level: X-Spam-Status: No, score=-103.997 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 v0h+Q1Wa-LlN for ; Mon, 24 Sep 2012 16:56:27 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 379891F041D for ; Mon, 24 Sep 2012 16:56:27 -0700 (PDT) Received: from mail160-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Sep 2012 23:56:26 +0000 Received: from mail160-ch1 (localhost [127.0.0.1]) by mail160-ch1-R.bigfish.com (Postfix) with ESMTP id 398E62E00BD; Mon, 24 Sep 2012 23:56:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M1432Izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received-SPF: pass (mail160-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail160-ch1 (localhost.localdomain [127.0.0.1]) by mail160-ch1 (MessageSwitch) id 1348530984665561_4918; Mon, 24 Sep 2012 23:56:24 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail160-ch1.bigfish.com (Postfix) with ESMTP id 9F409120079; Mon, 24 Sep 2012 23:56:24 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Sep 2012 23:56:24 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 24 Sep 2012 23:56:23 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 24 Sep 2012 16:56:22 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0318.003; Mon, 24 Sep 2012 16:56:23 -0700 From: Dave Thaler To: Yoshihiro Ohba , "pcp@ietf.org" Thread-Topic: [pcp] PCP Version 0 header format Thread-Index: AQHNmq+znAIjqCAeB0eGtTUjVXhyi5eaKrAg Date: Mon, 24 Sep 2012 23:56:21 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7CE84E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <5060F243.6080804@toshiba.co.jp> In-Reply-To: <5060F243.6080804@toshiba.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] PCP Version 0 header format X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 23:56:27 -0000 See http://tools.ietf.org/html/draft-cheshire-nat-pmp -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Yoshihiro Ohba > Sent: Monday, September 24, 2012 4:53 PM > To: pcp@ietf.org > Subject: [pcp] PCP Version 0 header format >=20 > While I am working on writing a new I-D for encapsulation approach after > the last interim meeting, I would like to also update side-by-side approa= ch > (draft-ohba-pcp-pana) if any update is needed. >=20 > Is Version 0 of PCP already implemented in shipped products? If so, what= is > the header format (especially the first 16 bits) being used for them? >=20 > Regards, > Yoshihiro Ohba >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From stephen.farrell@cs.tcd.ie Mon Sep 24 17:05:00 2012 Return-Path: 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 20F2C1F0C51 for ; Mon, 24 Sep 2012 17:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ZhtPa-a46GoP for ; Mon, 24 Sep 2012 17:04:59 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C6BEA1F041D for ; Mon, 24 Sep 2012 17:04:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B8900171480; Tue, 25 Sep 2012 01:04:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1348531496; bh=A4OFfEVQKS7hvT Mw3CbjN31oo8aF8ReJQIoNIkHS25U=; b=rILji1rGbHOmaZkpZP8xZ+wPwg1yPG fo7XRejB0gFDCRkq5viwhC7+WVphrq3KABVOxVDQuifGKR6cf+fzJZ6pepdYQR8t 0mFQCNAHq9yYPHjIZDviWhYR/6bme1dDOJXdiIwQql5+jQMV69trFhL5iLLw9H5a p9XySa/VnfEd3Ab/PzSKS97I1NROosUpgVxrgqvRKUJ/YMX4FJVGBXF3kXQCthvs EmOLkcsa1JkTkCtb5T5RQndlDVJNgFi/Ps4guVHEdFgtPyf38iuWiafufOoJyOS1 D8UVZKxfJSs1z3lsO8yuAu5ZHMpF2NHlRXOg8VvQ83EmgfXUkKDIDavg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Nk8XsYTfMYyT; Tue, 25 Sep 2012 01:04:56 +0100 (IST) Received: from [10.87.48.8] (unknown [86.46.22.78]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 56C4117147E; Tue, 25 Sep 2012 01:04:54 +0100 (IST) Message-ID: <5060F525.6020601@cs.tcd.ie> Date: Tue, 25 Sep 2012 01:04:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: pcp-ads@tools.ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 00:05:00 -0000 Hi, On first reading, Sam's analysis that a real vulnerability is introduced by this change seems correct to me. If that is so (is it?) then I do think this change warrants further discussion. Ta, S. On 09/23/2012 07:37 PM, Sam Hartman wrote: > > Hi. > draft-ietf-pcp-base-27 relaxes restrictions in the simple threat model > (section 18.1). > In particular, it permits the lifetime of a mapping to be reduced or a > mapping to be deleted. > > I understand that reducing the lifetime of mappings is useful, and think > that many deployments that implement a security mechanism (and thus > fall under the advanced threat model) will choose to have a relaxed > authorization policy about deleting mappings. > I think the mapping nonce changes introduced in pcp-base-27 will help > make that possible. > > However, for the simple threat model our goal is not to decrease the > security of the Internet by deploying a PCP server. > We fail to accomplish that. > > Here's an example of an attack where enabling PCP decreases the security > of a network. > > N1 is a NAT with PCP capability. > > N2 is a NAT without PCP capability. > > H1 and H2 are hosts behind N2.; N2 is behind N1. > That is, the path from H1 or H2 to the Internet looks like > {H1,H2}->N2->N1. > > From the standpoint of N1, H1 and H2 have the same internal address. > That permits H1 and H2 to create mappings on each others' behalf. > However, H1 and H2 cannot spoof each others' IP addresses from the > standpoint of N2. For example, H1 and H2 might be on different internal > subnets or address spoofing prevention may be in use. > > H1 is a host that either does not support PCP or follows the spec > recommendation not to use PCP through a NAT that does not support PCP. > > H2 would like to capture H1's traffic. > H2 guesses that some traffic will be sent from H1 towards x. H2 > guesses that port P will be used as the external port on N2 (the > internal port from N1's standpoint). > So, N1 will see traffic from towards x. > Before H1 sends this traffic, H2 requests a PCP mapping for ; it > could use either the map or peer opcode. > This traffic is mapped to appear to come from . > > Later, H2 wants to capture the reply traffic; because H2 created the > mapping, H2 knows the mapping nonce and can delete the mapping. > > Now, H2 needs to convince N1 to allocate Q such that traffic to > will eventually make its way to H2. > That depends on attacking N1's port allocation algorithm. This is > probably not an attack H2 can mount with 100% chance of success. > However by using multiple mappings to amplify the attack, trying to > exploit any races in N1, etc. > This is the kind of attack that looks hard until someone has it working, > then becomes very easy. > > If N1 disables PCP, the attack is impossible if H1 sends traffic often > enough to keep the mapping alive. > This is just one attack I found while not looking very hard. > I don't have time to perform detailed security analysis on this change, > but I have fairly high confidence that it does introduce harm. I suspect > that if we look we'll find other attacks. > > If I end up in the rough within the working group and we send this > change to the IESG, I believe a new IETF last call is > required. Typically a protocol like PCP would be required to have a > mandatory-to-implement security mechanism according to BCP 61. We have > tried to strike a compromise to permit PCP to move forward more quickly > than the security mechanism work. Many people have reviewed PCP; this > has been discussed widely in the security community and elsewhere. If > the working group is going to change this compromise after IESG review, > the IETF needs to be given a change to re-review and to suggest > balancing changes and debate questions like whether PCP should be > required to have a BCP 61 security mechanism. > From hartmans@mit.edu Mon Sep 24 17:10:52 2012 Return-Path: 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 BBA9B21F8862 for ; Mon, 24 Sep 2012 17:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.388 X-Spam-Level: **** X-Spam-Status: No, score=4.388 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 AnYqHT7hYdAm for ; Mon, 24 Sep 2012 17:10:50 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4B021F885D for ; Mon, 24 Sep 2012 17:10:49 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A940820155 for ; Mon, 24 Sep 2012 20:10:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E408D414A; Mon, 24 Sep 2012 20:10:09 -0400 (EDT) From: Sam Hartman To: pcp@ietf.org Date: Mon, 24 Sep 2012 20:10:09 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 00:10:52 -0000 --=-=-= I noticed that my original message never seems to have hit the list. Let's see if this goes better. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline X-From-Line: nobody Sun Sep 23 14:37:56 2012 From: Sam Hartman To: pcp@ietf.org Cc: pcp-ads@tools.ietf.org, stephen.farrell@cs.tcd.ie Subject: draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-Draft-From: ("inbox.painless-security") Date: Sun, 23 Sep 2012 14:37:56 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) Lines: 77 Xref: live misc-mail:36645 MIME-Version: 1.0 Hi. draft-ietf-pcp-base-27 relaxes restrictions in the simple threat model (section 18.1). In particular, it permits the lifetime of a mapping to be reduced or a mapping to be deleted. I understand that reducing the lifetime of mappings is useful, and think that many deployments that implement a security mechanism (and thus fall under the advanced threat model) will choose to have a relaxed authorization policy about deleting mappings. I think the mapping nonce changes introduced in pcp-base-27 will help make that possible. However, for the simple threat model our goal is not to decrease the security of the Internet by deploying a PCP server. We fail to accomplish that. Here's an example of an attack where enabling PCP decreases the security of a network. N1 is a NAT with PCP capability. N2 is a NAT without PCP capability. H1 and H2 are hosts behind N2.; N2 is behind N1. That is, the path from H1 or H2 to the Internet looks like {H1,H2}->N2->N1. > From the standpoint of N1, H1 and H2 have the same internal address. That permits H1 and H2 to create mappings on each others' behalf. However, H1 and H2 cannot spoof each others' IP addresses from the standpoint of N2. For example, H1 and H2 might be on different internal subnets or address spoofing prevention may be in use. H1 is a host that either does not support PCP or follows the spec recommendation not to use PCP through a NAT that does not support PCP. H2 would like to capture H1's traffic. H2 guesses that some traffic will be sent from H1 towards x. H2 guesses that port P will be used as the external port on N2 (the internal port from N1's standpoint). So, N1 will see traffic from towards x. Before H1 sends this traffic, H2 requests a PCP mapping for ; it could use either the map or peer opcode. This traffic is mapped to appear to come from . Later, H2 wants to capture the reply traffic; because H2 created the mapping, H2 knows the mapping nonce and can delete the mapping. Now, H2 needs to convince N1 to allocate Q such that traffic to will eventually make its way to H2. That depends on attacking N1's port allocation algorithm. This is probably not an attack H2 can mount with 100% chance of success. However by using multiple mappings to amplify the attack, trying to exploit any races in N1, etc. This is the kind of attack that looks hard until someone has it working, then becomes very easy. If N1 disables PCP, the attack is impossible if H1 sends traffic often enough to keep the mapping alive. This is just one attack I found while not looking very hard. I don't have time to perform detailed security analysis on this change, but I have fairly high confidence that it does introduce harm. I suspect that if we look we'll find other attacks. If I end up in the rough within the working group and we send this change to the IESG, I believe a new IETF last call is required. Typically a protocol like PCP would be required to have a mandatory-to-implement security mechanism according to BCP 61. We have tried to strike a compromise to permit PCP to move forward more quickly than the security mechanism work. Many people have reviewed PCP; this has been discussed widely in the security community and elsewhere. If the working group is going to change this compromise after IESG review, the IETF needs to be given a change to re-review and to suggest balancing changes and debate questions like whether PCP should be required to have a BCP 61 security mechanism. --=-=-=-- From yoshihiro.ohba@toshiba.co.jp Mon Sep 24 18:33:16 2012 Return-Path: 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 E35981F0CAF for ; Mon, 24 Sep 2012 18:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.74 X-Spam-Level: X-Spam-Status: No, score=-6.74 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 uRvNQVOa75XY for ; Mon, 24 Sep 2012 18:33:16 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id B72E81F0C9C for ; Mon, 24 Sep 2012 18:33:15 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8P1XCoe022607; Tue, 25 Sep 2012 10:33:12 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8P1XCXe001500; Tue, 25 Sep 2012 10:33:12 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id LAA01499; Tue, 25 Sep 2012 10:33:12 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8P1X7YO007820; Tue, 25 Sep 2012 10:33:12 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8P1X65b023983; Tue, 25 Sep 2012 10:33:07 +0900 (JST) Received: from [133.196.20.74] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAV00FS1TN64X70@mail.po.toshiba.co.jp>; Tue, 25 Sep 2012 10:33:06 +0900 (JST) Date: Tue, 25 Sep 2012 10:33:08 +0900 From: Yoshihiro Ohba In-reply-to: <9B57C850BB53634CACEC56EF4853FF653B7CE84E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler Message-id: <506109D4.6080808@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <5060F243.6080804@toshiba.co.jp> <9B57C850BB53634CACEC56EF4853FF653B7CE84E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP Version 0 header format X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 01:33:17 -0000 (2012/09/25 8:56), Dave Thaler wrote: > See http://tools.ietf.org/html/draft-cheshire-nat-pmp > Thank you for the link. Considering NAT-PMP, using bit 0 is better than bits 5-6-7 for demultiplexing. Yoshihiro Ohba > -Dave > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> Yoshihiro Ohba >> Sent: Monday, September 24, 2012 4:53 PM >> To: pcp@ietf.org >> Subject: [pcp] PCP Version 0 header format >> >> While I am working on writing a new I-D for encapsulation approach after >> the last interim meeting, I would like to also update side-by-side approach >> (draft-ohba-pcp-pana) if any update is needed. >> >> Is Version 0 of PCP already implemented in shipped products? If so, what is >> the header format (especially the first 16 bits) being used for them? >> >> Regards, >> Yoshihiro Ohba >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > > From simon.perreault@viagenie.ca Tue Sep 25 06:06:09 2012 Return-Path: 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 E066621F84B2 for ; Tue, 25 Sep 2012 06:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 UQW5Xz3HyGBh for ; Tue, 25 Sep 2012 06:06:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E412D21F84B5 for ; Tue, 25 Sep 2012 06:06:08 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f8cf:a881:e8cc:3ea9]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 51874415A9 for ; Tue, 25 Sep 2012 09:06:08 -0400 (EDT) Message-ID: <5061AC3F.9010207@viagenie.ca> Date: Tue, 25 Sep 2012 09:06:07 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: pcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 13:06:10 -0000 Here's an easy fix idea: an unauthenticated delete (with matching nonce) would do the equivalent of a TCP RST (with matching sequence number). That is, it would reduce the mapping's lifetime to what a TCP RST would reduce it to (which depends on the implementation but usually is not zero). In fact, the TCP RST lifetime would become sort of a floor lifetime below which mappings cannot be reduced. Once a mapping has attained this lifetime, all that can be done is either increase the lifetime or wait for the mapping to expire. That way, unauthenticated delete would still be useful while also preserving current NAT behaviour and thus eliminating this class of attacks. Simon Le 2012-09-24 20:10, Sam Hartman a écrit : > Hi. > draft-ietf-pcp-base-27 relaxes restrictions in the simple threat model > (section 18.1). > In particular, it permits the lifetime of a mapping to be reduced or a > mapping to be deleted. > > I understand that reducing the lifetime of mappings is useful, and think > that many deployments that implement a security mechanism (and thus > fall under the advanced threat model) will choose to have a relaxed > authorization policy about deleting mappings. > I think the mapping nonce changes introduced in pcp-base-27 will help > make that possible. > > However, for the simple threat model our goal is not to decrease the > security of the Internet by deploying a PCP server. > We fail to accomplish that. > > Here's an example of an attack where enabling PCP decreases the security > of a network. > > N1 is a NAT with PCP capability. > > N2 is a NAT without PCP capability. > > H1 and H2 are hosts behind N2.; N2 is behind N1. > That is, the path from H1 or H2 to the Internet looks like > {H1,H2}->N2->N1. > >> > From the standpoint of N1, H1 and H2 have the same internal address. > That permits H1 and H2 to create mappings on each others' behalf. > However, H1 and H2 cannot spoof each others' IP addresses from the > standpoint of N2. For example, H1 and H2 might be on different internal > subnets or address spoofing prevention may be in use. > > H1 is a host that either does not support PCP or follows the spec > recommendation not to use PCP through a NAT that does not support PCP. > > H2 would like to capture H1's traffic. > H2 guesses that some traffic will be sent from H1 towards x. H2 > guesses that port P will be used as the external port on N2 (the > internal port from N1's standpoint). > So, N1 will see traffic from towards x. > Before H1 sends this traffic, H2 requests a PCP mapping for ; it > could use either the map or peer opcode. > This traffic is mapped to appear to come from . > > Later, H2 wants to capture the reply traffic; because H2 created the > mapping, H2 knows the mapping nonce and can delete the mapping. > > Now, H2 needs to convince N1 to allocate Q such that traffic to > will eventually make its way to H2. > That depends on attacking N1's port allocation algorithm. This is > probably not an attack H2 can mount with 100% chance of success. > However by using multiple mappings to amplify the attack, trying to > exploit any races in N1, etc. > This is the kind of attack that looks hard until someone has it working, > then becomes very easy. > > If N1 disables PCP, the attack is impossible if H1 sends traffic often > enough to keep the mapping alive. > This is just one attack I found while not looking very hard. > I don't have time to perform detailed security analysis on this change, > but I have fairly high confidence that it does introduce harm. I suspect > that if we look we'll find other attacks. > > If I end up in the rough within the working group and we send this > change to the IESG, I believe a new IETF last call is > required. Typically a protocol like PCP would be required to have a > mandatory-to-implement security mechanism according to BCP 61. We have > tried to strike a compromise to permit PCP to move forward more quickly > than the security mechanism work. Many people have reviewed PCP; this > has been discussed widely in the security community and elsewhere. If > the working group is going to change this compromise after IESG review, > the IETF needs to be given a change to re-review and to suggest > balancing changes and debate questions like whether PCP should be > required to have a BCP 61 security mechanism. -- 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 From simon.perreault@viagenie.ca Tue Sep 25 06:26:37 2012 Return-Path: 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 4970A21F8690 for ; Tue, 25 Sep 2012 06:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 3dqLLgC61Yoa for ; Tue, 25 Sep 2012 06:26:36 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D11721F868A for ; Tue, 25 Sep 2012 06:26:36 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f8cf:a881:e8cc:3ea9]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0511145C50; Tue, 25 Sep 2012 09:26:33 -0400 (EDT) Message-ID: <5061B109.8060305@viagenie.ca> Date: Tue, 25 Sep 2012 09:26:33 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Sam Hartman References: <5061AC3F.9010207@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 13:26:37 -0000 Le 2012-09-25 09:16, Sam Hartman a écrit : > Simon> Here's an easy fix idea: an unauthenticated delete (with > Simon> matching nonce) would do the equivalent of a TCP RST (with > Simon> matching sequence number). That is, it would reduce the > Simon> mapping's lifetime to what a TCP RST would reduce it to > Simon> (which depends on the implementation but usually is not > Simon> zero). > > First, this clearly only works for TCP. The same behaviour can be specified no matter what the transport protocol is. > However, in my situation, could H2 actually send a TCP RST? The mapping > at N2 is to H1 not to H2. While H2 can appear to be from the same > address as H1 from the vantage of N1, it cannot use the same ports. That is besides the point. My point is that RST spoofing is a well-known attack that current NATs know how to deal with, and I'm proposing that the same mitigation technique could be applied to the PCP attack you described. 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 From hartmans@painless-security.com Tue Sep 25 06:27:19 2012 Return-Path: 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 DB58321F8694 for ; Tue, 25 Sep 2012 06:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.383 X-Spam-Level: **** X-Spam-Status: No, score=4.383 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 cSaE29fc9LY0 for ; Tue, 25 Sep 2012 06:27:19 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 110AF21F8690 for ; Tue, 25 Sep 2012 06:27:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4DF5F20146; Tue, 25 Sep 2012 09:16:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 330C6414A; Tue, 25 Sep 2012 09:16:20 -0400 (EDT) From: Sam Hartman To: Simon Perreault References: <5061AC3F.9010207@viagenie.ca> Date: Tue, 25 Sep 2012 09:16:20 -0400 In-Reply-To: <5061AC3F.9010207@viagenie.ca> (Simon Perreault's message of "Tue, 25 Sep 2012 09:06:07 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 13:27:20 -0000 >>>>> "Simon" == Simon Perreault writes: Simon> Here's an easy fix idea: an unauthenticated delete (with Simon> matching nonce) would do the equivalent of a TCP RST (with Simon> matching sequence number). That is, it would reduce the Simon> mapping's lifetime to what a TCP RST would reduce it to Simon> (which depends on the implementation but usually is not Simon> zero). First, this clearly only works for TCP. However, in my situation, could H2 actually send a TCP RST? The mapping at N2 is to H1 not to H2. While H2 can appear to be from the same address as H1 from the vantage of N1, it cannot use the same ports. So, I still believe that PCP creates new attacks. From simon.perreault@viagenie.ca Tue Sep 25 06:33:38 2012 Return-Path: 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 72E6721F84D4 for ; Tue, 25 Sep 2012 06:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 YsBafGvIxGuR for ; Tue, 25 Sep 2012 06:33:37 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D0F0621F84D1 for ; Tue, 25 Sep 2012 06:33:37 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f8cf:a881:e8cc:3ea9]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2150045C50 for ; Tue, 25 Sep 2012 09:33:37 -0400 (EDT) Message-ID: <5061B2B0.3000509@viagenie.ca> Date: Tue, 25 Sep 2012 09:33:36 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: pcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 13:33:38 -0000 Le 2012-09-24 20:10, Sam Hartman a écrit : > Later, H2 wants to capture the reply traffic; because H2 created the > mapping, H2 knows the mapping nonce and can delete the mapping. > > Now, H2 needs to convince N1 to allocate Q such that traffic to > will eventually make its way to H2. > That depends on attacking N1's port allocation algorithm. This is > probably not an attack H2 can mount with 100% chance of success. > However by using multiple mappings to amplify the attack, trying to > exploit any races in N1, etc. > This is the kind of attack that looks hard until someone has it working, > then becomes very easy. Another thought: once H2 deletes the mapping, the external port will be unusable for 120 seconds. See the last paragraph of section 15: To reduce unwanted traffic and data corruption, External UDP and TCP ports created by the MAP Opcode or PEER Opcode SHOULD NOT be re-used for the same interval enforced by NAT for implicitly creating mappings, which is typically the maximum segment lifetime interval of 120 seconds [RFC0793]. IMHO this needs to be mentioned as it can make the attack much harder to accomplish. 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 From hartmans@painless-security.com Tue Sep 25 06:37:18 2012 Return-Path: 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 EACFD21F8834 for ; Tue, 25 Sep 2012 06:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.378 X-Spam-Level: **** X-Spam-Status: No, score=4.378 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] 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 D0y2xeNT5VRe for ; Tue, 25 Sep 2012 06:37:18 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8A121F882F for ; Tue, 25 Sep 2012 06:37:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 14EA020146; Tue, 25 Sep 2012 09:37:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8FD1D414A; Tue, 25 Sep 2012 09:36:38 -0400 (EDT) From: Sam Hartman To: Simon Perreault References: <5061AC3F.9010207@viagenie.ca> <5061B109.8060305@viagenie.ca> Date: Tue, 25 Sep 2012 09:36:38 -0400 In-Reply-To: <5061B109.8060305@viagenie.ca> (Simon Perreault's message of "Tue, 25 Sep 2012 09:26:33 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 13:37:19 -0000 >>>>> "Simon" == Simon Perreault writes: >> However, in my situation, could H2 actually send a TCP RST? The >> mapping at N2 is to H1 not to H2. While H2 can appear to be from >> the same address as H1 from the vantage of N1, it cannot use the >> same ports. Simon> That is besides the point. My point is that RST spoofing is a Simon> well-known attack that current NATs know how to deal with, Simon> and I'm proposing that the same mitigation technique could be Simon> applied to the PCP attack you described. I agree the mittigation technique you describe makes things bettter. However we're still in a situation where deploying PCP decreases security. I'm happy with that situation if we have a mandatory-to-implement security mechanism but not otherwise. From dwing@cisco.com Tue Sep 25 07:19:27 2012 Return-Path: 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 9F2CE21F87B6 for ; Tue, 25 Sep 2012 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 grFWUqw0sxV6 for ; Tue, 25 Sep 2012 07:19:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 129C921F8557 for ; Tue, 25 Sep 2012 07:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1704; q=dns/txt; s=iport; t=1348582767; x=1349792367; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=y8gRuugEIBh+ck0HTgiCG/uKvbZ4LU1/uuLeSdjg63M=; b=e4ZK7MjfEKXq5xJX3+1oJEKRGXRuE2Nf+Kn00BuxFsBIr+yHYbNppS5l ceX+MDygeI7g+nXXWNsu+WQqsCkfMDTp++zTreuJbtSenR/3UHBObSgtc T4/YhfUOPZ+9iQeSv3BGpSwaSEHRiqs/qfXZtH7UsJ0I8Q5im+zdaAFgB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEJAEq8YVCtJV2b/2dsb2JhbABFrkSMVYJABIENgQiCIAEBAQQICgEXTw0DAgkPCSMLGSMbAQEEAR0Xh2OYWI9XkHiLdIVpA4ghNYURljmBaYMH X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="125119543" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 25 Sep 2012 14:19:26 +0000 Received: from dwingWS ([10.32.240.194]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8PEJQcN020255; Tue, 25 Sep 2012 14:19:26 GMT From: "Dan Wing" To: "'Simon Perreault'" , "'Sam Hartman'" References: <5061AC3F.9010207@viagenie.ca> <5061B109.8060305@viagenie.ca> In-Reply-To: <5061B109.8060305@viagenie.ca> Date: Tue, 25 Sep 2012 07:19:24 -0700 Message-ID: <20b301cd9b28$c42f1730$4c8d4590$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2bIWVWtdUOQ3igSUy5th2vEtwgzgABvdpA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 14:19:27 -0000 Simon Perreault wrote: > Le 2012-09-25 09:16, Sam Hartman a =E9crit : > > Simon> Here's an easy fix idea: an unauthenticated delete (with > > Simon> matching nonce) would do the equivalent of a TCP RST > (with > > Simon> matching sequence number). That is, it would reduce the > > Simon> mapping's lifetime to what a TCP RST would reduce it to > > Simon> (which depends on the implementation but usually is not > > Simon> zero). > > > > First, this clearly only works for TCP. >=20 > The same behaviour can be specified no matter what the transport > protocol is. >=20 > > However, in my situation, could H2 actually send a TCP RST? The > mapping > > at N2 is to H1 not to H2. While H2 can appear to be from the same > > address as H1 from the vantage of N1, it cannot use the same ports. >=20 > That is besides the point. My point is that RST spoofing is a well- > known > attack that current NATs know how to deal with, and I'm proposing that > the same mitigation technique could be applied to the PCP attack you > described. That mitigation is already in pcp-base-27 (and was in earlier versions, but not nearly as clear). pcp-base-27 says: 15.2. Lifetime Processing for the PEER Opcode The assigned lifetime MUST NOT be shorter than the lifetime the PCP- controlled device uses for an implicitly-created mapping with active bi-directional traffic (e.g., a NAT device might use 2-5 minutes for UDP [RFC4787], and might use 2 hours 4 minutes [RFC5382] for established TCP sessions). If the Requested Lifetime is outside that range, the mapping lifetime is assigned to the value within the range. -d From alper.yegin@yegin.org Tue Sep 25 07:29:07 2012 Return-Path: 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 A79E521F8512 for ; Tue, 25 Sep 2012 07:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.607 X-Spam-Level: X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] 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 OHo1vyorV45C for ; Tue, 25 Sep 2012 07:29:07 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD3321F850D for ; Tue, 25 Sep 2012 07:29:07 -0700 (PDT) Received: from [10.10.10.126] ([112.168.62.118]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lg1Ct-1TnaYN1j4N-00pCFG; Tue, 25 Sep 2012 10:29:06 -0400 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 25 Sep 2012 03:37:02 +0300 Message-Id: <39999FCF-B9BF-4EF9-8617-AEAC18C5B234@yegin.org> To: pcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:qKMOLcOipVyt+UmC844fphcbfqbr/akgvkUEqrlRpA1 LyNVJJlbVu2S6uV2W9JiDxJrUu8FHkAvjjaQJzEMnQPfkXQXT+ rIQq1vHjXSTttN3tpxckv7kNFlMZE3uRhO7YSTTNEBb7mIU8JH e5QGvzmuHLvCn+auJalNK9g7ICzFQhh7qb+KMlfLtb8/ZLFoln ptPrvTHTQ9hMMuPZZD+Ks+nqWII75p3Ua8SCCfhQITtTvU0cdQ clIQB/g8rTotR+1dv7+k5gThTHB2QbXEb7JPy09JmmSmuVMUxN 5iZrn7o16SVSW4+/55b6H40ZT1pLCzrb+lN0KKXs3KfHIZCsxl yOsYs073vzQygmTc+CLT7u170n1zL8R5XtTBQ76wTGTKBULI4/ oF5TzC2Z0Cr0Q== Subject: [pcp] pcp version 0 and version 1 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 14:29:07 -0000 Hello, Which specs define PCP version 0 and PCP version 1? Alper From simon.perreault@viagenie.ca Tue Sep 25 07:30:55 2012 Return-Path: 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 6436221F892A for ; Tue, 25 Sep 2012 07:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 equJD5rpBLFX for ; Tue, 25 Sep 2012 07:30:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B141C21F84EC for ; Tue, 25 Sep 2012 07:30:54 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f8cf:a881:e8cc:3ea9]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 124EA415A9; Tue, 25 Sep 2012 10:30:54 -0400 (EDT) Message-ID: <5061C01D.7020505@viagenie.ca> Date: Tue, 25 Sep 2012 10:30:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Dan Wing References: <5061AC3F.9010207@viagenie.ca> <5061B109.8060305@viagenie.ca> <20b301cd9b28$c42f1730$4c8d4590$@com> In-Reply-To: <20b301cd9b28$c42f1730$4c8d4590$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 14:30:55 -0000 Le 2012-09-25 10:19, Dan Wing a écrit : >> That is besides the point. My point is that RST spoofing is a well- >> known >> attack that current NATs know how to deal with, and I'm proposing that >> the same mitigation technique could be applied to the PCP attack you >> described. > > That mitigation is already in pcp-base-27 (and was in earlier versions, > but not nearly as clear). pcp-base-27 says: > > 15.2. Lifetime Processing for the PEER Opcode > > The assigned lifetime MUST NOT be shorter than the lifetime the PCP- > controlled device uses for an implicitly-created mapping with active > bi-directional traffic (e.g., a NAT device might use 2-5 minutes for > UDP [RFC4787], and might use 2 hours 4 minutes [RFC5382] for > established TCP sessions). If the Requested Lifetime is outside that > range, the mapping lifetime is assigned to the value within the > range. Right, but that's for PEER only. Sam said the attacker could use either MAP or PEER. 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 From dwing@cisco.com Tue Sep 25 07:55:26 2012 Return-Path: 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 0C1FC21F87FC for ; Tue, 25 Sep 2012 07:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Ih91j1SAFQfr for ; Tue, 25 Sep 2012 07:55:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6DD21F87F9 for ; Tue, 25 Sep 2012 07:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1486; q=dns/txt; s=iport; t=1348584925; x=1349794525; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=SvA/Avty2Fw68l3cXlvfon/TbSBdDGXG6wPXiJS6b6Y=; b=P0FAcGnrvZRaz+ZLYvNdJIyy6ijqKrHdOTGZr2D24gldLCWAw/y1b/f5 L9A4wRVuofiFl/CwjploZi5CL6u6HDuilwI791Gju6KKVUxUyZMgZTC21 iHMdV3NPerJ88RaPzpqzzX7kvnJ9Igpr/MWnT1srAN+6S8/BtUhICkEiL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQJAGLFYVCtJV2d/2dsb2JhbABFrkSPFQSBDYEIgiABAQEDAQgKARdPBQcBAwIJDwIEAQEkBAcZIwoJCAEBBBMLF4ddBphxj1eQeIsbWYVpA4ghNYURljmBaYMH X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="125082608" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 25 Sep 2012 14:55:07 +0000 Received: from dwingWS ([10.32.240.194]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8PEt7xM016084; Tue, 25 Sep 2012 14:55:07 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <5061AC3F.9010207@viagenie.ca> <5061B109.8060305@viagenie.ca> <20b301cd9b28$c42f1730$4c8d4590$@com> <5061C01D.7020505@viagenie.ca> In-Reply-To: <5061C01D.7020505@viagenie.ca> Date: Tue, 25 Sep 2012 07:55:05 -0700 Message-ID: <210801cd9b2d$c03b0760$40b11620$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2bKl8Yq8ISWcxMR7+iVAgPQEWbrQAAxGQw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 14:55:26 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Tuesday, September 25, 2012 7:31 AM > To: Dan Wing > Cc: 'Sam Hartman'; pcp@ietf.org > Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to > security considerations change; ietf last call requested >=20 > Le 2012-09-25 10:19, Dan Wing a =E9crit : > >> That is besides the point. My point is that RST spoofing is a well- > >> known > >> attack that current NATs know how to deal with, and I'm proposing > that > >> the same mitigation technique could be applied to the PCP attack = you > >> described. > > > > That mitigation is already in pcp-base-27 (and was in earlier > versions, > > but not nearly as clear). pcp-base-27 says: > > > > 15.2. Lifetime Processing for the PEER Opcode > > > > The assigned lifetime MUST NOT be shorter than the lifetime the > PCP- > > controlled device uses for an implicitly-created mapping with > active > > bi-directional traffic (e.g., a NAT device might use 2-5 minutes > for > > UDP [RFC4787], and might use 2 hours 4 minutes [RFC5382] for > > established TCP sessions). If the Requested Lifetime is outside > that > > range, the mapping lifetime is assigned to the value within the > > range. >=20 > Right, but that's for PEER only. Correct. > Sam said the attacker could use either MAP or PEER. I have not understood Sam's new attack with MAP. -d From dwing@cisco.com Tue Sep 25 08:48:05 2012 Return-Path: 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 CA41B21F87D3 for ; Tue, 25 Sep 2012 08:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 rC9vmr1CIRCH for ; Tue, 25 Sep 2012 08:48:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 08AEF21F8799 for ; Tue, 25 Sep 2012 08:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=743; q=dns/txt; s=iport; t=1348588085; x=1349797685; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=0XuHOKuy1Kev4nmQA3BcAth8iOSItehQ4FIeWgJG96A=; b=WIPpVNoVC+zwDdghQAJoUVUfWwl9UJ3EG1p0rheDYebWCL8grECqY6Rw Z2FtEY5HPf/TSj9myFXbSG8R/LonSw+zCfQZoO1RYl4jtswZ0DwzLfhau vi1sPRFs1frW1wdoYcdhtQxHVu/5+MdLZGnSN/nK8Kw4zWy1TlwIGqFyE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAOnQYVCtJV2d/2dsb2JhbABFhUSpAJAmgQiCIAEBAQMBAQEBBQoBFxA0EAcBAwIJDwIEAQEoBxkOFQoJCAEBBAESCxeHXQYLmGGPV5BvBIsbhkIDiFaFEZY5gWmDBw X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="125159832" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 25 Sep 2012 15:48:04 +0000 Received: from dwingWS ([10.32.240.194]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8PFm4gD005723; Tue, 25 Sep 2012 15:48:04 GMT From: "Dan Wing" To: "'Alper Yegin'" , References: <39999FCF-B9BF-4EF9-8617-AEAC18C5B234@yegin.org> In-Reply-To: <39999FCF-B9BF-4EF9-8617-AEAC18C5B234@yegin.org> Date: Tue, 25 Sep 2012 08:48:02 -0700 Message-ID: <21a401cd9b35$25c71b30$71555190$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2bKiLldUffQpASTEWXOwUHmeuHGQACo7yw Content-Language: en-us Subject: Re: [pcp] pcp version 0 and version 1 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:48:05 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Alper Yegin > Sent: Monday, September 24, 2012 5:37 PM > To: pcp@ietf.org > Subject: [pcp] pcp version 0 and version 1 > > Hello, > > Which specs define PCP version 0 draft-cheshire-nat-pmp > and PCP version 1? draft-ietf-pcp-base-00 through -24. In -25, the packet layout changed with the introduction of the Mapping Nonce, folks explained they needed a way to differentiate the old packet format from the new, so in -26 the version number was changed to 2. -d > Alper > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From yoshihiro.ohba@toshiba.co.jp Tue Sep 25 22:50:00 2012 Return-Path: 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 0063121F8835 for ; Tue, 25 Sep 2012 22:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.965 X-Spam-Level: X-Spam-Status: No, score=-6.965 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 wigzi-FjFPJG for ; Tue, 25 Sep 2012 22:49:59 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5E69221F87E7 for ; Tue, 25 Sep 2012 22:49:57 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8Q5ntFK011657 for ; Wed, 26 Sep 2012 14:49:55 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q8Q5ntJ6029974 for pcp@ietf.org; Wed, 26 Sep 2012 14:49:55 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id QAA29973; Wed, 26 Sep 2012 14:49:55 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8Q5ntAx023263 for ; Wed, 26 Sep 2012 14:49:55 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8Q5nsDs017535; Wed, 26 Sep 2012 14:49:54 +0900 (JST) Received: from [133.196.20.74] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAY00MPX076X260@mail.po.toshiba.co.jp> for pcp@ietf.org; Wed, 26 Sep 2012 14:49:54 +0900 (JST) Date: Wed, 26 Sep 2012 14:49:57 +0900 From: Yoshihiro Ohba To: "pcp@ietf.org" Message-id: <50629785.8060806@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: [pcp] PCP MTU X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 05:50:00 -0000 In draft-ietf-pcp-base-27, the PCP MTU size is 1024 octets. For PANA encapsulation approach, the PCP MTU size will need to be increased to meet the minimum EAP MTU of 1020 octets. As far as I remember this was discussed in the last interim meeting, but I would like to double check if there is any issue with increasing the PCP MTU size. Regards, Yoshihiro Ohba From dwing@cisco.com Wed Sep 26 07:59:56 2012 Return-Path: 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 C403F21F866B for ; Wed, 26 Sep 2012 07:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Y7FRk7eVIUyE for ; Wed, 26 Sep 2012 07:59:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 270D621F8440 for ; Wed, 26 Sep 2012 07:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=898; q=dns/txt; s=iport; t=1348671596; x=1349881196; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=NKLfyQ+0q2pDML+SAAdqeUtDwhqIco4bJi7WDnfirvo=; b=mA0nwWEAdXG0/etnFAVSF/iuh0BLOiCzAAeKcji5XauhBHBqqhUEh42l OiPUwOXxqbtZZdL8pPQg0CH8aYhk9GB//+28ZrKhC83lpD+EPTDpvOSVr 1IcLta0i6gPdValS1Q0Eaokd495ZpknLQ1D1DdlkhqzVBqlGljxZPTZEq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACUYY1CtJV2c/2dsb2JhbABFhUSob5AngQiCIAEBAQQICgEXEEsBAwIJDwIEAQEoBxkjCgkIAQEEARILF4djmTugMYsYhgkDiFiFEZZCgWmDBw X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="125543394" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2012 14:59:46 +0000 Received: from dwingWS ([10.32.240.194]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8QExje7019528; Wed, 26 Sep 2012 14:59:46 GMT From: "Dan Wing" To: "'Yoshihiro Ohba'" , References: <50629785.8060806@toshiba.co.jp> In-Reply-To: <50629785.8060806@toshiba.co.jp> Date: Wed, 26 Sep 2012 07:59:45 -0700 Message-ID: <270201cd9bf7$910cb950$b3262bf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2bqsXdMGv90eFjTdGEn7Xc9D0jRQAS/hug Content-Language: en-us Subject: Re: [pcp] PCP MTU X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 14:59:56 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Yoshihiro Ohba > Sent: Tuesday, September 25, 2012 10:50 PM > To: pcp@ietf.org > Subject: [pcp] PCP MTU > > In draft-ietf-pcp-base-27, the PCP MTU size is 1024 octets. > > For PANA encapsulation approach, the PCP MTU size will need to be > increased to meet the minimum EAP MTU of 1020 octets. As far as I > remember this was discussed in the last interim meeting, but I would > like to double check if there is any issue with increasing the PCP MTU > size. I don't see any issues. PCP header (24) + PANA header (16 octets) + PANA AVP header (12) = 52 octets. EAP needs 1020. 1020 + 52 = 1072. Rounding that up to 1100, there is still room for IPv6 (40) and UDP (8) headers without hitting the IPv6 minimum MTU of 1280. Expect to see 1100 in pcp-base-28. -d From dwing@cisco.com Thu Sep 27 21:57:01 2012 Return-Path: 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 03AE021F846E for ; Thu, 27 Sep 2012 21:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 WnYc8q-q3TcG for ; Thu, 27 Sep 2012 21:56:59 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C289F21F8574 for ; Thu, 27 Sep 2012 21:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7384; q=dns/txt; s=iport; t=1348808220; x=1350017820; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Pf5zHQ1xj4HlbiOGqQKJ7r+TGMoYDEVivv8Ai98U/tw=; b=gyngMqVv2fyPG7Re7j3LkVPQrjaYMLEcSsQtu1Y+jne1Xddk+LwUI3Of VijoxlCPHQJ/xNRhte/wLmUYy3lRNJcOuycSQP5RvFjgUiJfxWdOIFIhH FkFoRtJVt4PSBZ1DIpSxYwVwG6y+1JfBnOfAABfV8aP/U9BplsoGF79Wm I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmILABQtZVCrRDoJ/2dsb2JhbABErWqPDAKBE4EIgiABAQEECAoBFAMQPwwBAwIJDwIEAQEoBxkjCgkIAQEEARILCQcHh2KYJaAZixgcgT+ETAOIWIURlkKBaYMHgTs X-IronPort-AV: E=Sophos;i="4.80,498,1344211200"; d="scan'208";a="59690850" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2012 04:56:58 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8S4uwwd003429; Fri, 28 Sep 2012 04:56:58 GMT From: "Dan Wing" To: "'Sam Hartman'" , References: In-Reply-To: Date: Thu, 27 Sep 2012 21:56:57 -0700 Message-ID: <057c01cd9d35$b086e370$1194aa50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2ZuoxG1mmmQ5qYQ0aZuvnQHZdUEADcMY+g Content-Language: en-us Cc: stephen.farrell@cs.tcd.ie, pcp-ads@tools.ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 04:57:01 -0000 Sam, PCP working group, > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Sunday, September 23, 2012 11:38 AM > To: pcp@ietf.org > Cc: pcp-ads@tools.ietf.org; stephen.farrell@cs.tcd.ie > Subject: draft-ietf-pcp-base-27: objection to security considerations > change; ietf last call requested > > > Hi. > draft-ietf-pcp-base-27 relaxes restrictions in the simple threat model > (section 18.1). > In particular, it permits the lifetime of a mapping to be reduced or a > mapping to be deleted. > > I understand that reducing the lifetime of mappings is useful, and > think > that many deployments that implement a security mechanism (and thus > fall under the advanced threat model) will choose to have a relaxed > authorization policy about deleting mappings. > I think the mapping nonce changes introduced in pcp-base-27 will help > make that possible. > > However, for the simple threat model our goal is not to decrease the > security of the Internet by deploying a PCP server. > We fail to accomplish that. > > Here's an example of an attack where enabling PCP decreases the > security > of a network. > > N1 is a NAT with PCP capability. > > N2 is a NAT without PCP capability. > > H1 and H2 are hosts behind N2.; N2 is behind N1. > That is, the path from H1 or H2 to the Internet looks like > {H1,H2}->N2->N1. > > > From the standpoint of N1, H1 and H2 have the same internal address. > That permits H1 and H2 to create mappings on each others' behalf. > However, H1 and H2 cannot spoof each others' IP addresses from the > standpoint of N2. For example, H1 and H2 might be on different internal > subnets or address spoofing prevention may be in use. > > H1 is a host that either does not support PCP or follows the spec > recommendation not to use PCP through a NAT that does not support PCP. > > H2 would like to capture H1's traffic. > H2 guesses that some traffic will be sent from H1 towards x. H2 > guesses that port P will be used as the external port on N2 (the > internal port from N1's standpoint). > So, N1 will see traffic from towards x. > Before H1 sends this traffic, H2 requests a PCP mapping for ; it > could use either the map or peer opcode. > This traffic is mapped to appear to come from . > > Later, H2 wants to capture the reply traffic; because H2 created the > mapping, H2 knows the mapping nonce and can delete the mapping. > > Now, H2 needs to convince N1 to allocate Q such that traffic to > will eventually make its way to H2. > That depends on attacking N1's port allocation algorithm. This is > probably not an attack H2 can mount with 100% chance of success. > However by using multiple mappings to amplify the attack, trying to > exploit any races in N1, etc. > This is the kind of attack that looks hard until someone has it > working, > then becomes very easy. > > If N1 disables PCP, the attack is impossible if H1 sends traffic often > enough to keep the mapping alive. > This is just one attack I found while not looking very hard. > I don't have time to perform detailed security analysis on this change, > but I have fairly high confidence that it does introduce harm. I > suspect > that if we look we'll find other attacks. > > If I end up in the rough within the working group and we send this > change to the IESG, I believe a new IETF last call is > required. Typically a protocol like PCP would be required to have a > mandatory-to-implement security mechanism according to BCP 61. We have > tried to strike a compromise to permit PCP to move forward more quickly > than the security mechanism work. Many people have reviewed PCP; this > has been discussed widely in the security community and elsewhere. If > the working group is going to change this compromise after IESG review, > the IETF needs to be given a change to re-review and to suggest > balancing changes and debate questions like whether PCP should be > required to have a BCP 61 security mechanism. Thanks for describing this attack. Given the same scenario -- namely, a victim not using PCP and an attacker using PCP -- how would PCP authentication prevent the attack? The only way I see is if the attacker lacks authorization to create mappings or lacks authorization to delete mappings. I have enumerated the mitigations discussed so far and provided my analysis of each. I hopes will foster further technical discussion: a. Require PCP authentication. Requires attacker to lack authorization to create a mapping or lack authorization to delete a mapping. Analysis: May not be useful for preventing such an attack on CGN, because PCP authentication is likely rare for CGN deployments, according to REQ-9-D of draft-ietf-behave-lsn-requirements. b. Prohibit reducing lifetime of a mapping. That is, revert to draft-pcp-base-26. Analysis: Prevents the described attack. However, this can create a denial of service for a normal PCP that is making a bunch of PCP mappings -- the PCP client can consume all of its mappings with no way to remove them. This harms successful use of PCP. We can mitigate this harm by strongly suggesting large port quotas, allowing un-acknowledged TCP RST to shortcut this prohibition, or separate suggesting separate port quota space for PCP-created mappings and implicit mappings (so PCP cannot consume all of the port quota). Note: the specific text in the Security Considerations of pcp-base-26, which has been there for many versions, only prohibited shortening PEER mappings. Based on the description of the attack above and the text in REQ-9 of draft-ietf-behave-lsn-requirements, draft-ietf-pcp-base needs to worry about both MAP and PEER mappings. c. Prevent same internal host from acquiring same external port. After a port is mapped using PCP, prevent the same internal IP address from remapping that same external port to a different internal port for a period of time. Allow a different internal IP address to map that same external port. Analysis: Prevents the described attack. This solution is superior to (b), because it does not harm the user's port quota. After the PCP client issues a Delete, the port can be allocated to a different internal host. An attacking host would need a more sophisticated attack, specifically it would need to coordinate with another attacking host behind the same PCP- speaking NAT (that is, the two attacking hosts would need to be in different NATted homes and both homes are behind the same PCP-speaking CGN). d. Do not immediately delete mappings created by MAP or PEER. Instead, only allow the lifetime to be reduced to a few minutes. For TCP, suggested value RFC5382's "transitory connection idle- timeout" of 4 minutes; for UDP, RFC4787's 2 minutes. Analysis: Forces attacker to wait longer before the attacker can re-map the port to themselves. Attack will fail if victim host sends traffic during the 4 (TCP) or 2 (UDP) minutes. -d From dthaler@microsoft.com Fri Sep 28 11:35:13 2012 Return-Path: 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 9DEB621F85DA for ; Fri, 28 Sep 2012 11:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.98 X-Spam-Level: X-Spam-Status: No, score=-103.98 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 WOhKXdxKnI6e for ; Fri, 28 Sep 2012 11:35:12 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 260C921F85AD for ; Fri, 28 Sep 2012 11:35:11 -0700 (PDT) Received: from mail110-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Sep 2012 18:35:10 +0000 Received: from mail110-db3 (localhost [127.0.0.1]) by mail110-db3-R.bigfish.com (Postfix) with ESMTP id 045AC2E01DA for ; Fri, 28 Sep 2012 18:35:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zzc85fh1452Izz1202h1d1ah1d2ahzz17326ah8275bh8275dh177df4hz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1155h) Received-SPF: pass (mail110-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail110-db3 (localhost.localdomain [127.0.0.1]) by mail110-db3 (MessageSwitch) id 1348857308662867_10164; Fri, 28 Sep 2012 18:35:08 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.250]) by mail110-db3.bigfish.com (Postfix) with ESMTP id 9F3DD2A006E for ; Fri, 28 Sep 2012 18:35:08 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Sep 2012 18:35:06 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 28 Sep 2012 18:35:03 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0318.003; Fri, 28 Sep 2012 11:35:03 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Scheduling next WebEx interim meeting Thread-Index: Ac2dpnq+k2z1gkPQTgOP2RlG/6JFuA== Date: Fri, 28 Sep 2012 18:35:03 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7D63B5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7D63B5TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] Scheduling next WebEx interim meeting X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 18:35:13 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7D63B5TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Once I heard back from various key security discussion participants (authors/presenters/chairs/ADs) via email, it turned out that no day during the week of Oct 8th would work. Rather than trying to hold an interim when the relevant parties cannot be there, I want to see if a day early (Mon/Tues/Wed) the following week would work. I've created a doodle poll at http://doodle.com/cc78mg3yrx2g3bm7 Please list your availability there. If none of those work and you believ= e you're a key participant, send me mail with your closest availability. -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B7D63B5TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Once I heard back from various key security discussi= on participants

(authors/presenters/chairs/ADs) via email, it turned= out

that no day during the week of Oct 8th wo= uld work.   Rather

than trying to hold an interim when the relevant par= ties cannot be there,

I want to see if a day early (Mon/Tues/Wed) the foll= owing week would work.

 

I’ve created a doodle poll at

ht= tp://doodle.com/cc78mg3yrx2g3bm7

 

Please list your availability there.   If = none of those work and you believe

you’re a key participant, send me mail with yo= ur closest availability.

 

-Dave

 

--_000_9B57C850BB53634CACEC56EF4853FF653B7D63B5TK5EX14MBXW604w_-- From dthaler@microsoft.com Fri Sep 28 11:38:56 2012 Return-Path: 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 0F11F21F8516 for ; Fri, 28 Sep 2012 11:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.966 X-Spam-Level: X-Spam-Status: No, score=-103.966 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ZSqPjVonQY-C for ; Fri, 28 Sep 2012 11:38:54 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6F21F84DC for ; Fri, 28 Sep 2012 11:38:53 -0700 (PDT) Received: from mail94-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Sep 2012 18:38:51 +0000 Received: from mail94-am1 (localhost [127.0.0.1]) by mail94-am1-R.bigfish.com (Postfix) with ESMTP id 9ED73360116 for ; Fri, 28 Sep 2012 18:38:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic85fh1452Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh177df4hz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1155h) Received-SPF: pass (mail94-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail94-am1 (localhost.localdomain [127.0.0.1]) by mail94-am1 (MessageSwitch) id 1348857530572178_3454; Fri, 28 Sep 2012 18:38:50 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.233]) by mail94-am1.bigfish.com (Postfix) with ESMTP id 7FD07A006F for ; Fri, 28 Sep 2012 18:38:50 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Sep 2012 18:38:44 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 28 Sep 2012 18:38:42 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.129]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0318.003; Fri, 28 Sep 2012 11:38:42 -0700 From: Dave Thaler To: Dave Thaler , "pcp@ietf.org" Thread-Topic: Scheduling next WebEx interim meeting Thread-Index: Ac2dpnq+k2z1gkPQTgOP2RlG/6JFuAAAe4Vw Date: Fri, 28 Sep 2012 18:38:42 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7D6413@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B7D63B5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7D63B5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7D6413TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] Scheduling next WebEx interim meeting X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 18:38:56 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7D6413TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For comparison, I've also put in a late option on the 12th just to get a co= mparison if someone is unavailable all the week of the 15th. From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dave = Thaler Sent: Friday, September 28, 2012 11:35 AM To: pcp@ietf.org Subject: [pcp] Scheduling next WebEx interim meeting Once I heard back from various key security discussion participants (authors/presenters/chairs/ADs) via email, it turned out that no day during the week of Oct 8th would work. Rather than trying to hold an interim when the relevant parties cannot be there, I want to see if a day early (Mon/Tues/Wed) the following week would work. I've created a doodle poll at http://doodle.com/cc78mg3yrx2g3bm7 Please list your availability there. If none of those work and you believ= e you're a key participant, send me mail with your closest availability. -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B7D6413TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For comparison, I̵= 7;ve also put in a late option on the 12th just to get a compari= son

if someone is unavaila= ble all the week of the 15th.

 

From: pcp-boun= ces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: Friday, September 28, 2012 11:35 AM
To: pcp@ietf.org
Subject: [pcp] Scheduling next WebEx interim meeting

 

Once I heard back from various key security discussi= on participants

(authors/presenters/chairs/ADs) via email, it turned= out

that no day during the week of Oct 8th wo= uld work.   Rather

than trying to hold an interim when the relevant par= ties cannot be there,

I want to see if a day early (Mon/Tues/Wed) the foll= owing week would work.

 

I’ve created a doodle poll at

ht= tp://doodle.com/cc78mg3yrx2g3bm7

 

Please list your availability there.   If = none of those work and you believe

you’re a key participant, send me mail with yo= ur closest availability.

 

-Dave

 

--_000_9B57C850BB53634CACEC56EF4853FF653B7D6413TK5EX14MBXW604w_--