From repenno@cisco.com Mon Jul 1 08:27:29 2013 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 22E1311E8227 for ; Mon, 1 Jul 2013 08:27:29 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udZDF8XOnqMC for ; Mon, 1 Jul 2013 08:27:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 58AD911E81AF for ; Mon, 1 Jul 2013 08:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7496; q=dns/txt; s=iport; t=1372692440; x=1373902040; h=from:to:subject:date:message-id:mime-version; bh=+zpfB+yJcBfP9NNOMyLNplpW3Ke53hVHRlAFCOfFgyQ=; b=HrBRyD0rXduI7rPyu25mlnEy97BMUBgdLidYu3qan9cCX18/K++22nPN DKMH/5IQqBgM35x3f5sltCg74GSY0SLsX9lZTwyWC/IhSoWlnXAv4rOO3 JPEMinxHaZiasKviy7Jai2InY7skIsaqulfCS+SvP9yLNzLvD+6qoYyOl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAIad0VGtJXG9/2dsb2JhbABAFwOCRUQySYVosHeGY4FXfBZ0giUBBFURAiMBHA4KBAw8JAMEEwiIBwwzm2CTEoxdhTWHMYE2G3YLFQEoB4JsYwOYcZAcgkFQgXE3 X-IronPort-AV: E=Sophos;i="4.87,974,1363132800"; d="scan'208,217";a="229481025" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 01 Jul 2013 15:27:12 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r61FRCjp008947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 1 Jul 2013 15:27:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 1 Jul 2013 10:27:12 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: PCP Interim Meeting Tomorrow - July 2nd Thread-Index: AQHOdm90M6VrV43Ew0KaZARmQvYxPA== Date: Mon, 1 Jul 2013 15:27:11 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090C15E7@xmb-rcd-x04.cisco.com> 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.86.240.230] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090C15E7xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [pcp] PCP Interim Meeting Tomorrow - July 2nd 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, 01 Jul 2013 15:27:29 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090C15E7xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Details are below and also in: http://trac.tools.ietf.org/wg/pcp/trac/wiki http://tools.ietf.org/html/draft-ietf-pcp-proxy-03 - Dan Wing - 25 minutes http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family - Stuart Cheshi= re - 30 minutes http://tools.ietf.org/html/draft-penno-pcp-ext-addr - Reinaldo Penno - 25 m= inutes http://tools.ietf.org/html/draft-perreault-softwire-lw4over6-pcp-00 - Simon= Perreault - 15 minutes http://tools.ietf.org/html/draft-boucadair-pcp-failure-06 - Christian Jacqu= enet - 10 minutes http://tools.ietf.org/html/draft-boucadair-pcp-flow-examples-02 - Christian= Jacquenet - 10 minutes Port Control Protocol Working Group invites you to attend this online meeti= ng. Topic: PCP Interim Meeting Date: Tuesday, July 2, 2013 Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 642 233 632 Meeting Password: 123456 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=3D226920422&UID=3D0&PW=3DNNmY= wMTMxMzI3&RT=3DMiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 123456 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=3D226920422&UID=3D0&PW=3DNNmYwMTMxMzI3= &ORT=3DMiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:642 233 632 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: pcp-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://ietf.webex.com/ietf/j.php?ED=3D226920422&UID=3D0&ICS=3DMI&LD=3D1&RD= =3D2&ST=3D1&SHA2=3DAAAAAmmrikLDopD03t79kvRQwsEjPmyufxqd-a0jxJZMP6l2&RT=3DMi= M0 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com --_000_45A697A8FFD7CF48BCF2BE7E106F0604090C15E7xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <855F4730E5F6424D9613E757236AD924@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Details are below and also in:  http://trac.tools.ietf.org/wg/pcp/trac/wiki 

http://tools.ietf.org/html/draft-ietf-pcp-proxy-=
03 - Dan Wing - 25 minutes

http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family - Stuart Cheshi=
re - 30 minutes

http://tools.ietf.org/html/draft-penno-pcp-ext-addr - Reinaldo Penno - 25 m=
inutes

http://tools.ietf.org/html/draft-perreault-softwire-lw4over6-pcp-00 - Simon=
 Perreault - 15 minutes

http://tools.ietf.org/html/draft-boucadair-pcp-failure-06 - Christian Jacqu=
enet - 10 minutes

http://tools.ietf.org/html/draft-boucadair-pcp-flow-examples-02 - Christian=
 Jacquenet - 10 minutes


Port Control Protocol Working Group invites you =
to attend this online meeting.=20

Topic: PCP Interim Meeting=20
Date: Tuesday, July 2, 2013=20
Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20
Meeting Number: 642 233 632=20
Meeting Password: 123456=20


-------------------------------------------------------=20
To join the online meeting (Now from mobile devices!)=20
-------------------------------------------------------=20
1. Go to https://ietf.webex.com/ietf/j.php?ED=3D226920422&UID=3D0&P=
W=3DNNmYwMTMxMzI3&RT=3DMiM0=20
2. If requested, enter your name and email address.=20
3. If a password is required, enter the meeting password: 123456=20
4. Click "Join".=20

To view in other time zones or languages, please click the link:=20
https://ietf.webex.com/ietf/j.php?ED=3D226920422&UID=3D0&PW=3DNNmYw=
MTMxMzI3&ORT=3DMiM0=20

-------------------------------------------------------=20
To join the audio conference only=20
-------------------------------------------------------=20
Call-in toll number (US/Canada): 1-650-479-3208=20

Access code:642 233 632=20

-------------------------------------------------------=20
For assistance=20
-------------------------------------------------------=20
1. Go to https://ietf.webex.com/ietf/mc=20
2. On the left navigation bar, click "Support".=20

You can contact me at:=20
pcp-chairs@tools.ietf.org=20


To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:=20
https://ietf.webex.com/ietf/j.php?ED=3D226920422&UID=3D0&ICS=3DMI&a=
mp;LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmmrikLDopD03t79kvRQwsEjPmyu=
fxqd-a0jxJZMP6l2&RT=3DMiM0=20

The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20

Sign up for a free trial of WebEx=20
http://www.webex.com/go/mcemfreetrial=20

http://www.webex.com
--_000_45A697A8FFD7CF48BCF2BE7E106F0604090C15E7xmbrcdx04ciscoc_-- From dthaler@microsoft.com Mon Jul 1 21:03:34 2013 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 1827C11E83A3 for ; Mon, 1 Jul 2013 21:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.466 X-Spam-Level: X-Spam-Status: No, score=-98.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX2Dav84nz34 for ; Mon, 1 Jul 2013 21:03:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 57BA211E83AE for ; Mon, 1 Jul 2013 21:03:26 -0700 (PDT) Received: from BL2FFO11FD012.protection.gbl (10.173.161.202) by BL2FFO11HUB047.protection.gbl (10.173.161.123) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 2 Jul 2013 04:03:25 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 2 Jul 2013 04:03:24 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 2 Jul 2013 04:03:06 +0000 Received: from mail141-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 04:02:43 +0000 Received: from mail141-va3 (localhost [127.0.0.1]) by mail141-va3-R.bigfish.com (Postfix) with ESMTP id 26E492C01E5 for ; Tue, 2 Jul 2013 04:02:44 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -6 X-BigFish: PS-6(zzc85fhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h186M5eeeK8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail141-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(243025003)(56816003)(81342001)(77096001)(63696002)(558084003)(19300405004)(74706001)(76482001)(47446002)(54356001)(56776001)(15202345003)(76796001)(74876001)(16406001)(81542001)(76576001)(54316002)(76786001)(74662001)(74316001)(74366001)(51856001)(31966008)(53806001)(46102001)(4396001)(59766001)(79102001)(76176001)(47736001)(65816001)(80022001)(83072001)(47976001)(66066001)(77982001)(49866001)(33646001)(16236675002)(50986001)(69226001)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail141-va3 (localhost.localdomain [127.0.0.1]) by mail141-va3 (MessageSwitch) id 1372737761124032_12131; Tue, 2 Jul 2013 04:02:41 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.231]) by mail141-va3.bigfish.com (Postfix) with ESMTP id 18D2330009C; Tue, 2 Jul 2013 04:02:41 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Jul 2013 04:02:38 +0000 Received: from BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.324.0; Tue, 2 Jul 2013 04:02:38 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.702.21; Tue, 2 Jul 2013 04:02:36 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.25]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.101]) with mapi id 15.00.0702.005; Tue, 2 Jul 2013 04:02:35 +0000 From: Dave Thaler To: "draft-ietf-pcp-proxy@tools.ietf.org" Thread-Topic: DThaler comments on draft-ietf-pcp-proxy-03 Thread-Index: Ac521DK3NC2l8eO3QX2ssYVV7V1uSw== Date: Tue, 2 Jul 2013 04:02:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.141.94.226] x-forefront-prvs: 0895DF8FFD Content-Type: multipart/alternative; boundary="_000_afcbf939d5604c238df86b3f777c09f0BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(243025003)(16236675002)(47736001)(53806001)(76176001)(44976004)(81542001)(56816003)(19300405004)(512954002)(65816001)(74876001)(31966008)(77982001)(74316001)(76482001)(74502001)(51856001)(74706001)(76796001)(15202345003)(74662001)(56776001)(77096001)(69226001)(54316002)(83072001)(79102001)(74366001)(47446002)(76576001)(71186001)(76786001)(81342001)(54356001)(66066001)(47976001)(80022001)(50986001)(33646001)(46102001)(59766001)(6806003)(16676001)(20776003)(49866001)(63696002)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB047; H:TK5EX14HUBC101.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0895DF8FFD Cc: "pcp@ietf.org" Subject: [pcp] DThaler comments on draft-ietf-pcp-proxy-03 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, 02 Jul 2013 04:03:34 -0000 --_000_afcbf939d5604c238df86b3f777c09f0BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed draft-ietf-pcp-proxy-03 and added my comments and editorial suggestions into the marked up copy at http://research.microsoft.com/~dthaler/draft-ietf-pcp-proxy-03.pdf -Dave --_000_afcbf939d5604c238df86b3f777c09f0BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed  draft-ietf-pcp-proxy-03 and ad= ded my comments

and editorial suggestions into the marked up copy at=

http://research.microsoft.com/~dthaler/draft-iet= f-pcp-proxy-03.pdf

 

-Dave

--_000_afcbf939d5604c238df86b3f777c09f0BY2PR03MB269namprd03pro_-- From dthaler@microsoft.com Mon Jul 1 22:21:49 2013 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 F12A111E83DF for ; Mon, 1 Jul 2013 22:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.466 X-Spam-Level: X-Spam-Status: No, score=-98.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3RZDeQ6J8EZ for ; Mon, 1 Jul 2013 22:21:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5E84211E83B2 for ; Mon, 1 Jul 2013 22:21:43 -0700 (PDT) Received: from BY2FFO11FD004.protection.gbl (10.1.15.202) by BY2FFO11HUB009.protection.gbl (10.1.14.167) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 2 Jul 2013 05:21:42 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 2 Jul 2013 05:21:42 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 2 Jul 2013 05:20:59 +0000 Received: from mail70-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 05:20:55 +0000 Received: from mail70-va3 (localhost [127.0.0.1]) by mail70-va3-R.bigfish.com (Postfix) with ESMTP id 3098B4A02B1 for ; Tue, 2 Jul 2013 05:20:55 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -6 X-BigFish: PS-6(zzc85fhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h186M5eeeK8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail70-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(243025003)(189002)(199002)(59766001)(15202345003)(65816001)(47736001)(53806001)(4396001)(46102001)(33646001)(16236675002)(50986001)(47446002)(76176001)(69226001)(80022001)(83072001)(77982001)(66066001)(49866001)(47976001)(74316001)(31966008)(74502001)(81342001)(56816003)(76482001)(19300405004)(74662001)(81542001)(74366001)(76796001)(76786001)(79102001)(74706001)(63696002)(76576001)(558084003)(77096001)(51856001)(54316002)(54356001)(56776001)(74876001)(16406001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail70-va3 (localhost.localdomain [127.0.0.1]) by mail70-va3 (MessageSwitch) id 1372742453439726_6712; Tue, 2 Jul 2013 05:20:53 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.237]) by mail70-va3.bigfish.com (Postfix) with ESMTP id 63C2534006F; Tue, 2 Jul 2013 05:20:53 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Jul 2013 05:20:53 +0000 Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.324.0; Tue, 2 Jul 2013 05:20:52 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.702.21; Tue, 2 Jul 2013 05:20:50 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.25]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.101]) with mapi id 15.00.0702.005; Tue, 2 Jul 2013 05:20:50 +0000 From: Dave Thaler To: "draft-penno-pcp-ext-addr@tools.ietf.org" Thread-Topic: DThaler comments on draft-penno-pcp-ext-addr-01 Thread-Index: Ac524gmq0aGFw3oyQO2FfCsGOFKbVw== Date: Tue, 2 Jul 2013 05:20:49 +0000 Message-ID: <04ea4117e7a744d88ba9f2826df676d4@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.141.94.226] x-forefront-prvs: 0895DF8FFD Content-Type: multipart/alternative; boundary="_000_04ea4117e7a744d88ba9f2826df676d4BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(243025003)(76786001)(47446002)(44976004)(47976001)(76796001)(15202345003)(74706001)(74876001)(53806001)(81342001)(54316002)(54356001)(77096001)(16676001)(74662001)(51856001)(77982001)(69226001)(56776001)(81542001)(31966008)(76576001)(76176001)(71186001)(56816003)(79102001)(83072001)(59766001)(46102001)(74502001)(66066001)(6806003)(49866001)(33646001)(16236675002)(76482001)(74366001)(65816001)(4396001)(20776003)(74316001)(19300405004)(80022001)(512954002)(63696002)(47736001)(50986001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB009; H:TK5EX14MLTC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0895DF8FFD Cc: "pcp@ietf.org" Subject: [pcp] DThaler comments on draft-penno-pcp-ext-addr-01 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, 02 Jul 2013 05:21:50 -0000 --_000_04ea4117e7a744d88ba9f2826df676d4BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed draft-penno-pcp-ext-addr-01 and added my comments and editorial suggestions into the marked up copy at http://research.microsoft.com/~dthaler/draft-penno-pcp-ext-addr-01.pdf -Dave --_000_04ea4117e7a744d88ba9f2826df676d4BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-penno-pcp-ext-addr-01 and adde= d my comments

and editorial suggestions into the marked up copy at=

http://research.microsoft.com/~dthaler/draft= -penno-pcp-ext-addr-01.pdf

 

-Dave

--_000_04ea4117e7a744d88ba9f2826df676d4BY2PR03MB269namprd03pro_-- From dthaler@microsoft.com Mon Jul 1 22:23:26 2013 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 1C7D111E83E4 for ; Mon, 1 Jul 2013 22:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.466 X-Spam-Level: X-Spam-Status: No, score=-98.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0MWlEhW6R0e for ; Mon, 1 Jul 2013 22:23:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 32BB911E83B2 for ; Mon, 1 Jul 2013 22:23:19 -0700 (PDT) Received: from BY2FFO11FD028.protection.gbl (10.1.15.203) by BY2FFO11HUB017.protection.gbl (10.1.14.91) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 2 Jul 2013 05:23:17 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 2 Jul 2013 05:23:17 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 2 Jul 2013 05:23:07 +0000 Received: from mail177-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Tue, 2 Jul 2013 05:22:43 +0000 Received: from mail177-ch1 (localhost [127.0.0.1]) by mail177-ch1-R.bigfish.com (Postfix) with ESMTP id 2F9632600F0 for ; Tue, 2 Jul 2013 05:22:43 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -6 X-BigFish: PS-6(zzc85fhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h186M5eeeK8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail177-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(243025003)(189002)(199002)(31966008)(79102001)(59766001)(76176001)(65816001)(47736001)(53806001)(4396001)(46102001)(33646001)(16236675002)(50986001)(74502001)(69226001)(80022001)(83072001)(77982001)(66066001)(49866001)(47976001)(74706001)(558084003)(76482001)(19300405004)(81342001)(56816003)(77096001)(63696002)(47446002)(74662001)(76786001)(51856001)(74366001)(74316001)(54316002)(76796001)(54356001)(56776001)(15202345003)(81542001)(74876001)(16406001)(76576001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail177-ch1 (localhost.localdomain [127.0.0.1]) by mail177-ch1 (MessageSwitch) id 13727425611780_12454; Tue, 2 Jul 2013 05:22:41 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail177-ch1.bigfish.com (Postfix) with ESMTP id E7F411E0044; Tue, 2 Jul 2013 05:22:40 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Jul 2013 05:22:40 +0000 Received: from BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.324.0; Tue, 2 Jul 2013 05:22:40 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.702.21; Tue, 2 Jul 2013 05:22:38 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.25]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.101]) with mapi id 15.00.0702.005; Tue, 2 Jul 2013 05:22:37 +0000 From: Dave Thaler To: "draft-perreault-softwire-lw4over6-pcp@tools.ietf.org" Thread-Topic: DThaler comments on draft-perreault-softwire-lw4over6-pcp-00 Thread-Index: Ac525BRufK95mjXtRi2mXGH8K9oDgg== Date: Tue, 2 Jul 2013 05:22:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.141.94.226] x-forefront-prvs: 0895DF8FFD Content-Type: multipart/alternative; boundary="_000_ab6ef355756f498da085e552889544d0BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(243025003)(16676001)(20776003)(49866001)(15202345003)(77096001)(76576001)(79102001)(74366001)(74316001)(51856001)(56816003)(59766001)(76796001)(54356001)(53806001)(16236675002)(65816001)(66066001)(19300405004)(44976004)(74706001)(33646001)(76176001)(80022001)(74876001)(83072001)(69226001)(63696002)(46102001)(47446002)(31966008)(74502001)(54316002)(47736001)(76482001)(47976001)(76786001)(512954002)(6806003)(71186001)(56776001)(81542001)(81342001)(4396001)(50986001)(77982001)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB017; H:TK5EX14HUBC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0895DF8FFD Cc: "pcp@ietf.org" Subject: [pcp] DThaler comments on draft-perreault-softwire-lw4over6-pcp-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: Tue, 02 Jul 2013 05:23:26 -0000 --_000_ab6ef355756f498da085e552889544d0BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed draft-perreault-softwire-lw4over6-pcp-00 and added my comme= nts and editorial suggestions into the marked up copy at http://research.microsoft.com/~dthaler/draft-perreault-softwire-lw4over6-pc= p-00.pdf -Dave --_000_ab6ef355756f498da085e552889544d0BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-perreault-softwire-lw4over6-pc= p-00 and added my comments

and editorial suggestions into the marked up copy at=

http://research.microsoft.com/~= dthaler/draft-perreault-softwire-lw4over6-pcp-00.pdf

 

-Dave

--_000_ab6ef355756f498da085e552889544d0BY2PR03MB269namprd03pro_-- From dthaler@microsoft.com Mon Jul 1 22:23:29 2013 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 5AFA911E83EF for ; Mon, 1 Jul 2013 22:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.466 X-Spam-Level: X-Spam-Status: No, score=-98.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIMBClmRpeJc for ; Mon, 1 Jul 2013 22:23:22 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 982D711E83DF for ; Mon, 1 Jul 2013 22:23:22 -0700 (PDT) Received: from BN1AFFO11FD019.protection.gbl (10.58.52.203) by BN1BFFO11HUB038.protection.gbl (10.58.53.148) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 2 Jul 2013 05:23:21 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD019.mail.protection.outlook.com (10.58.52.79) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 2 Jul 2013 05:23:21 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 2 Jul 2013 05:22:13 +0000 Received: from mail219-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 05:20:54 +0000 Received: from mail219-va3 (localhost [127.0.0.1]) by mail219-va3-R.bigfish.com (Postfix) with ESMTP id D81456000AF for ; Tue, 2 Jul 2013 05:20:54 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -6 X-BigFish: PS-6(zzc85fhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h186M5eeeK8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail219-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(243025003)(189002)(199002)(53806001)(54356001)(69226001)(56816003)(74876001)(76786001)(16236675002)(76176001)(56776001)(49866001)(77982001)(63696002)(59766001)(65816001)(76576001)(51856001)(74502001)(79102001)(46102001)(47736001)(54316002)(47976001)(80022001)(76482001)(31966008)(81542001)(74662001)(81342001)(19300405004)(74366001)(50986001)(77096001)(15202345003)(4396001)(33646001)(83072001)(66066001)(16406001)(76796001)(74316001)(74706001)(47446002)(558084003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail219-va3 (localhost.localdomain [127.0.0.1]) by mail219-va3 (MessageSwitch) id 1372742451414406_21489; Tue, 2 Jul 2013 05:20:51 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.234]) by mail219-va3.bigfish.com (Postfix) with ESMTP id 58BE87E0168; Tue, 2 Jul 2013 05:20:51 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Jul 2013 05:20:51 +0000 Received: from BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.324.0; Tue, 2 Jul 2013 05:20:50 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.702.21; Tue, 2 Jul 2013 05:20:48 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.25]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.101]) with mapi id 15.00.0702.005; Tue, 2 Jul 2013 05:20:48 +0000 From: Dave Thaler To: "draft-cheshire-pcp-unsupp-family@tools.ietf.org" Thread-Topic: DThaler comments on draft-cheshire-pcp-unsupp-family-04 Thread-Index: Ac524cCAtfDXDxEuSaSobHilb52BTQ== Date: Tue, 2 Jul 2013 05:20:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.141.94.226] x-forefront-prvs: 0895DF8FFD Content-Type: multipart/alternative; boundary="_000_d562e4b8e6f247e0895449e4c03d0b6cBY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB271.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(243025003)(69226001)(80022001)(47736001)(59766001)(46102001)(16236675002)(50986001)(77982001)(79102001)(15202345003)(53806001)(76786001)(20776003)(54356001)(4396001)(76796001)(66066001)(49866001)(76176001)(65816001)(51856001)(77096001)(83072001)(76576001)(56776001)(81342001)(74876001)(71186001)(16676001)(31966008)(33646001)(76482001)(74706001)(47976001)(74662001)(63696002)(56816003)(74502001)(47446002)(74316001)(81542001)(74366001)(54316002)(19300405004)(512954002)(6806003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB038; H:TK5EX14MLTC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0895DF8FFD Cc: "pcp@ietf.org" Subject: [pcp] DThaler comments on draft-cheshire-pcp-unsupp-family-04 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, 02 Jul 2013 05:23:29 -0000 --_000_d562e4b8e6f247e0895449e4c03d0b6cBY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed draft-cheshire-pcp-unsupp-family-04 and added my comments and editorial suggestions into the marked up copy at http://research.microsoft.com/~dthaler/draft-cheshire-pcp-unsupp-family-04.= pdf -Dave --_000_d562e4b8e6f247e0895449e4c03d0b6cBY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-cheshire-pcp-unsupp-family-04 = and added my comments

and editorial suggestions into the marked up copy at=

http://research.microsoft.com/~dthal= er/draft-cheshire-pcp-unsupp-family-04.pdf

 

-Dave

--_000_d562e4b8e6f247e0895449e4c03d0b6cBY2PR03MB269namprd03pro_-- From simon.perreault@viagenie.ca Tue Jul 2 02:11:05 2013 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 899DE11E8446 for ; Tue, 2 Jul 2013 02:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4jLMiBDO41g for ; Tue, 2 Jul 2013 02:11:05 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E82F011E8441 for ; Tue, 2 Jul 2013 02:11:04 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 186D540D11; Tue, 2 Jul 2013 05:11:03 -0400 (EDT) Message-ID: <51D29927.5030206@viagenie.ca> Date: Tue, 02 Jul 2013 11:11:03 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "draft-cheshire-pcp-unsupp-family@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] DThaler comments on draft-cheshire-pcp-unsupp-family-04 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, 02 Jul 2013 09:11:05 -0000 Thanks Dave but it seems that the actual comments are absent from the PDF... Simon Le 2013-07-02 07:20, Dave Thaler a écrit : > I have reviewed draft-cheshire-pcp-unsupp-family-04 and added my comments > > and editorial suggestions into the marked up copy at > > http://research.microsoft.com/~dthaler/draft-cheshire-pcp-unsupp-family-04.pdf > > -Dave > -- 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 Jul 2 02:36:45 2013 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 645E111E845F for ; Tue, 2 Jul 2013 02:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxHgi4kDGMRK for ; Tue, 2 Jul 2013 02:36: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 B856711E8457 for ; Tue, 2 Jul 2013 02:36:44 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E314140D11; Tue, 2 Jul 2013 05:36:42 -0400 (EDT) Message-ID: <51D29F2A.2050407@viagenie.ca> Date: Tue, 02 Jul 2013 11:36:42 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "draft-perreault-softwire-lw4over6-pcp@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] DThaler comments on draft-perreault-softwire-lw4over6-pcp-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: Tue, 02 Jul 2013 09:36:45 -0000 Le 2013-07-02 07:22, Dave Thaler a écrit : > I have reviewed draft-perreault-softwire-lw4over6-pcp-00 and added my > comments and editorial suggestions into the marked up copy at > http://research.microsoft.com/~dthaler/draft-perreault-softwire-lw4over6-pcp-00.pdf Thanks! I'll try to address them here: > Only the external ip address/ports. Other parameters are configured > with other protocols like DHCP as explained in section 3.1. The title > of this draft is equally bad in that respect. and about section 3.1 you say: > This section is informative not normative yes? That is, nothing here > is mentioned beyond what’s already specified in other rfcs, yes? > Would help to clarify this. We need consider DHCPv4 and DHCPv6 separately. In our proposal we do use DHCPv6, and specifically OPTION_AFTR_NAME, to provision the tunnel's destination address. But we do not use DHCPv4. Now, in section 3.1 we explain how to provision the outside (IPv6) tunnel addresses and the inside (IPv4) tunnel addresses. The outside is provisioned as described in draft-ietf-softwire-unified-cpe-01, and we need to add a reference to it. However, the inside provisioning is specific to our proposal. We adapt the static address provisioning method from DS-Lite. AFAIK that is discussed in neither draft-ietf-softwire-lw4over6-00 nor draft-ietf-softwire-unified-cpe-01 because the tunnel's inside is unnumbered. In our proposal, we need a numbered tunnel to be able to use PCP. If that explanation makes sense, we'll try to clarify along those lines in -01. ----------- Section "3.3. PCP Proxy" will be vastly simplified by referring to draft-ietf-pcp-proxy. ----------- I'll let my coauthors speak about section "3.4. Failover Mechanism". 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 hotday007@gmail.com Tue Jul 2 10:38:03 2013 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 6D49221F9B7F for ; Tue, 2 Jul 2013 10:38:03 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNmKJMtn5dRp for ; Tue, 2 Jul 2013 10:38:02 -0700 (PDT) Received: from mail-qa0-x244.google.com (mail-qa0-x244.google.com [IPv6:2607:f8b0:400d:c00::244]) by ietfa.amsl.com (Postfix) with ESMTP id B44FA21F9B7E for ; Tue, 2 Jul 2013 10:38:02 -0700 (PDT) Received: by mail-qa0-f68.google.com with SMTP id f11so2025835qae.7 for ; Tue, 02 Jul 2013 10:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XBxhti8odjPgZHAl6THflKh1ljF/TWh/XlQYijFqr+Y=; b=O45yRqf2WcMjMFSFHP/X6e07vZCN6AfBzsoFXg41kuPP3S2NJ0D0ekzBgspNSYufkB +wvlQV6GqH4zifY563Uk6ksBzXObztv/0qjnP4UnF8jtudCCZkQhwTvgHfpXsOl7yc0J xWKFyU4wBCQSZE6ksoanyOjNuhpxLc1KLb8oy59ySIE6Us1o9sKK9QIGSJPrwlvRGjtt hEZn1YkDd5+pj+NijEJbjqfH7UnD1kWMkOUWxg0jL1ZkKl9hENy1mcB7Q1HTib6cFfWK 6pcDwTRiodPo5g6FriHDfc/xnB/FwuNEskf0QB39RLQ46MvyDIcYhrB/4N7urYJdiJPN d24w== MIME-Version: 1.0 X-Received: by 10.224.25.140 with SMTP id z12mr39792317qab.46.1372786682224; Tue, 02 Jul 2013 10:38:02 -0700 (PDT) Received: by 10.49.38.228 with HTTP; Tue, 2 Jul 2013 10:38:02 -0700 (PDT) Date: Wed, 3 Jul 2013 01:38:02 +0800 Message-ID: From: vic yan To: pcp@ietf.org Content-Type: multipart/alternative; boundary=047d7bdc8f5e8be39e04e08ace8d Subject: [pcp] questions about the DNS Security under simple threat model 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, 02 Jul 2013 17:38:03 -0000 --047d7bdc8f5e8be39e04e08ace8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear authors=EF=BC=8C I have some questions about the DNS Security under the simple threat model in section 18.1 of RFC6887 . As described in the simple threat model, the PCP clients are secure against off-path attackers who can spoof the PCP server's IP address. In PCP, a client can discover the PCP server's address via a DNS query of PCP Server Domain Name in DHCPv6 option [I-D.ieft-pcp-dhcp]. But this client may encount Pharming by a DNS attacker. I'm wondering whether the data origin authentication and data integrity to the DNS is within the scope of the above simple thread model? And if the three conditions described in section 18.1 of [RFC6887] are satisfied, can PCP clients be secure against the Pharming of PCP Server without deploying DNSsec? I look forward to a reply at your earliest convenience. Thanks in advance. Yours sincerely, Lei Yan --047d7bdc8f5e8be39e04e08ace8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear authors=EF=BC=8C
=C2=A0 =C2=A0 =C2=A0 =C2=A0I have so= me questions about the DNS Security under the simple threat model in=C2=A0s= ection=C2=A018.1=C2=A0of=C2=A0RFC6887=C2=A0.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0As described in the simple thre= at model, the PCP clients are secure against off-path attackers who can spo= of the PCP server's IP address.=C2=A0=C2=A0 In PCP, a=C2=A0client can d= iscover the PCP server's address via a DNS query of PCP=C2=A0Server Dom= ain Name in DHCPv6 option [I-D.ieft-pcp-dhcp]. But this client may encount = Pharming by a DNS=C2=A0attacker.=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I'= m wondering=C2=A0whether the data origin authentication and data integrity = to the DNS is within the=C2=A0scope of=C2=A0= the above=C2=A0simple thread model?=C2=A0And if the three conditions descri= bed in section 18.1 of [RFC6887] are satisfied, can PCP clients be secure a= gainst the Pharming of PCP Server without deploying DNSsec?
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I look forw= ard to a reply at your earliest convenience. Thanks in advance.
= =C2=A0
Yours sincerely,
Lei Yan
--047d7bdc8f5e8be39e04e08ace8d-- From dwing@cisco.com Tue Jul 2 12:28:47 2013 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 6553621F9B1B for ; Tue, 2 Jul 2013 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIAJTcrZu5wu for ; Tue, 2 Jul 2013 12:28:42 -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 653F721F9B21 for ; Tue, 2 Jul 2013 12:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1937; q=dns/txt; s=iport; t=1372793322; x=1374002922; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=786njGIP+wmc5JQ2lU5AqDEsXZ7Yjcj83BC5Js2hoOs=; b=Pa0RUOXx+1pimE3RVy7IIl5fQ2jmlc4gBsjPnXIvEqO+Tv+5DyA3yFyB FJ97+xTgkwI9rH5I0hKJ3pjomD+JAjD2jmh+7UJ/m55lQ2egnWDgnOcLl X9vfr6bWc1swkEB5LLH1TP7BgIOdi3rnVSZrEE2sUYBA24oqaLrwEybhV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAHsn01GrRDoJ/2dsb2JhbABagwmEArxPgQgWdIIjAQEBAwEjVgULCxoCJgICITYGE4d9AwkFqjSISw2IUoEmi0uCNjMHglEzZwOJI4w/gWeMIIUlgzEc X-IronPort-AV: E=Sophos;i="4.87,982,1363132800"; d="scan'208";a="82509571" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 02 Jul 2013 19:28:41 +0000 Received: from sjc-vpn2-667.cisco.com (sjc-vpn2-667.cisco.com [10.21.114.155]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r62JSeY4006552; Tue, 2 Jul 2013 19:28:40 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Tue, 2 Jul 2013 12:28:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C8E54F3-DD6C-4F29-B609-30BD5C1FF995@cisco.com> References: To: vic yan X-Mailer: Apple Mail (2.1508) Cc: pcp@ietf.org Subject: Re: [pcp] questions about the DNS Security under simple threat model 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, 02 Jul 2013 19:28:47 -0000 On Jul 2, 2013, at 10:38 AM, vic yan wrote: > Dear authors=EF=BC=8C > I have some questions about the DNS Security under the simple = threat model in section 18.1 of RFC6887 . > As described in the simple threat model, the PCP clients are = secure against off-path attackers who can spoof the PCP server's IP = address. In PCP, a client can discover the PCP server's address via a = DNS query of PCP Server Domain Name in DHCPv6 option = [I-D.ieft-pcp-dhcp]. RFC6887 describes one mechanism to communicate to the PCP server -- use = the default router's IP address. The default router's IP address is = most typically learned via DHCPv4, DHCPv6, or IPv6 Route Advertisement. = Those three mechanisms are typically un-protected, although there are = mechanisms to protect them but are not implemented in common OSs and are = even less often deployed (e.g., DHCP Authentication RFC3118). = draft-ietf-pcp-dhcp describes a DHCP option to indicate a different PCP = server, which is not the default router. That DHCP information would = need to be protected in the same way that other DHCP options are = provided to the client (e.g., NTP server, default router, SIP proxy, and = so on), through protections such as DHCP Guard. > But this client may encount Pharming by a DNS attacker.=20 > I'm wondering whether the data origin authentication and data = integrity to the DNS is within the scope of the above simple thread = model? And if the three conditions described in section 18.1 of = [RFC6887] are satisfied, can PCP clients be secure against the Pharming = of PCP Server without deploying DNSsec? I don't think those protections are sufficient if the attacker is = attacking DNS and you would need DNSSEC to protect against such a DNS = attack. > =20 > I look forward to a reply at your earliest convenience. Thanks = in advance. -d From dthaler@microsoft.com Tue Jul 2 15:00:14 2013 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 7A5A821F92FC for ; Tue, 2 Jul 2013 15:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8AmZYe9gFyY for ; Tue, 2 Jul 2013 14:59:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id C066021F92A5 for ; Tue, 2 Jul 2013 14:59:59 -0700 (PDT) Received: from BY2FFO11FD011.protection.gbl (10.1.15.203) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 2 Jul 2013 21:59:58 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 2 Jul 2013 21:59:58 +0000 Received: from DB8EHSOBE029.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 2 Jul 2013 21:59:58 +0000 Received: from mail145-db8-R.bigfish.com (10.174.8.229) by DB8EHSOBE029.bigfish.com (10.174.4.92) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 21:59:23 +0000 Received: from mail145-db8 (localhost [127.0.0.1]) by mail145-db8-R.bigfish.com (Postfix) with ESMTP id EE22D1E02DF for ; Tue, 2 Jul 2013 21:59:22 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -10 X-BigFish: PS-10(z36e9nzda00hdc73hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: softfail (mail145-db8: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(558084003)(51856001)(54356001)(74366001)(76576001)(33646001)(59766001)(4396001)(80022001)(50986001)(77982001)(47976001)(65816001)(16406001)(56776001)(49866001)(83072001)(63696002)(46102001)(69226001)(76482001)(47736001)(54316002)(74706001)(81342001)(74316001)(31966008)(77096001)(74662001)(79102001)(76786001)(81542001)(74876001)(47446002)(76796001)(56816003)(74502001)(76176001)(53806001)(140573001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail145-db8 (localhost.localdomain [127.0.0.1]) by mail145-db8 (MessageSwitch) id 1372802360891881_13862; Tue, 2 Jul 2013 21:59:20 +0000 (UTC) Received: from DB8EHSMHS014.bigfish.com (unknown [10.174.8.228]) by mail145-db8.bigfish.com (Postfix) with ESMTP id D67E580045 for ; Tue, 2 Jul 2013 21:59:20 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS014.bigfish.com (10.174.4.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 2 Jul 2013 21:59:20 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.324.0; Tue, 2 Jul 2013 21:59:19 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.702.21; Tue, 2 Jul 2013 21:59:16 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.25]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.101]) with mapi id 15.00.0702.005; Tue, 2 Jul 2013 21:59:16 +0000 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Nomcom still beating bushes Thread-Index: Ac53b18yoAEkV6dHTSmd22Jd8e8Lfg== Date: Tue, 2 Jul 2013 21:59:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:1a:3:985f:672a:51c3:e2a1] x-forefront-prvs: 0895DF8FFD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB269.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(54316002)(47776003)(54356001)(16676001)(51856001)(81342001)(23726002)(33646001)(46102001)(4396001)(76786001)(46406003)(47736001)(47976001)(81542001)(31966008)(77982001)(69226001)(50466002)(83072001)(74662001)(49866001)(56776001)(53806001)(50986001)(74706001)(80022001)(63696002)(76796001)(76176001)(558084003)(74316001)(76482001)(76576001)(65816001)(79102001)(47446002)(56816003)(59766001)(77096001)(6806003)(44976004)(74876001)(20776003)(74502001)(74366001)(140573001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037; H:TK5EX14HUBC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0895DF8FFD Subject: [pcp] Nomcom still beating bushes 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, 02 Jul 2013 22:00:14 -0000 In case you missed it, the Nomcom is still looking for volunteers for the p= ool. Please consider submitting your name. You can send a message to nomc= om-chair-2013@ietf.org to do so. Some background about the nomcom is at ht= tps://www.ietf.org/nomcom/. -Dave From bingxuere@gmail.com Tue Jul 2 15:26:46 2013 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 783D511E810E for ; Tue, 2 Jul 2013 15:26:46 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy-QHtj1Fk75 for ; Tue, 2 Jul 2013 15:26:46 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DBAC111E8100 for ; Tue, 2 Jul 2013 15:26:45 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ht10so3186504vcb.32 for ; Tue, 02 Jul 2013 15:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V27TX3aVPs65IWcWviy8xp4B+EbgOH5Wmdoev9xrsvw=; b=FbsYAdAsfmT9yKjWqTcEQOQ8BA/Ul6UPB2/XZj7yAEAFaU/v+iO2n7PcA1TxOX3PH4 mR794rWWSlJUwfKTo7LbNVt70XX+uZluRXGZhP0LXCGyCsUUEzrPgd7iEUgdiSiwbsiI hcoZZbm+eYgjQFwIodESeeWQtDqVXnRrsPqh+eXE7jkFtzt62rXRdXFDXmpcjPeqDYVe 9sW+7kgO1JGaGKVC3rM/hcnsv+iVavbmwMcAclWPurrSX/hpIakIbLe0xiAoow76OOaI XtxZxLWYb6kSnesTFGVa1jMyo5IRx5BcQ+Lo8FA0LIw82cgSOWgtlNZSrCSVdtDmLacd 5gFw== MIME-Version: 1.0 X-Received: by 10.221.31.130 with SMTP id sg2mr11620755vcb.86.1372804004256; Tue, 02 Jul 2013 15:26:44 -0700 (PDT) Received: by 10.220.210.202 with HTTP; Tue, 2 Jul 2013 15:26:44 -0700 (PDT) In-Reply-To: <51B05964.1080208@viagenie.ca> References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> <51B041F6.6040800@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> <51B05964.1080208@viagenie.ca> Date: Wed, 3 Jul 2013 06:26:44 +0800 Message-ID: From: Qiong To: Simon Perreault Content-Type: multipart/alternative; boundary=001a1133a04c0569ab04e08ed791 Cc: "pcp@ietf.org" Subject: [pcp] [Softwires] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-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, 02 Jul 2013 22:26:46 -0000 --001a1133a04c0569ab04e08ed791 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Simon, On Thursday, June 6, 2013, Simon Perreault wrote: > Le 2013-06-06 11:07, Qiong a =C3=A9crit : >> >> The hash computation can be updated to rely on IP-based information, >> no port numbers would be needed. >> >> [Qiong] That will cost a lot, especially when lwAFTR is deployed in more >> a centralized way that a lot of routers along the path all need to be >> updated. > > I think this is a core issue that needs discussion. > > Qiong, are you referring to ECMP? Right, exactly. Currently, different vendors, even different versions are implementing in a different way. Best wishes Qiong > > Simon > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a1133a04c0569ab04e08ed791 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Simon,

On Thursday, June 6, 2013, Simon Perreault <simon.perreault@viagenie.ca>= wrote:
> Le 2013-06-06 11:07, Qiong a =C3=A9crit :
>>
&g= t;> =C2=A0 =C2=A0 The hash computation can be updated to rely on IP-base= d information,
>> =C2=A0 =C2=A0 no port numbers would be needed.
>>
>= > [Qiong] That will cost a lot, especially when lwAFTR is deployed in mo= re
>> a centralized way that a lot of routers along the path all n= eed to be
>> updated.
>
> I think this is a core issue that needs d= iscussion.
>
> Qiong, are you referring to ECMP?

Right, = exactly. Currently, different vendors, even different versions are implemen= ting in a different way.

Best wishes
Qiong
>
> Simon
>

--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude


Open source code:
lig= htweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--001a1133a04c0569ab04e08ed791-- From bingxuere@gmail.com Tue Jul 2 21:10:58 2013 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 0AAC111E814C for ; Tue, 2 Jul 2013 21:10:58 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdHzJLG-aQrv for ; Tue, 2 Jul 2013 21:10:57 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB7B11E8149 for ; Tue, 2 Jul 2013 21:10:57 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so5430523veb.40 for ; Tue, 02 Jul 2013 21:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=daHLpVbnqOFvSaV7vCZLmMm9dtKbmV+5qgX/5ixy1zM=; b=XHIQyIILB5JSrBxqlTgJvnS0xEf1SL6V3mrgYB8jjrPQ9KVhQpvavuvW+LMj1/QrRD B+xmXVc1WHpZjWpA9NQhqOp7k+2D1TUGnfCQvF6hPA0DzgxntDT7MA4OvTJtJtqw3hpk 2nivcDYoS/Mo+/PGRuO/SN6gjW9FvezrP3ZUo1tKX7dtN1QSJixsb8Zqz+BUwwrf4yMw iHwg7AlacxztvToAK9M5UOSwaijyutjcNppJmXBvzF9Y5xEy9wuNhepa2RKMxGyZ6Y3e 7cJSCO+coBq3337Xomyrzi+2Yz86imzId1FjcJIkJU5XJTJzY4isxtoLTUTSjOJWIaMv i8HQ== X-Received: by 10.58.172.39 with SMTP id az7mr6438515vec.13.1372824656666; Tue, 02 Jul 2013 21:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.210.202 with HTTP; Tue, 2 Jul 2013 21:10:16 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED58ED01D@PUEXCB1B.nanterre.francetelecom.fr> References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> <51B041F6.6040800@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> <51B05964.1080208@viagenie.ca> <4BCA290E-BBD9-4AF5-976A-24B9644A62C4@gmail.com> <94C682931C08B048B7A8645303FDC9F36ED58ED01D@PUEXCB1B.nanterre.francetelecom.fr> From: Qiong Date: Wed, 3 Jul 2013 12:10:16 +0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7b5d8a67ffe5c004e093a5af Cc: "pcp@ietf.org" Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-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: Wed, 03 Jul 2013 04:10:58 -0000 --047d7b5d8a67ffe5c004e093a5af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Med, Sorry for so late reply...just find I have missed it. Some comments inline. On Fri, Jun 7, 2013 at 8:39 PM, wrote: > Please see inline. > > >-----Message d'origine----- > >De : bingxuere@gmail.com [mailto:bingxuere@gmail.com] > >Envoy=C3=A9 : jeudi 6 juin 2013 15:27 > >=C3=80 : Simon Perreault > >Cc : BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org > >Objet : Re: [pcp] Fwd: New Version Notification for draft-perreault- > >softwire-lw4over6-pcp-00.txt > > > >Hi Simon, > > > >On 2013-6-6, at 17:41, Simon Perreault > wrote: > > > >> Le 2013-06-06 11:07, Qiong a =C3=A9crit : > >>> The hash computation can be updated to rely on IP-based informatio= n, > >>> no port numbers would be needed. > >>> > >>> [Qiong] That will cost a lot, especially when lwAFTR is deployed in > more > >>> a centralized way that a lot of routers along the path all need to be > >>> updated. > [Med] .. but isn't L3-based ECMP LB needed for lw4over6 to work in your > case? > [Qiong] right. But different vendors (even different versions) have different default configurations on L3 or L4-based ECMP LB. For example, the default configuration of NE5000e with version V3 is using L3 ECMP while V8 100G is using L4 ECMP. So if there are a lot of existing routers along the path, we need to check whether the current configuration is L3-based ECMP or L4-based. That will introduce a lot of work. The encapsulation mode will get rid of all these work and the intermediate routers have to use L3-base ECMP even configured with L4-based ECMP. > > >> > >> I think this is a core issue that needs discussion. > >> > >> Qiong, are you referring to ECMP? > >[Qiong] Right, exactly. Currently, our routers from different vendors ev= en > >with different versions may implement ECMP differently. > [Med] Can you please point out an industrial product which supports > L4-based ECMP LB and not L3-based one? > [Qiong] see above Thanks a lot! Best wishes Qiong --047d7b5d8a67ffe5c004e093a5af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Med,

Sorry for so late reply= ...just find I have missed it.

Some co= mments inline.


On Fri, Jun 7, 2013 at 8:39 PM, <mohamed.boucadair@orange.com<= /a>> wrote:
Please see inline.

>-----Message d'origine-----
>De=C2=A0: bingxuere@gmail.com [mailto:bingxuere@gmail.com] >Envoy=C3=A9=C2=A0: jeudi 6 juin 2013 15:27
>=C3=80=C2=A0: Simon Perreault
>Cc=C2=A0: BOUCADAIR Mohamed OLNC/OLN; p= cp@ietf.org
>Objet=C2=A0: Re: [pcp] Fwd: New Version Notification = for draft-perreault-
>softwire-lw4over6-pcp-00.txt
>
>Hi Simon,
>
>On 2013-6-6, at 17:41, Simon Perreault <simon.perreault@viagenie.ca> wrote:
>
>> Le 2013-06-06 11:07, Qiong a =C3=A9crit :
>>> =C2=A0 =C2=A0The hash computation can be updated to rely on IP= -based information,
>>> =C2=A0 =C2=A0no port numbers would be needed.
>>>
>>> [Qiong] That will cost a lot, especially when lwAFTR is deploy= ed in more
>>> a centralized way that a lot of routers along the path all nee= d to be
>>> updated.
[Med] .. but isn't L3-based ECMP LB needed for lw4over6 to work i= n your case?
[Qiong] right. But different vendor= s (even different versions) have different default configurations on L3 or = L4-based ECMP LB.=C2=A0
For example, the default configuration of NE5000e with version V= 3 is using L3 ECMP while V8 100G is using L4 ECMP.=C2=A0
So= if there are a lot of existing routers along the path, we need to check wh= ether the current configuration is L3-based ECMP or L4-based. That will int= roduce a lot of work.
The encapsulation mode will get rid of all these work and the in= termediate routers have to use L3-base ECMP even configured with L4-based E= CMP.

>>
>> I think this is a core issue that needs discussion.
>>
>> Qiong, are you referring to ECMP?
>[Qiong] Right, exactly. Currently, our routers from different vendors e= ven
>with different versions may implement ECMP differently.
[Med] Can you please point out an industrial product which supports L= 4-based ECMP LB and not L3-based one?
[Qiong] se= e above

Thanks a lot!

Best wishes
Qiong=C2=A0
--047d7b5d8a67ffe5c004e093a5af-- From repenno@cisco.com Wed Jul 3 17:34:15 2013 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 B5B5621F8475 for ; Wed, 3 Jul 2013 17:34:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APcgzZQq3DSs for ; Wed, 3 Jul 2013 17:34:11 -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 DCC7211E81CF for ; Wed, 3 Jul 2013 17:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1542; q=dns/txt; s=iport; t=1372898049; x=1374107649; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=rriwEraqjC38xpxFi4FiUOXGiY0D+PA5NmkpJt/1lLw=; b=ci5T04jljqNkkQwNRLT5CQ276cL8I5docHpy36155ecPfKBYF9nwAAHx Sf70Og9O+oecKLvPg0cBJFlqJV5AV76vOj8cPOSEIqlnVsFXinv7ClYc9 oPJGN7BKjWiaFrYZIEOq6RoiG9CdKG8iabxepZfmtrYH7iRcb69XKOvME w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAKPB1FGtJV2a/2dsb2JhbABagwkyScA8gQkWdIIjAQEBAwE6UQEZAwECCxRCHQgCBBMIAYgABgyaGaAWjzo4gwRpA5hykByDEYIo X-IronPort-AV: E=Sophos;i="4.87,991,1363132800"; d="scan'208";a="230762042" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 04 Jul 2013 00:34:08 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r640Y2vq018177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Jul 2013 00:34:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 19:34:03 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: PCP Flowdata Option Thread-Index: AQHOeE4uX8qlWuTII0urdpoqWxoKJQ== Date: Thu, 4 Jul 2013 00:34:02 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090C399F@xmb-rcd-x04.cisco.com> 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.86.255.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <352CE1B873729C4F996C85C45337819E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] PCP Flowdata 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, 04 Jul 2013 00:34:15 -0000 Hello, We submitted a draft that proposes a new flow data option that allows PCP client to request or query QoS related parameters. For reasons discussed in the draft we believe that extending PCP with this functionality is a natural choice given its inherent ability to install flow state.=20 Thanks, > >> From: >> Subject: New Version Notification for draft-wing-pcp-flowdata-00.txt >> Date: July 3, 2013 12:35:01 PM PDT >> To: Tirumaleswar Reddy , Dan Wing , >>Reinaldo Penno >>=20 >>=20 >> A new version of I-D, draft-wing-pcp-flowdata-00.txt >> has been successfully submitted by Dan Wing and posted to the >> IETF repository. >>=20 >> Filename: draft-wing-pcp-flowdata >> Revision: 00 >> Title: PCP Flowdata Option >> Creation date: 2013-07-03 >> Group: Individual Submission >> Number of pages: 17 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-wing-pcp-flowdata-00.txt >> Status: http://datatracker.ietf.org/doc/draft-wing-pcp-flowdata >> Htmlized: http://tools.ietf.org/html/draft-wing-pcp-flowdata-00 >>=20 >>=20 >> Abstract: >> This document defines a mechanism for a host to signal flow >> characteristics to the network, and the network to signal its ability >> to accommodate that flow back to the host. The mechanism defines a >> new PCP option for the existing MAP and PEER opcodes. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 > From praspati@cisco.com Wed Jul 10 04:58:08 2013 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 B9B9B21F9E0C for ; Wed, 10 Jul 2013 04:58:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDXGwOBkaOd0 for ; Wed, 10 Jul 2013 04:58:04 -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 E043A21F9E90 for ; Wed, 10 Jul 2013 04:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1227; q=dns/txt; s=iport; t=1373457482; x=1374667082; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=x4xHJc0/i2/UrZ96gcTLjXbJ5+XqcbjkvP0Zl6iLNYQ=; b=IDbMYIoq2fZ+BnQ8B4leqa27Sb0AqWCXrc4IiWTX7Ngw2nDQK4eCHbKs Glk9qzwxYWnJr1Gut2xjeg4yPb2P/kLOGGD9sKy+HTdjC0TiLgDQzJ23d f9b0h4KppCl1ddMNWBPtyo/huyp95PclB84UBniZvHgsQnGGmqTvZNbfK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFALRL3VGtJXG//2dsb2JhbABagwkyRwbBEIERFnSCIwEBAQQ6NAkUAQgiFEIbAQYDAgQTCAGIBgcFmSygHI8yOIMJbAOZAJAhgxGCKA X-IronPort-AV: E=Sophos;i="4.87,1035,1363132800"; d="scan'208";a="233047666" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jul 2013 11:58:01 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6ABw1pZ015280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Jul 2013 11:58:01 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 10 Jul 2013 06:58:01 -0500 From: "Prashanth Patil (praspati)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-reddy-pcp-auth-req-04.txt Thread-Index: AQHOfU6E4TfS+LL3Ckmz05Bk4YNsg5leftgA Date: Wed, 10 Jul 2013 11:58:00 +0000 Message-ID: In-Reply-To: <20130710091857.29922.66353.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.68.21.104] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D4729244D8A2E42BB427D9653116EF8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-reddy-pcp-auth-req-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: Wed, 10 Jul 2013 11:58:08 -0000 Revised PCP authentication requirements has been published. Updated REQ-4, REQ-9 and REQ-14 as per discussions on the mailing list. -Prashanth On 10/07/13 2:48 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-reddy-pcp-auth-req-04.txt >has been successfully submitted by Tirumaleswar Reddy and posted to the >IETF repository. > >Filename: draft-reddy-pcp-auth-req >Revision: 04 >Title: PCP Authentication Requirements >Creation date: 2013-07-10 >Group: Individual Submission >Number of pages: 9 >URL: =20 >http://www.ietf.org/internet-drafts/draft-reddy-pcp-auth-req-04.txt >Status: http://datatracker.ietf.org/doc/draft-reddy-pcp-auth-req >Htmlized: http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-pcp-auth-req-04 > >Abstract: > In an attempt to reach consensus on a PCP authentication mechanism, > this document describes requirements for PCP authentication. It is > hoped this can serve as the basis for a comparison of PCP > authentication mechanisms. > > =20 > =20 > > >The IETF Secretariat > From dthaler@microsoft.com Sun Jul 14 17:33:31 2013 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 77B7F21F9C96 for ; Sun, 14 Jul 2013 17:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.362 X-Spam-Level: X-Spam-Status: No, score=-100.362 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxSB9HASvSfT for ; Sun, 14 Jul 2013 17:33:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id E117521F9C33 for ; Sun, 14 Jul 2013 17:33:24 -0700 (PDT) Received: from BY2FFO11FD023.protection.gbl (10.1.15.204) by BY2FFO11HUB036.protection.gbl (10.1.14.179) with Microsoft SMTP Server (TLS) id 15.0.717.3; Mon, 15 Jul 2013 00:33:23 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Mon, 15 Jul 2013 00:33:23 +0000 Received: from CO9EHSOBE027.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 15 Jul 2013 00:33:23 +0000 Received: from mail130-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Mon, 15 Jul 2013 00:33:22 +0000 Received: from mail130-co9 (localhost [127.0.0.1]) by mail130-co9-R.bigfish.com (Postfix) with ESMTP id DD4A83C024C for ; Mon, 15 Jul 2013 00:33:22 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 3 X-BigFish: PS3(z551bizzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz31h2a8h668h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail130-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(76176001)(81542001)(76796001)(49866001)(79102001)(56776001)(76576001)(51856001)(74502001)(4396001)(56816003)(76786001)(46102001)(16406001)(77982001)(47976001)(65816001)(59766001)(47736001)(81342001)(69226001)(76482001)(74706001)(31966008)(33646001)(74366001)(54316002)(74662001)(74316001)(66066001)(80022001)(63696002)(47446002)(54356001)(74876001)(53806001)(83072001)(77096001)(50986001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:50.135.4.20; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail130-co9 (localhost.localdomain [127.0.0.1]) by mail130-co9 (MessageSwitch) id 1373848399845708_21133; Mon, 15 Jul 2013 00:33:19 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.246]) by mail130-co9.bigfish.com (Postfix) with ESMTP id CABF668005A for ; Mon, 15 Jul 2013 00:33:19 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Jul 2013 00:33:19 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.329.3; Mon, 15 Jul 2013 00:33:18 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.731.11; Mon, 15 Jul 2013 00:33:15 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.140]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.140]) with mapi id 15.00.0731.000; Mon, 15 Jul 2013 00:33:15 +0000 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXA== Date: Mon, 15 Jul 2013 00:33:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 09086FB5C5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB269.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(74876001)(81342001)(6806004)(74366001)(69226001)(81542001)(76482001)(77096001)(31966008)(80022001)(4396001)(59766001)(53806001)(49866001)(47976001)(47776003)(44976005)(54356001)(20776003)(54316002)(50986001)(46102001)(47736001)(56776001)(47446002)(16676001)(74502001)(74706001)(66066001)(51856001)(79102001)(74662001)(63696002)(50466002)(83072001)(76796001)(76576001)(76176001)(56816003)(23756003)(76786001)(33646001)(65816001)(77982001)(74316001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB036; H:TK5EX14MLTC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 09086FB5C5 Subject: [pcp] CONSENSUS CALL on PCP security 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, 15 Jul 2013 00:33:31 -0000 The WG has discussed two approaches for using EAP with PCP: direct EAP-in-PCP vs using PANA. At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP and 10 or 11 for PANA. There was significant confusion/disagreement around requirements and proposed solutions at that time. At IETF 85, we again polled the room and got a different result, this time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however, still significant confusion/disagreement around requirements and proposed solutions. Since IETF 85, we have made lots of progress on getting agreement on the requirements, and draft-reddy-pcp-auth-req now seems to be relatively stable without significant areas of disagreement known. Discussion may of course continue if new issues are raised but we believe any additional changes are unlikely to affect people's position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA. The general sense of the WG also seems to be that either approach could be made to fit the requirements, so we believe it is now time for us to determine consensus (draft-resnick-on-consensus is a great read) on the approach question. We know many folks would just like to=20 make a decision and move on. Hence the chairs would like to ask the WG which solution direction the WG should pursue in meeting the requirements. Please state your recommendation on this thread, preferably along with your rationale. Avoid responding on this thread to others' rationale, use a separate thread as needed. To help us judge consensus, please use the template below and respond by SUNDAY JULY 28. -Dave and Reinaldo --- 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. =A0=A0=A0 2) Could you *live with* PANA? If not, state reason you would object. =A0=A0=A0 3) If you said yes to both 1 and 2, but have a strong preference between the two, which approach do you prefer and why? =A0=A0=A0 .=A0 From internet-drafts@ietf.org Mon Jul 15 07:03:25 2013 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 40DD511E80EC; Mon, 15 Jul 2013 07:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbaANrsVIU1V; Mon, 15 Jul 2013 07:03:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A7811E80E8; Mon, 15 Jul 2013 07:03:19 -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.51.p2 Message-ID: <20130715140319.19185.45116.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 07:03:19 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-port-set-02.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, 15 Jul 2013 14:03:25 -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) Extension for Port Set Alloc= ation Author(s) : Qiong Sun Mohamed Boucadair Senthil Sivakumar Cathy Zhou Tina Tsou Simon Perreault Filename : draft-ietf-pcp-port-set-02.txt Pages : 13 Date : 2013-07-15 Abstract: This document defines an extension to PCP allowing clients to manipulate sets of ports as a whole. This is accomplished by a new MAP option: PORT_SET. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-port-set There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-port-set-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-port-set-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Mon Jul 15 07:41:41 2013 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 8F15921E8056 for ; Mon, 15 Jul 2013 07:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njxmn-WXHrSL for ; Mon, 15 Jul 2013 07:41:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1507B11E80DC for ; Mon, 15 Jul 2013 07:41:41 -0700 (PDT) Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6C23740437 for ; Mon, 15 Jul 2013 10:41:40 -0400 (EDT) Message-ID: <51E40A24.5030500@viagenie.ca> Date: Mon, 15 Jul 2013 16:41:40 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: pcp@ietf.org References: <20130715140319.19185.45116.idtracker@ietfa.amsl.com> In-Reply-To: <20130715140319.19185.45116.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [pcp] I-D Action: draft-ietf-pcp-port-set-02.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, 15 Jul 2013 14:41:41 -0000 Change log: - Added the Offset parameter as discussed during the interim meeting. It allows NATs to map a subset of the Internal Port Set that starts from anywhere in the set (instead of always starting at the Internal Port). - Clarified text about resource unavailability handling and the nonce check procedures. Simon Le 2013-07-15 16:03, internet-drafts@ietf.org a écrit : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Port Control Protocol Working Group of the IETF. > > Title : Port Control Protocol (PCP) Extension for Port Set Allocation > Author(s) : Qiong Sun > Mohamed Boucadair > Senthil Sivakumar > Cathy Zhou > Tina Tsou > Simon Perreault > Filename : draft-ietf-pcp-port-set-02.txt > Pages : 13 > Date : 2013-07-15 > > Abstract: > This document defines an extension to PCP allowing clients to > manipulate sets of ports as a whole. This is accomplished by a new > MAP option: PORT_SET. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pcp-port-set > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pcp-port-set-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-port-set-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From trac@tools.ietf.org Mon Jul 15 07:41:48 2013 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 5D48321F99CD for ; Mon, 15 Jul 2013 07:41:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJOklZV6aT2P for ; Mon, 15 Jul 2013 07:41:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5D111E80EC for ; Mon, 15 Jul 2013 07:41:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:37182 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UyjyC-0003Dr-7W; Mon, 15 Jul 2013 16:41:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: pcp Date: Mon, 15 Jul 2013 14:41:44 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/65#comment:1 Message-ID: <074.1dba46cc6dac799157e7932b7532fc61@tools.ietf.org> References: <059.b0df0ae726efb01039302bce1946c177@tools.ietf.org> X-Trac-Ticket-ID: 65 In-Reply-To: <059.b0df0ae726efb01039302bce1946c177@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, mohamed.boucadair@orange.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mohamed.boucadair@orange.com Resent-Message-Id: <20130715144145.2A5D111E80EC@ietfa.amsl.com> Resent-Date: Mon, 15 Jul 2013 07:41:45 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #65: Dave Thaler's comments on draft-ietf-pcp-nat64-prefix64-02 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 14:41:48 -0000 #65: Dave Thaler's comments on draft-ietf-pcp-nat64-prefix64-02 Changes (by mohamed.boucadair@orange.com): * status: new => closed * resolution: => fixed Comment: http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-03 integrates all the proposed changes. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-pcp- dthaler@microsoft.com | nat64-prefix64@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: | Version: nat64-prefix64 | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: pcp From praspati@cisco.com Mon Jul 15 10:49:51 2013 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 3D5A311E81CB for ; Mon, 15 Jul 2013 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNLYn0VIlSD7 for ; Mon, 15 Jul 2013 10:49:46 -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 AD80D11E81CD for ; Mon, 15 Jul 2013 10:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18434; q=dns/txt; s=iport; t=1373910580; x=1375120180; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=C9TdLGteqgP4VfR6qT99aHkXoZpHnTgafm7bIKK41q4=; b=NrVcAo3gYTuS6q5NQ9GfO01qhZzAAxUGoEByv0BOb4bgVvrQ3iokfoLl 4f9XkurF1x3Axl2l5Gz7prF60eiY2eVDR8tZex3EnMtaShOIIGH1JBs0M XtAhAo4QQhJMtIfxnmtCHAr/MPtXQPsdSyKmUPALs8iiYEErDM0VM5VDg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FACo15FGtJXG//2dsb2JhbABRCYJCRDRPuRyINoETFnSCJQEEeRIBCCIdKBEUEQIEDgUIh3YDDwyseg2IXox6gS+BCjEHgwttA5NEgi+DEop+hSaDEoIo X-IronPort-AV: E=Sophos;i="4.89,670,1367971200"; d="scan'208,217";a="235016907" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 15 Jul 2013 17:49:36 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6FHnajs029347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 17:49:36 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 12:49:36 -0500 From: "Prashanth Patil (praspati)" To: Ben McCann Thread-Topic: [pcp] PCP Authentication *Technique* Requirements Thread-Index: AQHOgYOrY67Zcr3LHUyYECKqu7Ohvw== Date: Mon, 15 Jul 2013 17:49:36 +0000 Message-ID: In-Reply-To: <51BB6571.3000901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.65.48.101] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE314C5xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP Authentication *Technique* Requirements 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, 15 Jul 2013 17:49:51 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE314C5xmbrcdx07ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben, On 15/06/13 12:18 AM, "Ben McCann" > wrote: draft-reddy-pcp-auth-03 defines about 14 requirements for the PCP authentic= ation protocol. These requirements don't include any discussion about the c= ryptographic strength or user identity model of the authentication techniqu= es(s) used within PCP authentication. PRA: REQ-5 highlights basic requirements REQ-5: It is important that PCP not leak privacy information between the PCP client and PCP server, A. The authentication mechanism MUST be able to keep credentials hidden from eavesdroppers on path between the client and server. B. Confidentiality of the PCP messages is OPTIONAL for PCP request and response of opcodes MAP, PEER, ANNOUNCE and options THIRD_PARTY, PREFER_FAILURE and FILTER as explained in [RFC6887]. Other PCP drafts = MUST evaluate if confidentiality is OPTIONAL for new PCP opcodes and options introduced. C. PCP authentication SHOULD be immune to passive dictionary attacks. D. PCP Authentication MUST ensure that an attacker snooping PCP messages cannot guess the SA. Not sure if cryptographic strength and identity model be detailed, maybe a = requirement that the authentication framework support multiple cryptographi= c methods? It is then up to the parties to choose one based on their config= s/requirements. Same about the identity model I suppose. The current requirements are too vague on this point because, I think, ther= e's an assumption in the WG that PCP authentication will be based on EAP. I= agree. I don't think the PCP WG should invent authentication techniques. So, I suggest we change the following recommendation: REQ-11: It is RECOMMENDED to choose a widely deployed authentication technique with known security properties rather than inventing a new authentication mechanism. to a requirement: REQ-11: A widely deployed authentication technique with known security properties MUST be selected as the authentication mechanism within PC= P. PRA: Sure, a widely deployed auth technique eg EAP. I'd also add another recommendation: REQ-11-A: It is RECOMMENDED to choose an extensible authentication technique to ensure PCP authentication can adapt to future authentica= tion methods. PRA: Will do. -Prashanth This may be obvious to WG members who've followed the authentication discus= sion to date but it's not clear by looking at the PCP authentications requi= rements draft. The draft leaves open the possibility of inventing a new aut= hentication technique and I think that would be a distraction and a waste o= f time. -Ben McCann --_000_B235506D63D65E43B2E40FD27715372E1CE314C5xmbrcdx07ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <31DAB11851403D45A3BBD1ADBDD57757@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Ben,

On 15/06/13 12:18 AM, "Ben McCann" <bn.mccann@gmail.com> wrote:

draft-reddy-pcp-auth-03 defines a= bout 14 requirements for the PCP authentication protocol. These requirement= s don't include any discussion about the cryptographic strength or user ide= ntity model of the authentication techniques(s) used within PCP authentication.

PRA: REQ= -5 highlights basic requirements 
   REQ-5:  It is important that PCP not leak privac=
y information between
 
      the PCP client and PCP server,=

 
 
      A.  The authentication me=
chanism MUST be able to keep credentials
 
          hidden=
 from eavesdroppers on path between the client and
 
          server=
.
 
 
 
      B.  Confidentiality of th=
e PCP messages is OPTIONAL for PCP
 
          reques=
t and response of opcodes MAP, PEER, ANNOUNCE and
 
          option=
s THIRD_PARTY, PREFER_FAILURE and FILTER as explained in<=
/i>
 
          [RFC6887]. =
 Other PCP drafts MUST evaluate if confidentiality
 
          is OPT=
IONAL for new PCP opcodes and options introduced.
 
 
 
      C.  PCP authentication SH=
OULD be immune to passive dictionary
 
          attack=
s.
 
 
 
      D.  PCP Authentication MU=
ST ensure that an attacker snooping PCP
 
          messag=
es cannot guess the SA.

Not s= ure if cryptographic strength and ide= ntity model be detailed, maybe a requirement that the authentication framew= ork support multiple cryptographic methods? It is then up to the parties to choose one based on their configs/requirem= ents.

Same = about the identity model I suppose.



The current requirements are too vague on this point because, I think, ther= e's an assumption in the WG that PCP authentication will be based on EAP. I= agree. I don't think the PCP WG should invent authentication techniques.
So, I suggest we change the following recommendation:

   REQ-11:  It is RECOMMENDED to choose a widely deployed authenticat=
ion
      technique with known security properties rather than inventing a
      new authentication mechanism.

to a requirement:

   REQ-11:  A widely deployed authentication technique with known sec=
urity
      properties MUST be selected as the authentication mechanism within PC=
P.

PRA: Sure, a widely deployed auth technique eg EAP= .
I'd also add another recommendation:

   REQ-11-A:  It is RECOMMENDED to choose an extensible authentication
      technique to ensure PCP authentication can adapt to future authentica=
tion
      methods.

PRA: Will do.

-Prashanth
This may be obvious to WG members who've followed the authentication discus= sion to date but it's not clear by looking at the PCP authentications requi= rements draft. The draft leaves open the possibility of inventing a new aut= hentication technique and I think that would be a distraction and a waste of time.

-Ben McCann

 --_000_B235506D63D65E43B2E40FD27715372E1CE314C5xmbrcdx07ciscoc_-- From phdgang@gmail.com Mon Jul 15 18:51:01 2013 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 A257821E8097 for ; Mon, 15 Jul 2013 18:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcJBlc71KHMH for ; Mon, 15 Jul 2013 18:51:00 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id D157A21E8084 for ; Mon, 15 Jul 2013 18:50:50 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so2010691qak.14 for ; Mon, 15 Jul 2013 18:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yG3Q3DNvp3zHnFx3Qy+WX4q5FC3aRAmJ/dydtjPnljI=; b=iKz0tfrgegR+CJ+AeNbwxgWWrxGOSKU36Z/TWqYWg/3vXUlDcT28MHC3jC9D00bVFX ZRuc/08MMWq7lEnUkd4c0GQxB4UKPqvKDj1nRE+ZxAz4x0AZzsqRrjZAtlC0j4f/w2Q6 0lI+ZxM7owjt/3XslGvfP7Jgp49c3Fbubp/yLAUxW4NCkGsPKiKnhYF8nL4+eRUYgltD YFKWNNZEK9G38rTvFts5oeFgHm85zlAB1PC0NHilXQbcKkpwvEKIz2gJMs52uunh0Jb+ aUj9/9hGaCBFfuA3/T4aq41WtOjYNur3HTfT1uyfASE3gY7uyQ8l7mOEDq6OU8MVve8T 5JLg== MIME-Version: 1.0 X-Received: by 10.49.29.106 with SMTP id j10mr53970551qeh.37.1373939450249; Mon, 15 Jul 2013 18:50:50 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Mon, 15 Jul 2013 18:50:50 -0700 (PDT) In-Reply-To: <20130714063627.10944.67888.idtracker@ietfa.amsl.com> References: <20130714063627.10944.67888.idtracker@ietfa.amsl.com> Date: Tue, 16 Jul 2013 09:50:50 +0800 Message-ID: From: GangChen To: "pcp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [pcp] Fwd: I-D Action: draft-chen-pcp-mobile-deployment-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: Tue, 16 Jul 2013 01:51:02 -0000 Dear all, The new version of draft-chen-pcp-mobile-deployment is available. The update incorporates the comments from Tiru's detailed reviews. (Thank Tiru for his helpful comments) After several discussions/changes, we think the current version is stable and ready for the adoption. For the next step, we expect further guidance from the group. Many thanks PCP-Mobile Authors ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Sat, 13 Jul 2013 23:36:27 -0700 Subject: I-D Action: draft-chen-pcp-mobile-deployment-04.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Control Protocol in Mobile Network Author(s) : Gang Chen Zhen Cao Mohamed Boucadair Vizdal Ales Laurent Thiebaut Filename : draft-chen-pcp-mobile-deployment-04.txt Pages : 12 Date : 2013-07-13 Abstract: This memo provides a motivation description for the Port Control Protocol (PCP) deployment in a 3GPP mobile network environment. The document focuses on a mobile network specific issues (e.g. cell phone battery power consumption, keep-alive traffic reduction), PCP applicability to these issues is further studied and analyzed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-chen-pcp-mobile-deployment-04 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 tireddy@cisco.com Mon Jul 15 22:51:30 2013 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 1B9AB11E821A for ; Mon, 15 Jul 2013 22:51:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KwKzNN3Cq5F for ; Mon, 15 Jul 2013 22:51:25 -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 35F2121F8C71 for ; Mon, 15 Jul 2013 22:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2641; q=dns/txt; s=iport; t=1373953885; x=1375163485; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6vE+bxA176Wq5N9FS91n9MaMaBp2LkGMoq9b5m4AHqw=; b=kCzYWXaiitdh2zqDBjWmKsEYHNN/kKUwLXN9lS3MkFql1IgInacHJ29a hDRvOtwgoxXqLKHBTZwbsfXHOwBc0X6GnMJh4lQNfRnKnlkPRmtEWvG1+ cstVO4rElhpy+G9Ue6ACw2oi91+XSNe0iK10wv/JdFTPn2PBnoIm893nP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFABDf5FGtJV2Y/2dsb2JhbABagwY0T8FdgRAWdIIjAQEBBIEFBAIBCA4DBAEBCx0HMhQJCAIEARIIE4d1DLY6jzMGMgaDBW0DiG+QFpAkgxKCKA X-IronPort-AV: E=Sophos;i="4.89,674,1367971200"; d="scan'208";a="235289406" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 16 Jul 2013 05:51:00 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6G5p0XM011859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 05:51:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 00:51:00 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Dave Thaler , "pcp@ietf.org" Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: AQHOgYO2/UME/BL9NUa9YVGvlLydx5lmzBxw Date: Tue, 16 Jul 2013 05:50:59 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.48.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 16 Jul 2013 05:51:30 -0000 Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ie= tf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Monday, July 15, 2013 6:03 AM > To: pcp@ietf.org > Subject: [pcp] CONSENSUS CALL on PCP security >=20 > The WG has discussed two approaches for using EAP with PCP: > direct EAP-in-PCP vs using PANA. >=20 > At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP > and 10 or 11 for PANA. There was significant confusion/disagreement > around requirements and proposed solutions at that time. >=20 > At IETF 85, we again polled the room and got a different result, this > time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however, > still significant confusion/disagreement around requirements and > proposed solutions. >=20 > Since IETF 85, we have made lots of progress on getting agreement > on the requirements, and draft-reddy-pcp-auth-req now seems to be > relatively stable without significant areas of disagreement known. > Discussion may of course continue if new issues are raised but we > believe any additional changes are unlikely to affect people's > position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA. >=20 > The general sense of the WG also seems to be that either approach could b= e > made to fit the requirements, so we believe it is now time for us to > determine consensus (draft-resnick-on-consensus is a great read) > on the approach question. We know many folks would just like to > make a decision and move on. >=20 > Hence the chairs would like to ask the WG which solution direction the > WG should pursue in meeting the requirements. Please state your > recommendation on this thread, preferably along with your rationale. > Avoid responding on this thread to others' rationale, use a separate > thread as needed. >=20 > To help us judge consensus, please use the template below and > respond by SUNDAY JULY 28. >=20 > -Dave and Reinaldo >=20 > --- >=20 > 1) Could you *live with* EAP-in-PCP? If not, state reason you would objec= t. >=20 > =A0=A0=A0 >=20 > 2) Could you *live with* PANA? If not, state reason you would object. >=20 > =A0=A0=A0 >=20 > 3) If you said yes to both 1 and 2, but have a strong preference between > the two, which approach do you prefer and why? >=20 > =A0=A0=A0 .=A0 >=20 From yoshihiro.ohba@toshiba.co.jp Tue Jul 16 02:27:18 2013 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 CCFED11E827B for ; Tue, 16 Jul 2013 02:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=-1.999, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7QgNsxdI6Id for ; Tue, 16 Jul 2013 02:27:13 -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 E5C3611E826D for ; Tue, 16 Jul 2013 02:27:12 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r6G9R76q007231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 18:27:07 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6G9R7Vr027344; Tue, 16 Jul 2013 18:27:07 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 155; Tue, 16 Jul 2013 18:27:07 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6G9R7Qk027340; Tue, 16 Jul 2013 18:27:07 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r6G9R7fw005282; Tue, 16 Jul 2013 18:27:07 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA05281; Tue, 16 Jul 2013 18:27:06 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r6G9R6P8023003; Tue, 16 Jul 2013 18:27:06 +0900 (JST) Received: from TGXML330.toshiba.local by toshiba.co.jp id r6G9R6Z0017986; Tue, 16 Jul 2013 18:27:06 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.194]) by TGXML330.toshiba.local ([133.199.60.204]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 18:27:06 +0900 From: To: , , Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAAqkRqAABmN41A= Date: Tue, 16 Jul 2013 09:27:06 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D2FA81@tgxml338.toshiba.local> References: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.68] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 16 Jul 2013 09:27:19 -0000 SSB3b3VsZCBub3RlIHRoYXQgdGhlIHR3byBQQU5BIGFwcHJvYWNoZXMgKHNpZGUtYnktc2lkZSBh bmQgZW5jYXBzdWxhdGlvbikgbWF5IGhhdmUgZGlmZmVyZW5jZSBpbiBzdXBwb3J0aW5nIFBDUCBw cm94eS4gIEluIHRoZSBzaWRlLWJ5LXNpZGUgYXBwcm9hY2ggKGRyYWZ0LW9oYmEtcGNwLXBhbmEp LCBQQU5BIHJlbGF5IHdvdWxkIG5lZWQgdG8gYmUgaW1wbGVtZW50ZWQgb24gUENQIHByb3h5IHRv IGNvbW11bmljYXRlIGNsaWVudCdzIElQIGFkZHJlc3MgdG8gdGhlIHNlcnZlciBzaW5jZSBQQ1Ag VEhJUkRfUEFSVFkgb3B0aW9uIGlzIGNhcnJpZWQgb25seSBpbiBQQ1AgbWVzc2FnZS4gIEluIHRo ZSBlbmNhcHN1bGF0aW9uIGFwcHJvYWNoIChkcmFmdC1vaGJhLXBjcC1wYW5hLWVuY2FwKSwgUEFO QSByZWxheSB3b3VsZCBub3QgYmUgbmVlZGVkIHNpbmNlIFBDUCBUSElSRF9QQVJUWSBvcHRpb24g Y2FuIGJlIGNhcnJpZWQgaW4gYSBQQ1AgbWVzc2FnZSB0aGF0IGVuY2Fwc3VsYXRlcyBhIFBBTkEg bWVzc2FnZS4NCg0KU2luY2UgUEFOQSByZWxheSBpcyBzaW1wbGUgc3RhdGVsZXNzIHJlbGF5LCBp dCBzaG91bGQgbm90IGJlIGEgcHJvYmxlbSB3aXRoIHRoZSBzaWRlLWJ5LXNpZGUgYXBwcm9hY2gg YXMgbG9uZyBhcyBUSElSRF9QQVJUWSBvcHRpb24gaXMgdGhlIG9ubHkgUENQIG9wdGlvbiBpbnNl cnRlZCBieSBQQ1AgcHJveHkuICBIb3dldmVyLCBpZiBQQ1AgcHJveHkgaW5zZXJ0cyBvdGhlciBQ Q1Agb3B0aW9ucyBhcyB3ZWxsLCB0aGVuIEkgdGhpbmsgdGhlIGVuY2Fwc3VsYXRpb24gYXBwcm9h Y2ggY2FuIGJlIGJldHRlciB0aGFuIHRoZSBzaWRlLWJ5LXNpZGUgYXBwcm9hY2guDQoNClJlZ2Fy ZHMsDQpZb3NoaWhpcm8gT2hiYQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBwY3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KU2VudDogVHVlc2RheSwgSnVs eSAxNiwgMjAxMyAyOjUxIFBNDQpUbzogRGF2ZSBUaGFsZXI7IHBjcEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtwY3BdIENPTlNFTlNVUyBDQUxMIG9uIFBDUCBzZWN1cml0eQ0KDQpIaSBEYXZlLA0K DQpJbiB0aGUgcG9sbCB3aGVuIHlvdSByZWZlciB0byBQQU5BLCBwbGVhc2UgY2xhcmlmeSB0aGUg ZHJhZnQgeW91IGFyZSByZWZlcnJpbmcgdG8gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtb2hiYS1wY3AtcGFuYS0wNCBvciBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1v aGJhLXBjcC1wYW5hLWVuY2FwLTAxID8NCg0KLS1UaXJ1Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IERhdmUgVGhhbGVyIFttYWlsdG86ZHRoYWxlckBtaWNyb3NvZnQu Y29tXQ0KPiBTZW50OiBNb25kYXksIEp1bHkgMTUsIDIwMTMgNjowMyBBTQ0KPiBUbzogcGNwQGll dGYub3JnDQo+IFN1YmplY3Q6IFtwY3BdIENPTlNFTlNVUyBDQUxMIG9uIFBDUCBzZWN1cml0eQ0K PiANCj4gVGhlIFdHIGhhcyBkaXNjdXNzZWQgdHdvIGFwcHJvYWNoZXMgZm9yIHVzaW5nIEVBUCB3 aXRoIFBDUDoNCj4gZGlyZWN0IEVBUC1pbi1QQ1AgdnMgdXNpbmcgUEFOQS4NCj4gDQo+IEF0IElF VEYgODQsIHdlIHBvbGxlZCB0aGUgcm9vbSBhbmQgZ290IDUgaGFuZHMgZm9yIGRpcmVjdCBFQVAt aW4tUENQIA0KPiBhbmQgMTAgb3IgMTEgZm9yIFBBTkEuIFRoZXJlIHdhcyBzaWduaWZpY2FudCBj b25mdXNpb24vZGlzYWdyZWVtZW50IA0KPiBhcm91bmQgcmVxdWlyZW1lbnRzIGFuZCBwcm9wb3Nl ZCBzb2x1dGlvbnMgYXQgdGhhdCB0aW1lLg0KPiANCj4gQXQgSUVURiA4NSwgd2UgYWdhaW4gcG9s bGVkIHRoZSByb29tIGFuZCBnb3QgYSBkaWZmZXJlbnQgcmVzdWx0LCB0aGlzIA0KPiB0aW1lIDEy IGhhbmRzIGZvciBkaXJlY3QgRUFQLWluLVBDUCBhbmQgNiBmb3IgUEFOQS4gVGhlcmUgd2FzLCAN Cj4gaG93ZXZlciwgc3RpbGwgc2lnbmlmaWNhbnQgY29uZnVzaW9uL2Rpc2FncmVlbWVudCBhcm91 bmQgcmVxdWlyZW1lbnRzIA0KPiBhbmQgcHJvcG9zZWQgc29sdXRpb25zLg0KPiANCj4gU2luY2Ug SUVURiA4NSwgd2UgaGF2ZSBtYWRlIGxvdHMgb2YgcHJvZ3Jlc3Mgb24gZ2V0dGluZyBhZ3JlZW1l bnQgb24gDQo+IHRoZSByZXF1aXJlbWVudHMsIGFuZCBkcmFmdC1yZWRkeS1wY3AtYXV0aC1yZXEg bm93IHNlZW1zIHRvIGJlIA0KPiByZWxhdGl2ZWx5IHN0YWJsZSB3aXRob3V0IHNpZ25pZmljYW50 IGFyZWFzIG9mIGRpc2FncmVlbWVudCBrbm93bi4NCj4gRGlzY3Vzc2lvbiBtYXkgb2YgY291cnNl IGNvbnRpbnVlIGlmIG5ldyBpc3N1ZXMgYXJlIHJhaXNlZCBidXQgd2UgDQo+IGJlbGlldmUgYW55 IGFkZGl0aW9uYWwgY2hhbmdlcyBhcmUgdW5saWtlbHkgdG8gYWZmZWN0IHBlb3BsZSdzIA0KPiBw b3NpdGlvbiBvbiBvdmVyYWxsIHNvbHV0aW9uIGFwcHJvYWNoLCBpLmUuIGRpcmVjdCBFQVAtaW4t UENQIHZzLiBQQU5BLg0KPiANCj4gVGhlIGdlbmVyYWwgc2Vuc2Ugb2YgdGhlIFdHIGFsc28gc2Vl bXMgdG8gYmUgdGhhdCBlaXRoZXIgYXBwcm9hY2ggDQo+IGNvdWxkIGJlIG1hZGUgdG8gZml0IHRo ZSByZXF1aXJlbWVudHMsIHNvIHdlIGJlbGlldmUgaXQgaXMgbm93IHRpbWUgDQo+IGZvciB1cyB0 byBkZXRlcm1pbmUgY29uc2Vuc3VzIChkcmFmdC1yZXNuaWNrLW9uLWNvbnNlbnN1cyBpcyBhIGdy ZWF0IA0KPiByZWFkKSBvbiB0aGUgYXBwcm9hY2ggcXVlc3Rpb24uIFdlIGtub3cgbWFueSBmb2xr cyB3b3VsZCBqdXN0IGxpa2UgdG8gDQo+IG1ha2UgYSBkZWNpc2lvbiBhbmQgbW92ZSBvbi4NCj4g DQo+IEhlbmNlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBhc2sgdGhlIFdHIHdoaWNoIHNvbHV0 aW9uIGRpcmVjdGlvbiB0aGUgDQo+IFdHIHNob3VsZCBwdXJzdWUgaW4gbWVldGluZyB0aGUgcmVx dWlyZW1lbnRzLiBQbGVhc2Ugc3RhdGUgeW91ciANCj4gcmVjb21tZW5kYXRpb24gb24gdGhpcyB0 aHJlYWQsIHByZWZlcmFibHkgYWxvbmcgd2l0aCB5b3VyIHJhdGlvbmFsZS4NCj4gQXZvaWQgcmVz cG9uZGluZyBvbiB0aGlzIHRocmVhZCB0byBvdGhlcnMnIHJhdGlvbmFsZSwgdXNlIGEgc2VwYXJh dGUgDQo+IHRocmVhZCBhcyBuZWVkZWQuDQo+IA0KPiBUbyBoZWxwIHVzIGp1ZGdlIGNvbnNlbnN1 cywgcGxlYXNlIHVzZSB0aGUgdGVtcGxhdGUgYmVsb3cgYW5kIHJlc3BvbmQgDQo+IGJ5IFNVTkRB WSBKVUxZIDI4Lg0KPiANCj4gLURhdmUgYW5kIFJlaW5hbGRvDQo+IA0KPiAtLS0NCj4gDQo+IDEp IENvdWxkIHlvdSAqbGl2ZSB3aXRoKiBFQVAtaW4tUENQPyBJZiBub3QsIHN0YXRlIHJlYXNvbiB5 b3Ugd291bGQgb2JqZWN0Lg0KPiANCj4gwqDCoMKgIDxOTyBhbmQgc3RhdGUgcmVhc29uLCBvciBZ RVM+DQo+IA0KPiAyKSBDb3VsZCB5b3UgKmxpdmUgd2l0aCogUEFOQT8gSWYgbm90LCBzdGF0ZSBy ZWFzb24geW91IHdvdWxkIG9iamVjdC4NCj4gDQo+IMKgwqDCoCA8Tk8gYW5kIHN0YXRlIHJlYXNv biwgb3IgWUVTPg0KPiANCj4gMykgSWYgeW91IHNhaWQgeWVzIHRvIGJvdGggMSBhbmQgMiwgYnV0 IGhhdmUgYSBzdHJvbmcgcHJlZmVyZW5jZSANCj4gYmV0d2VlbiB0aGUgdHdvLCB3aGljaCBhcHBy b2FjaCBkbyB5b3UgcHJlZmVyIGFuZCB3aHk/DQo+IA0KPiDCoMKgwqAgPEVBUC1pbi1QQ1AsIG9y IFBBTkE+LsKgIDxzdGF0ZSByZWFzb24+DQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KcGNwIG1haWxpbmcgbGlzdA0KcGNwQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcA0K From alper.yegin@yegin.org Tue Jul 16 02:50:55 2013 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 22D3A11E8276 for ; Tue, 16 Jul 2013 02:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly3q1GnwKZM8 for ; Tue, 16 Jul 2013 02:50:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3100F11E828E for ; Tue, 16 Jul 2013 02:50:50 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MeyZt-1UnoY22Var-00OXKr; Tue, 16 Jul 2013 05:50:38 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D2FA81@tgxml338.toshiba.local> Date: Tue, 16 Jul 2013 12:50:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D2FA81@tgxml338.toshiba.local> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:3UleFkDmNCA6JvWCtzSt0c8d8sGrTmOUcaV7MM+zHLh NRQ/Kbk4V83rSJqNKiOzRAa7Rnpyk30CtfDibYie5llzuolwlL 3J/Fk1yj+cGWFL0thQ5XM8EdFcg6/MPkK5MwaJXtj9AtgQcW5E luBJP4fq8NDs+B81nLvVjRd5nQJ416GX5CTglDdFjQlOTa0Cyz ERrr/tOODZzPE4PrbIRdDam9x/ErrkDiPwGPuqs5SWOKsXtwYf leBhn4TyOn4fp7DgBHJtzAVYe2EkXcEJ3+U0W2zcGfOE1ZZ2um nk0iQ8ZV6A2lwQAqZKa0M6NgVc+RnLrF+OaHzul9awtYtkpNvY u32VUxKFainsKU3nqg8+dMwewLT3os2HvHfQgQFA/yUdYwh5ap rT/l5wfVnlRUQ== Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 16 Jul 2013 09:50:55 -0000 Hi Yoshi, > I would note that the two PANA approaches (side-by-side and = encapsulation) may have difference in supporting PCP proxy. In the = side-by-side approach (draft-ohba-pcp-pana), PANA relay would need to be = implemented on PCP proxy to communicate client's IP address to the = server since PCP THIRD_PARTY option is carried only in PCP message. In = the encapsulation approach (draft-ohba-pcp-pana-encap), PANA relay would = not be needed since PCP THIRD_PARTY option can be carried in a PCP = message that encapsulates a PANA message. >=20 > Since PANA relay is simple stateless relay, it should not be a problem = with the side-by-side approach as long as THIRD_PARTY option is the only = PCP option inserted by PCP proxy. However, if PCP proxy inserts other = PCP options as well, then I think the encapsulation approach can be = better than the side-by-side approach. >=20 I didn't understand why PCP proxy having to insert any PCP options have = any impact on the out-of band authentication performed by PANA. Alper > Regards, > Yoshihiro Ohba >=20 >=20 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Tirumaleswar Reddy (tireddy) > Sent: Tuesday, July 16, 2013 2:51 PM > To: Dave Thaler; pcp@ietf.org > Subject: Re: [pcp] CONSENSUS CALL on PCP security >=20 > Hi Dave, >=20 > In the poll when you refer to PANA, please clarify the draft you are = referring to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or = http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >=20 > --Tiru. >=20 >> -----Original Message----- >> From: Dave Thaler [mailto:dthaler@microsoft.com] >> Sent: Monday, July 15, 2013 6:03 AM >> To: pcp@ietf.org >> Subject: [pcp] CONSENSUS CALL on PCP security >>=20 >> The WG has discussed two approaches for using EAP with PCP: >> direct EAP-in-PCP vs using PANA. >>=20 >> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP=20= >> and 10 or 11 for PANA. There was significant confusion/disagreement=20= >> around requirements and proposed solutions at that time. >>=20 >> At IETF 85, we again polled the room and got a different result, this=20= >> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was,=20 >> however, still significant confusion/disagreement around requirements=20= >> and proposed solutions. >>=20 >> Since IETF 85, we have made lots of progress on getting agreement on=20= >> the requirements, and draft-reddy-pcp-auth-req now seems to be=20 >> relatively stable without significant areas of disagreement known. >> Discussion may of course continue if new issues are raised but we=20 >> believe any additional changes are unlikely to affect people's=20 >> position on overall solution approach, i.e. direct EAP-in-PCP vs. = PANA. >>=20 >> The general sense of the WG also seems to be that either approach=20 >> could be made to fit the requirements, so we believe it is now time=20= >> for us to determine consensus (draft-resnick-on-consensus is a great=20= >> read) on the approach question. We know many folks would just like to=20= >> make a decision and move on. >>=20 >> Hence the chairs would like to ask the WG which solution direction = the=20 >> WG should pursue in meeting the requirements. Please state your=20 >> recommendation on this thread, preferably along with your rationale. >> Avoid responding on this thread to others' rationale, use a separate=20= >> thread as needed. >>=20 >> To help us judge consensus, please use the template below and respond=20= >> by SUNDAY JULY 28. >>=20 >> -Dave and Reinaldo >>=20 >> --- >>=20 >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>=20 >> >>=20 >> 2) Could you *live with* PANA? If not, state reason you would object. >>=20 >> >>=20 >> 3) If you said yes to both 1 and 2, but have a strong preference=20 >> between the two, which approach do you prefer and why? >>=20 >> . >>=20 >=20 > _______________________________________________ > 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 trac@tools.ietf.org Tue Jul 16 05:34:18 2013 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 D01E421F842A for ; Tue, 16 Jul 2013 05:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfFFj7Y7VRQ1 for ; Tue, 16 Jul 2013 05:34:18 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 215D011E8195 for ; Tue, 16 Jul 2013 05:34:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:48945 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uz4SP-0007FK-2Z; Tue, 16 Jul 2013 14:34:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: pcp Date: Tue, 16 Jul 2013 12:34:16 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/64#comment:1 Message-ID: <079.ac76ba53ca62aed2ab1e0278a617d740@tools.ietf.org> References: <064.8793b93d389eea6b51bc55b5712fe096@tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <064.8793b93d389eea6b51bc55b5712fe096@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, mohamed.boucadair@orange.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mohamed.boucadair@orange.com Resent-Message-Id: <20130716123418.215D011E8195@ietfa.amsl.com> Resent-Date: Tue, 16 Jul 2013 05:34:18 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-02 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 12:34:18 -0000 #64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-02 Changes (by mohamed.boucadair@orange.com): * status: new => closed * resolution: => fixed Comment: http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-03 fixes all the comments raised by Teemu. In particular: * draft-ietf-behave-nat64-discovery-heuristic and learn-analysis I-D are referenced * suffix can be configured * the option solves the problem defined in "5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes" of draft-ietf-behave-nat64-discovery-heuristic -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-pcp- teemu.savolainen@nokia.com | nat64-prefix64@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nat64-prefix64 | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: pcp From yoshihiro.ohba@toshiba.co.jp Tue Jul 16 06:33:09 2013 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 39FD711E80F6 for ; Tue, 16 Jul 2013 06:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.422 X-Spam-Level: X-Spam-Status: No, score=-7.422 tagged_above=-999 required=5 tests=[AWL=0.667, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rpzbjv4EMcd for ; Tue, 16 Jul 2013 06:33:03 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5E95411E80E6 for ; Tue, 16 Jul 2013 06:33:03 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r6GDWwhW016977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 22:32:58 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6GDWvYv007023; Tue, 16 Jul 2013 22:32:57 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 859; Tue, 16 Jul 2013 22:32:57 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6GDWvGZ007009; Tue, 16 Jul 2013 22:32:57 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r6GDWvLg006259; Tue, 16 Jul 2013 22:32:57 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA06258; Tue, 16 Jul 2013 22:32:57 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r6GDWvX0025635; Tue, 16 Jul 2013 22:32:57 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r6GDWvZm003593; Tue, 16 Jul 2013 22:32:57 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.194]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 22:32:57 +0900 From: To: Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAAqkRqAABmN41D//3Z+AP//LQXw Date: Tue, 16 Jul 2013 13:32:56 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D2FBB1@tgxml338.toshiba.local> References: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D2FA81@tgxml338.toshiba.local> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.30] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 16 Jul 2013 13:33:09 -0000 Hi Alper, -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 Sent: Tuesday, July 16, 2013 6:51 PM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ) Cc: tireddy@cisco.com; dthaler@microsoft.com; pcp@ietf.org Subject: Re: [pcp] CONSENSUS CALL on PCP security Hi Yoshi, > I would note that the two PANA approaches (side-by-side and encapsulation= ) may have difference in supporting PCP proxy. In the side-by-side approac= h (draft-ohba-pcp-pana), PANA relay would need to be implemented on PCP pro= xy to communicate client's IP address to the server since PCP THIRD_PARTY o= ption is carried only in PCP message. In the encapsulation approach (draft= -ohba-pcp-pana-encap), PANA relay would not be needed since PCP THIRD_PARTY= option can be carried in a PCP message that encapsulates a PANA message. >=20 > Since PANA relay is simple stateless relay, it should not be a problem wi= th the side-by-side approach as long as THIRD_PARTY option is the only PCP = option inserted by PCP proxy. However, if PCP proxy inserts other PCP opti= ons as well, then I think the encapsulation approach can be better than the= side-by-side approach. >=20 I didn't understand why PCP proxy having to insert any PCP options have any= impact on the out-of band authentication performed by PANA. [YO] I meant any PCP options that affect PCP authentication behavior, in wh= ich case PANA relay in the side-by-side approach would have to insert equiv= alent PANA attributes which may not exist now.=20 Regards, Yoshihiro Ohba Alper > Regards, > Yoshihiro Ohba >=20 >=20 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of=20 > Tirumaleswar Reddy (tireddy) > Sent: Tuesday, July 16, 2013 2:51 PM > To: Dave Thaler; pcp@ietf.org > Subject: Re: [pcp] CONSENSUS CALL on PCP security >=20 > Hi Dave, >=20 > In the poll when you refer to PANA, please clarify the draft you are refe= rring to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.= ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >=20 > --Tiru. >=20 >> -----Original Message----- >> From: Dave Thaler [mailto:dthaler@microsoft.com] >> Sent: Monday, July 15, 2013 6:03 AM >> To: pcp@ietf.org >> Subject: [pcp] CONSENSUS CALL on PCP security >>=20 >> The WG has discussed two approaches for using EAP with PCP: >> direct EAP-in-PCP vs using PANA. >>=20 >> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP=20 >> and 10 or 11 for PANA. There was significant confusion/disagreement=20 >> around requirements and proposed solutions at that time. >>=20 >> At IETF 85, we again polled the room and got a different result, this=20 >> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was,=20 >> however, still significant confusion/disagreement around requirements=20 >> and proposed solutions. >>=20 >> Since IETF 85, we have made lots of progress on getting agreement on=20 >> the requirements, and draft-reddy-pcp-auth-req now seems to be=20 >> relatively stable without significant areas of disagreement known. >> Discussion may of course continue if new issues are raised but we=20 >> believe any additional changes are unlikely to affect people's=20 >> position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA. >>=20 >> The general sense of the WG also seems to be that either approach=20 >> could be made to fit the requirements, so we believe it is now time=20 >> for us to determine consensus (draft-resnick-on-consensus is a great >> read) on the approach question. We know many folks would just like to=20 >> make a decision and move on. >>=20 >> Hence the chairs would like to ask the WG which solution direction=20 >> the WG should pursue in meeting the requirements. Please state your=20 >> recommendation on this thread, preferably along with your rationale. >> Avoid responding on this thread to others' rationale, use a separate=20 >> thread as needed. >>=20 >> To help us judge consensus, please use the template below and respond=20 >> by SUNDAY JULY 28. >>=20 >> -Dave and Reinaldo >>=20 >> --- >>=20 >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would obje= ct. >>=20 >> >>=20 >> 2) Could you *live with* PANA? If not, state reason you would object. >>=20 >> >>=20 >> 3) If you said yes to both 1 and 2, but have a strong preference=20 >> between the two, which approach do you prefer and why? >>=20 >> . >>=20 >=20 > _______________________________________________ > 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 Tue Jul 16 09:44:41 2013 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 DE03A11E80FB for ; Tue, 16 Jul 2013 09:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNNOCFhWXe6f for ; Tue, 16 Jul 2013 09:44:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2148011E80E9 for ; Tue, 16 Jul 2013 09:44:37 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LaXZ9-1UIc8D1rvL-00mOUJ; Tue, 16 Jul 2013 12:44:32 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-2022-jp From: Alper Yegin In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D2FBB1@tgxml338.toshiba.local> Date: Tue, 16 Jul 2013 19:44:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9AF475F0-EC96-4BA4-A247-746F8CC1E2E4@yegin.org> References: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D2FA81@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D2FBB1@tgxml338.toshiba.local> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:BaavH1eFBJI/YbvWYL5Cdy4Sr0f8ZU2Iu2sVmg6Glxo rw58y6w/ZF4dGO3NQzxRID4nbYaEZmg3fw5ZS3si22fylbq6cm Qn0dK2EuCUtTJ0XcDKoUU2Mk5+iJtQT+9a9zWvyNZgOSKg1djG kkD8YB9Ri7vn++VIYJdOogjtTF3YONHAfTq5WRSycAPyW4jIYq 0T21g6HECgPA3ClwySnTbE+nqU6HWyTcwgpUqb1LbbJK+4T/tH U2kBBiZdtbnRmqsQcCRmb1DoWfIVq5p70NeDGU5nO3MgoMM8rD uPkF2Utqa02qXkX7e2q/IubUmcMQRxyRS1S02XpG1TuI6tLko7 xNIDo1VZ4w0LG6IMATtJuNY+ZdgxOQ+M5ZDdl9pMwVR0HJvCkd nEEiktMHMB6FQ== Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 16 Jul 2013 16:44:42 -0000 Hi Yoshi, >=20 >> I would note that the two PANA approaches (side-by-side and = encapsulation) may have difference in supporting PCP proxy. In the = side-by-side approach (draft-ohba-pcp-pana), PANA relay would need to be = implemented on PCP proxy to communicate client's IP address to the = server since PCP THIRD_PARTY option is carried only in PCP message. In = the encapsulation approach (draft-ohba-pcp-pana-encap), PANA relay would = not be needed since PCP THIRD_PARTY option can be carried in a PCP = message that encapsulates a PANA message. >>=20 >> Since PANA relay is simple stateless relay, it should not be a = problem with the side-by-side approach as long as THIRD_PARTY option is = the only PCP option inserted by PCP proxy. However, if PCP proxy = inserts other PCP options as well, then I think the encapsulation = approach can be better than the side-by-side approach. >>=20 >=20 > I didn't understand why PCP proxy having to insert any PCP options = have any impact on the out-of band authentication performed by PANA. >=20 > [YO] I meant any PCP options that affect PCP authentication behavior, = in which case PANA relay in the side-by-side approach would have to = insert equivalent PANA attributes which may not exist now.=20 >=20 I'm trying to imagine what such PCP options would be?=20 Alper > Regards, > Yoshihiro Ohba >=20 >=20 > Alper >=20 >=20 >=20 >> Regards, >> Yoshihiro Ohba >>=20 >>=20 >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of=20= >> Tirumaleswar Reddy (tireddy) >> Sent: Tuesday, July 16, 2013 2:51 PM >> To: Dave Thaler; pcp@ietf.org >> Subject: Re: [pcp] CONSENSUS CALL on PCP security >>=20 >> Hi Dave, >>=20 >> In the poll when you refer to PANA, please clarify the draft you are = referring to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or = http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >>=20 >> --Tiru. >>=20 >>> -----Original Message----- >>> From: Dave Thaler [mailto:dthaler@microsoft.com] >>> Sent: Monday, July 15, 2013 6:03 AM >>> To: pcp@ietf.org >>> Subject: [pcp] CONSENSUS CALL on PCP security >>>=20 >>> The WG has discussed two approaches for using EAP with PCP: >>> direct EAP-in-PCP vs using PANA. >>>=20 >>> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP=20= >>> and 10 or 11 for PANA. There was significant confusion/disagreement=20= >>> around requirements and proposed solutions at that time. >>>=20 >>> At IETF 85, we again polled the room and got a different result, = this=20 >>> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was,=20 >>> however, still significant confusion/disagreement around = requirements=20 >>> and proposed solutions. >>>=20 >>> Since IETF 85, we have made lots of progress on getting agreement on=20= >>> the requirements, and draft-reddy-pcp-auth-req now seems to be=20 >>> relatively stable without significant areas of disagreement known. >>> Discussion may of course continue if new issues are raised but we=20 >>> believe any additional changes are unlikely to affect people's=20 >>> position on overall solution approach, i.e. direct EAP-in-PCP vs. = PANA. >>>=20 >>> The general sense of the WG also seems to be that either approach=20 >>> could be made to fit the requirements, so we believe it is now time=20= >>> for us to determine consensus (draft-resnick-on-consensus is a great >>> read) on the approach question. We know many folks would just like = to=20 >>> make a decision and move on. >>>=20 >>> Hence the chairs would like to ask the WG which solution direction=20= >>> the WG should pursue in meeting the requirements. Please state your=20= >>> recommendation on this thread, preferably along with your rationale. >>> Avoid responding on this thread to others' rationale, use a separate=20= >>> thread as needed. >>>=20 >>> To help us judge consensus, please use the template below and = respond=20 >>> by SUNDAY JULY 28. >>>=20 >>> -Dave and Reinaldo >>>=20 >>> --- >>>=20 >>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>>=20 >>> >>>=20 >>> 2) Could you *live with* PANA? If not, state reason you would = object. >>>=20 >>> >>>=20 >>> 3) If you said yes to both 1 and 2, but have a strong preference=20 >>> between the two, which approach do you prefer and why? >>>=20 >>> . >>>=20 >>=20 >> _______________________________________________ >> 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 >=20 From dthaler@microsoft.com Tue Jul 16 09:52:51 2013 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 6B66821F964C for ; Tue, 16 Jul 2013 09:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.386 X-Spam-Level: X-Spam-Status: No, score=-100.386 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9o7Yo220uWH for ; Tue, 16 Jul 2013 09:52:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 87D9B21F8F4A for ; Tue, 16 Jul 2013 09:52:45 -0700 (PDT) Received: from BN1AFFO11FD009.protection.gbl (10.58.52.202) by BN1AFFO11HUB041.protection.gbl (10.58.52.152) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 16 Jul 2013 16:52:44 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD009.mail.protection.outlook.com (10.58.52.69) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 16 Jul 2013 16:52:44 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 16 Jul 2013 16:52:32 +0000 Received: from mail46-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.22; Tue, 16 Jul 2013 16:51:02 +0000 Received: from mail46-ch1 (localhost [127.0.0.1]) by mail46-ch1-R.bigfish.com (Postfix) with ESMTP id 7CF266010C for ; Tue, 16 Jul 2013 16:51:02 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(z551biz9371I1454I542I1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail46-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(51704005)(377454003)(52044002)(54316002)(56776001)(31966008)(74502001)(47446002)(80022001)(56816003)(33646001)(74316001)(16406001)(15202345003)(51856001)(74706001)(76482001)(76786001)(76796001)(76576001)(4396001)(77096001)(74876001)(63696002)(81342001)(74662001)(83072001)(69226001)(47736001)(53806001)(49866001)(50986001)(47976001)(54356001)(46102001)(59766001)(77982001)(65816001)(66066001)(74366001)(79102001)(81542001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:50.135.4.20; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail46-ch1 (localhost.localdomain [127.0.0.1]) by mail46-ch1 (MessageSwitch) id 137399346036681_12298; Tue, 16 Jul 2013 16:51:00 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail46-ch1.bigfish.com (Postfix) with ESMTP id EED784E0047; Tue, 16 Jul 2013 16:50:59 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 16 Jul 2013 16:50:58 +0000 Received: from BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.329.3; Tue, 16 Jul 2013 16:50:58 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.731.11; Tue, 16 Jul 2013 16:50:55 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.140]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.140]) with mapi id 15.00.0731.000; Tue, 16 Jul 2013 16:50:55 +0000 From: Dave Thaler To: "Tirumaleswar Reddy (tireddy)" , "pcp@ietf.org" Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAA9bRSAABbz96A= Date: Tue, 16 Jul 2013 16:50:54 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 09090B6B69 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB271.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(199002)(189002)(51704005)(52044002)(377454003)(49866001)(4396001)(47776003)(31966008)(46406003)(23726002)(63696002)(83072001)(69226001)(20776003)(74316001)(80022001)(6806004)(76576001)(51856001)(47736001)(59766001)(81342001)(74876001)(46102001)(44976005)(76482001)(16676001)(66066001)(81542001)(65816001)(50466002)(77982001)(47446002)(74706001)(56776001)(53806001)(50986001)(76786001)(74366001)(76796001)(79102001)(77096001)(54356001)(56816003)(74502001)(33646001)(47976001)(74662001)(54316002)(15202345003)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB041; H:TK5EX14HUBC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 09090B6B69 Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 16 Jul 2013 16:52:51 -0000 > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Sent: Monday, July 15, 2013 10:51 PM > To: Dave Thaler; pcp@ietf.org > Subject: RE: [pcp] CONSENSUS CALL on PCP security >=20 > Hi Dave, >=20 > In the poll when you refer to PANA, please clarify the draft you are refe= rring > to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or > http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >=20 > --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could=20 ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave =20 From dthaler@microsoft.com Tue Jul 16 09:54:53 2013 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 DFD6321F90FD for ; Tue, 16 Jul 2013 09:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.394 X-Spam-Level: X-Spam-Status: No, score=-99.394 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO4xdHF5HhOA for ; Tue, 16 Jul 2013 09:54:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id C8D2B21F9926 for ; Tue, 16 Jul 2013 09:54:46 -0700 (PDT) Received: from BL2FFO11FD007.protection.gbl (10.173.161.202) by BL2FFO11HUB048.protection.gbl (10.173.161.124) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 16 Jul 2013 16:54:45 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 16 Jul 2013 16:54:45 +0000 Received: from CO9EHSOBE034.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 16 Jul 2013 16:54:30 +0000 Received: from mail30-co9-R.bigfish.com (10.236.132.241) by CO9EHSOBE034.bigfish.com (10.236.130.97) with Microsoft SMTP Server id 14.1.225.22; Tue, 16 Jul 2013 16:53:52 +0000 Received: from mail30-co9 (localhost [127.0.0.1]) by mail30-co9-R.bigfish.com (Postfix) with ESMTP id 02277E0201 for ; Tue, 16 Jul 2013 16:53:52 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(z569dhz9371I542I1432I4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail30-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT004.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(13464003)(377454003)(51704005)(164054003)(199002)(33646001)(54316002)(56776001)(74706001)(31966008)(63696002)(66066001)(74662001)(81542001)(47446002)(54356001)(50986001)(77096001)(83072001)(74876001)(53806001)(80022001)(74316001)(4396001)(59766001)(49866001)(51856001)(76576001)(221733001)(74502001)(79102001)(74366001)(76796001)(76176001)(65816001)(69226001)(81342001)(15202345003)(47976001)(76786001)(47736001)(76482001)(16406001)(77982001)(46102001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:50.135.4.20; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail30-co9 (localhost.localdomain [127.0.0.1]) by mail30-co9 (MessageSwitch) id 1373993629683408_10220; Tue, 16 Jul 2013 16:53:49 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.235]) by mail30-co9.bigfish.com (Postfix) with ESMTP id 999304000CE; Tue, 16 Jul 2013 16:53:49 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Jul 2013 16:53:46 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.329.3; Tue, 16 Jul 2013 16:53:45 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.731.11; Tue, 16 Jul 2013 16:53:37 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.140]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.140]) with mapi id 15.00.0731.000; Tue, 16 Jul 2013 16:53:37 +0000 From: Dave Thaler To: Alper Yegin , "yoshihiro.ohba@toshiba.co.jp" Thread-Topic: PANA relay Thread-Index: Ac6CRLf1c4L4pzmrRumF/0rg48llLQ== Date: Tue, 16 Jul 2013 16:53:36 +0000 Message-ID: <8afeaa88ff3647a786ef4f80200ee753@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 09090B6B69 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB269.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%YEGIN.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOSHIBA.CO.JP$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454003)(13464003)(199002)(164054003)(189002)(51704005)(74706001)(76482001)(56776001)(59766001)(15202345003)(44976005)(69226001)(77982001)(77096001)(76786001)(50466002)(46102001)(74502001)(53806001)(54356001)(47446002)(76576001)(51856001)(47736001)(83072001)(76176001)(74662001)(74316001)(31966008)(47976001)(74876001)(79102001)(76796001)(74366001)(49866001)(56816003)(16676001)(81342001)(20776003)(50986001)(23726002)(81542001)(4396001)(6806004)(47776003)(33646001)(80022001)(54316002)(221733001)(46406003)(65816001)(66066001)(63696002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB048; H:TK5EX14HUBC101.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 09090B6B69 Cc: "pcp@ietf.org" , "tireddy@cisco.com" Subject: [pcp] PANA relay 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, 16 Jul 2013 16:54:53 -0000 To repeat something we said in the consensus call: > >>> Avoid responding on this thread to others' rationale, use a separate > >>> thread as needed. Hence changing subject line. Thanks, -Dave > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Tuesday, July 16, 2013 9:44 AM > To: yoshihiro.ohba@toshiba.co.jp > Cc: tireddy@cisco.com; Dave Thaler; pcp@ietf.org > Subject: Re: [pcp] CONSENSUS CALL on PCP security >=20 > Hi Yoshi, >=20 > > > >> I would note that the two PANA approaches (side-by-side and > encapsulation) may have difference in supporting PCP proxy. In the side-= by- > side approach (draft-ohba-pcp-pana), PANA relay would need to be > implemented on PCP proxy to communicate client's IP address to the server > since PCP THIRD_PARTY option is carried only in PCP message. In the > encapsulation approach (draft-ohba-pcp-pana-encap), PANA relay would not > be needed since PCP THIRD_PARTY option can be carried in a PCP message > that encapsulates a PANA message. > >> > >> Since PANA relay is simple stateless relay, it should not be a problem= with > the side-by-side approach as long as THIRD_PARTY option is the only PCP > option inserted by PCP proxy. However, if PCP proxy inserts other PCP > options as well, then I think the encapsulation approach can be better th= an > the side-by-side approach. > >> > > > > I didn't understand why PCP proxy having to insert any PCP options have > any impact on the out-of band authentication performed by PANA. > > > > [YO] I meant any PCP options that affect PCP authentication behavior, i= n > which case PANA relay in the side-by-side approach would have to insert > equivalent PANA attributes which may not exist now. > > >=20 > I'm trying to imagine what such PCP options would be? >=20 > Alper >=20 >=20 >=20 >=20 > > Regards, > > Yoshihiro Ohba > > > > > > Alper > > > > > > > >> Regards, > >> Yoshihiro Ohba > >> > >> > >> -----Original Message----- > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > >> Tirumaleswar Reddy (tireddy) > >> Sent: Tuesday, July 16, 2013 2:51 PM > >> To: Dave Thaler; pcp@ietf.org > >> Subject: Re: [pcp] CONSENSUS CALL on PCP security > >> > >> Hi Dave, > >> > >> In the poll when you refer to PANA, please clarify the draft you are > referring to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or > http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? > >> > >> --Tiru. > >> > >>> -----Original Message----- > >>> From: Dave Thaler [mailto:dthaler@microsoft.com] > >>> Sent: Monday, July 15, 2013 6:03 AM > >>> To: pcp@ietf.org > >>> Subject: [pcp] CONSENSUS CALL on PCP security > >>> > >>> The WG has discussed two approaches for using EAP with PCP: > >>> direct EAP-in-PCP vs using PANA. > >>> > >>> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP > >>> and 10 or 11 for PANA. There was significant confusion/disagreement > >>> around requirements and proposed solutions at that time. > >>> > >>> At IETF 85, we again polled the room and got a different result, > >>> this time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, > >>> however, still significant confusion/disagreement around > >>> requirements and proposed solutions. > >>> > >>> Since IETF 85, we have made lots of progress on getting agreement on > >>> the requirements, and draft-reddy-pcp-auth-req now seems to be > >>> relatively stable without significant areas of disagreement known. > >>> Discussion may of course continue if new issues are raised but we > >>> believe any additional changes are unlikely to affect people's > >>> position on overall solution approach, i.e. direct EAP-in-PCP vs. PAN= A. > >>> > >>> The general sense of the WG also seems to be that either approach > >>> could be made to fit the requirements, so we believe it is now time > >>> for us to determine consensus (draft-resnick-on-consensus is a great > >>> read) on the approach question. We know many folks would just like > >>> to make a decision and move on. > >>> > >>> Hence the chairs would like to ask the WG which solution direction > >>> the WG should pursue in meeting the requirements. Please state your > >>> recommendation on this thread, preferably along with your rationale. > >>> Avoid responding on this thread to others' rationale, use a separate > >>> thread as needed. > >>> > >>> To help us judge consensus, please use the template below and > >>> respond by SUNDAY JULY 28. > >>> > >>> -Dave and Reinaldo > >>> > >>> --- > >>> > >>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would > object. > >>> > >>> > >>> > >>> 2) Could you *live with* PANA? If not, state reason you would object. > >>> > >>> > >>> > >>> 3) If you said yes to both 1 and 2, but have a strong preference > >>> between the two, which approach do you prefer and why? > >>> > >>> . > >>> > >> > >> _______________________________________________ > >> 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 >=20 From tireddy@cisco.com Tue Jul 16 10:11:15 2013 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 11A4F21F9A94 for ; Tue, 16 Jul 2013 10:11:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lmhnc5qMa0Vv for ; Tue, 16 Jul 2013 10:11:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 92F6221F991E for ; Tue, 16 Jul 2013 10:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1277; q=dns/txt; s=iport; t=1373994669; x=1375204269; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m899C1HBGYZ1AQcoH+CLMrhc5lDMabfNNsuQve5dDIg=; b=Coff+PSbb9cqzCAaJJywwAM+xrq5p4LMNrEieb6PQ7MZN+MFGsiynPb9 kiooAAhu6MkeCdeKUdlHSWJhqv8ADmV2U4hm9K6czhDmMiC0MwFszLTu5 9p89BBXiAewOtOhBF8hFIovNwZCI6mAZKX6GIbdzHkS3WyFaaCzGpYu4J U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAEF+5VGtJV2c/2dsb2JhbABagwY0T8FugRAWdIIjAQEBAwE6RAcEAgEIDgMEAQELFAkHMhQJCAIEARIIiAIGDLV5jy44BoMGbQOZBZAkgxKCKA X-IronPort-AV: E=Sophos;i="4.89,678,1367971200"; d="scan'208";a="235609385" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2013 17:11:07 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6GHB73U031363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 17:11:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 12:11:07 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Dave Thaler , "pcp@ietf.org" Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: AQHOgYO2/UME/BL9NUa9YVGvlLydx5lmzBxwgAEN8wD//7GFAA== Date: Tue, 16 Jul 2013 17:11:06 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9B329@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 16 Jul 2013 17:11:15 -0000 > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Tuesday, July 16, 2013 10:21 PM > To: Tirumaleswar Reddy (tireddy); pcp@ietf.org > Subject: RE: [pcp] CONSENSUS CALL on PCP security >=20 > > -----Original Message----- > > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > > Sent: Monday, July 15, 2013 10:51 PM > > To: Dave Thaler; pcp@ietf.org > > Subject: RE: [pcp] CONSENSUS CALL on PCP security > > > > Hi Dave, > > > > In the poll when you refer to PANA, please clarify the draft you are > referring > > to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or > > http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? > > > > --Tiru. >=20 > The question is intentionally agnostic as this is about a general approac= h, > not which specific implementation. =20 Thanks that clarifies my doubt. --Tiru. > If it helps, you can interpret the > answer as "which of the two you think is better". >=20 > If the consensus is PANA rather than direct EAP-in-PCP, then we could > ask as a follow-up question which of the two we should go with. If > you'd like to include your answer to that now though, feel free to > include that in your response to the call. >=20 > -Dave >=20 >=20 From alper.yegin@yegin.org Tue Jul 16 13:01:23 2013 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 A130A21F9DCF for ; Tue, 16 Jul 2013 13:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMN4JQzP9ssx for ; Tue, 16 Jul 2013 13:01:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9512221F9D66 for ; Tue, 16 Jul 2013 13:01:18 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M4nkT-1UDZ6508yr-00zMrz; Tue, 16 Jul 2013 16:01:09 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Tue, 16 Jul 2013 23:01:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1A7721F2-825C-412C-A0A8-A7D0A149E3FC@yegin.org> References: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> To: Dave Thaler X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:PhmWdz3SYRL4aFLJ7/KBg8t3SGjJqwZe+BAieFToYPH 9MYptuLmAfxH1DZYCIT/UQTR2HDF5rxm+lSe58e9PDIVrIUT0f yeBn3YB+AGMcHUK9WN8WIPdVS9mOTd3KNh1pzwdW7FBRVp12cI yGjfsiJtqw7Lt37a38GtF4Qq+W2A+gf21XoeJjl+Gb4FIgEhyQ T9x6vhiAYC9L+UNNrIbKR4HSB4Bnpkls4NRY4hhom8D1t7DaFm prUBOjhen/sUs7z2f+0j6WZXKr85gyQIoqhE1hAy5jobw8jGZp sLmXZ0DyFh1Uig9nVJhMb0G0bvkMOl55KZ6Q56SCCMAq2dYQLm jxUzpwKe4mVw2DwUUAilxdfPzf8MQUxgI7gpe7SaIkfjeKJgJN 6QUhWqoRbdL1g== Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 16 Jul 2013 20:01:23 -0000 Dave, Last time we conducted this polling, the two pana-based solutions were = asked separately. Based on the discussions and the result of the poll, I realized some = people preferred one PANA solution over the other, with possibly varying = preference with respect to the EAP-o-PCP solution. Bundling them up as one option is not a good idea. So, I suggest we pose them as separate questions (like we did last = time). After all, they are technically different. One other thing:=20 I'm not sure if enough thought went into the PCP Proxy security. As much = as I'd love to be DONE! with this discussion, I also want to make sure = people feel comfortable having thought all aspects around the proxy use. = For (very important) example, what kind of security associations are = needed for securing the proxy use: An SA btw client and server, an SA = btw client and proxy, an SA btw proxy and server -- which combinations = of these are needed? Then we need to talk about how we dynamically = create those using any one of these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: >> -----Original Message----- >> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >> Sent: Monday, July 15, 2013 10:51 PM >> To: Dave Thaler; pcp@ietf.org >> Subject: RE: [pcp] CONSENSUS CALL on PCP security >>=20 >> Hi Dave, >>=20 >> In the poll when you refer to PANA, please clarify the draft you are = referring >> to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or >> http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >>=20 >> --Tiru. >=20 > The question is intentionally agnostic as this is about a general = approach, > not which specific implementation. If it helps, you can interpret the > answer as "which of the two you think is better". >=20 > If the consensus is PANA rather than direct EAP-in-PCP, then we could=20= > ask as a follow-up question which of the two we should go with. If > you'd like to include your answer to that now though, feel free to > include that in your response to the call. >=20 > -Dave >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From praspati@cisco.com Tue Jul 16 19:21:09 2013 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 36FC521F9C13 for ; Tue, 16 Jul 2013 19:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH6fFDXIf7wO for ; Tue, 16 Jul 2013 19:21:02 -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 EBB7621F9BAD for ; Tue, 16 Jul 2013 19:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10496; q=dns/txt; s=iport; t=1374027662; x=1375237262; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=5Xza8lmSmEBUjXfXTY2rhI+T/C0dbXl4G+Nd54vcnqE=; b=kdDoeAcHrxryPQhqDH/kWMQ21szY4pj7ihknR9v3+X287hT7MnWen1UO bGCrs00VpRDj78DHsfUzwomsorIUdSG5vuPEZ9+oU2LiYZarAnGDTbPgo hQMRpi2FRQ2x7XX+v9l0Vq41YjO+ANObOU+JuwMKC1PSTlI25UxUEhZbh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAPz95VGtJXG9/2dsb2JhbABagkJENE+EJIFDs3+IPYENFnSCIwEBAQQBAQFrCwwGAQgRBAEBCx0uCxQJCAIEAQ0FCBOHdQy1S489LQQHBoMGbgOBTZc4kCSBNYFdgWokGg X-IronPort-AV: E=Sophos;i="4.89,681,1367971200"; d="scan'208,217";a="235749999" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jul 2013 02:21:01 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6H2L1ED019153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 02:21:01 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 21:21:00 -0500 From: "Prashanth Patil (praspati)" To: Alper Yegin , Dave Thaler Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: AQHOgpRH/UME/BL9NUa9YVGvlLydxw== Date: Wed, 17 Jul 2013 02:21:00 +0000 Message-ID: In-Reply-To: <1A7721F2-825C-412C-A0A8-A7D0A149E3FC@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.65.70.75] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE320B6xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 17 Jul 2013 02:21:09 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE320B6xmbrcdx07ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alper, On 17/07/13 1:31 AM, "Alper Yegin" > wrote: Dave, Last time we conducted this polling, the two pana-based solutions were aske= d separately. Based on the discussions and the result of the poll, I realized some people= preferred one PANA solution over the other, with possibly varying preferen= ce with respect to the EAP-o-PCP solution. Bundling them up as one option is not a good idea. So, I suggest we pose them as separate questions (like we did last time). A= fter all, they are technically different. One other thing: I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_B235506D63D65E43B2E40FD27715372E1CE320B6xmbrcdx07ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Alper,

On 17/07/13 1:31 AM, "Alper Yegin&quo= t; <alper.yegin@yegin.org&g= t; wrote:

Dave,

Last time we conducted this polling, the two pana-based solutions were= asked separately.
Based on the discussions and the result of the poll, I realized some p= eople preferred one PANA solution over the other, with possibly varying pre= ference with respect to the EAP-o-PCP solution.
Bundling them up as one option is not a good idea.
So, I suggest we pose them as separate questions (like we did last tim= e). After all, they are technically different.

One other thing:

I'm not sure if enough thought went into the PCP Proxy security. As mu= ch as I'd love to be DONE! with this discussion, I also want to make sure p= eople feel comfortable having thought all aspects around the proxy use. For= (very important) example, what kind of security associations are needed for securing the proxy use: An SA= btw client and server, an SA btw client and proxy, an SA btw proxy and ser= ver -- which combinations of these are needed?

We've included this in the updated version of auth req:

REQ-9: A PCP proxy that modifies PCP me= ssages SHOULD have the
ability to independently authenticate w= ith the PCP client and PCP
server. The presence of a PCP proxy hen= ce requires two separately
authenticates SAs. As a consequence, th= e PCP proxy:

A. MUST be able to validate message int= egrity of PCP messages
from the PCP server and client respecti= vely.

B. MUST be able to ensure message integ= rity after updating the
PCP message for cases described in sect= ions 6 of ietf-pcp-proxy.

The PCP proxy MUST also permit authenti= cation on only one side of
the proxy. For example, a customer prem= ises host may not
authenticate with the PCP proxy but the= PCP proxy may authenticate
with the PCP server.

-Prashanth

Then we need to talk about how we dynamically create those using any o= ne of these solutions.

Alper





On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; pcp@ietf.org
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,
In the poll when you refer to PANA, please clarify the draft you are r= eferring
--Tiru.
The question is intentionally agnostic as this is about a general appr= oach,
not which specific implementation.  If it helps, you can int= erpret the
answer as "which of the two you think is better".
If the consensus is PANA rather than direct EAP-in-PCP, then we could =
ask as a follow-up question which of the two we should go with. If
you'd like to include your answer to that now though, feel free to
include that in your response to the call.
-Dave
_______________________________________________
pcp mailing list

_______________________________________________
pcp mailing list

--_000_B235506D63D65E43B2E40FD27715372E1CE320B6xmbrcdx07ciscoc_-- From tireddy@cisco.com Tue Jul 16 23:15:53 2013 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 15BA921F9AA3 for ; Tue, 16 Jul 2013 23:15: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lK-Jh8j0Twtg for ; Tue, 16 Jul 2013 23:15:47 -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 4454D21F9A8C for ; Tue, 16 Jul 2013 23:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2526; q=dns/txt; s=iport; t=1374041747; x=1375251347; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ye3p8j5Ai5Ga65A6oxlrtvrVQbYI/HVYGGJEmMx+h2M=; b=Bm5tepGLOEDj6jwHfD4Dxg7H4T0gv/1aamoZa7YzLm1ES38vDcOGZ0Ia qqFfzZUYW6hpKagAFqNwZQTV4blh8OpnMnJkk1KM876/kV05NT6RZfv8E nQT2aQbx3J0Gv72Hu8PxEyUTgGba6Z+s2wzJTuyAPAauVquABusiTu3d7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAHQ15lGtJV2a/2dsb2JhbABagwaBA8IygQ0WdIIjAQEBBIEFBAIBFgMEAQELHQcyFAkIAgQBEggTh3W1co89BjIGgwZuA4hvoDqDEoIo X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208";a="235773245" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2013 06:15:44 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6H6Fijw030553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 06:15:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 01:15:44 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Dave Thaler , "pcp@ietf.org" Thread-Topic: REQ-14 in PCP Authentication Requirements Thread-Index: AQHOgYO2dz+IlsSN4UWh+//hlms7JZlnUekQ Date: Wed, 17 Jul 2013 06:15:44 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9B7B8@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.63.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] REQ-14 in PCP Authentication Requirements 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, 17 Jul 2013 06:15:53 -0000 I have a clarification for both the drafts - how do EAP-in-PCP, PANA soluti= ons meet REQ-14 ? --Tiru. > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Monday, July 15, 2013 6:03 AM > To: pcp@ietf.org > Subject: [pcp] CONSENSUS CALL on PCP security >=20 > The WG has discussed two approaches for using EAP with PCP: > direct EAP-in-PCP vs using PANA. >=20 > At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP > and 10 or 11 for PANA. There was significant confusion/disagreement > around requirements and proposed solutions at that time. >=20 > At IETF 85, we again polled the room and got a different result, this > time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however, > still significant confusion/disagreement around requirements and > proposed solutions. >=20 > Since IETF 85, we have made lots of progress on getting agreement > on the requirements, and draft-reddy-pcp-auth-req now seems to be > relatively stable without significant areas of disagreement known. > Discussion may of course continue if new issues are raised but we > believe any additional changes are unlikely to affect people's > position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA. >=20 > The general sense of the WG also seems to be that either approach could b= e > made to fit the requirements, so we believe it is now time for us to > determine consensus (draft-resnick-on-consensus is a great read) > on the approach question. We know many folks would just like to > make a decision and move on. >=20 > Hence the chairs would like to ask the WG which solution direction the > WG should pursue in meeting the requirements. Please state your > recommendation on this thread, preferably along with your rationale. > Avoid responding on this thread to others' rationale, use a separate > thread as needed. >=20 > To help us judge consensus, please use the template below and > respond by SUNDAY JULY 28. >=20 > -Dave and Reinaldo >=20 > --- >=20 > 1) Could you *live with* EAP-in-PCP? If not, state reason you would objec= t. >=20 > =A0=A0=A0 >=20 > 2) Could you *live with* PANA? If not, state reason you would object. >=20 > =A0=A0=A0 >=20 > 3) If you said yes to both 1 and 2, but have a strong preference between > the two, which approach do you prefer and why? >=20 > =A0=A0=A0 .=A0 >=20 From alper.yegin@yegin.org Tue Jul 16 23:53:45 2013 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 78A4121F9A94 for ; Tue, 16 Jul 2013 23:53:45 -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.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rpwPWsz-C83 for ; Tue, 16 Jul 2013 23:53:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 83F3F21F9A51 for ; Tue, 16 Jul 2013 23:53:39 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M3htJ-1U920e1bkH-00rFFi; Wed, 17 Jul 2013 02:53:36 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_890CDDD8-754F-4CAF-BE1D-2668ED5DF9A7" From: Alper Yegin In-Reply-To: Date: Wed, 17 Jul 2013 09:53:32 +0300 Message-Id: <758747A2-EB6E-4581-BDE3-DD7798A77EDF@yegin.org> References: To: Prashanth Patil (praspati) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:Aog/ttqx9ICRNgpQKJNiywJvLjcd8BPWmXdt0KWD9IX rtkrWpKRjd/BdpuhbW+Ag7OuykmO8RZqMO9IpZJcIZfXDQBiD3 c3ppnPhKAN61gOESulvFtT1IG+svuaDjE8ileTrAtHqOhpqMSe Ndty+bk04JDQtQi3Ec5lkFCdHKTCGSUB+9qTcygZ3zgdwMYwqX aPTjl4wZa1exN89NdoQImYVe6F0PwwGdD1moevC2mhpPJ0dRYy DxbLEkItmMffS9ZDgo/MscO0/UB257lh2orDp5iXbe4wOpG6e4 uRN9axyjx2xXMkHYM1yUR4UiCdMW/ao39YsklsckMfHxYnORxC DQqTWy98sI/7rVlHmScJdH32KAmftvBrhSvu0UzlZpYy5uKx9b +EJkEYcyOt+Ew== Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 17 Jul 2013 06:53:45 -0000 --Apple-Mail=_890CDDD8-754F-4CAF-BE1D-2668ED5DF9A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Prashanth, >> I'm not sure if enough thought went into the PCP Proxy security. As = much as I'd love to be DONE! with this discussion, I also want to make = sure people feel comfortable having thought all aspects around the proxy = use. For (very important) example, what kind of security associations = are needed for securing the proxy use: An SA btw client and server, an = SA btw client and proxy, an SA btw proxy and server -- which = combinations of these are needed? >=20 > We've included this in the updated version of auth req: >=20 > REQ-9: A PCP proxy that modifies PCP messages SHOULD have the > ability to independently authenticate with the PCP client and PCP > server. The presence of a PCP proxy hence requires two separately > authenticates SAs. As a consequence, the PCP proxy: >=20 > A. MUST be able to validate message integrity of PCP messages > from the PCP server and client respectively. >=20 > B. MUST be able to ensure message integrity after updating the > PCP message for cases described in sections 6 of ietf-pcp-proxy. >=20 > The PCP proxy MUST also permit authentication on only one side of > the proxy. For example, a customer premises host may not > authenticate with the PCP proxy but the PCP proxy may authenticate > with the PCP server. >=20 So: - We have two types of SAs. One between the client and the proxy, = another between the proxy and the server. - None of them are mandatory to use. For each one that needs to be used, we need to perform authentication = between the end-points.=20 (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; = client to proxy, and proxy to server.=20 They are totally segregated from security perspective.=20 Right? Hmm, one thing: The server may need to know the authenticated ID of the = client. Since it's not part of the client authentication, it won't know = that value readily. So, we may need to define an option to carry that = piece of information from the proxy to the server. Alper > -Prashanth >=20 >> Then we need to talk about how we dynamically create those using any = one of these solutions. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: >>=20 >>>> -----Original Message----- >>>> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >>>> Sent: Monday, July 15, 2013 10:51 PM >>>> To: Dave Thaler; pcp@ietf.org >>>> Subject: RE: [pcp] CONSENSUS CALL on PCP security >>>> Hi Dave, >>>> In the poll when you refer to PANA, please clarify the draft you = are referring >>>> to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or >>>> http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >>>> --Tiru. >>> The question is intentionally agnostic as this is about a general = approach, >>> not which specific implementation. If it helps, you can interpret = the >>> answer as "which of the two you think is better". >>> If the consensus is PANA rather than direct EAP-in-PCP, then we = could >>> ask as a follow-up question which of the two we should go with. If >>> you'd like to include your answer to that now though, feel free to >>> include that in your response to the call. >>> -Dave >>> _______________________________________________ >>> 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 --Apple-Mail=_890CDDD8-754F-4CAF-BE1D-2668ED5DF9A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I'm not = sure if enough thought went into the PCP Proxy security. As much as I'd = love to be DONE! with this discussion, I also want to make sure people = feel comfortable having thought all aspects around the proxy use. For = (very important) example, what kind of security associations are needed for securing the proxy use: An = SA btw client and server, an SA btw client and proxy, an SA btw proxy = and server -- which combinations of these are needed?

We've included this in the updated version of auth req:

REQ-9: A PCP proxy that modifies PCP = messages SHOULD have the
ability to independently = authenticate with the PCP client and PCP
server. The presence of a PCP proxy = hence requires two separately
authenticates SAs. As a consequence, = the PCP proxy:

A. MUST be able to validate message = integrity of PCP messages
from the PCP server and client = respectively.

B. MUST be able to ensure message = integrity after updating the
PCP message for cases described in = sections 6 of ietf-pcp-proxy.

The PCP proxy MUST also permit = authentication on only one side of
the proxy. For example, a customer = premises host may not
authenticate with the PCP proxy but = the PCP proxy may authenticate
with the PCP server.
-Prashanth

Then we need to talk about how we dynamically create those using = any one of these solutions.

Alper





On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; pcp@ietf.org
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,
In the poll when you refer to PANA, please clarify the draft you = are referring
--Tiru.
The question is intentionally agnostic as this is about a general = approach,
not which specific implementation.  If it helps, you can = interpret the
answer as "which of the two you think is better".
If the consensus is PANA rather than direct EAP-in-PCP, then we = could
ask as a follow-up question which of the two we should go with. = If
you'd like to include your answer to that now though, feel free = to
include that in your response to the call.
-Dave
_______________________________________________
pcp mailing list

_______________________________________________
pcp mailing list


= --Apple-Mail=_890CDDD8-754F-4CAF-BE1D-2668ED5DF9A7-- From tireddy@cisco.com Wed Jul 17 00:09:41 2013 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 6F92F21F854E for ; Wed, 17 Jul 2013 00:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMPAYt6vrs-E for ; Wed, 17 Jul 2013 00:09:36 -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 A23A321F9BA2 for ; Wed, 17 Jul 2013 00:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25955; q=dns/txt; s=iport; t=1374044975; x=1375254575; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aP2v1czj7i23Rj7Xx3bPOthn0xlpvTdXtVlKDMfTTE8=; b=P5pZ4emlC0etVjxD5NLFsa0ugcEcHfOVozcJVH8zXCJLO90zgo2xRQUE 1EvaEWDgFb3gqxguyNh0RhH2eqXzrkzuG/Qi7wXrv7QNdYynid/MUH2Vr m3qhT/hMnkGFgInfFS5H1OdWDE3yzWI2yUWOZs8bF92PFC2PMdMWJapQy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAPJC5lGtJV2b/2dsb2JhbABagkJENE+5dog9gQ4WdIIjAQEBBAEBASQGQQsMBAIBCBEEAQELFgcHJwsUCQgCBAENBQgTh3UMtVqPPS0EBgEGgwZuA4FNlziQJIMSgWokGg X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208,217";a="235789623" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2013 07:09:32 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6H79WqF032074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 07:09:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 02:09:32 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin , "Prashanth Patil (praspati)" Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOgryVRJrEKluwhkGxicRNVT19rA== Date: Wed, 17 Jul 2013 07:09:32 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9B821@xmb-rcd-x10.cisco.com> References: <758747A2-EB6E-4581-BDE3-DD7798A77EDF@yegin.org> In-Reply-To: <758747A2-EB6E-4581-BDE3-DD7798A77EDF@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.63.247] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B9B821xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 17 Jul 2013 07:09:41 -0000 --_000_913383AAA69FF945B8F946018B75898A14B9B821xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, July 17, 2013 12:24 PM To: Prashanth Patil (praspati) Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. [TR] Why would the PCP server need to know the authentication ID of the client. = For example Home network; Alice (PCP client) -> Home Router (PCP Proxy) -= > ISP (PCP Server) Why would PCP Server in ISP care about the authentication ID of Alice ? --Tiru. Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_913383AAA69FF945B8F946018B75898A14B9B821xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see inline [TR]

 

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, July 17, 2013 12:24 PM
To: Prashanth Patil (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP securit= y)

 

Hi Prashanth,

 



I'm not sure if enough thought went into the PCP Proxy securit= y. As much as I'd love to be DONE! with this discussion, I also want to mak= e sure people feel comfortable having thought all aspects around the proxy use. For (very imp= ortant) example, what kind of security associations are needed for securing= the proxy use: An SA btw client and server, an SA btw client and proxy, an= SA btw proxy and server -- which combinations of these are needed?

 

We've included this in the updated version o= f auth req:

 

REQ-9: A PCP proxy that modifies PCP messages SHOULD have the<= /span>

ability to independently authenticate with the PCP client and = PCP

server. The presence of a PCP proxy hence requires two separat= ely

authenticates SAs. As a consequence, the PCP proxy:=

 

A. MUST be able to validate message integrity of PCP messages<= /span>

from the PCP server and client respectively.

 

B. MUST be able to ensure message integrity after updating the=

PCP message for cases described in sections 6 of ietf-pcp= -proxy.

 

The PCP proxy MUST also permit authentication on only one side= of

the proxy. For example, a customer premises host may not

authenticate with the PCP proxy but the PCP proxy may authenti= cate

with the PCP server.

 

 

 

So:

 

- We have two types of SAs. One between the client a= nd the proxy, another between the proxy and the server.

- None of them are mandatory to use.

 

For each one that needs to be used, we need to perfo= rm authentication between the end-points. 

(e.g., between client and proxy).

 

So, in a way, we are dealing with security in two in= dependent parts; client to proxy, and proxy to server. 

They are totally segregated from security perspectiv= e. 

 

 

Right?

 

Hmm, one thing: The server may need to know the auth= enticated ID of the client. Since it's not part of the client authenticatio= n, it won't know that value readily. So, we may need to define an option to= carry that piece of information from the proxy to the server.

 

[TR]

 

Why would the PCP server need to know the authentication ID = of the client. For example Home network;   Alice (PCP client) -&g= t; Home Router (PCP Proxy) -> ISP (PCP Server)

Why would PCP Server in ISP care about the authentication ID= of Alice ?

 

--Tiru.

 

Alper

 

 

 



-Prashanth

 

Then we need to talk about how we dynamically create those usi= ng any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:

 

-----Original Message-----

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 10:51 PM

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS CALL on PCP security

Hi Dave,

In the poll when you refer to PANA, please clarify the draft y= ou are referring

--Tiru.

The question is intentionally agnostic as this is about a gene= ral approach,

not which specific implementation.  If it helps, you= can interpret the

answer as "which of the two you think is better".

If the consensus is PANA rather than direct EAP-in-PCP, then w= e could

ask as a follow-up question which of the two we should go with= . If

you'd like to include your answer to that now though, feel fre= e to

include that in your response to the call.

-Dave

_______________________________________________

pcp mailing list

 

_______________________________________________

pcp mailing list

 

 

--_000_913383AAA69FF945B8F946018B75898A14B9B821xmbrcdx10ciscoc_-- From praspati@cisco.com Wed Jul 17 00:46:31 2013 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 D938D21F9CA6 for ; Wed, 17 Jul 2013 00:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56myKOJ0M2xL for ; Wed, 17 Jul 2013 00:46:26 -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 EFD6221F88DB for ; Wed, 17 Jul 2013 00:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13839; q=dns/txt; s=iport; t=1374047169; x=1375256769; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=QaiXiMviWrCTzIp0tLI6Ibh2MJMQtV+0vDhDy5udGlk=; b=b5/dUIyw/7dY88Mp+MMfPnh9cLAyHp/IwiHmFsJSUVhBm9kH4pE1Y0UO P1QNGXIn73S0j4jeFWg8Aw7qc+wc43+p9D8tttJmIcs+DtdR0XpWdijG2 qbZmcdPkcEPx/aarLiT4qcawCDVxDT45hftyDzvK7dORkZ3vmhv0uOutC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAHJK5lGtJXG+/2dsb2JhbABagkJENE+EJIFDtA6IPYEOFnSCIwEBAQQBAQFrCwwGAQgRBAEBCx0uCxQJCAIEDgUIE4d1DLVFjz0tBAcGgwZuA4FNlziQJIE1gV2BaiQa X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208,217";a="235828774" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jul 2013 07:46:08 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6H7k8R1021245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 07:46:08 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 02:46:07 -0500 From: "Prashanth Patil (praspati)" To: Alper Yegin Thread-Topic: Proxy security (was Re: [pcp] CONSENSUS CALL on PCP security) Thread-Index: AQHOgrppRoLDRvF29kml+aCL0HDhsJlpLe+A Date: Wed, 17 Jul 2013 07:46:07 +0000 Message-ID: In-Reply-To: <758747A2-EB6E-4581-BDE3-DD7798A77EDF@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [173.39.67.75] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE3238Dxmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 17 Jul 2013 07:46:32 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE3238Dxmbrcdx07ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alper, On 17/07/13 12:23 PM, "Alper Yegin" > wrote: Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. PRA: Yes, none of them are mandatory, it's currently the prerogative of the= server to mandate authentication. The proxy MUST be able authenticate with= either client or server or both. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? PRA: Right. As far as the client is concerned, the proxy is the PCP server.= The proxy is in turn a client to the upstream PCP server. The two parts sh= ould be independent of each other. Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. PRA: May be, but don=92t know why the server would want to know the auth-id= of a client. -Prashanth Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_B235506D63D65E43B2E40FD27715372E1CE3238Dxmbrcdx07ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <34B04A9A226C4841916BF304CD49C013@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Alper,

On 17/07/13 12:23 PM, "Alper Yegin" <alper.yegin@yegin.org> wrote:

Hi Prashanth,


I'm not sure if enough thought went into the PCP Proxy security. As mu= ch as I'd love to be DONE! with this discussion, I also want to make sure p= eople feel comfortable having thought all aspects around the proxy use. For= (very important) example, what kind of security associations are needed for securing the proxy use: An SA= btw client and server, an SA btw client and proxy, an SA btw proxy and ser= ver -- which combinations of these are needed?

We've included this in the updated version of auth req:

REQ-9: A PCP proxy that modifies PCP me= ssages SHOULD have the
ability to independently authenticate w= ith the PCP client and PCP
server. The presence of a PCP proxy hen= ce requires two separately
authenticates SAs. As a consequence, th= e PCP proxy:

A. MUST be able to validate message int= egrity of PCP messages
from the PCP server and client respecti= vely.

B. MUST be able to ensure message integ= rity after updating the
PCP message for cases described in sect= ions 6 of ietf-pcp-proxy.

The PCP proxy MUST also permit authenti= cation on only one side of
the proxy. For example, a customer prem= ises host may not
authenticate with the PCP proxy but the= PCP proxy may authenticate
with the PCP server.



So:

- We have two types of SAs. One between the client and the proxy, anot= her between the proxy and the server.
- None of them are mandatory to use.

PRA: Yes, none of them are mandatory, it's currently the prerogative o= f the server to mandate authentication. The proxy MUST be able authenticate= with either client or server or both.

For each one that needs to be used, we need to perform authentication = between the end-points. 
(e.g., between client and proxy).

So, in a way, we are dealing with security in two independent parts; c= lient to proxy, and proxy to server. 
They are totally segregated from security perspective. 

Right?

PRA: Right. As far as the client is concerned, the proxy is the PCP se= rver. The proxy is in turn a client to the upstream PCP server. The two par= ts should be independent of each other.

Hmm, one thing: The server may need to know the authenticated ID of th= e client. Since it's not part of the client authentication, it won't know t= hat value readily. So, we may need to define an option to carry that piece = of information from the proxy to the server.

PRA: May be, but don=92t know why the server would want to know the au= th-id of a client.

-Prashanth 

Alper




-Prashanth

Then we need to talk about how we dynamically create those using any o= ne of these solutions.

Alper





On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; pcp@ietf.org
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,
In the poll when you refer to PANA, please clarify the draft you are r= eferring
--Tiru.
The question is intentionally agnostic as this is about a general appr= oach,
not which specific implementation.  If it helps, you can int= erpret the
answer as "which of the two you think is better".
If the consensus is PANA rather than direct EAP-in-PCP, then we could =
ask as a follow-up question which of the two we should go with. If
you'd like to include your answer to that now though, feel free to
include that in your response to the call.
-Dave
_______________________________________________
pcp mailing list

_______________________________________________
pcp mailing list


 --_000_B235506D63D65E43B2E40FD27715372E1CE3238Dxmbrcdx07ciscoc_-- From alper.yegin@yegin.org Wed Jul 17 04:32:12 2013 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 DA12621F93F3 for ; Wed, 17 Jul 2013 04:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzqKOvzkIov9 for ; Wed, 17 Jul 2013 04:32:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id DFF4D21F9B19 for ; Wed, 17 Jul 2013 04:32:07 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MWCYL-1Ug1YP27A1-00XyEV; Wed, 17 Jul 2013 07:32:06 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E0E50F5D-85EB-40DF-B359-9B238BA8CC40" From: Alper Yegin In-Reply-To: <913383AAA69FF945B8F946018B75898A14B9B821@xmb-rcd-x10.cisco.com> Date: Wed, 17 Jul 2013 14:32:02 +0300 Message-Id: References: <758747A2-EB6E-4581-BDE3-DD7798A77EDF@yegin.org> <913383AAA69FF945B8F946018B75898A14B9B821@xmb-rcd-x10.cisco.com> To: Tirumaleswar Reddy (tireddy) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:Mqr7btE0g/2Gd4pC/SPMaMhcUUU1MQn1P67l2QUHLfB 1+WdgVA7vvkWJqDT3ezwL2Xir5N0jr4PzOohyUwd8nuEMuaV44 i26clez0XSgRjj43oeAQHK837pjvpbYnmSTgjFrkdfmjsMYVC6 o84NQl1zt55UeJKOx/gmeeFafxi3uceKLB704mSUXtCm1Ukea7 mlTWTUsAzaNxIB0DBpdl1peAL8MRNL1Am100ckvGHEyBLrfAhi Yt5r28+Nwu6CdmCP0ixwzWmnp31ANxhHisKjdImCwWZolD6210 NzBw3yxXgsIdz+G91qTN4vhLp1dgovL30t7vAccT/Z4S6Tn+Bo i/qb8bg0fsXbC8HgiQJ/RO7Fq8CLartMxDabDCnYHNGkrvbYSb AweJ4SFS65yEw== Cc: "pcp@ietf.org" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 17 Jul 2013 11:32:13 -0000 --Apple-Mail=_E0E50F5D-85EB-40DF-B359-9B238BA8CC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If the PCP server wants to provide some sort of differentiated service = to the subscribers (e.g., different mapping lifetime), then it needs to = know the authenticated ID of the subscriber. Alper On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: > Please see inline [TR] > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, July 17, 2013 12:24 PM > To: Prashanth Patil (praspati) > Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) > Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) > =20 > Hi Prashanth, > =20 >=20 >=20 > I'm not sure if enough thought went into the PCP Proxy security. As = much as I'd love to be DONE! with this discussion, I also want to make = sure people feel comfortable having thought all aspects around the proxy = use. For (very important) example, what kind of security associations = are needed for securing the proxy use: An SA btw client and server, an = SA btw client and proxy, an SA btw proxy and server -- which = combinations of these are needed? > =20 > We've included this in the updated version of auth req: > =20 > REQ-9: A PCP proxy that modifies PCP messages SHOULD have the > ability to independently authenticate with the PCP client and PCP > server. The presence of a PCP proxy hence requires two separately > authenticates SAs. As a consequence, the PCP proxy: > =20 > A. MUST be able to validate message integrity of PCP messages > from the PCP server and client respectively. > =20 > B. MUST be able to ensure message integrity after updating the > PCP message for cases described in sections 6 of ietf-pcp-proxy. > =20 > The PCP proxy MUST also permit authentication on only one side of > the proxy. For example, a customer premises host may not > authenticate with the PCP proxy but the PCP proxy may authenticate > with the PCP server. > =20 > =20 > =20 > So: > =20 > - We have two types of SAs. One between the client and the proxy, = another between the proxy and the server. > - None of them are mandatory to use. > =20 > For each one that needs to be used, we need to perform authentication = between the end-points.=20 > (e.g., between client and proxy). > =20 > So, in a way, we are dealing with security in two independent parts; = client to proxy, and proxy to server.=20 > They are totally segregated from security perspective.=20 > =20 > =20 > Right? > =20 > Hmm, one thing: The server may need to know the authenticated ID of = the client. Since it's not part of the client authentication, it won't = know that value readily. So, we may need to define an option to carry = that piece of information from the proxy to the server. > =20 > [TR] > =20 > Why would the PCP server need to know the authentication ID of the = client. For example Home network; Alice (PCP client) -> Home Router = (PCP Proxy) -> ISP (PCP Server) > Why would PCP Server in ISP care about the authentication ID of Alice = ? > =20 > --Tiru. > =20 > Alper > =20 > =20 > =20 >=20 >=20 > -Prashanth > =20 > Then we need to talk about how we dynamically create those using any = one of these solutions. > =20 > Alper > =20 > =20 > =20 > =20 > =20 > On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: > =20 > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Sent: Monday, July 15, 2013 10:51 PM > To: Dave Thaler; pcp@ietf.org > Subject: RE: [pcp] CONSENSUS CALL on PCP security > Hi Dave, > In the poll when you refer to PANA, please clarify the draft you are = referring > to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or > http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? > --Tiru. > The question is intentionally agnostic as this is about a general = approach, > not which specific implementation. If it helps, you can interpret the > answer as "which of the two you think is better". > If the consensus is PANA rather than direct EAP-in-PCP, then we could > ask as a follow-up question which of the two we should go with. If > you'd like to include your answer to that now though, feel free to > include that in your response to the call. > -Dave > _______________________________________________ > 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 --Apple-Mail=_E0E50F5D-85EB-40DF-B359-9B238BA8CC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If the PCP server wants to provide some sort of = differentiated service to the subscribers (e.g., different mapping = lifetime), then it needs to know the authenticated ID of the = subscriber.

Alper


On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) = wrote:

Please see inline = [TR]
 Alper = Yegin [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 = 12:24 PM
To: Prashanth Patil = (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy = (tireddy)
Subject: [pcp] Proxy security (was = Re: CONSENSUS CALL on PCP = security)
Hi = Prashanth,
I'm not sure if enough thought went into the = PCP Proxy security. As much as I'd love to be DONE! with this = discussion, I also want to make sure people feel comfortable having = thought all aspects around the proxy use. For (very important) example, = what kind of security associations are needed for securing the proxy = use: An SA btw client and server, an SA btw client and proxy, an SA btw = proxy and server -- which combinations of these are = needed?
 
We've included this in the updated version of auth = req:
REQ-9: A PCP proxy that modifies = PCP messages SHOULD have theability to independently authenticate with the PCP client and = PCP
server. The presence of a PCP proxy hence requires two = separately
authenticates SAs. As a = consequence, the PCP proxy:A. MUST be able to validate message integrity of PCP = messages
from the PCP server and client = respectively.
 
B. MUST be able to ensure message = integrity after updating thePCP message for cases described in sections 6 = of ietf-pcp-proxy.
 
The PCP proxy MUST also permit = authentication on only one side ofthe proxy. For example, a customer premises host may = not
authenticate with the PCP proxy but the PCP proxy may = authenticate
with the PCP = server.
 
 
So:
- We have two types of = SAs. One between the client and the proxy, another between the proxy and = the server.
- None of them are = mandatory to use.
For each one that needs = to be used, we need to perform authentication between the = end-points. 
(e.g., between = client and proxy).
So, in a way, we are = dealing with security in two independent parts; client to proxy, and = proxy to server. 
They are totally segregated from security = perspective. 
Hmm, one thing: The = server may need to know the authenticated ID of the client. Since it's = not part of the client authentication, it won't know that value readily. = So, we may need to define an option to carry that piece of information = from the proxy to the server.
 
[TR]
Why = would the PCP server need to know the authentication ID of the client. = For example Home network;   Alice (PCP client) -> Home = Router (PCP Proxy) -> ISP (PCP Server)
Why would PCP Server in ISP care = about the authentication ID of Alice ?
Then we need to talk about how we = dynamically create those using any one of these = solutions.
 
Alper
 
 
On Jul 16, 2013, at 7:50 PM, Dave Thaler = wrote:
-----Original = Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, July 15, 2013 10:51 = PM
To: Dave = Thaler; pcp@ietf.org
Subject: RE: [pcp] CONSENSUS CALL on PCP = security
Hi Dave,
In the poll when you refer to PANA, please = clarify the draft you are = referring
to  or
<= /div>
pcp mailing = list
To: Alper Yegin , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOgryWZGzXOvs7fU2hvWRltojzFZlpENsAgAB2EoA= Date: Wed, 17 Jul 2013 13:04:44 +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.3.5.130515 x-originating-ip: [173.39.67.75] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE32669xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 17 Jul 2013 13:05:05 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE32669xmbrcdx07ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alper, In the example below, wont the ISP consider all users behind the home route= r as a single subscriber and not differentiate among individual users? Esse= ntially, the PCP Server would treat the proxy (i.e the home router) as a si= ngle subscriber. -Prashanth On 17/07/13 5:02 PM, "Alper Yegin" > wrote: If the PCP server wants to provide some sort of differentiated service to t= he subscribers (e.g., different mapping lifetime), then it needs to know th= e authenticated ID of the subscriber. Alper On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, July 17, 2013 12:24 PM To: Prashanth Patil (praspati) Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. [TR] Why would the PCP server need to know the authentication ID of the client. = For example Home network; Alice (PCP client) -> Home Router (PCP Proxy) -= > ISP (PCP Server) Why would PCP Server in ISP care about the authentication ID of Alice ? --Tiru. Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_B235506D63D65E43B2E40FD27715372E1CE32669xmbrcdx07ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Alper,
In the example below, wont the ISP consider all users behind the home = router as a single subscriber and not differentiate among individual users?= Essentially, the PCP Server would treat the proxy (i.e the home router) as= a single subscriber.

-Prashanth

If the PCP server wants to provide some sort of differentiated service to t= he subscribers (e.g., different mapping lifetime), then it needs to know th= e authenticated ID of the subscriber.

Alper


On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote:
Please see inline [TR]
 
From:=  Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, J= uly 17, 2013 12:24 PM
To: Prashanth Pati= l (praspati)
Cc: pcp@i= etf.org; Tirumaleswar Reddy (tireddy)
Subject: [pcp] Pro= xy security (was Re: CONSENSUS CALL on PCP security)
 
Hi Prashanth,
 


I'm not sure if enough thought went into the PCP Proxy security. A= s much as I'd love to be DONE! with this discussion, I also want to make su= re people feel comfortable having thought all aspects around the proxy use. For (very important) example, wh= at kind of security associations are needed for securing the proxy use: An = SA btw client and server, an SA btw client and proxy, an SA btw proxy and s= erver -- which combinations of these are needed?
 = ;
We've incl= uded this in the updated version of auth req:
 = ;
REQ-9: A PCP proxy that modifies PCP messages SHOULD have the<= o:p>
ability to independently authenticate with the PCP client and P= CP server. The presence of a PCP proxy hence requires two separate= ly authenticates SAs. As a consequence, the PCP proxy:<= span style=3D"color: black; font-family: Calibri, sans-serif; ">=
 = ;
A. MUST be able to validate message integrity of PCP messages<= o:p>
from the PCP server and client respectively.=
 = ;
B. MUST be able to ensure message integrity after updating the<= /span>=
PCP message for cases described in sections 6 of ietf-pcp-= proxy.
 = ;
The PCP proxy MUST also permit authentication on only one side = of the proxy. For example, a customer premises host may not= <= /o:p>
authenticate with the PCP proxy but the PCP proxy may authentic= ate
with the PCP server.
 
 
 
So:
 
- We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server.
- None of them are mandatory to use.
 
For each one that needs to be used, we need to perform authentication betwe= en the end-points. 
(e.g., between client and proxy).
 
So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. 
They are totally segregated from security perspective. 
 
 
Right?
 
Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server.
 
[TR]
 
Why would the PCP server need to know the authentication = ID of the client. For example Home network;   Alice (PCP client) = -> Home Router (PCP Proxy) -> ISP (PCP Server)
Why would PCP Server in ISP care about the authentication= ID of Alice ?
 
--Tiru.
 
Alper
 
 
 


-Prashanth
 
Then we need to talk about how we dynamically create those using a= ny one of these solutions.
 
Alper
 
 
 
 
 
On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:<= /div>
 
-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@c= isco.com]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; pcp@ietf.org
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,
In the poll when you refer to PANA, please clarify the draft you a= re referring
--Tiru.
The question is intentionally agnostic as this is about a general = approach,
not which specific implementation.  If it helps, you can= interpret the
answer as "which of the two you think is better".
If the consensus is PANA rather than direct EAP-in-PCP, then we co= uld
ask as a follow-up question which of the two we should go with. If=
you'd like to include your answer to that now though, feel free to=
include that in your response to the call.
-Dave
_______________________________________________<= /div>
pcp mailing list
 
_______________________________________________<= /div>
pcp mailing list
 


--_000_B235506D63D65E43B2E40FD27715372E1CE32669xmbrcdx07ciscoc_-- From alper.yegin@yegin.org Wed Jul 17 07:36:47 2013 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 5D63321F8FF3 for ; Wed, 17 Jul 2013 07:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxGMGXO7jriM for ; Wed, 17 Jul 2013 07:36:42 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 46A0821F9FE4 for ; Wed, 17 Jul 2013 07:36:42 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MYOPh-1Udn4z2gr3-00Vn9L; Wed, 17 Jul 2013 10:36:38 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_069274B3-6179-4485-9D47-29269600E100" From: Alper Yegin In-Reply-To: Date: Wed, 17 Jul 2013 17:36:35 +0300 Message-Id: <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> References: To: "Prashanth Patil (praspati)" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:nC1OVRN+weU7wEHLIZ+bexi4SqLhIcVY1+rd4ZXM8Hj IXGDWcipar9FwGjwRi2QQBfpyRq0oSq04/ZMQfWywJbs7UszhV 3pHTNUIX0kvdd8FD7SaO/0d2NvjAgv2pJbMqOaTrIGAWmvyB0W TnuPrYIByvh4HYU2tJl+36JUullfu6aNfnY5OepT6/4mAawIYV Byiv76QH1Yd6juZmRhYzkGoiVtkKpOOOwRYgVHdfMFFZVEJpSK dw0lhb9b6njmT3xR+RnOTJPgPSlNrwYS/fJeZ+KkSD0E2BeyLr hM5xrTLG2ydtgb1kJXlOQTon40y5JfOzfqMB7zSCGzPuUvWqQc D3Z7gYgvrOcLLwyUIthrEMK2BaJJuGYspLztdt91cyNHULzvvp qT9ocUfzMY9nw== Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 17 Jul 2013 14:36:47 -0000 --Apple-Mail=_069274B3-6179-4485-9D47-29269600E100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For the home gateway case, yes I'd think so. Could we not apply PCP proxy case to public WiFi hotspots? There in that = case the terminals attaching to the AP are distinct subscribers. Alper =20 On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote: > Hi Alper, > In the example below, wont the ISP consider all users behind the home = router as a single subscriber and not differentiate among individual = users? Essentially, the PCP Server would treat the proxy (i.e the home = router) as a single subscriber. >=20 > -Prashanth >=20 > On 17/07/13 5:02 PM, "Alper Yegin" wrote: >=20 > If the PCP server wants to provide some sort of differentiated service = to the subscribers (e.g., different mapping lifetime), then it needs to = know the authenticated ID of the subscriber. >=20 > Alper >=20 >=20 > On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: >=20 >> Please see inline [TR] >> =20 >> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >> Sent: Wednesday, July 17, 2013 12:24 PM >> To: Prashanth Patil (praspati) >> Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) >> Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) >> =20 >> Hi Prashanth, >> =20 >>=20 >>=20 >>> I'm not sure if enough thought went into the PCP Proxy security. As = much as I'd love to be DONE! with this discussion, I also want to make = sure people feel comfortable having thought all aspects around the proxy = use. For (very important) example, what kind of security associations = are needed for securing the proxy use: An SA btw client and server, an = SA btw client and proxy, an SA btw proxy and server -- which = combinations of these are needed? >> =20 >> We've included this in the updated version of auth req: >> =20 >> REQ-9: A PCP proxy that modifies PCP messages SHOULD have the >> ability to independently authenticate with the PCP client and PCP >> server. The presence of a PCP proxy hence requires two separately >> authenticates SAs. As a consequence, the PCP proxy: >> =20 >> A. MUST be able to validate message integrity of PCP messages >> from the PCP server and client respectively. >> =20 >> B. MUST be able to ensure message integrity after updating the >> PCP message for cases described in sections 6 of ietf-pcp-proxy. >> =20 >> The PCP proxy MUST also permit authentication on only one side of >> the proxy. For example, a customer premises host may not >> authenticate with the PCP proxy but the PCP proxy may authenticate >> with the PCP server. >> =20 >> =20 >> =20 >> So: >> =20 >> - We have two types of SAs. One between the client and the proxy, = another between the proxy and the server. >> - None of them are mandatory to use. >> =20 >> For each one that needs to be used, we need to perform authentication = between the end-points.=20 >> (e.g., between client and proxy). >> =20 >> So, in a way, we are dealing with security in two independent parts; = client to proxy, and proxy to server.=20 >> They are totally segregated from security perspective.=20 >> =20 >> =20 >> Right? >> =20 >> Hmm, one thing: The server may need to know the authenticated ID of = the client. Since it's not part of the client authentication, it won't = know that value readily. So, we may need to define an option to carry = that piece of information from the proxy to the server. >> =20 >> [TR] >> =20 >> Why would the PCP server need to know the authentication ID of the = client. For example Home network; Alice (PCP client) -> Home Router = (PCP Proxy) -> ISP (PCP Server) >> Why would PCP Server in ISP care about the authentication ID of Alice = ? >> =20 >> --Tiru. >> =20 >> Alper >> =20 >> =20 >> =20 >>=20 >>=20 >> -Prashanth >> =20 >>> Then we need to talk about how we dynamically create those using any = one of these solutions. >>> =20 >>> Alper >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: >>> =20 >>>>> -----Original Message----- >>>>> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >>>>> Sent: Monday, July 15, 2013 10:51 PM >>>>> To: Dave Thaler; pcp@ietf.org >>>>> Subject: RE: [pcp] CONSENSUS CALL on PCP security >>>>> Hi Dave, >>>>> In the poll when you refer to PANA, please clarify the draft you = are referring >>>>> to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or >>>>> http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >>>>> --Tiru. >>>> The question is intentionally agnostic as this is about a general = approach, >>>> not which specific implementation. If it helps, you can interpret = the >>>> answer as "which of the two you think is better". >>>> If the consensus is PANA rather than direct EAP-in-PCP, then we = could >>>> ask as a follow-up question which of the two we should go with. If >>>> you'd like to include your answer to that now though, feel free to >>>> include that in your response to the call. >>>> -Dave >>>> _______________________________________________ >>>> 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 --Apple-Mail=_069274B3-6179-4485-9D47-29269600E100 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii For the home gateway case, yes I'd think so.
Could we not apply PCP proxy case to public WiFi hotspots? There in that case the terminals attaching to the AP are distinct subscribers.

Alper


 
On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote:

Hi Alper,
In the example below, wont the ISP consider all users behind the home router as a single subscriber and not differentiate among individual users? Essentially, the PCP Server would treat the proxy (i.e the home router) as a single subscriber.

-Prashanth

On 17/07/13 5:02 PM, "Alper Yegin" <alper.yegin@yegin.org> wrote:

If the PCP server wants to provide some sort of differentiated service to the subscribers (e.g., different mapping lifetime), then it needs to know the authenticated ID of the subscriber.

Alper


On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote:

Please see inline [TR]
 
From: Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 12:24 PM
To: Prashanth Patil (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)
 
Hi Prashanth,
 


I'm not sure if enough thought went into the PCP Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfortable having thought all aspects around the proxy use. For (very important) example, what kind of security associations are needed for securing the proxy use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinations of these are needed?
 
We've included this in the updated version of auth req:
 
REQ-9: A PCP proxy that modifies PCP messages SHOULD have the
ability to independently authenticate with the PCP client and PCP
server. The presence of a PCP proxy hence requires two separately
authenticates SAs. As a consequence, the PCP proxy:
 
A. MUST be able to validate message integrity of PCP messages
from the PCP server and client respectively.
 
B. MUST be able to ensure message integrity after updating the
PCP message for cases described in sections 6 of ietf-pcp-proxy.
 
The PCP proxy MUST also permit authentication on only one side of
the proxy. For example, a customer premises host may not
authenticate with the PCP proxy but the PCP proxy may authenticate
with the PCP server.
 
 
 
So:
 
- We have two types of SAs. One between the client and the proxy, another between the proxy and the server.
- None of them are mandatory to use.
 
For each one that needs to be used, we need to perform authentication between the end-points. 
(e.g., between client and proxy).
 
So, in a way, we are dealing with security in two independent parts; client to proxy, and proxy to server. 
They are totally segregated from security perspective. 
 
 
Right?
 
Hmm, one thing: The server may need to know the authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. So, we may need to define an option to carry that piece of information from the proxy to the server.
 
[TR]
 
Why would the PCP server need to know the authentication ID of the client. For example Home network;   Alice (PCP client) -> Home Router (PCP Proxy) -> ISP (PCP Server)
Why would PCP Server in ISP care about the authentication ID of Alice ?
 
--Tiru.
 
Alper
 
 
 


-Prashanth
 
Then we need to talk about how we dynamically create those using any one of these solutions.
 
Alper
 
 
 
 
 
On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:
 
-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; pcp@ietf.org
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,
In the poll when you refer to PANA, please clarify the draft you are referring
--Tiru.
The question is intentionally agnostic as this is about a general approach,
not which specific implementation.  If it helps, you can interpret the
answer as "which of the two you think is better".
If the consensus is PANA rather than direct EAP-in-PCP, then we could
ask as a follow-up question which of the two we should go with. If
you'd like to include your answer to that now though, feel free to
include that in your response to the call.
-Dave
_______________________________________________
pcp mailing list
 
_______________________________________________
pcp mailing list
 

--Apple-Mail=_069274B3-6179-4485-9D47-29269600E100-- From dwing@cisco.com Wed Jul 17 11:11:27 2013 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 95AB621E8091 for ; Wed, 17 Jul 2013 11:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.508 X-Spam-Level: X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KETy8z9s28-L for ; Wed, 17 Jul 2013 11:11:23 -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 3F21721E8086 for ; Wed, 17 Jul 2013 11:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14963; q=dns/txt; s=iport; t=1374084680; x=1375294280; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=oUpVxk+C7FY+kYZ4vUbUbE/fHC0TLdZ+Gja0CZf3DHU=; b=T1os/YnxNziUu0wg6z9mEp1JbvR2iRsp3M0eL8l+alwxCq60UL8r1qh9 kTA6IiXmTjFuZQGhVpBfQCSLMJ6nTBNu4kvZ2s+2mLC7GtZI35X4ZTEM8 3rJLq9Xy197ehGs4ZbdWTkfVZ9uU+sxaMwveDxv70X+AEDLcGsJyzJLU4 o=; X-IronPort-AV: E=Sophos;i="4.89,686,1367971200"; d="scan'208,217";a="83268039" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 17 Jul 2013 18:11:19 +0000 Received: from sjc-vpn6-1086.cisco.com (sjc-vpn6-1086.cisco.com [10.21.124.62]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6HIBIOB022522; Wed, 17 Jul 2013 18:11:18 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_15780669-051C-4E3B-8BDA-B45D14130FDF" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <758747A2-EB6E-4581-BDE3-DD7798A77EDF@yegin.org> Date: Wed, 17 Jul 2013 11:11:18 -0700 Message-Id: <3E000B89-C81D-4E0E-B810-92901F6A2E8E@cisco.com> References: <758747A2-EB6E-4581-BDE3-DD7798A77EDF@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1508) Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 17 Jul 2013 18:11:27 -0000 --Apple-Mail=_15780669-051C-4E3B-8BDA-B45D14130FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 16, 2013, at 11:53 PM, Alper Yegin wrote: > Hi Prashanth, >=20 >=20 >>> I'm not sure if enough thought went into the PCP Proxy security. As = much as I'd love to be DONE! with this discussion, I also want to make = sure people feel comfortable having thought all aspects around the proxy = use. For (very important) example, what kind of security associations = are needed for securing the proxy use: An SA btw client and server, an = SA btw client and proxy, an SA btw proxy and server -- which = combinations of these are needed? >>=20 >> We've included this in the updated version of auth req: >>=20 >> REQ-9: A PCP proxy that modifies PCP messages SHOULD have the >> ability to independently authenticate with the PCP client and PCP >> server. The presence of a PCP proxy hence requires two separately >> authenticates SAs. As a consequence, the PCP proxy: >>=20 >> A. MUST be able to validate message integrity of PCP messages >> from the PCP server and client respectively. >>=20 >> B. MUST be able to ensure message integrity after updating the >> PCP message for cases described in sections 6 of ietf-pcp-proxy. >>=20 >> The PCP proxy MUST also permit authentication on only one side of >> the proxy. For example, a customer premises host may not >> authenticate with the PCP proxy but the PCP proxy may authenticate >> with the PCP server. >>=20 >=20 >=20 > So: >=20 > - We have two types of SAs. One between the client and the proxy, = another between the proxy and the server. > - None of them are mandatory to use. >=20 > For each one that needs to be used, we need to perform authentication = between the end-points.=20 > (e.g., between client and proxy). >=20 > So, in a way, we are dealing with security in two independent parts; = client to proxy, and proxy to server.=20 > They are totally segregated from security perspective.=20 >=20 >=20 > Right? That is how I have modeled it in my head, yes. Imagining a home = network, there are "N" people and "MM" devices in the home. Each person = and each device might have its own credentials and its own permissions = to do various things (e.g., I don't want to allow my Sony television to = run a server). My ISP does not care about my NNN people and MMMM = devices; it only knows of one user, and only wants to know of one user = (anything else is too hard for the ISP). So, the PCP proxy enforces = policies for the NNN people and MMMM devices, and the PCP proxy uses = different credentials (and thus a different security association) to = talk with the ISP's PCP server. The per-user and per-device policy is = "aggregated" by the PCP proxy. The same would occur within an = enterprise network, where there are NNN people and MMMM devices. >=20 > Hmm, one thing: The server may need to know the authenticated ID of = the client. Since it's not part of the client authentication, it won't = know that value readily. So, we may need to define an option to carry = that piece of information from the proxy to the server. That's a different model, where the per-user / per-device policy is not = aggregated by the PCP proxy; instead, the client's identity is = propagated through the network. I don't know if we need that model yet. -d > Alper >=20 >=20 >=20 >=20 >> -Prashanth >>=20 >>> Then we need to talk about how we dynamically create those using any = one of these solutions. >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: >>>=20 >>>>> -----Original Message----- >>>>> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >>>>> Sent: Monday, July 15, 2013 10:51 PM >>>>> To: Dave Thaler; pcp@ietf.org >>>>> Subject: RE: [pcp] CONSENSUS CALL on PCP security >>>>> Hi Dave, >>>>> In the poll when you refer to PANA, please clarify the draft you = are referring >>>>> to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or >>>>> http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >>>>> --Tiru. >>>> The question is intentionally agnostic as this is about a general = approach, >>>> not which specific implementation. If it helps, you can interpret = the >>>> answer as "which of the two you think is better". >>>> If the consensus is PANA rather than direct EAP-in-PCP, then we = could >>>> ask as a follow-up question which of the two we should go with. If >>>> you'd like to include your answer to that now though, feel free to >>>> include that in your response to the call. >>>> -Dave >>>> _______________________________________________ >>>> 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 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail=_15780669-051C-4E3B-8BDA-B45D14130FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii alper.yegin@yegin.org> = wrote:

I'm not sure if enough thought went into the PCP = Proxy security. As much as I'd love to be DONE! with this discussion, I = also want to make sure people feel comfortable having thought all = aspects around the proxy use. For (very important) example, what kind of security associations are needed for securing the proxy use: An = SA btw client and server, an SA btw client and proxy, an SA btw proxy = and server -- which combinations of these are needed?

We've included this in the updated version of auth req:

REQ-9: A PCP proxy that modifies PCP = messages SHOULD have the
ability to independently = authenticate with the PCP client and PCP
server. The presence of a PCP proxy = hence requires two separately
authenticates SAs. As a consequence, = the PCP proxy:

A. MUST be able to validate message = integrity of PCP messages
from the PCP server and client = respectively.

B. MUST be able to ensure message = integrity after updating the
PCP message for cases described in = sections 6 of ietf-pcp-proxy.

The PCP proxy MUST also permit = authentication on only one side of
the proxy. For example, a customer = premises host may not
authenticate with the PCP proxy but = the PCP proxy may authenticate
with the PCP server.


Hmm, one thing: The server = may need to know the authenticated ID of the client. Since it's not part = of the client authentication, it won't know that value readily. So, we = may need to define an option to carry that piece of information from the = proxy to the = server.

That's a = different model, where the per-user / per-device policy is not = aggregated by the PCP proxy; instead, the client's identity is = propagated through the network.  I don't know if we need that model = yet.

-d


-Prashanth

Then we need to talk about how we dynamically create those using = any one of these solutions.

Alper





On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; pcp@ietf.org
Subject: RE: [pcp] CONSENSUS CALL on PCP security
Hi Dave,
In the poll when you refer to PANA, please clarify the draft you = are referring
--Tiru.
The question is intentionally agnostic as this is about a general = approach,
not which specific implementation.  If it helps, you can = interpret the
answer as "which of the two you think is better".
If the consensus is PANA rather than direct EAP-in-PCP, then we = could
ask as a follow-up question which of the two we should go with. = If
you'd like to include your answer to that now though, feel free = to
include that in your response to the call.
-Dave
_______________________________________________
pcp mailing list

_______________________________________________
pcp mailing list

=

_____________________________________________= __
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mail= man/listinfo/pcp

= --Apple-Mail=_15780669-051C-4E3B-8BDA-B45D14130FDF-- From B.McCann@F5.com Wed Jul 17 12:20:40 2013 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 0A5E211E80D1 for ; Wed, 17 Jul 2013 12:20:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BTLfLLmaunE for ; Wed, 17 Jul 2013 12:20:35 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 7053921F9F1F for ; Wed, 17 Jul 2013 12:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=B.McCann@f5.com; q=dns/txt; s=seattle; t=1374088835; x=1405624835; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fBFRYkHzrrPbfpU/g4jbBVqicniRmZ3EsL+V8624wE8=; b=YNGuxNQHXVLTqTOLaCOpC1396YEwy5dMfGTiPXbStxMO+4IiS4cJfmeR LksPfXQZ7IkVZkUBUn0LNRjgWyPcKSAisNSvx6JXQivHd2lOhOLZSvYfh qB4Emu5c6CBMNoS9nyjgKfGD5Pm9UJ5OPGczMGqKSObuGKiq7RfVEF8P0 I=; X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="76357136" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 17 Jul 2013 19:20:35 +0000 Received: from LWLECAS02.olympus.F5Net.com (192.168.96.201) by SEAECAS01.olympus.F5Net.com (192.168.16.220) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Jul 2013 12:20:34 -0700 Received: from LWLMBX01.olympus.F5Net.com ([fe80::c509:8f7f:7f5f:cab9]) by LWLECAS02.olympus.F5Net.com ([::1]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 15:20:33 -0400 From: Ben McCann To: Dave Thaler , "pcp@ietf.org" Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: AQHOgYO4rwdufDiNpE2YPGo0KrBE65lpL+CQ Date: Wed, 17 Jul 2013 19:20:32 +0000 Message-ID: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.101.23] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 17 Jul 2013 19:20:40 -0000 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. =A0=A0=A0YES 2) Could you *live with* PANA? If not, state reason you would object. =A0=A0=A0Yes, but we really rather not use PANA. See below... 3) If you said yes to both 1 and 2, but have a strong preference between th= e two, which approach do you prefer and why? We strongly prefer EAP-in-PCP for several reasons: * PANA, as we understand it, is not mobile-friendly. It requires the PCP cl= ient to *always* have an authenticated session active and that is wasteful = on mobile clients when the authentication rekey interval is much shorter th= an the mapping lifetime. Margaret Wasserman captured this in slides 13 and = 14 of her presentation http://www.ietf.org/proceedings/85/slides/slides-85-= pcp-17.pdf. We believe the *client* should decide when to authenticate (bec= ause it needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption.=20 We understand that a PCP server may need to send a message to the client wh= en no authenticated session is active. If no authenticated session is activ= e then we prefer the server send an UN-authenticated "call home" message di= recting the client to authenticate and then the server can send its message= s over the authenticated channel. We recognize an attacker can induce the c= lient to connect to the server by forging an unauthenticated "call home" me= ssage. But, having done that, the client can ignore subsequent forged call = home messages because it will already have an authenticated session. Worse = case, an attacker can't make EAP-in-PCP consume any more client resources t= han PANA does because PANA requires the client to always have an authentica= ted session available. * PANA requires more server side resources. The authentication protocol sho= uld efficiently support 100,000's of clients on a large PCP server. Why sho= uld the server continuously maintain authenticated sessions with *every* cl= ient? Clients using 24 hour mapping lifetimes can be served by short authen= tication key lifetime like, for example, 5 minutes. Let the client connect,= authenticate, program the mappings, and then let the authenticated session= expire. Rinse and repeat in 24 hours,. Client-driven authentication via EA= P-in-PCP requires less resources on the server because the server can disca= rd the authenticated session state once the key lifetime expires. There was some discussion that PANA is preferable to EAP-in-PCP because it = supports "liveness testing". We don't believe liveness testing is useful wh= en the server resources consumed, per client, are PCP mappings. Checking th= e liveness of 100,000 clients is much more resource intensive on the server= than just keeping the client's mappings around until they expire naturally= at the end of their lifetime. In short, we believe EAP-in-PCP will scale b= etter on the server than PANA. * We believe the decision to use EAP-in-PCP vs. PANA is a choice between de= signing and implementing an EAP-in-PCP transport that is tailored for PCP v= ersus adapting an existing protocol (PANA) to fit the needs of PCP. We don= 't think implementing an EAP-in-PCP transport is difficult so we prefer it = over PANA. EAP-in-PCP provides a clean slate that's unencumbered by the des= ign decisions and assumptions of an existing protocol (PANA).=20 -Ben McCann From tireddy@cisco.com Wed Jul 17 23:38:03 2013 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 4ECD421F8C4C for ; Wed, 17 Jul 2013 23:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcC2sFEXWpu3 for ; Wed, 17 Jul 2013 23:37:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E223921F8B12 for ; Wed, 17 Jul 2013 23:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39449; q=dns/txt; s=iport; t=1374129478; x=1375339078; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h9cpbyf6nQNZLmV8nod1vhKIm85+Iji0/0rjAAYW/IM=; b=HjgpYQGzG7APqa5FVKjG71zeNNKASZBpEE66SHZ+8j5KqRdfjQ95yqOv N6CR8SscR6cvL3ViKxRM6heyE38BoalN/ectXD44emcirqzwxRMyhL487 h192tgiym5HUic7iOFm68+utCyKgOdsLHUy01U4ww3EOW04ImJbrqdRF7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFALmL51GtJXG8/2dsb2JhbABagkJENFC4A4g8gREWdIIjAQEBAQMBAQEkBkELDAQCAQgRBAEBCxYBBgcnCxQJCAIEAQ0FCBOHdQy2RY9JLQQGAQaDB24DgU2XOJAkgxKBaiQa X-IronPort-AV: E=Sophos;i="4.89,691,1367971200"; d="scan'208,217";a="236103989" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jul 2013 06:37:56 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6I6buwF003848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 06:37:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 01:37:56 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin , "Prashanth Patil (praspati)" Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOgryVRJrEKluwhkGxicRNVT19rJlpENsAgAAZ5wCAABmpgIAAsyPg Date: Thu, 18 Jul 2013 06:37:55 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9C327@xmb-rcd-x10.cisco.com> References: <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> In-Reply-To: <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.76.229] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B9C327xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 06:38:03 -0000 --_000_913383AAA69FF945B8F946018B75898A14B9C327xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, July 17, 2013 8:07 PM To: Prashanth Patil (praspati) Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) For the home gateway case, yes I'd think so. Could we not apply PCP proxy case to public WiFi hotspots? There in that ca= se the terminals attaching to the AP are distinct subscribers. I did not get the use case, though there are distinct subscribers attached = to the WLC (MAG), wouldn't WLC act as PCP Proxy and communicate with the PC= P Server in ISP to which it's a single subscriber. This looks just like Enterprise deployment where there are multiple users (= similar to distinct subscribers attached to AP) communicating with the PCP = server in the Enterprise Network, the PCP server in the campus would act as= PCP proxy communicating with the ISP (PCP Server) to which it's a single s= ubscriber. --Tiru. Alper On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote: Hi Alper, In the example below, wont the ISP consider all users behind the home route= r as a single subscriber and not differentiate among individual users? Esse= ntially, the PCP Server would treat the proxy (i.e the home router) as a si= ngle subscriber. -Prashanth On 17/07/13 5:02 PM, "Alper Yegin" > wrote: If the PCP server wants to provide some sort of differentiated service to t= he subscribers (e.g., different mapping lifetime), then it needs to know th= e authenticated ID of the subscriber. Alper On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, July 17, 2013 12:24 PM To: Prashanth Patil (praspati) Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. [TR] Why would the PCP server need to know the authentication ID of the client. = For example Home network; Alice (PCP client) -> Home Router (PCP Proxy) -= > ISP (PCP Server) Why would PCP Server in ISP care about the authentication ID of Alice ? --Tiru. Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_913383AAA69FF945B8F946018B75898A14B9C327xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, July 17, 2013 8:07 PM
To: Prashanth Patil (praspati)
Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

For the home gateway case, yes I'd think so.

Could we not apply PCP proxy case to public WiFi hot= spots? There in that case the terminals attaching to the AP are distinct su= bscribers.

 

I did not get the use case, though there are distinct subscr= ibers attached to the WLC (MAG), wouldn’t WLC act as PCP Proxy and co= mmunicate with the PCP Server in ISP to which it’s a single subscriber.

 

This looks just like Enterprise deployment where there are m= ultiple users (similar to distinct subscribers attached to AP) communicatin= g with the PCP server in the Enterprise Network, the PCP server in the campus would act as PCP p= roxy communicating with the ISP (PCP Server) to which it’s a single s= ubscriber.

 

--Tiru.

 

Alper

 

 

 

On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspa= ti) wrote:



Hi Alper,

In the example below, wont the ISP consider all users behind t= he home router as a single subscriber and not differentiate among individua= l users? Essentially, the PCP Server would treat the proxy (i.e the home router) as a single sub= scriber.

 

-Prashanth

 

On 17/07/13 5:02 PM, "Alper Yegin" <alper.yegin@yegin.org> wrote:=

 

If the PCP server wants to provide some sort of differentiated= service to the subscribers (e.g., different mapping lifetime), then it nee= ds to know the authenticated ID of the subscriber.

 

Alper

 

 

On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wro= te:



Please see inline [TR]

 <= /p>

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Wednesday, J= uly 17, 2013 12:24 PM
To: Prashanth Pati= l (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: [pcp] Pro= xy security (was Re: CONSENSUS CALL on PCP security)

 =

Hi Prashanth,=

 =




I'm not sure if enough thought went into the PCP Proxy securit= y. As much as I'd love to be DONE! with this discussion, I also want to mak= e sure people feel comfortable having thought all aspects around the proxy use. For (very imp= ortant) example, what kind of security associations are needed for securing= the proxy use: An SA btw client and server, an SA btw client and proxy, an= SA btw proxy and server -- which combinations of these are needed?<= /o:p>

 

We've included this in the updated version o= f auth req:

 

REQ-9: A PCP proxy that modifies PCP messages SHOULD have the<= /span>

ability to independently authenticate with the PCP client and = PCP

server. The presence of a PCP proxy hence requires two separat= ely

authenticates SAs. As a consequence, the PCP proxy:=

 

A. MUST be able to validate message integrity of PCP messages<= /span>

from the PCP server and client respectively.

 

B. MUST be able to ensure message integrity after updating the=

PCP message for cases described in sections 6 of ietf-pcp= -proxy.

 

The PCP proxy MUST also permit authentication on only one side= of

the proxy. For example, a customer premises host may not

authenticate with the PCP proxy but the PCP proxy may authenti= cate

with the PCP server.

 

 =

 =

So:

 =

- We have two types of S= As. One between the client and the proxy, another between the proxy and the= server.

- None of them are manda= tory to use.

 =

For each one that needs = to be used, we need to perform authentication between the end-points. =

(e.g., between client an= d proxy).

 =

So, in a way, we are dea= ling with security in two independent parts; client to proxy, and proxy to = server. 

They are totally segrega= ted from security perspective. 

 =

 =

Right?=

 =

Hmm, one thing: The serv= er may need to know the authenticated ID of the client. Since it's not part= of the client authentication, it won't know that value readily. So, we may= need to define an option to carry that piece of information from the proxy to the server.

 <= /p>

[TR]

 <= /p>

Why would the PCP server need to know the authentication ID = of the client. For example Home network;   Alice (PCP client) -&g= t; Home Router (PCP Proxy) -> ISP (PCP Server)

Why would PCP Server in ISP care about the authentication ID= of Alice ?

 <= /p>

--Tiru.=

 =

Alper<= /p>

 =

 =

 =




-Prashanth

 

Then we need to talk about how we dynamically create those usi= ng any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:

 

-----Original Message-----<= o:p>

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=

Sent: Monday, July 15, 2013 10:51 PM

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS CALL on PCP security

Hi Dave,<= /p>

In the poll when you refer to PANA, please clarify the draft y= ou are referring

--Tiru.

The question is intentionally agnostic as this is about a gene= ral approach,

not which specific implementation.  If it helps, you= can interpret the

answer as "which of the two you think is better".

If the consensus is PANA rather than direct EAP-in-PCP, then w= e could

ask as a follow-up question which of the two we should go with= . If

you'd like to include your answer to that now though, feel fre= e to

include that in your response to the call.

-Dave

_______________________________________________

pcp mailing list=

 

_______________________________________________

pcp mailing list=

 

 

 

--_000_913383AAA69FF945B8F946018B75898A14B9C327xmbrcdx10ciscoc_-- From alper.yegin@yegin.org Thu Jul 18 01:07:05 2013 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 43C4321F9C06 for ; Thu, 18 Jul 2013 01:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7iu4taLJPNW for ; Thu, 18 Jul 2013 01:07:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 00D6B21F9FFB for ; Thu, 18 Jul 2013 01:06:58 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LaGaE-1UI7Yl12i6-00m7Q1; Thu, 18 Jul 2013 04:06:57 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FA1E3A04-35A4-4212-93FB-7CEA7AAE18A1" From: Alper Yegin In-Reply-To: <913383AAA69FF945B8F946018B75898A14B9C327@xmb-rcd-x10.cisco.com> Date: Thu, 18 Jul 2013 11:06:47 +0300 Message-Id: <3F1B99E5-B6A0-4149-A58E-0A80838874C1@yegin.org> References: <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C327@xmb-rcd-x10.cisco.com> To: Tirumaleswar Reddy (tireddy) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:HfWUFgTDge3HOyDTUaPHsAgIfxtt3QMw1e3lWOTNtM7 cQe2L+TXuE2//hfA+as5aS+1mGMEfiYoDfXZXxT+IVp6l3D2w3 uUBSkJCGi85DfTpglQsdtb+yEauU8ZvCk1btNIRi249rSGDGl5 uLuwJ1cjpWeBoqWFom8rva5SEBuLD3ilBX0zSnu0/NRlJRIINI je+70xis8mCM8XpOI6qXOxxIgvTpNRdVWYdg2v5o0WEphSUumH do1EgmuOXpzlESu8tmxj93w+wsm8RHpr+Ed3GwalAl3KqZmbwx oMc3lnoJ+0UiKiev1j22ld8Zf6/+lPkOyFvswsH4wMGH1VDALF Ui9YQwe2AD8/rCtX44Te+c7topuz0wfDi5NccSRPWfEC64dFmR JkZQqBRoSb3vA== Cc: "pcp@ietf.org" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 08:07:05 -0000 --Apple-Mail=_FA1E3A04-35A4-4212-93FB-7CEA7AAE18A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Tiru, I'm talking about "public WiFi hotspot". Like in coffee shops. The PCP proxy and the PCP server are either owned by the same ISP, or = two separate business entities. The users who attach to the hotspot are all distinct subscribers with = distinct service plans. This is different than how all members of my = house appears to the ISP, or all employees appears to the enterprise = network administration.=20 So, the PCP service provided to each user may differ. Maybe not all = users are allowed to control some certain ports. For PCP server to be = able to act based on the Id of the users, it needs to know who they are = as the requests are proxies by the PCP proxy. Alper On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tireddy) wrote: > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, July 17, 2013 8:07 PM > To: Prashanth Patil (praspati) > Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org > Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) > =20 > For the home gateway case, yes I'd think so. > Could we not apply PCP proxy case to public WiFi hotspots? There in = that case the terminals attaching to the AP are distinct subscribers. > =20 > I did not get the use case, though there are distinct subscribers = attached to the WLC (MAG), wouldn=92t WLC act as PCP Proxy and = communicate with the PCP Server in ISP to which it=92s a single = subscriber. > =20 > This looks just like Enterprise deployment where there are multiple = users (similar to distinct subscribers attached to AP) communicating = with the PCP server in the Enterprise Network, the PCP server in the = campus would act as PCP proxy communicating with the ISP (PCP Server) to = which it=92s a single subscriber. > =20 > --Tiru. > =20 > Alper > =20 > =20 > =20 > On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote: >=20 >=20 > Hi Alper, > In the example below, wont the ISP consider all users behind the home = router as a single subscriber and not differentiate among individual = users? Essentially, the PCP Server would treat the proxy (i.e the home = router) as a single subscriber. > =20 > -Prashanth > =20 > On 17/07/13 5:02 PM, "Alper Yegin" wrote: > =20 > If the PCP server wants to provide some sort of differentiated service = to the subscribers (e.g., different mapping lifetime), then it needs to = know the authenticated ID of the subscriber. > =20 > Alper > =20 > =20 > On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: >=20 >=20 > Please see inline [TR] > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, July 17, 2013 12:24 PM > To: Prashanth Patil (praspati) > Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) > Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) > =20 > Hi Prashanth, > =20 >=20 >=20 >=20 > I'm not sure if enough thought went into the PCP Proxy security. As = much as I'd love to be DONE! with this discussion, I also want to make = sure people feel comfortable having thought all aspects around the proxy = use. For (very important) example, what kind of security associations = are needed for securing the proxy use: An SA btw client and server, an = SA btw client and proxy, an SA btw proxy and server -- which = combinations of these are needed? > =20 > We've included this in the updated version of auth req: > =20 > REQ-9: A PCP proxy that modifies PCP messages SHOULD have the > ability to independently authenticate with the PCP client and PCP > server. The presence of a PCP proxy hence requires two separately > authenticates SAs. As a consequence, the PCP proxy: > =20 > A. MUST be able to validate message integrity of PCP messages > from the PCP server and client respectively. > =20 > B. MUST be able to ensure message integrity after updating the > PCP message for cases described in sections 6 of ietf-pcp-proxy. > =20 > The PCP proxy MUST also permit authentication on only one side of > the proxy. For example, a customer premises host may not > authenticate with the PCP proxy but the PCP proxy may authenticate > with the PCP server. > =20 > =20 > =20 > So: > =20 > - We have two types of SAs. One between the client and the proxy, = another between the proxy and the server. > - None of them are mandatory to use. > =20 > For each one that needs to be used, we need to perform authentication = between the end-points.=20 > (e.g., between client and proxy). > =20 > So, in a way, we are dealing with security in two independent parts; = client to proxy, and proxy to server.=20 > They are totally segregated from security perspective.=20 > =20 > =20 > Right? > =20 > Hmm, one thing: The server may need to know the authenticated ID of = the client. Since it's not part of the client authentication, it won't = know that value readily. So, we may need to define an option to carry = that piece of information from the proxy to the server. > =20 > [TR] > =20 > Why would the PCP server need to know the authentication ID of the = client. For example Home network; Alice (PCP client) -> Home Router = (PCP Proxy) -> ISP (PCP Server) > Why would PCP Server in ISP care about the authentication ID of Alice = ? > =20 > --Tiru. > =20 > Alper > =20 > =20 > =20 >=20 >=20 >=20 > -Prashanth > =20 > Then we need to talk about how we dynamically create those using any = one of these solutions. > =20 > Alper > =20 > =20 > =20 > =20 > =20 > On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: > =20 > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Sent: Monday, July 15, 2013 10:51 PM > To: Dave Thaler; pcp@ietf.org > Subject: RE: [pcp] CONSENSUS CALL on PCP security > Hi Dave, > In the poll when you refer to PANA, please clarify the draft you are = referring > to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or > http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? > --Tiru. > The question is intentionally agnostic as this is about a general = approach, > not which specific implementation. If it helps, you can interpret the > answer as "which of the two you think is better". > If the consensus is PANA rather than direct EAP-in-PCP, then we could > ask as a follow-up question which of the two we should go with. If > you'd like to include your answer to that now though, feel free to > include that in your response to the call. > -Dave > _______________________________________________ > 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 --Apple-Mail=_FA1E3A04-35A4-4212-93FB-7CEA7AAE18A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Tiru,

I'm talking about "public = WiFi hotspot". Like in coffee shops.
The PCP proxy and the PCP = server are either owned by the same ISP, or two separate business = entities.
The users who attach to the hotspot are all distinct = subscribers with distinct service plans. This is different than how all = members of my house appears to the ISP, or all employees appears to the = enterprise network administration. 
So, the PCP service = provided to each user may differ. Maybe not all users are allowed to = control some certain ports.  For PCP server to be able to act based = on the Id of the users, it needs to know who they are as the requests = are proxies by the PCP = proxy.

Alper


<= div>



On Jul = 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tireddy) wrote:

 Alper = Yegin [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 = 8:07 PM
To: Prashanth Patil = (praspati)
Cc: Tirumaleswar Reddy = (tireddy); pcp@ietf.org
Subject: Re: [pcp] Proxy security = (was Re: CONSENSUS CALL on PCP = security)
For the home gateway case, yes = I'd think so.
Could we not apply PCP = proxy case to public WiFi hotspots? There in that case the terminals = attaching to the AP are distinct subscribers.
I did = not get the use case, though there are distinct subscribers attached to = the WLC (MAG), wouldn=92t WLC act as PCP Proxy and communicate with the = PCP Server in ISP to which it=92s a single = subscriber.
This = looks just like Enterprise deployment where there are multiple users = (similar to distinct subscribers attached to AP) communicating with the = PCP server in the Enterprise Network, the PCP server in the campus would = act as PCP proxy communicating with the ISP (PCP Server) to which it=92s = a single subscriber.
 
On Jul 17, 2013, at 4:04 = PM, Prashanth Patil (praspati) wrote:


Hi = Alper,
In the example = below, wont the ISP consider all users behind the home router as a = single subscriber and not differentiate among individual users? = Essentially, the PCP Server would treat the proxy (i.e the home router) = as a single subscriber.
-Prashanth
On 17/07/13 5:02 PM, "Alper Yegin" <alper.yegin@yegin.org> = wrote:
 
If the PCP server wants to provide some sort = of differentiated service to the subscribers (e.g., different mapping = lifetime), then it needs to know the authenticated ID of the = subscriber.
Alper
 
 
On Jul 17, 2013, at 10:09 AM, Tirumaleswar = Reddy (tireddy) wrote:
Please see inline [TR]
 
Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 = 12:24 PM
To: Prashanth Patil = (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy = (tireddy)
Subject: [pcp] Proxy security (was = Re: CONSENSUS CALL on PCP security)Hi = Prashanth,
I'm not sure = if enough thought went into the PCP Proxy security. As much as I'd love = to be DONE! with this discussion, I also want to make sure people feel = comfortable having thought all aspects around the proxy use. For (very = important) example, what kind of security associations are needed for = securing the proxy use: An SA btw client and server, an SA btw client = and proxy, an SA btw proxy and server -- which combinations of these are = needed? We've = included this in the updated version of auth req:REQ-9: A PCP proxy that modifies = PCP messages SHOULD have theability to independently authenticate with the PCP client and = PCPserver. The presence of a PCP proxy hence requires two = separatelyauthenticates SAs. As a consequence, the PCP = proxy:A. MUST be able to validate message integrity of PCP = messagesfrom the PCP server and client respectively.B. MUST be able to ensure message integrity after updating = thePCP message for cases described in sections 6 = of ietf-pcp-proxy.The PCP proxy MUST also permit authentication on only one side = ofthe proxy. For example, a customer premises host may = notauthenticate with the PCP proxy but the PCP proxy may = authenticatewith the PCP server. - We have two types of = SAs. One between the client and the proxy, another between the proxy and = the server.
- None of them are = mandatory to use.
For each one that needs = to be used, we need to perform authentication between the = end-points. 
(e.g., between client = and proxy).
So, in a way, we are = dealing with security in two independent parts; client to proxy, and = proxy to server. 
They are totally = segregated from security = perspective. 
Hmm, one thing: The = server may need to know the authenticated ID of the client. Since it's = not part of the client authentication, it won't know that value readily. = So, we may need to define an option to carry that piece of information = from the proxy to the server.
 
[TR]Why = would the PCP server need to know the authentication ID of the client. = For example Home network;   Alice (PCP client) -> Home = Router (PCP Proxy) -> ISP (PCP Server)
Why would PCP Server in ISP care about the = authentication ID of Alice ?-Prashanth
 
Then we need to talk about how we = dynamically create those using any one of these solutions. Alper     On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: 
-----Original Message-----From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, July 15, 2013 10:51 = PMTo: Dave Thaler; pcp@ietf.orgSubject: RE: [pcp] CONSENSUS CALL on PCP securityHi Dave,In the poll when you refer to PANA, please clarify the draft = you are referringto  or ?
  Subject: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 08:33:57 -0000 Hello, I'm afraid your below issues are based on misconceptions introduced by = the http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf = slides. We did address those misconceptions in several rounds, but it seems like = some still linger. PANA does not force clients to always have a session, or always stay = awake or connected. If a client wants to get authenticated and generate a 5 minute key, and = afterwards sleep, detach, etc., it can very well do that using PANA. We can support that by simply setting the lifetime of the PANA SA to = that short fix value, or letting the PANA SA timeout and expire.=20 So, you can run PANA and have a 5 min SA, then have no PANA activity for = 23:55hrs, and then come back and do another PANA authentication and have = another 5min SA. No problems. Therefore, there are no issues with mobile, and no issues with server = side resources. After all, PANA is adopted by Zigbee Alliance. I don't think the = deployment cases considered here are any more constrained than theirs=85 > EAP-in-PCP provides a clean slate that's unencumbered by the design = decisions and assumptions of an existing protocol (PANA).=20 Was there any other concern leading to your above statement? Alper On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: > 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >=20 > YES >=20 > 2) Could you *live with* PANA? If not, state reason you would object. >=20 > Yes, but we really rather not use PANA. See below... >=20 > 3) If you said yes to both 1 and 2, but have a strong preference = between the two, which approach do you prefer and why? >=20 > We strongly prefer EAP-in-PCP for several reasons: >=20 > * PANA, as we understand it, is not mobile-friendly. It requires the = PCP client to *always* have an authenticated session active and that is = wasteful on mobile clients when the authentication rekey interval is = much shorter than the mapping lifetime. Margaret Wasserman captured this = in slides 13 and 14 of her presentation = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We = believe the *client* should decide when to authenticate (because it = needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption.=20 >=20 > We understand that a PCP server may need to send a message to the = client when no authenticated session is active. If no authenticated = session is active then we prefer the server send an UN-authenticated = "call home" message directing the client to authenticate and then the = server can send its messages over the authenticated channel. We = recognize an attacker can induce the client to connect to the server by = forging an unauthenticated "call home" message. But, having done that, = the client can ignore subsequent forged call home messages because it = will already have an authenticated session. Worse case, an attacker = can't make EAP-in-PCP consume any more client resources than PANA does = because PANA requires the client to always have an authenticated session = available. >=20 > * PANA requires more server side resources. The authentication = protocol should efficiently support 100,000's of clients on a large PCP = server. Why should the server continuously maintain authenticated = sessions with *every* client? Clients using 24 hour mapping lifetimes = can be served by short authentication key lifetime like, for example, 5 = minutes. Let the client connect, authenticate, program the mappings, and = then let the authenticated session expire. Rinse and repeat in 24 = hours,. Client-driven authentication via EAP-in-PCP requires less = resources on the server because the server can discard the authenticated = session state once the key lifetime expires. >=20 > There was some discussion that PANA is preferable to EAP-in-PCP = because it supports "liveness testing". We don't believe liveness = testing is useful when the server resources consumed, per client, are = PCP mappings. Checking the liveness of 100,000 clients is much more = resource intensive on the server than just keeping the client's mappings = around until they expire naturally at the end of their lifetime. In = short, we believe EAP-in-PCP will scale better on the server than PANA. >=20 > * We believe the decision to use EAP-in-PCP vs. PANA is a choice = between designing and implementing an EAP-in-PCP transport that is = tailored for PCP versus adapting an existing protocol (PANA) to fit the = needs of PCP. We don't think implementing an EAP-in-PCP transport is = difficult so we prefer it over PANA. EAP-in-PCP provides a clean slate = that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).=20 >=20 > -Ben McCann >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From rafa@um.es Thu Jul 18 04:45:02 2013 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 EDD8B11E8134 for ; Thu, 18 Jul 2013 04:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.659 X-Spam-Level: X-Spam-Status: No, score=-5.659 tagged_above=-999 required=5 tests=[AWL=0.940, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOMGSOfdYTdO for ; Thu, 18 Jul 2013 04:44:57 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 29AFD11E8132 for ; Thu, 18 Jul 2013 04:44:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 5431253820; Thu, 18 Jul 2013 13:44:46 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Gx6Nm-aoWciy; Thu, 18 Jul 2013 13:44:45 +0200 (CEST) Received: from inf-205-162.inf.um.es (inf-205-162.inf.um.es [155.54.205.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id 0915A5366A; Thu, 18 Jul 2013 13:44:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Rafa Marin Lopez In-Reply-To: <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> Date: Thu, 18 Jul 2013 13:44:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14EC50C8-8F37-4CC1-8409-756429341E1E@um.es> References: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> To: Ben McCann X-Mailer: Apple Mail (2.1283) Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 11:45:02 -0000 Hi Ben:=20 Apart from Alper's clarifications (I agree with them), I would like to = add a few notes as well. >> * PANA, as we understand it, is not mobile-friendly. It requires the = PCP client to *always* have an authenticated session active and that is = wasteful on mobile clients when the authentication rekey interval is = much shorter than the mapping lifetime. Margaret Wasserman captured this = in slides 13 and 14 of her presentation = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We = believe the *client* should decide when to authenticate (because it = needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption.=20 [Rafa] This is incorrect. The PCP client could authenticate and = immediately close PANA session (see PANA-Termination-Request/Answer) and = still keeping the key generated for PCP. Second, in PANA, the client can = decide when to authenticate (sending a PCI message). >>=20 >> We understand that a PCP server may need to send a message to the = client when no authenticated session is active. If no authenticated = session is active then we prefer the server send an UN-authenticated = "call home" message directing the client to authenticate and then the = server can send its messages over the authenticated channel. We = recognize an attacker can induce the client to connect to the server by = forging an unauthenticated "call home" message. But, having done that, = the client can ignore subsequent forged call home messages because it = will already have an authenticated session. Worse case, an attacker = can't make EAP-in-PCP consume any more client resources than PANA does = because PANA requires the client to always have an authenticated session = available. [Rafa] Again, this is incorrect. See my comment above about = PANA-Termination-Request/Answer. >>=20 >> * PANA requires more server side resources. The authentication = protocol should efficiently support 100,000's of clients on a large PCP = server. Why should the server continuously maintain authenticated = sessions with *every* client? Clients using 24 hour mapping lifetimes = can be served by short authentication key lifetime like, for example, 5 = minutes. Let the client connect, authenticate, program the mappings, and = then let the authenticated session expire. Rinse and repeat in 24 = hours,. Client-driven authentication via EAP-in-PCP requires less = resources on the server because the server can discard the authenticated = session state once the key lifetime expires. [Rafa] Also incorrect. PANA termination does the job. >>=20 >> There was some discussion that PANA is preferable to EAP-in-PCP = because it supports "liveness testing". We don't believe liveness = testing is useful when the server resources consumed, per client, are = PCP mappings. Checking the liveness of 100,000 clients is much more = resource intensive on the server than just keeping the client's mappings = around until they expire naturally at the end of their lifetime. In = short, we believe EAP-in-PCP will scale better on the server than PANA. [Rafa] Liveness testing is something not mandatory in PANA.=20 >>=20 >> * We believe the decision to use EAP-in-PCP vs. PANA is a choice = between designing and implementing an EAP-in-PCP transport that is = tailored for PCP versus adapting an existing protocol (PANA) to fit the = needs of PCP. We don't think implementing an EAP-in-PCP transport is = difficult so we prefer it over PANA. EAP-in-PCP provides a clean slate = that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).=20 [Rafa] You may agree with me that this pure speculation. However, as = founder of OpenPANA project (http://sourceforge.net/projects/openpana/) = I can speak on facts. We have been able to implement a PANA client in a = sensor node and to install PAA in a small wireless router. I have given, = a couple of times in this list, implementation information about lines = of source code.=20 Moreover, we have made the effort and presented in this WG the results = of PCP-PANA integration with two different open source PANA = implementations (OpenPANA and CPANA): http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 However, I am still waiting for seeing anything like this in EAP-in-PCP. Best Regards. >>=20 >> -Ben McCann >>=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 ------------------------------------------------------- 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 tireddy@cisco.com Thu Jul 18 06:16:54 2013 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 518B111E813B for ; Thu, 18 Jul 2013 06:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usMJonmiTgl2 for ; Thu, 18 Jul 2013 06:16:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 415C911E8140 for ; Thu, 18 Jul 2013 06:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46029; q=dns/txt; s=iport; t=1374153404; x=1375363004; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JnoBCFxXfXte32gIISJN7GszSwHWiIVMjojxlXENnIs=; b=jUDuCwul8NBf9uxmazLrst3CoKXXNQSQmKgzY/dEgXzU1aif+A+0CUhu ewiMuoczD91FWaDEwdEVofxrWhVGG+3hYJKaOHosg1dIGBeK5yHiqqBsN Wbip/ZyYTkOZLhoz9rgLbZ/c66PMG6h5WlBrVW+nUKhddD1zbiM/PaKQT Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYFANno51GtJXG+/2dsb2JhbABRCYJCRDVQuAeIPIEMFnSCJAEBAQEDAQEBJAZBCwwEAgEIEQQBAQsWAQYHJwsUCQgCBA4FCBOHdQy2Uo5UgQotBAYBBoMIbgOBTZc5kCSDEoFqJBw X-IronPort-AV: E=Sophos;i="4.89,693,1367971200"; d="scan'208,217";a="236511747" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jul 2013 13:16:43 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6IDGg5R003859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 13:16:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 08:16:42 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOgryVRJrEKluwhkGxicRNVT19rJlpENsAgAAZ5wCAABmpgIAAsyPggABySYCAAFaSgA== Date: Thu, 18 Jul 2013 13:16:41 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9C776@xmb-rcd-x10.cisco.com> References: <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C327@xmb-rcd-x10.cisco.com> <3F1B99E5-B6A0-4149-A58E-0A80838874C1@yegin.org> In-Reply-To: <3F1B99E5-B6A0-4149-A58E-0A80838874C1@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.48.187] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B9C776xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 13:16:54 -0000 --_000_913383AAA69FF945B8F946018B75898A14B9C776xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, July 18, 2013 1:37 PM To: Tirumaleswar Reddy (tireddy) Cc: pcp@ietf.org Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Tiru, I'm talking about "public WiFi hotspot". Like in coffee shops. The PCP proxy and the PCP server are either owned by the same ISP, or two s= eparate business entities. The users who attach to the hotspot are all distinct subscribers with disti= nct service plans. This is different than how all members of my house appea= rs to the ISP, or all employees appears to the enterprise network administr= ation. So, the PCP service provided to each user may differ. Maybe not all users a= re allowed to control some certain ports. For PCP server to be able to act= based on the Id of the users, it needs to know who they are as the request= s are proxies by the PCP proxy. [TR] If the PCP Proxy and PCP server belong to the same ISP, why can't the PCP P= roxy itself enforce the subscriber-based policy ? I do not understand why PCP Proxy cannot enforce identity-based policies fo= r PCP, if you could explain or point to more details how the topology looks= like ?, How PCP Auth works in this use with PCP proxy works in this use ca= se ? it will help. Thanks and Regards, --Tiru. Alper On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tireddy) wrote: From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, July 17, 2013 8:07 PM To: Prashanth Patil (praspati) Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) For the home gateway case, yes I'd think so. Could we not apply PCP proxy case to public WiFi hotspots? There in that ca= se the terminals attaching to the AP are distinct subscribers. I did not get the use case, though there are distinct subscribers attached = to the WLC (MAG), wouldn't WLC act as PCP Proxy and communicate with the PC= P Server in ISP to which it's a single subscriber. This looks just like Enterprise deployment where there are multiple users (= similar to distinct subscribers attached to AP) communicating with the PCP = server in the Enterprise Network, the PCP server in the campus would act as= PCP proxy communicating with the ISP (PCP Server) to which it's a single s= ubscriber. --Tiru. Alper On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote: Hi Alper, In the example below, wont the ISP consider all users behind the home route= r as a single subscriber and not differentiate among individual users? Esse= ntially, the PCP Server would treat the proxy (i.e the home router) as a si= ngle subscriber. -Prashanth On 17/07/13 5:02 PM, "Alper Yegin" > wrote: If the PCP server wants to provide some sort of differentiated service to t= he subscribers (e.g., different mapping lifetime), then it needs to know th= e authenticated ID of the subscriber. Alper On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, July 17, 2013 12:24 PM To: Prashanth Patil (praspati) Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. [TR] Why would the PCP server need to know the authentication ID of the client. = For example Home network; Alice (PCP client) -> Home Router (PCP Proxy) -= > ISP (PCP Server) Why would PCP Server in ISP care about the authentication ID of Alice ? --Tiru. Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_913383AAA69FF945B8F946018B75898A14B9C776xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 

Please see inline [TR]

 

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Thursday, July 18, 2013 1:37 PM
To: Tirumaleswar Reddy (tireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

Tiru,

 

I'm talking about "public WiFi hotspot". L= ike in coffee shops.

The PCP proxy and the PCP server are either owned by= the same ISP, or two separate business entities.

The users who attach to the hotspot are all distinct= subscribers with distinct service plans. This is different than how all me= mbers of my house appears to the ISP, or all employees appears to the enter= prise network administration. 

So, the PCP service provided to each user may differ= . Maybe not all users are allowed to control some certain ports.  For = PCP server to be able to act based on the Id of the users, it needs to know= who they are as the requests are proxies by the PCP proxy.

 

[TR]

 

If the PCP Proxy and PCP server belong to the same ISP, why = can’t the PCP Proxy itself enforce the subscriber-based policy ?=

I do not understand why PCP Proxy cannot enforce identity-ba= sed policies for PCP, if you could explain or point to more details how the= topology looks like ?, How PCP Auth works in this use with PCP proxy works in this use case ? = it will help.

 

Thanks and Regards,

--Tiru.

 

Alper

 

 

 

 

 

 

On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tir= eddy) wrote:



 

 

For the home gateway case, yes I'd think so.

Could we not apply PCP proxy case to public WiFi hot= spots? There in that case the terminals attaching to the AP are distinct su= bscribers.

 

I did not get the use case, though there are distinct subscr= ibers attached to the WLC (MAG), wouldn’t WLC act as PCP Proxy and co= mmunicate with the PCP Server in ISP to which it’s a single subscriber.

 

This looks just like Enterprise deployment where there are m= ultiple users (similar to distinct subscribers attached to AP) communicatin= g with the PCP server in the Enterprise Network, the PCP server in the campus would act as PCP p= roxy communicating with the ISP (PCP Server) to which it’s a single s= ubscriber.

 

--Tiru.

 

Alper

 

 

 

On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspa= ti) wrote:




Hi Alper,

In the example below, wont the ISP consider all users behind t= he home router as a single subscriber and not differentiate among individua= l users? Essentially, the PCP Server would treat the proxy (i.e the home router) as a single sub= scriber.

 

-Prashanth

 

 

If the PCP server wants to provide some sort of differentiated= service to the subscribers (e.g., different mapping lifetime), then it nee= ds to know the authenticated ID of the subscriber.

 

Alper

 

 

On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wro= te:




Please see inline [TR]

 

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Wednesday, J= uly 17, 2013 12:24 PM
To: Prashanth Pati= l (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: [pcp] Pro= xy security (was Re: CONSENSUS CALL on PCP security)

 =

Hi Prashanth,

 =





I'm not sure if enough thought went into the PCP Proxy securit= y. As much as I'd love to be DONE! with this discussion, I also want to mak= e sure people feel comfortable having thought all aspects around the proxy use. For (very imp= ortant) example, what kind of security associations are needed for securing= the proxy use: An SA btw client and server, an SA btw client and proxy, an= SA btw proxy and server -- which combinations of these are needed?

 

We've included this in the updated version o= f auth req:

 

REQ-9: A PCP proxy that modifies PCP messages SHOULD have the<= /span>

ability to independently authenticate with the PCP client and = PCP

server. The presence of a PCP proxy hence requires two separat= ely

authenticates SAs. As a consequence, the PCP proxy:=

 

A. MUST be able to validate message integrity of PCP messages<= /span>

from the PCP server and client respectively.

 

B. MUST be able to ensure message integrity after updating the=

PCP message for cases described in sections 6 of ietf-pcp= -proxy.

 

The PCP proxy MUST also permit authentication on only one side= of

the proxy. For example, a customer premises host may not

authenticate with the PCP proxy but the PCP proxy may authenti= cate

with the PCP server.

 

 =

 =

So:

 =

- We have two types of S= As. One between the client and the proxy, another between the proxy and the= server.

- None of them are manda= tory to use.

 =

For each one that needs = to be used, we need to perform authentication between the end-points. =

(e.g., between client an= d proxy).

 =

So, in a way, we are dea= ling with security in two independent parts; client to proxy, and proxy to = server. 

They are totally segrega= ted from security perspective. 

 =

 =

Right?=

 =

Hmm, one thing: The serv= er may need to know the authenticated ID of the client. Since it's not part= of the client authentication, it won't know that value readily. So, we may= need to define an option to carry that piece of information from the proxy to the server.

 

[TR]

 

Why would the PCP server need to know the authentication ID = of the client. For example Home network;   Alice (PCP client) -&g= t; Home Router (PCP Proxy) -> ISP (PCP Server)

Why would PCP Server in ISP care about the authentication ID= of Alice ?

 

--Tiru.

 =

Alper<= /p>

 =

 =

 =





-Prashanth

 

Then we need to talk about how we dynamically create those usi= ng any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:

 

-----Original Message-----

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 10:51 PM

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS CALL on PCP security<= /o:p>

Hi Dave,

In the poll when you refer to PANA, please clarify the draft y= ou are referring

--Tiru.

The question is intentionally agnostic as this is about a gene= ral approach,

not which specific implementation.  If it helps, you= can interpret the

answer as "which of the two you think is better".

If the consensus is PANA rather than direct EAP-in-PCP, then w= e could

ask as a follow-up question which of the two we should go with= . If

you'd like to include your answer to that now though, feel fre= e to

include that in your response to the call.

-Dave

_______________________________________________

pcp mailing list

 

_______________________________________________

pcp mailing list

 

 

 

--_000_913383AAA69FF945B8F946018B75898A14B9C776xmbrcdx10ciscoc_-- From yoshihiro.ohba@toshiba.co.jp Thu Jul 18 06:40:15 2013 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 5B2CC11E8140 for ; Thu, 18 Jul 2013 06:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.588 X-Spam-Level: X-Spam-Status: No, score=-7.588 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb6thWzNZwT0 for ; Thu, 18 Jul 2013 06:40: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 4E47111E8149 for ; Thu, 18 Jul 2013 06:40:03 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r6IDdw9J007381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jul 2013 22:39:58 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6IDdwTT009796; Thu, 18 Jul 2013 22:39:58 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 924; Thu, 18 Jul 2013 22:39:58 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6IDdw98009793; Thu, 18 Jul 2013 22:39:58 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r6IDdwj5015162; Thu, 18 Jul 2013 22:39:58 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA15161; Thu, 18 Jul 2013 22:39:57 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r6IDdr06017248; Thu, 18 Jul 2013 22:39:53 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r6IDdqBX024298; Thu, 18 Jul 2013 22:39:52 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.194]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 22:39:52 +0900 From: To: , Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOgrpla3wABna3lECF2TL4pPZxUpln5w+AgAKIlgA= Date: Thu, 18 Jul 2013 13:39:52 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D315F9@tgxml338.toshiba.local> References: <758747A2-EB6E-4581-BDE3-DD7798A77EDF@yegin.org> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.18.89] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D315F9tgxml338toshiba_" MIME-Version: 1.0 Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 13:40:15 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D315F9tgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Tiru, Abstract of pcp-proxy draft says: =1B$B!H=1B(B This document specifies a new PCP functional element denoted as PCP Proxy. The PCP Proxy relays PCP requests received from PCP Clients to upstream PCP Server(s). This function is mandatory when PCP Clients can not be configured with the address of the PCP Server located more than one hop. =1B$B!H=1B(B If this abstract is correct, I interpret that PCP clients only know the PCP= proxy=1B$B!G=1B(Bs address, but the PCP server *can* be the authentication= end-point for the PCP clients. This is similar to the http proxy case whe= re http servers are the authentication end-points for http clients. Having= said that, I think it is a bad idea to mandate PCP proxy to be *the* end-p= oint that authenticates the PCP clients in the proxy case. Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Prash= anth Patil (praspati) Sent: Wednesday, July 17, 2013 4:46 PM To: Alper Yegin Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Alper, On 17/07/13 12:23 PM, "Alper Yegin" > wrote: Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. PRA: Yes, none of them are mandatory, it's currently the prerogative of the= server to mandate authentication. The proxy MUST be able authenticate with= either client or server or both. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? PRA: Right. As far as the client is concerned, the proxy is the PCP server.= The proxy is in turn a client to the upstream PCP server. The two parts sh= ould be independent of each other. Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. PRA: May be, but don=1B$B!G=1B(Bt know why the server would want to know th= e auth-id of a client. -Prashanth Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D315F9tgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 <= /o:p>

Abstract of = pcp-proxy draft says:

 <= /o:p>

=1B$B!H=1B(B=

   This do= cument specifies a new PCP functional element denoted as PCP

   Proxy.&= nbsp; The PCP Proxy relays PCP requests received from PCP Clients

   to upst= ream PCP Server(s).  This function is mandatory when PCP

   Clients= can not be configured with the address of the PCP Server=

   located= more than one hop.

=1B$B!H=1B(B=

 <= /o:p>

If this abst= ract is correct, I interpret that PCP clients only know the PCP proxy=1B$B!= G=1B(Bs address, but the PCP server *can* be the authentication end-point for the PCP clients.  This is similar to the http proxy cas= e where http servers are the authentication end-points for http clients. &n= bsp;Having said that, I think it is a bad idea to mandate PCP proxy to be *= the* end-point that authenticates the PCP clients in the proxy case.

 <= /o:p>

Yoshihiro Oh= ba

 <= /o:p>

 <= /o:p>

 <= /o:p>

From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Prashanth Patil (praspat= i)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

Hi Alper,

 

On 17/07/13 12:23 PM, "Alp= er Yegin" <alper.yegin@yeg= in.org> wrote:

 

Hi Prashanth,=

 



I'm not sure if enough thought = went into the PCP Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfortab= le having thought all aspects around the proxy use. For (very important) ex= ample, what kind of security associations are needed for securing the proxy= use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinatio= ns of these are needed?

 

We've included this in the upda= ted version of auth req:

 

REQ-9: A PCP proxy that modi= fies PCP messages SHOULD have the

ability to independently aut= henticate with the PCP client and PCP

server. The presence of a PC= P proxy hence requires two separately

authenticates SAs. As a cons= equence, the PCP proxy:<= o:p>

 

A. MUST be able to validate = message integrity of PCP messages

from the PCP server and clie= nt respectively.

 

B. MUST be able to ensure me= ssage integrity after updating the

PCP message for cases descri= bed in sections 6 of ietf-pcp-proxy.

 

The PCP proxy MUST also perm= it authentication on only one side of

the proxy. For example, a cu= stomer premises host may not

authenticate with the PCP pr= oxy but the PCP proxy may authenticate

with the PCP server.<= /i>

 

 

 

So:

 

- We have two types of SAs. One= between the client and the proxy, another between the proxy and the server.

- None of them are mandatory to= use.

 

PRA: Yes, none of them are mand= atory, it's currently the prerogative of the server to mandate authentication. The proxy MUST be able authenticate with either client or = server or both.

 

For each one that needs to be u= sed, we need to perform authentication between the end-points. 

(e.g., between client and proxy= ).

 

So, in a way, we are dealing wi= th security in two independent parts; client to proxy, and proxy to server. 

They are totally segregated fro= m security perspective. 

 

Right?

 

PRA: Right. As far as the clien= t is concerned, the proxy is the PCP server. The proxy is in turn a client to the upstream PCP server. The two parts should be independ= ent of each other.

 

Hmm, one thing: The server may = need to know the authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. S= o, we may need to define an option to carry that piece of information from = the proxy to the server.

 

PRA: May be, but don=1B$B!G=1B(= Bt know why the server would want to know the auth-id of a client.

 

-Prashanth 

 

Alper

 

 

 



-Prashanth

 

Then we need to talk about how = we dynamically create those using any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, Da= ve Thaler wrote:

 

-----Original Message-----=

From: Tirumaleswar Reddy (tired= dy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 10:= 51 PM

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS CA= LL on PCP security

Hi Dave,

In the poll when you refer to P= ANA, please clarify the draft you are referring

--Tiru.

The question is intentionally a= gnostic as this is about a general approach,

not which specific implementati= on.  If it helps, you can interpret the

answer as "which of the tw= o you think is better".

If the consensus is PANA rather= than direct EAP-in-PCP, then we could

ask as a follow-up question whi= ch of the two we should go with. If

you'd like to include your answ= er to that now though, feel free to

include that in your response t= o the call.

-Dave

_______________________________= ________________

pcp mailing list

 

_______________________________= ________________

pcp mailing list

 

 

--_000_674F70E5F2BE564CB06B6901FD3DD78B12D315F9tgxml338toshiba_-- From alper.yegin@yegin.org Thu Jul 18 06:43:18 2013 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 8645C11E8133 for ; Thu, 18 Jul 2013 06:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miiIZd7v3In0 for ; Thu, 18 Jul 2013 06:43:13 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0053921E80E7 for ; Thu, 18 Jul 2013 06:43:10 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MDz31-1UveY23shL-00HREp; Thu, 18 Jul 2013 09:43:10 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2811F58E-E98F-425C-A40A-999A27E8CED0" From: Alper Yegin In-Reply-To: <913383AAA69FF945B8F946018B75898A14B9C776@xmb-rcd-x10.cisco.com> Date: Thu, 18 Jul 2013 16:43:04 +0300 Message-Id: References: <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C327@xmb-rcd-x10.cisco.com> <3F1B99E5-B6A0-4149-A58E-0A80838874C1@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C776@xmb-rcd-x10.cisco.com> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:Sf3iLVrLhTYf5fNG8oVf+Lnk3ZV+gKx911oYdHbc9p/ jy8N42Tiesn3FWue61kvDOxctZx1CJ6VeyqNsviceEW7eypXSo F7XgpPVkfA2xdYaBAt7T82A1250lBnRoiKnaa4c2ojR5ntdGUx P1+1RmzdnxqbIM0mdIrfLw60Z6MMNpSEvCHGVK6dhKTC+Aia9R 7+MBuY+5RHKdxNCHDbOoGdKUD8R6dddEhJztZ8Ec3VbXI3GZjJ C7wPN8CyO+wDUckyydkx6MIcF7zsypZ3Lkd085XEyfgLt3wh2S fRNGD+AOWKt08J+BeWuGnQMe7r8bDV45zo3Rqxgs7wYREnwfZ8 kJCd8aLOzmnMHChzOr1iJXnsV/qTaGdkAnB4h6+0SE2vMqVUu+ dQHDo7hG8cFrQ== Cc: "pcp@ietf.org" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 13:43:18 -0000 --Apple-Mail=_2811F58E-E98F-425C-A40A-999A27E8CED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Tiru, I'd expect the PCP proxy to be as transparent and as light-weight as = possible. Therefore, I'd normally expect the policy-based decision be = made and executed on the PCP server.=20 Besides, PCP server is the real end-point consuming requests of the PCP = client. Therefore it is simpler to let the PCP server apply the policy = on its own responses. Btw, can the PCP proxy and the PCP server belong to two separate ISPs? If so, would the PCP server be satisfied if it receives the "user's = authenticated ID", or would it require to authenticate the user itself?=20= Alper =20 On Jul 18, 2013, at 4:16 PM, Tirumaleswar Reddy (tireddy) wrote: > Hi Alper, > =20 > Please see inline [TR] > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Thursday, July 18, 2013 1:37 PM > To: Tirumaleswar Reddy (tireddy) > Cc: pcp@ietf.org > Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) > =20 > Tiru, > =20 > I'm talking about "public WiFi hotspot". Like in coffee shops. > The PCP proxy and the PCP server are either owned by the same ISP, or = two separate business entities. > The users who attach to the hotspot are all distinct subscribers with = distinct service plans. This is different than how all members of my = house appears to the ISP, or all employees appears to the enterprise = network administration.=20 > So, the PCP service provided to each user may differ. Maybe not all = users are allowed to control some certain ports. For PCP server to be = able to act based on the Id of the users, it needs to know who they are = as the requests are proxies by the PCP proxy. > =20 > [TR] > =20 > If the PCP Proxy and PCP server belong to the same ISP, why can=92t = the PCP Proxy itself enforce the subscriber-based policy ? > I do not understand why PCP Proxy cannot enforce identity-based = policies for PCP, if you could explain or point to more details how the = topology looks like ?, How PCP Auth works in this use with PCP proxy = works in this use case ? it will help. > =20 > Thanks and Regards, > --Tiru. > =20 > Alper > =20 > =20 > =20 > =20 > =20 > =20 > On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tireddy) wrote: >=20 >=20 > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, July 17, 2013 8:07 PM > To: Prashanth Patil (praspati) > Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org > Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) > =20 > For the home gateway case, yes I'd think so. > Could we not apply PCP proxy case to public WiFi hotspots? There in = that case the terminals attaching to the AP are distinct subscribers. > =20 > I did not get the use case, though there are distinct subscribers = attached to the WLC (MAG), wouldn=92t WLC act as PCP Proxy and = communicate with the PCP Server in ISP to which it=92s a single = subscriber. > =20 > This looks just like Enterprise deployment where there are multiple = users (similar to distinct subscribers attached to AP) communicating = with the PCP server in the Enterprise Network, the PCP server in the = campus would act as PCP proxy communicating with the ISP (PCP Server) to = which it=92s a single subscriber. > =20 > --Tiru. > =20 > Alper > =20 > =20 > =20 > On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote: >=20 >=20 >=20 > Hi Alper, > In the example below, wont the ISP consider all users behind the home = router as a single subscriber and not differentiate among individual = users? Essentially, the PCP Server would treat the proxy (i.e the home = router) as a single subscriber. > =20 > -Prashanth > =20 > On 17/07/13 5:02 PM, "Alper Yegin" wrote: > =20 > If the PCP server wants to provide some sort of differentiated service = to the subscribers (e.g., different mapping lifetime), then it needs to = know the authenticated ID of the subscriber. > =20 > Alper > =20 > =20 > On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: >=20 >=20 >=20 > Please see inline [TR] > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, July 17, 2013 12:24 PM > To: Prashanth Patil (praspati) > Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) > Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) > =20 > Hi Prashanth, > =20 >=20 >=20 >=20 >=20 > I'm not sure if enough thought went into the PCP Proxy security. As = much as I'd love to be DONE! with this discussion, I also want to make = sure people feel comfortable having thought all aspects around the proxy = use. For (very important) example, what kind of security associations = are needed for securing the proxy use: An SA btw client and server, an = SA btw client and proxy, an SA btw proxy and server -- which = combinations of these are needed? > =20 > We've included this in the updated version of auth req: > =20 > REQ-9: A PCP proxy that modifies PCP messages SHOULD have the > ability to independently authenticate with the PCP client and PCP > server. The presence of a PCP proxy hence requires two separately > authenticates SAs. As a consequence, the PCP proxy: > =20 > A. MUST be able to validate message integrity of PCP messages > from the PCP server and client respectively. > =20 > B. MUST be able to ensure message integrity after updating the > PCP message for cases described in sections 6 of ietf-pcp-proxy. > =20 > The PCP proxy MUST also permit authentication on only one side of > the proxy. For example, a customer premises host may not > authenticate with the PCP proxy but the PCP proxy may authenticate > with the PCP server. > =20 > =20 > =20 > So: > =20 > - We have two types of SAs. One between the client and the proxy, = another between the proxy and the server. > - None of them are mandatory to use. > =20 > For each one that needs to be used, we need to perform authentication = between the end-points.=20 > (e.g., between client and proxy). > =20 > So, in a way, we are dealing with security in two independent parts; = client to proxy, and proxy to server.=20 > They are totally segregated from security perspective.=20 > =20 > =20 > Right? > =20 > Hmm, one thing: The server may need to know the authenticated ID of = the client. Since it's not part of the client authentication, it won't = know that value readily. So, we may need to define an option to carry = that piece of information from the proxy to the server. > =20 > [TR] > =20 > Why would the PCP server need to know the authentication ID of the = client. For example Home network; Alice (PCP client) -> Home Router = (PCP Proxy) -> ISP (PCP Server) > Why would PCP Server in ISP care about the authentication ID of Alice = ? > =20 > --Tiru. > =20 > Alper > =20 > =20 > =20 >=20 >=20 >=20 >=20 > -Prashanth > =20 > Then we need to talk about how we dynamically create those using any = one of these solutions. > =20 > Alper > =20 > =20 > =20 > =20 > =20 > On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: > =20 > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Sent: Monday, July 15, 2013 10:51 PM > To: Dave Thaler; pcp@ietf.org > Subject: RE: [pcp] CONSENSUS CALL on PCP security > Hi Dave, > In the poll when you refer to PANA, please clarify the draft you are = referring > to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or > http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? > --Tiru. > The question is intentionally agnostic as this is about a general = approach, > not which specific implementation. If it helps, you can interpret the > answer as "which of the two you think is better". > If the consensus is PANA rather than direct EAP-in-PCP, then we could > ask as a follow-up question which of the two we should go with. If > you'd like to include your answer to that now though, feel free to > include that in your response to the call. > -Dave > _______________________________________________ > 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 --Apple-Mail=_2811F58E-E98F-425C-A40A-999A27E8CED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Tiru,

I'd expect the PCP = proxy to be as transparent and as light-weight as possible. Therefore, = I'd normally expect the policy-based decision be made and executed on = the PCP server. 
Besides, PCP server is the real = end-point consuming requests of the PCP client. Therefore it is simpler = to let the PCP server apply the policy on its own = responses.

Btw, can the PCP proxy and the PCP = server belong to two separate ISPs?
If so, would the PCP = server be satisfied if it receives the "user's authenticated ID", or = would it require to authenticate the user = itself? 

Alper
 


On Jul 18, 2013, at = 4:16 PM, Tirumaleswar Reddy (tireddy) wrote:

Hi = Alper,
 
From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Thursday, July 18, 2013 = 1:37 PM
To: Tirumaleswar Reddy = (tireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp] Proxy security = (was Re: CONSENSUS CALL on PCP = security)
Tiru,
 
I'm talking about "public WiFi hotspot". Like in coffee = shops.
The PCP proxy and the PCP = server are either owned by the same ISP, or two separate business = entities.
The users who attach to = the hotspot are all distinct subscribers with distinct service plans. = This is different than how all members of my house appears to the ISP, = or all employees appears to the enterprise network = administration. 
So, the PCP = service provided to each user may differ. Maybe not all users are = allowed to control some certain ports.  For PCP server to be able = to act based on the Id of the users, it needs to know who they are as = the requests are proxies by the PCP proxy.
If = the PCP Proxy and PCP server belong to the same ISP, why can=92t the PCP = Proxy itself enforce the subscriber-based policy = ?
I do not = understand why PCP Proxy cannot enforce identity-based policies for PCP, = if you could explain or point to more details how the topology looks = like ?, How PCP Auth works in this use with PCP proxy works in this use = case ? it will help.
 
Thanks and = Regards,
On Jul 18, 2013, at 9:37 = AM, Tirumaleswar Reddy (tireddy) wrote:


Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 = 8:07 PM
To: Prashanth Patil = (praspati)
Cc: Tirumaleswar Reddy = (tireddy); pcp@ietf.org
Subject: Re: [pcp] Proxy security = (was Re: CONSENSUS CALL on PCP = security)
 
For the home gateway case, yes I'd think = so.
Could we not apply PCP = proxy case to public WiFi hotspots? There in that case the terminals = attaching to the AP are distinct = subscribers.
I did not get the use case, though there are = distinct subscribers attached to the WLC (MAG), wouldn=92t WLC act as = PCP Proxy and communicate with the PCP Server in ISP to which it=92s a = single subscriber.
This looks just like Enterprise deployment where = there are multiple users (similar to distinct subscribers attached to = AP) communicating with the PCP server in the Enterprise Network, the PCP = server in the campus would act as PCP proxy communicating with the ISP = (PCP Server) to which it=92s a single = subscriber.
 
 
Alper
 
 
 
On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) = wrote:
Hi = Alper,
In the example below, wont the ISP consider = all users behind the home router as a single subscriber and not = differentiate among individual users? Essentially, the PCP Server would = treat the proxy (i.e the home router) as a single = subscriber.
On 17/07/13 5:02 PM, "Alper Yegin" <alper.yegin@yegin.org> = wrote:
If the PCP server wants to provide some sort = of differentiated service to the subscribers (e.g., different mapping = lifetime), then it needs to know the authenticated ID of the = subscriber.
On Jul 17, 2013, at 10:09 AM, Tirumaleswar = Reddy (tireddy) wrote:
Please see inline = [TR]
From:Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 = 12:24 PM
To: Prashanth Patil = (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy = (tireddy)
Subject: [pcp] Proxy security (was = Re: CONSENSUS CALL on PCP = security)
Hi = Prashanth,
I'm not sure if enough = thought went into the PCP Proxy security. As much as I'd love to be = DONE! with this discussion, I also want to make sure people feel = comfortable having thought all aspects around the proxy use. For (very = important) example, what kind of security associations are needed for = securing the proxy use: An SA btw client and server, an SA btw client = and proxy, an SA btw proxy and server -- which combinations of these are = needed?
 
We've included this in the updated version of auth = req:
 
REQ-9: A PCP proxy that modifies = PCP messages SHOULD have = the
ability to independently = authenticate with the PCP client and = PCP
server. The presence of a PCP proxy = hence requires two = separately
authenticates SAs. As a = consequence, the PCP = proxy:
 
A. MUST be able to validate message = integrity of PCP = messages
from the PCP server and client = respectively.
=
 
B. MUST be able to ensure message = integrity after updating = the
PCP message for cases described in = sections 6 = of ietf-pcp-proxy.
=
 
The PCP proxy MUST also permit = authentication on only one side = of
the proxy. For example, a customer = premises host may = not
authenticate with the PCP proxy but = the PCP proxy may = authenticate
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman', serif; ">with the PCP = server.
=
- We have two types of = SAs. One between the client and the proxy, another between the proxy and = the server.
- None of them are = mandatory to = use.
For each one that needs = to be used, we need to perform authentication between the = end-points. 
=
(e.g., between client = and proxy).
So, in a way, we are = dealing with security in two independent parts; client to proxy, and = proxy to = server. 
They are totally = segregated from security = perspective. 
Hmm, one thing: The = server may need to know the authenticated ID of the client. Since it's = not part of the client authentication, it won't know that value readily. = So, we may need to define an option to carry that piece of information = from the proxy to the = server.
Why would the PCP server need to = know the authentication ID of the client. For example Home = network;   Alice (PCP client) -> Home Router (PCP Proxy) = -> ISP (PCP Server)
Why would PCP Server in ISP care = about the authentication ID of Alice = ?
Then we need to talk about how we dynamically create those = using any one of these = solutions.
On Jul 16, 2013, at 7:50 PM, Dave Thaler = wrote:
-----Original = Message-----
From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
<= div>
Sent: Monday, July 15, = 2013 10:51 = PM
To: Dave Thaler; pcp@ietf.org
Subject: RE: [pcp] CONSENSUS CALL on PCP = security
Hi = Dave,
In the poll when you refer to PANA, please = clarify the draft you are = referring
to  or
To: "yoshihiro.ohba@toshiba.co.jp" , "alper.yegin@yegin.org" Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOg7xOgyVOTGpo0E674JzHPKIxG5lrOpsA Date: Thu, 18 Jul 2013 15:11:12 +0000 Message-ID: In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D315F9@tgxml338.toshiba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [173.39.67.75] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE33160xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 15:11:28 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE33160xmbrcdx07ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Yoshihiro, Although the abstract says that, I don=92t think the intent is for the PCP = Proxy to just be a relay agent. It is clear from other sections of the draf= t that the proxy is indeed a server and needs to modify fields (albeit mini= mal) before forwarding them to the actual server. This implies two independ= ent authentications need to happen. -Prashanth On 18/07/13 7:09 PM, "yoshihiro.ohba@toshiba.co.jp" > wrote: Hi Tiru, Abstract of pcp-proxy draft says: =93 This document specifies a new PCP functional element denoted as PCP Proxy. The PCP Proxy relays PCP requests received from PCP Clients to upstream PCP Server(s). This function is mandatory when PCP Clients can not be configured with the address of the PCP Server located more than one hop. =93 If this abstract is correct, I interpret that PCP clients only know the PCP= proxy=92s address, but the PCP server *can* be the authentication end-poin= t for the PCP clients. This is similar to the http proxy case where http s= ervers are the authentication end-points for http clients. Having said tha= t, I think it is a bad idea to mandate PCP proxy to be *the* end-point that= authenticates the PCP clients in the proxy case. Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Prashanth Patil (praspati) Sent: Wednesday, July 17, 2013 4:46 PM To: Alper Yegin Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Alper, On 17/07/13 12:23 PM, "Alper Yegin" > wrote: Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. PRA: Yes, none of them are mandatory, it's currently the prerogative of the= server to mandate authentication. The proxy MUST be able authenticate with= either client or server or both. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? PRA: Right. As far as the client is concerned, the proxy is the PCP server.= The proxy is in turn a client to the upstream PCP server. The two parts sh= ould be independent of each other. Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. PRA: May be, but don=92t know why the server would want to know the auth-id= of a client. -Prashanth Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_B235506D63D65E43B2E40FD27715372E1CE33160xmbrcdx07ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Yoshihiro,
Although the abstract says that, I don=92t think the intent is for the= PCP Proxy to just be a relay agent. It is clear from other sections of the= draft that the proxy is indeed a server and needs to modify fields (albeit= minimal) before forwarding them to the actual server. This implies two independent authentications need to ha= ppen.

-Prashanth

Hi Tiru,

 

Abstract of pcp-proxy= draft says:

 

=93=

   This document specifies a new PCP func= tional element denoted as PCP

   Proxy.  The PCP Proxy relays PCP = requests received from PCP Clients

   to upstream PCP Server(s).  This = function is mandatory when PCP

   Clients can not be configured with the= address of the PCP Server

   located more than one hop.<= /span>

=93=

 

If this abstract is c= orrect, I interpret that PCP clients only know the PCP proxy=92s address, b= ut the PCP server *can* be the authentication end-point for the PCP clients.  This is similar to the http proxy cas= e where http servers are the authentication end-points for http clients. &n= bsp;Having said that, I think it is a bad idea to mandate PCP proxy to be *= the* end-point that authenticates the PCP clients in the proxy case.

 

Yoshihiro Ohba

 

 

 

From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

Hi Alper,

 

On 17/07/13 12:23 PM, "Alper Yegin" &= lt;alper.yegin@yegin.org> wrote:

 

Hi Prashanth,

 



I'm not sure if enough thought went into the PC= P Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfor= table having thought all aspects around the proxy use. For (very important)= example, what kind of security associations are needed for securing the pr= oxy use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinatio= ns of these are needed?

 

We've included this in the updated version of a= uth req:

 

REQ-9: A PCP proxy that modifies PCP message= s SHOULD have the

ability to independently authenticate with t= he PCP client and PCP<= /p>

server. The presence of a PCP proxy hence re= quires two separately<= /p>

authenticates SAs. As a consequence, the PCP= proxy:

 

A. MUST be able to validate message integrit= y of PCP messages

from the PCP server and client respectively.=

 

B. MUST be able to ensure message integrity = after updating the

PCP message for cases described in sections = 6 of ietf-pcp-proxy.

 

The PCP proxy MUST also permit authenticatio= n on only one side of<= /p>

the proxy. For example, a customer premises = host may not

authenticate with the PCP proxy but the PCP = proxy may authenticate=

with the PCP server.

 

 

 

So:

 

- We have two types of SAs. One between the cli= ent and the proxy, another between the proxy and the server.

- None of them are mandatory to use.=

 

PRA: Yes, none of them are mandatory, it's curr= ently the prerogative of the server to mandate authentication. The proxy MUST be able authenticate with either client or = server or both.

 

For each one that needs to be used, we need to = perform authentication between the end-points. 

(e.g., between client and proxy).

 

So, in a way, we are dealing with security in t= wo independent parts; client to proxy, and proxy to server. 

They are totally segregated from security persp= ective. 

 

Right?

 

PRA: Right. As far as the client is concerned, = the proxy is the PCP server. The proxy is in turn a client to the upstream PCP server. The two parts should be indep= endent of each other.

 

Hmm, one thing: The server may need to know the= authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. S= o, we may need to define an option to carry that piece of information from = the proxy to the server.

 

PRA: May be, but don=92t know why the server wo= uld want to know the auth-id of a client.

 

-Prashanth 

 

Alper

 

 

 



-Prashanth

 

Then we need to talk about how we dynamically c= reate those using any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:=

 

-----Original Message-----

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 10:51 PM=

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS CALL on PCP securi= ty

Hi Dave,

In the poll when you refer to PANA, please clar= ify the draft you are referring

--Tiru.

The question is intentionally agnostic as this = is about a general approach,

not which specific implementation.  I= f it helps, you can interpret the

answer as "which of the two you think is b= etter".

If the consensus is PANA rather than direct EAP= -in-PCP, then we could

ask as a follow-up question which of the two we= should go with. If

you'd like to include your answer to that now t= hough, feel free to

include that in your response to the call.=

-Dave

_______________________________________________=

pcp mailing list

 

_______________________________________________=

pcp mailing list

 

 

--_000_B235506D63D65E43B2E40FD27715372E1CE33160xmbrcdx07ciscoc_-- From yoshihiro.ohba@toshiba.co.jp Thu Jul 18 08:30:34 2013 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 A081121E8128 for ; Thu, 18 Jul 2013 08:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.688 X-Spam-Level: X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXQuAElYhzLZ for ; Thu, 18 Jul 2013 08:30:15 -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 4E38E21E811E for ; Thu, 18 Jul 2013 08:29:51 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r6IFTjwH009065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 00:29:45 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6IFTjAI001847; Fri, 19 Jul 2013 00:29:45 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 21; Fri, 19 Jul 2013 00:29:44 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6IFTiD6001844; Fri, 19 Jul 2013 00:29:44 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r6IFTipO004451; Fri, 19 Jul 2013 00:29:44 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id AAA04449; Fri, 19 Jul 2013 00:29:44 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r6IFTiS3029182; Fri, 19 Jul 2013 00:29:44 +0900 (JST) Received: from TGXML330.toshiba.local by toshiba.co.jp id r6IFThji020501; Fri, 19 Jul 2013 00:29:43 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.194]) by TGXML330.toshiba.local ([133.199.60.204]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 00:29:43 +0900 From: To: , Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOgrpla3wABna3lECF2TL4pPZxUpln5w+AgAKIlgD//4YaAIAAmElw Date: Thu, 18 Jul 2013 15:29:43 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D31747@tgxml338.toshiba.local> References: <674F70E5F2BE564CB06B6901FD3DD78B12D315F9@tgxml338.toshiba.local> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.54] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D31747tgxml338toshiba_" MIME-Version: 1.0 Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 15:30:34 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D31747tgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Prashanth, From: Prashanth Patil (praspati) [mailto:praspati@cisco.com] Sent: Friday, July 19, 2013 12:11 AM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ); alper.yegin@yegin.org Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Yoshihiro, Although the abstract says that, I don=1B$B!G=1B(Bt think the intent is for= the PCP Proxy to just be a relay agent. It is clear from other sections of= the draft that the proxy is indeed a server and needs to modify fields (al= beit minimal) before forwarding them to the actual server. This implies two= independent authentications need to happen. [YO] I don=1B$B!G=1B(Bt understand your logic here. Even an http proxy can = modify http requests (e.g., X-Forwarded-For header), and an http server can= still authenticate http clients behind the proxy. Yoshihiro Ohba -Prashanth On 18/07/13 7:09 PM, "yoshihiro.ohba@toshiba.co.jp" > wrote: Hi Tiru, Abstract of pcp-proxy draft says: =1B$B!H=1B(B This document specifies a new PCP functional element denoted as PCP Proxy. The PCP Proxy relays PCP requests received from PCP Clients to upstream PCP Server(s). This function is mandatory when PCP Clients can not be configured with the address of the PCP Server located more than one hop. =1B$B!H=1B(B If this abstract is correct, I interpret that PCP clients only know the PCP= proxy=1B$B!G=1B(Bs address, but the PCP server *can* be the authentication= end-point for the PCP clients. This is similar to the http proxy case whe= re http servers are the authentication end-points for http clients. Having= said that, I think it is a bad idea to mandate PCP proxy to be *the* end-p= oint that authenticates the PCP clients in the proxy case. Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Prashanth Patil (praspati) Sent: Wednesday, July 17, 2013 4:46 PM To: Alper Yegin Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Alper, On 17/07/13 12:23 PM, "Alper Yegin" > wrote: Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. PRA: Yes, none of them are mandatory, it's currently the prerogative of the= server to mandate authentication. The proxy MUST be able authenticate with= either client or server or both. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? PRA: Right. As far as the client is concerned, the proxy is the PCP server.= The proxy is in turn a client to the upstream PCP server. The two parts sh= ould be independent of each other. Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. PRA: May be, but don=1B$B!G=1B(Bt know why the server would want to know th= e auth-id of a client. -Prashanth Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D31747tgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Prashanth= ,

 <= /o:p>

 <= /o:p>

From: Prashanth Patil (praspati) [mailto:praspati@cisco.com]
Sent: Friday, July 19, 2013 12:11 AM
To: ohba yoshihiro(=1B$BB= g>l=1B(B =1B$B5AMN=1B(B =1B$B!{=1B(B=1B$B#R#D#C=1B(B=1B$B""=1B(B= =1B$B#N#S#L=1B(B); alper.yegin@yegin.org
Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

Hi Yoshihiro,=

Although the abstract says that= , I don=1B$B!G=1B(Bt think the intent is for the PCP Proxy to just be a relay agent. It is clear from other sections of the draft that the proxy i= s indeed a server and needs to modify fields (albeit minimal) before forwar= ding them to the actual server. This implies two independent authentication= s need to happen.

[YO] I don=1B$B!G=1B(Bt understand your logic here. = Even an http proxy can modify http requests (e.g., X-Forwarded-For header), and an http server can still authenticate http clients behind the proxy.

 

Yoshihiro Ohba

 

-Prashanth

 

 

Hi Tiru,

 

Abstract of pcp-proxy draft say= s:

 

=1B$B!H=1B(B

   This document = specifies a new PCP functional element denoted as PCP

   Proxy.  T= he PCP Proxy relays PCP requests received from PCP Clients

   to upstream PC= P Server(s).  This function is mandatory when PCP

   Clients can no= t be configured with the address of the PCP Server

   located more t= han one hop.

=1B$B!H=1B(B

 

If this abstract is correct, I = interpret that PCP clients only know the PCP proxy=1B$B!G=1B(Bs address, but the PCP server *can* be the authentication end-point for the PC= P clients.  This is similar to the http proxy case where http servers = are the authentication end-points for http clients.  Having said that,= I think it is a bad idea to mandate PCP proxy to be *the* end-point that authenticates the PCP clients in the pro= xy case.

 

Yoshihiro Ohba

 

 

 

From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)<= /p>

 

Hi Alper,

 

On 17/07/13 12:23 PM, "Alp= er Yegin" <alper.yegin@yeg= in.org> wrote:=

 

Hi Prashanth,

 




I'm not sure if enough thought = went into the PCP Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfortab= le having thought all aspects around the proxy use. For (very important) ex= ample, what kind of security associations are needed for securing the proxy= use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinatio= ns of these are needed?

 

We've included this in the upda= ted version of auth req:<= o:p>

 

REQ-9: A PCP proxy that modi= fies PCP messages SHOULD have the

ability to independently aut= henticate with the PCP client and PCP

server. The presence of a PC= P proxy hence requires two separately

authenticates SAs. As a cons= equence, the PCP proxy:

 

A. MUST be able to validate = message integrity of PCP messages

from the PCP server and clie= nt respectively.=

 

B. MUST be able to ensure me= ssage integrity after updating the

PCP message for cases descri= bed in sections 6 of ietf-pcp-proxy.

 

The PCP proxy MUST also perm= it authentication on only one side of

the proxy. For example, a cu= stomer premises host may not

authenticate with the PCP pr= oxy but the PCP proxy may authenticate

with the PCP server.<= /i>

 

 

 

So:

 

- We have two types of SAs. One= between the client and the proxy, another between the proxy and the server.

- None of them are mandatory to= use.

 

PRA: Yes, none of them are mand= atory, it's currently the prerogative of the server to mandate authentication. The proxy MUST be able authenticate with either client or = server or both.

 

For each one that needs to be u= sed, we need to perform authentication between the end-points. =

(e.g., between client and proxy= ).

 

So, in a way, we are dealing wi= th security in two independent parts; client to proxy, and proxy to server. 

They are totally segregated fro= m security perspective. 

 

Right?

 

PRA: Right. As far as the clien= t is concerned, the proxy is the PCP server. The proxy is in turn a client to the upstream PCP server. The two parts should be independ= ent of each other.

 

Hmm, one thing: The server may = need to know the authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. S= o, we may need to define an option to carry that piece of information from = the proxy to the server.<= o:p>

 

PRA: May be, but don=1B$B!G=1B(= Bt know why the server would want to know the auth-id of a client.

 

-Prashanth 

 

Alper

 

 

 




-Prashanth

 

Then we need to talk about how = we dynamically create those using any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, Da= ve Thaler wrote:

 

-----Original Message-----

From: Tirumaleswar Reddy (tired= dy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 10:= 51 PM

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS CA= LL on PCP security

Hi Dave,

In the poll when you refer to P= ANA, please clarify the draft you are referring

--Tiru.

The question is intentionally a= gnostic as this is about a general approach,

not which specific implementati= on.  If it helps, you can interpret the

answer as "which of the tw= o you think is better".

If the consensus is PANA rather= than direct EAP-in-PCP, then we could

ask as a follow-up question whi= ch of the two we should go with. If

you'd like to include your answ= er to that now though, feel free to

include that in your response t= o the call.

-Dave

_______________________________= ________________

pcp mailing list

 

_______________________________= ________________

pcp mailing list

 

 

--_000_674F70E5F2BE564CB06B6901FD3DD78B12D31747tgxml338toshiba_-- From tireddy@cisco.com Thu Jul 18 08:50:02 2013 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 AEF7811E8176 for ; Thu, 18 Jul 2013 08:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK7vQ4zEz0Uf for ; Thu, 18 Jul 2013 08:49:57 -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 D960411E8171 for ; Thu, 18 Jul 2013 08:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56523; q=dns/txt; s=iport; t=1374162597; x=1375372197; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BOnwPpszwPAw6KYciVitdteH8r83ZMM5Eul69Br83lU=; b=PUZKHznWks3WfGV0wHaXi57QKwGZ5PyzfSlGJqcuqPizpZP/5vD3AZh6 b8iRVrp/KsuKsapkRrCX3H5ZayMPtsWgysnB3GbwXC+H438SwjV/5FjDI kgw/g0LYHNo1O/S0Uo4r6SctIHph9fnTTQcI9/PrJazIqtZy4gveRrcLy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYFAOcM6FGtJV2c/2dsb2JhbABRCYJCRDVQuAiIPIERFnSCJAEBAQEDAQEBJAZBCwwEAgEIEQQBAQsWAQYHJwsUCQgCBA4FCBOHdQy2HI5UgQotBAYBBoMIbgOBTZc5kCSDEoFqJBw X-IronPort-AV: E=Sophos;i="4.89,694,1367971200"; d="scan'208,217";a="233501413" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 18 Jul 2013 15:49:56 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6IFntf2032121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 15:49:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 10:49:55 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOgryVRJrEKluwhkGxicRNVT19rJlpENsAgAAZ5wCAABmpgIAAsyPggABySYCAAFaSgIAAB2MA///KVbA= Date: Thu, 18 Jul 2013 15:49:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9C898@xmb-rcd-x10.cisco.com> References: <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C327@xmb-rcd-x10.cisco.com> <3F1B99E5-B6A0-4149-A58E-0A80838874C1@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C776@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.48.187] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B9C898xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 15:50:02 -0000 --_000_913383AAA69FF945B8F946018B75898A14B9C898xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, July 18, 2013 7:13 PM To: Tirumaleswar Reddy (tireddy) Cc: pcp@ietf.org Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Tiru, I'd expect the PCP proxy to be as transparent and as light-weight as possib= le. [TR] Yes, PCP proxy is transparent. But it is acting as PCP server to the c= lient; client does not have to know that the PCP proxy it is communicating = with is acting as PCP proxy to upstream PCP server. Further PCP Proxy is st= ateful it will create NAT mapping etc. In all the PCP proxy scenarios menti= oned in the http://tools.ietf.org/id/draft-ietf-pcp-proxy-03.txt PCP proxy = will update the PCP message from the PCP client before forwarding to the PC= P server; so if the PCP proxy authenticates with the PCP server it must hav= e a separate SA so that it can update the Authenticate Data with the new MA= C. Therefore, I'd normally expect the policy-based decision be made and execut= ed on the PCP server. [TR] In my previous mails we discussed why it is not a problem with Home/En= terprise Networks which would have a PCP Proxy. If you could explain the "P= ublic Wifi Hotspot" use case with more details, it will help us understand = the scenario better. --Tiru. Besides, PCP server is the real end-point consuming requests of the PCP cli= ent. Therefore it is simpler to let the PCP server apply the policy on its = own responses. Btw, can the PCP proxy and the PCP server belong to two separate ISPs? If so, would the PCP server be satisfied if it receives the "user's authent= icated ID", or would it require to authenticate the user itself? Alper On Jul 18, 2013, at 4:16 PM, Tirumaleswar Reddy (tireddy) wrote: Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, July 18, 2013 1:37 PM To: Tirumaleswar Reddy (tireddy) Cc: pcp@ietf.org Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Tiru, I'm talking about "public WiFi hotspot". Like in coffee shops. The PCP proxy and the PCP server are either owned by the same ISP, or two s= eparate business entities. The users who attach to the hotspot are all distinct subscribers with disti= nct service plans. This is different than how all members of my house appea= rs to the ISP, or all employees appears to the enterprise network administr= ation. So, the PCP service provided to each user may differ. Maybe not all users a= re allowed to control some certain ports. For PCP server to be able to act= based on the Id of the users, it needs to know who they are as the request= s are proxies by the PCP proxy. [TR] If the PCP Proxy and PCP server belong to the same ISP, why can't the PCP P= roxy itself enforce the subscriber-based policy ? I do not understand why PCP Proxy cannot enforce identity-based policies fo= r PCP, if you could explain or point to more details how the topology looks= like ?, How PCP Auth works in this use with PCP proxy works in this use ca= se ? it will help. Thanks and Regards, --Tiru. Alper On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tireddy) wrote: From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, July 17, 2013 8:07 PM To: Prashanth Patil (praspati) Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) For the home gateway case, yes I'd think so. Could we not apply PCP proxy case to public WiFi hotspots? There in that ca= se the terminals attaching to the AP are distinct subscribers. I did not get the use case, though there are distinct subscribers attached = to the WLC (MAG), wouldn't WLC act as PCP Proxy and communicate with the PC= P Server in ISP to which it's a single subscriber. This looks just like Enterprise deployment where there are multiple users (= similar to distinct subscribers attached to AP) communicating with the PCP = server in the Enterprise Network, the PCP server in the campus would act as= PCP proxy communicating with the ISP (PCP Server) to which it's a single s= ubscriber. --Tiru. Alper On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote: Hi Alper, In the example below, wont the ISP consider all users behind the home route= r as a single subscriber and not differentiate among individual users? Esse= ntially, the PCP Server would treat the proxy (i.e the home router) as a si= ngle subscriber. -Prashanth On 17/07/13 5:02 PM, "Alper Yegin" > wrote: If the PCP server wants to provide some sort of differentiated service to t= he subscribers (e.g., different mapping lifetime), then it needs to know th= e authenticated ID of the subscriber. Alper On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, July 17, 2013 12:24 PM To: Prashanth Patil (praspati) Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. [TR] Why would the PCP server need to know the authentication ID of the client. = For example Home network; Alice (PCP client) -> Home Router (PCP Proxy) -= > ISP (PCP Server) Why would PCP Server in ISP care about the authentication ID of Alice ? --Tiru. Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_913383AAA69FF945B8F946018B75898A14B9C898xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 

Please see inline [TR]

 

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Thursday, July 18, 2013 7:13 PM
To: Tirumaleswar Reddy (tireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

Hi Tiru,

 

I'd expect the PCP proxy to be as transparent and as= light-weight as possible.

 

[TR] Yes, PCP proxy is transparent. But it is acting as PCP = server to the client; client does not have to know that the PCP proxy it is= communicating with is acting as PCP proxy to upstream PCP server. Further PCP Proxy is statef= ul it will create NAT mapping etc. In all the PCP proxy scenarios mentioned= in the http://too= ls.ietf.org/id/draft-ietf-pcp-proxy-03.txt PCP proxy will update the PC= P message from the PCP client before forwarding to the PCP server; so if th= e PCP proxy authenticates with the PCP server it must have a separate SA so that it can update the Authentica= te Data with the new MAC.

 

Therefore, I'd normally expect the policy-based deci= sion be made and executed on the PCP server. 

 

[TR] In my previous mails we discussed why it is not a probl= em with Home/Enterprise Networks which would have a PCP Proxy. If you could= explain the “Public Wifi Hotspot” use case with more details, it will help us understand= the scenario better.

 

--Tiru.

 

Besides, PCP server is the real end-point consuming = requests of the PCP client. Therefore it is simpler to let the PCP server a= pply the policy on its own responses.

 

Btw, can the PCP proxy and the PCP server belong to = two separate ISPs?

If so, would the PCP server be satisfied if it recei= ves the "user's authenticated ID", or would it require to authent= icate the user itself? 

 

Alper

 

 

 

 

On Jul 18, 2013, at 4:16 PM, Tirumaleswar Reddy (tir= eddy) wrote:



Hi Alper,

 

Please see inline [TR]

 

From: Alper Yegin [mailto:alper.yegin@yegin.org]=  
Sent: Thursday, Ju= ly 18, 2013 1:37 PM
To: Tirumaleswar R= eddy (tireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp]= Proxy security (was Re: CONSENSUS CALL on PCP security)<= /p>

 

Tiru,

 

I'm talking about "public WiFi hotspot". L= ike in coffee shops.

The PCP proxy and the PCP server are either owned by= the same ISP, or two separate business entities.

The users who attach to the hotspot are all distinct= subscribers with distinct service plans. This is different than how all me= mbers of my house appears to the ISP, or all employees appears to the enter= prise network administration. 

So, the PCP service provided to each user may differ= . Maybe not all users are allowed to control some certain ports.  For = PCP server to be able to act based on the Id of the users, it needs to know= who they are as the requests are proxies by the PCP proxy.

 

[TR]

 

If the PCP Proxy and PCP server belong to the same ISP, why = can’t the PCP Proxy itself enforce the subscriber-based policy ?

I do not understand why PCP Proxy cannot enforce identity-ba= sed policies for PCP, if you could explain or point to more details how the= topology looks like ?, How PCP Auth works in this use with PCP proxy works in this use case ? = it will help.

 

Thanks and Regards,

--Tiru.

 

Alper

 

 

 

 

 

 

On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tir= eddy) wrote:




 

From: Alper Yegin [mailto:alper.yegin@yegin.org]=  
Sent: Wednesday, J= uly 17, 2013 8:07 PM
To: Prashanth Pati= l (praspati)
Cc: Tirumaleswar R= eddy (tireddy); pcp@ietf.org
Subject: Re: [pcp]= Proxy security (was Re: CONSENSUS CALL on PCP security)<= /p>

 

For the home gateway case, yes I'd think so.

Could we not apply PCP proxy case to public WiFi hot= spots? There in that case the terminals attaching to the AP are distinct su= bscribers.

 

I did not get the use case, though there are distinct subscr= ibers attached to the WLC (MAG), wouldn’t WLC act as PCP Proxy and co= mmunicate with the PCP Server in ISP to which it’s a single subscriber.

 

This looks just like Enterprise deployment where there are m= ultiple users (similar to distinct subscribers attached to AP) communicatin= g with the PCP server in the Enterprise Network, the PCP server in the campus would act as PCP p= roxy communicating with the ISP (PCP Server) to which it’s a single s= ubscriber.

 

--Tiru.

 

Alper

 

 

 

On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspa= ti) wrote:





Hi Alper,

In the example below, wont the ISP consider all users behind t= he home router as a single subscriber and not differentiate among individua= l users? Essentially, the PCP Server would treat the proxy (i.e the home router) as a single sub= scriber.

 

-Prashanth

 

On 17/07/13 5:02 PM, "Alper Yegin" <alper.yegin@yegin.org> wrote:

 

If the PCP server wants to provide some sort of differentiated= service to the subscribers (e.g., different mapping lifetime), then it nee= ds to know the authenticated ID of the subscriber.

 

Alper

 

 

On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wro= te:





Please see inline [TR]

 

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Wednesday, J= uly 17, 2013 12:24 PM
To: Prashanth Pati= l (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: [pcp] Pro= xy security (was Re: CONSENSUS CALL on PCP security)

 =

Hi Prashanth,

 =






I'm not sure if enough thought went into the PCP Proxy securit= y. As much as I'd love to be DONE! with this discussion, I also want to mak= e sure people feel comfortable having thought all aspects around the proxy use. For (very imp= ortant) example, what kind of security associations are needed for securing= the proxy use: An SA btw client and server, an SA btw client and proxy, an= SA btw proxy and server -- which combinations of these are needed?

 

We've included this in the updated version o= f auth req:

 

REQ-9: A PCP proxy that modifies PCP messages SHOULD have the<= /span>

ability to independently authenticate with the PCP client and = PCP

server. The presence of a PCP proxy hence requires two separat= ely

authenticates SAs. As a consequence, the PCP proxy:=

 

A. MUST be able to validate message integrity of PCP messages<= /span>

from the PCP server and client respectively.

 

B. MUST be able to ensure message integrity after updating the=

PCP message for cases described in sections 6 of ietf-pcp= -proxy.

 

The PCP proxy MUST also permit authentication on only one side= of

the proxy. For example, a customer premises host may not

authenticate with the PCP proxy but the PCP proxy may authenti= cate

with the PCP server.

 

 =

 =

So:

 =

- We have two types of S= As. One between the client and the proxy, another between the proxy and the= server.

- None of them are manda= tory to use.

 =

For each one that needs = to be used, we need to perform authentication between the end-points. =

(e.g., between client an= d proxy).

 =

So, in a way, we are dea= ling with security in two independent parts; client to proxy, and proxy to = server. 

They are totally segrega= ted from security perspective. 

 =

 =

Right?=

 =

Hmm, one thing: The serv= er may need to know the authenticated ID of the client. Since it's not part= of the client authentication, it won't know that value readily. So, we may= need to define an option to carry that piece of information from the proxy to the server.

 

[TR]

 

Why would the PCP server need to know the authentication ID = of the client. For example Home network;   Alice (PCP client) -&g= t; Home Router (PCP Proxy) -> ISP (PCP Server)

Why would PCP Server in ISP care about the authentication ID= of Alice ?

 

--Tiru.

 =

Alper<= /p>

 =

 =

 =






-Prashanth

 

Then we need to talk about how we dynamically create those usi= ng any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:

 

-----Original Message-----

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 10:51 PM

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS CALL on PCP security<= /o:p>

Hi Dave,

In the poll when you refer to PANA, please clarify the draft y= ou are referring

--Tiru.

The question is intentionally agnostic as this is about a gene= ral approach,

not which specific implementation.  If it helps, you= can interpret the

answer as "which of the two you think is better".

If the consensus is PANA rather than direct EAP-in-PCP, then w= e could

ask as a follow-up question which of the two we should go with= . If

you'd like to include your answer to that now though, feel fre= e to

include that in your response to the call.

-Dave

_______________________________________________

pcp mailing list

 

_______________________________________________

pcp mailing list

 

 

 

--_000_913383AAA69FF945B8F946018B75898A14B9C898xmbrcdx10ciscoc_-- From praspati@cisco.com Thu Jul 18 09:23:59 2013 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 D6F3711E8190 for ; Thu, 18 Jul 2013 09:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUnqUr40-0Zn for ; Thu, 18 Jul 2013 09:23:27 -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 9142E21F9B19 for ; Thu, 18 Jul 2013 09:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57391; q=dns/txt; s=iport; t=1374164601; x=1375374201; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=rbQPFcUWZx1rl16ULA8/PKPRdHETccsWMY+LBPMsj30=; b=hdkrl6w+0Eze+DEYRdVvvdCSOPOdMPxQLhOtnNF2QJliNSCp0/JAbDaV 57v0GCalJAqO/t9q3lnuHvba74GcplzeOs4LFVn6r+isLL03HbCvdKLG7 B+fKf0td/SnoWovzqC+XPs/G/NZVXgfpkuDmYXYOb4AyVIS2ZBSAQxq0p g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscFAIQV6FGtJV2a/2dsb2JhbABagkJENVCDBrUCiDyBERZ0giQBAQEBAwEBAR4BC0ELDAYBCBEEAQELBREBBgIDKQsUCQgCBAENBQgTh3UMiSmbPAGRSo9eLQQGAQaCUjZuA4FNlzmQJIMSgWokHA X-IronPort-AV: E=Sophos;i="4.89,694,1367971200"; d="scan'208,217";a="236517738" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jul 2013 16:23:20 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6IGNJYP031832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 16:23:19 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 11:23:19 -0500 From: "Prashanth Patil (praspati)" To: "yoshihiro.ohba@toshiba.co.jp" , "alper.yegin@yegin.org" Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOg7xOgyVOTGpo0E674JzHPKIxG5lrOpsA//+o/oCAAGsmgA== Date: Thu, 18 Jul 2013 16:23:18 +0000 Message-ID: In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D31747@tgxml338.toshiba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.65.48.100] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE33271xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 16:24:00 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE33271xmbrcdx07ciscoc_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Yoshihiro, On 18/07/13 8:59 PM, "yoshihiro.ohba@toshiba.co.jp" > wrote: Hi Prashanth, From: Prashanth Patil (praspati) [mailto:praspati@cisco.com] Sent: Friday, July 19, 2013 12:11 AM To: ohba yoshihiro(=1B$BBg>l5AMN!{#R#D#C""#N#S#L=1B(B); alper.yegin@yegin.o= rg Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Yoshihiro, Although the abstract says that, I don=1B$B!G=1B(Bt think the intent is for= the PCP Proxy to just be a relay agent. It is clear from other sections of= the draft that the proxy is indeed a server and needs to modify fields (al= beit minimal) before forwarding them to the actual server. This implies two= independent authentications need to happen. [YO] I don=1B$B!G=1B(Bt understand your logic here. Even an http proxy can = modify http requests (e.g., X-Forwarded-For header), and an http server can= still authenticate http clients behind the proxy. How does the proxy maintain message integrity if it modifies requests/respo= nses? The case is different with HTTP. -Prashanth Yoshihiro Ohba -Prashanth On 18/07/13 7:09 PM, "yoshihiro.ohba@toshiba.co.jp" > wrote: Hi Tiru, Abstract of pcp-proxy draft says: =1B$B!H=1B(B This document specifies a new PCP functional element denoted as PCP Proxy. The PCP Proxy relays PCP requests received from PCP Clients to upstream PCP Server(s). This function is mandatory when PCP Clients can not be configured with the address of the PCP Server located more than one hop. =1B$B!H=1B(B If this abstract is correct, I interpret that PCP clients only know the PCP= proxy=1B$B!G=1B(Bs address, but the PCP server *can* be the authentication= end-point for the PCP clients. This is similar to the http proxy case whe= re http servers are the authentication end-points for http clients. Having= said that, I think it is a bad idea to mandate PCP proxy to be *the* end-p= oint that authenticates the PCP clients in the proxy case. Yoshihiro Ohba From:pcp-bounces@ietf.org [mailto:pcp-bounces@= ietf.org] On Behalf Of Prashanth Patil (praspati) Sent: Wednesday, July 17, 2013 4:46 PM To: Alper Yegin Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Alper, On 17/07/13 12:23 PM, "Alper Yegin" > wrote: Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. PRA: Yes, none of them are mandatory, it's currently the prerogative of the= server to mandate authentication. The proxy MUST be able authenticate with= either client or server or both. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? PRA: Right. As far as the client is concerned, the proxy is the PCP server.= The proxy is in turn a client to the upstream PCP server. The two parts sh= ould be independent of each other. Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. PRA: May be, but don=1B$B!G=1B(Bt know why the server would want to know th= e auth-id of a client. -Prashanth Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_B235506D63D65E43B2E40FD27715372E1CE33271xmbrcdx07ciscoc_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: <3C410C2F08C1304AB780B054206874FB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Yoshihiro,


Hi Prashanth,

 

 

From: Prashanth Patil (praspati) [mailto:praspati@ci= sco.com]
Sent: Friday, July 19, 2013 12:11 AM
To: ohba yoshihiro(=1B$BBg>l= =1B(B=1B$B5AMN=1B(B=1B$= B!{=1B(B=1B$B#R#D#C=1B(B=1B$B#N#S#L=1B(B); alper.yegin@yegin.org
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

Hi Yoshihiro,

Although the abstract says that, I don=1B$B!G= =1B(Bt think the intent is for the PCP Proxy to just be a relay agent. It is clear from other sections of the draft that the pr= oxy is indeed a server and needs to modify fields (albeit minimal) before f= orwarding them to the actual server. This implies two independent authentic= ations need to happen.

[YO] I don=1B$B!G=1B(Bt understand your logic here. Even an h= ttp proxy can modify http requests (e.g., X-Forwarded-For header), and an http server can still authenticate http clients behind the= proxy.

How does the proxy maintain message integrity if it modifies requests/= responses? The case is different with HTTP.

-Prashanth

 

Yoshihiro Ohba<= o:p>

 

-Prashanth

 

 

Hi Tiru,

 

Abstract of pcp-proxy draft says:=

 

=1B$B!H=1B(B

   This document spe= cifies a new PCP functional element denoted as PCP

   Proxy.  The = PCP Proxy relays PCP requests received from PCP Clients

   to upstream PCP S= erver(s).  This function is mandatory when PCP

   Clients can not b= e configured with the address of the PCP Server

   located more than= one hop.

=1B$B!H=1B(B

 

If this abstract is correct, I interpret= that PCP clients only know the PCP proxy=1B$B!G=1B(Bs address, but the PCP server *can* be the authentication end-point f= or the PCP clients.  This is similar to the http proxy case where http= servers are the authentication end-points for http clients.  Having s= aid that, I think it is a bad idea to mandate PCP proxy to be *the* end-point that authenticates the PCP clients = in the proxy case.

 

Yoshihiro Ohba

 

 

 

From:pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] = On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)<= /p>

 

Hi Alper,

 

On 17/07/13 12:23 PM, "Alper Yegin" &= lt;alper.yegin@yegin.org> wrote:=

 

Hi Prashanth,

 




I'm not sure if enough thought went into the PC= P Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfor= table having thought all aspects around the proxy use. For (very important)= example, what kind of security associations are needed for securing the pr= oxy use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinatio= ns of these are needed?

 

We've included this in the updated version of a= uth req:

 

REQ-9: A PCP proxy that modifies PCP message= s SHOULD have the

ability to independently authenticate with t= he PCP client and PCP=

server. The presence of a PCP proxy hence re= quires two separately=

authenticates SAs. As a consequence, the PCP= proxy:

 

A. MUST be able to validate message integrit= y of PCP messages

from the PCP server and client respectively.=

 

B. MUST be able to ensure message integrity = after updating the

PCP message for cases described in sections = 6 of ietf-pcp-proxy.

 

The PCP proxy MUST also permit authenticatio= n on only one side of=

the proxy. For example, a customer premises = host may not

authenticate with the PCP proxy but the PCP = proxy may authenticate

with the PCP server.

 

 

 

So:

 

- We have two types of SAs. One between the cli= ent and the proxy, another between the proxy and the server.

- None of them are mandatory to use.

 

PRA: Yes, none of them are mandatory, it's curr= ently the prerogative of the server to mandate authentication. The proxy MUST be able authenticate with either client or = server or both.

 

For each one that needs to be used, we need to = perform authentication between the end-points. 

(e.g., between client and proxy).

 

So, in a way, we are dealing with security in t= wo independent parts; client to proxy, and proxy to server. 

They are totally segregated from security persp= ective. <= /span>

 

Right?

 

PRA: Right. As far as the client is concerned, = the proxy is the PCP server. The proxy is in turn a client to the upstream PCP server. The two parts should be indep= endent of each other.

 

Hmm, one thing: The server may need to know the= authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. S= o, we may need to define an option to carry that piece of information from = the proxy to the server.<= o:p>

 

PRA: May be, but don=1B$B!G=1B(Bt know why the = server would want to know the auth-id of a client.

 

-Prashanth 

 

Alper

 

 

 




-Prashanth

 

Then we need to talk about how we dynamically c= reate those using any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:=

 

-----Original Message-----

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 10:51 PM

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS CALL on PCP securi= ty

Hi Dave,

In the poll when you refer to PANA, please clar= ify the draft you are referring

--Tiru.

The question is intentionally agnostic as this = is about a general approach,

not which specific implementation.  I= f it helps, you can interpret the

answer as "which of the two you think is b= etter".

If the consensus is PANA rather than direct EAP= -in-PCP, then we could

ask as a follow-up question which of the two we= should go with. If<= /o:p>

you'd like to include your answer to that now t= hough, feel free to<= /o:p>

include that in your response to the call.

-Dave

_______________________________________________=

pcp mailing list

 

_______________________________________________=

pcp mailing list

 

 

 --_000_B235506D63D65E43B2E40FD27715372E1CE33271xmbrcdx07ciscoc_-- From B.McCann@F5.com Thu Jul 18 10:01:28 2013 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 F022511E8167 for ; Thu, 18 Jul 2013 10:01: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiatJTn75XsQ for ; Thu, 18 Jul 2013 10:01:24 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id C4C5011E81A5 for ; Thu, 18 Jul 2013 10:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=B.McCann@f5.com; q=dns/txt; s=seattle; t=1374166870; x=1405702870; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CDzX8H/I1BjMA1zuXn7XrbqpMfCFut6GoZS9jWDo2ig=; b=QDlfnVNt30pMSwCEWY2SbWWhqNbMYG1/7YG8YZuFYSMAsI1E7cIB0XnD VA2yAsBkNRDDWVlG3Oj1jSKfsqsX0Hjok/X77Id82GNi5z2ePhiOfxEWc RHfPdxSbfh3A7Se0lqjLs1ukNMWXt+jpmstyYsBPOKRZjpfIgVJspbDRU s=; X-IronPort-AV: E=Sophos;i="4.89,695,1367971200"; d="scan'208";a="76453890" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 18 Jul 2013 17:00:56 +0000 Received: from LWLECAS02.olympus.F5Net.com (192.168.96.201) by SEAECAS01.olympus.F5Net.com (192.168.16.220) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 10:00:55 -0700 Received: from LWLMBX01.olympus.F5Net.com ([fe80::c509:8f7f:7f5f:cab9]) by LWLECAS02.olympus.F5Net.com ([::1]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 13:00:54 -0400 From: Ben McCann To: Alper Yegin Thread-Topic: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP security) Thread-Index: AQHOg5GFb5cRiwkWP0+zKLKzH9gBqZlqh0rA Date: Thu, 18 Jul 2013 17:00:54 +0000 Message-ID: <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> References: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> In-Reply-To: <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.101.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 17:01:28 -0000 Thank you for clarifying that "PANA does not force clients to always have a= session, or always stay awake or connected". That, I believe, wasn't Margaret's point. PANA *supports* server side re-au= thentication even if the client doesn't think it's necessary. So, if the se= rver chooses, it can wake up the client by sending packets. That said, this= really isn't a legitimate criticism of the PANA protocol. It's an issue th= at can be addressed by proper programming or configuration of the PCP/PANA = server to make sure it doesn't unnecessarily re-authenticate the clients.=20 So, I agree with you that PANA, on a properly configured server, can be as = "mobile friendly" and lightweight as EAP-in-PCP.=20 My concerns about starting from a clean slate are based, in part, on Steve = Hartman's "Implementation Analysis: strong preference for PCP-specific appr= oach" (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His= arguments were persuasive (to me) and the counter-arguments were not.=20 I understand that implementation should not dictate protocol design but I t= hink we should let implementation *inform* protocol design. If I have to se= lect between two ways to define a protocol, and one of them is simpler to i= mplement, then I will tend to vote for the simpler option if all other crit= eria are equal. I see EAP-in-PCP as the simpler option even if there is sou= rce code for PANA. I've also reviewed the OpenPANA source code and I have some concerns that i= llustrate this point: * The PANA state machine includes 13 states with 22 separate input events. = That state machine has to be integrated with the simpler PCP state machine.= My intuition, based on too many years of experience, is that integrating t= he PANA and PCP state machines is tricky to implement, debug, and verify. T= hat complexity is, in part, because PANA already has a fairly complex state= machine. I don't believe EAP-in-PCP requires this much complexity. * The OpenPANA implementation is about 6900 SLOCs long as measured by an sl= occount version 2.26. This seems like a lot of code (aka complexity) to tun= nel EAP packets over PCP. And, that doesn't include the code that must be a= dded to PCP required to integrate PCP with PANA. I believe an EAP-in-PCP im= plementation will be much simpler but, I admit, I don't have an implementat= ion to show you that proves that point. * The presence of an open source version of PANA is a vote in its favor but= that depends on whether that code is easily portable to many environments.= I think the OpenPANA implementation makes assumptions about its runtime en= vironment that aren't very portable. It assumes a multi-threaded environmen= t with posix sockets and my runtime environment doesn't meet those requirem= ents. To be fair, I don't think I've said anything here that wasn't already cover= ed by Steve Hartman. But, I did review the code and I agree with his conclu= sions. -Ben McCann -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 Sent: Thursday, July 18, 2013 4:34 AM To: Ben McCann Cc: Dave Thaler; pcp@ietf.org Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP security) Hello, I'm afraid your below issues are based on misconceptions introduced by the = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides. We did address those misconceptions in several rounds, but it seems like so= me still linger. PANA does not force clients to always have a session, or always stay awake = or connected. If a client wants to get authenticated and generate a 5 minute key, and aft= erwards sleep, detach, etc., it can very well do that using PANA. We can support that by simply setting the lifetime of the PANA SA to that s= hort fix value, or letting the PANA SA timeout and expire.=20 So, you can run PANA and have a 5 min SA, then have no PANA activity for 23= :55hrs, and then come back and do another PANA authentication and have anot= her 5min SA. No problems. Therefore, there are no issues with mobile, and no issues with server side = resources. After all, PANA is adopted by Zigbee Alliance. I don't think the deployment= cases considered here are any more constrained than theirs... > EAP-in-PCP provides a clean slate that's unencumbered by the design decis= ions and assumptions of an existing protocol (PANA).=20 Was there any other concern leading to your above statement? Alper On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: > 1) Could you *live with* EAP-in-PCP? If not, state reason you would objec= t. >=20 > YES >=20 > 2) Could you *live with* PANA? If not, state reason you would object. >=20 > Yes, but we really rather not use PANA. See below... >=20 > 3) If you said yes to both 1 and 2, but have a strong preference between = the two, which approach do you prefer and why? >=20 > We strongly prefer EAP-in-PCP for several reasons: >=20 > * PANA, as we understand it, is not mobile-friendly. It requires the PCP = client to *always* have an authenticated session active and that is wastefu= l on mobile clients when the authentication rekey interval is much shorter = than the mapping lifetime. Margaret Wasserman captured this in slides 13 an= d 14 of her presentation http://www.ietf.org/proceedings/85/slides/slides-8= 5-pcp-17.pdf. We believe the *client* should decide when to authenticate (b= ecause it needs to create or refresh a mapping) because that lets the clien= t optimize its use of the network and reduce its power consumption.=20 >=20 > We understand that a PCP server may need to send a message to the client = when no authenticated session is active. If no authenticated session is act= ive then we prefer the server send an UN-authenticated "call home" message = directing the client to authenticate and then the server can send its messa= ges over the authenticated channel. We recognize an attacker can induce the= client to connect to the server by forging an unauthenticated "call home" = message. But, having done that, the client can ignore subsequent forged cal= l home messages because it will already have an authenticated session. Wors= e case, an attacker can't make EAP-in-PCP consume any more client resources= than PANA does because PANA requires the client to always have an authenti= cated session available. >=20 > * PANA requires more server side resources. The authentication protocol s= hould efficiently support 100,000's of clients on a large PCP server. Why s= hould the server continuously maintain authenticated sessions with *every* = client? Clients using 24 hour mapping lifetimes can be served by short auth= entication key lifetime like, for example, 5 minutes. Let the client connec= t, authenticate, program the mappings, and then let the authenticated sessi= on expire. Rinse and repeat in 24 hours,. Client-driven authentication via = EAP-in-PCP requires less resources on the server because the server can dis= card the authenticated session state once the key lifetime expires. >=20 > There was some discussion that PANA is preferable to EAP-in-PCP because i= t supports "liveness testing". We don't believe liveness testing is useful = when the server resources consumed, per client, are PCP mappings. Checking = the liveness of 100,000 clients is much more resource intensive on the serv= er than just keeping the client's mappings around until they expire natural= ly at the end of their lifetime. In short, we believe EAP-in-PCP will scale= better on the server than PANA. >=20 > * We believe the decision to use EAP-in-PCP vs. PANA is a choice between = designing and implementing an EAP-in-PCP transport that is tailored for PCP= versus adapting an existing protocol (PANA) to fit the needs of PCP. We d= on't think implementing an EAP-in-PCP transport is difficult so we prefer i= t over PANA. EAP-in-PCP provides a clean slate that's unencumbered by the d= esign decisions and assumptions of an existing protocol (PANA).=20 >=20 > -Ben McCann >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From yoshihiro.ohba@toshiba.co.jp Thu Jul 18 13:19:34 2013 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 1666211E81A1 for ; Thu, 18 Jul 2013 13:19:34 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssyH+OFDs2rY for ; Thu, 18 Jul 2013 13:19:28 -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 B7AA111E8199 for ; Thu, 18 Jul 2013 13:19:27 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r6IKJMiP010025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 05:19:22 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6IKJM3Y030186; Fri, 19 Jul 2013 05:19:22 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 736; Fri, 19 Jul 2013 05:19:22 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6IKJMmN030183; Fri, 19 Jul 2013 05:19:22 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r6IKJMXv000681; Fri, 19 Jul 2013 05:19:22 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id FAA00680; Fri, 19 Jul 2013 05:19:22 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r6IKJL8n017757; Fri, 19 Jul 2013 05:19:21 +0900 (JST) Received: from tgxml345.toshiba.local by toshiba.co.jp id r6IKJLOB019408; Fri, 19 Jul 2013 05:19:21 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.194]) by tgxml345.toshiba.local ([133.199.60.32]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 05:19:21 +0900 From: To: , Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOgrpla3wABna3lECF2TL4pPZxUpln5w+AgAKIlgD//4YaAIAAmElw//973ACAANgKEA== Date: Thu, 18 Jul 2013 20:19:21 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D31838@tgxml338.toshiba.local> References: <674F70E5F2BE564CB06B6901FD3DD78B12D31747@tgxml338.toshiba.local> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.5] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D31838tgxml338toshiba_" MIME-Version: 1.0 Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 20:19:34 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D31838tgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Well, that is easy: Once the PCP server successfully authenticate a PCP cli= ent, it distributes a key used for protecting PCP message between the PCP c= lient and the PCP proxy to the PCP proxy in a secure way. Regards, Yoshihiro Ohba From: Prashanth Patil (praspati) [mailto:praspati@cisco.com] Sent: Friday, July 19, 2013 1:23 AM To: ohba yoshihiro; alper.yegin@yegin.org Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Yoshihiro, On 18/07/13 8:59 PM, "yoshihiro.ohba@toshiba.co.jp" > wrote: Hi Prashanth, From: Prashanth Patil (praspati) [mailto:praspati@cisco.com] Sent: Friday, July 19, 2013 12:11 AM To: ohba yoshihiro(=1B$BBg>l5AMN!{#R#D#C""#N#S#L=1B(B); alper.yegin@yegin.o= rg Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Yoshihiro, Although the abstract says that, I don=1B$B!G=1B(Bt think the intent is for= the PCP Proxy to just be a relay agent. It is clear from other sections of= the draft that the proxy is indeed a server and needs to modify fields (al= beit minimal) before forwarding them to the actual server. This implies two= independent authentications need to happen. [YO] I don=1B$B!G=1B(Bt understand your logic here. Even an http proxy can = modify http requests (e.g., X-Forwarded-For header), and an http server can= still authenticate http clients behind the proxy. How does the proxy maintain message integrity if it modifies requests/respo= nses? The case is different with HTTP. -Prashanth Yoshihiro Ohba -Prashanth On 18/07/13 7:09 PM, "yoshihiro.ohba@toshiba.co.jp" > wrote: Hi Tiru, Abstract of pcp-proxy draft says: =1B$B!H=1B(B This document specifies a new PCP functional element denoted as PCP Proxy. The PCP Proxy relays PCP requests received from PCP Clients to upstream PCP Server(s). This function is mandatory when PCP Clients can not be configured with the address of the PCP Server located more than one hop. =1B$B!H=1B(B If this abstract is correct, I interpret that PCP clients only know the PCP= proxy=1B$B!G=1B(Bs address, but the PCP server *can* be the authentication= end-point for the PCP clients. This is similar to the http proxy case whe= re http servers are the authentication end-points for http clients. Having= said that, I think it is a bad idea to mandate PCP proxy to be *the* end-p= oint that authenticates the PCP clients in the proxy case. Yoshihiro Ohba From:pcp-bounces@ietf.org [mailto:pcp-bounces@= ietf.org] On Behalf Of Prashanth Patil (praspati) Sent: Wednesday, July 17, 2013 4:46 PM To: Alper Yegin Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Alper, On 17/07/13 12:23 PM, "Alper Yegin" > wrote: Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. PRA: Yes, none of them are mandatory, it's currently the prerogative of the= server to mandate authentication. The proxy MUST be able authenticate with= either client or server or both. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? PRA: Right. As far as the client is concerned, the proxy is the PCP server.= The proxy is in turn a client to the upstream PCP server. The two parts sh= ould be independent of each other. Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. PRA: May be, but don=1B$B!G=1B(Bt know why the server would want to know th= e auth-id of a client. -Prashanth Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D31838tgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Well, that i= s easy: Once the PCP server successfully authenticate a PCP client, it dist= ributes a key used for protecting PCP message between the PCP client and the PCP proxy to the PCP proxy in a secure way.<= /span>

 <= /o:p>

Regards,

Yoshihiro Oh= ba

 <= /o:p>

 <= /o:p>

From: Prashanth Patil (praspati) [mailto:praspati@cisco.com]
Sent: Friday, July 19, 2013 1:23 AM
To: ohba yoshihiro; alper.yegin@yegin.org
Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

Hi Yoshihiro,=

 

 

Hi Prashanth,

 

 

From: Prashanth Patil (praspati) [mailto:p= raspati@cisco.com]
Sent: Friday, July 19, 2013 12:11 AM
To: ohba yoshihiro(=1B$BBg>l5AMN=1B(B=1B$B!= {=1B(B=1B$B#R#D#C=1B= (B=1B$B""=1B(B=1B$B#N#S#L=1B(B); alper.yegin@yegin.org
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)<= /p>

 

Hi Yoshihiro,

Although the abstract says that= , I don=1B$B!G=1B(Bt think the intent is for the PCP Proxy to just be a relay agent. It is clear from other sections of the draft that the proxy i= s indeed a server and needs to modify fields (albeit minimal) before forwar= ding them to the actual server. This implies two independent authentication= s need to happen.

[YO] I don=1B$B!G=1B(Bt u= nderstand your logic here. Even an http proxy can modify http requests (e.g., X-Forwarded-For header), and an http server can still authenticate = http clients behind the proxy.

 

How does the proxy maintain mes= sage integrity if it modifies requests/responses? The case is different with HTTP.

 

-Prashanth

 

Yoshihiro Ohba=

 

-Prashanth

 

 

Hi Tiru,

 

Abstract of pcp-proxy draft say= s:

 

=1B$B!H=1B(B

   This document = specifies a new PCP functional element denoted as PCP

   Proxy.  T= he PCP Proxy relays PCP requests received from PCP Clients

   to upstream PC= P Server(s).  This function is mandatory when PCP

   Clients can no= t be configured with the address of the PCP Server

   located more t= han one hop.

=1B$B!H=1B(B

 

If this abstract is correct, I = interpret that PCP clients only know the PCP proxy=1B$B!G=1B(Bs address, but the PCP server *can* be the authentication end-point for the PC= P clients.  This is similar to the http proxy case where http servers = are the authentication end-points for http clients.  Having said that,= I think it is a bad idea to mandate PCP proxy to be *the* end-point that authenticates the PCP clients in the pro= xy case.

 

Yoshihiro Ohba

 

 

 

From:pcp-bo= unces@ietf.org [mailto:pcp-bounces@ietf.org] = On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)<= /p>

 

Hi Alper,

 

On 17/07/13 12:23 PM, "A= lper Yegin" <alper.yegin@y= egin.org> wrote:=

 

Hi Prashanth,

 





I'm not sure if enough though= t went into the PCP Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfortab= le having thought all aspects around the proxy use. For (very important) ex= ample, what kind of security associations are needed for securing the proxy= use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinatio= ns of these are needed?

 

We've included this in the up= dated version of auth req:

 

REQ-9: A PCP proxy that mo= difies PCP messages SHOULD have the

ability to independently a= uthenticate with the PCP client and PCP

server. The presence of a = PCP proxy hence requires two separately

authenticates SAs. As a co= nsequence, the PCP proxy:

 

A. MUST be able to validat= e message integrity of PCP messages

from the PCP server and cl= ient respectively.

 

B. MUST be able to ensure = message integrity after updating the

PCP message for cases desc= ribed in sections 6 of ietf-pcp-proxy.

 

The PCP proxy MUST also pe= rmit authentication on only one side of

the proxy. For example, a = customer premises host may not

authenticate with the PCP = proxy but the PCP proxy may authenticate

with the PCP server.

 

 

 

So:

 

- We have two types of SAs. O= ne between the client and the proxy, another between the proxy and the server.

- None of them are mandatory = to use.=

 

PRA: Yes, none of them are ma= ndatory, it's currently the prerogative of the server to mandate authentication. The proxy MUST be able authenticate with either client or = server or both.

 

For each one that needs to be= used, we need to perform authentication between the end-points. 

(e.g., between client and pro= xy).

 

So, in a way, we are dealing = with security in two independent parts; client to proxy, and proxy to server. 

They are totally segregated f= rom security perspective. 

 

Right?

 

PRA: Right. As far as the cli= ent is concerned, the proxy is the PCP server. The proxy is in turn a client to the upstream PCP server. The two parts should be indep= endent of each other.

 

Hmm, one thing: The server ma= y need to know the authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. S= o, we may need to define an option to carry that piece of information from = the proxy to the server.<= o:p>

 

PRA: May be, but don=1B$B!G= =1B(Bt know why the server would want to know the auth-id of a client.

 

-Prashanth 

 

Alper

 

 

 





-Prashanth

 

Then we need to talk about ho= w we dynamically create those using any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, = Dave Thaler wrote:

 

-----Original Message-----

From: Tirumaleswar Reddy (tir= eddy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 1= 0:51 PM=

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS = CALL on PCP security=

Hi Dave,

In the poll when you refer to= PANA, please clarify the draft you are referring

--Tiru.

The question is intentionally= agnostic as this is about a general approach,

not which specific implementa= tion.  If it helps, you can interpret the

answer as "which of the = two you think is better".

If the consensus is PANA rath= er than direct EAP-in-PCP, then we could

ask as a follow-up question w= hich of the two we should go with. If

you'd like to include your an= swer to that now though, feel free to

include that in your response= to the call.<= /span>

-Dave

_____________________________= __________________

pcp mailing list

pcp@ietf.org<= /o:p>

 

_____________________________= __________________

pcp mailing list

pcp@ietf.org<= /o:p>

 

 

--_000_674F70E5F2BE564CB06B6901FD3DD78B12D31838tgxml338toshiba_-- From rafa@um.es Thu Jul 18 14:30:46 2013 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 546CD11E8217 for ; Thu, 18 Jul 2013 14:30:46 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da9Qok61vRRz for ; Thu, 18 Jul 2013 14:30:41 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id EC13411E820B for ; Thu, 18 Jul 2013 14:30:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 21AD85D677; Thu, 18 Jul 2013 23:30:39 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sLewYsHoE3o9; Thu, 18 Jul 2013 23:30:38 +0200 (CEST) Received: from [192.168.1.67] (29.Red-83-43-54.dynamicIP.rima-tde.net [83.43.54.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPSA id EB38E5D62A; Thu, 18 Jul 2013 23:30:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Rafa Marin Lopez In-Reply-To: <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> Date: Thu, 18 Jul 2013 23:30:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <76B8454D-73F0-4E3D-81A6-55F121535901@um.es> References: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> To: Ben McCann X-Mailer: Apple Mail (2.1085) Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) 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, 18 Jul 2013 21:30:46 -0000 Hi Ben: On Jul 18, 2013, at 7:00 PM, Ben McCann wrote: > Thank you for clarifying that "PANA does not force clients to always = have a session, or always stay awake or connected". >=20 > That, I believe, wasn't Margaret's point. PANA *supports* server side = re-authentication even if the client doesn't think it's necessary. So, = if the server chooses, it can wake up the client by sending packets. = That said, this really isn't a legitimate criticism of the PANA = protocol. It's an issue that can be addressed by proper programming or = configuration of the PCP/PANA server to make sure it doesn't = unnecessarily re-authenticate the clients.=20 >=20 > So, I agree with you that PANA, on a properly configured server, can = be as "mobile friendly" and lightweight as EAP-in-PCP.=20 >=20 >=20 > My concerns about starting from a clean slate are based, in part, on = Steve Hartman's "Implementation Analysis: strong preference for = PCP-specific approach" = (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His = arguments were persuasive (to me) and the counter-arguments were not.=20 [Rafa] Why my answers in = http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html are not = ok? >=20 > I understand that implementation should not dictate protocol design = but I think we should let implementation *inform* protocol design. If I = have to select between two ways to define a protocol, and one of them is = simpler to implement, then I will tend to vote for the simpler option if = all other criteria are equal. I see EAP-in-PCP as the simpler option = even if there is source code for PANA. >=20 > I've also reviewed the OpenPANA source code and I have some concerns = that illustrate this point: >=20 > * The PANA state machine includes 13 states with 22 separate input = events. That state machine has to be integrated with the simpler PCP = state machine. My intuition, based on too many years of experience, is = that integrating the PANA and PCP state machines is tricky to implement, = debug, and verify. That complexity is, in part, because PANA already has = a fairly complex state machine. I don't believe EAP-in-PCP requires this = much complexity. [Rafa] Ben, I have always assumed we all have experience in the area. In = particular, I have been working on PANA since 2003 and I have done = source coding myself, I have been leading an open source PANA = implementation and deployed PANA in several EU projects, without any = inconvenience so far. About the state machine, I can tell you that part of it is completely = optional.=20 And about the integration between PANA and PCP, I disagree based on the = experience we got from = http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 >=20 > * The OpenPANA implementation is about 6900 SLOCs long as measured by = an sloccount version 2.26. This seems like a lot of code (aka = complexity) to tunnel EAP packets over PCP. And, that doesn't include = the code that must be added to PCP required to integrate PCP with PANA. = I believe an EAP-in-PCP implementation will be much simpler but, I = admit, I don't have an implementation to show you that proves that = point. [Rafa] This number is completely wrong as I already explained in = http://www.ietf.org/mail-archive/web/pcp/current/msg02631.html (as you = may observe this is a repeating conversation). You may agree with me = that doing the sloccount over the entire package does not help too = much. We need to be more specific. In the message I already sent, the discussion was about openpana-0.2.3. = Right now, we have openpana-0.2.4 and we have new values. The following = values only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or = RADIUS client since those values will be common to any other solution = using EAP and RADIUS. OpenPANA: The PAA: 3130 LoC (PAA ST + PAA main program + PANA messages + PAA session + PRF) The PaC 2720 (PaC ST + PaC main + PANA messages + PaC session + PRF) It is worth noting that those values includes 1846 LoCs which are common = functionality to PaC and PAA. Moreover, as I also explained in the e-mail we have a version for very = constrained devices (sensor nodes). In particular we have a PaC = implementation for Contiki OS named PANATIKI = (http://sourceforge.net/projects/panatiki) and the values are:=20 PANATIKI : 517 (PaC state machine) + 141 (PaC main program) But again, please take into account this is just an open source = implementation and not a product. And, of course, running code is = absolutely better than no code. Regarding your comment "And, that doesn't include the code that must be = added to PCP required to integrate PCP with PANA", please see slide 12 = in http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 . Just a = 100 lines that includes "PCP Key derivation and export. Unix Sockets." = in the case of OpenPANA. >=20 > * The presence of an open source version of PANA is a vote in its = favor but that depends on whether that code is easily portable to many = environments. I think the OpenPANA implementation makes assumptions = about its runtime environment that aren't very portable. It assumes a = multi-threaded environment with posix sockets and my runtime environment = doesn't meet those requirements. [Rafa] For example, PANATIKI does not assume multi-threaded environment = with posix sockets (it is an implementation for a sensor node after = all). Btw, there are two open source implementations OpenPANA/PANATIKI = and CPANA. >=20 > To be fair, I don't think I've said anything here that wasn't already = covered by Steve Hartman. But, I did review the code and I agree with = his conclusions. [Rafa] As you can see, I already counter-argumented that analysis. In = any case, I will be in Berlin so any doubt you have about = OpenPana/PANATIKI or just implementating PANA, let me know and I will be = more than happy to meet and discuss. Best regards. >=20 > -Ben McCann >=20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Thursday, July 18, 2013 4:34 AM > To: Ben McCann > Cc: Dave Thaler; pcp@ietf.org > Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP = security) >=20 > Hello, >=20 > I'm afraid your below issues are based on misconceptions introduced by = the http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf = slides. > We did address those misconceptions in several rounds, but it seems = like some still linger. >=20 > PANA does not force clients to always have a session, or always stay = awake or connected. >=20 > If a client wants to get authenticated and generate a 5 minute key, = and afterwards sleep, detach, etc., it can very well do that using PANA. > We can support that by simply setting the lifetime of the PANA SA to = that short fix value, or letting the PANA SA timeout and expire.=20 > So, you can run PANA and have a 5 min SA, then have no PANA activity = for 23:55hrs, and then come back and do another PANA authentication and = have another 5min SA. No problems. >=20 > Therefore, there are no issues with mobile, and no issues with server = side resources. >=20 > After all, PANA is adopted by Zigbee Alliance. I don't think the = deployment cases considered here are any more constrained than theirs... >=20 >> EAP-in-PCP provides a clean slate that's unencumbered by the design = decisions and assumptions of an existing protocol (PANA).=20 >=20 >=20 > Was there any other concern leading to your above statement? >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: >=20 >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>=20 >> YES >>=20 >> 2) Could you *live with* PANA? If not, state reason you would object. >>=20 >> Yes, but we really rather not use PANA. See below... >>=20 >> 3) If you said yes to both 1 and 2, but have a strong preference = between the two, which approach do you prefer and why? >>=20 >> We strongly prefer EAP-in-PCP for several reasons: >>=20 >> * PANA, as we understand it, is not mobile-friendly. It requires the = PCP client to *always* have an authenticated session active and that is = wasteful on mobile clients when the authentication rekey interval is = much shorter than the mapping lifetime. Margaret Wasserman captured this = in slides 13 and 14 of her presentation = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We = believe the *client* should decide when to authenticate (because it = needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption.=20 >>=20 >> We understand that a PCP server may need to send a message to the = client when no authenticated session is active. If no authenticated = session is active then we prefer the server send an UN-authenticated = "call home" message directing the client to authenticate and then the = server can send its messages over the authenticated channel. We = recognize an attacker can induce the client to connect to the server by = forging an unauthenticated "call home" message. But, having done that, = the client can ignore subsequent forged call home messages because it = will already have an authenticated session. Worse case, an attacker = can't make EAP-in-PCP consume any more client resources than PANA does = because PANA requires the client to always have an authenticated session = available. >>=20 >> * PANA requires more server side resources. The authentication = protocol should efficiently support 100,000's of clients on a large PCP = server. Why should the server continuously maintain authenticated = sessions with *every* client? Clients using 24 hour mapping lifetimes = can be served by short authentication key lifetime like, for example, 5 = minutes. Let the client connect, authenticate, program the mappings, and = then let the authenticated session expire. Rinse and repeat in 24 = hours,. Client-driven authentication via EAP-in-PCP requires less = resources on the server because the server can discard the authenticated = session state once the key lifetime expires. >>=20 >> There was some discussion that PANA is preferable to EAP-in-PCP = because it supports "liveness testing". We don't believe liveness = testing is useful when the server resources consumed, per client, are = PCP mappings. Checking the liveness of 100,000 clients is much more = resource intensive on the server than just keeping the client's mappings = around until they expire naturally at the end of their lifetime. In = short, we believe EAP-in-PCP will scale better on the server than PANA. >>=20 >> * We believe the decision to use EAP-in-PCP vs. PANA is a choice = between designing and implementing an EAP-in-PCP transport that is = tailored for PCP versus adapting an existing protocol (PANA) to fit the = needs of PCP. We don't think implementing an EAP-in-PCP transport is = difficult so we prefer it over PANA. EAP-in-PCP provides a clean slate = that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).=20 >>=20 >> -Ben McCann >>=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 ------------------------------------------------------- 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 B.McCann@F5.com Thu Jul 18 17:55:29 2013 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 C0EE121E80FB for ; Thu, 18 Jul 2013 17:55:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxCCewY9M3pg for ; Thu, 18 Jul 2013 17:55:25 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id AD5E511E8176 for ; Thu, 18 Jul 2013 17:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=B.McCann@f5.com; q=dns/txt; s=seattle; t=1374195326; x=1405731326; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UpAxB0esSbQwk/wFRG4X57VO0UTO4pXgKy1JS4zAWBA=; b=zBLwTLsr6rFclSqxwfY4UmERaOgyAxdAhPJqB1MJqKbb1TeuRtYQ3cQY Bgq/PNm5GB4MJqhvgTlkxACOZGEZoajnNIl9opvz0MIVtx6lBtZ6BD7I5 tRhZ7ow3PDcEZRBUeiCi03cnszmLyRiVfOD4Eto0swTeLvZ5C1lSPREXh Y=; X-IronPort-AV: E=Sophos;i="4.89,697,1367971200"; d="scan'208";a="77260146" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 19 Jul 2013 00:55:24 +0000 Received: from LWLECAS01.olympus.F5Net.com (192.168.96.3) by SEAECAS04.olympus.F5Net.com (192.168.16.223) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 17:55:23 -0700 Received: from LWLMBX01.olympus.F5Net.com ([fe80::c509:8f7f:7f5f:cab9]) by LWLECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 20:55:22 -0400 From: Ben McCann To: Rafa Marin Lopez Thread-Topic: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOg/4QNvmxMKgZ9E+rY1WqIUKDo5lq/65g Date: Fri, 19 Jul 2013 00:55:21 +0000 Message-ID: <9374F3A019050A4C805B8DEF27285BE40115E08BCF@LWLMBX01.olympus.F5Net.com> References: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> <76B8454D-73F0-4E3D-81A6-55F121535901@um.es> In-Reply-To: <76B8454D-73F0-4E3D-81A6-55F121535901@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.101.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) 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, 19 Jul 2013 00:55:29 -0000 Hi Rafa, I incorrectly used a discussion about the suitability of the OpenPANA impl= ementation as an argument to defend my statement "EAP-in-PCP provides a cle= an slate that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).". That argument was a waste of time because the s= uitability or availability of a reference implementation is irrelevant to w= hether PANA was designed with a set of security considerations that are app= ropriate for PCP. This understanding of the security considerations is the = "clean slate" that is important to me. For example, PANA negotiates its own security association so it can provide= data integrity for the final EAP response packet. That's fine, but where h= ave we decided that PCP needs to secure the integrity of that response pack= et? (It probably should). PANA does not secure the earlier EAP packets that= carry parameters like the cipher suite selection or authentication paramet= ers for the selected EAP method. So, those could be compromised by an attac= ker. Where have we decided that this is an acceptable risk for PCP? We have= n't discussed that, but we implicitly agree to live with it if we move forw= ard with PANA. (Or, at least, we accept that risk with some EAP methods). I prefer EAP-in-PCP because it will make us think through those issues for = PCP. (We've made a good start in the auth requirements draft). Until we get= those requirements down, I think it's premature to decide PANA is the righ= t choice. It might be, if we agree that PANA's security considerations are = OK for PCP. Or, we could decide that a simple EAP-in-PCP transport w/o *any= * security association is sufficient because we can leverage the security p= roperties of EAP methods such as EAP-TTLS to achieve the data integrity req= uired for the EAP protocol. I'm vacation for two weeks and won't be in Berlin to continue this discussi= on face-to-face. -Ben McCann -----Original Message----- From: Rafa Marin Lopez [mailto:rafa@um.es]=20 Sent: Thursday, July 18, 2013 5:31 PM To: Ben McCann Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP secur= ity) Hi Ben: On Jul 18, 2013, at 7:00 PM, Ben McCann wrote: > Thank you for clarifying that "PANA does not force clients to always have= a session, or always stay awake or connected". >=20 > That, I believe, wasn't Margaret's point. PANA *supports* server side re-= authentication even if the client doesn't think it's necessary. So, if the = server chooses, it can wake up the client by sending packets. That said, th= is really isn't a legitimate criticism of the PANA protocol. It's an issue = that can be addressed by proper programming or configuration of the PCP/PAN= A server to make sure it doesn't unnecessarily re-authenticate the clients.= =20 >=20 > So, I agree with you that PANA, on a properly configured server, can be a= s "mobile friendly" and lightweight as EAP-in-PCP.=20 >=20 >=20 > My concerns about starting from a clean slate are based, in part, on Stev= e Hartman's "Implementation Analysis: strong preference for PCP-specific ap= proach" (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). H= is arguments were persuasive (to me) and the counter-arguments were not.=20 [Rafa] Why my answers in http://www.ietf.org/mail-archive/web/pcp/current/m= sg02349.html are not ok? >=20 > I understand that implementation should not dictate protocol design but I= think we should let implementation *inform* protocol design. If I have to = select between two ways to define a protocol, and one of them is simpler to= implement, then I will tend to vote for the simpler option if all other cr= iteria are equal. I see EAP-in-PCP as the simpler option even if there is s= ource code for PANA. >=20 > I've also reviewed the OpenPANA source code and I have some concerns that= illustrate this point: >=20 > * The PANA state machine includes 13 states with 22 separate input events= . That state machine has to be integrated with the simpler PCP state machin= e. My intuition, based on too many years of experience, is that integrating= the PANA and PCP state machines is tricky to implement, debug, and verify.= That complexity is, in part, because PANA already has a fairly complex sta= te machine. I don't believe EAP-in-PCP requires this much complexity. [Rafa] Ben, I have always assumed we all have experience in the area. In pa= rticular, I have been working on PANA since 2003 and I have done source cod= ing myself, I have been leading an open source PANA implementation and depl= oyed PANA in several EU projects, without any inconvenience so far. About the state machine, I can tell you that part of it is completely optio= nal.=20 And about the integration between PANA and PCP, I disagree based on the exp= erience we got from http://www.ietf.org/proceedings/86/slides/slides-86-pcp= -17 >=20 > * The OpenPANA implementation is about 6900 SLOCs long as measured by an = sloccount version 2.26. This seems like a lot of code (aka complexity) to t= unnel EAP packets over PCP. And, that doesn't include the code that must be= added to PCP required to integrate PCP with PANA. I believe an EAP-in-PCP = implementation will be much simpler but, I admit, I don't have an implement= ation to show you that proves that point. [Rafa] This number is completely wrong as I already explained in http://www= .ietf.org/mail-archive/web/pcp/current/msg02631.html (as you may observe th= is is a repeating conversation). You may agree with me that doing the slocc= ount over the entire package does not help too much. We need to be more sp= ecific. In the message I already sent, the discussion was about openpana-0.2.3. Rig= ht now, we have openpana-0.2.4 and we have new values. The following values= only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or RADIUS c= lient since those values will be common to any other solution using EAP and= RADIUS. OpenPANA: The PAA: 3130 LoC (PAA ST + PAA main program + PANA messages + PAA session + PRF) The PaC 2720 (PaC ST + PaC main + PANA messages + PaC session + PRF) It is worth noting that those values includes 1846 LoCs which are common fu= nctionality to PaC and PAA. Moreover, as I also explained in the e-mail we have a version for very cons= trained devices (sensor nodes). In particular we have a PaC implementation = for Contiki OS named PANATIKI (http://sourceforge.net/projects/panatiki) an= d the values are:=20 PANATIKI : 517 (PaC state machine) + 141 (PaC main program) But again, please take into account this is just an open source implementat= ion and not a product. And, of course, running code is absolutely better th= an no code. Regarding your comment "And, that doesn't include the code that must be add= ed to PCP required to integrate PCP with PANA", please see slide 12 in http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 . Just a 100 lines= that includes "PCP Key derivation and export. Unix Sockets." in the case = of OpenPANA. >=20 > * The presence of an open source version of PANA is a vote in its favor b= ut that depends on whether that code is easily portable to many environment= s. I think the OpenPANA implementation makes assumptions about its runtime = environment that aren't very portable. It assumes a multi-threaded environm= ent with posix sockets and my runtime environment doesn't meet those requir= ements. [Rafa] For example, PANATIKI does not assume multi-threaded environment wit= h posix sockets (it is an implementation for a sensor node after all). Btw,= there are two open source implementations OpenPANA/PANATIKI and CPANA. >=20 > To be fair, I don't think I've said anything here that wasn't already cov= ered by Steve Hartman. But, I did review the code and I agree with his conc= lusions. [Rafa] As you can see, I already counter-argumented that analysis. In any c= ase, I will be in Berlin so any doubt you have about OpenPana/PANATIKI or j= ust implementating PANA, let me know and I will be more than happy to meet = and discuss. Best regards. >=20 > -Ben McCann >=20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Thursday, July 18, 2013 4:34 AM > To: Ben McCann > Cc: Dave Thaler; pcp@ietf.org > Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP=20 > security) >=20 > Hello, >=20 > I'm afraid your below issues are based on misconceptions introduced by th= e http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides. > We did address those misconceptions in several rounds, but it seems like = some still linger. >=20 > PANA does not force clients to always have a session, or always stay awak= e or connected. >=20 > If a client wants to get authenticated and generate a 5 minute key, and a= fterwards sleep, detach, etc., it can very well do that using PANA. > We can support that by simply setting the lifetime of the PANA SA to that= short fix value, or letting the PANA SA timeout and expire.=20 > So, you can run PANA and have a 5 min SA, then have no PANA activity for = 23:55hrs, and then come back and do another PANA authentication and have an= other 5min SA. No problems. >=20 > Therefore, there are no issues with mobile, and no issues with server sid= e resources. >=20 > After all, PANA is adopted by Zigbee Alliance. I don't think the deployme= nt cases considered here are any more constrained than theirs... >=20 >> EAP-in-PCP provides a clean slate that's unencumbered by the design deci= sions and assumptions of an existing protocol (PANA).=20 >=20 >=20 > Was there any other concern leading to your above statement? >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: >=20 >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would obje= ct. >>=20 >> YES >>=20 >> 2) Could you *live with* PANA? If not, state reason you would object. >>=20 >> Yes, but we really rather not use PANA. See below... >>=20 >> 3) If you said yes to both 1 and 2, but have a strong preference between= the two, which approach do you prefer and why? >>=20 >> We strongly prefer EAP-in-PCP for several reasons: >>=20 >> * PANA, as we understand it, is not mobile-friendly. It requires the PCP= client to *always* have an authenticated session active and that is wastef= ul on mobile clients when the authentication rekey interval is much shorter= than the mapping lifetime. Margaret Wasserman captured this in slides 13 a= nd 14 of her presentation http://www.ietf.org/proceedings/85/slides/slides-= 85-pcp-17.pdf. We believe the *client* should decide when to authenticate (= because it needs to create or refresh a mapping) because that lets the clie= nt optimize its use of the network and reduce its power consumption.=20 >>=20 >> We understand that a PCP server may need to send a message to the client= when no authenticated session is active. If no authenticated session is ac= tive then we prefer the server send an UN-authenticated "call home" message= directing the client to authenticate and then the server can send its mess= ages over the authenticated channel. We recognize an attacker can induce th= e client to connect to the server by forging an unauthenticated "call home"= message. But, having done that, the client can ignore subsequent forged ca= ll home messages because it will already have an authenticated session. Wor= se case, an attacker can't make EAP-in-PCP consume any more client resource= s than PANA does because PANA requires the client to always have an authent= icated session available. >>=20 >> * PANA requires more server side resources. The authentication protocol = should efficiently support 100,000's of clients on a large PCP server. Why = should the server continuously maintain authenticated sessions with *every*= client? Clients using 24 hour mapping lifetimes can be served by short aut= hentication key lifetime like, for example, 5 minutes. Let the client conne= ct, authenticate, program the mappings, and then let the authenticated sess= ion expire. Rinse and repeat in 24 hours,. Client-driven authentication via= EAP-in-PCP requires less resources on the server because the server can di= scard the authenticated session state once the key lifetime expires. >>=20 >> There was some discussion that PANA is preferable to EAP-in-PCP because = it supports "liveness testing". We don't believe liveness testing is useful= when the server resources consumed, per client, are PCP mappings. Checking= the liveness of 100,000 clients is much more resource intensive on the ser= ver than just keeping the client's mappings around until they expire natura= lly at the end of their lifetime. In short, we believe EAP-in-PCP will scal= e better on the server than PANA. >>=20 >> * We believe the decision to use EAP-in-PCP vs. PANA is a choice between= designing and implementing an EAP-in-PCP transport that is tailored for PC= P versus adapting an existing protocol (PANA) to fit the needs of PCP. We = don't think implementing an EAP-in-PCP transport is difficult so we prefer = it over PANA. EAP-in-PCP provides a clean slate that's unencumbered by the = design decisions and assumptions of an existing protocol (PANA).=20 >>=20 >> -Ben McCann >>=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 ------------------------------------------------------- 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 dwing@cisco.com Thu Jul 18 19:40:17 2013 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 8D62E21E819D for ; Thu, 18 Jul 2013 19:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.47 X-Spam-Level: X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcpDhKbB9DR5 for ; Thu, 18 Jul 2013 19:40:13 -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 EE10821E8138 for ; Thu, 18 Jul 2013 19:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68810; q=dns/txt; s=iport; t=1374201612; x=1375411212; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=AncNdJPUvMJJjRvCwGu3hMPoVJ6Pn0lLvHjR2pm82x8=; b=CbCnnb5eEZK208TKY5XS8A4wmxi1ckdo5dk+lfyTqsnaKOEQZ4LWT9S9 igix9ucL+W3+9h6gNP4uKWXBdFxk+SBY/2eCpXeFnsJkqaomRYKLnfNdG /GAcuYvqvMaa+YvloffAHElIqMwb85y5ra5rMRyjhToXAdZKVTAwwPFCl 4=; X-IronPort-AV: E=Sophos;i="4.89,698,1367971200"; d="scan'208,217";a="83410787" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 19 Jul 2013 02:40:11 +0000 Received: from [10.156.16.29] ([10.156.16.29]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6J2eAWw015427; Fri, 19 Jul 2013 02:40:10 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_0664061B-E324-4932-965D-FC07F80D110A" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Thu, 18 Jul 2013 19:40:10 -0700 Message-Id: <29FF27C0-5713-4DB1-8F4D-41F463BAE27E@cisco.com> References: <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C327@xmb-rcd-x10.cisco.com> <3F1B99E5-B6A0-4149-A58E-0A80838874C1@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C776@xmb-rcd-x10.cisco.com> To: Alper Yegin X-Mailer: Apple Mail (2.1508) Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 19 Jul 2013 02:40:17 -0000 --Apple-Mail=_0664061B-E324-4932-965D-FC07F80D110A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 18, 2013, at 6:43 AM, Alper Yegin wrote: > Hi Tiru, >=20 > I'd expect the PCP proxy to be as transparent and as light-weight as = possible. Therefore, I'd normally expect the policy-based decision be = made and executed on the PCP server.=20 > Besides, PCP server is the real end-point consuming requests of the = PCP client. The PCP proxy is acting on the PCP requests, too, because the PCP proxy = in a home (or a coffee shop) is very likely doing IPv4 NAT for all the = reasons people do IPv4 NAT in homes and coffee shops. When it does = that, it necessarily also needs to change the source port number inside = the PCP request. For a concrete example, consider two hosts in a home, = both listening on TCP/80, and both asking for TCP/80 mappings; one of = them will be first and get what it wants (port 80 on the 'external' side = of the home NAT), the other will get assigned some other port on = 'external' side of the in-home NAT. This gets repeated again on the = ISP's PCP server, if the ISP is also operating its own NAT. > Therefore it is simpler to let the PCP server apply the policy on its = own responses. >=20 > Btw, can the PCP proxy and the PCP server belong to two separate ISPs? > If so, would the PCP server be satisfied if it receives the "user's = authenticated ID", or would it require to authenticate the user itself?=20= The ISP's PCP server does not need to know of the different users within = the home --- exactly like PSTN telephone service where mom (or dad) gets = the bill and anybody in the home can make a long distance phone call to = Timbuktu. The ISP has little business incentive to have that awareness; = the subscriber's CPE (running a PCP proxy) can solve that problem and = know about the NNN users in the home, control things by time-of-day, and = all the other things that are done on sophisticated residential CPE = today. -d >=20 > Alper > =20 >=20 >=20 >=20 > On Jul 18, 2013, at 4:16 PM, Tirumaleswar Reddy (tireddy) wrote: >=20 >> Hi Alper, >> =20 >> Please see inline [TR] >> =20 >> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >> Sent: Thursday, July 18, 2013 1:37 PM >> To: Tirumaleswar Reddy (tireddy) >> Cc: pcp@ietf.org >> Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) >> =20 >> Tiru, >> =20 >> I'm talking about "public WiFi hotspot". Like in coffee shops. >> The PCP proxy and the PCP server are either owned by the same ISP, or = two separate business entities. >> The users who attach to the hotspot are all distinct subscribers with = distinct service plans. This is different than how all members of my = house appears to the ISP, or all employees appears to the enterprise = network administration.=20 >> So, the PCP service provided to each user may differ. Maybe not all = users are allowed to control some certain ports. For PCP server to be = able to act based on the Id of the users, it needs to know who they are = as the requests are proxies by the PCP proxy. >> =20 >> [TR] >> =20 >> If the PCP Proxy and PCP server belong to the same ISP, why can=92t = the PCP Proxy itself enforce the subscriber-based policy ? >> I do not understand why PCP Proxy cannot enforce identity-based = policies for PCP, if you could explain or point to more details how the = topology looks like ?, How PCP Auth works in this use with PCP proxy = works in this use case ? it will help. >> =20 >> Thanks and Regards, >> --Tiru. >> =20 >> Alper >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tireddy) wrote: >>=20 >>=20 >> =20 >> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >> Sent: Wednesday, July 17, 2013 8:07 PM >> To: Prashanth Patil (praspati) >> Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org >> Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) >> =20 >> For the home gateway case, yes I'd think so. >> Could we not apply PCP proxy case to public WiFi hotspots? There in = that case the terminals attaching to the AP are distinct subscribers. >> =20 >> I did not get the use case, though there are distinct subscribers = attached to the WLC (MAG), wouldn=92t WLC act as PCP Proxy and = communicate with the PCP Server in ISP to which it=92s a single = subscriber. >> =20 >> This looks just like Enterprise deployment where there are multiple = users (similar to distinct subscribers attached to AP) communicating = with the PCP server in the Enterprise Network, the PCP server in the = campus would act as PCP proxy communicating with the ISP (PCP Server) to = which it=92s a single subscriber. >> =20 >> --Tiru. >> =20 >> Alper >> =20 >> =20 >> =20 >> On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote: >>=20 >>=20 >>=20 >> Hi Alper, >> In the example below, wont the ISP consider all users behind the home = router as a single subscriber and not differentiate among individual = users? Essentially, the PCP Server would treat the proxy (i.e the home = router) as a single subscriber. >> =20 >> -Prashanth >> =20 >> On 17/07/13 5:02 PM, "Alper Yegin" wrote: >> =20 >> If the PCP server wants to provide some sort of differentiated = service to the subscribers (e.g., different mapping lifetime), then it = needs to know the authenticated ID of the subscriber. >> =20 >> Alper >> =20 >> =20 >> On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: >>=20 >>=20 >>=20 >> Please see inline [TR] >> =20 >> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >> Sent: Wednesday, July 17, 2013 12:24 PM >> To: Prashanth Patil (praspati) >> Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) >> Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) >> =20 >> Hi Prashanth, >> =20 >>=20 >>=20 >>=20 >>=20 >> I'm not sure if enough thought went into the PCP Proxy security. As = much as I'd love to be DONE! with this discussion, I also want to make = sure people feel comfortable having thought all aspects around the proxy = use. For (very important) example, what kind of security associations = are needed for securing the proxy use: An SA btw client and server, an = SA btw client and proxy, an SA btw proxy and server -- which = combinations of these are needed? >> =20 >> We've included this in the updated version of auth req: >> =20 >> REQ-9: A PCP proxy that modifies PCP messages SHOULD have the >> ability to independently authenticate with the PCP client and PCP >> server. The presence of a PCP proxy hence requires two separately >> authenticates SAs. As a consequence, the PCP proxy: >> =20 >> A. MUST be able to validate message integrity of PCP messages >> from the PCP server and client respectively. >> =20 >> B. MUST be able to ensure message integrity after updating the >> PCP message for cases described in sections 6 of ietf-pcp-proxy. >> =20 >> The PCP proxy MUST also permit authentication on only one side of >> the proxy. For example, a customer premises host may not >> authenticate with the PCP proxy but the PCP proxy may authenticate >> with the PCP server. >> =20 >> =20 >> =20 >> So: >> =20 >> - We have two types of SAs. One between the client and the proxy, = another between the proxy and the server. >> - None of them are mandatory to use. >> =20 >> For each one that needs to be used, we need to perform authentication = between the end-points.=20 >> (e.g., between client and proxy). >> =20 >> So, in a way, we are dealing with security in two independent parts; = client to proxy, and proxy to server.=20 >> They are totally segregated from security perspective.=20 >> =20 >> =20 >> Right? >> =20 >> Hmm, one thing: The server may need to know the authenticated ID of = the client. Since it's not part of the client authentication, it won't = know that value readily. So, we may need to define an option to carry = that piece of information from the proxy to the server. >> =20 >> [TR] >> =20 >> Why would the PCP server need to know the authentication ID of the = client. For example Home network; Alice (PCP client) -> Home Router = (PCP Proxy) -> ISP (PCP Server) >> Why would PCP Server in ISP care about the authentication ID of Alice = ? >> =20 >> --Tiru. >> =20 >> Alper >> =20 >> =20 >> =20 >>=20 >>=20 >>=20 >>=20 >> -Prashanth >> =20 >> Then we need to talk about how we dynamically create those using any = one of these solutions. >> =20 >> Alper >> =20 >> =20 >> =20 >> =20 >> =20 >> On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: >> =20 >> -----Original Message----- >> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >> Sent: Monday, July 15, 2013 10:51 PM >> To: Dave Thaler; pcp@ietf.org >> Subject: RE: [pcp] CONSENSUS CALL on PCP security >> Hi Dave, >> In the poll when you refer to PANA, please clarify the draft you are = referring >> to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or >> http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >> --Tiru. >> The question is intentionally agnostic as this is about a general = approach, >> not which specific implementation. If it helps, you can interpret = the >> answer as "which of the two you think is better". >> If the consensus is PANA rather than direct EAP-in-PCP, then we could >> ask as a follow-up question which of the two we should go with. If >> you'd like to include your answer to that now though, feel free to >> include that in your response to the call. >> -Dave >> _______________________________________________ >> 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 --Apple-Mail=_0664061B-E324-4932-965D-FC07F80D110A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 alper.yegin@yegin.org> = wrote:

Hi Tiru,

I'd = expect the PCP proxy to be as transparent and as light-weight as = possible. Therefore, I'd normally expect the policy-based decision be = made and executed on the PCP server. 
Besides, PCP server = is the real end-point consuming requests of the PCP client. =

The PCP proxy is acting on = the PCP requests, too, because the PCP proxy in a home (or a coffee = shop) is very likely doing IPv4 NAT for all the reasons people do IPv4 = NAT in homes and coffee shops.  When it does that, it necessarily = also needs to change the source port number inside the PCP request. =  For a concrete example, consider two hosts in a home, both = listening on TCP/80, and both asking for TCP/80 mappings; one of them = will be first and get what it wants (port 80 on the 'external' side of = the home NAT), the other will get assigned some other port on 'external' = side of the in-home NAT.  This gets repeated again on the ISP's PCP = server, if the ISP is also operating its own = NAT.

Therefore it is simpler to = let the PCP server apply the policy on its own = responses.

Btw, can the PCP proxy and the PCP = server belong to two separate ISPs?
If so, would the PCP = server be satisfied if it receives the "user's authenticated ID", or = would it require to authenticate the user = itself? 

The ISP's PCP = server does not need to know of the different users within the home --- = exactly like PSTN telephone service where mom (or dad) gets the bill and = anybody in the home can make a long distance phone call to Timbuktu. The = ISP has little business incentive to have that awareness; the = subscriber's CPE (running a PCP proxy) can solve that problem and know = about the NNN users in the home, control things by time-of-day, and all = the other things that are done on sophisticated residential CPE = today.

-d


Hi = Alper,
Please see inline = [TR]
 Alper = Yegin [mailto:alper.yegin@yegin.org] 
Sent: Thursday, July 18, 2013 = 1:37 PM
To: Tirumaleswar Reddy = (tireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp] Proxy security = (was Re: CONSENSUS CALL on PCP = security)
Tiru,
 
I'm talking about "public WiFi hotspot". Like in coffee = shops.
The PCP proxy and the PCP = server are either owned by the same ISP, or two separate business = entities.
The users who attach to = the hotspot are all distinct subscribers with distinct service plans. = This is different than how all members of my house appears to the ISP, = or all employees appears to the enterprise network = administration. 
So, the PCP = service provided to each user may differ. Maybe not all users are = allowed to control some certain ports.  For PCP server to be able = to act based on the Id of the users, it needs to know who they are as = the requests are proxies by the PCP proxy.
 
[TR]
 
If the PCP Proxy and PCP server = belong to the same ISP, why can=92t the PCP Proxy itself enforce the = subscriber-based policy ?
I do not understand why PCP Proxy cannot enforce = identity-based policies for PCP, if you could explain or point to more = details how the topology looks like ?, How PCP Auth works in this use = with PCP proxy works in this use case ? it will = help.
Thanks and = Regards,
On Jul 18, 2013, at 9:37 = AM, Tirumaleswar Reddy (tireddy) wrote:


From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 = 8:07 PM
To: Prashanth Patil = (praspati)
Cc: Tirumaleswar Reddy = (tireddy); pcp@ietf.org
Subject: Re: [pcp] Proxy security = (was Re: CONSENSUS CALL on PCP = security)
 
For the home gateway case, yes I'd think = so.
Could we not apply PCP = proxy case to public WiFi hotspots? There in that case the terminals = attaching to the AP are distinct = subscribers.
I did not get the use case, though there are = distinct subscribers attached to the WLC (MAG), wouldn=92t WLC act as = PCP Proxy and communicate with the PCP Server in ISP to which it=92s a = single subscriber.
This looks just like Enterprise deployment where = there are multiple users (similar to distinct subscribers attached to = AP) communicating with the PCP server in the Enterprise Network, the PCP = server in the campus would act as PCP proxy communicating with the ISP = (PCP Server) to which it=92s a single = subscriber.
 
 
Alper
 
 
 
On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) = wrote:
Hi = Alper,
In the example below, wont = the ISP consider all users behind the home router as a single subscriber = and not differentiate among individual users? Essentially, the PCP = Server would treat the proxy (i.e the home router) as a single = subscriber.
On = 17/07/13 5:02 PM, "Alper Yegin" <alper.yegin@yegin.org> = wrote:
If the = PCP server wants to provide some sort of differentiated service to the = subscribers (e.g., different mapping lifetime), then it needs to know = the authenticated ID of the = subscriber.
On Jul = 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) = wrote:
Please see inline = [TR]
From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 = 12:24 PM
To: Prashanth Patil = (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy = (tireddy)
Subject: [pcp] Proxy security (was = Re: CONSENSUS CALL on PCP = security)
 
Hi = Prashanth,
 




I'm not sure if enough thought went into the PCP Proxy = security. As much as I'd love to be DONE! with this discussion, I also = want to make sure people feel comfortable having thought all aspects = around the proxy use. For (very important) example, what kind of = security associations are needed for securing the proxy use: An SA btw = client and server, an SA btw client and proxy, an SA btw proxy and = server -- which combinations of these are = needed?
We've included this in the = updated version of auth req:
REQ-9: A PCP proxy that modifies PCP messages = SHOULD have the
ability to independently authenticate with the = PCP client and PCP
server. The presence of a PCP proxy hence = requires two separately
authenticates SAs. As a consequence, the PCP = proxy:
A. MUST = be able to validate message integrity of PCP = messages
from the = PCP server and client = respectively.
B. MUST = be able to ensure message integrity after updating = the
PCP = message for cases described in sections 6 = of ietf-pcp-proxy.
The PCP = proxy MUST also permit authentication on only one side = of
the = proxy. For example, a customer premises host may = not
with the PCP = server.
 
 
 
So:
 
- We have two types of SAs. One = between the client and the proxy, another between the proxy and the = server.
- None = of them are mandatory to use.
 
For each one that needs to be used, we = need to perform authentication between the = end-points. 
(e.g., between client and = proxy).
 
So, in a way, we are dealing with = security in two independent parts; client to proxy, and proxy to = server. 
They are totally segregated from security = perspective. 
 
 
Right?
 
Hmm, one thing: The server may need to = know the authenticated ID of the client. Since it's not part of the = client authentication, it won't know that value readily. So, we may need = to define an option to carry that piece of information from the proxy to = the server.
 
Why would the PCP server need to know the = authentication ID of the client. For example Home network;   = Alice (PCP client) -> Home Router (PCP Proxy) -> ISP (PCP = Server)
Why = would PCP Server in ISP care about the authentication ID of Alice = ?
--Tiru.
 
Alper
 
 
 




-Prashanth
 
Then we need to talk about = how we dynamically create those using any one of these = solutions.
On Jul = 16, 2013, at 7:50 PM, Dave Thaler = wrote:
-----Original = Message-----
From: = Tirumaleswar Reddy (tireddy) [Sent: Monday, July 15, 2013 10:51 = PM
Subject: RE: [pcp] CONSENSUS CALL on PCP = security
Hi = Dave,
In the poll when you refer = to PANA, please clarify the draft you are = referring
pcp@ietf.org
https://www.ietf.org/mail= man/listinfo/pcp

= --Apple-Mail=_0664061B-E324-4932-965D-FC07F80D110A-- From alper.yegin@yegin.org Fri Jul 19 05:34:28 2013 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 00F9E11E810E for ; Fri, 19 Jul 2013 05:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4hUygwlYUHA for ; Fri, 19 Jul 2013 05:34:23 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1D90B11E8115 for ; Fri, 19 Jul 2013 05:34:22 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LuOlj-1U273T3kYB-010x6E; Fri, 19 Jul 2013 08:34:21 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_35976487-6C5A-41AA-918C-33478796A283" From: Alper Yegin In-Reply-To: <29FF27C0-5713-4DB1-8F4D-41F463BAE27E@cisco.com> Date: Fri, 19 Jul 2013 15:34:11 +0300 Message-Id: References: <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C327@xmb-rcd-x10.cisco.com> <3F1B99E5-B6A0-4149-A58E-0A80838874C1@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C776@xmb-rcd-x10.cisco.com> <29FF27C0-5713-4DB1-8F4D-41F463BAE27E@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:eEgb1hFugYAmVYAGWTujzCiOuSeJVmvo4u8gRiogG4n osg8+Gzq7+56NJnkHtpQ76cpT1ouAchgNWO7voUyNGwtJc9BiP zbiQyBzkTKUfi31LeeaZi18fsbkU2Zgx7EYhXFsgS11Hhgs4YI aZKjO3WbQxjlDrCOXXSVKIG3VcBR+5Nwk6P8EAfHN/irBlV8o3 IzP/l8/E91fcev+gIAn3Tn88O6Z1BnWIpCDUFsCfWcY3CroipS KAVP4FfKAwPew+4p66TIxmow97QYfq16rsGPtEsEZe9tJIhMAa U3AEZOsAAEMMNyBLGYBse9fFzkjH8JZJAraeunhZE02eK3kRhv YRHvaS9pYMpxPKWjWqFLezV/DY25OzLVxmPPIetkOjR9sMnU9j nIsYNkP+2POkg== Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 19 Jul 2013 12:34:28 -0000 --Apple-Mail=_35976487-6C5A-41AA-918C-33478796A283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 19, 2013, at 5:40 AM, Dan Wing wrote: >=20 > On Jul 18, 2013, at 6:43 AM, Alper Yegin = wrote: >=20 >> Hi Tiru, >>=20 >> I'd expect the PCP proxy to be as transparent and as light-weight as = possible. Therefore, I'd normally expect the policy-based decision be = made and executed on the PCP server.=20 >> Besides, PCP server is the real end-point consuming requests of the = PCP client. >=20 > The PCP proxy is acting on the PCP requests, too, because the PCP = proxy in a home (or a coffee shop) is very likely doing IPv4 NAT for all = the reasons people do IPv4 NAT in homes and coffee shops. When it does = that, it necessarily also needs to change the source port number inside = the PCP request. For a concrete example, consider two hosts in a home, = both listening on TCP/80, and both asking for TCP/80 mappings; one of = them will be first and get what it wants (port 80 on the 'external' side = of the home NAT), the other will get assigned some other port on = 'external' side of the in-home NAT. This gets repeated again on the = ISP's PCP server, if the ISP is also operating its own NAT. >=20 OK. I think I was confused about the term "proxy". Now I understand this is about controlling a chain of NATs.=20 It's not like one node is proxying messages for another node, but one = node is doing its own thing, and passing the message further up for the = other node to do its own thing. The roles of the two nodes are quite equivalent, not like one is simply = forwarding messages back and forth. Going back to your port 80 example, maybe the first gold user will get = the port 80 and never a silver user is allowed to get it. For that, the PCP server also needs to know the identity of the users. Alper >> Therefore it is simpler to let the PCP server apply the policy on its = own responses. >>=20 >> Btw, can the PCP proxy and the PCP server belong to two separate = ISPs? >> If so, would the PCP server be satisfied if it receives the "user's = authenticated ID", or would it require to authenticate the user itself?=20= >=20 > The ISP's PCP server does not need to know of the different users = within the home --- exactly like PSTN telephone service where mom (or = dad) gets the bill and anybody in the home can make a long distance = phone call to Timbuktu. The ISP has little business incentive to have = that awareness; the subscriber's CPE (running a PCP proxy) can solve = that problem and know about the NNN users in the home, control things by = time-of-day, and all the other things that are done on sophisticated = residential CPE today. >=20 Alper > -d >=20 >=20 >>=20 >> Alper >> =20 >>=20 >>=20 >>=20 >> On Jul 18, 2013, at 4:16 PM, Tirumaleswar Reddy (tireddy) wrote: >>=20 >>> Hi Alper, >>> =20 >>> Please see inline [TR] >>> =20 >>> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >>> Sent: Thursday, July 18, 2013 1:37 PM >>> To: Tirumaleswar Reddy (tireddy) >>> Cc: pcp@ietf.org >>> Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) >>> =20 >>> Tiru, >>> =20 >>> I'm talking about "public WiFi hotspot". Like in coffee shops. >>> The PCP proxy and the PCP server are either owned by the same ISP, = or two separate business entities. >>> The users who attach to the hotspot are all distinct subscribers = with distinct service plans. This is different than how all members of = my house appears to the ISP, or all employees appears to the enterprise = network administration.=20 >>> So, the PCP service provided to each user may differ. Maybe not all = users are allowed to control some certain ports. For PCP server to be = able to act based on the Id of the users, it needs to know who they are = as the requests are proxies by the PCP proxy. >>> =20 >>> [TR] >>> =20 >>> If the PCP Proxy and PCP server belong to the same ISP, why can=92t = the PCP Proxy itself enforce the subscriber-based policy ? >>> I do not understand why PCP Proxy cannot enforce identity-based = policies for PCP, if you could explain or point to more details how the = topology looks like ?, How PCP Auth works in this use with PCP proxy = works in this use case ? it will help. >>> =20 >>> Thanks and Regards, >>> --Tiru. >>> =20 >>> Alper >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tireddy) wrote: >>>=20 >>>=20 >>> =20 >>> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >>> Sent: Wednesday, July 17, 2013 8:07 PM >>> To: Prashanth Patil (praspati) >>> Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org >>> Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) >>> =20 >>> For the home gateway case, yes I'd think so. >>> Could we not apply PCP proxy case to public WiFi hotspots? There in = that case the terminals attaching to the AP are distinct subscribers. >>> =20 >>> I did not get the use case, though there are distinct subscribers = attached to the WLC (MAG), wouldn=92t WLC act as PCP Proxy and = communicate with the PCP Server in ISP to which it=92s a single = subscriber. >>> =20 >>> This looks just like Enterprise deployment where there are multiple = users (similar to distinct subscribers attached to AP) communicating = with the PCP server in the Enterprise Network, the PCP server in the = campus would act as PCP proxy communicating with the ISP (PCP Server) to = which it=92s a single subscriber. >>> =20 >>> --Tiru. >>> =20 >>> Alper >>> =20 >>> =20 >>> =20 >>> On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote: >>>=20 >>>=20 >>>=20 >>> Hi Alper, >>> In the example below, wont the ISP consider all users behind the = home router as a single subscriber and not differentiate among = individual users? Essentially, the PCP Server would treat the proxy (i.e = the home router) as a single subscriber. >>> =20 >>> -Prashanth >>> =20 >>> On 17/07/13 5:02 PM, "Alper Yegin" wrote: >>> =20 >>> If the PCP server wants to provide some sort of differentiated = service to the subscribers (e.g., different mapping lifetime), then it = needs to know the authenticated ID of the subscriber. >>> =20 >>> Alper >>> =20 >>> =20 >>> On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote: >>>=20 >>>=20 >>>=20 >>> Please see inline [TR] >>> =20 >>> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >>> Sent: Wednesday, July 17, 2013 12:24 PM >>> To: Prashanth Patil (praspati) >>> Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) >>> Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP = security) >>> =20 >>> Hi Prashanth, >>> =20 >>>=20 >>>=20 >>>=20 >>>=20 >>> I'm not sure if enough thought went into the PCP Proxy security. As = much as I'd love to be DONE! with this discussion, I also want to make = sure people feel comfortable having thought all aspects around the proxy = use. For (very important) example, what kind of security associations = are needed for securing the proxy use: An SA btw client and server, an = SA btw client and proxy, an SA btw proxy and server -- which = combinations of these are needed? >>> =20 >>> We've included this in the updated version of auth req: >>> =20 >>> REQ-9: A PCP proxy that modifies PCP messages SHOULD have the >>> ability to independently authenticate with the PCP client and PCP >>> server. The presence of a PCP proxy hence requires two separately >>> authenticates SAs. As a consequence, the PCP proxy: >>> =20 >>> A. MUST be able to validate message integrity of PCP messages >>> from the PCP server and client respectively. >>> =20 >>> B. MUST be able to ensure message integrity after updating the >>> PCP message for cases described in sections 6 of ietf-pcp-proxy. >>> =20 >>> The PCP proxy MUST also permit authentication on only one side of >>> the proxy. For example, a customer premises host may not >>> authenticate with the PCP proxy but the PCP proxy may authenticate >>> with the PCP server. >>> =20 >>> =20 >>> =20 >>> So: >>> =20 >>> - We have two types of SAs. One between the client and the proxy, = another between the proxy and the server. >>> - None of them are mandatory to use. >>> =20 >>> For each one that needs to be used, we need to perform = authentication between the end-points.=20 >>> (e.g., between client and proxy). >>> =20 >>> So, in a way, we are dealing with security in two independent parts; = client to proxy, and proxy to server.=20 >>> They are totally segregated from security perspective.=20 >>> =20 >>> =20 >>> Right? >>> =20 >>> Hmm, one thing: The server may need to know the authenticated ID of = the client. Since it's not part of the client authentication, it won't = know that value readily. So, we may need to define an option to carry = that piece of information from the proxy to the server. >>> =20 >>> [TR] >>> =20 >>> Why would the PCP server need to know the authentication ID of the = client. For example Home network; Alice (PCP client) -> Home Router = (PCP Proxy) -> ISP (PCP Server) >>> Why would PCP Server in ISP care about the authentication ID of = Alice ? >>> =20 >>> --Tiru. >>> =20 >>> Alper >>> =20 >>> =20 >>> =20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -Prashanth >>> =20 >>> Then we need to talk about how we dynamically create those using any = one of these solutions. >>> =20 >>> Alper >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: >>> =20 >>> -----Original Message----- >>> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >>> Sent: Monday, July 15, 2013 10:51 PM >>> To: Dave Thaler; pcp@ietf.org >>> Subject: RE: [pcp] CONSENSUS CALL on PCP security >>> Hi Dave, >>> In the poll when you refer to PANA, please clarify the draft you are = referring >>> to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or >>> http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >>> --Tiru. >>> The question is intentionally agnostic as this is about a general = approach, >>> not which specific implementation. If it helps, you can interpret = the >>> answer as "which of the two you think is better". >>> If the consensus is PANA rather than direct EAP-in-PCP, then we = could >>> ask as a follow-up question which of the two we should go with. If >>> you'd like to include your answer to that now though, feel free to >>> include that in your response to the call. >>> -Dave >>> _______________________________________________ >>> 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 --Apple-Mail=_35976487-6C5A-41AA-918C-33478796A283 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
alper.yegin@yegin.org> = wrote:

Hi Tiru,

I'd = expect the PCP proxy to be as transparent and as light-weight as = possible. Therefore, I'd normally expect the policy-based decision be = made and executed on the PCP server. 
Besides, PCP server = is the real end-point consuming requests of the PCP client. =

The PCP proxy is acting on = the PCP requests, too, because the PCP proxy in a home (or a coffee = shop) is very likely doing IPv4 NAT for all the reasons people do IPv4 = NAT in homes and coffee shops.  When it does that, it necessarily = also needs to change the source port number inside the PCP request. =  For a concrete example, consider two hosts in a home, both = listening on TCP/80, and both asking for TCP/80 mappings; one of them = will be first and get what it wants (port 80 on the 'external' side of = the home NAT), the other will get assigned some other port on 'external' = side of the in-home NAT.  This gets repeated again on the ISP's PCP = server, if the ISP is also operating its own = NAT.


OK. = I think I was confused about the term "proxy".
Now I = understand this is about controlling a chain of = NATs. 
It's not like one node is proxying messages for = another node, but one node is doing its own thing, and passing the = message further up for the other node to do its own thing.
The = roles of the two nodes are quite equivalent, not like one is simply = forwarding messages back and forth.

Going back = to your port 80 example, maybe the first gold user will get the port 80 = and never a silver user is allowed to get it.
For that, the = PCP server also needs to know the identity of the = users.

Alper


<= div>

Therefore it is simpler to = let the PCP server apply the policy on its own = responses.

Btw, can the PCP proxy and the PCP = server belong to two separate ISPs?
If so, would the PCP = server be satisfied if it receives the "user's authenticated ID", or = would it require to authenticate the user = itself? 

The ISP's PCP = server does not need to know of the different users within the home --- = exactly like PSTN telephone service where mom (or dad) gets the bill and = anybody in the home can make a long distance phone call to Timbuktu. The = ISP has little business incentive to have that awareness; the = subscriber's CPE (running a PCP proxy) can solve that problem and know = about the NNN users in the home, control things by time-of-day, and all = the other things that are done on sophisticated residential CPE = today.


Al= per




=



Hi = Alper,
Please see inline = [TR]
 Alper = Yegin [mailto:alper.yegin@yegin.org] 
Sent: Thursday, July 18, 2013 = 1:37 PM
To: Tirumaleswar Reddy = (tireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp] Proxy security = (was Re: CONSENSUS CALL on PCP = security)
Tiru,
 
I'm talking about "public WiFi hotspot". Like in coffee = shops.
The PCP proxy and the PCP = server are either owned by the same ISP, or two separate business = entities.
The users who attach to = the hotspot are all distinct subscribers with distinct service plans. = This is different than how all members of my house appears to the ISP, = or all employees appears to the enterprise network = administration. 
So, the PCP = service provided to each user may differ. Maybe not all users are = allowed to control some certain ports.  For PCP server to be able = to act based on the Id of the users, it needs to know who they are as = the requests are proxies by the PCP proxy.
 
[TR]
 
If the PCP Proxy and PCP server = belong to the same ISP, why can=92t the PCP Proxy itself enforce the = subscriber-based policy ?
I do not understand why PCP Proxy cannot enforce = identity-based policies for PCP, if you could explain or point to more = details how the topology looks like ?, How PCP Auth works in this use = with PCP proxy works in this use case ? it will = help.
Thanks and = Regards,
On Jul 18, 2013, at 9:37 = AM, Tirumaleswar Reddy (tireddy) wrote:


From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 = 8:07 PM
To: Prashanth Patil = (praspati)
Cc: Tirumaleswar Reddy = (tireddy); pcp@ietf.org
Subject: Re: [pcp] Proxy security = (was Re: CONSENSUS CALL on PCP = security)
 
For the home gateway case, yes I'd think = so.
Could we not apply PCP = proxy case to public WiFi hotspots? There in that case the terminals = attaching to the AP are distinct = subscribers.
I did not get the use case, though there are = distinct subscribers attached to the WLC (MAG), wouldn=92t WLC act as = PCP Proxy and communicate with the PCP Server in ISP to which it=92s a = single subscriber.
This looks just like Enterprise deployment where = there are multiple users (similar to distinct subscribers attached to = AP) communicating with the PCP server in the Enterprise Network, the PCP = server in the campus would act as PCP proxy communicating with the ISP = (PCP Server) to which it=92s a single = subscriber.
 
 
Alper
 
 
 
On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) = wrote:
Hi = Alper,
In the example below, wont = the ISP consider all users behind the home router as a single subscriber = and not differentiate among individual users? Essentially, the PCP = Server would treat the proxy (i.e the home router) as a single = subscriber.
On = 17/07/13 5:02 PM, "Alper Yegin" <alper.yegin@yegin.org> = wrote:
If the = PCP server wants to provide some sort of differentiated service to the = subscribers (e.g., different mapping lifetime), then it needs to know = the authenticated ID of the = subscriber.
On Jul = 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) = wrote:
Please see inline = [TR]
From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, July 17, 2013 = 12:24 PM
To: Prashanth Patil = (praspati)
Cc: pcp@ietf.org; Tirumaleswar Reddy = (tireddy)
Subject: [pcp] Proxy security (was = Re: CONSENSUS CALL on PCP = security)
 
Hi = Prashanth,
 




I'm not sure if enough thought went into the PCP Proxy = security. As much as I'd love to be DONE! with this discussion, I also = want to make sure people feel comfortable having thought all aspects = around the proxy use. For (very important) example, what kind of = security associations are needed for securing the proxy use: An SA btw = client and server, an SA btw client and proxy, an SA btw proxy and = server -- which combinations of these are = needed?
We've included this in the = updated version of auth req:
REQ-9: A PCP proxy that modifies PCP messages = SHOULD have the
ability to independently authenticate with the = PCP client and PCP
server. The presence of a PCP proxy hence = requires two separately
authenticates SAs. As a consequence, the PCP = proxy:
A. MUST = be able to validate message integrity of PCP = messages
from the = PCP server and client = respectively.
B. MUST = be able to ensure message integrity after updating = the
PCP = message for cases described in sections 6 = of ietf-pcp-proxy.
The PCP = proxy MUST also permit authentication on only one side = of
the = proxy. For example, a customer premises host may = not
with the PCP = server.
 
 
 
So:
 
- We have two types of SAs. One = between the client and the proxy, another between the proxy and the = server.
- None = of them are mandatory to use.
 
For each one that needs to be used, we = need to perform authentication between the = end-points. 
(e.g., between client and = proxy).
 
So, in a way, we are dealing with = security in two independent parts; client to proxy, and proxy to = server. 
They are totally segregated from security = perspective. 
 
 
Right?
 
Hmm, one thing: The server may need to = know the authenticated ID of the client. Since it's not part of the = client authentication, it won't know that value readily. So, we may need = to define an option to carry that piece of information from the proxy to = the server.
 
Why would the PCP server need to know the = authentication ID of the client. For example Home network;   = Alice (PCP client) -> Home Router (PCP Proxy) -> ISP (PCP = Server)
Why = would PCP Server in ISP care about the authentication ID of Alice = ?
--Tiru.
 
Alper
 
 
 




-Prashanth
 
Then we need to talk about = how we dynamically create those using any one of these = solutions.
On Jul = 16, 2013, at 7:50 PM, Dave Thaler = wrote:
-----Original = Message-----
From: = Tirumaleswar Reddy (tireddy) [Sent: Monday, July 15, 2013 10:51 = PM
Subject: RE: [pcp] CONSENSUS CALL on PCP = security
Hi = Dave,
In the poll when you refer = to PANA, please clarify the draft you are = referring
=
= --Apple-Mail=_35976487-6C5A-41AA-918C-33478796A283-- From praspati@cisco.com Fri Jul 19 05:56:53 2013 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 9EBB511E8103 for ; Fri, 19 Jul 2013 05:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.373 X-Spam-Level: X-Spam-Status: No, score=-9.373 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqzfEzq4O40q for ; Fri, 19 Jul 2013 05:56:48 -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 DD9E911E8117 for ; Fri, 19 Jul 2013 05:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67674; q=dns/txt; s=iport; t=1374238608; x=1375448208; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=03MOMiQCPbJvjSn87V6eKNPPDAOhpJWQ202qGQ+YFc4=; b=EcjEBZu9SGE76wrkTrSDDh83Ic1ozmGbZKgwyfQ+h0a01EbQxqROy2fa a6JAdmFbZu6zKlywrHkIQieC6A7nh+tUYvEEd5vULeM1lHaWnSfSWZwLu 7p0aM2J68CetjLx5ZwHtzaohoJ0+eajCOvSvAkhX3rnOqZBSiMTnHk8tX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFAEs36VGtJXG+/2dsb2JhbABagkJENVCDB7UDiDwXeRZ0giQBAQEEAQEBCSFBCwwGAQYCEQQBAQsWAQYFBCULFAkIAgQBDQUIE4d1DIlrmzUOkUePXhYXBAYBBoJOPG4DgU2XOZAkgxKBaiQc X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208,217";a="236931337" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 19 Jul 2013 12:56:32 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6JCuV7F003281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 12:56:31 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 07:56:31 -0500 From: "Prashanth Patil (praspati)" To: "yoshihiro.ohba@toshiba.co.jp" , "alper.yegin@yegin.org" Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOg7xOgyVOTGpo0E674JzHPKIxG5lrOpsA//+o/oCAAGsmgP//5caAgAFyyoA= Date: Fri, 19 Jul 2013 12:56:31 +0000 Message-ID: In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D31838@tgxml338.toshiba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.68.21.116] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE33C90xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 19 Jul 2013 12:56:53 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE33C90xmbrcdx07ciscoc_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 RGlzdHJpYnV0aW9uIGlzIG5vdCBhIGdvb2QgYXBwcm9hY2gsIGJyaW5ncyBpbiB0b28gbWFueSBh ZGRpdGlvbmFsIHByb2JsZW1zLiBIb3cgZG9lcyB0aGUgUENQIFNlcnZlciB0cnVzdCB0aGUgcHJv eHksIGhvdyBpcyB0aGUga2V5IGRpc3RyaWJ1dGVkLCBzaG91bGQgaXQgYWxsIGJlIGZhY2lsaXRh dGVkIG92ZXIgUENQIGV0YyA/DQoNClRoZSBhYm92ZSBwcm9ibGVtcyBhc2lkZSwgYXMgYmVpbmcg ZGlzY3Vzc2VkIGluIG90aGVyIHRocmVhZHMsIHRoZSByb2xlIG9mIHRoZSBQQ1AgcHJveHkgaXMg bm90IGp1c3QgdGhhdCBvZiBmb3J3YXJkaW5nIGJ1dCBhbHNvIGFjdGluZyBvbiB0aGUgcmVxdWVz dCwgaW5zdGFsbGluZyBzdGF0ZSBldGMgYW5kIGRvZXMgYWxsIG9mIHRoaXMgYmFzZWQgb24gaXRz IG93biBwb2xpY3kuIEFsc28sIGFuIElTUCdzIFBDUCBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0byBr bm93IG9mIHRoZSBkaWZmZXJlbnQgdXNlcnMgd2l0aGluIHRoZSBob21lIGFuZCBoYXMgbm8gaW5j ZW50aXZlIHRvIGluZGl2aWR1YWxseSBhdXRoZW50aWNhdGUgZWFjaCBvZiB0aG9zZSBkaWZmZXJl bnQgdXNlcnMgoVYgaXQncyBvbmx5IGludGVyZXN0aW5nIHRvIHRoZSBwcm94eSAodGhlIFBDUCBz ZXJ2ZXIgYXMgZmFyIGFzIHRoZSBpbmRpdmlkdWFsIGhvbWUgdXNlcnMgYXJlIGNvbmNlcm5lZCku DQpGb3IgYWxsIHRoZXNlIHJlYXNvbnMsIHRoZSB0d28gbGVncyBhcmUgaW5kZXBlbmRlbnQgYW5k IG5lZWQgdG8gaGF2ZSBpbmRlcGVuZGVudCBhdXRoZW50aWNhdGlvbi4NCg0KLVByYXNoYW50aA0K DQpPbiAxOS8wNy8xMyAxOjQ5IEFNLCAieW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcDxtYWls dG86eW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcD4iIDx5b3NoaWhpcm8ub2hiYUB0b3NoaWJh LmNvLmpwPG1haWx0bzp5b3NoaWhpcm8ub2hiYUB0b3NoaWJhLmNvLmpwPj4gd3JvdGU6DQoNCldl bGwsIHRoYXQgaXMgZWFzeTogT25jZSB0aGUgUENQIHNlcnZlciBzdWNjZXNzZnVsbHkgYXV0aGVu dGljYXRlIGEgUENQIGNsaWVudCwgaXQgZGlzdHJpYnV0ZXMgYSBrZXkgdXNlZCBmb3IgcHJvdGVj dGluZyBQQ1AgbWVzc2FnZSBiZXR3ZWVuIHRoZSBQQ1AgY2xpZW50IGFuZCB0aGUgUENQIHByb3h5 IHRvIHRoZSBQQ1AgcHJveHkgaW4gYSBzZWN1cmUgd2F5Lg0KDQpSZWdhcmRzLA0KWW9zaGloaXJv IE9oYmENCg0KDQpGcm9tOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKSBbbWFpbHRvOnByYXNw YXRpQGNpc2NvLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVseSAxOSwgMjAxMyAxOjIzIEFNDQpUbzog b2hiYSB5b3NoaWhpcm87IGFscGVyLnllZ2luQHllZ2luLm9yZzxtYWlsdG86YWxwZXIueWVnaW5A eWVnaW4ub3JnPg0KQ2M6IHBjcEBpZXRmLm9yZzxtYWlsdG86cGNwQGlldGYub3JnPjsgVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KU3ViamVjdDogUmU6IFtwY3BdIFByb3h5IHNlY3VyaXR5 ICh3YXMgUmU6IENPTlNFTlNVUyBDQUxMIG9uIFBDUCBzZWN1cml0eSkNCg0KSGkgWW9zaGloaXJv LA0KDQpPbiAxOC8wNy8xMyA4OjU5IFBNLCAieW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcDxt YWlsdG86eW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcD4iIDx5b3NoaWhpcm8ub2hiYUB0b3No aWJhLmNvLmpwPG1haWx0bzp5b3NoaWhpcm8ub2hiYUB0b3NoaWJhLmNvLmpwPj4gd3JvdGU6DQoN CkhpIFByYXNoYW50aCwNCg0KDQpGcm9tOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKSBbbWFp bHRvOnByYXNwYXRpQGNpc2NvLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVseSAxOSwgMjAxMyAxMjox MSBBTQ0KVG86IG9oYmEgeW9zaGloaXJvKKRqs/W4cax2obOi4KLSotGhvKLcouGi2ik7IGFscGVy LnllZ2luQHllZ2luLm9yZzxtYWlsdG86YWxwZXIueWVnaW5AeWVnaW4ub3JnPg0KQ2M6IHBjcEBp ZXRmLm9yZzxtYWlsdG86cGNwQGlldGYub3JnPjsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KQ0KU3ViamVjdDogUmU6IFtwY3BdIFByb3h5IHNlY3VyaXR5ICh3YXMgUmU6IENPTlNFTlNVUyBD QUxMIG9uIFBDUCBzZWN1cml0eSkNCg0KSGkgWW9zaGloaXJvLA0KQWx0aG91Z2ggdGhlIGFic3Ry YWN0IHNheXMgdGhhdCwgSSBkb26hpnQgdGhpbmsgdGhlIGludGVudCBpcyBmb3IgdGhlIFBDUCBQ cm94eSB0byBqdXN0IGJlIGEgcmVsYXkgYWdlbnQuIEl0IGlzIGNsZWFyIGZyb20gb3RoZXIgc2Vj dGlvbnMgb2YgdGhlIGRyYWZ0IHRoYXQgdGhlIHByb3h5IGlzIGluZGVlZCBhIHNlcnZlciBhbmQg bmVlZHMgdG8gbW9kaWZ5IGZpZWxkcyAoYWxiZWl0IG1pbmltYWwpIGJlZm9yZSBmb3J3YXJkaW5n IHRoZW0gdG8gdGhlIGFjdHVhbCBzZXJ2ZXIuIFRoaXMgaW1wbGllcyB0d28gaW5kZXBlbmRlbnQg YXV0aGVudGljYXRpb25zIG5lZWQgdG8gaGFwcGVuLg0KW1lPXSBJIGRvbqGmdCB1bmRlcnN0YW5k IHlvdXIgbG9naWMgaGVyZS4gRXZlbiBhbiBodHRwIHByb3h5IGNhbiBtb2RpZnkgaHR0cCByZXF1 ZXN0cyAoZS5nLiwgWC1Gb3J3YXJkZWQtRm9yIGhlYWRlciksIGFuZCBhbiBodHRwIHNlcnZlciBj YW4gc3RpbGwgYXV0aGVudGljYXRlIGh0dHAgY2xpZW50cyBiZWhpbmQgdGhlIHByb3h5Lg0KDQpI b3cgZG9lcyB0aGUgcHJveHkgbWFpbnRhaW4gbWVzc2FnZSBpbnRlZ3JpdHkgaWYgaXQgbW9kaWZp ZXMgcmVxdWVzdHMvcmVzcG9uc2VzPyBUaGUgY2FzZSBpcyBkaWZmZXJlbnQgd2l0aCBIVFRQLg0K DQotUHJhc2hhbnRoDQoNCllvc2hpaGlybyBPaGJhDQoNCi1QcmFzaGFudGgNCg0KT24gMTgvMDcv MTMgNzowOSBQTSwgInlvc2hpaGlyby5vaGJhQHRvc2hpYmEuY28uanA8bWFpbHRvOnlvc2hpaGly by5vaGJhQHRvc2hpYmEuY28uanA+IiA8eW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcDxtYWls dG86eW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcD4+IHdyb3RlOg0KDQpIaSBUaXJ1LA0KDQpB YnN0cmFjdCBvZiBwY3AtcHJveHkgZHJhZnQgc2F5czoNCg0KoacNCiAgIFRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIGEgbmV3IFBDUCBmdW5jdGlvbmFsIGVsZW1lbnQgZGVub3RlZCBhcyBQQ1ANCiAg IFByb3h5LiAgVGhlIFBDUCBQcm94eSByZWxheXMgUENQIHJlcXVlc3RzIHJlY2VpdmVkIGZyb20g UENQIENsaWVudHMNCiAgIHRvIHVwc3RyZWFtIFBDUCBTZXJ2ZXIocykuICBUaGlzIGZ1bmN0aW9u IGlzIG1hbmRhdG9yeSB3aGVuIFBDUA0KICAgQ2xpZW50cyBjYW4gbm90IGJlIGNvbmZpZ3VyZWQg d2l0aCB0aGUgYWRkcmVzcyBvZiB0aGUgUENQIFNlcnZlcg0KICAgbG9jYXRlZCBtb3JlIHRoYW4g b25lIGhvcC4NCqGnDQoNCklmIHRoaXMgYWJzdHJhY3QgaXMgY29ycmVjdCwgSSBpbnRlcnByZXQg dGhhdCBQQ1AgY2xpZW50cyBvbmx5IGtub3cgdGhlIFBDUCBwcm94eaGmcyBhZGRyZXNzLCBidXQg dGhlIFBDUCBzZXJ2ZXIgKmNhbiogYmUgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZC1wb2ludCBmb3Ig dGhlIFBDUCBjbGllbnRzLiAgVGhpcyBpcyBzaW1pbGFyIHRvIHRoZSBodHRwIHByb3h5IGNhc2Ug d2hlcmUgaHR0cCBzZXJ2ZXJzIGFyZSB0aGUgYXV0aGVudGljYXRpb24gZW5kLXBvaW50cyBmb3Ig aHR0cCBjbGllbnRzLiAgSGF2aW5nIHNhaWQgdGhhdCwgSSB0aGluayBpdCBpcyBhIGJhZCBpZGVh IHRvIG1hbmRhdGUgUENQIHByb3h5IHRvIGJlICp0aGUqIGVuZC1wb2ludCB0aGF0IGF1dGhlbnRp Y2F0ZXMgdGhlIFBDUCBjbGllbnRzIGluIHRoZSBwcm94eSBjYXNlLg0KDQpZb3NoaWhpcm8gT2hi YQ0KDQoNCg0KRnJvbTpwY3AtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGNwLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86cGNwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQcmFzaGFu dGggUGF0aWwgKHByYXNwYXRpKQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDEzIDQ6NDYg UE0NClRvOiBBbHBlciBZZWdpbg0KQ2M6IHBjcEBpZXRmLm9yZzxtYWlsdG86cGNwQGlldGYub3Jn PjsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KU3ViamVjdDogUmU6IFtwY3BdIFByb3h5 IHNlY3VyaXR5ICh3YXMgUmU6IENPTlNFTlNVUyBDQUxMIG9uIFBDUCBzZWN1cml0eSkNCg0KSGkg QWxwZXIsDQoNCk9uIDE3LzA3LzEzIDEyOjIzIFBNLCAiQWxwZXIgWWVnaW4iIDxhbHBlci55ZWdp bkB5ZWdpbi5vcmc8bWFpbHRvOmFscGVyLnllZ2luQHllZ2luLm9yZz4+IHdyb3RlOg0KDQpIaSBQ cmFzaGFudGgsDQoNCg0KDQoNCg0KSSdtIG5vdCBzdXJlIGlmIGVub3VnaCB0aG91Z2h0IHdlbnQg aW50byB0aGUgUENQIFByb3h5IHNlY3VyaXR5LiBBcyBtdWNoIGFzIEknZCBsb3ZlIHRvIGJlIERP TkUhIHdpdGggdGhpcyBkaXNjdXNzaW9uLCBJIGFsc28gd2FudCB0byBtYWtlIHN1cmUgcGVvcGxl IGZlZWwgY29tZm9ydGFibGUgaGF2aW5nIHRob3VnaHQgYWxsIGFzcGVjdHMgYXJvdW5kIHRoZSBw cm94eSB1c2UuIEZvciAodmVyeSBpbXBvcnRhbnQpIGV4YW1wbGUsIHdoYXQga2luZCBvZiBzZWN1 cml0eSBhc3NvY2lhdGlvbnMgYXJlIG5lZWRlZCBmb3Igc2VjdXJpbmcgdGhlIHByb3h5IHVzZTog QW4gU0EgYnR3IGNsaWVudCBhbmQgc2VydmVyLCBhbiBTQSBidHcgY2xpZW50IGFuZCBwcm94eSwg YW4gU0EgYnR3IHByb3h5IGFuZCBzZXJ2ZXIgLS0gd2hpY2ggY29tYmluYXRpb25zIG9mIHRoZXNl IGFyZSBuZWVkZWQ/DQoNCldlJ3ZlIGluY2x1ZGVkIHRoaXMgaW4gdGhlIHVwZGF0ZWQgdmVyc2lv biBvZiBhdXRoIHJlcToNCg0KUkVRLTk6IEEgUENQIHByb3h5IHRoYXQgbW9kaWZpZXMgUENQIG1l c3NhZ2VzIFNIT1VMRCBoYXZlIHRoZQ0KYWJpbGl0eSB0byBpbmRlcGVuZGVudGx5IGF1dGhlbnRp Y2F0ZSB3aXRoIHRoZSBQQ1AgY2xpZW50IGFuZCBQQ1ANCnNlcnZlci4gVGhlIHByZXNlbmNlIG9m IGEgUENQIHByb3h5IGhlbmNlIHJlcXVpcmVzIHR3byBzZXBhcmF0ZWx5DQphdXRoZW50aWNhdGVz IFNBcy4gQXMgYSBjb25zZXF1ZW5jZSwgdGhlIFBDUCBwcm94eToNCg0KQS4gTVVTVCBiZSBhYmxl IHRvIHZhbGlkYXRlIG1lc3NhZ2UgaW50ZWdyaXR5IG9mIFBDUCBtZXNzYWdlcw0KZnJvbSB0aGUg UENQIHNlcnZlciBhbmQgY2xpZW50IHJlc3BlY3RpdmVseS4NCg0KQi4gTVVTVCBiZSBhYmxlIHRv IGVuc3VyZSBtZXNzYWdlIGludGVncml0eSBhZnRlciB1cGRhdGluZyB0aGUNClBDUCBtZXNzYWdl IGZvciBjYXNlcyBkZXNjcmliZWQgaW4gc2VjdGlvbnMgNiBvZiBpZXRmLXBjcC1wcm94eS4NCg0K VGhlIFBDUCBwcm94eSBNVVNUIGFsc28gcGVybWl0IGF1dGhlbnRpY2F0aW9uIG9uIG9ubHkgb25l IHNpZGUgb2YNCnRoZSBwcm94eS4gRm9yIGV4YW1wbGUsIGEgY3VzdG9tZXIgcHJlbWlzZXMgaG9z dCBtYXkgbm90DQphdXRoZW50aWNhdGUgd2l0aCB0aGUgUENQIHByb3h5IGJ1dCB0aGUgUENQIHBy b3h5IG1heSBhdXRoZW50aWNhdGUNCndpdGggdGhlIFBDUCBzZXJ2ZXIuDQoNCg0KDQpTbzoNCg0K LSBXZSBoYXZlIHR3byB0eXBlcyBvZiBTQXMuIE9uZSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRo ZSBwcm94eSwgYW5vdGhlciBiZXR3ZWVuIHRoZSBwcm94eSBhbmQgdGhlIHNlcnZlci4NCi0gTm9u ZSBvZiB0aGVtIGFyZSBtYW5kYXRvcnkgdG8gdXNlLg0KDQpQUkE6IFllcywgbm9uZSBvZiB0aGVt IGFyZSBtYW5kYXRvcnksIGl0J3MgY3VycmVudGx5IHRoZSBwcmVyb2dhdGl2ZSBvZiB0aGUgc2Vy dmVyIHRvIG1hbmRhdGUgYXV0aGVudGljYXRpb24uIFRoZSBwcm94eSBNVVNUIGJlIGFibGUgYXV0 aGVudGljYXRlIHdpdGggZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIgb3IgYm90aC4NCg0KRm9yIGVh Y2ggb25lIHRoYXQgbmVlZHMgdG8gYmUgdXNlZCwgd2UgbmVlZCB0byBwZXJmb3JtIGF1dGhlbnRp Y2F0aW9uIGJldHdlZW4gdGhlIGVuZC1wb2ludHMuDQooZS5nLiwgYmV0d2VlbiBjbGllbnQgYW5k IHByb3h5KS4NCg0KU28sIGluIGEgd2F5LCB3ZSBhcmUgZGVhbGluZyB3aXRoIHNlY3VyaXR5IGlu IHR3byBpbmRlcGVuZGVudCBwYXJ0czsgY2xpZW50IHRvIHByb3h5LCBhbmQgcHJveHkgdG8gc2Vy dmVyLg0KVGhleSBhcmUgdG90YWxseSBzZWdyZWdhdGVkIGZyb20gc2VjdXJpdHkgcGVyc3BlY3Rp dmUuDQoNClJpZ2h0Pw0KDQpQUkE6IFJpZ2h0LiBBcyBmYXIgYXMgdGhlIGNsaWVudCBpcyBjb25j ZXJuZWQsIHRoZSBwcm94eSBpcyB0aGUgUENQIHNlcnZlci4gVGhlIHByb3h5IGlzIGluIHR1cm4g YSBjbGllbnQgdG8gdGhlIHVwc3RyZWFtIFBDUCBzZXJ2ZXIuIFRoZSB0d28gcGFydHMgc2hvdWxk IGJlIGluZGVwZW5kZW50IG9mIGVhY2ggb3RoZXIuDQoNCkhtbSwgb25lIHRoaW5nOiBUaGUgc2Vy dmVyIG1heSBuZWVkIHRvIGtub3cgdGhlIGF1dGhlbnRpY2F0ZWQgSUQgb2YgdGhlIGNsaWVudC4g U2luY2UgaXQncyBub3QgcGFydCBvZiB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uLCBpdCB3b24n dCBrbm93IHRoYXQgdmFsdWUgcmVhZGlseS4gU28sIHdlIG1heSBuZWVkIHRvIGRlZmluZSBhbiBv cHRpb24gdG8gY2FycnkgdGhhdCBwaWVjZSBvZiBpbmZvcm1hdGlvbiBmcm9tIHRoZSBwcm94eSB0 byB0aGUgc2VydmVyLg0KDQpQUkE6IE1heSBiZSwgYnV0IGRvbqGmdCBrbm93IHdoeSB0aGUgc2Vy dmVyIHdvdWxkIHdhbnQgdG8ga25vdyB0aGUgYXV0aC1pZCBvZiBhIGNsaWVudC4NCg0KLVByYXNo YW50aA0KDQpBbHBlcg0KDQoNCg0KDQoNCg0KDQotUHJhc2hhbnRoDQoNClRoZW4gd2UgbmVlZCB0 byB0YWxrIGFib3V0IGhvdyB3ZSBkeW5hbWljYWxseSBjcmVhdGUgdGhvc2UgdXNpbmcgYW55IG9u ZSBvZiB0aGVzZSBzb2x1dGlvbnMuDQoNCkFscGVyDQoNCg0KDQoNCg0KT24gSnVsIDE2LCAyMDEz LCBhdCA3OjUwIFBNLCBEYXZlIFRoYWxlciB3cm90ZToNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgW21haWx0bzp0aXJlZGR5 QGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVseSAxNSwgMjAxMyAxMDo1MSBQTQ0KVG86IERh dmUgVGhhbGVyOyBwY3BAaWV0Zi5vcmc8bWFpbHRvOnBjcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBbcGNwXSBDT05TRU5TVVMgQ0FMTCBvbiBQQ1Agc2VjdXJpdHkNCkhpIERhdmUsDQpJbiB0aGUg cG9sbCB3aGVuIHlvdSByZWZlciB0byBQQU5BLCBwbGVhc2UgY2xhcmlmeSB0aGUgZHJhZnQgeW91 IGFyZSByZWZlcnJpbmcNCnRvIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW9oYmEt cGNwLXBhbmEtMDQgb3INCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW9oYmEtcGNw LXBhbmEtZW5jYXAtMDEgPw0KLS1UaXJ1Lg0KVGhlIHF1ZXN0aW9uIGlzIGludGVudGlvbmFsbHkg YWdub3N0aWMgYXMgdGhpcyBpcyBhYm91dCBhIGdlbmVyYWwgYXBwcm9hY2gsDQpub3Qgd2hpY2gg c3BlY2lmaWMgaW1wbGVtZW50YXRpb24uICBJZiBpdCBoZWxwcywgeW91IGNhbiBpbnRlcnByZXQg dGhlDQphbnN3ZXIgYXMgIndoaWNoIG9mIHRoZSB0d28geW91IHRoaW5rIGlzIGJldHRlciIuDQpJ ZiB0aGUgY29uc2Vuc3VzIGlzIFBBTkEgcmF0aGVyIHRoYW4gZGlyZWN0IEVBUC1pbi1QQ1AsIHRo ZW4gd2UgY291bGQNCmFzayBhcyBhIGZvbGxvdy11cCBxdWVzdGlvbiB3aGljaCBvZiB0aGUgdHdv IHdlIHNob3VsZCBnbyB3aXRoLiBJZg0KeW91J2QgbGlrZSB0byBpbmNsdWRlIHlvdXIgYW5zd2Vy IHRvIHRoYXQgbm93IHRob3VnaCwgZmVlbCBmcmVlIHRvDQppbmNsdWRlIHRoYXQgaW4geW91ciBy ZXNwb25zZSB0byB0aGUgY2FsbC4NCi1EYXZlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KcGNwIG1haWxpbmcgbGlzdA0KcGNwQGlldGYub3JnPG1haWx0 bzpwY3BAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bj cA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGNw IG1haWxpbmcgbGlzdA0KcGNwQGlldGYub3JnPG1haWx0bzpwY3BAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcA0KDQoNCg== --_000_B235506D63D65E43B2E40FD27715372E1CE33C90xmbrcdx07ciscoc_ Content-Type: text/html; charset="big5" Content-ID: Content-Transfer-Encoding: quoted-printable
Distribu= tion is not a good approach, brings in too many additional problems. How do= es the PCP Server trust the proxy, how is the key distributed, should it al= l be facilitated over PCP etc ?

The abov= e problems aside, as being discussed in other threads, the role of the PCP = proxy is not just that of forwarding but also acting on the request, instal= ling state etc and does all of this based on its own policy. Also, an ISP's PCP server does not= need to know of the different users within the home and has no incentive t= o individually authenticate each of those different users =A1V it's only interesting to the proxy (the PCP server as= far as the individual home users are concerned).

Well, that is easy: O= nce the PCP server successfully authenticate a PCP client, it distributes a= key used for protecting PCP message between the PCP client and the PCP proxy to the PCP proxy in a secure way.

 

Regards,

Yoshihiro Ohba

 

 

From: Prashanth Patil (praspati) [mailto:praspati@ci= sco.com]
Sent: Friday, July 19, 2013 1:23 AM
To: ohba yoshihiro; alper.y= egin@yegin.org
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

Hi Yoshihiro,

 

 

Hi Prashanth,

 

 

From: Prashanth Patil (praspati) [mailto:p= raspati@cisco.com]
Sent: Friday, July 19, 2013 12:11 AM
To: ohba yoshihiro(=A4j=B3= =F5=B8q=ACv=A1=B3=A2=E0=A2=D2=A2=D1=A1=BC=A2=DC=A2=E1=A2=DA= ); alper.yegin@yegin.org
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)<= /p>

 

Hi Yoshihiro,

Although the abstract says that, I don=A1=A6t t= hink the intent is for the PCP Proxy to just be a relay agent. It is clear from other sections of the draft that the pr= oxy is indeed a server and needs to modify fields (albeit minimal) before f= orwarding them to the actual server. This implies two independent authentic= ations need to happen.

[YO] I don=A1=A6t understand your = logic here. Even an http proxy can modify http requests (e.g., X-Forwarded-For header), and an http server can still auth= enticate http clients behind the proxy.

 

How does the proxy maintain message integrity i= f it modifies requests/responses? The case is different with HTTP.

 

-Prashanth

 

Yoshihiro Ohba

 

-Prashanth

 

 

Hi Tiru,

 

Abstract of pcp-proxy draft says:=

 

=A1=A7

   This document specifies a new PCP= functional element denoted as PCP

   Proxy.  The PCP Proxy relays= PCP requests received from PCP Clients

   to upstream PCP Server(s).  = This function is mandatory when PCP

   Clients can not be configured wit= h the address of the PCP Server

   located more than one hop.=

=A1=A7

 

If this abstract is correct, I interpret= that PCP clients only know the PCP proxy=A1=A6s address, but the PCP server *can* be the authentication end-point f= or the PCP clients.  This is similar to the http proxy case where http= servers are the authentication end-points for http clients.  Having s= aid that, I think it is a bad idea to mandate PCP proxy to be *the* end-point that authenticates the PCP clients = in the proxy case.

 

Yoshihiro Ohba

 

 

 

From:pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] = On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)<= /p>

 

Hi Alper,

 

On 17/07/13 12:23 PM, "Alper Yegin"= <alper.yegin@yegin.org> wrote:=

 

Hi Prashanth,

 





I'm not sure if enough thought went into the = PCP Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel com= fortable having thought all aspects around the proxy use. For (very importa= nt) example, what kind of security associations are needed for securing the= proxy use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which co= mbinations of these are needed?

 

We've included this in the updated version of= auth req:

 

REQ-9: A PCP proxy that modifies PCP messa= ges SHOULD have the

ability to independently authenticate with= the PCP client and PCP

server. The presence of a PCP proxy hence = requires two separately

authenticates SAs. As a consequence, the P= CP proxy:<= /span>

 

A. MUST be able to validate message integr= ity of PCP messages

from the PCP server and client respectivel= y.<= /p>

 

B. MUST be able to ensure message integrit= y after updating the<= o:p>

PCP message for cases described in section= s 6 of ietf-pcp-proxy.

 

The PCP proxy MUST also permit authenticat= ion on only one side of

the proxy. For example, a customer premise= s host may not

authenticate with the PCP proxy but the PC= P proxy may authenticate

with the PCP server.

 

 

 

So:

 

- We have two types of SAs. One between the c= lient and the proxy, another between the proxy and the server.

- None of them are mandatory to use.

 

PRA: Yes, none of them are mandatory, it's cu= rrently the prerogative of the server to mandate authentication. The proxy MUST be able authenticate with either cl= ient or server or both.

 

For each one that needs to be used, we need t= o perform authentication between the end-points. 

(e.g., between client and proxy).

 

So, in a way, we are dealing with security in= two independent parts; client to proxy, and proxy to server. 

They are totally segregated from security per= spective. 

 

Right?

 

PRA: Right. As far as the client is concerned= , the proxy is the PCP server. The proxy is in turn a client to the upstream PCP server. The two parts should be in= dependent of each other.<= o:p>

 

Hmm, one thing: The server may need to know t= he authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readi= ly. So, we may need to define an option to carry that piece of information = from the proxy to the server.

 

PRA: May be, but don=A1=A6t know why the serv= er would want to know the auth-id of a client.

 

-Prashanth 

 

Alper

 

 

 





-Prashanth

 

Then we need to talk about how we dynamically= create those using any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, Dave Thaler wrot= e:

 

-----Original Message-----

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 10:51 PM

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS CALL on PCP secu= rity

Hi Dave,

In the poll when you refer to PANA, please cl= arify the draft you are referring

--Tiru.

The question is intentionally agnostic as thi= s is about a general approach,

not which specific implementation.  = ;If it helps, you can interpret the

answer as "which of the two you think is= better".=

If the consensus is PANA rather than direct E= AP-in-PCP, then we could

ask as a follow-up question which of the two = we should go with. If

you'd like to include your answer to that now= though, feel free to

include that in your response to the call.

-Dave

_____________________________________________= __

pcp mailing list

 

_____________________________________________= __

pcp mailing list

 

 

 --_000_B235506D63D65E43B2E40FD27715372E1CE33C90xmbrcdx07ciscoc_-- From alper.yegin@yegin.org Fri Jul 19 05:58:33 2013 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 F2A8021F9ADA for ; Fri, 19 Jul 2013 05:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTEtnWlYgkk0 for ; Fri, 19 Jul 2013 05:58:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 27AC321F99DA for ; Fri, 19 Jul 2013 05:58:28 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MZl3O-1Ui5Pa3QKc-00L4RZ; Fri, 19 Jul 2013 08:58:22 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> Date: Fri, 19 Jul 2013 15:58:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> To: Ben McCann X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:wPZe6zDmLcTkLTMfG8BgJZfav7bae7gbn63cJRDb8jL Ny4OoGs78qJgtIxdLFL47mMTB/EzG6sp9y88wmJ/h2k8I0Sej6 h3rC2qrxyxm7hf+1gAGbvNq7ab/DJPW9XzGxNRqbWkvlBowphK Csz0PSUc9/qJR4RDPjdkP1CUxOx8cHtZ1pNfpK4dFRDbRmvAjx stAHHiIAIIep9TkCq22PEV9l4i8/qU+lrLxmXEEGs9z5M9TtF2 EQzYkS55pI2nPT7moh/LHjzvThT5fdrsI7i6/qqGPF/o00wAB9 Y27Hh6W3VPxu1JAvt9X6TbydIhHWMtavkIOemTJ+PVsXPcpAR1 PVuONAxleMgGbernEAe2exB7lo+evhFy1ZNpPqOycYslCLAO/R BAt1rL1V2vV+w== Cc: "pcp@ietf.org" Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) 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, 19 Jul 2013 12:58:33 -0000 Hi Ben, "If I have to select between two ways to define a protocol, and one of = them is simpler to implement, then I will tend to vote for the simpler = option if all other criteria are equal." Indeed. But the simplicity comparison is apples to oranges.=20 On one side there is an RFC that went thru the whole IETF system and got = published as an RFC, with multiple interoperable implementations, and = industry adoption. On the other side is a incomplete, early stage personal I-D with no = running code. It's not surprising that the latter appears simpler.=20 Lot of work starts with the same claim in IETF: We'll design a Simple X. = One needs to wait and see how they end up eventually. There's gotta be some tangible signs about the truthfulness of the = claim, before IETF embarks on that path. Otherwise we'd be abandoning the "reuse" mantra and spend precious IETF = cycles on re-inventing. =85 Regarding the states in one PANA implementation and its implication on = PCP integration: PANA protocol itself has only 4 phases. It does not matter if one implementation chose to implement it using 13 = states. Your implementation can use less.=20 Besides, number of states in EAP-o-Foo does not matter when integrating = EAP-o-Foo with Foo. Foo tells EAP-o-Foo to authenticate X, and EAP-o-Foo comes back with the = result.=20 It does not matter (for integration) how many states are used by = EAP-o-Foo in between. It's an internal matter for EAP-o-Foo = implementation. Alper On Jul 18, 2013, at 8:00 PM, Ben McCann wrote: > Thank you for clarifying that "PANA does not force clients to always = have a session, or always stay awake or connected". >=20 > That, I believe, wasn't Margaret's point. PANA *supports* server side = re-authentication even if the client doesn't think it's necessary. So, = if the server chooses, it can wake up the client by sending packets. = That said, this really isn't a legitimate criticism of the PANA = protocol. It's an issue that can be addressed by proper programming or = configuration of the PCP/PANA server to make sure it doesn't = unnecessarily re-authenticate the clients.=20 >=20 > So, I agree with you that PANA, on a properly configured server, can = be as "mobile friendly" and lightweight as EAP-in-PCP.=20 >=20 >=20 > My concerns about starting from a clean slate are based, in part, on = Steve Hartman's "Implementation Analysis: strong preference for = PCP-specific approach" = (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His = arguments were persuasive (to me) and the counter-arguments were not.=20 >=20 > I understand that implementation should not dictate protocol design = but I think we should let implementation *inform* protocol design. If I = have to select between two ways to define a protocol, and one of them is = simpler to implement, then I will tend to vote for the simpler option if = all other criteria are equal. I see EAP-in-PCP as the simpler option = even if there is source code for PANA. >=20 > I've also reviewed the OpenPANA source code and I have some concerns = that illustrate this point: >=20 > * The PANA state machine includes 13 states with 22 separate input = events. That state machine has to be integrated with the simpler PCP = state machine. My intuition, based on too many years of experience, is = that integrating the PANA and PCP state machines is tricky to implement, = debug, and verify. That complexity is, in part, because PANA already has = a fairly complex state machine. I don't believe EAP-in-PCP requires this = much complexity. >=20 > * The OpenPANA implementation is about 6900 SLOCs long as measured by = an sloccount version 2.26. This seems like a lot of code (aka = complexity) to tunnel EAP packets over PCP. And, that doesn't include = the code that must be added to PCP required to integrate PCP with PANA. = I believe an EAP-in-PCP implementation will be much simpler but, I = admit, I don't have an implementation to show you that proves that = point. >=20 > * The presence of an open source version of PANA is a vote in its = favor but that depends on whether that code is easily portable to many = environments. I think the OpenPANA implementation makes assumptions = about its runtime environment that aren't very portable. It assumes a = multi-threaded environment with posix sockets and my runtime environment = doesn't meet those requirements. >=20 > To be fair, I don't think I've said anything here that wasn't already = covered by Steve Hartman. But, I did review the code and I agree with = his conclusions. >=20 > -Ben McCann >=20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Thursday, July 18, 2013 4:34 AM > To: Ben McCann > Cc: Dave Thaler; pcp@ietf.org > Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP = security) >=20 > Hello, >=20 > I'm afraid your below issues are based on misconceptions introduced by = the http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf = slides. > We did address those misconceptions in several rounds, but it seems = like some still linger. >=20 > PANA does not force clients to always have a session, or always stay = awake or connected. >=20 > If a client wants to get authenticated and generate a 5 minute key, = and afterwards sleep, detach, etc., it can very well do that using PANA. > We can support that by simply setting the lifetime of the PANA SA to = that short fix value, or letting the PANA SA timeout and expire.=20 > So, you can run PANA and have a 5 min SA, then have no PANA activity = for 23:55hrs, and then come back and do another PANA authentication and = have another 5min SA. No problems. >=20 > Therefore, there are no issues with mobile, and no issues with server = side resources. >=20 > After all, PANA is adopted by Zigbee Alliance. I don't think the = deployment cases considered here are any more constrained than theirs... >=20 >> EAP-in-PCP provides a clean slate that's unencumbered by the design = decisions and assumptions of an existing protocol (PANA).=20 >=20 >=20 > Was there any other concern leading to your above statement? >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: >=20 >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>=20 >> YES >>=20 >> 2) Could you *live with* PANA? If not, state reason you would object. >>=20 >> Yes, but we really rather not use PANA. See below... >>=20 >> 3) If you said yes to both 1 and 2, but have a strong preference = between the two, which approach do you prefer and why? >>=20 >> We strongly prefer EAP-in-PCP for several reasons: >>=20 >> * PANA, as we understand it, is not mobile-friendly. It requires the = PCP client to *always* have an authenticated session active and that is = wasteful on mobile clients when the authentication rekey interval is = much shorter than the mapping lifetime. Margaret Wasserman captured this = in slides 13 and 14 of her presentation = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We = believe the *client* should decide when to authenticate (because it = needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption.=20 >>=20 >> We understand that a PCP server may need to send a message to the = client when no authenticated session is active. If no authenticated = session is active then we prefer the server send an UN-authenticated = "call home" message directing the client to authenticate and then the = server can send its messages over the authenticated channel. We = recognize an attacker can induce the client to connect to the server by = forging an unauthenticated "call home" message. But, having done that, = the client can ignore subsequent forged call home messages because it = will already have an authenticated session. Worse case, an attacker = can't make EAP-in-PCP consume any more client resources than PANA does = because PANA requires the client to always have an authenticated session = available. >>=20 >> * PANA requires more server side resources. The authentication = protocol should efficiently support 100,000's of clients on a large PCP = server. Why should the server continuously maintain authenticated = sessions with *every* client? Clients using 24 hour mapping lifetimes = can be served by short authentication key lifetime like, for example, 5 = minutes. Let the client connect, authenticate, program the mappings, and = then let the authenticated session expire. Rinse and repeat in 24 = hours,. Client-driven authentication via EAP-in-PCP requires less = resources on the server because the server can discard the authenticated = session state once the key lifetime expires. >>=20 >> There was some discussion that PANA is preferable to EAP-in-PCP = because it supports "liveness testing". We don't believe liveness = testing is useful when the server resources consumed, per client, are = PCP mappings. Checking the liveness of 100,000 clients is much more = resource intensive on the server than just keeping the client's mappings = around until they expire naturally at the end of their lifetime. In = short, we believe EAP-in-PCP will scale better on the server than PANA. >>=20 >> * We believe the decision to use EAP-in-PCP vs. PANA is a choice = between designing and implementing an EAP-in-PCP transport that is = tailored for PCP versus adapting an existing protocol (PANA) to fit the = needs of PCP. We don't think implementing an EAP-in-PCP transport is = difficult so we prefer it over PANA. EAP-in-PCP provides a clean slate = that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).=20 >>=20 >> -Ben McCann >>=20 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 From alper.yegin@yegin.org Fri Jul 19 06:05:50 2013 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 4F40C11E812F for ; Fri, 19 Jul 2013 06:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53GApiWoTIMW for ; Fri, 19 Jul 2013 06:05:45 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 37C5511E8126 for ; Fri, 19 Jul 2013 06:05:39 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Mb6xv-1Ughi10e2l-00KfMw; Fri, 19 Jul 2013 09:05:24 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <9374F3A019050A4C805B8DEF27285BE40115E08BCF@LWLMBX01.olympus.F5Net.com> Date: Fri, 19 Jul 2013 16:05:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> <76B8454D-73F0-4E3D-81A6-55F121535901@um.es> <9374F3A019050A4C805B8DEF27285BE40115E08BCF@LWLMBX01.olympus.F5Net.com> To: Ben McCann X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:ybkzdBovOjRz/dE/m2v+hB2WOOSVodLt0oDX9zKk0Sy m01eiNCFXDeQq+NrYWyvVKQUot5anFCfSBVLlcTj0aFUNPYBwx 8IKwONBi/zslBztm1Zui021Xp/Kpra4YTzVGscjrUR7VWQCcct L6c5BTSNuL8D+iASUdCyZpEK0paYNFsKGDWA5rfbN0dxdB8UCn NdgPMFZMR3t8+qEqqvfo2RtlMYI0FHL5iG0lysnJfw+m4+wwYg ieL0nCbaApq89CRnS8GGMusDtC1Gv2vGjJCSiutL1BjSn7LJxz DbcfycQ33P+VyPxAInEiG3kJ4nTlRIG0lZb2mR7zJKBLU1ZbUO WYhBLMXrRr6teZgcwxLQSU5ayTAS893Nd6eKg2siOz0vT/QLzq uLbBv0M5CnRiw== Cc: "pcp@ietf.org" Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) 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, 19 Jul 2013 13:05:50 -0000 Let me inject my toughest on this one=85. On Jul 19, 2013, at 3:55 AM, Ben McCann wrote: > Hi Rafa, >=20 > I incorrectly used a discussion about the suitability of the OpenPANA = implementation as an argument to defend my statement "EAP-in-PCP = provides a clean slate that's unencumbered by the design decisions and = assumptions of an existing protocol (PANA).". That argument was a waste = of time because the suitability or availability of a reference = implementation is irrelevant to whether PANA was designed with a set of = security considerations that are appropriate for PCP. This understanding = of the security considerations is the "clean slate" that is important to = me. >=20 > For example, PANA negotiates its own security association so it can = provide data integrity for the final EAP response packet. That's fine, = but where have we decided that PCP needs to secure the integrity of that = response packet? (It probably should). PANA does not secure the earlier = EAP packets that carry parameters like the cipher suite selection or = authentication parameters for the selected EAP method. So, those could = be compromised by an attacker. Where have we decided that this is an = acceptable risk for PCP? We haven't discussed that, but we implicitly = agree to live with it if we move forward with PANA. (Or, at least, we = accept that risk with some EAP methods). >=20 > I prefer EAP-in-PCP because it will make us think through those issues = for PCP. Well, thinking about those issues are fine. It's fair.=20 Jumping to a conclusion that EAP-o-PCP is simpler and sufficient, w/o = doing that is not fine :-)=20 Already few such things were brought up and examined (e.g., the need for = server-side re-auth, ping, etc). Re-auth turned out to be needed, ping turned out to be not needed but = negligible amount of code. What else? Alper > (We've made a good start in the auth requirements draft). Until we get = those requirements down, I think it's premature to decide PANA is the = right choice. It might be, if we agree that PANA's security = considerations are OK for PCP. Or, we could decide that a simple = EAP-in-PCP transport w/o *any* security association is sufficient = because we can leverage the security properties of EAP methods such as = EAP-TTLS to achieve the data integrity required for the EAP protocol. >=20 > I'm vacation for two weeks and won't be in Berlin to continue this = discussion face-to-face. >=20 > -Ben McCann >=20 > -----Original Message----- > From: Rafa Marin Lopez [mailto:rafa@um.es]=20 > Sent: Thursday, July 18, 2013 5:31 PM > To: Ben McCann > Cc: pcp@ietf.org > Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP = security) >=20 > Hi Ben: >=20 > On Jul 18, 2013, at 7:00 PM, Ben McCann wrote: >=20 >> Thank you for clarifying that "PANA does not force clients to always = have a session, or always stay awake or connected". >>=20 >> That, I believe, wasn't Margaret's point. PANA *supports* server side = re-authentication even if the client doesn't think it's necessary. So, = if the server chooses, it can wake up the client by sending packets. = That said, this really isn't a legitimate criticism of the PANA = protocol. It's an issue that can be addressed by proper programming or = configuration of the PCP/PANA server to make sure it doesn't = unnecessarily re-authenticate the clients.=20 >>=20 >> So, I agree with you that PANA, on a properly configured server, can = be as "mobile friendly" and lightweight as EAP-in-PCP.=20 >>=20 >>=20 >> My concerns about starting from a clean slate are based, in part, on = Steve Hartman's "Implementation Analysis: strong preference for = PCP-specific approach" = (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His = arguments were persuasive (to me) and the counter-arguments were not.=20 >=20 > [Rafa] Why my answers in = http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html are not = ok? >=20 >>=20 >> I understand that implementation should not dictate protocol design = but I think we should let implementation *inform* protocol design. If I = have to select between two ways to define a protocol, and one of them is = simpler to implement, then I will tend to vote for the simpler option if = all other criteria are equal. I see EAP-in-PCP as the simpler option = even if there is source code for PANA. >>=20 >> I've also reviewed the OpenPANA source code and I have some concerns = that illustrate this point: >>=20 >> * The PANA state machine includes 13 states with 22 separate input = events. That state machine has to be integrated with the simpler PCP = state machine. My intuition, based on too many years of experience, is = that integrating the PANA and PCP state machines is tricky to implement, = debug, and verify. That complexity is, in part, because PANA already has = a fairly complex state machine. I don't believe EAP-in-PCP requires this = much complexity. >=20 > [Rafa] Ben, I have always assumed we all have experience in the area. = In particular, I have been working on PANA since 2003 and I have done = source coding myself, I have been leading an open source PANA = implementation and deployed PANA in several EU projects, without any = inconvenience so far. >=20 > About the state machine, I can tell you that part of it is completely = optional.=20 >=20 > And about the integration between PANA and PCP, I disagree based on = the experience we got from = http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 >=20 >>=20 >> * The OpenPANA implementation is about 6900 SLOCs long as measured by = an sloccount version 2.26. This seems like a lot of code (aka = complexity) to tunnel EAP packets over PCP. And, that doesn't include = the code that must be added to PCP required to integrate PCP with PANA. = I believe an EAP-in-PCP implementation will be much simpler but, I = admit, I don't have an implementation to show you that proves that = point. >=20 > [Rafa] This number is completely wrong as I already explained in = http://www.ietf.org/mail-archive/web/pcp/current/msg02631.html (as you = may observe this is a repeating conversation). You may agree with me = that doing the sloccount over the entire package does not help too = much. We need to be more specific. >=20 > In the message I already sent, the discussion was about = openpana-0.2.3. Right now, we have openpana-0.2.4 and we have new = values. The following values only show the LoC dedicated to PANA, not to = EAP ST, EAP-Method or RADIUS client since those values will be common to = any other solution using EAP and RADIUS. >=20 > OpenPANA: >=20 > The PAA: >=20 > 3130 LoC (PAA ST + PAA main program + PANA messages + PAA session + = PRF) >=20 > The PaC >=20 > 2720 (PaC ST + PaC main + PANA messages + PaC session + PRF) >=20 > It is worth noting that those values includes 1846 LoCs which are = common functionality to PaC and PAA. >=20 > Moreover, as I also explained in the e-mail we have a version for very = constrained devices (sensor nodes). In particular we have a PaC = implementation for Contiki OS named PANATIKI = (http://sourceforge.net/projects/panatiki) and the values are:=20 >=20 > PANATIKI : 517 (PaC state machine) + 141 (PaC main program) >=20 > But again, please take into account this is just an open source = implementation and not a product. And, of course, running code is = absolutely better than no code. >=20 > Regarding your comment "And, that doesn't include the code that must = be added to PCP required to integrate PCP with PANA", please see slide = 12 in http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 . = Just a 100 lines that includes "PCP Key derivation and export. Unix = Sockets." in the case of OpenPANA. >=20 >=20 >>=20 >> * The presence of an open source version of PANA is a vote in its = favor but that depends on whether that code is easily portable to many = environments. I think the OpenPANA implementation makes assumptions = about its runtime environment that aren't very portable. It assumes a = multi-threaded environment with posix sockets and my runtime environment = doesn't meet those requirements. >=20 > [Rafa] For example, PANATIKI does not assume multi-threaded = environment with posix sockets (it is an implementation for a sensor = node after all). Btw, there are two open source implementations = OpenPANA/PANATIKI and CPANA. >=20 >>=20 >> To be fair, I don't think I've said anything here that wasn't already = covered by Steve Hartman. But, I did review the code and I agree with = his conclusions. >=20 > [Rafa] As you can see, I already counter-argumented that analysis. In = any case, I will be in Berlin so any doubt you have about = OpenPana/PANATIKI or just implementating PANA, let me know and I will be = more than happy to meet and discuss. >=20 > Best regards. >=20 >>=20 >> -Ben McCann >>=20 >> -----Original Message----- >> From: Alper Yegin [mailto:alper.yegin@yegin.org] >> Sent: Thursday, July 18, 2013 4:34 AM >> To: Ben McCann >> Cc: Dave Thaler; pcp@ietf.org >> Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP=20 >> security) >>=20 >> Hello, >>=20 >> I'm afraid your below issues are based on misconceptions introduced = by the http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf = slides. >> We did address those misconceptions in several rounds, but it seems = like some still linger. >>=20 >> PANA does not force clients to always have a session, or always stay = awake or connected. >>=20 >> If a client wants to get authenticated and generate a 5 minute key, = and afterwards sleep, detach, etc., it can very well do that using PANA. >> We can support that by simply setting the lifetime of the PANA SA to = that short fix value, or letting the PANA SA timeout and expire.=20 >> So, you can run PANA and have a 5 min SA, then have no PANA activity = for 23:55hrs, and then come back and do another PANA authentication and = have another 5min SA. No problems. >>=20 >> Therefore, there are no issues with mobile, and no issues with server = side resources. >>=20 >> After all, PANA is adopted by Zigbee Alliance. I don't think the = deployment cases considered here are any more constrained than theirs... >>=20 >>> EAP-in-PCP provides a clean slate that's unencumbered by the design = decisions and assumptions of an existing protocol (PANA).=20 >>=20 >>=20 >> Was there any other concern leading to your above statement? >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: >>=20 >>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>>=20 >>> YES >>>=20 >>> 2) Could you *live with* PANA? If not, state reason you would = object. >>>=20 >>> Yes, but we really rather not use PANA. See below... >>>=20 >>> 3) If you said yes to both 1 and 2, but have a strong preference = between the two, which approach do you prefer and why? >>>=20 >>> We strongly prefer EAP-in-PCP for several reasons: >>>=20 >>> * PANA, as we understand it, is not mobile-friendly. It requires the = PCP client to *always* have an authenticated session active and that is = wasteful on mobile clients when the authentication rekey interval is = much shorter than the mapping lifetime. Margaret Wasserman captured this = in slides 13 and 14 of her presentation = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We = believe the *client* should decide when to authenticate (because it = needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption.=20 >>>=20 >>> We understand that a PCP server may need to send a message to the = client when no authenticated session is active. If no authenticated = session is active then we prefer the server send an UN-authenticated = "call home" message directing the client to authenticate and then the = server can send its messages over the authenticated channel. We = recognize an attacker can induce the client to connect to the server by = forging an unauthenticated "call home" message. But, having done that, = the client can ignore subsequent forged call home messages because it = will already have an authenticated session. Worse case, an attacker = can't make EAP-in-PCP consume any more client resources than PANA does = because PANA requires the client to always have an authenticated session = available. >>>=20 >>> * PANA requires more server side resources. The authentication = protocol should efficiently support 100,000's of clients on a large PCP = server. Why should the server continuously maintain authenticated = sessions with *every* client? Clients using 24 hour mapping lifetimes = can be served by short authentication key lifetime like, for example, 5 = minutes. Let the client connect, authenticate, program the mappings, and = then let the authenticated session expire. Rinse and repeat in 24 = hours,. Client-driven authentication via EAP-in-PCP requires less = resources on the server because the server can discard the authenticated = session state once the key lifetime expires. >>>=20 >>> There was some discussion that PANA is preferable to EAP-in-PCP = because it supports "liveness testing". We don't believe liveness = testing is useful when the server resources consumed, per client, are = PCP mappings. Checking the liveness of 100,000 clients is much more = resource intensive on the server than just keeping the client's mappings = around until they expire naturally at the end of their lifetime. In = short, we believe EAP-in-PCP will scale better on the server than PANA. >>>=20 >>> * We believe the decision to use EAP-in-PCP vs. PANA is a choice = between designing and implementing an EAP-in-PCP transport that is = tailored for PCP versus adapting an existing protocol (PANA) to fit the = needs of PCP. We don't think implementing an EAP-in-PCP transport is = difficult so we prefer it over PANA. EAP-in-PCP provides a clean slate = that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).=20 >>>=20 >>> -Ben McCann >>>=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 > ------------------------------------------------------- > 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 > ------------------------------------------------------- >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From praspati@cisco.com Fri Jul 19 06:10:17 2013 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 4702221E808B for ; Fri, 19 Jul 2013 06:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.292 X-Spam-Level: X-Spam-Status: No, score=-10.292 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVE2ugDegCPY for ; Fri, 19 Jul 2013 06:10:12 -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 DA30321E80AB for ; Fri, 19 Jul 2013 06:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36201; q=dns/txt; s=iport; t=1374239412; x=1375449012; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=49l4dGky0js5JVx0RECyMXuZDuAWexEEqPob+lzubJo=; b=UfANjy9SjQnTP5k2AQfHh7fqQulEo6gxmWgwfktR2S8hqvJdhjJUOpRk OpyCcxPTQ/AP1quXNiFf7dSwP2K2bP1v0GAo8DV+KAKNEgPVhgHuTm+ac 7M6rdqDz61FHFcWjvR8c0ZKzXQ9womrJ8MrLZzQSLp/AKI/xIR5r+vfBr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwFAMY56VGtJV2c/2dsb2JhbABagkJENVCEJYFDqGqQFIFggRAWdIIkAQEBAgIBAQEXUgIIAwwGAQgRBAEBCwsLBy4LFAkIAgQBDQUIARKHdQy2dY5dAYEABicEBwIEBIMGbgOZBpAkgTWBXYFxOQ X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208,217";a="236946061" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 19 Jul 2013 13:09:54 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6JD9rGf008223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 13:09:53 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 08:09:53 -0500 From: "Prashanth Patil (praspati)" To: Ben McCann , Rafa Marin Lopez Thread-Topic: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOhIFCVdfwqifKVUWMdYKUKp2YAA== Date: Fri, 19 Jul 2013 13:09:53 +0000 Message-ID: In-Reply-To: <9374F3A019050A4C805B8DEF27285BE40115E08BCF@LWLMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.68.21.116] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE33CC5xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) 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, 19 Jul 2013 13:10:17 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE33CC5xmbrcdx07ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 19/07/13 6:25 AM, "Ben McCann" >= wrote: Hi Rafa, I incorrectly used a discussion about the suitability of the OpenPANA impl= ementation as an argument to defend my statement "EAP-in-PCP provides a cle= an slate that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).". That argument was a waste of time because the s= uitability or availability of a reference implementation is irrelevant to w= hether PANA was designed with a set of security considerations that are app= ropriate for PCP. This understanding of the security considerations is the = "clean slate" that is important to me. For example, PANA negotiates its own security association so it can provide= data integrity for the final EAP response packet. That's fine, but where h= ave we decided that PCP needs to secure the integrity of that response pack= et? (It probably should). PANA does not secure the earlier EAP packets that= carry parameters like the cipher suite selection or authentication paramet= ers for the selected EAP method. So, those could be compromised by an attac= ker. Where have we decided that this is an acceptable risk for PCP? We have= n't discussed that, but we implicitly agree to live with it if we move forw= ard with PANA. (Or, at least, we accept that risk with some EAP methods). Agreed. REQ-5 that lists requirements in this area should discuss points yo= u've highlighted. I prefer EAP-in-PCP because it will make us think through those issues for = PCP. (We've made a good start in the auth requirements draft). Until we get= those requirements down, I think it's premature to decide PANA is the righ= t choice. It might be, if we agree that PANA's security considerations are = OK for PCP. Or, we could decide that a simple EAP-in-PCP transport w/o *any= * security association is sufficient because we can leverage the security p= roperties of EAP methods such as EAP-TTLS to achieve the data integrity req= uired for the EAP protocol. TLS/DTLS is a good candidate to satisfy REQ-14: REQ-14: There SHOULD be support for a means to provide integrity protection without user authentication, i.e., an anonymous client should be able to verify a PCP server using server-side-only auth and as a consequence obtain an SA which will be used for PCP message integrity. For example, a client visiting foreign networks such as a hotel, hot spot etc where the client may gain access to the network but does not know the credentials to authenticate with the PCP server. The negotiation of SA should be secure such that the SA is only known to the anonymous client and PCP server. -Prashanth I'm vacation for two weeks and won't be in Berlin to continue this discussi= on face-to-face. -Ben McCann -----Original Message----- From: Rafa Marin Lopez [mailto:rafa@um.es] Sent: Thursday, July 18, 2013 5:31 PM To: Ben McCann Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP secur= ity) Hi Ben: On Jul 18, 2013, at 7:00 PM, Ben McCann wrote: Thank you for clarifying that "PANA does not force clients to always have a= session, or always stay awake or connected". That, I believe, wasn't Margaret's point. PANA *supports* server side re-au= thentication even if the client doesn't think it's necessary. So, if the se= rver chooses, it can wake up the client by sending packets. That said, this= really isn't a legitimate criticism of the PANA protocol. It's an issue th= at can be addressed by proper programming or configuration of the PCP/PANA = server to make sure it doesn't unnecessarily re-authenticate the clients. So, I agree with you that PANA, on a properly configured server, can be as = "mobile friendly" and lightweight as EAP-in-PCP. My concerns about starting from a clean slate are based, in part, on Steve = Hartman's "Implementation Analysis: strong preference for PCP-specific appr= oach" (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His= arguments were persuasive (to me) and the counter-arguments were not. [Rafa] Why my answers in http://www.ietf.org/mail-archive/web/pcp/current/m= sg02349.html are not ok? I understand that implementation should not dictate protocol design but I t= hink we should let implementation *inform* protocol design. If I have to se= lect between two ways to define a protocol, and one of them is simpler to i= mplement, then I will tend to vote for the simpler option if all other crit= eria are equal. I see EAP-in-PCP as the simpler option even if there is sou= rce code for PANA. I've also reviewed the OpenPANA source code and I have some concerns that i= llustrate this point: * The PANA state machine includes 13 states with 22 separate input events. = That state machine has to be integrated with the simpler PCP state machine.= My intuition, based on too many years of experience, is that integrating t= he PANA and PCP state machines is tricky to implement, debug, and verify. T= hat complexity is, in part, because PANA already has a fairly complex state= machine. I don't believe EAP-in-PCP requires this much complexity. [Rafa] Ben, I have always assumed we all have experience in the area. In pa= rticular, I have been working on PANA since 2003 and I have done source cod= ing myself, I have been leading an open source PANA implementation and depl= oyed PANA in several EU projects, without any inconvenience so far. About the state machine, I can tell you that part of it is completely optio= nal. And about the integration between PANA and PCP, I disagree based on the exp= erience we got from http://www.ietf.org/proceedings/86/slides/slides-86-pcp= -17 * The OpenPANA implementation is about 6900 SLOCs long as measured by an sl= occount version 2.26. This seems like a lot of code (aka complexity) to tun= nel EAP packets over PCP. And, that doesn't include the code that must be a= dded to PCP required to integrate PCP with PANA. I believe an EAP-in-PCP im= plementation will be much simpler but, I admit, I don't have an implementat= ion to show you that proves that point. [Rafa] This number is completely wrong as I already explained in http://www= .ietf.org/mail-archive/web/pcp/current/msg02631.html (as you may observe th= is is a repeating conversation). You may agree with me that doing the slocc= ount over the entire package does not help too much. We need to be more sp= ecific. In the message I already sent, the discussion was about openpana-0.2.3. Rig= ht now, we have openpana-0.2.4 and we have new values. The following values= only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or RADIUS c= lient since those values will be common to any other solution using EAP and= RADIUS. OpenPANA: The PAA: 3130 LoC (PAA ST + PAA main program + PANA messages + PAA session + PRF) The PaC 2720 (PaC ST + PaC main + PANA messages + PaC session + PRF) It is worth noting that those values includes 1846 LoCs which are common fu= nctionality to PaC and PAA. Moreover, as I also explained in the e-mail we have a version for very cons= trained devices (sensor nodes). In particular we have a PaC implementation = for Contiki OS named PANATIKI (http://sourceforge.net/projects/panatiki) an= d the values are: PANATIKI : 517 (PaC state machine) + 141 (PaC main program) But again, please take into account this is just an open source implementat= ion and not a product. And, of course, running code is absolutely better th= an no code. Regarding your comment "And, that doesn't include the code that must be add= ed to PCP required to integrate PCP with PANA", please see slide 12 in http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 . Just a 100 lines= that includes "PCP Key derivation and export. Unix Sockets." in the case = of OpenPANA. * The presence of an open source version of PANA is a vote in its favor but= that depends on whether that code is easily portable to many environments.= I think the OpenPANA implementation makes assumptions about its runtime en= vironment that aren't very portable. It assumes a multi-threaded environmen= t with posix sockets and my runtime environment doesn't meet those requirem= ents. [Rafa] For example, PANATIKI does not assume multi-threaded environment wit= h posix sockets (it is an implementation for a sensor node after all). Btw,= there are two open source implementations OpenPANA/PANATIKI and CPANA. To be fair, I don't think I've said anything here that wasn't already cover= ed by Steve Hartman. But, I did review the code and I agree with his conclu= sions. [Rafa] As you can see, I already counter-argumented that analysis. In any c= ase, I will be in Berlin so any doubt you have about OpenPana/PANATIKI or j= ust implementating PANA, let me know and I will be more than happy to meet = and discuss. Best regards. -Ben McCann -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, July 18, 2013 4:34 AM To: Ben McCann Cc: Dave Thaler; pcp@ietf.org Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP security) Hello, I'm afraid your below issues are based on misconceptions introduced by the = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides. We did address those misconceptions in several rounds, but it seems like so= me still linger. PANA does not force clients to always have a session, or always stay awake = or connected. If a client wants to get authenticated and generate a 5 minute key, and aft= erwards sleep, detach, etc., it can very well do that using PANA. We can support that by simply setting the lifetime of the PANA SA to that s= hort fix value, or letting the PANA SA timeout and expire. So, you can run PANA and have a 5 min SA, then have no PANA activity for 23= :55hrs, and then come back and do another PANA authentication and have anot= her 5min SA. No problems. Therefore, there are no issues with mobile, and no issues with server side = resources. After all, PANA is adopted by Zigbee Alliance. I don't think the deployment= cases considered here are any more constrained than theirs... EAP-in-PCP provides a clean slate that's unencumbered by the design decisio= ns and assumptions of an existing protocol (PANA). Was there any other concern leading to your above statement? Alper On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. YES 2) Could you *live with* PANA? If not, state reason you would object. Yes, but we really rather not use PANA. See below... 3) If you said yes to both 1 and 2, but have a strong preference between th= e two, which approach do you prefer and why? We strongly prefer EAP-in-PCP for several reasons: * PANA, as we understand it, is not mobile-friendly. It requires the PCP cl= ient to *always* have an authenticated session active and that is wasteful = on mobile clients when the authentication rekey interval is much shorter th= an the mapping lifetime. Margaret Wasserman captured this in slides 13 and = 14 of her presentation http://www.ietf.org/proceedings/85/slides/slides-85-= pcp-17.pdf. We believe the *client* should decide when to authenticate (bec= ause it needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption. We understand that a PCP server may need to send a message to the client wh= en no authenticated session is active. If no authenticated session is activ= e then we prefer the server send an UN-authenticated "call home" message di= recting the client to authenticate and then the server can send its message= s over the authenticated channel. We recognize an attacker can induce the c= lient to connect to the server by forging an unauthenticated "call home" me= ssage. But, having done that, the client can ignore subsequent forged call = home messages because it will already have an authenticated session. Worse = case, an attacker can't make EAP-in-PCP consume any more client resources t= han PANA does because PANA requires the client to always have an authentica= ted session available. * PANA requires more server side resources. The authentication protocol sho= uld efficiently support 100,000's of clients on a large PCP server. Why sho= uld the server continuously maintain authenticated sessions with *every* cl= ient? Clients using 24 hour mapping lifetimes can be served by short authen= tication key lifetime like, for example, 5 minutes. Let the client connect,= authenticate, program the mappings, and then let the authenticated session= expire. Rinse and repeat in 24 hours,. Client-driven authentication via EA= P-in-PCP requires less resources on the server because the server can disca= rd the authenticated session state once the key lifetime expires. There was some discussion that PANA is preferable to EAP-in-PCP because it = supports "liveness testing". We don't believe liveness testing is useful wh= en the server resources consumed, per client, are PCP mappings. Checking th= e liveness of 100,000 clients is much more resource intensive on the server= than just keeping the client's mappings around until they expire naturally= at the end of their lifetime. In short, we believe EAP-in-PCP will scale b= etter on the server than PANA. * We believe the decision to use EAP-in-PCP vs. PANA is a choice between de= signing and implementing an EAP-in-PCP transport that is tailored for PCP v= ersus adapting an existing protocol (PANA) to fit the needs of PCP. We don= 't think implementing an EAP-in-PCP transport is difficult so we prefer it = over PANA. EAP-in-PCP provides a clean slate that's unencumbered by the des= ign decisions and assumptions of an existing protocol (PANA). -Ben McCann _______________________________________________ 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 ------------------------------------------------------- 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 ------------------------------------------------------- _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp --_000_B235506D63D65E43B2E40FD27715372E1CE33CC5xmbrcdx07ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <70A514CDB1D69B4D88E38BA0FE205808@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


On 19/07/13 6:25 AM, "Ben McCann" <B.McCann@F5.com> wrote:

Hi Rafa,

I incorrectly used a discussion about the suitability of the OpenPANA&= nbsp; implementation as an argument to defend my statement "EAP-i= n-PCP provides a clean slate that's unencumbered by the design decisions an= d assumptions of an existing protocol (PANA).". That argument was a waste of time because the suitability or availability = of a reference implementation is irrelevant to whether PANA was designed wi= th a set of security considerations that are appropriate for PCP. This unde= rstanding of the security considerations is the "clean slate" that is important to me.

For example, PANA negotiates its own security association so it can pr= ovide data integrity for the final EAP response packet. That's fine, but wh= ere have we decided that PCP needs to secure the integrity of that response= packet? (It probably should). PANA does not secure the earlier EAP packets that carry parameters like the cip= her suite selection or authentication parameters for the selected EAP metho= d. So, those could be compromised by an attacker. Where have we decided tha= t this is an acceptable risk for PCP? We haven't discussed that, but we implicitly agree to live with it if= we move forward with PANA. (Or, at least, we accept that risk with some EA= P methods).

Agreed. REQ-5 that lists requirements in this area should discuss poin= ts you've highlighted.


I prefer EAP-in-PCP because it will make us think through those issues= for PCP. (We've made a good start in the auth requirements draft). Until w= e get those requirements down, I think it's premature to decide PANA is the= right choice. It might be, if we agree that PANA's security considerations are OK for PCP. Or, we could dec= ide that a simple EAP-in-PCP transport w/o *any* security association is su= fficient because we can leverage the security properties of EAP methods suc= h as EAP-TTLS to achieve the data integrity required for the EAP protocol.

TLS/DTLS is a good candidate to satisfy REQ-14:

REQ-14: There SHOULD be support for a means to provide integrity
protection without user authentication, i.e., an anonymous client
should be able to verify a PCP server using server-side-only auth
and as a consequence obtain an SA which will be used for PCP
message integrity. For example, a client visiting foreign
networks such as a hotel, hot spot etc where the client may gain
access to the network but does not know the credentials to
authenticate with the PCP server. The negotiation of SA should be
secure such that the SA is only known to the anonymous client and
PCP server.

-Prashanth


I'm vacation for two weeks and won't be in Berlin to continue this dis= cussion face-to-face.

-Ben McCann

-----Original Message-----
From: Rafa Marin Lopez [mailto:rafa@um.e= s]
Sent: Thursday, July 18, 2013 5:31 PM
To: Ben McCann
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP = security)

Hi Ben:

On Jul 18, 2013, at 7:00 PM, Ben McCann wrote:

Thank you for clarifying that "PANA does not force clients to alw= ays have a session, or always stay awake or connected".
That, I believe, wasn't Margaret's point. PANA *supports* server side = re-authentication even if the client doesn't think it's necessary. So, if t= he server chooses, it can wake up the client by sending packets. That said,= this really isn't a legitimate criticism of the PANA protocol. It's an issue that can be addressed by pro= per programming or configuration of the PCP/PANA server to make sure it doe= sn't unnecessarily re-authenticate the clients.
So, I agree with you that PANA, on a properly configured server, can b= e as "mobile friendly" and lightweight as EAP-in-PCP.
My concerns about starting from a clean slate are based, in part, on S= teve Hartman's "Implementation Analysis: strong preference for PCP-spe= cific approach" (http://www.ietf.org/mail-archive/web/pcp/current/msg0= 2324.html). His arguments were persuasive (to me) and the counter-arguments were not. =


I understand that implementation should not dictate protocol design bu= t I think we should let implementation *inform* protocol design. If I have = to select between two ways to define a protocol, and one of them is simpler= to implement, then I will tend to vote for the simpler option if all other criteria are equal. I see EAP-= in-PCP as the simpler option even if there is source code for PANA.
I've also reviewed the OpenPANA source code and I have some concerns t= hat illustrate this point:
* The PANA state machine includes 13 states with 22 separate input eve= nts. That state machine has to be integrated with the simpler PCP state mac= hine. My intuition, based on too many years of experience, is that integrat= ing the PANA and PCP state machines is tricky to implement, debug, and verify. That complexity is, in part, be= cause PANA already has a fairly complex state machine. I don't believe EAP-= in-PCP requires this much complexity.

[Rafa] Ben, I have always assumed we all have experience in the area. = In particular, I have been working on PANA since 2003 and I have done sourc= e coding myself, I have been leading an open source PANA implementation and= deployed PANA in several EU projects,  without any inconvenience so far.

About the state machine, I can tell you that part of it is completely = optional.

And about the integration between PANA and PCP, I disagree based on th= e experience we got from http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17

* The OpenPANA implementation is about 6900 SLOCs long as measured by = an sloccount version 2.26. This seems like a lot of code (aka complexity) t= o tunnel EAP packets over PCP. And, that doesn't include the code that must= be added to PCP required to integrate PCP with PANA. I believe an EAP-in-PCP implementation will be much simpler= but, I admit, I don't have an implementation to show you that proves that = point.

[Rafa] This number is completely wrong as I already explained in http://www.ietf.org/mail-archive/web/pcp/current/msg02631.html (as you = may observe this is a repeating conversation). You may agree with me that d= oing the sloccount  over the entire package does not help too muc= h. We need to be more specific.

In the message I already sent, the discussion was about openpana-0.2.3= . Right now, we have openpana-0.2.4 and we have new values. The following v= alues only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or RAD= IUS client since those values will be common to any other solution using EAP and RADIUS.

OpenPANA:

The PAA:

3130 LoC (PAA ST + PAA main program + PANA messages + PAA = session + PRF)

The PaC

2720 (PaC ST + PaC main + PANA messages + PaC session += ; PRF)

It is worth noting that those values includes 1846 LoCs which are comm= on functionality to PaC and PAA.

Moreover, as I also explained in the e-mail we have a version for very= constrained devices (sensor nodes). In particular we have a PaC implementa= tion for Contiki OS named PANATIKI (http://sourceforge.net/projects/panatiki) and the values are:

PANATIKI : 517 (PaC state machine) + 141 (PaC main program)

But again, please take into account this is just an open source implem= entation and not a product. And, of course, running code is absolutely bett= er than no code.

Regarding your comment "And, that doesn't include the code that m= ust be added to PCP required to integrate PCP with PANA", please see s= lide 12 in http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17  .&nbs= p; Just a 100 lines that includes "PCP Key derivation and export.= Unix Sockets."  in the case of OpenPANA.


* The presence of an open source version of PANA is a vote in its favo= r but that depends on whether that code is easily portable to many environm= ents. I think the OpenPANA implementation makes assumptions about its runti= me environment that aren't very portable. It assumes a multi-threaded environment with posix sockets and m= y runtime environment doesn't meet those requirements.

[Rafa] For example, PANATIKI does not assume multi-threaded environmen= t with posix sockets (it is an implementation for a sensor node after all).= Btw, there are two open source implementations OpenPANA/PANATIKI and CPANA= .

To be fair, I don't think I've said anything here that wasn't already = covered by Steve Hartman. But, I did review the code and I agree with his c= onclusions.

[Rafa] As you can see, I already counter-argumented that analysis. In = any case, I will be in Berlin so any doubt you have about OpenPana/PANATIKI= or just implementating PANA, let me know and I will be more than happy to = meet and discuss.

Best regards.

-Ben McCann
-----Original Message-----
From: Alper Yegin [mailto:alp= er.yegin@yegin.org]
Sent: Thursday, July 18, 2013 4:34 AM
To: Ben McCann
Cc: Dave Thaler; pcp@ietf.org
Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP
security)
Hello,
I'm afraid your below issues are based on misconceptions introduced by= the http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides.<= /div>
We did address those misconceptions in several rounds, but it seems li= ke some still linger.
PANA does not force clients to always have a session, or always stay a= wake or connected.
If a client wants to get authenticated and generate a 5 minute key, an= d afterwards sleep, detach, etc., it can very well do that using PANA.
We can support that by simply setting the lifetime of the PANA SA to t= hat short fix value, or letting the PANA SA timeout and expire.
So, you can run PANA and have a 5 min SA, then have no PANA activity f= or 23:55hrs, and then come back and do another PANA authentication and have= another 5min SA. No problems.
Therefore, there are no issues with mobile, and no issues with server = side resources.
After all, PANA is adopted by Zigbee Alliance. I don't think the deplo= yment cases considered here are any more constrained than theirs...
EAP-in-PCP provides a clean slate that's unencumbered by the design de= cisions and assumptions of an existing protocol (PANA).
Was there any other concern leading to your above statement?
Alper
On Jul 17, 2013, at 10:20 PM, Ben McCann wrote:
1) Could you *live with* EAP-in-PCP? If not, state reason you would ob= ject.
   YES
2) Could you *live with* PANA? If not, state reason you would object.<= /div>
   Yes, but we really rather not use PANA. See below...
3) If you said yes to both 1 and 2, but have a strong preference betwe= en the two, which approach do you prefer and why?
We strongly prefer EAP-in-PCP for several reasons:
* PANA, as we understand it, is not mobile-friendly. It requires the P= CP client to *always* have an authenticated session active and that is wast= eful on mobile clients when the authentication rekey interval is much short= er than the mapping lifetime. Margaret Wasserman captured this in slides 13 and 14 of her presentation http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We beli= eve the *client* should decide when to authenticate (because it needs to cr= eate or refresh a mapping) because that lets the client optimize its use of= the network and reduce its power consumption.
We understand that a PCP server may need to send a message to the clie= nt when no authenticated session is active. If no authenticated session is = active then we prefer the server send an UN-authenticated "call home&q= uot; message directing the client to authenticate and then the server can send its messages over the authenticated channel. = We recognize an attacker can induce the client to connect to the server by = forging an unauthenticated "call home" message. But, having done = that, the client can ignore subsequent forged call home messages because it will already have an authenticated session. = Worse case, an attacker can't make EAP-in-PCP consume any more client resou= rces than PANA does because PANA requires the client to always have an auth= enticated session available.
* PANA requires more server side resources. The authentication protoco= l should efficiently support 100,000's of clients on a large PCP server. Wh= y should the server continuously maintain authenticated sessions with *ever= y* client? Clients using 24 hour mapping lifetimes can be served by short authentication key lifetime like,= for example, 5 minutes. Let the client connect, authenticate, program the = mappings, and then let the authenticated session expire. Rinse and repeat i= n 24 hours,. Client-driven authentication via EAP-in-PCP requires less resources on the server because the server ca= n discard the authenticated session state once the key lifetime expires.
There was some discussion that PANA is preferable to EAP-in-PCP becaus= e it supports "liveness testing". We don't believe liveness testi= ng is useful when the server resources consumed, per client, are PCP mappin= gs. Checking the liveness of 100,000 clients is much more resource intensive on the server than just keeping the client= 's mappings around until they expire naturally at the end of their lifetime= . In short, we believe EAP-in-PCP will scale better on the server than PANA= .
* We believe the decision to use EAP-in-PCP vs. PANA is a choice betwe= en designing and implementing an EAP-in-PCP transport that is tailored for = PCP versus adapting an existing protocol (PANA) to fit the needs of PCP.&nb= sp; We don't think implementing an EAP-in-PCP transport is difficult so we prefer it over PANA. EAP-in-PCP provides a cl= ean slate that's unencumbered by the design decisions and assumptions of an= existing protocol (PANA).
-Ben McCann
_______________________________________________
pcp mailing list
_______________________________________________
pcp mailing list

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


_______________________________________________
pcp mailing list

--_000_B235506D63D65E43B2E40FD27715372E1CE33CC5xmbrcdx07ciscoc_-- From alper.yegin@yegin.org Fri Jul 19 06:22:10 2013 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 CCE0311E812C for ; Fri, 19 Jul 2013 06:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8BHS7i0tyxE for ; Fri, 19 Jul 2013 06:22:06 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E7E5F11E8144 for ; Fri, 19 Jul 2013 06:22:03 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LeeIQ-1UM6As2Xx0-00qUvV; Fri, 19 Jul 2013 09:22:01 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <913383AAA69FF945B8F946018B75898A14B9B7B8@xmb-rcd-x10.cisco.com> Date: Fri, 19 Jul 2013 16:21:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <913383AAA69FF945B8F946018B75898A14B9B7B8@xmb-rcd-x10.cisco.com> To: Tirumaleswar Reddy (tireddy) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:qwLCLEkl6f64yjPhugN0IWwpBTmV3qwbepqdsPcyRK1 CfwRpwQoW1xShxSMq6mkZ7EP+8VWu6mdFR6LJS5Ju87Ok48FvT 9wIzJhDdCxYs7YjLWPbJSTH69u0ahN7eRsR6YHAm60pOgoVtWn xlg8epGe2EueyQ5bPENdB+sbIpQn5aW6ifbBSg1w6XAYclTz75 tBOfFmYFcZYunBRdynl0AJbmehMHwkuGzYeHCbq+jOckZ+bjxd zn2arFT9TQCBEa1rMFs0BAHlBWtr9Wk0gSQcXBobl6RlVoJIVi RUn1P8kXJauH8hRDZHphabHOzy/h46Crl2NrDAts5ssYrGAogX Y4Fcj3v/VXEofImQM3kDAKBpBjb/TGujngAYva8sml2/5/V7Dc ntPIHmDEJdhmQ== Cc: "pcp@ietf.org" Subject: Re: [pcp] REQ-14 in PCP Authentication Requirements 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, 19 Jul 2013 13:22:11 -0000 They can use EAP-TLS with server-side-only authentication. On Jul 17, 2013, at 9:15 AM, Tirumaleswar Reddy (tireddy) wrote: > I have a clarification for both the drafts - how do EAP-in-PCP, PANA = solutions meet REQ-14 ? >=20 > --Tiru. >=20 >> -----Original Message----- >> From: Dave Thaler [mailto:dthaler@microsoft.com] >> Sent: Monday, July 15, 2013 6:03 AM >> To: pcp@ietf.org >> Subject: [pcp] CONSENSUS CALL on PCP security >>=20 >> The WG has discussed two approaches for using EAP with PCP: >> direct EAP-in-PCP vs using PANA. >>=20 >> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP >> and 10 or 11 for PANA. There was significant confusion/disagreement >> around requirements and proposed solutions at that time. >>=20 >> At IETF 85, we again polled the room and got a different result, this >> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, = however, >> still significant confusion/disagreement around requirements and >> proposed solutions. >>=20 >> Since IETF 85, we have made lots of progress on getting agreement >> on the requirements, and draft-reddy-pcp-auth-req now seems to be >> relatively stable without significant areas of disagreement known. >> Discussion may of course continue if new issues are raised but we >> believe any additional changes are unlikely to affect people's >> position on overall solution approach, i.e. direct EAP-in-PCP vs. = PANA. >>=20 >> The general sense of the WG also seems to be that either approach = could be >> made to fit the requirements, so we believe it is now time for us to >> determine consensus (draft-resnick-on-consensus is a great read) >> on the approach question. We know many folks would just like to >> make a decision and move on. >>=20 >> Hence the chairs would like to ask the WG which solution direction = the >> WG should pursue in meeting the requirements. Please state your >> recommendation on this thread, preferably along with your rationale. >> Avoid responding on this thread to others' rationale, use a separate >> thread as needed. >>=20 >> To help us judge consensus, please use the template below and >> respond by SUNDAY JULY 28. >>=20 >> -Dave and Reinaldo >>=20 >> --- >>=20 >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>=20 >> >>=20 >> 2) Could you *live with* PANA? If not, state reason you would object. >>=20 >> >>=20 >> 3) If you said yes to both 1 and 2, but have a strong preference = between >> the two, which approach do you prefer and why? >>=20 >> . >>=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From yoshihiro.ohba@toshiba.co.jp Fri Jul 19 06:41:52 2013 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 72BF411E812C for ; Fri, 19 Jul 2013 06:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKpJP4YxzMJJ for ; Fri, 19 Jul 2013 06:41:45 -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 1231A11E8118 for ; Fri, 19 Jul 2013 06:41:44 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r6JDfePG003443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 22:41:40 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6JDfeJ7021243; Fri, 19 Jul 2013 22:41:40 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 157; Fri, 19 Jul 2013 22:41:39 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6JDfdA8021064; Fri, 19 Jul 2013 22:41:39 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r6JDfdUJ002050; Fri, 19 Jul 2013 22:41:39 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id YAA02049; Fri, 19 Jul 2013 22:41:39 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r6JDfd0F022628; Fri, 19 Jul 2013 22:41:39 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r6JDfcHr027002; Fri, 19 Jul 2013 22:41:38 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.194]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 22:41:38 +0900 From: To: , Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOgrpla3wABna3lECF2TL4pPZxUpln5w+AgAKIlgD//4YaAIAAmElw//973ACAANgKEIAAgISAgACdabA= Date: Fri, 19 Jul 2013 13:41:37 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D31F29@tgxml338.toshiba.local> References: <674F70E5F2BE564CB06B6901FD3DD78B12D31838@tgxml338.toshiba.local> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.18.172] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D31F29tgxml338toshiba_" MIME-Version: 1.0 Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) 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, 19 Jul 2013 13:41:52 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D31F29tgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Prashanth, From: Prashanth Patil (praspati) [mailto:praspati@cisco.com] Sent: Friday, July 19, 2013 9:57 PM To: ohba yoshihiro; alper.yegin@yegin.org Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Distribution is not a good approach, brings in too many additional problems= . How does the PCP Server trust the proxy, how is the key distributed, shou= ld it all be facilitated over PCP etc ? [YO] Key distribution is common in EAP/AAA (e.g., MSK distribution from AAA= server to APs). Proxy itself needs to be authenticated by PCP server. The= resulting SA created between the proxy and server can be used as the secur= e channel for the key distribution. Details will need to be worked out, but= I think we need to agree on the use case and requirement before entering i= nto solution space. Having said that I think the current PCP authentication requirements are st= ill unclear in terms of proxy support. The above problems aside, as being discussed in other threads, the role of = the PCP proxy is not just that of forwarding but also acting on the request= , installing state etc and does all of this based on its own policy. Also, = an ISP's PCP server does not need to know of the different users within the= home and has no incentive to individually authenticate each of those diffe= rent users - it's only interesting to the proxy (the PCP server as far as t= he individual home users are concerned). For all these reasons, the two legs are independent and need to have indepe= ndent authentication. [YO] I agree that your model is definitely *a* valid use case, but my whole= point is that there are other proxy use cases that would require end-to-en= d authentication between clients and server (e.g., public wifi hotspot). Yoshihiro Ohba -Prashanth On 19/07/13 1:49 AM, "yoshihiro.ohba@toshiba.co.jp" > wrote: Well, that is easy: Once the PCP server successfully authenticate a PCP cli= ent, it distributes a key used for protecting PCP message between the PCP c= lient and the PCP proxy to the PCP proxy in a secure way. Regards, Yoshihiro Ohba From: Prashanth Patil (praspati) [mailto:praspati@cisco.com] Sent: Friday, July 19, 2013 1:23 AM To: ohba yoshihiro; alper.yegin@yegin.org Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Yoshihiro, On 18/07/13 8:59 PM, "yoshihiro.ohba@toshiba.co.jp" > wrote: Hi Prashanth, From: Prashanth Patil (praspati) [mailto:praspati@cisco.com] Sent: Friday, July 19, 2013 12:11 AM To: ohba yoshihiro(=1B$BBg>l5AMN!{#R#D#C""#N#S#L=1B(B); alper.yegin@yegin.o= rg Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Yoshihiro, Although the abstract says that, I don=1B$B!G=1B(Bt think the intent is for= the PCP Proxy to just be a relay agent. It is clear from other sections of= the draft that the proxy is indeed a server and needs to modify fields (al= beit minimal) before forwarding them to the actual server. This implies two= independent authentications need to happen. [YO] I don=1B$B!G=1B(Bt understand your logic here. Even an http proxy can = modify http requests (e.g., X-Forwarded-For header), and an http server can= still authenticate http clients behind the proxy. How does the proxy maintain message integrity if it modifies requests/respo= nses? The case is different with HTTP. -Prashanth Yoshihiro Ohba -Prashanth On 18/07/13 7:09 PM, "yoshihiro.ohba@toshiba.co.jp" > wrote: Hi Tiru, Abstract of pcp-proxy draft says: =1B$B!H=1B(B This document specifies a new PCP functional element denoted as PCP Proxy. The PCP Proxy relays PCP requests received from PCP Clients to upstream PCP Server(s). This function is mandatory when PCP Clients can not be configured with the address of the PCP Server located more than one hop. =1B$B!H=1B(B If this abstract is correct, I interpret that PCP clients only know the PCP= proxy=1B$B!G=1B(Bs address, but the PCP server *can* be the authentication= end-point for the PCP clients. This is similar to the http proxy case whe= re http servers are the authentication end-points for http clients. Having= said that, I think it is a bad idea to mandate PCP proxy to be *the* end-p= oint that authenticates the PCP clients in the proxy case. Yoshihiro Ohba From:pcp-bounces@ietf.org [mailto:pcp-bounces@= ietf.org] On Behalf Of Prashanth Patil (praspati) Sent: Wednesday, July 17, 2013 4:46 PM To: Alper Yegin Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security) Hi Alper, On 17/07/13 12:23 PM, "Alper Yegin" > wrote: Hi Prashanth, I'm not sure if enough thought went into the PCP Proxy security. As much as= I'd love to be DONE! with this discussion, I also want to make sure people= feel comfortable having thought all aspects around the proxy use. For (ver= y important) example, what kind of security associations are needed for sec= uring the proxy use: An SA btw client and server, an SA btw client and prox= y, an SA btw proxy and server -- which combinations of these are needed? We've included this in the updated version of auth req: REQ-9: A PCP proxy that modifies PCP messages SHOULD have the ability to independently authenticate with the PCP client and PCP server. The presence of a PCP proxy hence requires two separately authenticates SAs. As a consequence, the PCP proxy: A. MUST be able to validate message integrity of PCP messages from the PCP server and client respectively. B. MUST be able to ensure message integrity after updating the PCP message for cases described in sections 6 of ietf-pcp-proxy. The PCP proxy MUST also permit authentication on only one side of the proxy. For example, a customer premises host may not authenticate with the PCP proxy but the PCP proxy may authenticate with the PCP server. So: - We have two types of SAs. One between the client and the proxy, another b= etween the proxy and the server. - None of them are mandatory to use. PRA: Yes, none of them are mandatory, it's currently the prerogative of the= server to mandate authentication. The proxy MUST be able authenticate with= either client or server or both. For each one that needs to be used, we need to perform authentication betwe= en the end-points. (e.g., between client and proxy). So, in a way, we are dealing with security in two independent parts; client= to proxy, and proxy to server. They are totally segregated from security perspective. Right? PRA: Right. As far as the client is concerned, the proxy is the PCP server.= The proxy is in turn a client to the upstream PCP server. The two parts sh= ould be independent of each other. Hmm, one thing: The server may need to know the authenticated ID of the cli= ent. Since it's not part of the client authentication, it won't know that v= alue readily. So, we may need to define an option to carry that piece of in= formation from the proxy to the server. PRA: May be, but don=1B$B!G=1B(Bt know why the server would want to know th= e auth-id of a client. -Prashanth Alper -Prashanth Then we need to talk about how we dynamically create those using any one of= these solutions. Alper On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Monday, July 15, 2013 10:51 PM To: Dave Thaler; pcp@ietf.org Subject: RE: [pcp] CONSENSUS CALL on PCP security Hi Dave, In the poll when you refer to PANA, please clarify the draft you are referr= ing to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? --Tiru. The question is intentionally agnostic as this is about a general approach, not which specific implementation. If it helps, you can interpret the answer as "which of the two you think is better". If the consensus is PANA rather than direct EAP-in-PCP, then we could ask as a follow-up question which of the two we should go with. If you'd like to include your answer to that now though, feel free to include that in your response to the call. -Dave _______________________________________________ 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 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D31F29tgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Prashanth,

 <= /o:p>

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif";mso-fareast-language:JA"> Prashanth Patil (praspati) [mailto:praspati@cisco.com]
Sent: Friday, July 19, 2013 9:57 PM
To: ohba yoshihiro; alper.yegin@yegin.org
Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)

 

Distribution is not a good appr= oach, brings in too many additional problems. How does the PCP Server trust the proxy, how is the key distributed, should it all be facil= itated over PCP etc ?

[YO] Key distribution is com= mon in EAP/AAA (e.g., MSK distribution from AAA server to APs). Proxy itself needs to be authenticated by PCP server.  The resulting = SA created between the proxy and server can be used as the secure channel f= or the key distribution. Details will need to be worked out, but I think we= need to agree on the use case and requirement before entering into solution space.

 =

Having said that I think the= current PCP authentication requirements are still unclear  in terms of proxy support.

 

The above problems aside, as be= ing discussed in other threads, the role of the PCP proxy is not just that of forwarding but also acting on the request, installing sta= te etc and does all of this based on its own policy. Also, an ISP= 's PCP server does not need to know of the different users within the home an= d has no incentive to individually authenticate each of those different use= rs – it's only interesting to the proxy (the PCP server as far as the= individual home users are concerned).

[YO] I agree that your model= is definitely *a* valid use case, but my whole point is that there are other proxy use cases that would require end-to-end authenticati= on between clients and server (e.g., public wifi hotspot).

 =

Yoshihiro Ohba

 

 

 

 

Well, that is easy: Once the PC= P server successfully authenticate a PCP client, it distributes a key used for protecting PCP message between the PCP client and the PCP p= roxy to the PCP proxy in a secure way.

 

Regards,

Yoshihiro Ohba

 

 

From: Prashanth Patil (praspati) [mailto:p= raspati@cisco.com]
Sent: Friday, July 19, 2013 1:23 AM
To: ohba yoshihiro; alper.y= egin@yegin.org
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)<= /p>

 

Hi Yoshihiro,

 

 

Hi Prashanth,

 

 

From: Prashanth Patil (praspati) [mailto:p= raspati@cisco.com]
Sent: Friday, July 19, 2013 12:11 AM
To: ohba yoshihiro(=1B$BBg>l5AMN=1B(B=1B$B!{=1B(B=1B$B#R#D#C=1B(B=1B$B""=1B(B=1B$B#N#S#L=1B(B); alper.yegin@yegin.org
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)<= /p>

 

Hi Yoshihiro,

Although the abstract says th= at, I don=1B$B!G=1B(Bt think the intent is for the PCP Proxy to just be a relay agent. It is clear from other sections of the draft that the proxy= is indeed a server and needs to modify fields (albeit minimal) before forw= arding them to the actual server. This implies two independent authenticati= ons need to happen.<= /o:p>

[YO] I don=1B$B!G=1B(Bt= understand your logic here. Even an http proxy can modify http requests (e.g., X-Forwarded-For header), and an http server can still authenticate = http clients behind the proxy.

 

How does the proxy maintain mes= sage integrity if it modifies requests/responses? The case is different with HTTP.

 

-Prashanth

 

Yoshihiro Ohba

 

-Prashanth

 

On 18/07/13 7:09 PM, "yoshihiro.ohba@toshiba.co.jp<= /a>" <yoshihiro.ohba@toshiba= .co.jp> wrote:

 

Hi Tiru,

 

Abstract of pcp-proxy draft s= ays:

 

=1B$B!H=1B(B

   This document specifies a new = PCP functional element denoted as PCP

   Proxy.  The PCP Proxy rel= ays PCP requests received from PCP Clients

   to upstream PCP Server(s).&nbs= p; This function is mandatory when PCP

   Clients can not be configured = with the address of the PCP Server

   located more than one hop.

=1B$B!H=1B(B

 

If this abstract is correct, = I interpret that PCP clients only know the PCP proxy=1B$B!G=1B(Bs address, but the PCP server *can* be the authentication end-point for the PC= P clients.  This is similar to the http proxy case where http servers = are the authentication end-points for http clients.  Having said that,= I think it is a bad idea to mandate PCP proxy to be *the* end-point that authenticates the PCP clients in the pro= xy case.

 

Yoshihiro Ohba

 

 

 

From:pcp-bo= unces@ietf.org [mailto:pcp-bounces@ietf.org] = On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: pcp@ietf.org; Tirumaleswar R= eddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP sec= urity)<= /p>

 

Hi Alper,

 

On 17/07/13 12:23 PM, "A= lper Yegin" <alper.yegin@y= egin.org> wrote:=

 

Hi Prashanth,

 






I'm not sure if enough though= t went into the PCP Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfortab= le having thought all aspects around the proxy use. For (very important) ex= ample, what kind of security associations are needed for securing the proxy= use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinatio= ns of these are needed?

 

We've included this in the up= dated version of auth req:

 

REQ-9: A PCP proxy that mo= difies PCP messages SHOULD have the

ability to independently a= uthenticate with the PCP client and PCP

server. The presence of a = PCP proxy hence requires two separately

authenticates SAs. As a co= nsequence, the PCP proxy:

 

A. MUST be able to validat= e message integrity of PCP messages

from the PCP server and cl= ient respectively.

 

B. MUST be able to ensure = message integrity after updating the

PCP message for cases desc= ribed in sections 6 of ietf-pcp-proxy.

 

The PCP proxy MUST also pe= rmit authentication on only one side of

the proxy. For example, a = customer premises host may not

authenticate with the PCP = proxy but the PCP proxy may authenticate

with the PCP server.

 

 

 

So:

 

- We have two types of SAs. O= ne between the client and the proxy, another between the proxy and the server.

- None of them are mandatory = to use.=

 

PRA: Yes, none of them are ma= ndatory, it's currently the prerogative of the server to mandate authentication. The proxy MUST be able authenticate with either client or = server or both.

 

For each one that needs to be= used, we need to perform authentication between the end-points. 

(e.g., between client and pro= xy).

 

So, in a way, we are dealing = with security in two independent parts; client to proxy, and proxy to server. 

They are totally segregated f= rom security perspective. 

 

Right?

 

PRA: Right. As far as the cli= ent is concerned, the proxy is the PCP server. The proxy is in turn a client to the upstream PCP server. The two parts should be indep= endent of each other.

 

Hmm, one thing: The server ma= y need to know the authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. S= o, we may need to define an option to carry that piece of information from = the proxy to the server.<= o:p>

 

PRA: May be, but don=1B$B!G= =1B(Bt know why the server would want to know the auth-id of a client.

 

-Prashanth 

 

Alper

 

 

 






-Prashanth

 

Then we need to talk about ho= w we dynamically create those using any one of these solutions.

 

Alper

 

 

 

 

 

On Jul 16, 2013, at 7:50 PM, = Dave Thaler wrote:

 

-----Original Message-----

From: Tirumaleswar Reddy (tir= eddy) [mailto:tireddy@cisco.com]

Sent: Monday, July 15, 2013 1= 0:51 PM=

To: Dave Thaler; pcp@ietf.org

Subject: RE: [pcp] CONSENSUS = CALL on PCP security=

Hi Dave,

In the poll when you refer to= PANA, please clarify the draft you are referring

--Tiru.

The question is intentionally= agnostic as this is about a general approach,

not which specific implementa= tion.  If it helps, you can interpret the

answer as "which of the = two you think is better".

If the consensus is PANA rath= er than direct EAP-in-PCP, then we could

ask as a follow-up question w= hich of the two we should go with. If

you'd like to include your an= swer to that now though, feel free to

include that in your response= to the call.<= /span>

-Dave

_____________________________= __________________

pcp mailing list

pcp@ietf.org<= /o:p>

 

_____________________________= __________________

pcp mailing list

pcp@ietf.org<= /o:p>

 

 

--_000_674F70E5F2BE564CB06B6901FD3DD78B12D31F29tgxml338toshiba_-- From rafa@um.es Sun Jul 21 16:44:00 2013 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 08B5721F96A7 for ; Sun, 21 Jul 2013 16:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH3ETfZwytIs for ; Sun, 21 Jul 2013 16:43:53 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id BC6E421F8749 for ; Sun, 21 Jul 2013 16:43:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id C83D25D4D5; Mon, 22 Jul 2013 01:43:50 +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 Phtk+W-qwYDY; Mon, 22 Jul 2013 01:43:49 +0200 (CEST) Received: from [192.168.1.67] (188.Red-79-159-149.staticIP.rima-tde.net [79.159.149.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPSA id 3A6415D4D2; Mon, 22 Jul 2013 01:43:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-1-1006033373 From: Rafa Marin Lopez In-Reply-To: <9374F3A019050A4C805B8DEF27285BE40115E08BCF@LWLMBX01.olympus.F5Net.com> Date: Mon, 22 Jul 2013 01:43:44 +0200 Message-Id: References: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> <76B8454D-73F0-4E3D-81A6-55F121535901@um.es> <9374F3A019050A4C805B8DEF27285BE40115E08BCF@LWLMBX01.olympus.F5Net.com> To: Ben McCann X-Mailer: Apple Mail (2.1085) Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) 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, 21 Jul 2013 23:44:00 -0000 --Apple-Mail-1-1006033373 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ben: On Jul 19, 2013, at 2:55 AM, Ben McCann wrote: > Hi Rafa, >=20 > I incorrectly used a discussion about the suitability of the OpenPANA = implementation as an argument to defend my statement "EAP-in-PCP = provides a clean slate that's unencumbered by the design decisions and = assumptions of an existing protocol (PANA).". That argument was a waste = of time because the suitability or availability of a reference = implementation is irrelevant to whether PANA was designed with a set of = security considerations that are appropriate for PCP. This understanding = of the security considerations is the "clean slate" that is important to = me. [Rafa] I must say I am a little bit confused about your general line of = thoughts here. You started your arguments first saying about PANA is not = mobile-friendly, then PANA consumes resources and then implementation = problems or the liveliness test. Those are clearly misconceptions about = PANA that we have clarified. Now, "clean slate" is regarding security = considerations. Ok, let us discuss about security, but you may agree = with me that this line of arguments might be a little bit confusing.=20 >=20 > For example, PANA negotiates its own security association so it can = provide data integrity for the final EAP response packet. > That's fine, but where have we decided that PCP needs to secure the = integrity of that response packet? (It probably should). [Rafa] The main purpose of the PANA SA does not have anything to do with = protecting the final EAP response packet. As many security protocols, it = provides key confirmation to bind authentication with the exported key = material by EAP. This is a cryptographic binding between the two = layers. This ensures that same two entities participate not only = performing EAP but also the EAP lower-layer protocol. This is useful to = avoid man-in-the-middle attacks. Moreover it serves to avoid the attack = you mention about ciphersuite and authentication parameters below (see = how PANA generates the PANA_AUTH_KEY).=20 > PANA does not secure the earlier EAP packets that carry parameters = like the cipher suite selection or authentication parameters for the = selected EAP method. So, those could be compromised by an attacker. = Where have we decided that this is an acceptable risk for PCP? [Rafa] If you don't have any keys.... how are you supposed to protect = anything? If we assume we are performing EAP for authentication and key = management, we will not have any key material exported to any EAP = lower-layer (e.g. PCP or PANA) until EAP is successfully finished at the = end. Moreover EAP is designed to operate with no security assumption in = the lower-layer.=20 =20 > We haven't discussed that, but we implicitly agree to live with it if = we move forward with PANA. (Or, at least, we accept that risk with some = EAP methods). [Rafa] See my comment above, there is no such a risk. Btw, what EAP = methods are you referring to? As I said EAP is designed to operate with = no security. >=20 > I prefer EAP-in-PCP because it will make us think through those issues = for PCP. (We've made a good start in the auth requirements draft). [Rafa] About simplicity, how about this? Let assume that the only thing = you have to worry about at PCP level is to manage a pre-shared key = between PCP client and PCP server. That is simple, don't you think? > Until we get those requirements down, I think it's premature to decide = PANA is the right choice. [Rafa] Then, do you think the consensus call is too premature?=20 > It might be, if we agree that PANA's security considerations are OK = for PCP. Or, we could decide that a simple EAP-in-PCP transport w/o = *any* security association is sufficient because we can leverage the = security properties of EAP methods such as EAP-TTLS to achieve the data = integrity required for the EAP protocol. [Rafa] Either or I don't understand your point or I think there is some = confusion about EAP and its layers (see Fig. 1 and 2 in RFC 3748) = EAP-TTLS is a method and it will export keys to the EAP lower-layer . = Why do you relate EAP-TTLS with the protection of the EAP protocol ? In this regard, I also think there is a general misconception about EAP. = For example, people may think that this is just tunneling EAP in PCP (I = think you even mentioned this in a previous e-mail). But it is not. RFC = 3748 defines requirements for a correct EAP lower-layer. If we transport = EAP in PCP , PCP will become an EAP lower-layer according to the EAP = standard. Consequence is PCP has to follow requirements imposed by RFC = 3748 and RFC 5247 to be a correct EAP lower-layer. In other words, this = means we will have to define a new EAP lower-layer and to follow the = same path we already followed with PANA which is a RFC now. In other = words, we are essentially re-inventing the wheel (I say this based also = on experience since, at research level, I have tried to design different = EAP lower-layers... EAP-in-X, EAP-in-Y, etc...). I would appreciate if = you could read this link I sent to the list about this aspect: = http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html The usage of PANA avoids to include all these aspects in PCP itself = (PANA already does it), and as a consequence the PCP security would be = simplified a lot. >=20 > I'm vacation for two weeks and won't be in Berlin to continue this = discussion face-to-face. Enjoy your vacations! >=20 > -Ben McCann >=20 > -----Original Message----- > From: Rafa Marin Lopez [mailto:rafa@um.es]=20 > Sent: Thursday, July 18, 2013 5:31 PM > To: Ben McCann > Cc: pcp@ietf.org > Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP = security) >=20 > Hi Ben: >=20 > On Jul 18, 2013, at 7:00 PM, Ben McCann wrote: >=20 >> Thank you for clarifying that "PANA does not force clients to always = have a session, or always stay awake or connected". >>=20 >> That, I believe, wasn't Margaret's point. PANA *supports* server side = re-authentication even if the client doesn't think it's necessary. So, = if the server chooses, it can wake up the client by sending packets. = That said, this really isn't a legitimate criticism of the PANA = protocol. It's an issue that can be addressed by proper programming or = configuration of the PCP/PANA server to make sure it doesn't = unnecessarily re-authenticate the clients.=20 >>=20 >> So, I agree with you that PANA, on a properly configured server, can = be as "mobile friendly" and lightweight as EAP-in-PCP.=20 >>=20 >>=20 >> My concerns about starting from a clean slate are based, in part, on = Steve Hartman's "Implementation Analysis: strong preference for = PCP-specific approach" = (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His = arguments were persuasive (to me) and the counter-arguments were not.=20 >=20 > [Rafa] Why my answers in = http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html are not = ok? >=20 >>=20 >> I understand that implementation should not dictate protocol design = but I think we should let implementation *inform* protocol design. If I = have to select between two ways to define a protocol, and one of them is = simpler to implement, then I will tend to vote for the simpler option if = all other criteria are equal. I see EAP-in-PCP as the simpler option = even if there is source code for PANA. >>=20 >> I've also reviewed the OpenPANA source code and I have some concerns = that illustrate this point: >>=20 >> * The PANA state machine includes 13 states with 22 separate input = events. That state machine has to be integrated with the simpler PCP = state machine. My intuition, based on too many years of experience, is = that integrating the PANA and PCP state machines is tricky to implement, = debug, and verify. That complexity is, in part, because PANA already has = a fairly complex state machine. I don't believe EAP-in-PCP requires this = much complexity. >=20 > [Rafa] Ben, I have always assumed we all have experience in the area. = In particular, I have been working on PANA since 2003 and I have done = source coding myself, I have been leading an open source PANA = implementation and deployed PANA in several EU projects, without any = inconvenience so far. >=20 > About the state machine, I can tell you that part of it is completely = optional.=20 >=20 > And about the integration between PANA and PCP, I disagree based on = the experience we got from = http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 >=20 >>=20 >> * The OpenPANA implementation is about 6900 SLOCs long as measured by = an sloccount version 2.26. This seems like a lot of code (aka = complexity) to tunnel EAP packets over PCP. And, that doesn't include = the code that must be added to PCP required to integrate PCP with PANA. = I believe an EAP-in-PCP implementation will be much simpler but, I = admit, I don't have an implementation to show you that proves that = point. >=20 > [Rafa] This number is completely wrong as I already explained in = http://www.ietf.org/mail-archive/web/pcp/current/msg02631.html (as you = may observe this is a repeating conversation). You may agree with me = that doing the sloccount over the entire package does not help too = much. We need to be more specific. >=20 > In the message I already sent, the discussion was about = openpana-0.2.3. Right now, we have openpana-0.2.4 and we have new = values. The following values only show the LoC dedicated to PANA, not to = EAP ST, EAP-Method or RADIUS client since those values will be common to = any other solution using EAP and RADIUS. >=20 > OpenPANA: >=20 > The PAA: >=20 > 3130 LoC (PAA ST + PAA main program + PANA messages + PAA session + = PRF) >=20 > The PaC >=20 > 2720 (PaC ST + PaC main + PANA messages + PaC session + PRF) >=20 > It is worth noting that those values includes 1846 LoCs which are = common functionality to PaC and PAA. >=20 > Moreover, as I also explained in the e-mail we have a version for very = constrained devices (sensor nodes). In particular we have a PaC = implementation for Contiki OS named PANATIKI = (http://sourceforge.net/projects/panatiki) and the values are:=20 >=20 > PANATIKI : 517 (PaC state machine) + 141 (PaC main program) >=20 > But again, please take into account this is just an open source = implementation and not a product. And, of course, running code is = absolutely better than no code. >=20 > Regarding your comment "And, that doesn't include the code that must = be added to PCP required to integrate PCP with PANA", please see slide = 12 in http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 . = Just a 100 lines that includes "PCP Key derivation and export. Unix = Sockets." in the case of OpenPANA. >=20 >=20 >>=20 >> * The presence of an open source version of PANA is a vote in its = favor but that depends on whether that code is easily portable to many = environments. I think the OpenPANA implementation makes assumptions = about its runtime environment that aren't very portable. It assumes a = multi-threaded environment with posix sockets and my runtime environment = doesn't meet those requirements. >=20 > [Rafa] For example, PANATIKI does not assume multi-threaded = environment with posix sockets (it is an implementation for a sensor = node after all). Btw, there are two open source implementations = OpenPANA/PANATIKI and CPANA. >=20 >>=20 >> To be fair, I don't think I've said anything here that wasn't already = covered by Steve Hartman. But, I did review the code and I agree with = his conclusions. >=20 > [Rafa] As you can see, I already counter-argumented that analysis. In = any case, I will be in Berlin so any doubt you have about = OpenPana/PANATIKI or just implementating PANA, let me know and I will be = more than happy to meet and discuss. >=20 > Best regards. >=20 >>=20 >> -Ben McCann >>=20 >> -----Original Message----- >> From: Alper Yegin [mailto:alper.yegin@yegin.org] >> Sent: Thursday, July 18, 2013 4:34 AM >> To: Ben McCann >> Cc: Dave Thaler; pcp@ietf.org >> Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP=20 >> security) >>=20 >> Hello, >>=20 >> I'm afraid your below issues are based on misconceptions introduced = by the http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf = slides. >> We did address those misconceptions in several rounds, but it seems = like some still linger. >>=20 >> PANA does not force clients to always have a session, or always stay = awake or connected. >>=20 >> If a client wants to get authenticated and generate a 5 minute key, = and afterwards sleep, detach, etc., it can very well do that using PANA. >> We can support that by simply setting the lifetime of the PANA SA to = that short fix value, or letting the PANA SA timeout and expire.=20 >> So, you can run PANA and have a 5 min SA, then have no PANA activity = for 23:55hrs, and then come back and do another PANA authentication and = have another 5min SA. No problems. >>=20 >> Therefore, there are no issues with mobile, and no issues with server = side resources. >>=20 >> After all, PANA is adopted by Zigbee Alliance. I don't think the = deployment cases considered here are any more constrained than theirs... >>=20 >>> EAP-in-PCP provides a clean slate that's unencumbered by the design = decisions and assumptions of an existing protocol (PANA).=20 >>=20 >>=20 >> Was there any other concern leading to your above statement? >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: >>=20 >>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>>=20 >>> YES >>>=20 >>> 2) Could you *live with* PANA? If not, state reason you would = object. >>>=20 >>> Yes, but we really rather not use PANA. See below... >>>=20 >>> 3) If you said yes to both 1 and 2, but have a strong preference = between the two, which approach do you prefer and why? >>>=20 >>> We strongly prefer EAP-in-PCP for several reasons: >>>=20 >>> * PANA, as we understand it, is not mobile-friendly. It requires the = PCP client to *always* have an authenticated session active and that is = wasteful on mobile clients when the authentication rekey interval is = much shorter than the mapping lifetime. Margaret Wasserman captured this = in slides 13 and 14 of her presentation = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We = believe the *client* should decide when to authenticate (because it = needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption.=20 >>>=20 >>> We understand that a PCP server may need to send a message to the = client when no authenticated session is active. If no authenticated = session is active then we prefer the server send an UN-authenticated = "call home" message directing the client to authenticate and then the = server can send its messages over the authenticated channel. We = recognize an attacker can induce the client to connect to the server by = forging an unauthenticated "call home" message. But, having done that, = the client can ignore subsequent forged call home messages because it = will already have an authenticated session. Worse case, an attacker = can't make EAP-in-PCP consume any more client resources than PANA does = because PANA requires the client to always have an authenticated session = available. >>>=20 >>> * PANA requires more server side resources. The authentication = protocol should efficiently support 100,000's of clients on a large PCP = server. Why should the server continuously maintain authenticated = sessions with *every* client? Clients using 24 hour mapping lifetimes = can be served by short authentication key lifetime like, for example, 5 = minutes. Let the client connect, authenticate, program the mappings, and = then let the authenticated session expire. Rinse and repeat in 24 = hours,. Client-driven authentication via EAP-in-PCP requires less = resources on the server because the server can discard the authenticated = session state once the key lifetime expires. >>>=20 >>> There was some discussion that PANA is preferable to EAP-in-PCP = because it supports "liveness testing". We don't believe liveness = testing is useful when the server resources consumed, per client, are = PCP mappings. Checking the liveness of 100,000 clients is much more = resource intensive on the server than just keeping the client's mappings = around until they expire naturally at the end of their lifetime. In = short, we believe EAP-in-PCP will scale better on the server than PANA. >>>=20 >>> * We believe the decision to use EAP-in-PCP vs. PANA is a choice = between designing and implementing an EAP-in-PCP transport that is = tailored for PCP versus adapting an existing protocol (PANA) to fit the = needs of PCP. We don't think implementing an EAP-in-PCP transport is = difficult so we prefer it over PANA. EAP-in-PCP provides a clean slate = that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).=20 >>>=20 >>> -Ben McCann >>>=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 > ------------------------------------------------------- > 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 > ------------------------------------------------------- >=20 >=20 ------------------------------------------------------- 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 ------------------------------------------------------- --Apple-Mail-1-1006033373 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Ben:

On Jul 19, 2013, at 2:55 AM, Ben = McCann wrote:

Hi Rafa,

I incorrectly used a discussion about = the suitability of the OpenPANA  implementation as an argument to = defend my statement "EAP-in-PCP provides a clean slate that's = unencumbered by the design decisions and assumptions of an existing = protocol (PANA).". That argument was a waste of time because the = suitability or availability of a reference implementation is irrelevant = to whether PANA was designed with a set of security considerations that = are appropriate for PCP. This understanding of the security = considerations is the "clean slate" that is important to = me.

[Rafa] I must say I am a = little bit confused about your general line of thoughts here. You = started your arguments first saying about PANA is not mobile-friendly, = then PANA consumes resources and then implementation problems or the = liveliness test. Those are clearly misconceptions about PANA that we = have clarified. Now, "clean slate" is regarding security = considerations. Ok, let us discuss about security, but you may agree = with me that this line of arguments might be a little bit = confusing. 


For = example, PANA negotiates its own security association so it can provide = data integrity for the final EAP response = packet.
That's fine, = but where have we decided that PCP needs to secure the integrity of that = response packet? (It probably = should).

[Rafa] The main = purpose of the PANA SA does not have anything to do with protecting the = final EAP response packet. As many security protocols, it provides key = confirmation to bind authentication with the exported key material by = EAP. This  is a cryptographic binding between the two layers. This = ensures that same two entities participate not only performing EAP but = also the EAP lower-layer protocol. This is useful to avoid = man-in-the-middle attacks. Moreover it serves to avoid the attack = you mention about ciphersuite and authentication parameters below (see = how PANA generates the PANA_AUTH_KEY). 

PANA does not secure the earlier EAP packets that = carry parameters like the cipher suite selection or authentication = parameters for the selected EAP method. So, those could be compromised = by an attacker. Where have we decided that this is an acceptable risk = for PCP?

[Rafa] If you don't have = any keys.... how are you supposed to protect anything?  If we = assume we are performing EAP for authentication and key management, we = will not have any key material exported to any EAP lower-layer (e.g. PCP = or PANA) until EAP is successfully finished at the end.  Moreover = EAP is designed to operate with no security assumption in the = lower-layer. 
 
We= haven't discussed that, but we implicitly agree to live with it if we = move forward with PANA. (Or, at least, we accept that risk with some EAP = methods).

[Rafa] See my = comment above, there is no such a risk. Btw, what EAP methods are you = referring to? As I said EAP is designed to operate with no = security.


I prefer = EAP-in-PCP because it will make us think through those issues for PCP. = (We've made a good start in the auth requirements = draft).

[Rafa] About simplicity, = how about this? Let assume that the only thing you have to worry about = at PCP level is to manage a pre-shared key between PCP client and PCP = server. That is simple, don't you think?

Until we get those requirements down, I think it's = premature to decide PANA is the right = choice.

[Rafa] Then, do you think = the consensus call is too premature? 

It might be, if we agree that PANA's security = considerations are OK for PCP. Or, we could decide that a simple = EAP-in-PCP transport w/o *any* security association is sufficient = because we can leverage the security properties of EAP methods such as = EAP-TTLS to achieve the data integrity required for the EAP = protocol.

[Rafa] Either or I = don't understand your point or I think there is some confusion about EAP = and its layers (see Fig. 1 and 2 in RFC 3748) EAP-TTLS is a method = and it will export keys to the EAP lower-layer . Why do you relate = EAP-TTLS with the protection of the EAP protocol = ?

In this regard, I also think there is a = general misconception about EAP. For example, people may think that this = is just tunneling EAP in PCP (I think you even mentioned this in a = previous e-mail). But it is not. RFC 3748 defines requirements for a = correct EAP lower-layer. If we transport EAP in PCP , PCP will become an = EAP lower-layer according to the EAP standard. Consequence is PCP has to = follow requirements imposed by RFC 3748 and RFC 5247 to be a correct EAP = lower-layer. In other words, this means we will have to define a new EAP = lower-layer and to follow the same path we already followed with PANA = which is a RFC now. In other words, we are essentially re-inventing the = wheel (I say this based also on experience since, at research level, I = have tried to design different EAP lower-layers... EAP-in-X, EAP-in-Y, = etc...). I would appreciate if you could read this link I sent to the = list about this aspect:  ht= tp://www.ietf.org/mail-archive/web/pcp/current/msg02349.html

The usage of PANA avoids to include all these aspects in = PCP itself (PANA already does it), and as a consequence the PCP security = would be simplified a lot.


I'm= vacation for two weeks and won't be in Berlin to continue this = discussion face-to-face.

Enjoy = your vacations!


-Ben = McCann

-----Original Message-----
From: Rafa Marin Lopez = [mailto:rafa@um.es]
Sent: Thursday, July 18, 2013 5:31 PM
To: Ben = McCann
Cc: pcp@ietf.org
Subject:= Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP = security)

Hi Ben:

On Jul 18, 2013, at 7:00 PM, Ben McCann = wrote:

Thank you for clarifying that = "PANA does not force clients to always have a session, or always stay = awake or connected".

That, I = believe, wasn't Margaret's point. PANA *supports* server side = re-authentication even if the client doesn't think it's necessary. So, = if the server chooses, it can wake up the client by sending packets. = That said, this really isn't a legitimate criticism of the PANA = protocol. It's an issue that can be addressed by proper programming or = configuration of the PCP/PANA server to make sure it doesn't = unnecessarily re-authenticate the clients.

So, I agree = with you that PANA, on a properly configured server, can be as "mobile = friendly" and lightweight as EAP-in-PCP.


My concerns = about starting from a clean slate are based, in part, on Steve Hartman's = "Implementation Analysis: strong preference for PCP-specific approach" = (ht= tp://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His = arguments were persuasive (to me) and the counter-arguments were not. =

[Rafa] Why my answers in ht= tp://www.ietf.org/mail-archive/web/pcp/current/msg02349.html are not = ok?


I understand that implementation should not dictate = protocol design but I think we should let implementation *inform* = protocol design. If I have to select between two ways to define a = protocol, and one of them is simpler to implement, then I will tend to = vote for the simpler option if all other criteria are equal. I see = EAP-in-PCP as the simpler option even if there is source code for = PANA.

I've also = reviewed the OpenPANA source code and I have some concerns that = illustrate this point:

* The PANA = state machine includes 13 states with 22 separate input events. That = state machine has to be integrated with the simpler PCP state machine. = My intuition, based on too many years of experience, is that integrating = the PANA and PCP state machines is tricky to implement, debug, and = verify. That complexity is, in part, because PANA already has a fairly = complex state machine. I don't believe EAP-in-PCP requires this much = complexity.

[Rafa] Ben, I have always assumed we all = have experience in the area. In particular, I have been working on PANA = since 2003 and I have done source coding myself, I have been leading an = open source PANA implementation and deployed PANA in several EU = projects,  without any inconvenience so far.

About the state = machine, I can tell you that part of it is completely optional. =

And about the integration between PANA and PCP, I disagree based = on the experience we got from http:/= /www.ietf.org/proceedings/86/slides/slides-86-pcp-17


* The = OpenPANA implementation is about 6900 SLOCs long as measured by an = sloccount version 2.26. This seems like a lot of code (aka complexity) = to tunnel EAP packets over PCP. And, that doesn't include the code that = must be added to PCP required to integrate PCP with PANA. I believe an = EAP-in-PCP implementation will be much simpler but, I admit, I don't = have an implementation to show you that proves that = point.

[Rafa] This number is completely wrong as I = already explained in ht= tp://www.ietf.org/mail-archive/web/pcp/current/msg02631.html (as you = may observe this is a repeating conversation). You may agree with me = that doing the sloccount  over the entire package does not help too = much. We need to be more specific.

In the message I already sent, = the discussion was about openpana-0.2.3. Right now, we have = openpana-0.2.4 and we have new values. The following values only show = the LoC dedicated to PANA, not to EAP ST, EAP-Method or RADIUS client = since those values will be common to any other solution using EAP and = RADIUS.

OpenPANA:

The PAA:

3130 LoC (PAA ST + PAA = main program + PANA messages + PAA session + PRF)

The = PaC

2720 (PaC ST + PaC main + PANA messages + PaC session + = PRF)

It is worth noting that those values includes 1846 LoCs = which are common functionality to PaC and PAA.

Moreover, as I = also explained in the e-mail we have a version for very constrained = devices (sensor nodes). In particular we have a PaC implementation for = Contiki OS named PANATIKI (http://sourceforge.net/p= rojects/panatiki) and the values are:

PANATIKI : 517 (PaC = state machine) + 141 (PaC main program)

But again, please take = into account this is just an open source implementation and not a = product. And, of course, running code is absolutely better than no = code.

Regarding your comment "And, that doesn't include the code = that must be added to PCP required to integrate PCP with PANA", please = see slide 12 in http:/= /www.ietf.org/proceedings/86/slides/slides-86-pcp-17  . =  Just a 100 lines that includes "PCP Key derivation and export. = Unix Sockets."  in the case of OpenPANA.



* The presence = of an open source version of PANA is a vote in its favor but that = depends on whether that code is easily portable to many environments. I = think the OpenPANA implementation makes assumptions about its runtime = environment that aren't very portable. It assumes a multi-threaded = environment with posix sockets and my runtime environment doesn't meet = those requirements.

[Rafa] For example, PANATIKI = does not assume multi-threaded environment with posix sockets (it is an = implementation for a sensor node after all). Btw, there are two open = source implementations OpenPANA/PANATIKI and CPANA.


To be fair, I = don't think I've said anything here that wasn't already covered by Steve = Hartman. But, I did review the code and I agree with his = conclusions.

[Rafa] As you can see, I already = counter-argumented that analysis. In any case, I will be in Berlin so = any doubt you have about OpenPana/PANATIKI or just implementating PANA, = let me know and I will be more than happy to meet and = discuss.

Best regards.


-Ben = McCann

-----Original = Message-----
From: Alper Yegin = [mailto:alper.yegin@yegin.org]
Sent: Thursday, July 18, 2013 4:34 = AM
To: Ben = McCann
Cc: Dave Thaler; pcp@ietf.org
Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL = on PCP
security)

Hello,

I'm afraid your = below issues are based on misconceptions introduced by the ht= tp://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf = slides.
We did address those = misconceptions in several rounds, but it seems like some still = linger.

PANA does not = force clients to always have a session, or always stay awake or = connected.

If a client = wants to get authenticated and generate a 5 minute key, and afterwards = sleep, detach, etc., it can very well do that using = PANA.
We can support that by = simply setting the lifetime of the PANA SA to that short fix value, or = letting the PANA SA timeout and expire.
So, you can run PANA and have a 5 min SA, then have no = PANA activity for 23:55hrs, and then come back and do another PANA = authentication and have another 5min SA. No = problems.

Therefore, = there are no issues with mobile, and no issues with server side = resources.

After all, PANA = is adopted by Zigbee Alliance. I don't think the deployment cases = considered here are any more constrained than = theirs...

EAP-in-PCP provides a clean slate that's unencumbered by = the design decisions and assumptions of an existing protocol (PANA). =


Was there any = other concern leading to your above = statement?

Alper









On Jul 17, = 2013, at 10:20 PM, Ben McCann wrote:

1) Could you *live with* EAP-in-PCP? If not, state reason = you would object.

=  YES

2) Could you *live with* PANA? = If not, state reason you would = object.

 Yes, but we really rather = not use PANA. See below...

3) If you said yes to both 1 and = 2, but have a strong preference between the two, which approach do you = prefer and why?

We strongly prefer EAP-in-PCP = for several reasons:

* PANA, as we understand it, is = not mobile-friendly. It requires the PCP client to *always* have an = authenticated session active and that is wasteful on mobile clients when = the authentication rekey interval is much shorter than the mapping = lifetime. Margaret Wasserman captured this in slides 13 and 14 of her = presentation ht= tp://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We = believe the *client* should decide when to authenticate (because it = needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption. =

We understand that a PCP server = may need to send a message to the client when no authenticated session = is active. If no authenticated session is active then we prefer the = server send an UN-authenticated "call home" message directing the client = to authenticate and then the server can send its messages over the = authenticated channel. We recognize an attacker can induce the client to = connect to the server by forging an unauthenticated "call home" message. = But, having done that, the client can ignore subsequent forged call home = messages because it will already have an authenticated session. Worse = case, an attacker can't make EAP-in-PCP consume any more client = resources than PANA does because PANA requires the client to always have = an authenticated session = available.

* PANA requires more server side = resources. The authentication protocol should efficiently support = 100,000's of clients on a large PCP server. Why should the server = continuously maintain authenticated sessions with *every* client? = Clients using 24 hour mapping lifetimes can be served by short = authentication key lifetime like, for example, 5 minutes. Let the client = connect, authenticate, program the mappings, and then let the = authenticated session expire. Rinse and repeat in 24 hours,. = Client-driven authentication via EAP-in-PCP requires less resources on = the server because the server can discard the authenticated session = state once the key lifetime = expires.

There was some discussion that = PANA is preferable to EAP-in-PCP because it supports "liveness testing". = We don't believe liveness testing is useful when the server resources = consumed, per client, are PCP mappings. Checking the liveness of 100,000 = clients is much more resource intensive on the server than just keeping = the client's mappings around until they expire naturally at the end of = their lifetime. In short, we believe EAP-in-PCP will scale better on the = server than PANA.

* We believe the decision to use = EAP-in-PCP vs. PANA is a choice between designing and implementing an = EAP-in-PCP transport that is tailored for PCP versus adapting an = existing protocol (PANA) to fit the needs of PCP.  We don't think = implementing an EAP-in-PCP transport is difficult so we prefer it over = PANA. EAP-in-PCP provides a clean slate that's unencumbered by the = design decisions and assumptions of an existing protocol (PANA). =

-Ben = McCann



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

_______________________________________________
pcp mailing = list
pcp@ietf.org
https://www.ietf.org/ma= ilman/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
-----------------------------= --------------------------



rafa@um.es
-----------------------------= --------------------------

= --Apple-Mail-1-1006033373-- From teemu.savolainen@nokia.com Mon Jul 22 00:59:48 2013 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 7E69321F9E7E for ; Mon, 22 Jul 2013 00:59:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2fKn+AVBvl6 for ; Mon, 22 Jul 2013 00:59:38 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A04CD21E8089 for ; Mon, 22 Jul 2013 00:58:44 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6M7wWkJ022593; Mon, 22 Jul 2013 10:58:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.49]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jul 2013 10:58:32 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.140]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.03.0136.001; Mon, 22 Jul 2013 07:58:25 +0000 From: To: , , Thread-Topic: [pcp] #64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-02 Thread-Index: AQHOgiCyf74KEVNAaE6U+gyML0YQ8plwXb8Q Date: Mon, 22 Jul 2013 07:58:25 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620480B759@008-AM1MPN1-053.mgdnok.nokia.com> References: <064.8793b93d389eea6b51bc55b5712fe096@tools.ietf.org> <079.ac76ba53ca62aed2ab1e0278a617d740@tools.ietf.org> In-Reply-To: <079.ac76ba53ca62aed2ab1e0278a617d740@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.206.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jul 2013 07:58:32.0261 (UTC) FILETIME=[4274D750:01CE86B1] X-Nokia-AV: Clean Cc: pcp@ietf.org Subject: Re: [pcp] #64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-02 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, 22 Jul 2013 07:59:48 -0000 I acknowledge the -03 to fix my concerns. Thank you for taking the feedback into account, Teemu -----Original Message----- From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of ext p= cp issue tracker Sent: 16. hein=E4kuuta 2013 15.34 To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org; mohamed.boucadair@orange.= com Cc: pcp@ietf.org Subject: Re: [pcp] #64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-0= 2 #64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-02 Changes (by mohamed.boucadair@orange.com): * status: new =3D> closed * resolution: =3D> fixed Comment: http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-03 fixes all the = comments raised by Teemu. In particular: * draft-ietf-behave-nat64-discovery-heuristic and learn-analysis I-D are = referenced * suffix can be configured * the option solves the problem defined in "5.1. Mapping of IPv4 Address = Ranges to IPv6 Prefixes" of draft-ietf-behave-nat64-discovery-heuristic --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-pcp- teemu.savolainen@nokia.com | nat64-prefix64@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nat64-prefix64 | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: pcp _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From Tina.Tsou.Zouting@huawei.com Tue Jul 23 14:11:43 2013 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 7D1AA11E8386 for ; Tue, 23 Jul 2013 14:11:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OM2YPkxHC10 for ; Tue, 23 Jul 2013 14:11:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7711E836F for ; Tue, 23 Jul 2013 14:11:25 -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 AVI87752; Tue, 23 Jul 2013 21:11:24 +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.7; Tue, 23 Jul 2013 22:11:10 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 22:11:21 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.217]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 14:11:16 -0700 From: Tina TSOU To: Dave Thaler Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: AQHOh+kr076e4buh5E6YRUgHIK1O9g== Date: Tue, 23 Jul 2013 21:11:16 +0000 Message-ID: <5D41E9D8-1474-416C-B13A-3C7E7E879FE3@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] CONSENSUS CALL on PCP security 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, 23 Jul 2013 21:11:43 -0000 Dear all, 2) Could you *live with* PANA? If not, state reason you would object. YES Thank you, Tina From dwing@cisco.com Tue Jul 23 18:41:08 2013 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 2B45E11E81AC for ; Tue, 23 Jul 2013 18:41:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSbmsyls5pBt for ; Tue, 23 Jul 2013 18:41:03 -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 244E411E81B5 for ; Tue, 23 Jul 2013 18:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1145; q=dns/txt; s=iport; t=1374630063; x=1375839663; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=E5Cj7Gp8X2LWGMXCfVm5bQN7VKx590+jao/vV6x2iMk=; b=W4H8d/xWvy1G+XPfdb1jUM9be4hDsSFAD+N8w/ZwJjAFWtp48zrvC8o7 mE6dtUnukfIcUhfo/2PvEUON0l7GptgDV8nGZDSmX61wH8z93uBZIs4dT 0tqwNsDe9eicC/FWZauHLD3+QQeC8ZXVloj0lmWx16ukHm4sqqkoty6l0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAAgw71GrRDoI/2dsb2JhbABbgwbDBhZ0gmWBfYgil26gOpMWbgOJKo41hiOLKoM0HA X-IronPort-AV: E=Sophos;i="4.89,731,1367971200"; d="scan'208";a="84485637" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 24 Jul 2013 01:40:55 +0000 Received: from [10.21.103.25] ([10.21.103.25]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6O1eskX021093 for ; Wed, 24 Jul 2013 01:40:54 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <09D9F37E-8339-412C-B703-4DBC9A96696A@cisco.com> Date: Tue, 23 Jul 2013 18:40:54 -0700 To: "pcp@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-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, 24 Jul 2013 01:41:08 -0000 I am trying to understand the difference between draft-ietf-pcp-proxy = and draft-cheshire-recursive-pcp. One of the significant differences = seems to be if the proxy should function differently from an endpoint. = draft-ietf-pcp-proxy has a proxy operating differently from an endpoint = with the sentence starting with "Nevertheless" 6. No NAT is Co-located with the PCP Proxy When no NAT is co-located with the PCP Proxy, the port numbers included in received PCP messages (from the PCP server or PCP client(s)) are not altered by the PCP Proxy. Nevertheless, the PCP client IP Address MUST be changed to the address of the PCP Proxy and a THIRD_PARTY Option inserted to carry the IP address of the source PCP client. The text is under-specified (as the PCP proxy can have have several = addresses, even if it is a firewall), but I don't know why the PCP proxy = needs to add the THIRD_PARTY option. It could just send the packet = as-is, with the original source IP address. The proxy will see the = response just as it will see the TCP SYNACK response to a TCP SYN. WG thoughts? -d From mohamed.boucadair@orange.com Tue Jul 23 23:09:03 2013 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 D4AFB11E81FE for ; Tue, 23 Jul 2013 23:09:03 -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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgwTpqaRVq6D for ; Tue, 23 Jul 2013 23:08:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 330FD11E81FA for ; Tue, 23 Jul 2013 23:08:51 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5ACE03B4F9B; Wed, 24 Jul 2013 08:08:47 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4036A27C053; Wed, 24 Jul 2013 08:08:47 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 24 Jul 2013 08:08:47 +0200 From: To: Dan Wing , "pcp@ietf.org" Date: Wed, 24 Jul 2013 08:08:45 +0200 Thread-Topic: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp Thread-Index: Ac6IDvApTJKB+6tISTaC6gOwOtKPwwAJDSDQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EE4BA569B@PUEXCB1B.nanterre.francetelecom.fr> References: <09D9F37E-8339-412C-B703-4DBC9A96696A@cisco.com> In-Reply-To: <09D9F37E-8339-412C-B703-4DBC9A96696A@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: 2013.7.1.45418 Subject: Re: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-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, 24 Jul 2013 06:09:04 -0000 Hi Dan,=20 The main reasons why we had that text are as follows: * The PCP Proxy won't need to inspect every incoming packet. The current ap= proach makes it easy to redirect PCP responses to the PCP proxy because PCP= responses will be explicitly sent to its external IP address.=20 * In some scenarios, the address family of the internal IP address is not t= he same as the one available in the external interface of the PCP Proxy. A = typical example is DS-Lite. As you know DS-Lite assumes plain IPv6 mode, in= ternal PCP requests are received over IPv4 while external requests are sent= over IPv6 without requiring in NAT. In such case, internal request cannot = just be relayed to the next PCP server. Cheers, Med =20 >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Da= n >Wing >Envoy=E9=A0: mercredi 24 juillet 2013 03:41 >=C0=A0: pcp@ietf.org >Objet=A0: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp > >I am trying to understand the difference between draft-ietf-pcp-proxy and >draft-cheshire-recursive-pcp. One of the significant differences seems t= o >be if the proxy should function differently from an endpoint. draft-ietf- >pcp-proxy has a proxy operating differently from an endpoint with the >sentence starting with "Nevertheless" > > 6. No NAT is Co-located with the PCP Proxy > > When no NAT is co-located with the PCP Proxy, the port numbers > included in received PCP messages (from the PCP server or PCP > client(s)) are not altered by the PCP Proxy. Nevertheless, the PCP > client IP Address MUST be changed to the address of the PCP Proxy and > a THIRD_PARTY Option inserted to carry the IP address of the source > PCP client. > >The text is under-specified (as the PCP proxy can have have several >addresses, even if it is a firewall), but I don't know why the PCP proxy >needs to add the THIRD_PARTY option. It could just send the packet as-is, >with the original source IP address. The proxy will see the response just >as it will see the TCP SYNACK response to a TCP SYN. > >WG thoughts? > >-d > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From wwwrun@rfc-editor.org Wed Jul 24 09:40:02 2013 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 5FD8211E8222; Wed, 24 Jul 2013 09:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VInLTXvv9sS; Wed, 24 Jul 2013 09:40:01 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9144A11E8118; Wed, 24 Jul 2013 09:39:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0AC7BB1E003; Wed, 24 Jul 2013 09:36:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130724163656.0AC7BB1E003@rfc-editor.org> Date: Wed, 24 Jul 2013 09:36:56 -0700 (PDT) Cc: drafts-update-ref@iana.org, pcp@ietf.org, rfc-editor@rfc-editor.org Subject: [pcp] RFC 6970 on Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF) 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, 24 Jul 2013 16:40:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6970 Title: Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF) Author: M. Boucadair, R. Penno, D. Wing Status: Standards Track Stream: IETF Date: July 2013 Mailbox: mohamed.boucadair@orange.com, repenno@cisco.com, dwing@cisco.com Pages: 23 Characters: 50900 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pcp-upnp-igd-interworking-10.txt URL: http://www.rfc-editor.org/rfc/rfc6970.txt This document specifies the behavior of the Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparent NAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From dwing@cisco.com Thu Jul 25 15:43:40 2013 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 6A86E21F8F61 for ; Thu, 25 Jul 2013 15:43:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0wszNdcujOD for ; Thu, 25 Jul 2013 15:43:36 -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 0C35021F848A for ; Thu, 25 Jul 2013 15:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2336; q=dns/txt; s=iport; t=1374792216; x=1376001816; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=qZhirZWMz9E8mi8RspNMtXnV0T/dq7NyVyDPD6vcW1k=; b=G2DaYEr2os04ojFO4GZ6oskMLIS0nLCHjb4iGwnD5CZlqafXM/RykB5Q jBg5Cf4o6mBioKVNRLgYUrmrbhqIDyOrN8yfj2B1wFct6itGpJqY2nmtB N0d2BOKZefldlYiQN8yZ2pXX9fwRwec1yoAfxcnPK/645qC0ljH8WqkkU Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJKp8VGrRDoJ/2dsb2JhbABagwY1v0kWdIJlgX0uE4dhDZhEoEGOPQyETW4DJwKJAY41gSmQJIM0HIEtCgg X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="87294091" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 25 Jul 2013 22:43:34 +0000 Received: from sjc-vpn7-549.cisco.com (sjc-vpn7-549.cisco.com [10.21.146.37]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6PMhXEs017229 for ; Thu, 25 Jul 2013 22:43:33 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0D5D4049-2847-46C8-BD0D-8C6CF6BB1AF0@cisco.com> Date: Thu, 25 Jul 2013 15:43:33 -0700 To: "pcp@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [pcp] differentiating traffic, draft-wing-pcp-flowdata 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, 25 Jul 2013 22:43:40 -0000 Many networks have insufficient access bandwidth and it is desirable to = handle flows differently over that access link based on the flow's needs = (high bandwidth, low loss, high delay) or if the flow is to a certain = device or certain user ((living room television, tablet, mom/dad/kid). = Hosts don't have a way to prioritize flows downstream (towards the host) = and have poor capability to prioritize flows upstream, especially among = the various hosts on the network. Various solutions to this problem = have been developed over the years (DSCP, RSVP, NSIS) but have = drawbacks. I hope the problem described above resonates with people on this list. = If so, read on. In draft-wing-pcp-flowdata we propose a solution: the host describes = the flow characteristics to the network and the network indicates its = (in)ability to accommodate the flow. That flow description can be used = by the default network, or propagated along the network. For example in = a home network the flow description can propagate from in-home CPE = router to the ISP's access router, and in an enterprise network the flow = description can propagate within the enterprise network and up to the = ISP's access router. When the flow characteristics are communicated to = both sides of a resource-constrained link, the routers on both end can = provide different packet forwarding treatment to the flow. The mechanism draft-wing-pcp-flowdata brings some advantages: * incrementally deployable. This can be implemented entirely within a = subscriber's network without participation of their ISP, providing some = value (but of course not as much value as being deployed by the ISP's = access router). Similarly, this can be implemented on the ISP's router = and the host could signal directly to that ISP's router without needing = support of the intermediate network. * adaptive bit rate applications can improve user experience by = avoiding attempts to exceed the network's upper bandwidth limit * traffic differentiation can be per-"event" (e.g., streaming TV of = the Olympics, VoIP call with an important customer), in addition to more = traditional per-user or per-device or per-application. Details are in http://tools.ietf.org/html/draft-wing-pcp-flowdata. Comments welcome. -d From dwing@cisco.com Thu Jul 25 15:56:31 2013 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 DD2DD21F8F07 for ; Thu, 25 Jul 2013 15:56:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb9zt-Tlb4LV for ; Thu, 25 Jul 2013 15:56:27 -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 76F3521F8426 for ; Thu, 25 Jul 2013 15:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4331; q=dns/txt; s=iport; t=1374792987; x=1376002587; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=L8Ny2i/5/g/7e1xs6O4a07BdB3JWzd81OcO43tgDDm0=; b=dZ+ESHUW6c3pQXLJCANbNQS7nnKAf+iwCBxGn/M8uv1Svsq+W9Q0y0ej fD9UyyD8l/wh37jg8zMXwjM68aomfcg5d5V/h9GldrEekup+U/GdFoWkN n5bqETl0KgZiI7v2ezu7oMjBWsFNsYbtX6CxRvdqz4Bf3Gi7HWwKIGlRf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFANas8VGrRDoG/2dsb2JhbABagwY1vjSBFRZ0giQBAQEDAQEBAWsLBQsLPwcnHxEZiAoFDbh5BI9KMweDEm4DiSqONZFNgzQc X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="87230123" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 25 Jul 2013 22:56:18 +0000 Received: from sjc-vpn7-549.cisco.com (sjc-vpn7-549.cisco.com [10.21.146.37]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6PMuGjG007687; Thu, 25 Jul 2013 22:56:17 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE4BA569B@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 25 Jul 2013 15:56:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10106ED6-5FF5-4C03-8F2E-8AFCE2D0812A@cisco.com> References: <09D9F37E-8339-412C-B703-4DBC9A96696A@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE4BA569B@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1508) Cc: "pcp@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-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, 25 Jul 2013 22:56:32 -0000 On Jul 23, 2013, at 11:08 PM, mohamed.boucadair@orange.com wrote: > Hi Dan,=20 >=20 > The main reasons why we had that text are as follows: >=20 > * The PCP Proxy won't need to inspect every incoming packet. The = current approach makes it easy to redirect PCP responses to the PCP = proxy because PCP responses will be explicitly sent to its external IP = address.=20 I agree it is different to send the packet to the PCP proxy's public = address than what I described. However, ALG code in NATs and firewalls = today are pretty capable of seeing the response traffic. Thus what I am = suggesting is not new. > * In some scenarios, the address family of the internal IP address is = not the same as the one available in the external interface of the PCP = Proxy. A typical example is DS-Lite. As you know DS-Lite assumes plain = IPv6 mode, internal PCP requests are received over IPv4 while external = requests are sent over IPv6 without requiring in NAT. In such case, = internal request cannot just be relayed to the next PCP server. Why can't IPv4 PCP requests be sent over IPv4 (over the DS-Lite IPv6 = tunnel), just like a IPv4 TCP SYNs? I recall there was objection to = that and a preference for sending the PCP requests over IPv6, but I am = now worried the security implications of such a decision have not been = fully considered. What of scenarios where IPv6/IPv4 tunneling is not involved -- why does = draft-ietf-pcp-proxy require the proxy insert THIRD_PARTY for those, = too? Just to make the proxy implementation less like an ALG (your first = bullet)? What are the security implications of a deployment where some = subscribers have a PCP proxy and it adds THIRD_PARTY (legitimately) = versus other subscribers who don't have a PCP proxy and someone on that = subscriber's network (e.g., coffee shop, hotel) is abusing THIRD_PARTY = (maliciously). How would the service provider's PCP server = differentiate between those two types of subscribers and know to allow = one THIRD_PARTY but deny the other THIRD_PARTY? The problem I see with = the PCP proxy inserting THIRD_PARTY is the upstream PCP server is now = doing something different than it was without a PCP proxy on the path -- = the upstream PCP server has to understand and allow THIRD_PARTY. = Imagine a situation, all too common, where there are two NATs in a home = ("look, a fancy blue LED, 802.1ac, and only $40. My Internet will go = really fast") and each is doing PCP proxying -- now the second one has = to do PCP proxying, which it will be surprised to see from what it = thought was an end host. -d >=20 > Cheers, > Med =20 >=20 >> -----Message d'origine----- >> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de = Dan >> Wing >> Envoy=E9 : mercredi 24 juillet 2013 03:41 >> =C0 : pcp@ietf.org >> Objet : [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp >>=20 >> I am trying to understand the difference between draft-ietf-pcp-proxy = and >> draft-cheshire-recursive-pcp. One of the significant differences = seems to >> be if the proxy should function differently from an endpoint. = draft-ietf- >> pcp-proxy has a proxy operating differently from an endpoint with the >> sentence starting with "Nevertheless" >>=20 >> 6. No NAT is Co-located with the PCP Proxy >>=20 >> When no NAT is co-located with the PCP Proxy, the port numbers >> included in received PCP messages (from the PCP server or PCP >> client(s)) are not altered by the PCP Proxy. Nevertheless, the PCP >> client IP Address MUST be changed to the address of the PCP Proxy = and >> a THIRD_PARTY Option inserted to carry the IP address of the source >> PCP client. >>=20 >> The text is under-specified (as the PCP proxy can have have several >> addresses, even if it is a firewall), but I don't know why the PCP = proxy >> needs to add the THIRD_PARTY option. It could just send the packet = as-is, >> with the original source IP address. The proxy will see the response = just >> as it will see the TCP SYNACK response to a TCP SYN. >>=20 >> WG thoughts? >>=20 >> -d >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Fri Jul 26 01:05:49 2013 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 9852D21F8947 for ; Fri, 26 Jul 2013 01:05:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aktpWCGyK3gw for ; Fri, 26 Jul 2013 01:05:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEDE21F8EEA for ; Fri, 26 Jul 2013 01:05:43 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 16E6F3B4466; Fri, 26 Jul 2013 10:05:42 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id ECE7A35C058; Fri, 26 Jul 2013 10:05:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 26 Jul 2013 10:05:42 +0200 From: To: Dan Wing Date: Fri, 26 Jul 2013 10:05:39 +0200 Thread-Topic: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp Thread-Index: Ac6JijP4u9dpIZ43SYeeqWZlii00WgAQIcyQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E83194@PUEXCB1B.nanterre.francetelecom.fr> References: <09D9F37E-8339-412C-B703-4DBC9A96696A@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE4BA569B@PUEXCB1B.nanterre.francetelecom.fr> <10106ED6-5FF5-4C03-8F2E-8AFCE2D0812A@cisco.com> In-Reply-To: <10106ED6-5FF5-4C03-8F2E-8AFCE2D0812A@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: 2013.7.26.63617 Cc: "pcp@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-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, 26 Jul 2013 08:05:49 -0000 Hi Dan, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Dan Wing [mailto:dwing@cisco.com] >Envoy=E9=A0: vendredi 26 juillet 2013 00:56 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp > > >On Jul 23, 2013, at 11:08 PM, mohamed.boucadair@orange.com wrote: > >> Hi Dan, >> >> The main reasons why we had that text are as follows: >> >> * The PCP Proxy won't need to inspect every incoming packet. The current >approach makes it easy to redirect PCP responses to the PCP proxy because >PCP responses will be explicitly sent to its external IP address. > >I agree it is different to send the packet to the PCP proxy's public >address than what I described. However, ALG code in NATs and firewalls >today are pretty capable of seeing the response traffic. Thus what I am >suggesting is not new. [Med] I'm not saying this is not possible; the point is that it is much mor= e simple to direct explicitly PCP traffic to the proxy rather than inspecti= ng all incoming traffic. Remember there is no NAT in the case we are discus= sing here. =20 > > >> * In some scenarios, the address family of the internal IP address is no= t >the same as the one available in the external interface of the PCP Proxy. = A >typical example is DS-Lite. As you know DS-Lite assumes plain IPv6 mode, >internal PCP requests are received over IPv4 while external requests are >sent over IPv6 without requiring in NAT. In such case, internal request >cannot just be relayed to the next PCP server. > >Why can't IPv4 PCP requests be sent over IPv4 (over the DS-Lite IPv6 >tunnel), just like a IPv4 TCP SYNs?=20 [Med] The plain mode is what is implemented in most platforms I'm aware of,= and it is the mode adopted by the WG. I recall there was objection to that >and a preference for sending the PCP requests over IPv6, but I am now >worried the security implications of such a decision have not been fully >considered. [Med] FWIW, there is a decent security analysis available at: http://tools.= ietf.org/html/draft-ietf-pcp-dslite-00#section-3=20 > >What of scenarios where IPv6/IPv4 tunneling is not involved -- why does >draft-ietf-pcp-proxy require the proxy insert THIRD_PARTY for those, too? >Just to make the proxy implementation less like an ALG (your first bullet)= ? [Med] Yes. > > >What are the security implications of a deployment where some subscribers >have a PCP proxy and it adds THIRD_PARTY (legitimately) versus other >subscribers who don't have a PCP proxy and someone on that subscriber's >network (e.g., coffee shop, hotel) is abusing THIRD_PARTY (maliciously). [Med] The same issue can be raised without having the THIRD_PARTY because t= he malicious user can spoof the source IP address. >How would the service provider's PCP server differentiate between those tw= o >types of subscribers and know to allow one THIRD_PARTY but deny the other >THIRD_PARTY? [Med] The use of THIRD_PARTY assumes the network in which it is used is tru= sted. This is a generic concern discussed in rfc6887. The problem I see with the PCP proxy inserting THIRD_PARTY is >the upstream PCP server is now doing something different than it was >without a PCP proxy on the path -- the upstream PCP server has to >understand and allow THIRD_PARTY. Imagine a situation, all too common, >where there are two NATs in a home ("look, a fancy blue LED, 802.1ac, and >only $40. My Internet will go really fast") and each is doing PCP proxyin= g >-- now the second one has to do PCP proxying, which it will be surprised t= o >see from what it thought was an end host. [Med] Your scenario involves NAT... which is not the case we are discussing= here. For this particular case, there is no need to insert a THIRD_PARTY b= y the PCP Proxy because the internal IP address set by the proxy is also th= e address used by the proxy to relay the request. > >-d > > > >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Dan >>> Wing >>> Envoy=E9 : mercredi 24 juillet 2013 03:41 >>> =C0 : pcp@ietf.org >>> Objet : [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp >>> >>> I am trying to understand the difference between draft-ietf-pcp-proxy >and >>> draft-cheshire-recursive-pcp. One of the significant differences seem= s >to >>> be if the proxy should function differently from an endpoint. draft- >ietf- >>> pcp-proxy has a proxy operating differently from an endpoint with the >>> sentence starting with "Nevertheless" >>> >>> 6. No NAT is Co-located with the PCP Proxy >>> >>> When no NAT is co-located with the PCP Proxy, the port numbers >>> included in received PCP messages (from the PCP server or PCP >>> client(s)) are not altered by the PCP Proxy. Nevertheless, the PCP >>> client IP Address MUST be changed to the address of the PCP Proxy and >>> a THIRD_PARTY Option inserted to carry the IP address of the source >>> PCP client. >>> >>> The text is under-specified (as the PCP proxy can have have several >>> addresses, even if it is a firewall), but I don't know why the PCP prox= y >>> needs to add the THIRD_PARTY option. It could just send the packet as- >is, >>> with the original source IP address. The proxy will see the response >just >>> as it will see the TCP SYNACK response to a TCP SYN. >>> >>> WG thoughts? >>> >>> -d >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Fri Jul 26 01:20:46 2013 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 A859121F8F2E for ; Fri, 26 Jul 2013 01:20:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVglasqfNF83 for ; Fri, 26 Jul 2013 01:20:45 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7798121F84CD for ; Fri, 26 Jul 2013 01:20:40 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E4810403DC for ; Fri, 26 Jul 2013 04:20:38 -0400 (EDT) Message-ID: <51F23156.1040104@viagenie.ca> Date: Fri, 26 Jul 2013 10:20:38 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: pcp@ietf.org References: <09D9F37E-8339-412C-B703-4DBC9A96696A@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE4BA569B@PUEXCB1B.nanterre.francetelecom.fr> <10106ED6-5FF5-4C03-8F2E-8AFCE2D0812A@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E83194@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE6E83194@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [pcp] DS-Lite "plain mode" (Was: Re: draft-ietf-pcp-proxy and draft-cheshire-recursive-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, 26 Jul 2013 08:20:46 -0000 Le 2013-07-26 10:05, mohamed.boucadair@orange.com a écrit : >> Why can't IPv4 PCP requests be sent over IPv4 (over the DS-Lite IPv6 >> tunnel), just like a IPv4 TCP SYNs? > > [Med] The plain mode is what is implemented in most platforms I'm aware of, and it is the mode adopted by the WG. Why did the WG adopt this method in the first place? Why did those platforms do it that way? There must be a reason... 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 Fri Jul 26 01:27:57 2013 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 329A021F84D9 for ; Fri, 26 Jul 2013 01:27:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwN7zWmX4nAb for ; Fri, 26 Jul 2013 01:27:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8C76121F8493 for ; Fri, 26 Jul 2013 01:27:50 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 3A2D22DC699; Fri, 26 Jul 2013 10:27:47 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1AF9A27C06A; Fri, 26 Jul 2013 10:27:47 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 26 Jul 2013 10:27:46 +0200 From: To: Dan Wing , "pcp@ietf.org" Date: Fri, 26 Jul 2013 10:27:45 +0200 Thread-Topic: [pcp] differentiating traffic, draft-wing-pcp-flowdata Thread-Index: Ac6JiGp7SkaRMWwqSXSpuJXtGJeKcgAT3EnA Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E831B6@PUEXCB1B.nanterre.francetelecom.fr> References: <0D5D4049-2847-46C8-BD0D-8C6CF6BB1AF0@cisco.com> In-Reply-To: <0D5D4049-2847-46C8-BD0D-8C6CF6BB1AF0@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: 2013.7.1.45418 Subject: Re: [pcp] differentiating traffic, draft-wing-pcp-flowdata 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, 26 Jul 2013 08:27:57 -0000 Hi Dan, This is indeed an interesting piece of work...which has also its drawbacks;= -) See the comment I made about the generic framework here: http://www.ietf= .org/mail-archive/web/int-area/current/msg03627.html. Targeting a perfect solution which does not suffer from limitations is not = viable IMHO. This is why I'm seeing this work as a useful tool to be added = to the existing toolkit. This work opens a new perspective which is worth t= o be considered by the WG. In addition to the flowdata work, I'm also sugge= sting to consider other work items such as: * Use PCP to enforce DSCP remarking policies (http://tools.ietf.org/html/dr= aft-boucadair-pcp-extensions-03#section-3). This is useful when the PCP Cli= ent is operated by the provider. This is an intra-domain case. * Use PCP to discover the DSCP marking to be used for outbound packets: thi= s option can be used with or without FLOWDATA option. The typical use case = is where the PCP client is embedded in a CPE (not the host) and various mar= king policies are used at the access network. This is an intra-domain case. =20 Cheers, Med =20 >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Da= n >Wing >Envoy=E9=A0: vendredi 26 juillet 2013 00:44 >=C0=A0: pcp@ietf.org >Objet=A0: [pcp] differentiating traffic, draft-wing-pcp-flowdata > >Many networks have insufficient access bandwidth and it is desirable to >handle flows differently over that access link based on the flow's needs >(high bandwidth, low loss, high delay) or if the flow is to a certain >device or certain user ((living room television, tablet, mom/dad/kid). >Hosts don't have a way to prioritize flows downstream (towards the host) >and have poor capability to prioritize flows upstream, especially among th= e >various hosts on the network. Various solutions to this problem have been >developed over the years (DSCP, RSVP, NSIS) but have drawbacks. > >I hope the problem described above resonates with people on this list. If >so, read on. > > >In draft-wing-pcp-flowdata we propose a solution: the host describes the >flow characteristics to the network and the network indicates its >(in)ability to accommodate the flow. That flow description can be used by >the default network, or propagated along the network. For example in a >home network the flow description can propagate from in-home CPE router to >the ISP's access router, and in an enterprise network the flow description >can propagate within the enterprise network and up to the ISP's access >router. When the flow characteristics are communicated to both sides of a >resource-constrained link, the routers on both end can provide different >packet forwarding treatment to the flow. > >The mechanism draft-wing-pcp-flowdata brings some advantages: > > * incrementally deployable. This can be implemented entirely within a >subscriber's network without participation of their ISP, providing some >value (but of course not as much value as being deployed by the ISP's >access router). Similarly, this can be implemented on the ISP's router an= d >the host could signal directly to that ISP's router without needing suppor= t >of the intermediate network. > * adaptive bit rate applications can improve user experience by avoiding >attempts to exceed the network's upper bandwidth limit > * traffic differentiation can be per-"event" (e.g., streaming TV of the >Olympics, VoIP call with an important customer), in addition to more >traditional per-user or per-device or per-application. > >Details are in http://tools.ietf.org/html/draft-wing-pcp-flowdata. > >Comments welcome. >-d > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Fri Jul 26 02:28:40 2013 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 A882621F8C72 for ; Fri, 26 Jul 2013 02:28:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zB4urn+L+X6 for ; Fri, 26 Jul 2013 02:28:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8298621F8A50 for ; Fri, 26 Jul 2013 02:28:36 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id BD21422D6A7; Fri, 26 Jul 2013 11:28:34 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 9FAD04C024; Fri, 26 Jul 2013 11:28:34 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 26 Jul 2013 11:28:34 +0200 From: To: Simon Perreault , "pcp@ietf.org" Date: Fri, 26 Jul 2013 11:28:32 +0200 Thread-Topic: [pcp] DS-Lite "plain mode" (Was: Re: draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp) Thread-Index: Ac6J2Qrutdy36aI2TviddCNSCfQLUQAAQKJg Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E83222@PUEXCB1B.nanterre.francetelecom.fr> References: <09D9F37E-8339-412C-B703-4DBC9A96696A@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE4BA569B@PUEXCB1B.nanterre.francetelecom.fr> <10106ED6-5FF5-4C03-8F2E-8AFCE2D0812A@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E83194@PUEXCB1B.nanterre.francetelecom.fr> <51F23156.1040104@viagenie.ca> In-Reply-To: <51F23156.1040104@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: 2013.6.28.101520 Subject: Re: [pcp] DS-Lite "plain mode" (Was: Re: draft-ietf-pcp-proxy and draft-cheshire-recursive-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, 26 Jul 2013 09:28:40 -0000 Hi Simon, You can find some justification in the DS-Lite draft (see the appendix). I recall there were discussions in the list and some interim meeting but I = failed where the decision was formally made. BTW, it is hard to find pcp me= eting minutes :-( Cheers, Med =20 >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Si= mon >Perreault >Envoy=E9=A0: vendredi 26 juillet 2013 10:21 >=C0=A0: pcp@ietf.org >Objet=A0: [pcp] DS-Lite "plain mode" (Was: Re: draft-ietf-pcp-proxy and >draft-cheshire-recursive-pcp) > >Le 2013-07-26 10:05, mohamed.boucadair@orange.com a =E9crit : >>> Why can't IPv4 PCP requests be sent over IPv4 (over the DS-Lite IPv6 >>> tunnel), just like a IPv4 TCP SYNs? >> >> [Med] The plain mode is what is implemented in most platforms I'm aware >of, and it is the mode adopted by the WG. > >Why did the WG adopt this method in the first place? Why did those >platforms do it that way? There must be a reason... > >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 dwing@cisco.com Fri Jul 26 10:22:59 2013 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 D5D3B21F9AED for ; Fri, 26 Jul 2013 10:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7hWBhEvNzAd for ; Fri, 26 Jul 2013 10:22:41 -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 BD62C21F8C3E for ; Fri, 26 Jul 2013 10:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8073; q=dns/txt; s=iport; t=1374859358; x=1376068958; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aStFdJKlm2tey25UsiwYZo/0fUU/3wx89qdHOrHd6QE=; b=DVhuFreK2+8zgOhHGcqUJDyVNPGVgLrkAROTlbU12E6D7kF3ApYVB0T0 HLfzvK8p3G25eIehIJ/szZZnSO5K//1mbZx3jYeZT9efUEXUG4rvQgYKP fnD1Bt3z6yafxo7Ij2RCtmUpaatr/nheZKCdzkanvqND1pABOnpeVESh6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAASw8lGrRDoI/2dsb2JhbABbgwY1vi6BGRZ0giQBAQEDAQEBAWsLBQsLGCcHJx8RGYgKBQ24TI9KMweDFm8DiSqKXoNXgSmQI4M0HIEsBw X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="87325124" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 26 Jul 2013 17:22:38 +0000 Received: from sjc-vpn7-2043.cisco.com (sjc-vpn7-2043.cisco.com [10.21.151.251]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6QHMaVn014147; Fri, 26 Jul 2013 17:22:37 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE6E83194@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 26 Jul 2013 10:22:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <09D9F37E-8339-412C-B703-4DBC9A96696A@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE4BA569B@PUEXCB1B.nanterre.francetelecom.fr> <10106ED6-5FF5-4C03-8F2E-8AFCE2D0812A@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E83194@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1508) Cc: "pcp@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-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, 26 Jul 2013 17:22:59 -0000 On Jul 26, 2013, at 1:05 AM, mohamed.boucadair@orange.com wrote: > Hi Dan, >=20 > Please see inline. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Dan Wing [mailto:dwing@cisco.com] >> Envoy=E9 : vendredi 26 juillet 2013 00:56 >> =C0 : BOUCADAIR Mohamed OLNC/OLN >> Cc : pcp@ietf.org >> Objet : Re: [pcp] draft-ietf-pcp-proxy and = draft-cheshire-recursive-pcp >>=20 >>=20 >> On Jul 23, 2013, at 11:08 PM, mohamed.boucadair@orange.com wrote: >>=20 >>> Hi Dan, >>>=20 >>> The main reasons why we had that text are as follows: >>>=20 >>> * The PCP Proxy won't need to inspect every incoming packet. The = current >> approach makes it easy to redirect PCP responses to the PCP proxy = because >> PCP responses will be explicitly sent to its external IP address. >>=20 >> I agree it is different to send the packet to the PCP proxy's public >> address than what I described. However, ALG code in NATs and = firewalls >> today are pretty capable of seeing the response traffic. Thus what I = am >> suggesting is not new. >=20 > [Med] I'm not saying this is not possible; the point is that it is = much more simple to direct explicitly PCP traffic to the proxy rather = than inspecting all incoming traffic. Remember there is no NAT in the = case we are discussing here. But there likely is a firewall, which has to process incoming TCP SYNs = (in order to adjust its timers). > =20 >=20 >>=20 >>=20 >>> * In some scenarios, the address family of the internal IP address = is not >> the same as the one available in the external interface of the PCP = Proxy. A >> typical example is DS-Lite. As you know DS-Lite assumes plain IPv6 = mode, >> internal PCP requests are received over IPv4 while external requests = are >> sent over IPv6 without requiring in NAT. In such case, internal = request >> cannot just be relayed to the next PCP server. >>=20 >> Why can't IPv4 PCP requests be sent over IPv4 (over the DS-Lite IPv6 >> tunnel), just like a IPv4 TCP SYNs?=20 >=20 > [Med] The plain mode is what is implemented in most platforms I'm = aware of, and it is the mode adopted by the WG. > I recall there was objection to that >> and a preference for sending the PCP requests over IPv6, but I am now >> worried the security implications of such a decision have not been = fully >> considered. >=20 > [Med] FWIW, there is a decent security analysis available at: = http://tools.ietf.org/html/draft-ietf-pcp-dslite-00#section-3=20 Yes, that reads very nice for DS-Lite. I read it before my earlier = message. My concern is not DS-Lite, but draft-ietf-pcp-proxy which applies to all = proxying scenarios including non-DS-Lite proxying. >=20 >>=20 >> What of scenarios where IPv6/IPv4 tunneling is not involved -- why = does >> draft-ietf-pcp-proxy require the proxy insert THIRD_PARTY for those, = too? >> Just to make the proxy implementation less like an ALG (your first = bullet)? >=20 > [Med] Yes. >=20 >>=20 >>=20 >> What are the security implications of a deployment where some = subscribers >> have a PCP proxy and it adds THIRD_PARTY (legitimately) versus other >> subscribers who don't have a PCP proxy and someone on that = subscriber's >> network (e.g., coffee shop, hotel) is abusing THIRD_PARTY = (maliciously). >=20 > [Med] The same issue can be raised without having the THIRD_PARTY = because the malicious user can spoof the source IP address. No, it's not the same issue. If a malicious user can spoof a source address that user can attack a = multitude of protocols, and create mappings in a firewall or a NAT (by = sending a TCP SYN or UDP packet towards the Internet). If THIRD_PARTY is not blocked, using techniques similar to the = techniques described in = http://tools.ietf.org/html/draft-ietf-pcp-dslite-00#section-4 -- which = requires the CPE to block such PCP messages -- and THIRD_PARTY is = supported by the upstream ISP, then THIRD_PARTY introduces new risks = because THIRD_PARTY would not require the attacker to spoof their source = IP address. >=20 >> How would the service provider's PCP server differentiate between = those two >> types of subscribers and know to allow one THIRD_PARTY but deny the = other >> THIRD_PARTY? >=20 > [Med] The use of THIRD_PARTY assumes the network in which it is used = is trusted. This is a generic concern discussed in rfc6887. I don't understand what is meant by 'network trust' in your sentence. = You mean, that no device will send a bogus PCP message, accidentally = (misconfigured) or maliciously? >=20 > The problem I see with the PCP proxy inserting THIRD_PARTY is >> the upstream PCP server is now doing something different than it was >> without a PCP proxy on the path -- the upstream PCP server has to >> understand and allow THIRD_PARTY. Imagine a situation, all too = common, >> where there are two NATs in a home ("look, a fancy blue LED, 802.1ac, = and >> only $40. My Internet will go really fast") and each is doing PCP = proxying >> -- now the second one has to do PCP proxying, which it will be = surprised to >> see from what it thought was an end host. >=20 > [Med] Your scenario involves NAT... which is not the case we are = discussing here. For this particular case, there is no need to insert a = THIRD_PARTY by the PCP Proxy because the internal IP address set by the = proxy is also the address used by the proxy to relay the request. Sorry. Allow me to restate: "Imagine a situation, all too common, where there are two=20 non-NAT CPE=20 devices in a home ("look, a fancy blue LED, 802.1ac, and only $40. My Internet will go really fast") and each is doing PCP = proxying -- now the second one has to do PCP proxying, which it will be surprised = to see from what it thought was an end host." Those non-NAT CPE devices could be 100% IPv6-only Homenet devices, doing = IPv6 filtering as suggested in Simple Security (RFC6092) and running PCP = and PCP proxy as the way to poke pinholes through their firewalls (as = suggested in http://tools.ietf.org/html/rfc6092#section-3.4 where it = references ALD, UPnP IGD, MIDCOM, and NSIS). -d >=20 >=20 >>=20 >> -d >>=20 >>=20 >>=20 >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part = de >> Dan >>>> Wing >>>> Envoy=E9 : mercredi 24 juillet 2013 03:41 >>>> =C0 : pcp@ietf.org >>>> Objet : [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp >>>>=20 >>>> I am trying to understand the difference between = draft-ietf-pcp-proxy >> and >>>> draft-cheshire-recursive-pcp. One of the significant differences = seems >> to >>>> be if the proxy should function differently from an endpoint. = draft- >> ietf- >>>> pcp-proxy has a proxy operating differently from an endpoint with = the >>>> sentence starting with "Nevertheless" >>>>=20 >>>> 6. No NAT is Co-located with the PCP Proxy >>>>=20 >>>> When no NAT is co-located with the PCP Proxy, the port numbers >>>> included in received PCP messages (from the PCP server or PCP >>>> client(s)) are not altered by the PCP Proxy. Nevertheless, the PCP >>>> client IP Address MUST be changed to the address of the PCP Proxy = and >>>> a THIRD_PARTY Option inserted to carry the IP address of the source >>>> PCP client. >>>>=20 >>>> The text is under-specified (as the PCP proxy can have have several >>>> addresses, even if it is a firewall), but I don't know why the PCP = proxy >>>> needs to add the THIRD_PARTY option. It could just send the packet = as- >> is, >>>> with the original source IP address. The proxy will see the = response >> just >>>> as it will see the TCP SYNACK response to a TCP SYN. >>>>=20 >>>> WG thoughts? >>>>=20 >>>> -d >>>>=20 >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >=20 From rmartija@appcomsci.com Fri Jul 26 10:43:58 2013 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 3401711E80FB for ; Fri, 26 Jul 2013 10:43:58 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUEY+1-wtoeR for ; Fri, 26 Jul 2013 10:43:52 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id C846E11E80F6 for ; Fri, 26 Jul 2013 10:43:51 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r6QHhoU4022782; Fri, 26 Jul 2013 13:43:50 -0400 (EDT) Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r6QHhoTZ018073; Fri, 26 Jul 2013 13:43:50 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Fri, 26 Jul 2013 13:43:50 -0400 From: "Martija, Ricardo V" To: "dthaler@microsoft.com" , "pcp@ietf.org" Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: AQHOh7LBXPrq7BX7xECsch6mq+y1Gpl3Pa99 Date: Fri, 26 Jul 2013 17:43:49 +0000 Message-ID: <5A89907367C6E94EAEE4509F799DBAFF0D02DD82@rrc-ats-exmb2.ats.atsinnovate.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5A89907367C6E94EAEE4509F799DBAFF0D02DD82rrcatsexmb2atsa_" MIME-Version: 1.0 Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 26 Jul 2013 17:43:58 -0000 --_000_5A89907367C6E94EAEE4509F799DBAFF0D02DD82rrcatsexmb2atsa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. YES 2) Could you *live with* PANA? If not, state reason you would object. YES 3) If you said yes to both 1 and 2, but have a strong preference between the two, which approach do you prefer and why? PANA. PCP can "piggyback" on PANA for the key management function and eliminate the need for using EAP directly over PCP. At IETF86, Y. Ohba demonstrated that: a) the PANA-based PCP authentication solution and its implementation ca= n meet ALL the basic PCP authentication requirements b) the PANA-based PCP authentication solution works c) support for PCP authentication requires minimal changes to existing open-source PANA implementation Rick --_000_5A89907367C6E94EAEE4509F799DBAFF0D02DD82rrcatsexmb2atsa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

1) Could you *live with* EAP-in-PCP? If not, state reason you would obje= ct.

    YES

2) Could you *live with* PANA? If not, state reason you would object.

    YES

3) If you said yes to both 1 and 2, but have a strong preference between the two, which approach do you prefer and why?

    PANA. PCP can "piggyback" on PANA for the key = management function and

    eliminate the need for using EAP directly over PCP. A= t IETF86, Y. Ohba

    demonstrated that:

 

    a) the PANA-based PCP authentication solution and its= implementation can

        meet ALL the basic PCP authen= tication requirements

 

    b) the PANA-based PCP authentication solution works

 

    c) support for PCP authentication requires minimal ch= anges to existing

        open-source PANA implementati= on

 

Rick


 

--_000_5A89907367C6E94EAEE4509F799DBAFF0D02DD82rrcatsexmb2atsa_-- From dwing@cisco.com Fri Jul 26 13:23:22 2013 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 3029011E8150 for ; Fri, 26 Jul 2013 13:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.572 X-Spam-Level: X-Spam-Status: No, score=-110.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEWAxkCGXgc2 for ; Fri, 26 Jul 2013 13:23:17 -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 B4EAA11E80FB for ; Fri, 26 Jul 2013 13:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5162; q=dns/txt; s=iport; t=1374870197; x=1376079797; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rFwYgLVftRWoqxigvfPhz06Imst38mFgpZFOXgBeTww=; b=DjOM5fZVqOuCVHy1LctIZ7oZ21C2jPkBoQT2afz++WbrIL6UggzNoZ1C JNfbEbbSLuwq3pFaoIi1+AvOodJxTt6b4Cj0Pj1BIQqD0j4dtw9IZefQ9 5JHY9tWsKEZnQEczIKVnS64E5ld6x6Fr7opEOvHwhdXVTSoxYZiiK+VMf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAD/a8lGrRDoI/2dsb2JhbABbgwY1vi6BGRZ0giQBAQEDAQEBAWsLBQsLPwcnHxEZCRITh1wFDbhyjj0MBXwzB4MWbwMnAokBjjWBKZAjgzQcgS0IAggN X-IronPort-AV: E=Sophos;i="4.89,753,1367971200"; d="scan'208";a="87341824" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 26 Jul 2013 20:23:17 +0000 Received: from sjc-vpn7-2043.cisco.com (sjc-vpn7-2043.cisco.com [10.21.151.251]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6QKNFvN004940; Fri, 26 Jul 2013 20:23:16 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE6E831B6@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 26 Jul 2013 13:23:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2653EA58-AA3B-4F65-B4BE-785342C7A3F1@cisco.com> References: <0D5D4049-2847-46C8-BD0D-8C6CF6BB1AF0@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E831B6@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1508) Cc: "pcp@ietf.org" Subject: Re: [pcp] differentiating traffic, draft-wing-pcp-flowdata 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, 26 Jul 2013 20:23:22 -0000 On Jul 26, 2013, at 1:27 AM, mohamed.boucadair@orange.com wrote: > Hi Dan, >=20 > This is indeed an interesting piece of work...which has also its = drawbacks;-) See the comment I made about the generic framework here: = http://www.ietf.org/mail-archive/web/int-area/current/msg03627.html. I am not involved with the generic framework. But reading your = objections in that post, the primary objection seemed to be application = developers won't signal their flow characteristics. To do such = signaling, such signaling would need to provide value to the application = developer or to the end user experience. That is, to do such signaling, = the signaling has to solve a real problem. I believe multiple flows contending for access bandwidth is a real = problem. If it is not a problem (that is, sufficient bandwidth is always = available), then I agree there is no value or purpose in differentiating = flows over that network. However, every year that I hear someone = proclaim "we have enough resources", that has only been true for a year = or two -- no matter if the resources are CPU cores, memory, bandwidth, = network latency, or disk space. > Targeting a perfect solution which does not suffer from limitations is = not viable IMHO. This is why I'm seeing this work as a useful tool to be = added to the existing toolkit. This work opens a new perspective which = is worth to be considered by the WG. Thanks for your positive feedback. > In addition to the flowdata work, I'm also suggesting to consider = other work items such as: >=20 > * Use PCP to enforce DSCP remarking policies = (http://tools.ietf.org/html/draft-boucadair-pcp-extensions-03#section-3). = This is useful when the PCP Client is operated by the provider. This is = an intra-domain case. > * Use PCP to discover the DSCP marking to be used for outbound = packets: this option can be used with or without FLOWDATA option. The = typical use case is where the PCP client is embedded in a CPE (not the = host) and various marking policies are used at the access network. This = is an intra-domain case. Signaling DSCP is not something described in draft-wing-pcp-flowdata -- = on purpose. -d >=20 > Cheers, > Med =20 >=20 >> -----Message d'origine----- >> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de = Dan >> Wing >> Envoy=E9 : vendredi 26 juillet 2013 00:44 >> =C0 : pcp@ietf.org >> Objet : [pcp] differentiating traffic, draft-wing-pcp-flowdata >>=20 >> Many networks have insufficient access bandwidth and it is desirable = to >> handle flows differently over that access link based on the flow's = needs >> (high bandwidth, low loss, high delay) or if the flow is to a certain >> device or certain user ((living room television, tablet, = mom/dad/kid). >> Hosts don't have a way to prioritize flows downstream (towards the = host) >> and have poor capability to prioritize flows upstream, especially = among the >> various hosts on the network. Various solutions to this problem have = been >> developed over the years (DSCP, RSVP, NSIS) but have drawbacks. >>=20 >> I hope the problem described above resonates with people on this = list. If >> so, read on. >>=20 >>=20 >> In draft-wing-pcp-flowdata we propose a solution: the host describes = the >> flow characteristics to the network and the network indicates its >> (in)ability to accommodate the flow. That flow description can be = used by >> the default network, or propagated along the network. For example in = a >> home network the flow description can propagate from in-home CPE = router to >> the ISP's access router, and in an enterprise network the flow = description >> can propagate within the enterprise network and up to the ISP's = access >> router. When the flow characteristics are communicated to both sides = of a >> resource-constrained link, the routers on both end can provide = different >> packet forwarding treatment to the flow. >>=20 >> The mechanism draft-wing-pcp-flowdata brings some advantages: >>=20 >> * incrementally deployable. This can be implemented entirely within = a >> subscriber's network without participation of their ISP, providing = some >> value (but of course not as much value as being deployed by the ISP's >> access router). Similarly, this can be implemented on the ISP's = router and >> the host could signal directly to that ISP's router without needing = support >> of the intermediate network. >> * adaptive bit rate applications can improve user experience by = avoiding >> attempts to exceed the network's upper bandwidth limit >> * traffic differentiation can be per-"event" (e.g., streaming TV of = the >> Olympics, VoIP call with an important customer), in addition to more >> traditional per-user or per-device or per-application. >>=20 >> Details are in http://tools.ietf.org/html/draft-wing-pcp-flowdata. >>=20 >> Comments welcome. >> -d >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp From dthaler@microsoft.com Sun Jul 28 03:39:35 2013 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 33ADF21F9D69 for ; Sun, 28 Jul 2013 03:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.133 X-Spam-Level: X-Spam-Status: No, score=-100.133 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKAuIZm4yrFt for ; Sun, 28 Jul 2013 03:39:25 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 55FC021F9CF7 for ; Sun, 28 Jul 2013 03:39:24 -0700 (PDT) Received: from mail124-db8-R.bigfish.com (10.174.8.229) by DB8EHSOBE013.bigfish.com (10.174.4.76) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 10:39:23 +0000 Received: from mail124-db8 (localhost [127.0.0.1]) by mail124-db8-R.bigfish.com (Postfix) with ESMTP id BBF1BA00E5 for ; Sun, 28 Jul 2013 10:39:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(z551biz14dfI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h683h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail124-db8: 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 ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail124-db8 (localhost.localdomain [127.0.0.1]) by mail124-db8 (MessageSwitch) id 1375007961365814_3875; Sun, 28 Jul 2013 10:39:21 +0000 (UTC) Received: from DB8EHSMHS031.bigfish.com (unknown [10.174.8.244]) by mail124-db8.bigfish.com (Postfix) with ESMTP id 54FD61C0047 for ; Sun, 28 Jul 2013 10:39:21 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by DB8EHSMHS031.bigfish.com (10.174.4.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 10:39:17 +0000 Received: from DB8EHSOBE035.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sun, 28 Jul 2013 10:37:41 +0000 Received: from mail205-db8-R.bigfish.com (10.174.8.244) by DB8EHSOBE035.bigfish.com (10.174.4.98) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 10:37:38 +0000 Received: from mail205-db8 (localhost [127.0.0.1]) by mail205-db8-R.bigfish.com (Postfix) with ESMTP id B3F9C4402C3 for ; Sun, 28 Jul 2013 10:37:38 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(51704005)(53434003)(189002)(199002)(377454003)(74502001)(50986001)(49866001)(51856001)(47976001)(4396001)(56816003)(77096001)(74366001)(47446002)(19580385001)(19580405001)(33646001)(80022001)(74662001)(76786001)(76576001)(76796001)(47736001)(31966008)(19580395003)(83322001)(16406001)(79102001)(63696002)(54356001)(54316002)(59766001)(74876001)(80976001)(74706001)(77982001)(56776001)(81342001)(65816001)(83072001)(46102001)(74316001)(69226001)(53806001)(81542001)(76482001)(24736002)(3826001)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:df8:0:64:4081:a95b:44c9:973; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail205-db8 (localhost.localdomain [127.0.0.1]) by mail205-db8 (MessageSwitch) id 1375007856505326_11709; Sun, 28 Jul 2013 10:37:36 +0000 (UTC) Received: from DB8EHSMHS024.bigfish.com (unknown [10.174.8.238]) by mail205-db8.bigfish.com (Postfix) with ESMTP id 763CA20046 for ; Sun, 28 Jul 2013 10:37:36 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS024.bigfish.com (10.174.4.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 10:37:36 +0000 Received: from BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sun, 28 Jul 2013 10:37:35 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sun, 28 Jul 2013 10:37:11 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Sun, 28 Jul 2013 10:37:11 +0000 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAKi5qHQ Date: Sun, 28 Jul 2013 10:37:11 +0000 Message-ID: <8c0d2d47049a4482b66cda8c6ebe9d97@BY2PR03MB269.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:64:4081:a95b:44c9:973] x-forefront-prvs: 0921D55E4F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB271.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 10:39:36 -0000 Just a reminder that this poll is closing shortly. If you plan to respond,= please do so asap. -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Monday, July 15, 2013 2:33 AM > To: pcp@ietf.org > Subject: [pcp] CONSENSUS CALL on PCP security >=20 > The WG has discussed two approaches for using EAP with PCP: > direct EAP-in-PCP vs using PANA. >=20 > At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP and = 10 > or 11 for PANA. There was significant confusion/disagreement around > requirements and proposed solutions at that time. >=20 > At IETF 85, we again polled the room and got a different result, this tim= e 12 > hands for direct EAP-in-PCP and 6 for PANA. There was, however, still > significant confusion/disagreement around requirements and proposed > solutions. >=20 > Since IETF 85, we have made lots of progress on getting agreement on the > requirements, and draft-reddy-pcp-auth-req now seems to be relatively > stable without significant areas of disagreement known. > Discussion may of course continue if new issues are raised but we believe > any additional changes are unlikely to affect people's position on overal= l > solution approach, i.e. direct EAP-in-PCP vs. PANA. >=20 > The general sense of the WG also seems to be that either approach could b= e > made to fit the requirements, so we believe it is now time for us to > determine consensus (draft-resnick-on-consensus is a great read) on the > approach question. We know many folks would just like to make a decision > and move on. >=20 > Hence the chairs would like to ask the WG which solution direction the WG > should pursue in meeting the requirements. Please state your > recommendation on this thread, preferably along with your rationale. > Avoid responding on this thread to others' rationale, use a separate thre= ad as > needed. >=20 > To help us judge consensus, please use the template below and respond by > SUNDAY JULY 28. >=20 > -Dave and Reinaldo >=20 > --- >=20 > 1) Could you *live with* EAP-in-PCP? If not, state reason you would objec= t. >=20 > =A0=A0=A0 >=20 > 2) Could you *live with* PANA? If not, state reason you would object. >=20 > =A0=A0=A0 >=20 > 3) If you said yes to both 1 and 2, but have a strong preference between = the > two, which approach do you prefer and why? >=20 > =A0=A0=A0 .=A0 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 From margaretw42@gmail.com Sun Jul 28 09:48:07 2013 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 BFA1421F85B2 for ; Sun, 28 Jul 2013 09:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poFGAH+84aPF for ; Sun, 28 Jul 2013 09:48:06 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA2521F9CDF for ; Sun, 28 Jul 2013 09:48:00 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id q10so1448248pdj.35 for ; Sun, 28 Jul 2013 09:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=S7hOevSPYLWt8vzKhQE+nrPYMi7Z21SDbwQPD/W1Ktk=; b=XVN99F4CxOKr31sJPDMUqwa6FNPUEoKm2ZttrImggYJI28TRJmBMQXxMi7cSvfCs2i BBIn0UVpqR/HdCEXVsVumJV+EnMrnuzVNAiI/h2pE7xnS+0Is45RuN7U4WR88Z58R2aD /vhl4Xkt1tpN2VKOHtHsSGV8f9SeqcySNpX0bDvTzg8yZ4Dauo2DRRx6r4OqVHrr2UrW dCl/U/5292WT0thxHo7VhFcNmWLkzUa5cPBdpSJj4r47uD8TZyDVU0t4wbI2f4c3q1TI 79XakWeKv3V6RiFF6Efee9yyk8RKNclrQDspk5pOqOicBVIm4pZTI1If4vRzFKdQw+RV LMcQ== X-Received: by 10.66.122.131 with SMTP id ls3mr64851606pab.2.1375030080648; Sun, 28 Jul 2013 09:48:00 -0700 (PDT) Received: from [130.129.64.89] (dhcp-4059.meeting.ietf.org. [130.129.64.89]) by mx.google.com with ESMTPSA id ht5sm72023704pbb.29.2013.07.28.09.47.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 09:47:59 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <14AE66FD-CA15-4A80-A761-DDF30552276B@gmail.com> X-Mailer: iPad Mail (10A523) From: Margaret Wasserman Date: Sun, 28 Jul 2013 18:47:55 +0200 To: Dave Thaler Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 16:48:07 -0000 > 1) Could you *live with* EAP-in-PCP? If not, state reason you would object= . >=20 > Yes. > 2) Could you *live with* PANA? If not, state reason you would object. >=20 > Yes. > 3) If you said yes to both 1 and 2, but have a strong preference between > the two, which approach do you prefer and why? >=20 > . I have a very strong preference for EAP-in-PCP for several reasons, all of w= hich I have presented in WG sessions. In summary, I believe that adding PAN= A to the security stack adds complexity to the solution, and I do not see an= y benefits that justify the added complexity. Also, the "code reuse" benefi= t of using PANA and EAP is not, in my opinion, any greater than the code reu= se benefit of using EAP directly, as PCP would require modifications to the P= ANA standards and modifications to any available PANA code. I continue to believe that both solutions could work, and that they would pr= ovide the same level of security. Margaret From cheshire@apple.com Sun Jul 28 10:38:01 2013 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 8C21C21F9D21 for ; Sun, 28 Jul 2013 10:38: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5VqPE8CGbdl for ; Sun, 28 Jul 2013 10:37:55 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 17EE921F9C90 for ; Sun, 28 Jul 2013 10:37:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQN00K7MQB4TS20@mail-out.apple.com> for pcp@ietf.org; Sun, 28 Jul 2013 10:37:54 -0700 (PDT) X-AuditID: 11807166-b7f9f6d000005fde-85-51f556f262ee Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 96.45.24542.2F655F15; Sun, 28 Jul 2013 10:37:54 -0700 (PDT) Received: from dhcp-4145.meeting.ietf.org (dhcp-4145.meeting.ietf.org [130.129.65.69]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MQN008PEQB3V840@koseret.apple.com> for pcp@ietf.org; Sun, 28 Jul 2013 10:37:54 -0700 (PDT) From: Stuart Cheshire In-reply-to: Date: Sun, 28 Jul 2013 10:37:50 -0700 Message-id: <3365F4CD-7EAF-4CB9-86C3-B345968440E7@apple.com> References: To: pcp@ietf.org X-Mailer: Apple Mail (2.1085) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUiON1OXfdT2NdAg7PzpCwmH/vN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKWbdjEW3GSrWPmsk7mBcRVrFyMHh4SAicSLnZldjJxAppjE hXvr2boYuTiEBFqYJHbsOssCkhAS2MMksX4tO4jNLKAlsX7ncSYQm1fAUGLJ9S1gcWEge8ub H2wgNhtQzYvPV8BsToEIiU0zToPNYRFQlZh7dTcjxBxtiSfvLoDdwCtgI/Fsmx7EqnCJS2e7 wMpFBAQkfq++zARxm6zEzjunWSYw8s9CcsUsJFfMQjJ1ASPzKkaBotScxEoLvcSCgpxUveT8 3E2MoOBqKEzbwdi03OoQowAHoxIPr6Xrl0Ah1sSy4srcQ4wSHMxKIrwcRl8DhXhTEiurUovy 44tKc1KLDzFKc7AoifN6Z34IFBJITyxJzU5NLUgtgskycXBKNTAuOPBwqnD55qsrm5pbH16/ fKJFeXLTDbb3P5fnSs25qD1x5dJCoziD9d8ac+X2fHu5L+T3E8bNZV72Bz71rj1T8MGJ13HK 5TmxglKzM2wecyx6HrhOh6/hXe1Gx8vd0u9kwiOOZjyZFaPbs/hZrdKKpqkWMecKhDrXTmr2 DmcTtvlg+S3owRVvJZbijERDLeai4kQA9GWU0SoCAAA= Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 17:38:01 -0000 On 14 Jul 2013, at 17:33, Dave Thaler wrote: > 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. YES. > 2) Could you *live with* PANA? If not, state reason you would object. NO. To elaborate, what I mean is that I would be willing to lobby the relevant Apple engineering teams to implement EAP-in-PCP, and I believe that such efforts would have a reasonable chance of being successful. Note that "relevant Apple engineering teams" covers multiple groups -- PCP client, AirPort Base Station, Internet Sharing, and iPhone personal hotspot. I believe that trying to lobby those four groups to support PCP authentication via PANA would have a small chance of success, because that solution is more complicated and has more potential for more inter-group dependencies. Stuart Cheshire From yoshihiro.ohba@toshiba.co.jp Sun Jul 28 11:21:33 2013 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 6D3F321F9CE9 for ; Sun, 28 Jul 2013 11:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.439 X-Spam-Level: X-Spam-Status: No, score=-4.439 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YldWYgKfXay for ; Sun, 28 Jul 2013 11:21:17 -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 5F7BB21F9D50 for ; Sun, 28 Jul 2013 11:21:09 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r6SIL8fa023560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 03:21:08 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6SIL8fK012054; Mon, 29 Jul 2013 03:21:08 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 183; Mon, 29 Jul 2013 03:21:07 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6SIL7aN012051; Mon, 29 Jul 2013 03:21:07 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r6SIL79K011702; Mon, 29 Jul 2013 03:21:07 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id DAA11701; Mon, 29 Jul 2013 03:21:07 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r6SIL7V8003935; Mon, 29 Jul 2013 03:21:07 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r6SIL7UP007168; Mon, 29 Jul 2013 03:21:07 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.201]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0146.000; Mon, 29 Jul 2013 03:21:07 +0900 From: To: , Thread-Topic: CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAJUru4w Date: Sun, 28 Jul 2013 18:21:07 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.244] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 18:21:33 -0000 MSkgQ291bGQgeW91ICpsaXZlIHdpdGgqIEVBUC1pbi1QQ1A/IElmIG5vdCwgc3RhdGUgcmVhc29u IHlvdSB3b3VsZCBvYmplY3QuDQoNCk5vLiAgDQoNCkVBUC1pbi1QQ1AgaXMgYSByZS1pbnZlbnRp b24gb2YgUEFOQSBpbiB0aGF0IGl0IG1vZGlmaWVzIFBBTkEgaGVhZGVyIHRvIGJlIGEgUENQIG9w Y29kZSBhbmQgUEFOQSBBVlBzIHRvIGJlIFBDUCBvcHRpb25zLiAgV2hhdCBvcHBvbmVudHMgb2Yg UEFOQSBzYXkgIml0J3MgY29tcGxleCB0aGFuIEVBUC1pbi1QQ1AiIGlzIGVpdGhlciBhIGZhbHNl IHN0YXRlbWVudCBvciBtaXNjb25jZXB0aW9uLCBnaXZlbiB0aGF0IHRoZXJlIGlzIG5vIGtub3du IHJ1bm5pbmcgY29kZSBvZiBFQVAtaW4tUENQIEFGQUlLLiAgVGhlIGJhc2ljIHBhcnQgb2YgdGhl IHNjaGVtZSBpcyB0aGUgc2FtZSBhcyB0aGF0IG9mIFBBTkEsIGV4Y2VwdCB0aGF0IHRoZSBzY2hl bWUgbGFja3Mgc3VwcG9ydCBmb3IgcHJvdGVjdGVkIHNlcnZlci1pbml0aWF0ZWQgcmUtYXV0aGVu dGljYXRpb24gdHJpZ2dlciB0byByZW5ldyBhbiBleGlzdGluZyBTQS4gIEFzIGEgcmVzdWx0LCB0 aGUgc2NoZW1lIHdvdWxkIHVubmVjZXNzYXJpbHkgZm9yY2UgdGhlIHNlcnZlciBhbmQgY2xpZW50 IHRvIHdhaXQgdW50aWwgdGhlIGV4aXN0aW5nIFNBIHRvIGJlIGV4cGlyZWQgdG8gaGF2ZSBhIG5l dyBTQSBldmVuIGlmIGltbWVkaWF0ZSByZS1rZXkgaXMgbmVlZGVkLCB0byBmb2xsb3cgdGhlIFBD UCBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMuICBUaGlzIGZ1bmN0aW9uYWwgc2hvcnRjb21p bmcgY291bGQgcHJvYmFibHkgcmVzb2x2ZWQgYnkgZnVydGhlciBtb2RpZnlpbmcgdGhlIHNjaGVt ZSwgYnV0IGl0IHdvdWxkIG1ha2UgdGhlIHNjaGVtZSBmdW5jdGlvbnMgaW4gdGhlIHNhbWUgd2F5 IGFzIFBBTkEuICANCg0KSSBhbSBzdHJvbmdseSBjb25jZXJuZWQgb24gcmUtaW52ZW50aW9uIGlu IHRoZSBJRVRGIGJlY2F1c2UgaWYgd2UgKHRoZSBJRVRGKSBnbyB3aXRoIHRoaXMgc2NoZW1lLCB0 aGVuIHdlIGFyZSBiYXNpY2FsbHkgZW5kb3JzaW5nIHRvIGRldmVsb3AgbXVsdGlwbGUgZGlmZmVy ZW50IGFwcGxpY2F0aW9uLXNwZWNpZmljIEVBUCB0cmFuc3BvcnQgcHJvdG9jb2xzLiAgSW5zdGVh ZCwgd2Ugc2hvdWxkIHJlLXVzZSBhbiBleGlzdGluZyBzdGFuZGFyZCBwcm90b2NvbCBhcyBtdWNo IGFzIHBvc3NpYmxlIGZvciByZWR1Y2luZyByaXNrIG9mIGRlc2lnbiBmbGF3cyBhcyB3ZWxsIGFz IHJlZHVjaW5nIG1haW50ZW5hbmNlIGNvc3Qgb2Ygc3RhbmRhcmQgcHJvdG9jb2xzLiAgSW4gdGhp cyBwcm9ibGVtIHNwYWNlLCByZS11c2Ugb2YgRUFQIGlzIG5vdCBzdWZmaWNpZW50IGFuZCB3ZSBu ZWVkIHRvIHRoaW5rIGFib3V0IHJlLXVzZSBvZiBleGlzdGluZyBFQVAgdHJhbnNwb3J0IGFzIHdl bGwsIGFzIHRyYW5zcG9ydGluZyBFQVAgaGFzIHRvIGNvbnNpZGVyIG1hbnkgYXNwZWN0cyB0byBn ZXQgaXQgcmlnaHQsIGFuZCB0aGF0IGlzIHdoeSBFQVAtaW4tUENQIGxvb2tzIHNpbWlsYXIgdG8g UEFOQS4gIExpa2UgaXQgb3Igbm90LCByZS1pbnZlbnRpb24gY2Fubm90IGJlIGEgZ29vZCBlbmdp bmVlcmluZyB3YXkgdGhhbiByZS11c2UuICAoRm9yIHRoZSBzYW1lIHJlYXNvbiwgSSB3b3VsZCBz dHJvbmdseSBvYmplY3QgaWYgc29tZW9uZSBjb21lIHVwIHdpdGggYSBuZXcgYXV0aGVudGljYXRp b24gcHJvdG9jb2wgdGhhdCBmdW5jdGlvbnMgaW4gdGhlIHNhbWUgd2F5IGFzIEVBUCBvciBhIG5l dyBob3N0IGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wgdGhhdCBmdW5jdGlvbnMgaW4gdGhlIHNhbWUg d2F5IGFzIERIQ1AsIGV0Yy4pDQoNCjIpIENvdWxkIHlvdSAqbGl2ZSB3aXRoKiBQQU5BPyBJZiBu b3QsIHN0YXRlIHJlYXNvbiB5b3Ugd291bGQgb2JqZWN0Lg0KDQpZZXMuDQoNClJlZ2FyZHMsDQpZ b3NoaWhpcm8gT2hiYQ0K From subirdas21@gmail.com Sun Jul 28 14:06:19 2013 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 8BD0121F9E5E for ; Sun, 28 Jul 2013 14:06:19 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxvpVdAM3ZqX for ; Sun, 28 Jul 2013 14:06:18 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2021F9E28 for ; Sun, 28 Jul 2013 14:06:18 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so11369551oah.21 for ; Sun, 28 Jul 2013 14:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sqv2y/yt0XFSiKy/MVx8Rh3Flk0UPrL2p3Sn1GqYotI=; b=T3Yk/lv+j4zpv1uY70jDjDA0Roqlep+En2aPPTYboqTRVeyFlUcOy4s3z4laeir1I9 K8c2Erhl9QzQ8eA5ysSmPAwBH1kVFMGik2qecBX8ZTUD5IjMk3buwBXOn0EV1QZQQaTa hkPPpGvEDFPzxibWP8LYu9A/CTw1NJglWl0YnKK3ouMZviXN82VmSUE7/FCeC5Qys1zd U0Z6ak6in1OTmHAxCDzpu9/Rp5a2NaqvStRTt8x7yc2we8yOCuGaeDn7gURBd9uGPK2z 8DpmknYe05pqexmgOWBUu/ywGp3/eMiAqa3kzwbZ81imf1aAzdgsADVhQ3GnMhacGCgN 6jKA== MIME-Version: 1.0 X-Received: by 10.43.11.69 with SMTP id pd5mr157872icb.62.1375045577905; Sun, 28 Jul 2013 14:06:17 -0700 (PDT) Received: by 10.43.172.8 with HTTP; Sun, 28 Jul 2013 14:06:17 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Jul 2013 17:06:17 -0400 Message-ID: From: Subir Das To: Dave Thaler Content-Type: multipart/alternative; boundary=bcaec50fe46f389a2f04e298bf6e Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 21:06:19 -0000 --bcaec50fe46f389a2f04e298bf6e Content-Type: text/plain; charset=ISO-8859-1 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. No. IMO, the current specification is not complete. Assume that the draft is modified and it satisfies the PCP requirements, my understanding is that it will end up with another protocol very similar to PANA. What would be the benefit of doing the similar work and develop yet another EAP lower layer when we have already an IETF protocol that satisfies all the PCP requirements? It was shown that PANA works with PCP without any modifications of existing PANA RFC. The results were presented in the last IETF. So my points are: existing RFC and running code. Moreover, the integration is simple. N.B.: PANA is currently under deployment in a major vertical market. 2) Could you *live with* PANA? If not, state reason you would object. Yes. Thanks, -Subir On Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler wrote: > The WG has discussed two approaches for using EAP with PCP: > direct EAP-in-PCP vs using PANA. > > At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP > and 10 or 11 for PANA. There was significant confusion/disagreement > around requirements and proposed solutions at that time. > > At IETF 85, we again polled the room and got a different result, this > time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however, > still significant confusion/disagreement around requirements and > proposed solutions. > > Since IETF 85, we have made lots of progress on getting agreement > on the requirements, and draft-reddy-pcp-auth-req now seems to be > relatively stable without significant areas of disagreement known. > Discussion may of course continue if new issues are raised but we > believe any additional changes are unlikely to affect people's > position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA. > > The general sense of the WG also seems to be that either approach could be > made to fit the requirements, so we believe it is now time for us to > determine consensus (draft-resnick-on-consensus is a great read) > on the approach question. We know many folks would just like to > make a decision and move on. > > Hence the chairs would like to ask the WG which solution direction the > WG should pursue in meeting the requirements. Please state your > recommendation on this thread, preferably along with your rationale. > Avoid responding on this thread to others' rationale, use a separate > thread as needed. > > To help us judge consensus, please use the template below and > respond by SUNDAY JULY 28. > > -Dave and Reinaldo > > --- > > 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. > > > > 2) Could you *live with* PANA? If not, state reason you would object. > > > > 3) If you said yes to both 1 and 2, but have a strong preference between > the two, which approach do you prefer and why? > > . > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > --bcaec50fe46f389a2f04e298bf6e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1) Could you *live with* EAP-in-PCP? If not, state re= ason you would object.

No. IMO, the current=A0 specification is not = complete.=A0=A0Assume that=A0the draft is modified and=A0it satisfies=A0=A0= the PCP requirements, my=A0understanding =A0is that it will end up with=A0a= nother protocol very similar to PANA.=A0What=A0would be the benefit of doin= g the=A0similar work and=A0develop yet another=A0EAP lower layer when=A0we = have already an IETF protocol that=A0satisfies all the PCP requirements?=A0= =A0It was shown that PANA works with PCP without=A0any=A0modifications of= =A0existing PANA RFC.=A0The results were presented in the last IETF.=A0=A0 = So my points are: existing RFC and running code. Moreover, the integration = is simple.
=A0
N.B.: PANA is currently under deployment in a major vert= ical market.=A0

=A02) Could you *live with* PANA? If not, st= ate reason you would object.

=A0=A0=A0Yes.

=A0Thanks,
<= div>-Subir


O= n Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler <dthaler@microsoft.com> wrote:
The WG has discussed two approaches for usin= g EAP with PCP:
direct EAP-in-PCP vs using PANA.

At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP
and 10 or 11 for PANA. There was significant confusion/disagreement
around requirements and proposed solutions at that time.

At IETF 85, we again polled the room and got a different result, this
time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however,
still significant confusion/disagreement around requirements and
proposed solutions.

Since IETF 85, we have made lots of progress on getting agreement
on the requirements, and draft-reddy-pcp-auth-req now seems to be
relatively stable without significant areas of disagreement known.
Discussion may of course continue if new issues are raised but we
believe any additional changes are unlikely to affect people's
position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA.

The general sense of the WG also seems to be that either approach could be<= br> made to fit the requirements, so we believe it is now time for us to
determine consensus (draft-resnick-on-consensus is a great read)
on the approach question. We know many folks would just like to
make a decision and move on.

Hence the chairs would like to ask the WG which solution direction the
WG should pursue in meeting the requirements. Please state your
recommendation on this thread, preferably along with your rationale.
Avoid responding on this thread to others' rationale, use a separate thread as needed.

To help us judge consensus, please use the template below and
respond by SUNDAY JULY 28.

-Dave and Reinaldo

---

1) Could you *live with* EAP-in-PCP? If not, state reason you would object.=

=A0=A0=A0 <NO and state reason, or YES>

2) Could you *live with* PANA? If not, state reason you would object.

=A0=A0=A0 <NO and state reason, or YES>

3) If you said yes to both 1 and 2, but have a strong preference between the two, which approach do you prefer and why?

=A0=A0=A0 <EAP-in-PCP, or PANA>.=A0 <state reason>

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

--bcaec50fe46f389a2f04e298bf6e-- From Ted.Lemon@nominum.com Sun Jul 28 14:45:19 2013 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 A423F21F99CD for ; Sun, 28 Jul 2013 14:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eino8BoXRiW4 for ; Sun, 28 Jul 2013 14:45:12 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1AD21F9E1E for ; Sun, 28 Jul 2013 14:45:11 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUfWQ5lsHLd+5zOXNfl7WS9O3Be3ckelG@postini.com; Sun, 28 Jul 2013 14:45:11 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AC8B41B8244 for ; Sun, 28 Jul 2013 14:45:10 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1728619006B; Sun, 28 Jul 2013 14:45:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 14:45:03 -0700 From: Ted Lemon To: "yoshihiro.ohba@toshiba.co.jp" Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAJUru4wAHNf5gA= Date: Sun, 28 Jul 2013 21:45:02 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <8E076AFA8D613B458DD74E5A2B76DD7E@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 21:45:19 -0000 On Jul 28, 2013, at 8:21 PM, yoshihiro.ohba@toshiba.co.jp wrote: > 1) Could you *live with* EAP-in-PCP? If not, state reason you would objec= t. >=20 > No. >=20 > EAP-in-PCP is a re-invention of PANA in that it modifies PANA header to b= e a PCP opcode and PANA AVPs to be PCP options. What opponents of PANA say= "it's complex than EAP-in-PCP" is either a false statement or misconceptio= n, given that there is no known running code of EAP-in-PCP AFAIK. The basi= c part of the scheme is the same as that of PANA, except that the scheme la= cks support for protected server-initiated re-authentication trigger to ren= ew an existing SA. As a result, the scheme would unnecessarily force the s= erver and client to wait until the existing SA to be expired to have a new = SA even if immediate re-key is needed, to follow the PCP authentication req= uirements. This functional shortcoming could probably resolved by further = modifying the scheme, but it would make the scheme functions in the same wa= y as PANA. =20 >=20 > I am strongly concerned on re-invention in the IETF because if we (the IE= TF) go with this scheme, then we are basically endorsing to develop multipl= e different application-specific EAP transport protocols. Instead, we shoul= d re-use an existing standard protocol as much as possible for reducing ris= k of design flaws as well as reducing maintenance cost of standard protocol= s. In this problem space, re-use of EAP is not sufficient and we need to t= hink about re-use of existing EAP transport as well, as transporting EAP ha= s to consider many aspects to get it right, and that is why EAP-in-PCP look= s similar to PANA. Like it or not, re-invention cannot be a good engineeri= ng way than re-use. (For the same reason, I would strongly object if someo= ne come up with a new authentication protocol that functions in the same wa= y as EAP or a new host configuration protocol that functions in the same wa= y as DHCP, etc.) You will notice that Margaret made a statement about her preference, but sh= e stated it in response to the question about preference, and in that conte= xt it made sense and was responsive to the chairs' question. The above st= atement reads to me like a statement of preference, not a technical objecti= on, and so it seems to me not to be responsive to the chairs' question. I= s there a technical objection somewhere in the above text that I have misse= d, or are you in fact just stating a preference? From alper.yegin@yegin.org Sun Jul 28 14:46:42 2013 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 DEA7D21F9EAA for ; Sun, 28 Jul 2013 14:46:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MYltjlPOIc1 for ; Sun, 28 Jul 2013 14:46:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id C3C0E21F9E01 for ; Sun, 28 Jul 2013 14:46:30 -0700 (PDT) Received: from vpn-cust-10-119-16-2.witopia.net (37-59-223-44.op-net.com [37.59.223.44]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M9sJc-1Ux0Gx2AP2-00B87b; Sun, 28 Jul 2013 17:46:22 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: Date: Mon, 29 Jul 2013 00:46:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <63D8E1EA-A7F0-414C-8678-0F5121BFDD79@yegin.org> References: To: Dave Thaler X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:mbHR/P9jCVtWMqcXZNtAnRfnI/AbGrVyuQw3gsZ4s5L ui3ml5Zd99Sn9LNJGJzpp1c2IqUqyd1KAgAA6i9fls8F6TULCe 2yWvx1otGK+C1dlhuGqEAYr6qooTpgzp/n6/O6o89PPZrb01GF kc3v6V9uR2NU11c6v2U09jrLndMZJM0bJXW/7fOIIkrY2wi86Q aV9wIzjYYj5xI3hSLhvli27owMKM9sfw9s4fYy/nyX5mOLxLKc 2aNcyfTS2dTsJceslUUEXtq62XksuqiDhNYtsCpwkJHI9YbfG8 dCO1j0HebZyZnbkPSXW1sWGC7LW/t+4qizWbpVbeFt6OO1orLO MAMt/OmKB0g+GTq4A0YnTC/IZVEYivmlsn+0pd9OusrgnE8dgs PFCsYlC5E/61YhCmWE9lDwrO25B5+mmRhc= Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 21:46:43 -0000 >=20 > --- >=20 > 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >=20 >=20 No. Supporters have not made a successful case for not using an already = existing IETF RFC, and instead reinventing it (which is EAP-o-PCP). Besides, EAP-o-PCP spec is still incomplete (no support for = server-initiated re-auth -- which people finally agreed to its need = after long debates).=20 On one side, there is an IETF RFC that got adopted by another SDO = (Zigbee Alliance), implemented by multiple vendors and successfully = interoperated. On the other side is an incomplete spec, which at best can do what PANA = already does if and when it goes thru the same stages. There's literally no indication that EAP-o-PCP would be any better, = simpler, etc. after passing all those stages. =20 > 2) Could you *live with* PANA? If not, state reason you would object. >=20 >=20 Yes.=20 From rafa@um.es Sun Jul 28 14:57:26 2013 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 8D52921F99F6 for ; Sun, 28 Jul 2013 14:57:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkTKciSJalBI for ; Sun, 28 Jul 2013 14:57:20 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 766E821F99E1 for ; Sun, 28 Jul 2013 14:57:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 0E9BE5D4E9 for ; Sun, 28 Jul 2013 23:57:19 +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 cA--ahLzTPzP for ; Sun, 28 Jul 2013 23:57:18 +0200 (CEST) Received: from dhcp-92cc.meeting.ietf.org (dhcp-92cc.meeting.ietf.org [130.129.10.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPSA id 5FD815D4E6 for ; Sun, 28 Jul 2013 23:57:17 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: Rafa Marin Lopez In-Reply-To: Date: Sun, 28 Jul 2013 23:57:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1092757F-2853-4F2D-BF60-4C4E733AB3EC@um.es> References: To: pcp@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 21:57:26 -0000 > 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. NO.=20 Let's avoid re-inventing the wheel. All the arguments I have seen in = favor of EAP-in-PCP have been based on pure speculation so far. The same = has happened with the arguments against PANA. And those against PANA = either they have been based on misconceptions about PANA or simply the = arguments were wrong. Here in the list, we have clarified several times = these points one by one. In any case, the fact is PANA is a RFC, another = fact is that it has running code (two open source implementations so = far) and another fact it has been easily integrated with PCP as we = showed in IETF 86. So, what else do we need? >=20 > 2) Could you *live with* PANA? If not, state reason you would object. >=20 > YES.=20 ------------------------------------------------------- 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 yoshihiro.ohba@toshiba.co.jp Sun Jul 28 14:58:24 2013 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 0D56421F84B6 for ; Sun, 28 Jul 2013 14:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=1.767, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xozc1Oa6K-oX for ; Sun, 28 Jul 2013 14:58:15 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id DC43121F9130 for ; Sun, 28 Jul 2013 14:58:10 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r6SLw8jZ018871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 06:58:08 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6SLw8QM026343; Mon, 29 Jul 2013 06:58:08 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 526; Mon, 29 Jul 2013 06:58:08 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6SLw89w026340; Mon, 29 Jul 2013 06:58:08 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r6SLw8uI001380; Mon, 29 Jul 2013 06:58:08 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id GAA01379; Mon, 29 Jul 2013 06:58:08 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r6SLw717005963; Mon, 29 Jul 2013 06:58:08 +0900 (JST) Received: from TGXML330.toshiba.local by toshiba.co.jp id r6SLw7ac017185; Mon, 29 Jul 2013 06:58:07 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.201]) by TGXML330.toshiba.local ([133.199.60.204]) with mapi id 14.03.0146.000; Mon, 29 Jul 2013 06:58:07 +0900 From: To: Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAJUru4wAHNf5gAADaTBMA== Date: Sun, 28 Jul 2013 21:58:07 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.174] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcp@ietf.org Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 21:58:24 -0000 -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Monday, July 29, 2013 6:45 AM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ) Cc: ; Subject: Re: [pcp] CONSENSUS CALL on PCP security On Jul 28, 2013, at 8:21 PM, yoshihiro.ohba@toshiba.co.jp wrote: > 1) Could you *live with* EAP-in-PCP? If not, state reason you would objec= t. >=20 > No. >=20 > EAP-in-PCP is a re-invention of PANA in that it modifies PANA header to b= e a PCP opcode and PANA AVPs to be PCP options. What opponents of PANA say= "it's complex than EAP-in-PCP" is either a false statement or misconceptio= n, given that there is no known running code of EAP-in-PCP AFAIK. The basi= c part of the scheme is the same as that of PANA, except that the scheme la= cks support for protected server-initiated re-authentication trigger to ren= ew an existing SA. As a result, the scheme would unnecessarily force the s= erver and client to wait until the existing SA to be expired to have a new = SA even if immediate re-key is needed, to follow the PCP authentication req= uirements. This functional shortcoming could probably resolved by further = modifying the scheme, but it would make the scheme functions in the same wa= y as PANA. =20 >=20 > I am strongly concerned on re-invention in the IETF because if we (the IE= TF) go with this scheme, then we are basically endorsing to develop multipl= e different application-specific EAP transport protocols. Instead, we shoul= d re-use an existing standard protocol as much as possible for reducing ris= k of design flaws as well as reducing maintenance cost of standard protocol= s. In this problem space, re-use of EAP is not sufficient and we need to t= hink about re-use of existing EAP transport as well, as transporting EAP ha= s to consider many aspects to get it right, and that is why EAP-in-PCP look= s similar to PANA. Like it or not, re-invention cannot be a good engineeri= ng way than re-use. (For the same reason, I would strongly object if someo= ne come up with a new authentication protocol that functions in the same wa= y as EAP or a new host configuration protocol that functions in the same wa= y as DHCP, etc.) You will notice that Margaret made a statement about her preference, but sh= e stated it in response to the question about preference, and in that conte= xt it made sense and was responsive to the chairs' question. The above st= atement reads to me like a statement of preference, not a technical objecti= on, and so it seems to me not to be responsive to the chairs' question. I= s there a technical objection somewhere in the above text that I have misse= d, or are you in fact just stating a preference? [YO] I wrote the above statement from architectural point of view, which I = believe is a technical matter (not just a preference). Yoshihiro Ohba From pedrorechez@gmail.com Sun Jul 28 14:59:14 2013 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 4CBBE21F9B14 for ; Sun, 28 Jul 2013 14:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZghUtnwQ9uYt for ; Sun, 28 Jul 2013 14:59:13 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3D19D21F9AFE for ; Sun, 28 Jul 2013 14:59:13 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hr7so732733wib.12 for ; Sun, 28 Jul 2013 14:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:cc:content-type; bh=8UWW4N/zOgKDgbpsx0lTqR07ICwGRYdMTWYPrquhP5I=; b=KkacDUnCIR/CGaQZsaacYumlXuj7g6gVt4bs99M1r6uIM8MVVCcjUgaIdDg7x9I5PH 6Un3pCgjL6a5s9AirofdNw6VNSCedkc84srJyHTzbJ6Yjgdg3Iu4HkEInIXiPPMYuCio iRkj6oZGLwXJeoEF9gj/Wb6DYN5ZhVhCD7jSHdPPvT3aLoqMOMsCnjXiP0sgdFA3s8f0 WXHjJ8BLxTLnuPPW9g7W8QVO2NnubTG6ZIjt0AI1iUoz3FN8afPAN9dArw21ibMeBYTD VocBu9Kg6trDFJVdEl3vWuH2OHCRr9XghvucoVRW5U8ZQF+FFANzKDl80LV87fvMV9+6 Dp5Q== X-Received: by 10.180.12.196 with SMTP id a4mr5221858wic.29.1375048752322; Sun, 28 Jul 2013 14:59:12 -0700 (PDT) MIME-Version: 1.0 Sender: pedrorechez@gmail.com Received: by 10.194.81.162 with HTTP; Sun, 28 Jul 2013 14:58:52 -0700 (PDT) In-Reply-To: <1092757F-2853-4F2D-BF60-4C4E733AB3EC@um.es> References: <1092757F-2853-4F2D-BF60-4C4E733AB3EC@um.es> From: =?ISO-8859-1?Q?Pedro_Moreno_S=E1nchez?= Date: Sun, 28 Jul 2013 23:58:52 +0200 X-Google-Sender-Auth: 3MMO6k9y6_hhBGoZWEa2R-yZlak Message-ID: Cc: pcp@ietf.org Content-Type: multipart/alternative; boundary=001a11c3668a6e5eb804e2997ccf Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 22:04:03 -0000 --001a11c3668a6e5eb804e2997ccf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. NO. During the discussion, it has been stated that the integration of PANA and PCP is hard to implement and to mantain given the current PANA opensource implementations (i.e., OpenPANA and CPANA) As one of main developers of OpenPANA and the PCP-PANA integration project presented at the IETF86 meeting, I would like to totally disclaim this argument. Given the currently available code of OpenPANA and CPANA, the integration with PCP was really easy. Our PCP-PANA integration from scratch took few lines of code and, however, it leaded to a correctly working solution according to the PCP requirements. 2) Could you *live with* PANA? If not, state reason you would object. YES On 28 July 2013 23:57, Rafa Marin Lopez wrote: > > > 1) Could you *live with* EAP-in-PCP? If not, state reason you would > object. > > NO. > > Let's avoid re-inventing the wheel. All the arguments I have seen in favo= r > of EAP-in-PCP have been based on pure speculation so far. The same has > happened with the arguments against PANA. And those against PANA either > they have been based on misconceptions about PANA or simply the arguments > were wrong. Here in the list, we have clarified several times these point= s > one by one. In any case, the fact is PANA is a RFC, another fact is that = it > has running code (two open source implementations so far) and another fac= t > it has been easily integrated with PCP as we showed in IETF 86. So, what > else do we need? > > > > > 2) Could you *live with* PANA? If not, state reason you would object. > > > > > > YES. > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- > > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > --=20 ---------------------------------------------------------------------------= - Pedro Moreno S=E1nchez - MSc Computer Engineer Networks and Telematics Faculty of Computer Science - University of Murcia 30100 - Murcia - Spain email: p.morenosanchez@um.es ---------------------------------------------------------------------------= - --001a11c3668a6e5eb804e2997ccf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1) Could you *live with* EAP-in-PCP? If not, state reason = you would object.
NO. During the discussion, it has been stated that the= integration of PANA and PCP is hard to implement and to mantain given the = current PANA opensource implementations (i.e., OpenPANA and CPANA)

As one of main developers of OpenPANA and the PCP-PANA integration proj= ect
presented at the IETF86 meeting, I would like to totally disclaim th= is argument. Given the
currently available code of OpenPANA and CPANA, t= he integration with PCP was really easy.
Our PCP-PANA integration from scratch took few lines of code and, however, = it leaded
to a correctly working solution according to the PCP requireme= nts.

2) Could you *live with* PANA? If not, state reason you would o= bject.
YES


= On 28 July 2013 23:57, Rafa Marin Lopez <rafa@um.es> wrote:

> 1) Could you *live with* EAP-in-PCP? If not, state reason you would ob= ject.

NO.

Let's avoid re-inventing the wheel. All the arguments I have seen in fa= vor of EAP-in-PCP have been based on pure speculation so far. The same has = happened with the arguments against PANA. And those against PANA either the= y have been based on misconceptions about PANA or simply the arguments were= wrong. Here in the list, we have clarified several times these points one = by one. In any case, the fact is PANA is a RFC, another fact is that it has= running code (two open source implementations so far) and another fact it = has been easily integrated with PCP as we showed in IETF 86. So, what else = do we need?

>
> 2) Could you *live with* PANA? If not, state reason you would object.<= br> >
> =A0 =A0 <NO and state reason, or YES>

YES.


-------------------------------------------------------
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
-------------------------------------------------------




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



--
-----------= -----------------------------------------------------------------
Pedro = Moreno S=E1nchez =A0- MSc Computer Engineer
Networks and Telematics
<= div> Faculty of Computer Science - University of Murcia
30100 - Murcia - Spain<= /div>
---------= -------------------------------------------------------------------<= /span>
<= br>



--001a11c3668a6e5eb804e2997ccf-- From Ted.Lemon@nominum.com Sun Jul 28 15:07:11 2013 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 E83A521F9EDB for ; Sun, 28 Jul 2013 15:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZcyaqxcFYMQ for ; Sun, 28 Jul 2013 15:07:05 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 207E521F9EC6 for ; Sun, 28 Jul 2013 15:07:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUfWWByH5XG6Si1piUynDGAMHI5HqSOwv@postini.com; Sun, 28 Jul 2013 15:07:05 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0B4031B8232 for ; Sun, 28 Jul 2013 15:07:03 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 039C019006B; Sun, 28 Jul 2013 15:07:03 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 15:07:03 -0700 From: Ted Lemon To: " " Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAJUru4wAHNf5gAADaTBMP//n9GA Date: Sun, 28 Jul 2013 22:07:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <42D51991BA6CBC4BBA6BDFF433889CC8@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 22:07:12 -0000 On Jul 28, 2013, at 11:58 PM, wrote: > [YO] I wrote the above statement from architectural point of view, which = I believe is a technical matter (not just a preference). No, it's not a technical matter. It is a matter of preference, in much th= e same way that the choice of whether to have an open atrium that brings in= sunlight, or closed floor that provides more square footage is a matter of= preference. If the extra square footage is a must, then that _becomes_ a technical argu= ment, because the atrium provides less square footage. But none of the fo= ur people (you, Alper, Subir and Rafa) who just asserted that EAP-in-PCP wa= s something they could live with gave a reason why they couldn't live with = it. All four of you just said you couldn't live with it because you like = atriums better than closed floors. I do too, and it's a perfectly valid t= hing to say, but it's not a reason to say you can't *live with* EAP-in-PCP. The problem with discussions about what is "architecturally better" tend to= be matters of opinion, which can't be resolved, so it's always better to h= ave some technical argument to use as a basis for differentiating between t= he choices, so that we don't have to make a choice based on a coin toss. From Ted.Lemon@nominum.com Sun Jul 28 15:11:34 2013 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 CD61921F9EBE for ; Sun, 28 Jul 2013 15:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qddOFPr4c88G for ; Sun, 28 Jul 2013 15:11:28 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 14B8421F9E46 for ; Sun, 28 Jul 2013 15:11:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUfWXD5N78belZS+pdFHR3R/HXNPWRjOF@postini.com; Sun, 28 Jul 2013 15:11:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A2B861B8244 for ; Sun, 28 Jul 2013 15:11:27 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9C42919006B; Sun, 28 Jul 2013 15:11:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 15:11:27 -0700 From: Ted Lemon To: "" Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAJUru4wAHNf5gAADaTBMP//n9GAgAABO4A= Date: Sun, 28 Jul 2013 22:11:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 28 Jul 2013 22:11:34 -0000 On Jul 29, 2013, at 12:07 AM, Ted Lemon wrote: > But none of the four people (you, Alper, Subir and Rafa) who just asserte= d that EAP-in-PCP was something they could live with gave a reason why they= couldn't live with it. Sorry, that should have been "could not live with". From aland@deployingradius.com Sun Jul 28 17:11:14 2013 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 2A26621F96D9 for ; Sun, 28 Jul 2013 17:11:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXL3k5nRMVsY for ; Sun, 28 Jul 2013 17:11:08 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB46021F967F for ; Sun, 28 Jul 2013 17:11:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 4B36822400FB; Mon, 29 Jul 2013 02:11:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIgjAe71-GWX; Mon, 29 Jul 2013 02:11:03 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 8C8C222400BE; Mon, 29 Jul 2013 02:11:02 +0200 (CEST) Message-ID: <51F5B318.2050908@deployingradius.com> Date: Sun, 28 Jul 2013 20:11:04 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Margaret Wasserman References: <14AE66FD-CA15-4A80-A761-DDF30552276B@gmail.com> In-Reply-To: <14AE66FD-CA15-4A80-A761-DDF30552276B@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 00:11:14 -0000 I agree with Margaret. Margaret Wasserman wrote: >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. >> >> > > Yes. > >> 2) Could you *live with* PANA? If not, state reason you would object. >> >> > > Yes. > >> 3) If you said yes to both 1 and 2, but have a strong preference between >> the two, which approach do you prefer and why? >> >> . > > I have a very strong preference for EAP-in-PCP for several reasons, all of which I have presented in WG sessions. In summary, I believe that adding PANA to the security stack adds complexity to the solution, and I do not see any benefits that justify the added complexity. Also, the "code reuse" benefit of using PANA and EAP is not, in my opinion, any greater than the code reuse benefit of using EAP directly, as PCP would require modifications to the PANA standards and modifications to any available PANA code. > > I continue to believe that both solutions could work, and that they would provide the same level of security. > > Margaret > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From aland@deployingradius.com Sun Jul 28 17:12:55 2013 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 10C3921F9946 for ; Sun, 28 Jul 2013 17:12:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eefQvNRz-hkG for ; Sun, 28 Jul 2013 17:12:49 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25ACC21F997B for ; Sun, 28 Jul 2013 17:12:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E269822400FB; Mon, 29 Jul 2013 02:12:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXDv-SR7UGtI; Mon, 29 Jul 2013 02:12:01 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id C690D22400BE; Mon, 29 Jul 2013 02:12:00 +0200 (CEST) Message-ID: <51F5B352.3010803@deployingradius.com> Date: Sun, 28 Jul 2013 20:12:02 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 00:12:55 -0000 yoshihiro.ohba@toshiba.co.jp wrote: > EAP-in-PCP is a re-invention of PANA in that it modifies PANA header to be a PCP opcode and PANA AVPs to be PCP options. What opponents of PANA say "it's complex than EAP-in-PCP" is either a false statement or misconception, given that there is no known running code of EAP-in-PCP AFAIK. Only if you ignore the previous conversations on this topic, along with statistics. Alan DeKok. From aland@deployingradius.com Sun Jul 28 17:20:29 2013 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 42E9921F9AC1 for ; Sun, 28 Jul 2013 17:20:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADhPY8c3s3oY for ; Sun, 28 Jul 2013 17:20:23 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5042321F9AB3 for ; Sun, 28 Jul 2013 17:20:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id B9D7922400FB; Mon, 29 Jul 2013 02:20:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q585gle6wfbU; Mon, 29 Jul 2013 02:20:22 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 1C33E22400BE; Mon, 29 Jul 2013 02:20:22 +0200 (CEST) Message-ID: <51F5B548.6030406@deployingradius.com> Date: Sun, 28 Jul 2013 20:20:24 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Rafa Marin Lopez References: <1092757F-2853-4F2D-BF60-4C4E733AB3EC@um.es> In-Reply-To: <1092757F-2853-4F2D-BF60-4C4E733AB3EC@um.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 00:20:29 -0000 Rafa Marin Lopez wrote: > Let's avoid re-inventing the wheel. All the arguments I have seen in favor of EAP-in-PCP have been based on pure speculation so far. No. > The same has happened with the arguments against PANA. And those against PANA either they have been based on misconceptions about PANA or simply the arguments were wrong. No. > Here in the list, we have clarified several times these points one by one. Partly. The arguments for PANA are (a) it's a standard, and (b) random pointing to proprietary implementations. The arguments for EAP-in-PCP have drawn on prior art, with statistics, facts, and evidence. The main reason to not use EAP-in-PCP is that it's not a standard use of EAP. But EAP has been proven to work in practice in similar situations. > In any case, the fact is PANA is a RFC, another fact is that it has running code (two open source implementations so far) Are these actually used anywhere? i.e. have even the authors used them? Last I looked, I couldn't even build them in a Posix environment. They seemed to require a specific version of Linux with specific libraries, etc. They just don't look like production code used in a wide variety of environments. And to show my statistics: every new release of FreeRADIUS has 1M downloads just from my web site. It's worked for nearly 15 years on Linux, *BSD, Solaris, AIX, HPUX, Mac OSX, with a preliminary Windows port. It's used by tier one Telcos, in loads reaching 100K+ transactions per day, for over a decade. Even ignoring the usage numbers, the open source PANA implementations don't match that level of code quality, portability, or stability. I would *not* recommend depending on them in any production environment. > and another fact it has been easily integrated with PCP as we showed in IETF 86. So, what else do we need? The truth would help. Alan DeKok. From internet-drafts@ietf.org Sun Jul 28 23:12:07 2013 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 623E711E80D2; Sun, 28 Jul 2013 23:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNeRci1xZh+G; Sun, 28 Jul 2013 23:12:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BDB21F9FE1; Sun, 28 Jul 2013 23:12: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.60p1 Message-ID: <20130729061206.24586.72780.idtracker@ietfa.amsl.com> Date: Sun, 28 Jul 2013 23:12:06 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-proxy-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, 29 Jul 2013 06:12: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 : Port Control Protocol (PCP) Proxy Function Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-proxy-04.txt Pages : 11 Date : 2013-07-28 Abstract: This document specifies a new PCP functional element denoted as a PCP Proxy. The PCP Proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that can not be configured with the address of a PCP server located more than one hop away. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-proxy-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Sun Jul 28 23:25:26 2013 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 BD4D221F99AE for ; Sun, 28 Jul 2013 23:25:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTfA+voPIXy3 for ; Sun, 28 Jul 2013 23:25:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 69E2721F96D9 for ; Sun, 28 Jul 2013 23:25:22 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6FC1122E943 for ; Mon, 29 Jul 2013 08:25:20 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 59732238055 for ; Mon, 29 Jul 2013 08:25:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 29 Jul 2013 08:25:20 +0200 From: To: "pcp@ietf.org" Date: Mon, 29 Jul 2013 08:25:17 +0200 Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-proxy-04.txt Thread-Index: Ac6MIpfT/OWbBnPDQNKkaAVbKuqd7AAAUYJg Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E83440@PUEXCB1B.nanterre.francetelecom.fr> References: <20130729061206.24586.72780.idtracker@ietfa.amsl.com> In-Reply-To: <20130729061206.24586.72780.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: 2013.7.29.54526 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-proxy-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, 29 Jul 2013 06:25:26 -0000 Dear all, The main changes in the new version are: * Add explicit text about configuring which interface(s) the PCP Proxy will= act on as a PCP Server * Explicit the PCP error code to be returned * Explicit the ICMP error code to be returned when an error on the UDP sock= et is experienced * The PCP Proxy is now in charge to enforce the message size limit instead = of relaying the message to the ultimate server * If the PCP Proxy processing (e.g., adding a THIRD_PARTY Option) makes a r= equest that exceeds 1100 octets, a MALFORMED_REQUEST response is sent to th= e PCP client * Update the security considerations section with some text about THIRD_PAR= TY To check the detailed modifs, a diff is available at: http://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-pcp-proxy-04=20 Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >internet-drafts@ietf.org >Envoy=E9=A0: lundi 29 juillet 2013 08:12 >=C0=A0: i-d-announce@ietf.org >Cc=A0: pcp@ietf.org >Objet=A0: [pcp] I-D Action: draft-ietf-pcp-proxy-04.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Port Control Protocol Working Group of >the IETF. > > Title : Port Control Protocol (PCP) Proxy Function > Author(s) : Mohamed Boucadair > Reinaldo Penno > Dan Wing > Filename : draft-ietf-pcp-proxy-04.txt > Pages : 11 > Date : 2013-07-28 > >Abstract: > This document specifies a new PCP functional element denoted as a PCP > Proxy. The PCP Proxy relays PCP requests received from PCP clients > to upstream PCP server(s). A typical deployment usage of this > function is to help establish successful PCP communications for PCP > clients that can not be configured with the address of a PCP server > located more than one hop away. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-proxy-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-04 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From zhang_dacheng@hotmail.com Mon Jul 29 00:38:24 2013 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 7022B21F8C20 for ; Mon, 29 Jul 2013 00:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.247 X-Spam-Level: * X-Spam-Status: No, score=1.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plTHk9nrO-gB for ; Mon, 29 Jul 2013 00:38:19 -0700 (PDT) Received: from blu0-omc1-s7.blu0.hotmail.com (blu0-omc1-s7.blu0.hotmail.com [65.55.116.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5136521F8AD5 for ; Mon, 29 Jul 2013 00:38:19 -0700 (PDT) Received: from BLU0-SMTP226 ([65.55.116.7]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Jul 2013 00:38:19 -0700 X-EIP: [07G0qkKv4G2WGmjyz80OYMdTk3IlNdvm] X-Originating-Email: [zhang_dacheng@hotmail.com] Message-ID: Received: from dhcp-15e4.meeting.ietf.org ([130.129.21.228]) by BLU0-SMTP226.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Jul 2013 00:38:15 -0700 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="GB2312" From: Dacheng Zhang In-Reply-To: <14AE66FD-CA15-4A80-A761-DDF30552276B@gmail.com> Date: Mon, 29 Jul 2013 09:38:13 +0200 Content-Transfer-Encoding: quoted-printable References: <14AE66FD-CA15-4A80-A761-DDF30552276B@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1283) X-OriginalArrivalTime: 29 Jul 2013 07:38:16.0059 (UTC) FILETIME=[966F64B0:01CE8C2E] Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 07:38:24 -0000 +1 I was beside Margaret when she sent the email, and fully agree with = her. I am ok with PANA but like EAP-in-PCP more. I found that EAP-in-PCP is criticized to be incomplete during the = discussion. But I believe the key point of the current discussion is to = clarify which type of solution is more suitable to PCP rather than which = work is more complete. Right?=20 Cheers Dacheng =D4=DA 2013-7-28=A3=AC=CF=C2=CE=E76:47=A3=AC Margaret Wasserman =D0=B4=B5=C0= =A3=BA >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>=20 >> >=20 > Yes. >=20 >> 2) Could you *live with* PANA? If not, state reason you would object. >>=20 >> >=20 > Yes. >=20 >> 3) If you said yes to both 1 and 2, but have a strong preference = between >> the two, which approach do you prefer and why? >>=20 >> . >=20 > I have a very strong preference for EAP-in-PCP for several reasons, = all of which I have presented in WG sessions. In summary, I believe = that adding PANA to the security stack adds complexity to the solution, = and I do not see any benefits that justify the added complexity. Also, = the "code reuse" benefit of using PANA and EAP is not, in my opinion, = any greater than the code reuse benefit of using EAP directly, as PCP = would require modifications to the PANA standards and modifications to = any available PANA code. >=20 > I continue to believe that both solutions could work, and that they = would provide the same level of security. >=20 > Margaret >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 From alper.yegin@yegin.org Mon Jul 29 00:58:14 2013 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 1957921F99FA for ; Mon, 29 Jul 2013 00:58:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3kJW0Okeft9 for ; Mon, 29 Jul 2013 00:58:09 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA4D21F9C01 for ; Mon, 29 Jul 2013 00:58:08 -0700 (PDT) Received: from [10.119.8.2] (178-32-45-6.ovh.net [178.32.45.6]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MX1My-1UXsA23V8W-00Vw8I; Mon, 29 Jul 2013 03:58:06 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> Date: Mon, 29 Jul 2013 10:58:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:V0cu66PXsyhXsHbCKhcJkOZhLUi4jK/M6CHzQa9feTj eOac18ph+fD2GaH659FVfniJAFkh2XXxkslsIcI/AIJhej+rAA tfgrIBbgMpBN5uVAxKmnDD3jmHXEpz5f0cQuMscxBl8DJC89tg Z6BZW1YuabHd5Vjdy/mtsrr/XPeDA6UeYj55s2y+JxzLemAWY/ JhzO82YfzxDeWCP/vs2fwNwAZLaw6aRvQiSJzhc5lXnLixGso0 wRTtcga/Om8/aQj67m1jE4BaLr2HGxtt+f4q5PVBrd/eNXpKVt sg/XaOh8ADq3J+nrUpvaOXLKblAaf3PSTDsCyJ6r4vwEPBOY88 pGiz7iwugiT4vEPJhihtEIp5iCn4vbR+8w+zI5b4O Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 07:58:14 -0000 Hi Ted, I cannot live with the possibility that IETF would not be reusing an = existing protocol, and instead reinvent it just because few folks insist = on their own solution. I cannot live with it, because=20 > it'd suck considerable amount of energy out of precious IETF cycles = while designing it now, and while maintaining/extending it later, > it'd suck considerable amount of energy out of architecture designers = when they need to deal with the integration of one more protocol, and = maintaining/extending it later, > it'd suck considerable amount of energy out of product developers when = they need to implement one more protocol, maintaining later too. I feel funny when I need to explain why reuse is a good thing on an IETF = mailing list. I think the questions that'd get a YES answer is a different one: Can = EAP-o-PCP made to work?=20 Yes, it can be.=20 Let me give another example to illustrate this:=20 If someone comes along with a new host configuration protocol, with = equivalent functionality as DHCP, without any substantial issue with = DHCP, can it be made to work? YES. Should IETF live with it? NO. Alper =20 On Jul 29, 2013, at 1:11 AM, Ted Lemon wrote: > On Jul 29, 2013, at 12:07 AM, Ted Lemon wrote: >> But none of the four people (you, Alper, Subir and Rafa) who just = asserted that EAP-in-PCP was something they could live with gave a = reason why they couldn't live with it. >=20 > Sorry, that should have been "could not live with". >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Mon Jul 29 01:07:56 2013 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 94F8721F9E28 for ; Mon, 29 Jul 2013 01:07:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgRnJYRfZ2ke for ; Mon, 29 Jul 2013 01:07:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id EE19621F9E01 for ; Mon, 29 Jul 2013 01:07:16 -0700 (PDT) Received: from [10.119.8.2] (178-32-45-6.ovh.net [178.32.45.6]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MbOcG-1Ul5hX01gK-00Jaky; Mon, 29 Jul 2013 04:07:02 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <51F5B548.6030406@deployingradius.com> Date: Mon, 29 Jul 2013 11:06:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <855ED432-F5A4-442C-B785-81B7505DDA7E@yegin.org> References: <1092757F-2853-4F2D-BF60-4C4E733AB3EC@um.es> <51F5B548.6030406@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:vSH3WbTETmqKYI7fxgB3OQlxTyrLAyaW5cdoRQeXus6 cVW5PyfQ7xh9Tw1vBw0z9CdAiwts5wiIJxbrkZqD7ewhj426vY 6Nofg012b1Jx1Bo8DZgtASilfCBJcQXtIftLhR7sgtmB2KY/aX vJSlpNcle0YDfER6yeuXOZ479g9Dw/0XsgbZn4qXMuECdZ8v7Z l21EkYiBoTdGhDVp3yIxXF8vBzu6mJa5mjRTBH37TqQU6+Lj/e hFzT/m/SoKFkpFBrLZEi1Ww23ZunZZvPh6gGs3/6ENjTYkeo6y r+I0uKF0V3T4gSozDINrktzMTHM5hkhlwfVcmTWxhOBIzLLboP ppG/+IXNG9HIlYcgiqanA20jY+c/Si/FkAm9Ipy4O Cc: pcp@ietf.org Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 08:07:56 -0000 Alan, I'll leave it to the open source implementors to respond, if they care. But let me point the following: PANA having two open-source implementations is just one of the signs of = maturity and completeness of the work. If you don't want to use those implementations, that's OK. Write your = own. This is not a sufficient justification to design a whole new = protocol from scratch. Alper On Jul 29, 2013, at 3:20 AM, Alan DeKok wrote: > Rafa Marin Lopez wrote: >> Let's avoid re-inventing the wheel. All the arguments I have seen in = favor of EAP-in-PCP have been based on pure speculation so far. >=20 > No. >=20 >> The same has happened with the arguments against PANA. And those = against PANA either they have been based on misconceptions about PANA or = simply the arguments were wrong. >=20 > No. >=20 >> Here in the list, we have clarified several times these points one by = one. >=20 > Partly. The arguments for PANA are (a) it's a standard, and (b) > random pointing to proprietary implementations. The arguments for > EAP-in-PCP have drawn on prior art, with statistics, facts, and = evidence. >=20 > The main reason to not use EAP-in-PCP is that it's not a standard use > of EAP. But EAP has been proven to work in practice in similar = situations. >=20 >> In any case, the fact is PANA is a RFC, another fact is that it has = running code (two open source implementations so far)=20 >=20 > Are these actually used anywhere? i.e. have even the authors used = them? >=20 > Last I looked, I couldn't even build them in a Posix environment. > They seemed to require a specific version of Linux with specific > libraries, etc. >=20 > They just don't look like production code used in a wide variety of > environments. >=20 > And to show my statistics: every new release of FreeRADIUS has 1M > downloads just from my web site. It's worked for nearly 15 years on > Linux, *BSD, Solaris, AIX, HPUX, Mac OSX, with a preliminary Windows > port. It's used by tier one Telcos, in loads reaching 100K+ > transactions per day, for over a decade. >=20 > Even ignoring the usage numbers, the open source PANA implementations > don't match that level of code quality, portability, or stability. I > would *not* recommend depending on them in any production environment. >=20 >> and another fact it has been easily integrated with PCP as we showed = in IETF 86. So, what else do we need? >=20 > The truth would help. >=20 > Alan DeKok. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Ted.Lemon@nominum.com Mon Jul 29 01:33:53 2013 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 F088621F91C4 for ; Mon, 29 Jul 2013 01:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSoXbgjj2J+y for ; Mon, 29 Jul 2013 01:33:47 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3315221F8449 for ; Mon, 29 Jul 2013 01:33:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUfYo5PVTGCbStya5ypqRklrn6e7bmxxQ@postini.com; Mon, 29 Jul 2013 01:33:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A83961B825D for ; Mon, 29 Jul 2013 01:33:40 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5EC5B19006B; Mon, 29 Jul 2013 01:33:39 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 01:33:39 -0700 From: Ted Lemon To: Alper Yegin Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAJUru4wAHNf5gAADaTBMP//n9GAgAABO4CAAKPlgIAACfWA Date: Mon, 29 Jul 2013 08:33:38 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775233C85@mbx-01.win.nominum.com> References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B113365B083594AAC59074A30201C5B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 08:33:54 -0000 On Jul 29, 2013, at 9:58 AM, Alper Yegin wrote: > I cannot live with the possibility that IETF would not be reusing an exis= ting protocol, and instead reinvent it just because few folks insist on the= ir own solution. The working group can never reach consensus if we use this as the basis for= making consensus decisions. The reason DHCP hasn't been replaced by something else is not that nobody's= tried. It's that nobody's produced something better. There have been n= umerous attempts to replace DHCP. Some have produced useful results; none= have eliminated the demand for DHCP. For example, SLAAC replaces part of DHCP functionality, and it is popular b= ecause of the ways it is _better_ than DHCP. DNS-SD replaces parts of DHC= P, because it solves the problem _better_ in a specific domain. If I were= to have said "we shouldn't do DNS-SD because you can do that with DHCP," t= his would not have been constructive, and if I had gotten my way, it would = have resulted in a bad outcome. So this is why I am pressing you to state a technical objection if you have= one, rather than taking the architectural issue as a technical objection, = which it is not. From alper.yegin@yegin.org Mon Jul 29 01:55:01 2013 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 314CB21E809A for ; Mon, 29 Jul 2013 01:54:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UlZIXZxetjS for ; Mon, 29 Jul 2013 01:54:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id CA20921E8094 for ; Mon, 29 Jul 2013 01:54:36 -0700 (PDT) Received: from [10.119.8.2] (178-32-45-6.ovh.net [178.32.45.6]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M7p1M-1U8kr52uKe-00wFkv; Mon, 29 Jul 2013 04:54:31 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775233C85@mbx-01.win.nominum.com> Date: Mon, 29 Jul 2013 11:54:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775233C85@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:rWT/z9DOwHuBwHlvl1pxjz7DqfcVMsJ2/peil3bPedT 1G43bszgXTMRzOmBSLKzOBdzygwxjvo+038e0iLSTMtoilHyb5 WIrIPLYBO3m8OnZLWf4t/qyMlZo4ExLZYV0UFwUjnpnS/9xzit UWNOR4MujH0L5yNAgmH8fI/krsLO1+x3u9jYbwmaAQ8KyTWyCe tx5iC8kZHn5rBhrecZy/JpkdHrkjQQx9WAn7j8hEzgBJi/xCKm 8fy5eMcxQJqD3wBEWEsZQbNyDsThpAliem4+gF+Tgc9fz27gj1 l5gOVeGKQ+nwHdPVsvqfewJzK7qSUzna1p7hpmOGwAE3QyUuZf NCYwJ4NCHA0jeAM1cA+FF/vSfnpXr8Zpx6+/ECAlX Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 08:55:01 -0000 Ted, On Jul 29, 2013, at 11:33 AM, Ted Lemon wrote: > On Jul 29, 2013, at 9:58 AM, Alper Yegin = wrote: >> I cannot live with the possibility that IETF would not be reusing an = existing protocol, and instead reinvent it just because few folks insist = on their own solution. >=20 > The working group can never reach consensus if we use this as the = basis for making consensus decisions. >=20 > The reason DHCP hasn't been replaced by something else is not that = nobody's tried. It's that nobody's produced something better. There = have been numerous attempts to replace DHCP. Some have produced useful = results; none have eliminated the demand for DHCP. >=20 > For example, SLAAC replaces part of DHCP functionality, and it is = popular because of the ways it is _better_ than DHCP. DNS-SD replaces = parts of DHCP, because it solves the problem _better_ in a specific = domain. If I were to have said "we shouldn't do DNS-SD because you can = do that with DHCP," this would not have been constructive, and if I had = gotten my way, it would have resulted in a bad outcome. >=20 Obviously those solutions made a technical case for getting into the = IETF system.=20 If they were doing what DHCP did, nothing more, nothing less, then = they'd be rejected. > So this is why I am pressing you to state a technical objection if you = have one, rather than taking the architectural issue as a technical = objection, which it is not. >=20 Someone brings in a proposal draft-X. I look at it and state that RFC-Y solves that problem. I do lengthy analysis and discussions, and conclude that proponents of = draft-X couldn't demonstrate why draft-X is still needed. So, I state draft-X is not needed. IMHO, this is a technical objection. And whether it's called technical or not, if this line of discussion = were not respected in deciding what IETF gets to do, then what's to = prevent proliferation of functional clones of IETF standards, within = IETF? Whatever it is, then maybe we should be asking that question too. Alper From margaretw42@gmail.com Mon Jul 29 02:23:11 2013 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 15B2521E808F for ; Mon, 29 Jul 2013 02:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6TG4Ut9nybL for ; Mon, 29 Jul 2013 02:23:09 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2989221E808B for ; Mon, 29 Jul 2013 02:22:57 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id lb1so5634428pab.26 for ; Mon, 29 Jul 2013 02:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=/NN/dkGwYFXxsab+xu3XN4+EGWXYeynH9DwqQ+eXXrc=; b=i7n8/j/larVQLxLeoI3VE5tX8kNHwXYNvHhLy1ZJYkEFKCD/iNq/tLZNZZrUgf6Nh4 5lKQ/N/ZYKta2NarUHmYCYK9a9PVLxu0/4B7kc+ExKIAuKVA3KaOLqDSn7CcGXwmHOTe tRY12DkLnhVmD+N6KrtzTv89aERkzgSxhbixbyzT5MCy2VdxVgb/on99GC69BKcyWV0J 5xWjwhevXBSseWyEMryrMGtNjsINUUEQ6RX5AaKQZaMoMh5kThBhu+SnvCU4iekHNvKh 8Xv0UHG6OOZySNTkf3FULNWBr3BFSct1zsRNCABnob+AF5hCEjiKmstaBKuiU11ZpArR OUCQ== X-Received: by 10.68.137.8 with SMTP id qe8mr67329020pbb.100.1375089775623; Mon, 29 Jul 2013 02:22:55 -0700 (PDT) Received: from ?IPv6:2001:df8::64:84e4:6677:728d:cf03? ([2001:df8:0:64:84e4:6677:728d:cf03]) by mx.google.com with ESMTPSA id om2sm18297044pbc.30.2013.07.29.02.22.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 02:22:54 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-B65DEF39-C03D-4973-8AED-A38603D590C7 Content-Transfer-Encoding: 7bit Message-Id: <2C4BDE35-810E-4552-A000-0305133548AC@gmail.com> X-Mailer: iPad Mail (10A523) From: Margaret Wasserman Date: Mon, 29 Jul 2013 11:22:51 +0200 To: Subir Das Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 09:23:12 -0000 --Apple-Mail-B65DEF39-C03D-4973-8AED-A38603D590C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subir, The specification for the use of PANA with PCP is also incomplete. We would= need to make a fairly major decision about _how_ to use PANA with PCP (side= -by-side or encaps) both of which have pluses and minuses, because PANA was n= ot designed to be a general-purpose authentication layer with upper layers. Also, we will need to define what parts of PANA are/are not used with PCP, a= nd make sure that we specify the use of PANA w/PCP in a way that does not co= nflict with the use of PANA on the same device for authenticating network ac= cess (as that is the purpose of PANA). I believe it is possible to do this work, just as I believe it is possible t= o specify a direct PCP to EAP mapping. I honestly think it will be more wor= k to specify the PANA solution, and that the eventual implementation will be= more complex. I feel uncomfortable about people stating that they can't "live with" EAP-ov= er-PCP because they just happen to like PANA better. If there is an actual t= echnical reason why any of you believe that an EAP-over-PCP solution will no= t work, could you state it? If we are claiming we "can't live with" things that will work, simply becaus= e we prefer the other option, I would like to change my response accordingly= . Margaret Sent from my iPad On Jul 28, 2013, at 11:06 PM, Subir Das wrote: > 1) Could you *live with* EAP-in-PCP? If not, state reason you would object= . >=20 > No. IMO, the current specification is not complete. Assume that the draf= t is modified and it satisfies the PCP requirements, my understanding is t= hat it will end up with another protocol very similar to PANA. What would be= the benefit of doing the similar work and develop yet another EAP lower lay= er when we have already an IETF protocol that satisfies all the PCP requirem= ents? It was shown that PANA works with PCP without any modifications of ex= isting PANA RFC. The results were presented in the last IETF. So my points= are: existing RFC and running code. Moreover, the integration is simple. > =20 > N.B.: PANA is currently under deployment in a major vertical market.=20 >=20 > 2) Could you *live with* PANA? If not, state reason you would object.=20 >=20 > Yes. >=20 > Thanks, > -Subir=20 >=20 >=20 > On Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler wrote= : >> The WG has discussed two approaches for using EAP with PCP: >> direct EAP-in-PCP vs using PANA. >>=20 >> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP >> and 10 or 11 for PANA. There was significant confusion/disagreement >> around requirements and proposed solutions at that time. >>=20 >> At IETF 85, we again polled the room and got a different result, this >> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however, >> still significant confusion/disagreement around requirements and >> proposed solutions. >>=20 >> Since IETF 85, we have made lots of progress on getting agreement >> on the requirements, and draft-reddy-pcp-auth-req now seems to be >> relatively stable without significant areas of disagreement known. >> Discussion may of course continue if new issues are raised but we >> believe any additional changes are unlikely to affect people's >> position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA. >>=20 >> The general sense of the WG also seems to be that either approach could b= e >> made to fit the requirements, so we believe it is now time for us to >> determine consensus (draft-resnick-on-consensus is a great read) >> on the approach question. We know many folks would just like to >> make a decision and move on. >>=20 >> Hence the chairs would like to ask the WG which solution direction the >> WG should pursue in meeting the requirements. Please state your >> recommendation on this thread, preferably along with your rationale. >> Avoid responding on this thread to others' rationale, use a separate >> thread as needed. >>=20 >> To help us judge consensus, please use the template below and >> respond by SUNDAY JULY 28. >>=20 >> -Dave and Reinaldo >>=20 >> --- >>=20 >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would objec= t. >>=20 >> >>=20 >> 2) Could you *live with* PANA? If not, state reason you would object. >>=20 >> >>=20 >> 3) If you said yes to both 1 and 2, but have a strong preference between >> the two, which approach do you prefer and why? >>=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-B65DEF39-C03D-4973-8AED-A38603D590C7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Subir,

The specification for the use of PANA with PCP is also incomplete. &= nbsp;We would need to make a fairly major decision about _how_ to use PANA w= ith PCP (side-by-side or encaps) both of which have pluses and minuses, beca= use PANA was not designed to be a general-purpose authentication layer with u= pper layers.

Also, we will need to define what part= s of PANA are/are not used with PCP, and make sure that we specify the use o= f PANA w/PCP in a way that does not conflict with the use of PANA on the sam= e device for authenticating network access (as that is the purpose of PANA).=

I believe it is possible to do this work, just as I= believe it is possible to specify a direct PCP to EAP mapping.  I hone= stly think it will be more work to specify the PANA solution, and that the e= ventual implementation will be more complex.

I feel= uncomfortable about people stating that they can't "live with" EAP-over-PCP= because they just happen to like PANA better. If there is an actual technic= al reason why any of you believe that an EAP-over-PCP solution will not work= , could you state it?

If we are claiming we "can't l= ive with" things that will work, simply because we prefer the other option, I= would like to change my response accordingly.

Marg= aret



Sent from my iPad

On Jul= 28, 2013, at 11:06 PM, Subir Das <subirdas21@gmail.com> wrote:

1) Could you *live with* EAP-in-PCP? If not, sta= te reason you would object.

No. IMO, the current  specification i= s not complete.  Assume that the draft is modified and i= t satisfies  the PCP requirements, my understanding  is t= hat it will end up with another protocol very similar to PANA. Wha= t would be the benefit of doing the similar work and develop y= et another EAP lower layer when we have already an IETF protocol t= hat satisfies all the PCP requirements?  It was shown that PA= NA works with PCP without any modifications of existing PANA R= FC. The results were presented in the last IETF.   So my poin= ts are: existing RFC and running code. Moreover, the integration is simple. <= /div>
 
N.B.: PANA is currently under deployment in a major ve= rtical market. 

 2) Could you *live with* PANA? If n= ot, state reason you would object.

   Yes.

&nb= sp;Thanks,
-Subir


On= Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler <dthaler@microsoft.com>= ; wrote:
The WG has discussed two approaches for using E= AP with PCP:
direct EAP-in-PCP vs using PANA.

At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP
and 10 or 11 for PANA. There was significant confusion/disagreement
around requirements and proposed solutions at that time.

At IETF 85, we again polled the room and got a different result, this
time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however,
still significant confusion/disagreement around requirements and
proposed solutions.

Since IETF 85, we have made lots of progress on getting agreement
on the requirements, and draft-reddy-pcp-auth-req now seems to be
relatively stable without significant areas of disagreement known.
Discussion may of course continue if new issues are raised but we
believe any additional changes are unlikely to affect people's
position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA.

The general sense of the WG also seems to be that either approach could be made to fit the requirements, so we believe it is now time for us to
determine consensus (draft-resnick-on-consensus is a great read)
on the approach question. We know many folks would just like to
make a decision and move on.

Hence the chairs would like to ask the WG which solution direction the
WG should pursue in meeting the requirements. Please state your
recommendation on this thread, preferably along with your rationale.
Avoid responding on this thread to others' rationale, use a separate
thread as needed.

To help us judge consensus, please use the template below and
respond by SUNDAY JULY 28.

-Dave and Reinaldo

---

1) Could you *live with* EAP-in-PCP? If not, state reason you would object.<= br>
    <NO and state reason, or YES>

2) Could you *live with* PANA? If not, state reason you would object.

    <NO and state reason, or YES>

3) If you said yes to both 1 and 2, but have a strong preference between
= the two, which approach do you prefer and why?

    <EAP-in-PCP, or PANA>.  <state reason>
_______________________________________________
pcp mailing list
pcp@ietf.org
http= s://www.ietf.org/mailman/listinfo/pcp

____________________= ___________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/lis= tinfo/pcp
= --Apple-Mail-B65DEF39-C03D-4973-8AED-A38603D590C7-- From margaretw42@gmail.com Mon Jul 29 02:27:28 2013 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 3D09C11E80EC for ; Mon, 29 Jul 2013 02:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saQe7NQdtnjH for ; Mon, 29 Jul 2013 02:27:27 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4F91D11E80F1 for ; Mon, 29 Jul 2013 02:27:15 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id jh10so5656359pab.17 for ; Mon, 29 Jul 2013 02:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=0y6BOtfunTkieu2NzQzidnZNfp9yIk13AXucXpA/MAw=; b=okDjDsyLDE9MRDPGF6/hBTQiu0cltR5S2SC2Eyeaw/G8tiG0PuKclFQGPvZQdmOqwz FVeJp7ML5QRGcCqsYsma3+rR3vzK9jqUOzvzoEXrfdwkeVHcRnwKgW3d7Nn6/gHnYbey BbRdtRi0BZG0jtAWMKIh9i5eU3RkJPVbLNEqpK6hFFWAiDFHwkrzjpOFijdJW7tLJ/DZ SiFXGhR1tgADMmh/RF5xZEzH1fNcEkAttupDPD1gyun5/yVkXe9UmIT4cU9Vn9PtgWup /+xOjeCENpTIRjqwrTjtGC15w9DarRs54KDJSih/BBKbnp450Tbf08j/7k1HSqX4ewcZ zZSg== X-Received: by 10.66.155.163 with SMTP id vx3mr67231086pab.67.1375090034948; Mon, 29 Jul 2013 02:27:14 -0700 (PDT) Received: from ?IPv6:2001:df8::64:84e4:6677:728d:cf03? ([2001:df8:0:64:84e4:6677:728d:cf03]) by mx.google.com with ESMTPSA id xl3sm75891302pbb.17.2013.07.29.02.27.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 02:27:14 -0700 (PDT) References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <359E98A4-AAC7-438E-A39A-0A4EBD70FB54@gmail.com> X-Mailer: iPad Mail (10A523) From: Margaret Wasserman Date: Mon, 29 Jul 2013 11:27:11 +0200 To: Alper Yegin Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 09:27:29 -0000 Alper, The problem with your argument is that PANA is _not_ a general-purpose authe= ntication protocol, EAP is. One solution reuses EAP directly, and the other= incorporates PANA and EAP. Both of them reuse existing security standards.= Including PANA between EAP and PCP is roughly akin to including UDP in an IP= over IP tunnel. There are cases where it is valuable to do so, and cases w= here UDP would provide overhead and no value. It doesn't make sense to incl= ude UDP between IP and IP _just because_ it is a standard. In my opinion, P= ANA does not add sufficient value to be worth the overhead of including it. = Your opinion may differ from mine. Margaret Sent from my iPad On Jul 29, 2013, at 9:58 AM, Alper Yegin wrote: > Hi Ted, >=20 > I cannot live with the possibility that IETF would not be reusing an exist= ing protocol, and instead reinvent it just because few folks insist on their= own solution. > I cannot live with it, because=20 >> it'd suck considerable amount of energy out of precious IETF cycles while= designing it now, and while maintaining/extending it later, >> it'd suck considerable amount of energy out of architecture designers whe= n they need to deal with the integration of one more protocol, and maintaini= ng/extending it later, >> it'd suck considerable amount of energy out of product developers when th= ey need to implement one more protocol, maintaining later too. >=20 > I feel funny when I need to explain why reuse is a good thing on an IETF m= ailing list. >=20 > I think the questions that'd get a YES answer is a different one: Can EAP-= o-PCP made to work?=20 > Yes, it can be.=20 >=20 >=20 > Let me give another example to illustrate this:=20 >=20 > If someone comes along with a new host configuration protocol, with equiva= lent functionality as DHCP, without any substantial issue with DHCP, can it b= e made to work? > YES. > Should IETF live with it? > NO. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Jul 29, 2013, at 1:11 AM, Ted Lemon wrote: >=20 >> On Jul 29, 2013, at 12:07 AM, Ted Lemon wrote: >>> But none of the four people (you, Alper, Subir and Rafa) who just assert= ed that EAP-in-PCP was something they could live with gave a reason why they= couldn't live with it. >>=20 >> Sorry, that should have been "could not live with". >>=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 Jul 29 02:28:18 2013 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 B899611E80F6 for ; Mon, 29 Jul 2013 02:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgxE8wooxkGM for ; Mon, 29 Jul 2013 02:28: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 50DB421F9A71 for ; Mon, 29 Jul 2013 02:28:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 8FA1C18D080; Mon, 29 Jul 2013 11:28:08 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 75CC1238055; Mon, 29 Jul 2013 11:28:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 29 Jul 2013 11:28:08 +0200 From: To: Dan Wing Date: Mon, 29 Jul 2013 11:28:05 +0200 Thread-Topic: [pcp] differentiating traffic, draft-wing-pcp-flowdata Thread-Index: Ac6KPfm9fRXHV47OQGCDoT+Bk35P3AB/yv+g Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E8352F@PUEXCB1B.nanterre.francetelecom.fr> References: <0D5D4049-2847-46C8-BD0D-8C6CF6BB1AF0@cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E831B6@PUEXCB1B.nanterre.francetelecom.fr> <2653EA58-AA3B-4F65-B4BE-785342C7A3F1@cisco.com> In-Reply-To: <2653EA58-AA3B-4F65-B4BE-785342C7A3F1@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: 2013.5.21.113319 Cc: "pcp@ietf.org" Subject: Re: [pcp] differentiating traffic, draft-wing-pcp-flowdata 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, 29 Jul 2013 09:28:19 -0000 Hi Dan, For the DSCP case, please not I'm referring to intra-domain cases not inter= -domain ones. The cases I have in mind does not require the involvement of = the end host, but the following: * a PCP client under the responsibility of the service provider. * a managed CPE DSCP value re-setting and OSSifying dscp setting are not issues for those c= ases.=20 I will re-spin the dscp pcp option to further clarify the usage. Cheers, Med >-----Message d'origine----- >De=A0: Dan Wing [mailto:dwing@cisco.com] >Envoy=E9=A0: vendredi 26 juillet 2013 22:23 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] differentiating traffic, draft-wing-pcp-flowdata > > >On Jul 26, 2013, at 1:27 AM, mohamed.boucadair@orange.com wrote: > >> Hi Dan, >> >> This is indeed an interesting piece of work...which has also its >drawbacks;-) See the comment I made about the generic framework here: >http://www.ietf.org/mail-archive/web/int-area/current/msg03627.html. > >I am not involved with the generic framework. But reading your objections >in that post, the primary objection seemed to be application developers >won't signal their flow characteristics. To do such signaling, such >signaling would need to provide value to the application developer or to >the end user experience. That is, to do such signaling, the signaling has >to solve a real problem. > >I believe multiple flows contending for access bandwidth is a real problem= . > >If it is not a problem (that is, sufficient bandwidth is always available)= , >then I agree there is no value or purpose in differentiating flows over >that network. However, every year that I hear someone proclaim "we have >enough resources", that has only been true for a year or two -- no matter >if the resources are CPU cores, memory, bandwidth, network latency, or dis= k >space. > >> Targeting a perfect solution which does not suffer from limitations is >not viable IMHO. This is why I'm seeing this work as a useful tool to be >added to the existing toolkit. This work opens a new perspective which is >worth to be considered by the WG. > >Thanks for your positive feedback. > >> In addition to the flowdata work, I'm also suggesting to consider other >work items such as: >> >> * Use PCP to enforce DSCP remarking policies >(http://tools.ietf.org/html/draft-boucadair-pcp-extensions-03#section-3). >This is useful when the PCP Client is operated by the provider. This is an >intra-domain case. >> * Use PCP to discover the DSCP marking to be used for outbound packets: >this option can be used with or without FLOWDATA option. The typical use >case is where the PCP client is embedded in a CPE (not the host) and >various marking policies are used at the access network. This is an intra- >domain case. > >Signaling DSCP is not something described in draft-wing-pcp-flowdata -- on >purpose. > >-d > >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Dan >>> Wing >>> Envoy=E9 : vendredi 26 juillet 2013 00:44 >>> =C0 : pcp@ietf.org >>> Objet : [pcp] differentiating traffic, draft-wing-pcp-flowdata >>> >>> Many networks have insufficient access bandwidth and it is desirable to >>> handle flows differently over that access link based on the flow's need= s >>> (high bandwidth, low loss, high delay) or if the flow is to a certain >>> device or certain user ((living room television, tablet, mom/dad/kid). >>> Hosts don't have a way to prioritize flows downstream (towards the host= ) >>> and have poor capability to prioritize flows upstream, especially among >the >>> various hosts on the network. Various solutions to this problem have >been >>> developed over the years (DSCP, RSVP, NSIS) but have drawbacks. >>> >>> I hope the problem described above resonates with people on this list. >If >>> so, read on. >>> >>> >>> In draft-wing-pcp-flowdata we propose a solution: the host describes >the >>> flow characteristics to the network and the network indicates its >>> (in)ability to accommodate the flow. That flow description can be used >by >>> the default network, or propagated along the network. For example in a >>> home network the flow description can propagate from in-home CPE router >to >>> the ISP's access router, and in an enterprise network the flow >description >>> can propagate within the enterprise network and up to the ISP's access >>> router. When the flow characteristics are communicated to both sides o= f >a >>> resource-constrained link, the routers on both end can provide differen= t >>> packet forwarding treatment to the flow. >>> >>> The mechanism draft-wing-pcp-flowdata brings some advantages: >>> >>> * incrementally deployable. This can be implemented entirely within a >>> subscriber's network without participation of their ISP, providing some >>> value (but of course not as much value as being deployed by the ISP's >>> access router). Similarly, this can be implemented on the ISP's router >and >>> the host could signal directly to that ISP's router without needing >support >>> of the intermediate network. >>> * adaptive bit rate applications can improve user experience by avoidin= g >>> attempts to exceed the network's upper bandwidth limit >>> * traffic differentiation can be per-"event" (e.g., streaming TV of the >>> Olympics, VoIP call with an important customer), in addition to more >>> traditional per-user or per-device or per-application. >>> >>> Details are in http://tools.ietf.org/html/draft-wing-pcp-flowdata. >>> >>> Comments welcome. >>> -d >>> >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp From achatz@forthnetgroup.gr Mon Jul 29 02:53:11 2013 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 D0B4421F9F20 for ; Mon, 29 Jul 2013 02:53:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6GCpMp5p7WG for ; Mon, 29 Jul 2013 02:53:05 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id C65A521F9F08 for ; Mon, 29 Jul 2013 02:52:58 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r6T9qu0S014495 for ; Mon, 29 Jul 2013 12:52:56 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r6T9quWZ009940 for ; Mon, 29 Jul 2013 12:52:56 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-02.forthnet.gr (8.14.4/8.14.4) with ESMTP id r6T9qtDh029325; Mon, 29 Jul 2013 12:52:56 +0300 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <51F63B76.2000103@forthnetgroup.gr> Date: Mon, 29 Jul 2013 12:52:54 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19 MIME-Version: 1.0 To: "pcp@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 09:53:12 -0000 Dave Thaler wrote on 15/07/2013 03:33: > > 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. > > YES > 2) Could you *live with* PANA? If not, state reason you would object. > > YES > 3) If you said yes to both 1 and 2, but have a strong preference between > the two, which approach do you prefer and why? > > . EAP-in PCP Talking strictly as an operator, i first heard of PANA through this WG (when the initial talks about pcp auth were happening). I'm not saying PANA won't do the job (maybe better in some areas), i'm just saying that i feel more comfortable working with something i have some experience with, regardless the possible scenario that PANA's learning curve might end up less steep than expected. Whatever the vendors decide to implement it's fine by me, as long as there is interoperability between all of them. Operators need something to work. -- Tassos From subirdas21@gmail.com Mon Jul 29 03:00:13 2013 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 8F5F421F9BF0 for ; Mon, 29 Jul 2013 03:00:13 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLm7zdT9HuzV for ; Mon, 29 Jul 2013 03:00:11 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBA521F9F6F for ; Mon, 29 Jul 2013 03:00:08 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id uz6so5342913obc.3 for ; Mon, 29 Jul 2013 03:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bz/6nnXqb7AztjJg3DXytcfWZ72g2JNarmX6bMVcld4=; b=pl4M9V5UprqjoDDrNB8/zrj5VPoyl2bBxMu9SxJ4zVQ/357ideIopuKqtF1HMABagi bc8NJ7odSYxh85k6n2zQZ/gEKVax0KMzn06P7wcHTvACnigoKfi5TyT8qSNv5/2UW8Ev NJ1wIRqPTk4tBAJHd0s02f876qcjPFN2yRu7kFQrCNaHtV5Oll/yU35kuaqYnYBuHBnR pRpgeFdcmWlk3vgwisB7gzOeomZUoaqgR7MqoX/jTS4TLgbwqrOJlQ5JjWfs5rs09lf9 TAoKRYBZWnHhcmbUD9j35cKZREpWaC8e7y+uvZIZQ0qrDC2OQhG2OBv13bQ9TBB35xoX ySRQ== MIME-Version: 1.0 X-Received: by 10.43.11.69 with SMTP id pd5mr334544icb.62.1375092008021; Mon, 29 Jul 2013 03:00:08 -0700 (PDT) Received: by 10.43.172.8 with HTTP; Mon, 29 Jul 2013 03:00:07 -0700 (PDT) In-Reply-To: <2C4BDE35-810E-4552-A000-0305133548AC@gmail.com> References: <2C4BDE35-810E-4552-A000-0305133548AC@gmail.com> Date: Mon, 29 Jul 2013 06:00:07 -0400 Message-ID: From: Subir Das To: Margaret Wasserman Content-Type: multipart/alternative; boundary=bcaec50fe46fabf7fd04e2a38e2f Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 10:00:13 -0000 --bcaec50fe46fabf7fd04e2a38e2f Content-Type: text/plain; charset=ISO-8859-1 Margaret, We implemented the side-by-side approach and found that it does not require any change to PANA RFC and it was relatively simple. Of course we need to define a PANA use case for PCP if that is what you meant by additional specification. It would be good to have a discussion on where you think the complexities are and the conflicts between network access authentication and PCP authentication using PANA. We have not implemented direct EAP over PCP. If you have an implementation and it satisfies the PCP requirements, can we get a copy? It would be then easier for us to compare. Thanks, -Subir On Mon, Jul 29, 2013 at 5:22 AM, Margaret Wasserman wrote: > > Subir, > > The specification for the use of PANA with PCP is also incomplete. We > would need to make a fairly major decision about _how_ to use PANA with PCP > (side-by-side or encaps) both of which have pluses and minuses, because > PANA was not designed to be a general-purpose authentication layer with > upper layers. > > Also, we will need to define what parts of PANA are/are not used with PCP, > and make sure that we specify the use of PANA w/PCP in a way that does not > conflict with the use of PANA on the same device for authenticating network > access (as that is the purpose of PANA). > > I believe it is possible to do this work, just as I believe it is possible > to specify a direct PCP to EAP mapping. I honestly think it will be more > work to specify the PANA solution, and that the eventual implementation > will be more complex. > > I feel uncomfortable about people stating that they can't "live with" > EAP-over-PCP because they just happen to like PANA better. If there is an > actual technical reason why any of you believe that an EAP-over-PCP > solution will not work, could you state it? > > If we are claiming we "can't live with" things that will work, simply > because we prefer the other option, I would like to change my response > accordingly. > > Margaret > > > > Sent from my iPad > > On Jul 28, 2013, at 11:06 PM, Subir Das wrote: > > 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. > > No. IMO, the current specification is not complete. Assume that the > draft is modified and it satisfies the PCP requirements, my understanding > is that it will end up with another protocol very similar to > PANA. What would be the benefit of doing the similar work and develop yet > another EAP lower layer when we have already an IETF protocol > that satisfies all the PCP requirements? It was shown that PANA works with > PCP without any modifications of existing PANA RFC. The results were > presented in the last IETF. So my points are: existing RFC and running > code. Moreover, the integration is simple. > > N.B.: PANA is currently under deployment in a major vertical market. > > 2) Could you *live with* PANA? If not, state reason you would object. > > Yes. > > Thanks, > -Subir > > > On Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler wrote: > >> The WG has discussed two approaches for using EAP with PCP: >> direct EAP-in-PCP vs using PANA. >> >> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP >> and 10 or 11 for PANA. There was significant confusion/disagreement >> around requirements and proposed solutions at that time. >> >> At IETF 85, we again polled the room and got a different result, this >> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however, >> still significant confusion/disagreement around requirements and >> proposed solutions. >> >> Since IETF 85, we have made lots of progress on getting agreement >> on the requirements, and draft-reddy-pcp-auth-req now seems to be >> relatively stable without significant areas of disagreement known. >> Discussion may of course continue if new issues are raised but we >> believe any additional changes are unlikely to affect people's >> position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA. >> >> The general sense of the WG also seems to be that either approach could be >> made to fit the requirements, so we believe it is now time for us to >> determine consensus (draft-resnick-on-consensus is a great read) >> on the approach question. We know many folks would just like to >> make a decision and move on. >> >> Hence the chairs would like to ask the WG which solution direction the >> WG should pursue in meeting the requirements. Please state your >> recommendation on this thread, preferably along with your rationale. >> Avoid responding on this thread to others' rationale, use a separate >> thread as needed. >> >> To help us judge consensus, please use the template below and >> respond by SUNDAY JULY 28. >> >> -Dave and Reinaldo >> >> --- >> >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would >> object. >> >> >> >> 2) Could you *live with* PANA? If not, state reason you would object. >> >> >> >> 3) If you said yes to both 1 and 2, but have a strong preference between >> the two, which approach do you prefer and why? >> >> . >> >> _______________________________________________ >> 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 > > --bcaec50fe46fabf7fd04e2a38e2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Margaret,
We=A0 implemented the side-by-sid= e approach and found that it does not require any change to PANA RFC and it= was relatively=A0simple.=A0Of course we need to define a PANA use case for= PCP if that is what you meant by additional specification. It would be goo= d to have a discussion on where you=A0think the complexities are and the co= nflicts between network access authentication and PCP authentication using = PANA.=A0
=A0
We have not implemented direct EAP over PCP.=A0If you ha= ve an implementation and it satisfies the PCP requirements, can we get a co= py? It would be=A0then easier for us to compare.=A0
=A0
Thanks,
-Subir =A0
=A0

On Mon, Jul 29, 2013 at 5:22 AM, Margaret Wasse= rman <margaretw42@gmail.com> wrote:

Subir,=

The specification for the use of PANA with PCP is= also incomplete. =A0We would need to make a fairly major decision about _h= ow_ to use PANA with PCP (side-by-side or encaps) both of which have pluses= and minuses, because PANA was not designed to be a general-purpose authent= ication layer with upper layers.

Also, we will need to define what parts of PANA are/are= not used with PCP, and make sure that we specify the use of PANA w/PCP in = a way that does not conflict with the use of PANA on the same device for au= thenticating network access (as that is the purpose of PANA).

I believe it is possible to do this work, just as I bel= ieve it is possible to specify a direct PCP to EAP mapping. =A0I honestly t= hink it will be more work to specify the PANA solution, and that the eventu= al implementation will be more complex.

I feel uncomfortable about people stating that they can= 't "live with" EAP-over-PCP because they just happen to like = PANA better. If there is an actual technical reason why any of you believe = that an EAP-over-PCP solution will not work, could you state it?

If we are claiming we "can't live with" t= hings that will work, simply because we prefer the other option, I would li= ke to change my response accordingly.

Margaret



Sent from my iPad
<= div>
On Jul 28, 2013, at 11:06 PM, Subir Das <subirdas21@gmail.com> wrote:
<= br>
1) Could you *li= ve with* EAP-in-PCP? If not, state reason you would object.

No. IMO,= the current=A0 specification is not complete.=A0=A0Assume that=A0the draft= is modified and=A0it satisfies=A0=A0the PCP requirements, my=A0understandi= ng =A0is that it will end up with=A0another protocol very similar to PANA.= =A0What=A0would be the benefit of doing the=A0similar work and=A0develop ye= t another=A0EAP lower layer when=A0we have already an IETF protocol that=A0= satisfies all the PCP requirements?=A0=A0It was shown that PANA works with = PCP without=A0any=A0modifications of=A0existing PANA RFC.=A0The results wer= e presented in the last IETF.=A0=A0 So my points are: existing RFC and runn= ing code. Moreover, the integration is simple.
=A0
N.B.: PANA is currently under deployment in a major vert= ical market.=A0

=A02) Could you *live with* PANA? If not, st= ate reason you would object.

=A0=A0=A0Yes.

=A0Thanks,
<= div>-Subir


O= n Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler <dthaler@microsoft.com> wrote:
The WG has discussed two approaches for using EAP with PCP= :
direct EAP-in-PCP vs using PANA.

At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP
and 10 or 11 for PANA. There was significant confusion/disagreement
around requirements and proposed solutions at that time.

At IETF 85, we again polled the room and got a different result, this
time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however,
still significant confusion/disagreement around requirements and
proposed solutions.

Since IETF 85, we have made lots of progress on getting agreement
on the requirements, and draft-reddy-pcp-auth-req now seems to be
relatively stable without significant areas of disagreement known.
Discussion may of course continue if new issues are raised but we
believe any additional changes are unlikely to affect people's
position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA.

The general sense of the WG also seems to be that either approach could be<= br> made to fit the requirements, so we believe it is now time for us to
determine consensus (draft-resnick-on-consensus is a great read)
on the approach question. We know many folks would just like to
make a decision and move on.

Hence the chairs would like to ask the WG which solution direction the
WG should pursue in meeting the requirements. Please state your
recommendation on this thread, preferably along with your rationale.
Avoid responding on this thread to others' rationale, use a separate thread as needed.

To help us judge consensus, please use the template below and
respond by SUNDAY JULY 28.

-Dave and Reinaldo

---

1) Could you *live with* EAP-in-PCP? If not, state reason you would object.=

=A0=A0=A0 <NO and state reason, or YES>

2) Could you *live with* PANA? If not, state reason you would object.

=A0=A0=A0 <NO and state reason, or YES>

3) If you said yes to both 1 and 2, but have a strong preference between the two, which approach do you prefer and why?

=A0=A0=A0 <EAP-in-PCP, or PANA>.=A0 <state reason>

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

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

--bcaec50fe46fabf7fd04e2a38e2f-- From repenno@cisco.com Mon Jul 29 03:22:43 2013 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 29C0921F9E24 for ; Mon, 29 Jul 2013 03:22:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seosmUKjSkLj for ; Mon, 29 Jul 2013 03:22:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D790921F9D6F for ; Mon, 29 Jul 2013 03:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=604; q=dns/txt; s=iport; t=1375093353; x=1376302953; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=QrYZcBXiM/PNadK22bqX7jweBuM9p3nbmv7E66WOw+c=; b=ksa8gPftHev/xM0vkB4bFPUUFzHukPlxBKw6eNfjF0/xQR6551i43EU/ GmDZZF3qTeM829TiaLpwLWOkG8j16Mr8cO9GgE3Yks2kL0VFMYfw3kn3H R6YQM3IhvHkW6A0njSPVpE9zb9nCrNaN/iA6co9KNbPwgaxVw+1dplt9F A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFACRB9lGtJXG+/2dsb2JhbABbgwY1UIJJuw6BFRZ0giYBBB0dNB0BKhRCJQIEG4gIDJdCoByOPoEOOIMYbwOZCJAjgVuBOYFxOQ X-IronPort-AV: E=Sophos;i="4.89,768,1367971200"; d="scan'208";a="240546446" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jul 2013 10:22:31 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6TAMU1R027181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Jul 2013 10:22:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 05:22:30 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjEWHMNpikDyP/E6vAANE1noeMg== Date: Mon, 29 Jul 2013 10:22:29 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040905138F@xmb-rcd-x04.cisco.com> 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.86.252.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <96BD4DDF25078341B19609960B17D61B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (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: Mon, 29 Jul 2013 10:22:43 -0000 Hello, This email starts a 2-week consensus call on adopting "Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item. Title : Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Author(s) : T. Reddy et al Filename : draft-reddy-pcp-optimize-keepalives-01 URL : http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 Please read the current revision and state you opinion either for or against adoption in the mailing list. The call for adoption ends 12th August 2013. Thanks, Chairs From yoshihiro.ohba@toshiba.co.jp Mon Jul 29 03:43:31 2013 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 B25CD21F9ADC for ; Mon, 29 Jul 2013 03:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.764 X-Spam-Level: X-Spam-Status: No, score=-4.764 tagged_above=-999 required=5 tests=[AWL=-0.675, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6ucMOYIjmHi for ; Mon, 29 Jul 2013 03:43:25 -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 DB6B221F994B for ; Mon, 29 Jul 2013 03:43:24 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r6TAhCwb023031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 19:43:12 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6TAhCTw020007; Mon, 29 Jul 2013 19:43:12 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 384; Mon, 29 Jul 2013 19:43:11 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6TAhB35020004; Mon, 29 Jul 2013 19:43:11 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r6TAhBbD004852; Mon, 29 Jul 2013 19:43:11 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id VAA04851; Mon, 29 Jul 2013 19:43:11 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r6TAhBQS005640; Mon, 29 Jul 2013 19:43:11 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r6TAhBdv019615; Mon, 29 Jul 2013 19:43:11 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.201]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0146.000; Mon, 29 Jul 2013 19:43:10 +0900 From: To: , Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXAKnz5YAAAT/tgAAEEtIgAAVuw6w Date: Mon, 29 Jul 2013 10:43:10 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D40EC5@tgxml338.toshiba.local> References: <1092757F-2853-4F2D-BF60-4C4E733AB3EC@um.es> <51F5B548.6030406@deployingradius.com> <855ED432-F5A4-442C-B785-81B7505DDA7E@yegin.org> In-Reply-To: <855ED432-F5A4-442C-B785-81B7505DDA7E@yegin.org> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.11] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcp@ietf.org Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 10:43:32 -0000 I fully agree with what Alper stated below.=20 For information to the WG members that were not involved in Zigbee Alliance= : During ZigBee IP discussion on PANA, Toshiba released CPANA as open sour= ce with the request from the Alliance members. It helped the community to m= ake the decision but when vendors build their products they may not be usin= g the open source code. In any case, they have PANA as a mandatory functio= n of ZigBee IP, and are interoperable and available in the market. Thanks, Yoshihiro Ohba -----Original Message----- From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Alper= Yegin Sent: Monday, July 29, 2013 5:07 PM To: Alan DeKok Cc: pcp@ietf.org Subject: Re: [pcp] CONSENSUS CALL on PCP security Alan, I'll leave it to the open source implementors to respond, if they care. But let me point the following: PANA having two open-source implementations is just one of the signs of mat= urity and completeness of the work. If you don't want to use those implementations, that's OK. Write your own. = This is not a sufficient justification to design a whole new protocol from = scratch. Alper On Jul 29, 2013, at 3:20 AM, Alan DeKok wrote: > Rafa Marin Lopez wrote: >> Let's avoid re-inventing the wheel. All the arguments I have seen in fav= or of EAP-in-PCP have been based on pure speculation so far. >=20 > No. >=20 >> The same has happened with the arguments against PANA. And those against= PANA either they have been based on misconceptions about PANA or simply th= e arguments were wrong. >=20 > No. >=20 >> Here in the list, we have clarified several times these points one by on= e. >=20 > Partly. The arguments for PANA are (a) it's a standard, and (b)=20 > random pointing to proprietary implementations. The arguments for=20 > EAP-in-PCP have drawn on prior art, with statistics, facts, and evidence. >=20 > The main reason to not use EAP-in-PCP is that it's not a standard use=20 > of EAP. But EAP has been proven to work in practice in similar situation= s. >=20 >> In any case, the fact is PANA is a RFC, another fact is that it has=20 >> running code (two open source implementations so far) >=20 > Are these actually used anywhere? i.e. have even the authors used them? >=20 > Last I looked, I couldn't even build them in a Posix environment. > They seemed to require a specific version of Linux with specific=20 > libraries, etc. >=20 > They just don't look like production code used in a wide variety of=20 > environments. >=20 > And to show my statistics: every new release of FreeRADIUS has 1M=20 > downloads just from my web site. It's worked for nearly 15 years on=20 > Linux, *BSD, Solaris, AIX, HPUX, Mac OSX, with a preliminary Windows=20 > port. It's used by tier one Telcos, in loads reaching 100K+=20 > transactions per day, for over a decade. >=20 > Even ignoring the usage numbers, the open source PANA implementations=20 > don't match that level of code quality, portability, or stability. I=20 > would *not* recommend depending on them in any production environment. >=20 >> and another fact it has been easily integrated with PCP as we showed in = IETF 86. So, what else do we need? >=20 > The truth would help. >=20 > Alan DeKok. > _______________________________________________ > 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 Mon Jul 29 04:46:26 2013 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 43DFD21F9C0A for ; Mon, 29 Jul 2013 04:46:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eACx2l7XsN4C for ; Mon, 29 Jul 2013 04:46:13 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E549521F9BF0 for ; Mon, 29 Jul 2013 04:46:12 -0700 (PDT) Received: from [10.119.8.1] (178-32-45-6.ovh.net [178.32.45.6]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M4o9F-1UA0JP2gHd-00yvFy; Mon, 29 Jul 2013 07:46:09 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <51F63B76.2000103@forthnetgroup.gr> Date: Mon, 29 Jul 2013 14:46:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> References: <51F63B76.2000103@forthnetgroup.gr> To: Tassos Chatzithomaoglou X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:2JOrrey6rGR1uuiHKI/b07bxEWczZ9CNJ1p7xF4juii l8a09uV8HYHj0JYH6JusnpbHVRbZWGA+/W9awVclfVjTOeHA7C cHnzw23BMZtax8YPtQXuHOBi7rLnOGhMKxD51zKq8f3iPDV8HX LC9Tkp1B/k/KOm7Bd4HAPJUFo23S9vcz7aRY7ULaI3wF0gEwm4 TAW+Vtm6Nq4wEUtyMXdRd7sB5zPTeXQw/3yrv86qA3S2ZedVBd u7PiTSJWTfdsOHWm6NBWtCZhnbebPz7PpCLjkJ1UjnmxfYTMn3 BkVevonnkAlgoDbwksuxk+U0Mp7NyjmAd/R43wvTLNlCQ2kUNP r7oAxp/1h1jpkFMREUHR2yCY/4HO+hqEwOKJI9//T Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 11:46:26 -0000 Hello Tassos, "i'm just saying that i feel more comfortable working with something i = have some experience with," This statement is alerting me to a possible misunderstanding.=20 EAP-over-PCP is being invented in PCP WG. There's really nothing in = there that people can possibly have experience with. (except for EAP, but that's common between EAP-o-PCP and EAP-o-PANA). Alper On Jul 29, 2013, at 12:52 PM, Tassos Chatzithomaoglou wrote: > Dave Thaler wrote on 15/07/2013 03:33: >>=20 >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>=20 >> > YES >> 2) Could you *live with* PANA? If not, state reason you would object. >>=20 >> > YES >> 3) If you said yes to both 1 and 2, but have a strong preference = between >> the two, which approach do you prefer and why? >>=20 >> . > EAP-in PCP >=20 > Talking strictly as an operator, i first heard of PANA through this WG = (when the initial talks about pcp auth were happening). > I'm not saying PANA won't do the job (maybe better in some areas), i'm = just saying that i feel more comfortable working with something i have = some experience with, regardless the possible scenario that PANA's = learning curve might end up less steep than expected. > Whatever the vendors decide to implement it's fine by me, as long as = there is interoperability between all of them. Operators need something = to work. >=20 > -- > Tassos >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From aland@deployingradius.com Mon Jul 29 04:51:59 2013 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 A74C421F9A96 for ; Mon, 29 Jul 2013 04:51:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMcADpS8CyFx for ; Mon, 29 Jul 2013 04:51:50 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8598721F9AA8 for ; Mon, 29 Jul 2013 04:51:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8B320224007B; Mon, 29 Jul 2013 13:51:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfRiEwX0BbNy; Mon, 29 Jul 2013 13:51:43 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 6F7852240079; Mon, 29 Jul 2013 13:51:43 +0200 (CEST) Message-ID: <51F65750.4010007@deployingradius.com> Date: Mon, 29 Jul 2013 07:51:44 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alper Yegin References: <51F63B76.2000103@forthnetgroup.gr> <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> In-Reply-To: <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 11:51:59 -0000 Alper Yegin wrote: > EAP-over-PCP is being invented in PCP WG. There's really nothing in there that people can possibly have experience with. Yes, there is related experience. Please see previous discussions on EAP being transported in other protocols. Alan DeKok. From alper.yegin@yegin.org Mon Jul 29 04:52:12 2013 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 61A1F21F9AA8 for ; Mon, 29 Jul 2013 04:52:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ9vHPssP2Sj for ; Mon, 29 Jul 2013 04:51:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBE821F9A94 for ; Mon, 29 Jul 2013 04:51:54 -0700 (PDT) Received: from [10.119.8.1] (178-32-45-6.ovh.net [178.32.45.6]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LpKGb-1UPSxK02In-00fP2r; Mon, 29 Jul 2013 07:51:51 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <359E98A4-AAC7-438E-A39A-0A4EBD70FB54@gmail.com> Date: Mon, 29 Jul 2013 14:51:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> <359E98A4-AAC7-438E-A39A-0A4EBD70FB54@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:0+xLVnaKFgj+GVrzZONZAJwtPQ+AhXoU0I+p6CggySf 1ykHL6PJgjCzTcUeOh5GyWXY6RWaTAqRmBBtXFBISk6K+ZuvRx vICndYxswlpXjrtTFtFJbk031VMfxiSgKm4Jx9pX4R/Bk55Zyp 1cpWXzOBmDLcBmXfjdOIG4MQ7X0TOajZafJC475qWBUW9lntV7 2yY3wY5N1C7qxEIoFz2Lij7ZNNlj2zlba2KgAfMKohAvqVXbOF dS6FYummoAQI+jMskFYEj3Bke1TIw+pHoy8GPq8hrAPWm8+ydV vzWdioqAAKujWpcIkRNWfh4RNik1KKA0BzeIKdtlo4ZxvKR+gG 8gPsKwFnSGSKFS6lkxmAHH0471qSGXSlx17qKpRJA Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 11:52:13 -0000 Margaret, On Jul 29, 2013, at 12:27 PM, Margaret Wasserman wrote: >=20 > Alper, >=20 > The problem with your argument is that PANA is _not_ a general-purpose = authentication protocol, EAP is. One solution reuses EAP directly, and = the other incorporates PANA and EAP. =20 This is plain incorrect. You give the impression that you simply put EAP as a payload of PCP and = be done with it. We had a lengthy discussion on that, and pointed out the EAP lower layer = requirements in RFC 3748.=20 =20 > Both of them reuse existing security standards. >=20 > Including PANA between EAP and PCP is roughly akin to including UDP in = an IP over IP tunnel. =20 > There are cases where it is valuable to do so, and cases where UDP = would provide overhead and no value. It doesn't make sense to include = UDP between IP and IP _just because_ it is a standard. In my opinion, = PANA does not add sufficient value to be worth the overhead of including = it. Your opinion may differ from mine. >=20 Now you are pointing to just one of the two ways PANA is provided, the = one that tunnels PANA over PCP. Yes, there's additional UDP header there. But is that a big enough = problem to justify reinvent a solution? Note that this is not about = carrying all IP traffic over an additional UDP layer. This is for brief = authentication signaling only. And then there's the other way of using PANA, which is the side-by-side = approach, which is not subject to that extra UDP header at all. Alper > Margaret >=20 >=20 > Sent from my iPad >=20 > On Jul 29, 2013, at 9:58 AM, Alper Yegin = wrote: >=20 >> Hi Ted, >>=20 >> I cannot live with the possibility that IETF would not be reusing an = existing protocol, and instead reinvent it just because few folks insist = on their own solution. >> I cannot live with it, because=20 >>> it'd suck considerable amount of energy out of precious IETF cycles = while designing it now, and while maintaining/extending it later, >>> it'd suck considerable amount of energy out of architecture = designers when they need to deal with the integration of one more = protocol, and maintaining/extending it later, >>> it'd suck considerable amount of energy out of product developers = when they need to implement one more protocol, maintaining later too. >>=20 >> I feel funny when I need to explain why reuse is a good thing on an = IETF mailing list. >>=20 >> I think the questions that'd get a YES answer is a different one: Can = EAP-o-PCP made to work?=20 >> Yes, it can be.=20 >>=20 >>=20 >> Let me give another example to illustrate this:=20 >>=20 >> If someone comes along with a new host configuration protocol, with = equivalent functionality as DHCP, without any substantial issue with = DHCP, can it be made to work? >> YES. >> Should IETF live with it? >> NO. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jul 29, 2013, at 1:11 AM, Ted Lemon wrote: >>=20 >>> On Jul 29, 2013, at 12:07 AM, Ted Lemon = wrote: >>>> But none of the four people (you, Alper, Subir and Rafa) who just = asserted that EAP-in-PCP was something they could live with gave a = reason why they couldn't live with it. >>>=20 >>> Sorry, that should have been "could not live with". >>>=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 Jul 29 04:57:49 2013 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 C11C521F9D70 for ; Mon, 29 Jul 2013 04:57:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKAYdzKzwktH for ; Mon, 29 Jul 2013 04:57:43 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D1B4B21F9DB2 for ; Mon, 29 Jul 2013 04:57:42 -0700 (PDT) Received: from [10.119.8.1] (178-32-45-6.ovh.net [178.32.45.6]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MUHso-1UcnIR2GXq-00QmZi; Mon, 29 Jul 2013 07:57:33 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <51F65750.4010007@deployingradius.com> Date: Mon, 29 Jul 2013 14:57:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51F63B76.2000103@forthnetgroup.gr> <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> <51F65750.4010007@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:nMMuik6NtW5I8gxdhQXksKatpclteq2foh/i59Dh5f8 S469Q2laEAIECsu6q5nQW5yx9/ncggoVcLk3GHZ/vmBf1/6wJt Q+Oo4OLN/RfBl4B6cjcrUUjM8/vQ08occHsB2OLlBDCCZE8FCV 3kO+J2AyjYSA2ZgJy2SuzmCbQ5fXTE05IOj7FKBG18y4v+iurc 7SlH3Q1DUG4WOfPODAaNGTrNtpr1lsfvwppC3Ke+bJV9Dk8k0g GFoBGtJx+zjjczkU/GYICkthqc9MJnpxXlu07kDsjFxBswgQ4i 6pGcJ6OtV3DhJpAdB+p2P59uGy4ZhqMRlIZYDS0lG41epQA3Nl uWF3J38OE+g9zLaMRaHGdI9ffOMCbVGLMh/dxCdzu Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 11:57:50 -0000 On Jul 29, 2013, at 2:51 PM, Alan DeKok wrote: > Alper Yegin wrote: >> EAP-over-PCP is being invented in PCP WG. There's really nothing in = there that people can possibly have experience with. >=20 > Yes, there is related experience. Please see previous discussions on > EAP being transported in other protocols. >=20 Which ones specifically? And how are the experience with those protocols = are translating to favoring EAP-o-PCP but not EAP-o-PANA? > Alan DeKok. From aland@deployingradius.com Mon Jul 29 05:02:51 2013 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 251AC21F9CB0 for ; Mon, 29 Jul 2013 05:02:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO3ME1FTXMMQ for ; Mon, 29 Jul 2013 05:02:45 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A38AD21F9C59 for ; Mon, 29 Jul 2013 05:02:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 16BDC224007B; Mon, 29 Jul 2013 14:02:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duG+nk6yEiDo; Mon, 29 Jul 2013 14:02:43 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 78A202240079; Mon, 29 Jul 2013 14:02:43 +0200 (CEST) Message-ID: <51F659E4.9040702@deployingradius.com> Date: Mon, 29 Jul 2013 08:02:44 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alper Yegin References: <1092757F-2853-4F2D-BF60-4C4E733AB3EC@um.es> <51F5B548.6030406@deployingradius.com> <855ED432-F5A4-442C-B785-81B7505DDA7E@yegin.org> In-Reply-To: <855ED432-F5A4-442C-B785-81B7505DDA7E@yegin.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 12:02:51 -0000 Alper Yegin wrote: > PANA having two open-source implementations is just one of the signs of maturity and completeness of the work. It's offered by you as proof that we should use PANA. > If you don't want to use those implementations, that's OK. Write your own. No, I'm saying that those implementations aren't mature. Which invalidates your use of them as proof we should use PANA. It's simple logic. Your straw man portrayal of my argument is both false, and a well-known logical fallacy. Alan DeKok. From aland@deployingradius.com Mon Jul 29 05:07:19 2013 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 4ADCD21F9DD0 for ; Mon, 29 Jul 2013 05:07:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9TIC7SGJ+If for ; Mon, 29 Jul 2013 05:07:13 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBB2221F9CC8 for ; Mon, 29 Jul 2013 05:06:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3E891224007B; Mon, 29 Jul 2013 14:05:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHUG-FoneYTu; Mon, 29 Jul 2013 14:05:43 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id A22AF2240079; Mon, 29 Jul 2013 14:05:42 +0200 (CEST) Message-ID: <51F65A98.2070807@deployingradius.com> Date: Mon, 29 Jul 2013 08:05:44 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alper Yegin References: <51F63B76.2000103@forthnetgroup.gr> <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> <51F65750.4010007@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 12:07:19 -0000 Alper Yegin wrote: > Which ones specifically? And how are the experience with those protocols are translating to favoring EAP-o-PCP but not EAP-o-PANA? I said: Please see previous discussions on EAP being transported in other protocols. If you're too lazy to search the WG archives, I'm too lazy to do that, too. And I have this thing where I "remember" what happened. You're playing the fool by claiming ignorance, and asking me for endless justifications of my opinion. I'm not going to play that game. Alan DeKok. From margaretw42@gmail.com Mon Jul 29 05:08:30 2013 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 EF69521F9DFB for ; Mon, 29 Jul 2013 05:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceB1Q33MqGtl for ; Mon, 29 Jul 2013 05:08:27 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id EE77421F9A2E for ; Mon, 29 Jul 2013 05:08:26 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so4573637pbc.24 for ; Mon, 29 Jul 2013 05:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=DHa5SDuV5Qo7zlxedwcVidnncEyV5uRp0jDHYRXHisk=; b=tPzNbA4Qj99Ijb83a3/V0sg3d74QW/tBfOdMVOaNnXVoG8krAhf/EZDcuoJs7U81OU nHxOGz7LjZklHOOayu+iIyrKCnF7m8eI0f0pNwUESXL8Nx0J8NiuXZy5znSLtC7PF7CZ VmNMnS9AQrTyvAVD0DfIujLH7K04frsKZ/7afTtYk5Qjy6MVNQs9Dqik87y4prhV/KGC TKPwG1QFTSeKgrBwE0quwP3Ktu18Gt4P25E9Tn8y5MM9KlRXnydu9RwkKE6KrGSm0GNh qXeFsGB2wA8n9fale+VivROvWeOMlvSgNB/xnSZPr7opjleaObmh6T5+gowTp/uPafVZ wipA== X-Received: by 10.66.252.234 with SMTP id zv10mr20077597pac.186.1375099706373; Mon, 29 Jul 2013 05:08:26 -0700 (PDT) Received: from ?IPv6:2001:df8::64:dd17:4d57:ce63:384b? ([2001:df8:0:64:dd17:4d57:ce63:384b]) by mx.google.com with ESMTPSA id t9sm18756636pba.46.2013.07.29.05.08.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 05:08:25 -0700 (PDT) References: <2C4BDE35-810E-4552-A000-0305133548AC@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-F7685F57-C862-4F2E-930C-B911FF33BAD8 Content-Transfer-Encoding: 7bit Message-Id: <7C9F0F9E-1423-4A97-A687-BF8320E82673@gmail.com> X-Mailer: iPad Mail (10A523) From: Margaret Wasserman Date: Mon, 29 Jul 2013 14:08:17 +0200 To: Subir Das Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 12:08:30 -0000 --Apple-Mail-F7685F57-C862-4F2E-930C-B911FF33BAD8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subir,=20 In the implementation you site below, what mechanism did you use to distingu= ish between PCP-related PANA traffic and regular network-access-related PANA= traffic? Were you able to use a single PANA implementation for both tasks,= running on a single port without specifying any way to distinguish between t= he two different PANA purposes? Margaret Sent from my iPad On Jul 29, 2013, at 12:00 PM, Subir Das wrote: > Margaret, > We implemented the side-by-side approach and found that it does not requi= re any change to PANA RFC and it was relatively simple. Of course we need to= define a PANA use case for PCP if that is what you meant by additional spec= ification. It would be good to have a discussion on where you think the comp= lexities are and the conflicts between network access authentication and PCP= authentication using PANA.=20 > =20 > We have not implemented direct EAP over PCP. If you have an implementation= and it satisfies the PCP requirements, can we get a copy? It would be then e= asier for us to compare.=20 > =20 > Thanks, > -Subir =20 > =20 >=20 >=20 > On Mon, Jul 29, 2013 at 5:22 AM, Margaret Wasserman wrote: >>=20 >> Subir, >>=20 >> The specification for the use of PANA with PCP is also incomplete. We wo= uld need to make a fairly major decision about _how_ to use PANA with PCP (s= ide-by-side or encaps) both of which have pluses and minuses, because PANA w= as not designed to be a general-purpose authentication layer with upper laye= rs. >>=20 >> Also, we will need to define what parts of PANA are/are not used with PCP= , and make sure that we specify the use of PANA w/PCP in a way that does not= conflict with the use of PANA on the same device for authenticating network= access (as that is the purpose of PANA). >>=20 >> I believe it is possible to do this work, just as I believe it is possibl= e to specify a direct PCP to EAP mapping. I honestly think it will be more w= ork to specify the PANA solution, and that the eventual implementation will b= e more complex. >>=20 >> I feel uncomfortable about people stating that they can't "live with" EAP= -over-PCP because they just happen to like PANA better. If there is an actua= l technical reason why any of you believe that an EAP-over-PCP solution will= not work, could you state it? >>=20 >> If we are claiming we "can't live with" things that will work, simply bec= ause we prefer the other option, I would like to change my response accordin= gly. >>=20 >> Margaret >>=20 >>=20 >>=20 >> Sent from my iPad >>=20 >> On Jul 28, 2013, at 11:06 PM, Subir Das wrote: >>=20 >>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would obje= ct. >>>=20 >>> No. IMO, the current specification is not complete. Assume that the dr= aft is modified and it satisfies the PCP requirements, my understanding is= that it will end up with another protocol very similar to PANA. What would b= e the benefit of doing the similar work and develop yet another EAP lower la= yer when we have already an IETF protocol that satisfies all the PCP require= ments? It was shown that PANA works with PCP without any modifications of e= xisting PANA RFC. The results were presented in the last IETF. So my point= s are: existing RFC and running code. Moreover, the integration is simple. >>> =20 >>> N.B.: PANA is currently under deployment in a major vertical market.=20 >>>=20 >>> 2) Could you *live with* PANA? If not, state reason you would object.=20= >>>=20 >>> Yes. >>>=20 >>> Thanks, >>> -Subir=20 >>>=20 >>>=20 >>> On Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler wro= te: >>>> The WG has discussed two approaches for using EAP with PCP: >>>> direct EAP-in-PCP vs using PANA. >>>>=20 >>>> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP >>>> and 10 or 11 for PANA. There was significant confusion/disagreement >>>> around requirements and proposed solutions at that time. >>>>=20 >>>> At IETF 85, we again polled the room and got a different result, this >>>> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however,= >>>> still significant confusion/disagreement around requirements and >>>> proposed solutions. >>>>=20 >>>> Since IETF 85, we have made lots of progress on getting agreement >>>> on the requirements, and draft-reddy-pcp-auth-req now seems to be >>>> relatively stable without significant areas of disagreement known. >>>> Discussion may of course continue if new issues are raised but we >>>> believe any additional changes are unlikely to affect people's >>>> position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA.= >>>>=20 >>>> The general sense of the WG also seems to be that either approach could= be >>>> made to fit the requirements, so we believe it is now time for us to >>>> determine consensus (draft-resnick-on-consensus is a great read) >>>> on the approach question. We know many folks would just like to >>>> make a decision and move on. >>>>=20 >>>> Hence the chairs would like to ask the WG which solution direction the >>>> WG should pursue in meeting the requirements. Please state your >>>> recommendation on this thread, preferably along with your rationale. >>>> Avoid responding on this thread to others' rationale, use a separate >>>> thread as needed. >>>>=20 >>>> To help us judge consensus, please use the template below and >>>> respond by SUNDAY JULY 28. >>>>=20 >>>> -Dave and Reinaldo >>>>=20 >>>> --- >>>>=20 >>>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would obj= ect. >>>>=20 >>>> >>>>=20 >>>> 2) Could you *live with* PANA? If not, state reason you would object. >>>>=20 >>>> >>>>=20 >>>> 3) If you said yes to both 1 and 2, but have a strong preference betwee= n >>>> the two, which approach do you prefer and why? >>>>=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 --Apple-Mail-F7685F57-C862-4F2E-930C-B911FF33BAD8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Subir, 
=
In the implementation you site below, what mechanism did you u= se to distinguish between PCP-related PANA traffic and regular network-acces= s-related PANA traffic?  Were you able to use a single PANA implementat= ion for both tasks, running on a single port without specifying any way to d= istinguish between the two different PANA purposes?

Margaret



Sent from my iPad

On Jul 29, 2013, at 12:00 PM, Subir Das <subirdas21@gmail.com> wrote:

Margaret,
We  imp= lemented the side-by-side approach and found that it does not require any ch= ange to PANA RFC and it was relatively simple. Of course we need t= o define a PANA use case for PCP if that is what you meant by additional spe= cification. It would be good to have a discussion on where you think th= e complexities are and the conflicts between network access authentication a= nd PCP authentication using PANA. 
 
We have not implemented direct EAP over PCP. If y= ou have an implementation and it satisfies the PCP requirements, can we get a= copy? It would be then easier for us to compare. 
&nbs= p;
Thanks,
-Subir  
 

On Mon, Jul 29, 2013 at 5:22 AM, Margaret W= asserman <margaretw42@gmail.com> wrote:

Subir,

The specification for the use of PANA with PCP is al= so incomplete.  We would need to make a fairly major decision about _ho= w_ to use PANA with PCP (side-by-side or encaps) both of which have pluses a= nd minuses, because PANA was not designed to be a general-purpose authentica= tion layer with upper layers.

Also, we will need to define what parts of PANA are/are n= ot used with PCP, and make sure that we specify the use of PANA w/PCP in a w= ay that does not conflict with the use of PANA on the same device for authen= ticating network access (as that is the purpose of PANA).

I believe it is possible to do this work, just as I beli= eve it is possible to specify a direct PCP to EAP mapping.  I honestly t= hink it will be more work to specify the PANA solution, and that the eventua= l implementation will be more complex.

I feel uncomfortable about people stating that they can'= t "live with" EAP-over-PCP because they just happen to like PANA better. If t= here is an actual technical reason why any of you believe that an EAP-over-P= CP solution will not work, could you state it?

If we are claiming we "can't live with" things that will= work, simply because we prefer the other option, I would like to change my r= esponse accordingly.

Margaret



Sent from my iPad

On Jul 28, 2013, at 11:06 PM, Subir Das <subirdas21@gmail.com> wrote:

=
1) Could you *liv= e with* EAP-in-PCP? If not, state reason you would object.

No. IMO, t= he current  specification is not complete.  Assume that = the draft is modified and it satisfies  the PCP requirements,= my understanding  is that it will end up with another protoc= ol very similar to PANA. What would be the benefit of doing the&nb= sp;similar work and develop yet another EAP lower layer when = we have already an IETF protocol that satisfies all the PCP requirement= s?  It was shown that PANA works with PCP without any mo= difications of existing PANA RFC. The results were presented in th= e last IETF.   So my points are: existing RFC and running code. Mo= reover, the integration is simple.
 
N.B.: PANA is currently under deployment in a major ve= rtical market. 

 2) Could you *live with* PANA? If n= ot, state reason you would object.

   Yes.

&nb= sp;Thanks,
-Subir


On= Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler <dthaler@microsoft.com>= ; wrote:
The WG has discussed two approaches for using EAP with PCP: direct EAP-in-PCP vs using PANA.

At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP
and 10 or 11 for PANA. There was significant confusion/disagreement
around requirements and proposed solutions at that time.

At IETF 85, we again polled the room and got a different result, this
time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however,
still significant confusion/disagreement around requirements and
proposed solutions.

Since IETF 85, we have made lots of progress on getting agreement
on the requirements, and draft-reddy-pcp-auth-req now seems to be
relatively stable without significant areas of disagreement known.
Discussion may of course continue if new issues are raised but we
believe any additional changes are unlikely to affect people's
position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA.

The general sense of the WG also seems to be that either approach could be made to fit the requirements, so we believe it is now time for us to
determine consensus (draft-resnick-on-consensus is a great read)
on the approach question. We know many folks would just like to
make a decision and move on.

Hence the chairs would like to ask the WG which solution direction the
WG should pursue in meeting the requirements. Please state your
recommendation on this thread, preferably along with your rationale.
Avoid responding on this thread to others' rationale, use a separate
thread as needed.

To help us judge consensus, please use the template below and
respond by SUNDAY JULY 28.

-Dave and Reinaldo

---

1) Could you *live with* EAP-in-PCP? If not, state reason you would object.<= br>
    <NO and state reason, or YES>

2) Could you *live with* PANA? If not, state reason you would object.

    <NO and state reason, or YES>

3) If you said yes to both 1 and 2, but have a strong preference between
= the two, which approach do you prefer and why?

    <EAP-in-PCP, or PANA>.  <state reason>
_______________________________________________
pcp mailing list
pcp@ietf.org
http= s://www.ietf.org/mailman/listinfo/pcp

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

= --Apple-Mail-F7685F57-C862-4F2E-930C-B911FF33BAD8-- From margaretw42@gmail.com Mon Jul 29 05:22:00 2013 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 0A99A21F9BFF for ; Mon, 29 Jul 2013 05:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F00OhH4yUv61 for ; Mon, 29 Jul 2013 05:21:54 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 88E8A21F9BD0 for ; Mon, 29 Jul 2013 05:21:50 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id lb1so5825376pab.12 for ; Mon, 29 Jul 2013 05:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=9yqHNyHKoJ8rGUHIXMYjT38xzXXMnzBLs805rkNZKiU=; b=V8mGpt8knJ0vlu+N749X+vYyFwHcEJ/nvbmGMgk2l5LXh2o0xkmKQBMgFhVUHojPOO T00+Idy0npdxuiTZcDkDBCDwAqv/IfJUrndwAIUN9WFCLsylivji4W2Pfbs7rxF8Qrvt RuO4ZQl4B2tid3uqOINCP+xWdWKrStdNEkNVAEscDXVS/s5IE/sSPq3C+2kOe5a72PCj NxvHybjXw83VAVhESOO/sy2BozEiUnz4lgAmIwjZwks81RgFPLUKDOFF7Zxu6E0oSBCv STCIfxGxjz8zZSL40kTWBCcQyX2uPqqWSdvAYa9CH0AqTJ3VXCOKB8KEVeW4/g9wSrr5 yz3Q== X-Received: by 10.66.122.41 with SMTP id lp9mr69282402pab.6.1375100509705; Mon, 29 Jul 2013 05:21:49 -0700 (PDT) Received: from ?IPv6:2001:df8::64:dd17:4d57:ce63:384b? ([2001:df8:0:64:dd17:4d57:ce63:384b]) by mx.google.com with ESMTPSA id pq1sm76691574pbb.26.2013.07.29.05.21.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 05:21:48 -0700 (PDT) References: <2C4BDE35-810E-4552-A000-0305133548AC@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-F48AC23D-8391-4F84-AD56-962F6F105BCD Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A523) From: Margaret Wasserman Date: Mon, 29 Jul 2013 14:21:46 +0200 To: Subir Das Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 12:22:00 -0000 --Apple-Mail-F48AC23D-8391-4F84-AD56-962F6F105BCD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable BTW, the major concern that I have with the side-by-side PANA approach is _n= ot_ that it won't work, but that it involves two different ports that need t= o be equally accessible (and at the same IP address) in order for PCP to wor= k properly -- in my experience, that presents a huge operational problem. H= ow is a network/system admin supposed to know that it is necessary to config= ure firewalls to pass both the PCP and PANA ports in order for PCP to work p= roperly? IMO, the encapsulated PANA approach is very similar to the PCP-over-EAP appr= oach, operationally, except that PANA introduces more complexity and overhea= d. Margaret Sent from my iPad On Jul 29, 2013, at 12:00 PM, Subir Das wrote: > Margaret, > We implemented the side-by-side approach and found that it does not requi= re any change to PANA RFC and it was relatively simple. Of course we need to= define a PANA use case for PCP if that is what you meant by additional spec= ification. It would be good to have a discussion on where you think the comp= lexities are and the conflicts between network access authentication and PCP= authentication using PANA.=20 > =20 > We have not implemented direct EAP over PCP. If you have an implementation= and it satisfies the PCP requirements, can we get a copy? It would be then e= asier for us to compare.=20 > =20 > Thanks, > -Subir =20 > =20 >=20 >=20 > On Mon, Jul 29, 2013 at 5:22 AM, Margaret Wasserman wrote: >>=20 >> Subir, >>=20 >> The specification for the use of PANA with PCP is also incomplete. We wo= uld need to make a fairly major decision about _how_ to use PANA with PCP (s= ide-by-side or encaps) both of which have pluses and minuses, because PANA w= as not designed to be a general-purpose authentication layer with upper laye= rs. >>=20 >> Also, we will need to define what parts of PANA are/are not used with PCP= , and make sure that we specify the use of PANA w/PCP in a way that does not= conflict with the use of PANA on the same device for authenticating network= access (as that is the purpose of PANA). >>=20 >> I believe it is possible to do this work, just as I believe it is possibl= e to specify a direct PCP to EAP mapping. I honestly think it will be more w= ork to specify the PANA solution, and that the eventual implementation will b= e more complex. >>=20 >> I feel uncomfortable about people stating that they can't "live with" EAP= -over-PCP because they just happen to like PANA better. If there is an actua= l technical reason why any of you believe that an EAP-over-PCP solution will= not work, could you state it? >>=20 >> If we are claiming we "can't live with" things that will work, simply bec= ause we prefer the other option, I would like to change my response accordin= gly. >>=20 >> Margaret >>=20 >>=20 >>=20 >> Sent from my iPad >>=20 >> On Jul 28, 2013, at 11:06 PM, Subir Das wrote: >>=20 >>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would obje= ct. >>>=20 >>> No. IMO, the current specification is not complete. Assume that the dr= aft is modified and it satisfies the PCP requirements, my understanding is= that it will end up with another protocol very similar to PANA. What would b= e the benefit of doing the similar work and develop yet another EAP lower la= yer when we have already an IETF protocol that satisfies all the PCP require= ments? It was shown that PANA works with PCP without any modifications of e= xisting PANA RFC. The results were presented in the last IETF. So my point= s are: existing RFC and running code. Moreover, the integration is simple. >>> =20 >>> N.B.: PANA is currently under deployment in a major vertical market.=20 >>>=20 >>> 2) Could you *live with* PANA? If not, state reason you would object.=20= >>>=20 >>> Yes. >>>=20 >>> Thanks, >>> -Subir=20 >>>=20 >>>=20 >>> On Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler wro= te: >>>> The WG has discussed two approaches for using EAP with PCP: >>>> direct EAP-in-PCP vs using PANA. >>>>=20 >>>> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP >>>> and 10 or 11 for PANA. There was significant confusion/disagreement >>>> around requirements and proposed solutions at that time. >>>>=20 >>>> At IETF 85, we again polled the room and got a different result, this >>>> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however,= >>>> still significant confusion/disagreement around requirements and >>>> proposed solutions. >>>>=20 >>>> Since IETF 85, we have made lots of progress on getting agreement >>>> on the requirements, and draft-reddy-pcp-auth-req now seems to be >>>> relatively stable without significant areas of disagreement known. >>>> Discussion may of course continue if new issues are raised but we >>>> believe any additional changes are unlikely to affect people's >>>> position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA.= >>>>=20 >>>> The general sense of the WG also seems to be that either approach could= be >>>> made to fit the requirements, so we believe it is now time for us to >>>> determine consensus (draft-resnick-on-consensus is a great read) >>>> on the approach question. We know many folks would just like to >>>> make a decision and move on. >>>>=20 >>>> Hence the chairs would like to ask the WG which solution direction the >>>> WG should pursue in meeting the requirements. Please state your >>>> recommendation on this thread, preferably along with your rationale. >>>> Avoid responding on this thread to others' rationale, use a separate >>>> thread as needed. >>>>=20 >>>> To help us judge consensus, please use the template below and >>>> respond by SUNDAY JULY 28. >>>>=20 >>>> -Dave and Reinaldo >>>>=20 >>>> --- >>>>=20 >>>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would obj= ect. >>>>=20 >>>> >>>>=20 >>>> 2) Could you *live with* PANA? If not, state reason you would object. >>>>=20 >>>> >>>>=20 >>>> 3) If you said yes to both 1 and 2, but have a strong preference betwee= n >>>> the two, which approach do you prefer and why? >>>>=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 --Apple-Mail-F48AC23D-8391-4F84-AD56-962F6F105BCD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
BTW, the major concern that I have wit= h the side-by-side PANA approach is _not_ that it won't work, but that it in= volves two different ports that need to be equally accessible (and at the sa= me IP address) in order for PCP to work properly -- in my experience, that p= resents a huge operational problem.  How is a network/system admin supp= osed to know that it is necessary to configure firewalls to pass both the PC= P and PANA ports in order for PCP to work properly?

IMO, the encapsulated PANA approach is very similar to the PCP-over-EAP app= roach, operationally, except that PANA introduces more complexity and overhe= ad.

Margaret



Sent f= rom my iPad

On Jul 29, 2013, at 12:00 PM, Subir Das <subirdas21@gmail.com> wrote:
Margaret,
<= div>We  implemented the side-by-side approach and found that it does no= t require any change to PANA RFC and it was relatively simple. Of c= ourse we need to define a PANA use case for PCP if that is what you meant by= additional specification. It would be good to have a discussion on where yo= u think the complexities are and the conflicts between network access a= uthentication and PCP authentication using PANA. 
 
We have not implemented direct EAP over PCP. If y= ou have an implementation and it satisfies the PCP requirements, can we get a= copy? It would be then easier for us to compare. 
&nbs= p;
Thanks,
-Subir  
 

On Mon, Jul 29, 2013 at 5:22 AM, Margaret W= asserman <margaretw42@gmail.com> wrote:

Subir,

The specification for the use of PANA with PCP is al= so incomplete.  We would need to make a fairly major decision about _ho= w_ to use PANA with PCP (side-by-side or encaps) both of which have pluses a= nd minuses, because PANA was not designed to be a general-purpose authentica= tion layer with upper layers.

Also, we will need to define what parts of PANA are/are n= ot used with PCP, and make sure that we specify the use of PANA w/PCP in a w= ay that does not conflict with the use of PANA on the same device for authen= ticating network access (as that is the purpose of PANA).

I believe it is possible to do this work, just as I beli= eve it is possible to specify a direct PCP to EAP mapping.  I honestly t= hink it will be more work to specify the PANA solution, and that the eventua= l implementation will be more complex.

I feel uncomfortable about people stating that they can'= t "live with" EAP-over-PCP because they just happen to like PANA better. If t= here is an actual technical reason why any of you believe that an EAP-over-P= CP solution will not work, could you state it?

If we are claiming we "can't live with" things that will= work, simply because we prefer the other option, I would like to change my r= esponse accordingly.

Margaret



Sent from my iPad

On Jul 28, 2013, at 11:06 PM, Subir Das <subirdas21@gmail.com> wrote:

=
1) Could you *liv= e with* EAP-in-PCP? If not, state reason you would object.

No. IMO, t= he current  specification is not complete.  Assume that = the draft is modified and it satisfies  the PCP requirements,= my understanding  is that it will end up with another protoc= ol very similar to PANA. What would be the benefit of doing the&nb= sp;similar work and develop yet another EAP lower layer when = we have already an IETF protocol that satisfies all the PCP requirement= s?  It was shown that PANA works with PCP without any mo= difications of existing PANA RFC. The results were presented in th= e last IETF.   So my points are: existing RFC and running code. Mo= reover, the integration is simple.
 
N.B.: PANA is currently under deployment in a major ve= rtical market. 

 2) Could you *live with* PANA? If n= ot, state reason you would object.

   Yes.

&nb= sp;Thanks,
-Subir


On= Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler <dthaler@microsoft.com>= ; wrote:
The WG has discussed two approaches for using EAP with PCP: direct EAP-in-PCP vs using PANA.

At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP
and 10 or 11 for PANA. There was significant confusion/disagreement
around requirements and proposed solutions at that time.

At IETF 85, we again polled the room and got a different result, this
time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however,
still significant confusion/disagreement around requirements and
proposed solutions.

Since IETF 85, we have made lots of progress on getting agreement
on the requirements, and draft-reddy-pcp-auth-req now seems to be
relatively stable without significant areas of disagreement known.
Discussion may of course continue if new issues are raised but we
believe any additional changes are unlikely to affect people's
position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA.

The general sense of the WG also seems to be that either approach could be made to fit the requirements, so we believe it is now time for us to
determine consensus (draft-resnick-on-consensus is a great read)
on the approach question. We know many folks would just like to
make a decision and move on.

Hence the chairs would like to ask the WG which solution direction the
WG should pursue in meeting the requirements. Please state your
recommendation on this thread, preferably along with your rationale.
Avoid responding on this thread to others' rationale, use a separate
thread as needed.

To help us judge consensus, please use the template below and
respond by SUNDAY JULY 28.

-Dave and Reinaldo

---

1) Could you *live with* EAP-in-PCP? If not, state reason you would object.<= br>
    <NO and state reason, or YES>

2) Could you *live with* PANA? If not, state reason you would object.

    <NO and state reason, or YES>

3) If you said yes to both 1 and 2, but have a strong preference between
= the two, which approach do you prefer and why?

    <EAP-in-PCP, or PANA>.  <state reason>
_______________________________________________
pcp mailing list
pcp@ietf.org
http= s://www.ietf.org/mailman/listinfo/pcp

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

= --Apple-Mail-F48AC23D-8391-4F84-AD56-962F6F105BCD-- From subirdas21@gmail.com Mon Jul 29 05:36:20 2013 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 ED37C21F9D0F for ; Mon, 29 Jul 2013 05:36:18 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5b1pY05q8RO for ; Mon, 29 Jul 2013 05:36:16 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 82E9221F9DC7 for ; Mon, 29 Jul 2013 05:35:02 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o17so3694526oag.27 for ; Mon, 29 Jul 2013 05:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nXvXCqJQAnbll5YySdRC4R+Wqqry0j88bqtKwV7FrPE=; b=O41xhaUhZlM6/qXy2HT4YUDdWOCRXCR5N1cRxjA2a/x2nD8DL6iW6PHbcGS0sJDEyD TlXNc0l286C9WzogdXFNKygGw/qoz22I/JHmQb0hAzYBsVM2ZV4XHilUdfvDmN/afjvX AT694UwwYAhmJLX3QjTyOdqWkPV8jUL4K82BpVtqHbJPWrayaY/gHu7/SK991EzMCtc9 vpvlr6oqdxTMde/EPcSjaVF/iiobML2ippJMCyPNnyaVZMfC2bM2w05VtJQLNaYlkXEL SntHOAjOGCMTwbZmI8daPgZdI+m4A9J406M2VKW525Y/8Lda2p7MmhV0YU9o/TCLAJNX WlcA== MIME-Version: 1.0 X-Received: by 10.43.11.69 with SMTP id pd5mr384563icb.62.1375101296527; Mon, 29 Jul 2013 05:34:56 -0700 (PDT) Received: by 10.43.172.8 with HTTP; Mon, 29 Jul 2013 05:34:56 -0700 (PDT) In-Reply-To: References: <2C4BDE35-810E-4552-A000-0305133548AC@gmail.com> Date: Mon, 29 Jul 2013 08:34:56 -0400 Message-ID: From: Subir Das To: Margaret Wasserman Content-Type: multipart/alternative; boundary=bcaec50fe46f4f52a904e2a5b824 Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 12:36:20 -0000 --bcaec50fe46f4f52a904e2a5b824 Content-Type: text/plain; charset=ISO-8859-1 Both side-by-side and encapsulated approaches can work using a single port. In our implementation we didn't use two separate ports. As I mentioned to you, would be interested t know the complexity and overhead issues. On Mon, Jul 29, 2013 at 8:21 AM, Margaret Wasserman wrote: > BTW, the major concern that I have with the side-by-side PANA approach is > _not_ that it won't work, but that it involves two different ports that > need to be equally accessible (and at the same IP address) in order for PCP > to work properly -- in my experience, that presents a huge operational > problem. How is a network/system admin supposed to know that it is > necessary to configure firewalls to pass both the PCP and PANA ports in > order for PCP to work properly? > > IMO, the encapsulated PANA approach is very similar to the PCP-over-EAP > approach, operationally, except that PANA introduces more complexity and > overhead. > > Margaret > > > > Sent from my iPad > > On Jul 29, 2013, at 12:00 PM, Subir Das wrote: > > Margaret, > We implemented the side-by-side approach and found that it does not > require any change to PANA RFC and it was relatively simple. Of course we > need to define a PANA use case for PCP if that is what you meant by > additional specification. It would be good to have a discussion on where > you think the complexities are and the conflicts between network access > authentication and PCP authentication using PANA. > > We have not implemented direct EAP over PCP. If you have an implementation > and it satisfies the PCP requirements, can we get a copy? It would be then > easier for us to compare. > > Thanks, > -Subir > > > > On Mon, Jul 29, 2013 at 5:22 AM, Margaret Wasserman > wrote: > >> >> Subir, >> >> The specification for the use of PANA with PCP is also incomplete. We >> would need to make a fairly major decision about _how_ to use PANA with PCP >> (side-by-side or encaps) both of which have pluses and minuses, because >> PANA was not designed to be a general-purpose authentication layer with >> upper layers. >> >> Also, we will need to define what parts of PANA are/are not used with >> PCP, and make sure that we specify the use of PANA w/PCP in a way that does >> not conflict with the use of PANA on the same device for authenticating >> network access (as that is the purpose of PANA). >> >> I believe it is possible to do this work, just as I believe it is >> possible to specify a direct PCP to EAP mapping. I honestly think it will >> be more work to specify the PANA solution, and that the eventual >> implementation will be more complex. >> >> I feel uncomfortable about people stating that they can't "live with" >> EAP-over-PCP because they just happen to like PANA better. If there is an >> actual technical reason why any of you believe that an EAP-over-PCP >> solution will not work, could you state it? >> >> If we are claiming we "can't live with" things that will work, simply >> because we prefer the other option, I would like to change my response >> accordingly. >> >> Margaret >> >> >> >> Sent from my iPad >> >> On Jul 28, 2013, at 11:06 PM, Subir Das wrote: >> >> 1) Could you *live with* EAP-in-PCP? If not, state reason you would >> object. >> >> No. IMO, the current specification is not complete. Assume that the >> draft is modified and it satisfies the PCP requirements, my understanding >> is that it will end up with another protocol very similar to >> PANA. What would be the benefit of doing the similar work and develop yet >> another EAP lower layer when we have already an IETF protocol >> that satisfies all the PCP requirements? It was shown that PANA works with >> PCP without any modifications of existing PANA RFC. The results were >> presented in the last IETF. So my points are: existing RFC and running >> code. Moreover, the integration is simple. >> >> N.B.: PANA is currently under deployment in a major vertical market. >> >> 2) Could you *live with* PANA? If not, state reason you would object. >> >> Yes. >> >> Thanks, >> -Subir >> >> >> On Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler wrote: >> >>> The WG has discussed two approaches for using EAP with PCP: >>> direct EAP-in-PCP vs using PANA. >>> >>> At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP >>> and 10 or 11 for PANA. There was significant confusion/disagreement >>> around requirements and proposed solutions at that time. >>> >>> At IETF 85, we again polled the room and got a different result, this >>> time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however, >>> still significant confusion/disagreement around requirements and >>> proposed solutions. >>> >>> Since IETF 85, we have made lots of progress on getting agreement >>> on the requirements, and draft-reddy-pcp-auth-req now seems to be >>> relatively stable without significant areas of disagreement known. >>> Discussion may of course continue if new issues are raised but we >>> believe any additional changes are unlikely to affect people's >>> position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA. >>> >>> The general sense of the WG also seems to be that either approach could >>> be >>> made to fit the requirements, so we believe it is now time for us to >>> determine consensus (draft-resnick-on-consensus is a great read) >>> on the approach question. We know many folks would just like to >>> make a decision and move on. >>> >>> Hence the chairs would like to ask the WG which solution direction the >>> WG should pursue in meeting the requirements. Please state your >>> recommendation on this thread, preferably along with your rationale. >>> Avoid responding on this thread to others' rationale, use a separate >>> thread as needed. >>> >>> To help us judge consensus, please use the template below and >>> respond by SUNDAY JULY 28. >>> >>> -Dave and Reinaldo >>> >>> --- >>> >>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would >>> object. >>> >>> >>> >>> 2) Could you *live with* PANA? If not, state reason you would object. >>> >>> >>> >>> 3) If you said yes to both 1 and 2, but have a strong preference between >>> the two, which approach do you prefer and why? >>> >>> . >>> >>> _______________________________________________ >>> 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 >> >> > --bcaec50fe46f4f52a904e2a5b824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Both side-by-side and encapsulated approaches can work usi= ng a single port. In our implementation we didn't use two separate port= s. As I mentioned to you, would be interested t know the complexity and ove= rhead issues.


On Mon, Jul 2= 9, 2013 at 8:21 AM, Margaret Wasserman <margaretw42@gmail.com><= /span> wrote:
BTW, the major concer= n that I have with the side-by-side PANA approach is _not_ that it won'= t work, but that it involves two different ports that need to be equally ac= cessible (and at the same IP address) in order for PCP to work properly -- = in my experience, that presents a huge operational problem. =A0How is a net= work/system admin supposed to know that it is necessary to configure firewa= lls to pass both the PCP and PANA ports in order for PCP to work properly?<= /div>

IMO, the encapsulated PANA approach is very similar to = the PCP-over-EAP approach, operationally, except that PANA introduces more = complexity and overhead.

Margare= t



Sent from my iPad

On Jul 29, 2013, at 12:00 PM, Subir Das <subirdas21@gmail.com> wrote= :

Margaret,
We=A0 implemented the side-by-side approach and found that it does = not require any change to PANA RFC and it was relatively=A0simple.=A0Of cou= rse we need to define a PANA use case for PCP if that is what you meant by = additional specification. It would be good to have a discussion on where yo= u=A0think the complexities are and the conflicts between network access aut= hentication and PCP authentication using PANA.=A0
=A0
We have not implemented direct EAP over PCP.=A0If you ha= ve an implementation and it satisfies the PCP requirements, can we get a co= py? It would be=A0then easier for us to compare.=A0
=A0
Thanks,
-Subir =A0
=A0

On Mon, Jul 29, 2013 at 5:22 AM, Margaret Wasse= rman <margaretw42@gmail.com> wrote:

Subir,
The specification for the use of PANA with PCP is also incomplet= e. =A0We would need to make a fairly major decision about _how_ to use PANA= with PCP (side-by-side or encaps) both of which have pluses and minuses, b= ecause PANA was not designed to be a general-purpose authentication layer w= ith upper layers.

Also, we will need to define what parts of PANA are/are= not used with PCP, and make sure that we specify the use of PANA w/PCP in = a way that does not conflict with the use of PANA on the same device for au= thenticating network access (as that is the purpose of PANA).

I believe it is possible to do this work, just as I bel= ieve it is possible to specify a direct PCP to EAP mapping. =A0I honestly t= hink it will be more work to specify the PANA solution, and that the eventu= al implementation will be more complex.

I feel uncomfortable about people stating that they can= 't "live with" EAP-over-PCP because they just happen to like = PANA better. If there is an actual technical reason why any of you believe = that an EAP-over-PCP solution will not work, could you state it?

If we are claiming we "can't live with" t= hings that will work, simply because we prefer the other option, I would li= ke to change my response accordingly.

Margaret



Sent from my iPad

On Ju= l 28, 2013, at 11:06 PM, Subir Das <subirdas21@gmail.com> wrote:

1) Could you *li= ve with* EAP-in-PCP? If not, state reason you would object.

No. IMO,= the current=A0 specification is not complete.=A0=A0Assume that=A0the draft= is modified and=A0it satisfies=A0=A0the PCP requirements, my=A0understandi= ng =A0is that it will end up with=A0another protocol very similar to PANA.= =A0What=A0would be the benefit of doing the=A0similar work and=A0develop ye= t another=A0EAP lower layer when=A0we have already an IETF protocol that=A0= satisfies all the PCP requirements?=A0=A0It was shown that PANA works with = PCP without=A0any=A0modifications of=A0existing PANA RFC.=A0The results wer= e presented in the last IETF.=A0=A0 So my points are: existing RFC and runn= ing code. Moreover, the integration is simple.
=A0
N.B.: PANA is currently under deployment in a major vert= ical market.=A0

=A02) Could you *live with* PANA? If not, st= ate reason you would object.

=A0=A0=A0Yes.

=A0Thanks,
<= div>-Subir


O= n Sun, Jul 14, 2013 at 8:33 PM, Dave Thaler <dthaler@microsoft.com> wrote:
The WG has discussed two approaches for using EAP with PCP= :
direct EAP-in-PCP vs using PANA.

At IETF 84, we polled the room and got 5 hands for direct EAP-in-PCP
and 10 or 11 for PANA. There was significant confusion/disagreement
around requirements and proposed solutions at that time.

At IETF 85, we again polled the room and got a different result, this
time 12 hands for direct EAP-in-PCP and 6 for PANA. There was, however,
still significant confusion/disagreement around requirements and
proposed solutions.

Since IETF 85, we have made lots of progress on getting agreement
on the requirements, and draft-reddy-pcp-auth-req now seems to be
relatively stable without significant areas of disagreement known.
Discussion may of course continue if new issues are raised but we
believe any additional changes are unlikely to affect people's
position on overall solution approach, i.e. direct EAP-in-PCP vs. PANA.

The general sense of the WG also seems to be that either approach could be<= br> made to fit the requirements, so we believe it is now time for us to
determine consensus (draft-resnick-on-consensus is a great read)
on the approach question. We know many folks would just like to
make a decision and move on.

Hence the chairs would like to ask the WG which solution direction the
WG should pursue in meeting the requirements. Please state your
recommendation on this thread, preferably along with your rationale.
Avoid responding on this thread to others' rationale, use a separate thread as needed.

To help us judge consensus, please use the template below and
respond by SUNDAY JULY 28.

-Dave and Reinaldo

---

1) Could you *live with* EAP-in-PCP? If not, state reason you would object.=

=A0=A0=A0 <NO and state reason, or YES>

2) Could you *live with* PANA? If not, state reason you would object.

=A0=A0=A0 <NO and state reason, or YES>

3) If you said yes to both 1 and 2, but have a strong preference between the two, which approach do you prefer and why?

=A0=A0=A0 <EAP-in-PCP, or PANA>.=A0 <state reason>

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

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


--bcaec50fe46f4f52a904e2a5b824-- From margaretw42@gmail.com Mon Jul 29 05:37:50 2013 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 3CA0521F9D54 for ; Mon, 29 Jul 2013 05:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hiNwMu97F9Z for ; Mon, 29 Jul 2013 05:37:49 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DFB2521F9EB3 for ; Mon, 29 Jul 2013 05:36:25 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wy7so4608777pbc.17 for ; Mon, 29 Jul 2013 05:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=wfDdZb0p5WA2QuQOVVpqQ2hZagB5fAIuZobkmF33L2A=; b=m6M7qQL9RD9b7i0Lk7FeePSyk+kCLYH9aLtcunKkruMSFC8/wM/fl4cW+fZ2o43EuM eTTDkJbp87gWxajy7sCh2PWDE/jSpReYczh+1hPAnmZocAwYgsy92OulEl1N2FHcICvj g2ucQTAjDnKsdFi7qrlZeg/q7+6TU+QpsQgGLeVJvetABiUFUcHyKQ9/DL8XYJBw24pa 1ZpbEwItZYLmKdLkHWPVR11wLYPlcTxVnW6C7TnGzYBlDq3Vq3LwCVbRZeKQ7WGVpjmL 3Pw0BxVTMPyfkFlQ73rwJUFwWzxFdRBEbnDuOPHjX0zuTpFQj1vSuYsXERWgfhlhpKDq 0f+Q== X-Received: by 10.67.22.99 with SMTP id hr3mr68026232pad.12.1375101385607; Mon, 29 Jul 2013 05:36:25 -0700 (PDT) Received: from ?IPv6:2001:df8::64:dd17:4d57:ce63:384b? ([2001:df8:0:64:dd17:4d57:ce63:384b]) by mx.google.com with ESMTPSA id bg3sm76707815pbb.44.2013.07.29.05.36.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 05:36:24 -0700 (PDT) References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> <359E98A4-AAC7-438E-A39A-0A4EBD70FB54@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <101DB1D5-715E-420E-9ED6-2A7437F3919C@gmail.com> X-Mailer: iPad Mail (10A523) From: Margaret Wasserman Date: Mon, 29 Jul 2013 14:36:22 +0200 To: Alper Yegin Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 12:37:50 -0000 Hi Alper, >> The problem with your argument is that PANA is _not_ a general-purpose au= thentication protocol, EAP is. One solution reuses EAP directly, and the ot= her incorporates PANA and EAP. =20 >=20 > This is plain incorrect. > You give the impression that you simply put EAP as a payload of PCP and be= done with it. I don't know what you are referring to... We wrote a draft that explains ho= w to do this. It is quite a concise draft, and people who want to know what= we are proposing can read it. I hope, at this point, that this is a discus= sion between people who understand the contents of all three drafts. >=20 >> Both of them reuse existing security standards. >>=20 >> Including PANA between EAP and PCP is roughly akin to including UDP in an= IP over IP tunnel. =20 >> There are cases where it is valuable to do so, and cases where UDP would p= rovide overhead and no value. It doesn't make sense to include UDP between I= P and IP _just because_ it is a standard. In my opinion, PANA does not add s= ufficient value to be worth the overhead of including it. Your opinion may d= iffer from mine. >=20 > Now you are pointing to just one of the two ways PANA is provided, the one= that tunnels PANA over PCP. > Yes, there's additional UDP header there. But is that a big enough problem= to justify reinvent a solution? Note that this is not about carrying all IP= traffic over an additional UDP layer. This is for brief authentication sign= aling only. I was making an analogy, not discussing (just) the UDP header in PANA. IMO,= there are significant portions of PANA that are not needed for PCP, and the= y are all additional overhead in both PANA approaches. > And then there's the other way of using PANA, which is the side-by-side ap= proach, which is not subject to that extra UDP header at all. In my opinion, the side-by-side approach is fatally flawed, because it uses t= wo ports (see my previous message). Therefore, all claims that are made abo= ut the side-by-side approach are immaterial IMO. The only PANA solution I can "live with" is the encapsulated approach, and I= consider it inferior to the direct PCP-over-EAP approach, because of added c= omplexity/overhead that offers little/no benefit. I admit that they will bo= th work, though. They will both provide the same level of security and appr= oximately the same operational/user experience, so I can "live with" either o= f them, even though I have a strong preference. Please note that the _only_ PCP implementor who has stated an opinion has cl= aimed that he would implement the direct PCP-over-EAP solution and would not= implement a PANA-based solution. Margaret= From pedrorechez@gmail.com Mon Jul 29 06:11:42 2013 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 32C0A21F9EE5 for ; Mon, 29 Jul 2013 06:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrx-YvuUOH+l for ; Mon, 29 Jul 2013 06:11:41 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4859D21F9F6C for ; Mon, 29 Jul 2013 06:11:39 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id en1so2972755wid.0 for ; Mon, 29 Jul 2013 06:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=cMaJBUo5jEkrgOOZg/augCyg31Sv8KZleuaXN1TH1l8=; b=tRp/zJLx8AbSVfL6PL2Dr1xPT1CDI15ySnrsKMWR//4eS3nZYZ+pIcpWMdSy7Ofk5G Bg9aMivKqgBV0jruoU0DXqUciw/BdDIJOp6yoqqR4ozyurIefDoI742YuYZZMcgynD3j /4mnMQung5Yq9Rm2xDuX6iq8gz0pnU1xoHmwtP+2oV5hIP016ub1R8th2J2EHJ3hxvJ0 JOo8TZ9xYQySNwFHTjQwWtV0InEWg770PgXKGX8ZQPGWq6rcxL9I1NMkkUtFD3SUdUzZ Tz8mMDL11Pg11uP7m4DgMyNdJvCyEx4e404b+lciTENwx1GbIwF/BE5Yv2L+003p2FeD UvMw== X-Received: by 10.194.243.164 with SMTP id wz4mr43379383wjc.28.1375103498007; Mon, 29 Jul 2013 06:11:38 -0700 (PDT) MIME-Version: 1.0 Sender: pedrorechez@gmail.com Received: by 10.194.81.162 with HTTP; Mon, 29 Jul 2013 06:11:17 -0700 (PDT) In-Reply-To: <101DB1D5-715E-420E-9ED6-2A7437F3919C@gmail.com> References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> <359E98A4-AAC7-438E-A39A-0A4EBD70FB54@gmail.com> <101DB1D5-715E-420E-9ED6-2A7437F3919C@gmail.com> From: =?ISO-8859-1?Q?Pedro_Moreno_S=E1nchez?= Date: Mon, 29 Jul 2013 15:11:17 +0200 X-Google-Sender-Auth: 7FM6XLIiR8i9DjxQin3IIqEPZDU Message-ID: To: Margaret Wasserman Content-Type: multipart/alternative; boundary=089e0149405087390c04e2a63b53 Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 13:11:42 -0000 --089e0149405087390c04e2a63b53 Content-Type: text/plain; charset=ISO-8859-1 Hello Margaret, > Please note that the _only_ PCP implementor who has stated an opinion has > claimed that he would implement the direct PCP-over-EAP solution and would > not implement a PANA-based solution. > > I would like to say that this comment is incorrect. Both Ricardo Martijaand I implemented a functional PCP client and PCP server from scratch, supporting the two PANA opensource implementations available (i.e., OpenPANAand CPANA). The results of this integration were presented by Yoshihiro Ohba in the IETF86 meeting. Additionally, both of us have stated our opinion in favor of PCP-PANA approach. Please see: http://www.ietf.org/mail-archive/web/pcp/current/msg03223.html http://www.ietf.org/mail-archive/web/pcp/current/msg03234.html Best, Pedro. --089e0149405087390c04e2a63b53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Margaret,


Please note that the _only_ PCP implementor who has stated an opinion has c= laimed that he would implement the direct PCP-over-EAP solution and would n= ot implement a PANA-based solution.

I would l= ike to say that this comment is incorrect. Both Ricardo Martija and I implemented a functional PCP client and PCP serv= er from scratch, supporting the two PANA opensource implementations available (i.e., OpenPANA and CPANA).= The results of this integration were presented by Y= oshihiro Ohba in the IETF86 meeting. A= dditionally, both of us have stated our opinion in f= avor of PCP-PANA approach. Please see:=
http://www.ietf.or= g/mail-archive/web/pcp/current/msg03223.html<= br>http://www.ietf= .org/mail-archive/web/pcp/current/msg03234.ht= ml

Best,
Pedro.
--089e0149405087390c04e2a63b53-- From alper.yegin@yegin.org Mon Jul 29 06:57:55 2013 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 F1EA811E80A2 for ; Mon, 29 Jul 2013 06:57:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMVjBSWjDmnu for ; Mon, 29 Jul 2013 06:57:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 13C1721F9A3D for ; Mon, 29 Jul 2013 06:57:13 -0700 (PDT) Received: from vpn-cust-10-119-8-4.witopia.net ([93.113.37.108]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LjqxF-1UXEDY0S4X-00bu81; Mon, 29 Jul 2013 09:57:09 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <101DB1D5-715E-420E-9ED6-2A7437F3919C@gmail.com> Date: Mon, 29 Jul 2013 16:57:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <59A5F1E9-72A6-4084-BD44-01BBE494DA34@yegin.org> References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> <359E98A4-AAC7-438E-A39A-0A4EBD70FB54@gmail.com> <101DB1D5-715E-420E-9ED6-2A7437F3919C@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:bZDlUjLicDD765mKPcK6YfaiBbL4PUvgO3e0oIuzeg0 guhBclquozXmje1Tdz+x0u4zGw8+q8fKumkIY7SFBez193ncur MkLAGfAuXrPNMUmStle9FXYTAtfi6jp615336xp7gjE2Ixf6X8 xsYGbscHbwdiixYLOsbNnVigVqzB1wkJ4yfoCD94xITrsU/TsQ MV/73JyroUcyXU053OZupwYXTfpHYhSuDuqBpeQcN6gIw2lOgC jR0ABDOekKajHNHLIPldHIlzj0zM8r6sduR3WuQ3tLxc3KcTnw 6mIA8dLdO93QkbAra6mvsPDgtTERj3dyOwOFQdR0R4D3Si/9j4 SReGxOvgj2qGUSMdTEzRTqRnSt+9GpjPeuev+loJBtKsiu8lFG wnFWdKpE5vRXDOEJwpQuak9FiONJ7hpFmo= Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 13:57:55 -0000 Hi Margaret, >=20 >>> The problem with your argument is that PANA is _not_ a = general-purpose authentication protocol, EAP is. One solution reuses = EAP directly, and the other incorporates PANA and EAP. =20 >>=20 >> This is plain incorrect. >> You give the impression that you simply put EAP as a payload of PCP = and be done with it. >=20 > I don't know what you are referring to... We wrote a draft that = explains how to do this. It is quite a concise draft, and people who = want to know what we are proposing can read it. I hope, at this point, = that this is a discussion between people who understand the contents of = all three drafts. >=20 I hope so too. >>=20 >>> Both of them reuse existing security standards. >>>=20 >>> Including PANA between EAP and PCP is roughly akin to including UDP = in an IP over IP tunnel. =20 >>> There are cases where it is valuable to do so, and cases where UDP = would provide overhead and no value. It doesn't make sense to include = UDP between IP and IP _just because_ it is a standard. In my opinion, = PANA does not add sufficient value to be worth the overhead of including = it. Your opinion may differ from mine. >>=20 >> Now you are pointing to just one of the two ways PANA is provided, = the one that tunnels PANA over PCP. >=20 >=20 >> Yes, there's additional UDP header there. But is that a big enough = problem to justify reinvent a solution? Note that this is not about = carrying all IP traffic over an additional UDP layer. This is for brief = authentication signaling only. >=20 > I was making an analogy, not discussing (just) the UDP header in PANA. = IMO, there are significant portions of PANA that are not needed for = PCP, and they are all additional overhead in both PANA approaches. >=20 We discussed this. Only two things turned out to be "extras". One is = pana-ping, the other is IP reconfig flag. These are two minor features, costing 10s of lines of code. Not = implementing, or implementing and not using is not a deal at all. At = least not a deal to design a whole new protocol from scratch. (We discussed this already. I'm sure you are not doing this = intentionally, but repeatedly raising an already addressed issue is not = productive). >> And then there's the other way of using PANA, which is the = side-by-side approach, which is not subject to that extra UDP header at = all. >=20 > In my opinion, the side-by-side approach is fatally flawed, because it = uses two ports (see my previous message). Therefore, all claims that = are made about the side-by-side approach are immaterial IMO. >=20 No, it uses single port. This issue was discussed long time ago, and = already addressed, and documented in the I-Ds. Both PANA solutions work over PCP port. (this, again, is another "discussed and addressed issue"). > The only PANA solution I can "live with" is the encapsulated approach, = and I consider it inferior to the direct PCP-over-EAP approach, because = of added complexity/overhead that offers little/no benefit. I admit = that they will both work, though. They will both provide the same level = of security and approximately the same operational/user experience, so I = can "live with" either of them, even though I have a strong preference. >=20 > Please note that the _only_ PCP implementor who has stated an opinion = has claimed that he would implement the direct PCP-over-EAP solution and = would not implement a PANA-based solution. >=20 Not true. Please see Pedro's email. Thanks. Alper > Margaret From alper.yegin@yegin.org Mon Jul 29 07:08:00 2013 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 ADB3F21F9FF6 for ; Mon, 29 Jul 2013 07:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FKTeyiOdUz8 for ; Mon, 29 Jul 2013 07:07:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id DE2D221F99C7 for ; Mon, 29 Jul 2013 07:07:55 -0700 (PDT) Received: from vpn-cust-10-119-8-4.witopia.net ([93.113.37.108]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M2KNg-1UByZb0Chg-00sQ8T; Mon, 29 Jul 2013 10:07:51 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_89EE900D-3C4E-4DBA-A4C4-0AFAC02B8F3E" From: Alper Yegin In-Reply-To: Date: Mon, 29 Jul 2013 17:07:44 +0300 Message-Id: <8AF8A64B-5330-4FF5-B3C2-A2EA844BB5AD@yegin.org> References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> <359E98A4-AAC7-438E-A39A-0A4EBD70FB54@gmail.com> <101DB1D5-715E-420E-9ED6-2A7437F3919C@gmail.com> To: =?iso-8859-1?Q?Pedro_Moreno_S=E1nchez?= X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:2hoTAOIGE5/7ivavg7fYgdhbmXE6aCDWGFGsNQUIyMp rnu5CMRdQFA826h6IWph5ciRr3nsT29DHLwD4uGoI2ak55+Bih xENDLqnJRIdQiN7ciK0CfqENrzYvrkZ58eZ+o1sXE0BZHNFdBu UEhUrpOJRGZaUNQPcYt4GUFQbRJaeAoxXuz7PR3DYEnPo7Te3B HzCoVGQ4UxQa17CQoKXP2/NK1GQGR0q7b8QIbhEs2JBJxZgAGC k2gVNEn94wQ4o/Z4lYNwKu2bxZiej35faghOG1rayMdHVc/hM6 aWoWaUmWvVUnOSzTNFiOJdzs9dC1c/vYJNk3H7gJfiNn8f7Zf2 NU7hg8WgAkvvn9IHS3753SMehp+UfdqrWmH3xcqj1jyPtL9H9W dumTJfCh5yuYSYTmrqhZ1ceznPvZMNobDM= Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 14:08:01 -0000 --Apple-Mail=_89EE900D-3C4E-4DBA-A4C4-0AFAC02B8F3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 29, 2013, at 4:11 PM, Pedro Moreno S=E1nchez wrote: > Hello Margaret, >=20 >=20 > Please note that the _only_ PCP implementor who has stated an opinion = has claimed that he would implement the direct PCP-over-EAP solution and = would not implement a PANA-based solution. >=20 Aside from ignoring Pedro's input, this is also not reflecting what = Stuart said. He said:=20 "To elaborate, what I mean is that I would be willing to lobby the = relevant Apple engineering teams to implement EAP-in-PCP, and I believe = that such efforts would have a reasonable chance of being successful. = Note that "relevant Apple engineering teams" covers multiple groups -- = PCP client, AirPort Base Station, Internet Sharing, and iPhone personal = hotspot. I believe that trying to lobby those four groups to support PCP = authentication via PANA would have a small chance of success, because = that solution is more complicated and has more potential for more = inter-group dependencies." Nowhere I see a commitment to implement EAP-o-PCP and not to implement = PANA.=20 This is all about "willingness to internally lobby" and "predictions = about what might the engineering teams do". That's all. Alper > I would like to say that this comment is incorrect. Both Ricardo = Martija and I implemented a functional PCP client and PCP server from = scratch, supporting the two PANA opensource implementations available = (i.e., OpenPANA and CPANA). The results of this integration were = presented by Yoshihiro Ohba in the IETF86 meeting. Additionally, both of = us have stated our opinion in favor of PCP-PANA approach. Please see:=20 > http://www.ietf.org/mail-archive/web/pcp/current/msg03223.html > http://www.ietf.org/mail-archive/web/pcp/current/msg03234.html >=20 > Best, > Pedro. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail=_89EE900D-3C4E-4DBA-A4C4-0AFAC02B8F3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hello Margaret,


Please note that the _only_ PCP implementor who has stated an opinion = has claimed that he would implement the direct PCP-over-EAP solution and = would not implement a PANA-based solution.

<= /blockquote>

Aside from ignoring Pedro's input, this = is also not reflecting what Stuart said. He = said: 

"To elaborate, what I mean is that = I would be willing to lobby the relevant Apple engineering teams to = implement EAP-in-PCP, and I believe that such efforts would have a = reasonable chance of being successful. Note that "relevant Apple = engineering teams" covers multiple groups -- PCP client, AirPort Base = Station, Internet Sharing, and iPhone personal hotspot.

I = believe that trying to lobby those four groups to support PCP = authentication via PANA would have a small chance of success, because = that solution is more complicated and has more potential for more = inter-group dependencies."

Nowhere I see a = commitment to implement EAP-o-PCP and not to implement = PANA. 
This is all about "willingness to internally = lobby" and "predictions about what might the engineering teams do". = That's = all.

Alper



I would like to = say that this comment is incorrect. Both Ricardo Martija and I implemented a functional PCP client and = PCP server from scratch, supporting the two PANA opensource = implementations available (i.e., OpenPANA and CPANA). = The results of this integration were presented by Yoshihiro Ohba in = the IETF86 meeting. Additionally, both of us have stated our opinion in = favor of PCP-PANA approach. Please see:
http://www.ietf.org/mail-archive/web/pcp/current/msg03223.html
http://www.ietf.org/mail-archive/web/pcp/current/msg03234.html

Best,
Pedro.
_______________________________________________
pcp mailing = list
pcp@ietf.org
https://www.ietf.org/mail= man/listinfo/pcp

= --Apple-Mail=_89EE900D-3C4E-4DBA-A4C4-0AFAC02B8F3E-- From tireddy@cisco.com Mon Jul 29 07:52:01 2013 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 3DBF121F9E02 for ; Mon, 29 Jul 2013 07:51:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RazaFwkWv5Dx for ; Mon, 29 Jul 2013 07:51:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 548CA21F9D82 for ; Mon, 29 Jul 2013 07:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2830; q=dns/txt; s=iport; t=1375109499; x=1376319099; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=WcBZ+EbWgVLwRK+oGATVbgFyjS+rwAXgEaQ2k5wRKz0=; b=iAJQlgu1MXQvDiAHT5SVSElqb6tWeItXYv7lQF3/ynbn92DpBUYAo+iS uB3hl95nVEKLxgGnWgeAI1cMqKlaTZnXpS+cKAtuM1WRYKF7NoGob8DKg zrL9v+JNMOdsYfrgIWKJKFKr0NlepYwLxFFEBlz8+ay5tF86Lyk2/vQh0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALGA9lGtJXG9/2dsb2JhbABbgwY1UIMQukcXgQEWdIIkAQEBBCMRQw4GAQgRBAEBAwIGHQMCBDAUAQYBAQUFBBMIAYgHDJgDjwCRO4EojiQ+gl8zbwOZCJAjgxSCKg X-IronPort-AV: E=Sophos;i="4.89,770,1367971200"; d="scan'208";a="240834128" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jul 2013 14:51:39 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6TEpc52023784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Jul 2013 14:51:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 09:51:38 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-penno-pcp-mobile-qos-00.txt Thread-Index: AQHOjGPlFkU857h2sUuLAoAGnM6nAZl7ug3w Date: Mon, 29 Jul 2013 14:51:37 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14BB30CB@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.189] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-penno-pcp-mobile-qos-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: Mon, 29 Jul 2013 14:52:01 -0000 VGhpcyBkb2N1bWVudCBleHBsYWlucyBob3cgdGhlIFBDUCBTZXJ2ZXIgaW4gdGhlIEV2b2x2ZWQg UGFja2V0IENvcmUgKEVQQykgbWFwcyB0aGUgZmllbGRzIGluIFBDUCBGTE9XREFUQSBvcHRpb24g dG8gM0dQUCBRQ0ksIEdCUiB2YWx1ZXMgYW5kIGlzIGFsc28gY29tcGxpYW50IHdpdGggdGhlIDNH UFAncyBuZXR3b3JrLXRyaWdnZXJlZCBRb1MgcG9saWN5IGVuZm9yY2VtZW50IG1vZGVsLiBDb21t ZW50cyBhbmQgU3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCi0tQXV0aG9ycy4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bHkgMjksIDIw MTMgNzoyOCBQTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFJlaW5hbGRvIFBl bm5vIChyZXBlbm5vKTsgQmlsbCBWZXJTdGVlZzsgQmlsbCBWZXIgU3RlZWc7IE1vaGFtZWQgQm91 Y2FkYWlyOyBEYW4gV2luZyAoZHdpbmcpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXBlbm5vLXBjcC1tb2JpbGUtcW9zLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1wZW5uby1wY3AtbW9iaWxlLXFvcy0wMC50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmVpbmFsZG8gUGVubm8gYW5kIHBvc3RlZCB0byB0aGUN CklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1wZW5uby1wY3AtbW9iaWxlLXFv cw0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgUENQIFVzYWdlIGZvciBRdWFsaXR5IG9mIFNlcnZp Y2UgKFFvUykgaW4gTW9iaWxlIE5ldHdvcmtzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0yOQ0K R3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEzDQpVUkw6 ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBl bm5vLXBjcC1tb2JpbGUtcW9zLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbm5vLXBjcC1tb2JpbGUtcW9zDQpIdG1saXplZDog ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbm5vLXBjcC1tb2JpbGUt cW9zLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGVyZSBhcmUgY2hhbGxlbmdlcyB0byByZXF1ZXN0 IHF1YWxpdHkgb2Ygc2VydmljZSBmb3IgYW4gYXBwbGljYXRpb24NCiAgIG9yIG5ldHdvcmsgZmxv dyB0aGF0IGlzIG5vdCBwYXJ0IG9mIGEgbW9iaWxlIG5ldHdvcmsncyBFdm9sdmVkIFBhY2tldA0K ICAgQ29yZSAoRVBDKS4gIFRoaXMgZG9jdW1lbnQgYWRkcmVzc2VzIHRoaXMgaXNzdWUgYnkgZGVm aW5pbmcgYQ0KICAgbWVjaGFuaXNtIHRvIHNpZ25hbCB0aGUgZGVzaXJlZCBjaGFyYWN0ZXJpc3Rp Y3Mgb2YgYSBmbG93IHRvIHRoZQ0KICAgTW9iaWxlIE5ldHdvcmsgZnJvbSBhIFVzZXIgRXF1aXBt ZW50IChVRSkgdXNpbmcgUG9ydCBDb250cm9sIFByb3RvY29sDQogICAoUENQKS4gIFRoZSBzaWdu YWxlZCBjaGFyYWN0ZXJpc3RpY3MgYWxsb3cgdGhlIE1vYmlsZSBOZXR3b3JrIHRvDQogICBlbmZv cmNlIGFwcHJvcHJpYXRlIHBvbGljaWVzIHN1Y2ggYXMgcHJpb3JpdGl6ZSB0aGF0IGZsb3cgYWNj b3JkaW5nbHkNCiAgIGFuZCB0cmlnZ2VyIGRlZGljYXRlZCBiZWFyZXIgYWN0aXZhdGlvbiBvciBi ZWFyZXIgbW9kaWZpY2F0aW9uDQogICBwcm9jZWR1cmUuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From margaretw42@gmail.com Mon Jul 29 07:57:35 2013 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 E73D611E80D2 for ; Mon, 29 Jul 2013 07:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngLiTUJ0dS1G for ; Mon, 29 Jul 2013 07:57:33 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id CD5F021E805A for ; Mon, 29 Jul 2013 07:57:23 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y11so16260pdj.0 for ; Mon, 29 Jul 2013 07:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=TA5/ZUSFSxDvrGmU8zPPru19ry+WbAKVSYk/d9nFPdc=; b=ybD5QLvq61rY/zTN9C7gvjaIr0dnZZFyLL0nG3EkS9iPiUniv1qQs404Nbmgglqfmd HbHOAu81M3XSt8BEA+AU3O+os461/FkkSyzK2Ckg96lEy0w9chxxMPj0LIjWq9Zt/0sE PBOxksMYFsrSxVHA9w3M+Xb8BezijIpF0SiTY6JmQ8eoDsB0OCnvQKzCnlLHoTNd9GM/ 9HNmzXIPhXsaYwOd6t5pKex5qkjbn1L31jras5aXtOHV5rxTvaTl/nvmyrhFj868bkXk tT3rILcL3gE9pgAUni9lzC5ToyzQ1ndbtz+2zseMs9zjDRBQdWL70hP9KRmqnS+o53DR wbjw== X-Received: by 10.68.97.229 with SMTP id ed5mr68640225pbb.37.1375109843290; Mon, 29 Jul 2013 07:57:23 -0700 (PDT) Received: from ?IPv6:2001:df8::8:4985:fa29:f79a:ea2b? ([2001:df8:0:8:4985:fa29:f79a:ea2b]) by mx.google.com with ESMTPSA id ep4sm77383667pbd.35.2013.07.29.07.57.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 07:57:22 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_507A7621-3A25-489B-9C7B-569E44E2843D" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Margaret Wasserman In-Reply-To: Date: Mon, 29 Jul 2013 16:57:19 +0200 Message-Id: References: <674F70E5F2BE564CB06B6901FD3DD78B12D40B63@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B63077523329F@mbx-01.win.nominum.com> <674F70E5F2BE564CB06B6901FD3DD78B12D40C0F@tgxml338.toshiba.local> <8D23D4052ABE7A4490E77B1A012B6307752333C8@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307752333F2@mbx-01.win.nominum.com> <359E98A4-AAC7-438E-A39A-0A4EBD70FB54@gmail.com> <101DB1D5-715E-420E-9ED6-2A7437F3919C@gmail.com> To: =?iso-8859-1?Q?Pedro_Moreno_S=E1nchez?= X-Mailer: Apple Mail (2.1508) Cc: "" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 14:57:36 -0000 --Apple-Mail=_507A7621-3A25-489B-9C7B-569E44E2843D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sorry, Pedro. I apologize for being unaware of your implementation. = Could you send a pointer to the open source project, if there is one? Thanks, Margaret On Jul 29, 2013, at 3:11 PM, Pedro Moreno S=E1nchez = wrote: > Hello Margaret, >=20 >=20 > Please note that the _only_ PCP implementor who has stated an opinion = has claimed that he would implement the direct PCP-over-EAP solution and = would not implement a PANA-based solution. >=20 > I would like to say that this comment is incorrect. Both Ricardo = Martija and I implemented a functional PCP client and PCP server from = scratch, supporting the two PANA opensource implementations available = (i.e., OpenPANA and CPANA). The results of this integration were = presented by Yoshihiro Ohba in the IETF86 meeting. Additionally, both of = us have stated our opinion in favor of PCP-PANA approach. Please see:=20 > http://www.ietf.org/mail-archive/web/pcp/current/msg03223.html > http://www.ietf.org/mail-archive/web/pcp/current/msg03234.html >=20 > Best, > Pedro. --Apple-Mail=_507A7621-3A25-489B-9C7B-569E44E2843D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 p.morenosanchez@um.es>= wrote:

Hello Margaret,


Please note that the _only_ PCP implementor who has stated an opinion = has claimed that he would implement the direct PCP-over-EAP solution and = would not implement a PANA-based solution.

I = would like to say that this comment is incorrect. Both Ricardo Martija and I implemented a functional PCP = client and PCP server from scratch, supporting the two PANA opensource = implementations available (i.e., OpenPANA and CPANA). = The results of this integration were presented by Yoshihiro Ohba in = the IETF86 meeting. Additionally, both of us have stated our opinion in = favor of PCP-PANA approach. Please see:
http://www.ietf.org/mail-archive/web/pcp/current/msg03223.html
http://www.ietf.org/mail-archive/web/pcp/current/msg03234.html

Best,
Pedro.

= --Apple-Mail=_507A7621-3A25-489B-9C7B-569E44E2843D-- From achatz@forthnetgroup.gr Mon Jul 29 07:58:38 2013 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 AEED311E80EE for ; Mon, 29 Jul 2013 07:58:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li1CbHw+XXUt for ; Mon, 29 Jul 2013 07:58:18 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0DF11E80EF for ; Mon, 29 Jul 2013 07:58:10 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r6TEw7sO025586 for ; Mon, 29 Jul 2013 17:58:07 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r6TEw7G4023778 for ; Mon, 29 Jul 2013 17:58:07 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r6TEw6ZJ013219; Mon, 29 Jul 2013 17:58:07 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <51F682FD.6070701@forthnetgroup.gr> Date: Mon, 29 Jul 2013 17:58:05 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19 MIME-Version: 1.0 To: "pcp@ietf.org" References: <51F63B76.2000103@forthnetgroup.gr> <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> In-Reply-To: <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 14:58:38 -0000 Alper, from an operator's view, i see something like the following: EAP over PANA over/with PCP EAP over PCP In the first case i have an intermediate layer which already works according to your experiences, but adds an unknown entity to operate/troubleshoot. In the second case i have a known entity, which must be made to work in a way that is easy to operate/troubleshoot. Really, i don't know if the second case is viable, but i would be willing to take the risk. From a vendor's view, everything might be different. I wish i could have much simpler auth built into PCP from the beginning (generally i don't enjoy the idea of using something extra), but that is another talk. -- Tassos Alper Yegin wrote on 29/07/2013 14:46: > Hello Tassos, > > "i'm just saying that i feel more comfortable working with something i have some experience with," > > This statement is alerting me to a possible misunderstanding. > > EAP-over-PCP is being invented in PCP WG. There's really nothing in there that people can possibly have experience with. > (except for EAP, but that's common between EAP-o-PCP and EAP-o-PANA). > > > Alper > > > > On Jul 29, 2013, at 12:52 PM, Tassos Chatzithomaoglou wrote: > >> Dave Thaler wrote on 15/07/2013 03:33: >>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. >>> >>> >> YES >>> 2) Could you *live with* PANA? If not, state reason you would object. >>> >>> >> YES >>> 3) If you said yes to both 1 and 2, but have a strong preference between >>> the two, which approach do you prefer and why? >>> >>> . >> EAP-in PCP >> >> Talking strictly as an operator, i first heard of PANA through this WG (when the initial talks about pcp auth were happening). >> I'm not saying PANA won't do the job (maybe better in some areas), i'm just saying that i feel more comfortable working with something i have some experience with, regardless the possible scenario that PANA's learning curve might end up less steep than expected. >> Whatever the vendors decide to implement it's fine by me, as long as there is interoperability between all of them. Operators need something to work. >> >> -- >> Tassos >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > From alper.yegin@yegin.org Mon Jul 29 09:21:23 2013 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 465D521F9C4A for ; Mon, 29 Jul 2013 09:21:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzpspypLbJ-K for ; Mon, 29 Jul 2013 09:21:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 988FB21F93DB for ; Mon, 29 Jul 2013 09:20:57 -0700 (PDT) Received: from [10.119.8.4] (178-32-45-6.ovh.net [178.32.45.6]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MX0u4-1UY1Yd2v6i-00WqR0; Mon, 29 Jul 2013 12:20:56 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <51F682FD.6070701@forthnetgroup.gr> Date: Mon, 29 Jul 2013 19:20:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <13583D53-74B4-46CE-A87A-39531FF72226@yegin.org> References: <51F63B76.2000103@forthnetgroup.gr> <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> <51F682FD.6070701@forthnetgroup.gr> To: Tassos Chatzithomaoglou X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:T/eTg8cyJcbXPXupfE7xBsXOzGvpdKbYkTbKbPkH6N7 Bc2RGxshq1mX6HK1xFCC+iUFv09XrXTSZG64uqIiwLis1QJmeK S2OTzF/z7M38TZg9QraT1lLva1p7LELkW6/FimOrrlHZ6sAj5L LWPbFwpMklj0tcZ0yMGC4dOW2peWjB0w/1byhoIqW5o6bjH7nO 13WTTT2dB09MnkgGmzjKOvL3RlMzRBbeTL2fpXlSqBztRtvfgq P4VC3p8p89GNdqGJOTMLzVk3MbkBpHTRP56zYT/WVQLPMUDdjN sLwFbvQ8htfmdA6qXx64fAJD4BbgMr5yn1iMkHY8uUevoRHPrq yjsa7mF2YdP4VJBmG/axeAyjS7hh/HARuGQ3b/v3j Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 16:21:27 -0000 Hello Tassos, I think there's a misunderstanding in here. The name "EAP over PCP" may give a false comfort to the people, thinking = "I know EAP (RFC 3748), I know PCP (RFC 6887), so it's just implementing = two well-known specs". That's not so.=20 EAP over PCP involves implementation of EAP, PCP, and EAP-o-PCP specs = (draft-ietf-pcp-authentication-0X). All three. This last spec is the so-called "EAP lower layer" according to RFC 3748 = terminology (and that's what PANA is too). So, in that solution too one has an intermediate layer. In other words, In terms of counting entities, there are same number of = entities to deal with. As for comparing the entities with respect to their viability, = completeness, maturity, PANA is several years ahead of = draft-ietf-pcp-authentication. (RFC + implemented + interoperated + = other SDO adopted). Alper =20 The EAP over PCP solution involves an intermediate layer between the EAP = and PCP, which is defined in=20 >=20 > Alper, from an operator's view, i see something like the following: >=20 > EAP over PANA over/with PCP > EAP over PCP >=20 > In the first case i have an intermediate layer which already works = according to your experiences, but adds an unknown entity to = operate/troubleshoot. > In the second case i have a known entity, which must be made to work = in a way that is easy to operate/troubleshoot. >=20 > Really, i don't know if the second case is viable, but i would be = willing to take the risk. =46rom a vendor's view, everything might be = different. > I wish i could have much simpler auth built into PCP from the = beginning (generally i don't enjoy the idea of using something extra), = but that is another talk. >=20 > -- > Tassos >=20 >=20 > Alper Yegin wrote on 29/07/2013 14:46: >> Hello Tassos, >>=20 >> "i'm just saying that i feel more comfortable working with something = i have some experience with," >>=20 >> This statement is alerting me to a possible misunderstanding.=20 >>=20 >> EAP-over-PCP is being invented in PCP WG. There's really nothing in = there that people can possibly have experience with. >> (except for EAP, but that's common between EAP-o-PCP and EAP-o-PANA). >>=20 >>=20 >> Alper >>=20 >>=20 >>=20 >> On Jul 29, 2013, at 12:52 PM, Tassos Chatzithomaoglou wrote: >>=20 >>> Dave Thaler wrote on 15/07/2013 03:33: >>>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would = object. >>>>=20 >>>> >>> YES >>>> 2) Could you *live with* PANA? If not, state reason you would = object. >>>>=20 >>>> >>> YES >>>> 3) If you said yes to both 1 and 2, but have a strong preference = between >>>> the two, which approach do you prefer and why? >>>>=20 >>>> . >>> EAP-in PCP >>>=20 >>> Talking strictly as an operator, i first heard of PANA through this = WG (when the initial talks about pcp auth were happening). >>> I'm not saying PANA won't do the job (maybe better in some areas), = i'm just saying that i feel more comfortable working with something i = have some experience with, regardless the possible scenario that PANA's = learning curve might end up less steep than expected. >>> Whatever the vendors decide to implement it's fine by me, as long as = there is interoperability between all of them. Operators need something = to work. >>>=20 >>> -- >>> Tassos >>>=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 From dthaler@microsoft.com Mon Jul 29 10:30:56 2013 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 B3AE321F9980 for ; Mon, 29 Jul 2013 10:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.828 X-Spam-Level: X-Spam-Status: No, score=-101.828 tagged_above=-999 required=5 tests=[AWL=1.639, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umnPd-1biHEy for ; Mon, 29 Jul 2013 10:30:48 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8E111E8115 for ; Mon, 29 Jul 2013 10:25:37 -0700 (PDT) Received: from mail111-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 17:25:35 +0000 Received: from mail111-tx2 (localhost [127.0.0.1]) by mail111-tx2-R.bigfish.com (Postfix) with ESMTP id 01F584C00B6 for ; Mon, 29 Jul 2013 17:25:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: 4 X-BigFish: VS4(z551biz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail111-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=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail111-tx2 (localhost.localdomain [127.0.0.1]) by mail111-tx2 (MessageSwitch) id 1375118733392080_11781; Mon, 29 Jul 2013 17:25:33 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.239]) by mail111-tx2.bigfish.com (Postfix) with ESMTP id 518C5360046 for ; Mon, 29 Jul 2013 17:25:33 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 17:25:33 +0000 Received: from CO9EHSOBE018.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 29 Jul 2013 17:25:14 +0000 Received: from mail193-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE018.bigfish.com (10.236.130.81) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 17:22:56 +0000 Received: from mail193-co9 (localhost [127.0.0.1]) by mail193-co9-R.bigfish.com (Postfix) with ESMTP id 749B4420067 for ; Mon, 29 Jul 2013 17:22:56 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(46102001)(76482001)(4396001)(81342001)(74706001)(54356001)(74876001)(81542001)(59766001)(54316002)(69226001)(74316001)(80976001)(51856001)(77982001)(53806001)(56776001)(74366001)(33646001)(83322001)(83072001)(49866001)(47736001)(74502001)(56816003)(31966008)(76576001)(74662001)(65816001)(76786001)(16406001)(79102001)(76796001)(77096001)(80022001)(63696002)(47446002)(50986001)(47976001)(24736002)(3826001)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:df8:0:16:9144:1d88:1f3d:8cb4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail193-co9 (localhost.localdomain [127.0.0.1]) by mail193-co9 (MessageSwitch) id 1375118573994086_12381; Mon, 29 Jul 2013 17:22:53 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.227]) by mail193-co9.bigfish.com (Postfix) with ESMTP id E1C50200048; Mon, 29 Jul 2013 17:22:53 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 17:22:53 +0000 Received: from BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 29 Jul 2013 16:37:23 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.731.11; Mon, 29 Jul 2013 16:36:19 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Mon, 29 Jul 2013 16:36:18 +0000 From: Dave Thaler To: Alper Yegin , Tassos Chatzithomaoglou Thread-Topic: [pcp] CONSENSUS CALL on PCP security Thread-Index: Ac6A8r33C+Nqhx9WSI++usK9rdsTXALTqdMAAAPz8IAABrSdgAAC47GAAABgyiA= Date: Mon, 29 Jul 2013 16:36:18 +0000 Message-ID: <33188916e8874eddabcdf533399a088f@BY2PR03MB269.namprd03.prod.outlook.com> References: <51F63B76.2000103@forthnetgroup.gr> <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> <51F682FD.6070701@forthnetgroup.gr> <13583D53-74B4-46CE-A87A-39531FF72226@yegin.org> In-Reply-To: <13583D53-74B4-46CE-A87A-39531FF72226@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:16:9144:1d88:1f3d:8cb4] x-forefront-prvs: 09222B39F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FORTHNETGROUP.GR$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%YEGIN.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 17:30:56 -0000 > The name "EAP over PCP" may give a false comfort to the people, thinking = "I > know EAP (RFC 3748), I know PCP (RFC 6887), so it's just implementing two > well-known specs". >=20 > That's not so. >=20 > EAP over PCP involves implementation of EAP, PCP, and EAP-o-PCP specs > (draft-ietf-pcp-authentication-0X). All three. > This last spec is the so-called "EAP lower layer" according to RFC 3748 > terminology (and that's what PANA is too). > So, in that solution too one has an intermediate layer. > In other words, In terms of counting entities, there are same number of > entities to deal with. If you're counting specs, then I get a different count: "EAP over PCP" =3D 3 specs: EAP, EAP-over-PCP (aka pcp-authentication), and= PCP "EAP-PANA-PCP" =3D 4 specs: EAP, PANA, PANA-with-PCP (e.g. draft-ohba-pcp-p= ana-encap) and PCP. > As for comparing the entities with respect to their viability, completene= ss, > maturity, PANA is several years ahead of draft-ietf-pcp-authentication. (= RFC > + implemented + interoperated + other SDO adopted). My understanding is he's saying that PANA-with-PCP is not several years ahe= ad of EAP-over-PCP. That seems a valid point to me. -Dave From achatz@forthnetgroup.gr Mon Jul 29 13:25:24 2013 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 8BE2B21E809A for ; Mon, 29 Jul 2013 13:25:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp+ltx23pNeV for ; Mon, 29 Jul 2013 13:25:17 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4EA11E812B for ; Mon, 29 Jul 2013 13:25:14 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id r6TKPCVO002537 for ; Mon, 29 Jul 2013 23:25:12 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id r6TKPBjV007369 for ; Mon, 29 Jul 2013 23:25:11 +0300 Received: from [192.168.1.2] (194.219.240.148.dsl.dyn.forthnet.gr [194.219.240.148]) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r6TKPAQr008916; Mon, 29 Jul 2013 23:25:11 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; spf=pass Authentication-Results: MX-IN-05.forthnet.gr header.from=achatz@forthnetgroup.gr; sender-id=pass Message-ID: <51F6CFA5.4040100@forthnetgroup.gr> Date: Mon, 29 Jul 2013 23:25:09 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19 MIME-Version: 1.0 To: "pcp@ietf.org" References: <51F63B76.2000103@forthnetgroup.gr> <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> <51F682FD.6070701@forthnetgroup.gr> <13583D53-74B4-46CE-A87A-39531FF72226@yegin.org> In-Reply-To: <13583D53-74B4-46CE-A87A-39531FF72226@yegin.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 29 Jul 2013 20:25:24 -0000 The differentiation i'm trying to emphasize is that in terms of actual operation i feel like i'm having to compare the following: EAP over a unknown (for me) but "old" transport protocol & this transport protocol over/with PCP EAP over a new but "known" (for me) transport protocol So i'm not actually looking at the development effort needed (which in case of PANA might indeed be less and the developers are the ones that should take that into account most), but on the operation effort from a very high level. I can understand (but not always agree with) the protocol re-usability "rule" of IETF, but if i had to choose between "combine X old solutions" vs "create a new solution", i wouldn't always choose the first. If the vendors (from where i buy from) come back and tell me otherwise, then most probably i'll have to accept their opinion (unless i'm a very large operator, which can drive things the other way around). -- Tassos Alper Yegin wrote on 29/7/2013 19:20: > Hello Tassos, > > > I think there's a misunderstanding in here. > > The name "EAP over PCP" may give a false comfort to the people, thinking "I know EAP (RFC 3748), I know PCP (RFC 6887), so it's just implementing two well-known specs". > > That's not so. > > EAP over PCP involves implementation of EAP, PCP, and EAP-o-PCP specs (draft-ietf-pcp-authentication-0X). All three. > This last spec is the so-called "EAP lower layer" according to RFC 3748 terminology (and that's what PANA is too). > So, in that solution too one has an intermediate layer. > In other words, In terms of counting entities, there are same number of entities to deal with. > > As for comparing the entities with respect to their viability, completeness, maturity, PANA is several years ahead of draft-ietf-pcp-authentication. (RFC + implemented + interoperated + other SDO adopted). > > Alper > > > > > > > > > > > The EAP over PCP solution involves an intermediate layer between the EAP and PCP, which is defined in > > >> Alper, from an operator's view, i see something like the following: >> >> EAP over PANA over/with PCP >> EAP over PCP >> >> In the first case i have an intermediate layer which already works according to your experiences, but adds an unknown entity to operate/troubleshoot. >> In the second case i have a known entity, which must be made to work in a way that is easy to operate/troubleshoot. >> >> Really, i don't know if the second case is viable, but i would be willing to take the risk. From a vendor's view, everything might be different. >> I wish i could have much simpler auth built into PCP from the beginning (generally i don't enjoy the idea of using something extra), but that is another talk. >> >> -- >> Tassos >> >> >> Alper Yegin wrote on 29/07/2013 14:46: >>> Hello Tassos, >>> >>> "i'm just saying that i feel more comfortable working with something i have some experience with," >>> >>> This statement is alerting me to a possible misunderstanding. >>> >>> EAP-over-PCP is being invented in PCP WG. There's really nothing in there that people can possibly have experience with. >>> (except for EAP, but that's common between EAP-o-PCP and EAP-o-PANA). >>> >>> >>> Alper >>> >>> >>> >>> On Jul 29, 2013, at 12:52 PM, Tassos Chatzithomaoglou wrote: >>> >>>> Dave Thaler wrote on 15/07/2013 03:33: >>>>> 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. >>>>> >>>>> >>>> YES >>>>> 2) Could you *live with* PANA? If not, state reason you would object. >>>>> >>>>> >>>> YES >>>>> 3) If you said yes to both 1 and 2, but have a strong preference between >>>>> the two, which approach do you prefer and why? >>>>> >>>>> . >>>> EAP-in PCP >>>> >>>> Talking strictly as an operator, i first heard of PANA through this WG (when the initial talks about pcp auth were happening). >>>> I'm not saying PANA won't do the job (maybe better in some areas), i'm just saying that i feel more comfortable working with something i have some experience with, regardless the possible scenario that PANA's learning curve might end up less steep than expected. >>>> Whatever the vendors decide to implement it's fine by me, as long as there is interoperability between all of them. Operators need something to work. >>>> >>>> -- >>>> Tassos >>>> >>>> _______________________________________________ >>>> 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 rafa.marinlopez@gmail.com Mon Jul 29 13:47:06 2013 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 17C0521E80BE for ; Mon, 29 Jul 2013 13:47:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQBPUdTZLjSK for ; Mon, 29 Jul 2013 13:47:05 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 309AF21E80B9 for ; Mon, 29 Jul 2013 13:47:04 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id jf20so33783bkc.7 for ; Mon, 29 Jul 2013 13:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=j03Guo7+ihI8tmpMkyhnjyx1yEYQ6+b+Haj0lU2hfs4=; b=BOF1M2nPPyroBUkjAOPjJWZnFGbdzzLvKoTIA7T8NQ5TbnTjl6rhBToo3PfbnoryC8 migPdIaDl3667Qo/0moMRBuz47lXYiNTJmsG73ih2082SN5JMsISTkceb3M0rOW0L+yN zKgmvEjEOXqF86zXH1X+M1TgpN+qzDoDLJPtUT1QrjNJ2Aoy9fH/+k4eZo32/y6OcGKv M+tIXyGTB9A0fKUz52iMylI6LJ5JVimO6cTNX9Nxobt5zDv/qM4N6z7qBdaILFvQL4BG ZL/eDgMw6BQrDDm77kiKa0LTK4GdNfITbXPqAgrz3gUCQx8kvLZeI3WwE4hA40nxcYuH yOWQ== X-Received: by 10.204.241.75 with SMTP id ld11mr4241097bkb.35.1375130824000; Mon, 29 Jul 2013 13:47:04 -0700 (PDT) Received: from [10.138.234.159] ([88.128.80.12]) by mx.google.com with ESMTPSA id if11sm16595446bkc.15.2013.07.29.13.47.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 13:47:03 -0700 (PDT) From: Rafa Marin Lopez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jul 2013 22:47:00 +0200 Message-Id: <985E3C5E-E2BB-48DE-914A-A97ED626D2A6@gmail.com> To: pcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [pcp] About OpenPANA license 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, 29 Jul 2013 21:15:40 -0000 Dear all: Today, I have been asked about OpenPANA license for a WG member. In = general, it seems that BSD license would be more acceptable. As I = mentioned some time ago, we do not have any problem to change the = license to any is required or preferred. In any case, we will prepare = next version of OpenPANA based on BSD license. After all, we want people = to use it. Thanks. P.D: My apologies for using a different e-mail now... problems with my = e-mail server.= From sureshk@juniper.net Mon Jul 29 14:51:07 2013 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 7D23521F9BC2; Mon, 29 Jul 2013 14:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.088 X-Spam-Level: * X-Spam-Status: No, score=1.088 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63OHZCMEyoi0; Mon, 29 Jul 2013 14:51:01 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 208D521F9A33; Mon, 29 Jul 2013 14:51:00 -0700 (PDT) Received: from mail11-db9-R.bigfish.com (10.174.16.233) by DB9EHSOBE003.bigfish.com (10.174.14.66) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 21:50:53 +0000 Received: from mail11-db9 (localhost [127.0.0.1]) by mail11-db9-R.bigfish.com (Postfix) with ESMTP id 387F7C0244; Mon, 29 Jul 2013 21:50:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I936eI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail11-db9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=sureshk@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail11-db9 (localhost.localdomain [127.0.0.1]) by mail11-db9 (MessageSwitch) id 1375134651736057_27537; Mon, 29 Jul 2013 21:50:51 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.246]) by mail11-db9.bigfish.com (Postfix) with ESMTP id ADEB7300046; Mon, 29 Jul 2013 21:50:51 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.53) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 21:50:50 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 29 Jul 2013 14:50:48 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Mon, 29 Jul 2013 14:50:48 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 29 Jul 2013 15:03:46 -0700 Received: from mail18-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 21:50:46 +0000 Received: from mail18-tx2 (localhost [127.0.0.1]) by mail18-tx2-R.bigfish.com (Postfix) with ESMTP id 573091A0146; Mon, 29 Jul 2013 21:50:46 +0000 (UTC) Received: from mail18-tx2 (localhost.localdomain [127.0.0.1]) by mail18-tx2 (MessageSwitch) id 1375134574729543_20471; Mon, 29 Jul 2013 21:49:34 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.239]) by mail18-tx2.bigfish.com (Postfix) with ESMTP id 270A14A0245; Mon, 29 Jul 2013 21:49:29 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 21:49:29 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.249]) by BL2PRD0510HT002.namprd05.prod.outlook.com ([10.255.100.37]) with mapi id 14.16.0341.000; Mon, 29 Jul 2013 21:49:26 +0000 From: Suresh Kumar Vinapamula Venkata To: "pcp@ietf.org" , "softwires@ietf.org" Thread-Topic: New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt Thread-Index: AQHOjKV+DqnVR/+wNEag014aVhLhTA== Date: Mon, 29 Jul 2013 21:49:26 +0000 Message-ID: In-Reply-To: <20130729172759.6145.45952.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A39C33B7B41664C8709C7FC91113E39@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [pcp] FW: New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-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: Mon, 29 Jul 2013 21:51:08 -0000 Dear All,=20 We submitted a new draft that sketches a set of recommendations for the possible issues when B4 address changes. Suresh On 7/29/13 10:27 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, >draft-vinapamula-softwire-dslite-prefix-binding-00.txt >has been successfully submitted by Suresh Vinapamula and posted to the >IETF repository. > >Filename: draft-vinapamula-softwire-dslite-prefix-binding >Revision: 00 >Title: Recommendation for Prefix Binding in the Softwire DS-Lite Context >Creation date: 2013-07-29 >Group: Individual Submission >Number of pages: 5 >URL: =20 >http://www.ietf.org/internet-drafts/draft-vinapamula-softwire-dslite-prefi >x-binding-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-prefix-bi >nding >Htmlized: =20 >http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix-binding >-00 > > >Abstract: > This document describes possible issues induced by the change of the > B4 IPv6 address and sketches a set of recommendations. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > From alper.yegin@yegin.org Tue Jul 30 01:42:45 2013 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 A0EDD21F9E53 for ; Tue, 30 Jul 2013 01:42:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBY0CmoQHDRk for ; Tue, 30 Jul 2013 01:42:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8B25F21E80D7 for ; Tue, 30 Jul 2013 01:41:54 -0700 (PDT) Received: from [10.119.8.4] (178-32-45-6.ovh.net [178.32.45.6]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LyX1y-1TySQl23nS-0169wE; Tue, 30 Jul 2013 04:41:53 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <33188916e8874eddabcdf533399a088f@BY2PR03MB269.namprd03.prod.outlook.com> Date: Tue, 30 Jul 2013 11:41:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51F63B76.2000103@forthnetgroup.gr> <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> <51F682FD.6070701@forthnetgroup.gr> <13583D53-74B4-46CE-A87A-39531FF72226@yegin.org> <33188916e8874eddabcdf533399a088f@BY2PR03MB269.namprd03.prod.outlook.com> To: Dave Thaler X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:b0ck37I/X7svidWAVVbGAupeXHqKYHKpnhSIo8HSrF5 TN/4KuUDwS06e4ZZbifcO6X3omp47pmu4EMCqpCTDJkJBc/DRM 8o87CNmMVBqPloTJ/KYLF01Zw+/9snCXFuDdX7UWiJvRhfGeFW iPM2FadzM/QVY3pyBErDptW5EEEFFtHm2P44hsf2sjbXKA5u8j fKXf+24Zhe3TVkkXgDufyISiKyPUQaRSl0+oJg84wtnZiCAjVA dc5MlLAk1CJg0Vfu6keG0yDjh3oroJkqm0cwoANEN38wBHmuxx 534f2b4RPmMbg/h01PTHuLTrCaP3CPLoRXzkD/aYXLaV/xNOL/ dkjpd2+SB8NSmUBwickOSq8TDtBAs0RFCNmJRFZLi Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 30 Jul 2013 08:42:46 -0000 >=20 >> As for comparing the entities with respect to their viability, = completeness, >> maturity, PANA is several years ahead of = draft-ietf-pcp-authentication. (RFC >> + implemented + interoperated + other SDO adopted). >=20 > My understanding is he's saying that PANA-with-PCP is not several = years ahead > of EAP-over-PCP. That seems a valid point to me. >=20 I think that's a very optimistic view, knowing IETF :-) See, it took us several months to convince people that network-initiated = re-auth is needed (for something that obvious, it takes that long in = IETF!), and then after many months their I-D is still not supporting = that essential aspect=85.=20 From alper.yegin@yegin.org Tue Jul 30 01:55:44 2013 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 1762221F944C for ; Tue, 30 Jul 2013 01:55: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+GM4-7Ou1DC for ; Tue, 30 Jul 2013 01:55:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7121F9473 for ; Tue, 30 Jul 2013 01:54:31 -0700 (PDT) Received: from [10.119.8.4] (178-32-45-6.ovh.net [178.32.45.6]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MhR5W-1UhSEb1YJu-00MCSC; Tue, 30 Jul 2013 04:54:15 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <33188916e8874eddabcdf533399a088f@BY2PR03MB269.namprd03.prod.outlook.com> Date: Tue, 30 Jul 2013 11:54:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7C99CC45-96B9-4328-AA62-C9E9BBEE35E4@yegin.org> References: <51F63B76.2000103@forthnetgroup.gr> <182687CD-543A-4B4B-B694-7E81C47220AD@yegin.org> <51F682FD.6070701@forthnetgroup.gr> <13583D53-74B4-46CE-A87A-39531FF72226@yegin.org> <33188916e8874eddabcdf533399a088f@BY2PR03MB269.namprd03.prod.outlook.com> To: Dave Thaler X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:hskHPjT9eDdhYYQ5ykLs1XVld9FVtMAkme6qBLxyI99 hnDWWXSv2sVm+LdNUvxbbpeSDX0t+hWIGy/ExPJ86qd25SrZKU xyB0W6CGMqky5LBmA4n1I/T8ELd03w/Bx0JxRfXkLvFvlOdqPJ oKZPNZFi6SiQfhtpS27d78zSeAwJZQzDVZhLnw8rblADAjRAXD CLgCXTmx0Pb2GYNpDLfhzNXV4Ch28lg3lK1lBpPZLYkSQHzLpA 3qEDm0wiUiZ+xmBMgLt4USKTtcyqwZA3ViowaIb/B6CBBDtyXi ek1A7RCgjcDaBI7XIhQsItQE0CS2T9I/z1TnfTAgDslI1rgM75 DrjJEtS+1hrU+/3Nqs5GG4idpyp5egG0IlIw1jUi6 Cc: "pcp@ietf.org" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 30 Jul 2013 08:55:44 -0000 On Jul 29, 2013, at 7:36 PM, Dave Thaler wrote: >> The name "EAP over PCP" may give a false comfort to the people, = thinking "I >> know EAP (RFC 3748), I know PCP (RFC 6887), so it's just implementing = two >> well-known specs". >>=20 >> That's not so. >>=20 >> EAP over PCP involves implementation of EAP, PCP, and EAP-o-PCP specs >> (draft-ietf-pcp-authentication-0X). All three. >> This last spec is the so-called "EAP lower layer" according to RFC = 3748 >> terminology (and that's what PANA is too). >> So, in that solution too one has an intermediate layer. >> In other words, In terms of counting entities, there are same number = of >> entities to deal with. >=20 > If you're counting specs, then I get a different count: > "EAP over PCP" =3D 3 specs: EAP, EAP-over-PCP (aka = pcp-authentication), and PCP > "EAP-PANA-PCP" =3D 4 specs: EAP, PANA, PANA-with-PCP (e.g. = draft-ohba-pcp-pana-encap) and PCP. I was counting protocol entities in response to intermediate layer = comment. As for counting the number of docs, yes you are correct. If you look at the content though, you see PANA ones are all about = describing how to glue PANA with PCP (hence 3-4 pages of content), = whereas EAP-o-PCP includes the glue + defines the new thing to glue (14 = pages in its incomplete/early stage form). Alper From hartmans@painless-security.com Tue Jul 30 02:33:52 2013 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 F317C21F8B4E for ; Tue, 30 Jul 2013 02:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyQRg0a4Uirw for ; Tue, 30 Jul 2013 02:33:45 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id EAFD821F944C for ; Tue, 30 Jul 2013 02:29:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 65B1C20202 for ; Tue, 30 Jul 2013 05:28:48 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4R2qNjJhdtf for ; Tue, 30 Jul 2013 05:28:48 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-4332.meeting.ietf.org [130.129.67.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Tue, 30 Jul 2013 05:28:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 927E287F9D; Tue, 30 Jul 2013 05:29:21 -0400 (EDT) From: Sam Hartman To: pcp@ietf.org Date: Tue, 30 Jul 2013 05:29:21 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pcp] Authentication consensus call 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, 30 Jul 2013 09:33:52 -0000 I can live with either a PANA-based solution or a EAP over PCP solution. I prefer EAP over PCP because I believe it is easier to implement, debug and inteugrate into an OS or product. >From a security standpoint the two solutions are basically the same. --Sam From dthaler@microsoft.com Tue Jul 30 02:41:19 2013 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 E2C6D21E8063 for ; Tue, 30 Jul 2013 02:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.414 X-Spam-Level: X-Spam-Status: No, score=-100.414 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tqxo672S2nR for ; Tue, 30 Jul 2013 02:41:14 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id D546921E8056 for ; Tue, 30 Jul 2013 02:41:08 -0700 (PDT) Received: from mail31-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE022.bigfish.com (10.3.207.144) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 09:41:08 +0000 Received: from mail31-am1 (localhost [127.0.0.1]) by mail31-am1-R.bigfish.com (Postfix) with ESMTP id CFAFC2A0219 for ; Tue, 30 Jul 2013 09:41:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -72 X-BigFish: VS-72(zz9371Ic89bh936eI542I1432I15caKJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275bh8275dh1de097hz2fh2a8h683h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail31-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=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail31-am1 (localhost.localdomain [127.0.0.1]) by mail31-am1 (MessageSwitch) id 1375177266234452_19923; Tue, 30 Jul 2013 09:41:06 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.247]) by mail31-am1.bigfish.com (Postfix) with ESMTP id 3528234005A for ; Tue, 30 Jul 2013 09:41:06 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 09:41:05 +0000 Received: from db9outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 30 Jul 2013 09:40:41 +0000 Received: from mail11-db9-R.bigfish.com (10.174.16.250) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 09:40:19 +0000 Received: from mail11-db9 (localhost [127.0.0.1]) by mail11-db9-R.bigfish.com (Postfix) with ESMTP id D3A59C021B for ; Tue, 30 Jul 2013 09:40:18 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377424004)(13464003)(55784002)(51704005)(189002)(199002)(377454003)(76576001)(77096001)(83072001)(19580405001)(59766001)(76796001)(54316002)(56776001)(83322001)(54356001)(19580385001)(74876001)(53806001)(74316001)(79102001)(77982001)(49866001)(80976001)(33646001)(56816003)(65816001)(69226001)(47976001)(74366001)(19580395003)(76482001)(74706001)(47736001)(31966008)(81342001)(74502001)(47446002)(46102001)(80022001)(16406001)(50986001)(4396001)(74662001)(51856001)(76786001)(63696002)(81542001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:10.255.93.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail11-db9 (localhost.localdomain [127.0.0.1]) by mail11-db9 (MessageSwitch) id 1375177216932422_24983; Tue, 30 Jul 2013 09:40:16 +0000 (UTC) Received: from DB9EHSMHS008.bigfish.com (unknown [10.174.16.238]) by mail11-db9.bigfish.com (Postfix) with ESMTP id DE605300049; Tue, 30 Jul 2013 09:40:16 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by DB9EHSMHS008.bigfish.com (10.174.14.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 09:40:16 +0000 Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 30 Jul 2013 09:40:15 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.731.11; Tue, 30 Jul 2013 09:40:13 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Tue, 30 Jul 2013 09:40:12 +0000 From: Dave Thaler To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-description-option-01.txt Thread-Index: AQHOVebt5G2QstkWKkeAvUbkEd36XpkQ7z2AgGx09SA= Date: Tue, 30 Jul 2013 09:40:12 +0000 Message-ID: <06e14f544e3143348cf7c10e58c77e84@BY2PR03MB269.namprd03.prod.outlook.com> References: <20130521054741.32449.41106.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36ECFB4A906@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ECFB4A906@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.93.4] x-forefront-prvs: 0923977CCA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORANGE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [pcp] I-D Action: draft-ietf-pcp-description-option-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: Tue, 30 Jul 2013 09:41:20 -0000 I reviewed -01 and am happy with the resolution of my comments. I have one comment on -01. The following paragraph was added to the security considerations in -01: > The DESCRIPTION option could be used to influence the PCP server's > behavior. For example, if the DESCRIPTION option contains a certain > string the PCP server might allocate a mapping from a different IP > address pool or might allow (or disallow) the creation of the mapping > itself. Such overloading of the DESCRIPTION option is out of scope > of this document. If future documents make use of this option to > influence the PCP server decisions, it is the responsibility of those > documents to elaborate on the associated security considerations. I think this paragraph should be removed for the following reasons: * The document does not say anything about normalization or comparison rules for the UTF-8 string. That's fine if it's only used f= or display purposes. It's not fine if anything might use it to match (e.g., to test if it "contains a certain string"). As such, if this p= aragraph were retained I would want to agree on what the rules are in this document, and I'd rather be done and just say it's for display purposes as it does now. * The paragraph doesn't really add anything related to security considerati= ons. * I think using the description would be the wrong way to choose a pool. We do not yet have consensus on suggesting any such thing. As such, if this paragraph is removed then I think it's done. -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Wednesday, May 22, 2013 11:20 AM > To: pcp@ietf.org > Subject: Re: [pcp] I-D Action: draft-ietf-pcp-description-option-01.txt >=20 > Re-, >=20 > This new version integrates the comments received during the WGLC. The > main changes are: >=20 > * Clarify the procedure to follow to update a description > * Clarify the usage of empty DESCRIPTION option > * Provide a suggested max length >=20 > + some editorial changes. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > >internet-drafts@ietf.org Envoy=E9=A0: mardi 21 mai 2013 07:48 =C0=A0: > >i-d-announce@ietf.org Cc=A0: pcp@ietf.org Objet=A0: [pcp] I-D Action: > >draft-ietf-pcp-description-option-01.txt > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Port Control Protocol Working Group > >of the IETF. > > > > Title : PCP Description Option > > Author(s) : Mohamed Boucadair > > Reinaldo Penno > > Dan Wing > > Filename : draft-ietf-pcp-description-option-01.txt > > Pages : 6 > > Date : 2013-05-20 > > > >Abstract: > > This document extends Port Control Protocol (PCP) with the ability to > > associate a description with a PCP-instantiated mapping. It does so > > by defining a new DESCRIPTION option. > > > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-pcp-description-option > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-pcp-description-option-01 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-description-option-01 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >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 From dthaler@microsoft.com Tue Jul 30 03:26:13 2013 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 66BCF21F9644 for ; Tue, 30 Jul 2013 03:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.916 X-Spam-Level: X-Spam-Status: No, score=-101.916 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIBHbR2C3poE for ; Tue, 30 Jul 2013 03:26:06 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id DACEB11E81C4 for ; Tue, 30 Jul 2013 03:26:03 -0700 (PDT) Received: from mail215-tx2-R.bigfish.com (10.9.14.225) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 10:26:03 +0000 Received: from mail215-tx2 (localhost [127.0.0.1]) by mail215-tx2-R.bigfish.com (Postfix) with ESMTP id 22F24AC0164 for ; Tue, 30 Jul 2013 10:26:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371Ic89bhc85dh1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah18c673h186M1de096h5eeeK8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail215-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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail215-tx2 (localhost.localdomain [127.0.0.1]) by mail215-tx2 (MessageSwitch) id 1375179960676448_25491; Tue, 30 Jul 2013 10:26:00 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.225]) by mail215-tx2.bigfish.com (Postfix) with ESMTP id 97942D40046 for ; Tue, 30 Jul 2013 10:26:00 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 10:25:57 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 30 Jul 2013 10:24:56 +0000 Received: from mail220-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE035.bigfish.com (10.243.66.100) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 10:24:55 +0000 Received: from mail220-co1 (localhost [127.0.0.1]) by mail220-co1-R.bigfish.com (Postfix) with ESMTP id 8E61140011B for ; Tue, 30 Jul 2013 10:24:55 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(243025003)(377454003)(74316001)(15202345003)(46102001)(76576001)(16406001)(56816003)(76786001)(74366001)(77982001)(77096001)(4396001)(76796001)(51856001)(74876001)(59766001)(33646001)(83072001)(83322001)(81342001)(19580385001)(19580395003)(19580405001)(31966008)(80022001)(19300405004)(74662001)(79102001)(16236675002)(80976001)(74502001)(47446002)(47976001)(76482001)(53806001)(81542001)(47736001)(56776001)(69226001)(49866001)(50986001)(54356001)(63696002)(54316002)(65816001)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:10.255.93.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail220-co1 (localhost.localdomain [127.0.0.1]) by mail220-co1 (MessageSwitch) id 1375179893741205_8916; Tue, 30 Jul 2013 10:24:53 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.236]) by mail220-co1.bigfish.com (Postfix) with ESMTP id A47D7C6004A; Tue, 30 Jul 2013 10:24:53 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 10:24:51 +0000 Received: from BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 30 Jul 2013 10:24:49 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.731.11; Tue, 30 Jul 2013 10:24:47 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Tue, 30 Jul 2013 10:24:46 +0000 From: Dave Thaler To: "mohamed.boucadair@orange.com" Thread-Topic: Comments on draft-ietf-pcp-nat64-prefix64-02 Thread-Index: Ac5eXnzFuvsf6bqRT0e9D2Vte/Z4hAC03IHwCvceZIA= Date: Tue, 30 Jul 2013 10:24:46 +0000 Message-ID: References: <4ca214b2e2264f409935b918f6b71ab2@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36ED4CCFE93@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED4CCFE93@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.93.4] x-forefront-prvs: 0923977CCA Content-Type: multipart/alternative; boundary="_000_a148a8b89cf142adacf68331001e9e49BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB271.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORANGE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-nat64-prefix64-02 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, 30 Jul 2013 10:26:13 -0000 --_000_a148a8b89cf142adacf68331001e9e49BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I reviewed -03 and am happy with everything (there's a couple grammar nits = in new text I will send separately, but very minor) except one of my comments was not addressed where the text in section 4.2 contradicts itself: > Upon receipt of the message from the PCP server, the PCP client > replaces any old prefix(es)/suffix(es) received from the same PCP > server with the new one(s) included in the PREFIX64 option(s). And > Upon receipt of this message, the PCP client > replaces the old prefix/suffix received from the same PCP server with > the new Pref64::/n and suffix included in the PREFIX64 option. Both imply that a client MUST remember which PCP server they were received = from, since otherwise it could not possibly do what is stated. However, it also says: > The PCP client SHOULD associate each > received Pref64::/n and suffix with the PCP server from which the > Pref64::/n and suffix information was retrieved. Above says it's only a SHOULD and hence contradicts the other two paragraph= s. Changing the SHOULD to a MUST is the simplest fix. -Dave From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Tuesday, June 4, 2013 4:45 PM To: Dave Thaler Cc: pcp@ietf.org Subject: RE: Comments on draft-ietf-pcp-nat64-prefix64-02 Hi Dave, Thank you for the review. I accepted most of your proposed modifications. Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@= ietf.org] De la part de Dave Thaler Envoy=E9 : samedi 1 juin 2013 02:34 =C0 : draft-ietf-pcp-nat64-prefix64@tools.ietf.org Cc : pcp@ietf.org Objet : [pcp] Comments on draft-ietf-pcp-nat64-prefix64-02 Looks pretty good. My marked up copy is at http://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-prefix64-02.pdf (or for those who can use .docx: http://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-prefix64-02.doc= x). Summary: 1) Text appears contradictory as to whether remembering which server a= Pref64 was from is required or just a SHOULD. My preference is to change the SHOUL= D to a MUST, and then the rest of the text is fine. 2) Add reference to draft-ietf-behave-nat64-discovery-heuristic and ex= plain what cases this handles that the simple heuristic cannot. 3) Steal a few phrases from draft-ietf-behave-nat64-discovery-heuristi= c that are applicable here too. 4) Various grammatical corrections/suggestions. -Dave --_000_a148a8b89cf142adacf68331001e9e49BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I reviewed -03 and am = happy with everything (there’s a couple grammar nits in new text=

I will send separately= , but very minor) except one of my comments was not

addressed where the te= xt in section 4.2 contradicts itself:

 

> Upon receipt of the message from the PCP server, the PCP client

> replaces any old prefix(es)/suffix(es) received from the same PCP

> server with the new one(s) included in the PREFIX64 option(s). = ;

And<= /p>

> Upon receipt of this message, the PCP client

> replaces the old prefix/suffix received from the same PCP server wi= th

> the new Pref64::/n and suffix included in the PREFIX64 option.=

 

Both imply that a client MUST remember which PCP server they= were received from,

since otherwise it cou= ld not possibly do what is stated.

 

However, it also says:=

> The PCP client SHOULD associate each

> received Pref64::/n and suffix with the PCP server from which the

> Pref64::/n and suffix information was retrieved. = ;

 

Above says it’s = only a SHOULD and hence contradicts the other two paragraphs.

Changing the SHOULD to= a MUST is the simplest fix.

 

-Dave

 

From: mohamed.boucadair@orange.com [mailto:mo= hamed.boucadair@orange.com]
Sent: Tuesday, June 4, 2013 4:45 PM
To: Dave Thaler
Cc: pcp@ietf.org
Subject: RE: Comments on draft-ietf-pcp-nat64-prefix64-02=

 

Hi Dave,

 

Thank you for the review.

I accepted most of your proposed modificatio= ns.

 

Cheers,

Med

 

De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dave Thaler
Envoy=E9 : samedi 1 juin 2013 02:34
=C0 : draft-ietf-pcp-nat64-prefix64@tools.ietf.org
Cc : pcp@ietf.org
Objet : [pcp] Comments on draft-ietf-pcp-nat64-prefix64-02=

 

Looks pretty good.  My marked up copy is at

http://research.microsoft.com/~dthaler/= draft-ietf-pcp-nat64-prefix64-02.pdf

(or for those who can use .docx:

http://research.microsoft.com/~dthaler= /draft-ietf-pcp-nat64-prefix64-02.docx).

 

Summary:

1)      Text appears contradictory as to whether remembering which server a = Pref64

was from is required or just a SHOULD. My pre= ference is to change the SHOULD

to a MUST, and then the rest of the text is f= ine.

2)      Add reference to draft-ietf-behave-nat64-discovery-heuristic and exp= lain what

cases this handles that the simple heuristic = cannot.

3)      Steal a few phrases from draft-ietf-behave-nat64-discovery-heuristic= that are

applicable here too.

4)      Various grammatical corrections/suggestions.

 

-Dave

--_000_a148a8b89cf142adacf68331001e9e49BY2PR03MB269namprd03pro_-- From margaretw42@gmail.com Tue Jul 30 04:27:11 2013 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 5AA1711E81DA for ; Tue, 30 Jul 2013 04:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6XQUd-PPnqy for ; Tue, 30 Jul 2013 04:27:10 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id E93E521F9EE5 for ; Tue, 30 Jul 2013 04:27:09 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so6577998pdi.11 for ; Tue, 30 Jul 2013 04:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8ax3msdDKzotJQGh1xqNdXg/f/z7ntb0krowTfT5qvU=; b=lvrFuGeOx8mgd8LFpqoRUl1mzRMFDV39AgxVc9wt3otK5/pWz2I29nJ9Cj/GjlWhoe uzVg+wMV0E1uVw2Z+IjUagzKiWJpbHprO80a3LdVOrFZWkrRffz3TcyJmGVZKN5qAcMb ethBU4RT7pgWmm/T4YO00KLlj4SPzhXysTxkRH5v+gIPQoJ0hkb58PtNqTesBpklpJTE UHJ1im9ARB8ZnqsbWj/W3AnJFtxpHqUSaNQUZF4gL7q/Qk9kGGCRq1ZNpfgcWjxLzVxR p0dZrHXetdLwccvrTIPNYh+oTMnbzQtqg4NlQS34ptcv4we0ymInSJl6Oah2yaZOshu4 xY4g== X-Received: by 10.68.100.98 with SMTP id ex2mr13390085pbb.36.1375183629674; Tue, 30 Jul 2013 04:27:09 -0700 (PDT) Received: from ?IPv6:2001:df8::8:9c02:c82c:438d:d376? ([2001:df8:0:8:9c02:c82c:438d:d376]) by mx.google.com with ESMTPSA id iq6sm82603770pbc.1.2013.07.30.04.27.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 04:27:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Margaret Wasserman In-Reply-To: <1A7721F2-825C-412C-A0A8-A7D0A149E3FC@yegin.org> Date: Tue, 30 Jul 2013 13:27:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <913383AAA69FF945B8F946018B75898A14B9AE60@xmb-rcd-x10.cisco.com> <1A7721F2-825C-412C-A0A8-A7D0A149E3FC@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1508) Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] CONSENSUS CALL on PCP security 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, 30 Jul 2013 11:27:11 -0000 I think we should try to reach consensus on a a way forward now. If we = don't get moving, we may not be able to finish any PCP security solution = before the WG disappears, and I think it is important to have a security = solution. Because of that I do not support asking any new questions = now. =46rom my perspective, though, the only PANA solution I can live with is = the encapsulated approach. I understand that it is possible to specify some sort of hack involving = the version fields and/or create a new short header to allow the = side-by-side PANA approach to work on a single port, but I think that is = equally undesirable to running the side-by-side version on two ports. =20= After talking to Subir about his implementation, he indicated that the = PANA messages in his implementation are transmitted inside PCP headers, = which (in my mind) means that he has implemented the encapsulated = option. The fact that he has said that he implements the side-by-side = option makes me concerned that we may not have the same idea of what = those two different options actually are. We will need to make sure we = know exactly what we are comparing before we ask people to choose = between them. Margaret On Jul 16, 2013, at 10:01 PM, Alper Yegin wrote: > Dave, >=20 > Last time we conducted this polling, the two pana-based solutions were = asked separately. > Based on the discussions and the result of the poll, I realized some = people preferred one PANA solution over the other, with possibly varying = preference with respect to the EAP-o-PCP solution. > Bundling them up as one option is not a good idea. > So, I suggest we pose them as separate questions (like we did last = time). After all, they are technically different. >=20 > One other thing:=20 >=20 > I'm not sure if enough thought went into the PCP Proxy security. As = much as I'd love to be DONE! with this discussion, I also want to make = sure people feel comfortable having thought all aspects around the proxy = use. For (very important) example, what kind of security associations = are needed for securing the proxy use: An SA btw client and server, an = SA btw client and proxy, an SA btw proxy and server -- which = combinations of these are needed? Then we need to talk about how we = dynamically create those using any one of these solutions. >=20 > Alper >=20 >=20 >=20 >=20 >=20 > On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote: >=20 >>> -----Original Message----- >>> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >>> Sent: Monday, July 15, 2013 10:51 PM >>> To: Dave Thaler; pcp@ietf.org >>> Subject: RE: [pcp] CONSENSUS CALL on PCP security >>>=20 >>> Hi Dave, >>>=20 >>> In the poll when you refer to PANA, please clarify the draft you are = referring >>> to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or >>> http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ? >>>=20 >>> --Tiru. >>=20 >> The question is intentionally agnostic as this is about a general = approach, >> not which specific implementation. If it helps, you can interpret = the >> answer as "which of the two you think is better". >>=20 >> If the consensus is PANA rather than direct EAP-in-PCP, then we could=20= >> ask as a follow-up question which of the two we should go with. If >> you'd like to include your answer to that now though, feel free to >> include that in your response to the call. >>=20 >> -Dave >>=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 Tue Jul 30 05:03:07 2013 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 57F0321F9EE9 for ; Tue, 30 Jul 2013 05:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdFvGmD02QLp for ; Tue, 30 Jul 2013 05:03:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1B221F9EF4 for ; Tue, 30 Jul 2013 05:02:56 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id EED542DCA8C; Tue, 30 Jul 2013 14:02:54 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D20234C079; Tue, 30 Jul 2013 14:02:54 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 30 Jul 2013 14:02:55 +0200 From: To: Dave Thaler Date: Tue, 30 Jul 2013 14:02:50 +0200 Thread-Topic: Comments on draft-ietf-pcp-nat64-prefix64-02 Thread-Index: Ac5eXnzFuvsf6bqRT0e9D2Vte/Z4hAC03IHwCvceZIAAA4wq0A== Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E8383B@PUEXCB1B.nanterre.francetelecom.fr> References: <4ca214b2e2264f409935b918f6b71ab2@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36ED4CCFE93@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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_94C682931C08B048B7A8645303FDC9F36EE6E8383BPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-nat64-prefix64-02 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, 30 Jul 2013 12:03:07 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EE6E8383BPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for catching this. I agree with the fix. Cheers, Med De : Dave Thaler [mailto:dthaler@microsoft.com] Envoy=E9 : mardi 30 juillet 2013 12:25 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : pcp@ietf.org Objet : RE: Comments on draft-ietf-pcp-nat64-prefix64-02 I reviewed -03 and am happy with everything (there's a couple grammar nits = in new text I will send separately, but very minor) except one of my comments was not addressed where the text in section 4.2 contradicts itself: > Upon receipt of the message from the PCP server, the PCP client > replaces any old prefix(es)/suffix(es) received from the same PCP > server with the new one(s) included in the PREFIX64 option(s). And > Upon receipt of this message, the PCP client > replaces the old prefix/suffix received from the same PCP server with > the new Pref64::/n and suffix included in the PREFIX64 option. Both imply that a client MUST remember which PCP server they were received = from, since otherwise it could not possibly do what is stated. However, it also says: > The PCP client SHOULD associate each > received Pref64::/n and suffix with the PCP server from which the > Pref64::/n and suffix information was retrieved. Above says it's only a SHOULD and hence contradicts the other two paragraph= s. Changing the SHOULD to a MUST is the simplest fix. -Dave From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, June 4, 2013 4:45 PM To: Dave Thaler Cc: pcp@ietf.org Subject: RE: Comments on draft-ietf-pcp-nat64-prefix64-02 Hi Dave, Thank you for the review. I accepted most of your proposed modifications. Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@= ietf.org] De la part de Dave Thaler Envoy=E9 : samedi 1 juin 2013 02:34 =C0 : draft-ietf-pcp-nat64-prefix64@tools.ietf.org Cc : pcp@ietf.org Objet : [pcp] Comments on draft-ietf-pcp-nat64-prefix64-02 Looks pretty good. My marked up copy is at http://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-prefix64-02.pdf (or for those who can use .docx: http://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-prefix64-02.doc= x). Summary: 1) Text appears contradictory as to whether remembering which server a= Pref64 was from is required or just a SHOULD. My preference is to change the SHOUL= D to a MUST, and then the rest of the text is fine. 2) Add reference to draft-ietf-behave-nat64-discovery-heuristic and ex= plain what cases this handles that the simple heuristic cannot. 3) Steal a few phrases from draft-ietf-behave-nat64-discovery-heuristi= c that are applicable here too. 4) Various grammatical corrections/suggestions. -Dave --_000_94C682931C08B048B7A8645303FDC9F36EE6E8383BPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Thanks for catching this. I agree with the fix.

 

Cheers,=

Med

 

= De : Dave Thaler [mailto:dthaler@microsoft.com]
= Envoy=E9 : mardi 30 juillet 2013 12:25
=C0 : BOU= CADAIR Mohamed OLNC/OLN
Cc : pcp@ietf.org
Objet := RE: Comments on draft-ietf-pcp-nat64-prefix64-02

=

 

= I reviewed -03 and am happy with everything (= there’s a couple grammar nits in new text

I will send separately, but ve= ry minor) except one of my comments was not

addressed where the text in sect= ion 4.2 contradicts itself:

 

> Upon receipt of the messag= e from the PCP server, the PCP client

> replaces any old pre= fix(es)/suffix(es) received from the same PCP

> server with = the new one(s) included in the PREFIX64 option(s).  =

And

>= Upon receipt of this message, the PCP client

> replaces the= old prefix/suffix received from the same PCP server with=

> = the new Pref64::/n and suffix included in the PREFIX64 option.<= /o:p>

 

Both imply = that a client MUST remember which PCP server they were received from,

since ot= herwise it could not possibly do what is stated.

 

<= p class=3DMsoNormal>However, it also says:

> The PCP client SHOULD associate each

> receiv= ed Pref64::/n and suffix with the PCP server from which the

> Pref64::/n and suffix information was retrieved. 

 =

Ab= ove says it’s only a SHOULD and hence contradicts the other two parag= raphs.

Changing the SHOULD to a MUST is the simplest fix.

 

-Dave

 

From: m= ohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Tuesday, Ju= ne 4, 2013 4:45 PM
To: Dave Thaler
Cc: pcp@ietf.org
Subject: RE: Comments on draft-i= etf-pcp-nat64-prefix64-02

&n= bsp;

Hi Dave,<= /p>

 

Thank you for the review.

I accepted most of your proposed modifications.

=

 

Cheers,

Med

 

De : pcp-= bounces@ietf.org [mailto:pcp-bo= unces@ietf.org] De la part de Dave Thaler
Envoy=E9 :<= /b> samedi 1 juin 2013 02:34
=C0 : draft-ietf-pcp-nat64-prefix64@tools.= ietf.org
Cc : pcp@ietf.o= rg
Objet : [pcp] Comments on draft-ietf-pcp-nat64-prefix= 64-02

 

Looks pretty good.  = My marked up copy is at

htt= p://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-prefix64-02.pdf

(or for those who can use .docx:<= /o:p>

http://research.microsoft.com/~= dthaler/draft-ietf-pcp-nat64-prefix64-02.docx).

 

Summary:<= /p>

1)  &nbs= p;   Text appears contradictory as to whether remembering = which server a Pref64

was from is= required or just a SHOULD. My preference is to change the SHOULD

to a MUST, and then the rest of the text i= s fine.

2)3)  &nbs= p;   Steal a few phrases from draft-ietf-behave-nat64-disc= overy-heuristic that are

applicab= le here too.

4)      Various grammatical correction= s/suggestions.

 <= /p>

-Dave

= = --_000_94C682931C08B048B7A8645303FDC9F36EE6E8383BPUEXCB1Bnante_-- From dthaler@microsoft.com Tue Jul 30 09:27:07 2013 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 3859E21F9C37 for ; Tue, 30 Jul 2013 09:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.266 X-Spam-Level: X-Spam-Status: No, score=-99.266 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DcUCE+a7epe for ; Tue, 30 Jul 2013 09:27:00 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 43AC721F99DE for ; Tue, 30 Jul 2013 09:26:48 -0700 (PDT) Received: from mail58-db9-R.bigfish.com (10.174.16.237) by DB9EHSOBE021.bigfish.com (10.174.14.84) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 16:26:47 +0000 Received: from mail58-db9 (localhost [127.0.0.1]) by mail58-db9-R.bigfish.com (Postfix) with ESMTP id 1B42ADC004E for ; Tue, 30 Jul 2013 16:26:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: 2 X-BigFish: VS2(zzc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail58-db9: 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 ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail58-db9 (localhost.localdomain [127.0.0.1]) by mail58-db9 (MessageSwitch) id 1375201605120391_20718; Tue, 30 Jul 2013 16:26:45 +0000 (UTC) Received: from DB9EHSMHS016.bigfish.com (unknown [10.174.16.233]) by mail58-db9.bigfish.com (Postfix) with ESMTP id 12A96A00046 for ; Tue, 30 Jul 2013 16:26:45 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS016.bigfish.com (10.174.14.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 16:26:40 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 30 Jul 2013 16:26:39 +0000 Received: from mail219-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE023.bigfish.com (10.243.66.86) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 16:24:44 +0000 Received: from mail219-co1 (localhost [127.0.0.1]) by mail219-co1-R.bigfish.com (Postfix) with ESMTP id E76261000C2 for ; Tue, 30 Jul 2013 16:24:43 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(76576001)(76176001)(15202345003)(46102001)(16406001)(74316001)(76786001)(56816003)(77982001)(74366001)(77096001)(4396001)(81342001)(59766001)(51856001)(33646001)(19580395003)(83072001)(83322001)(19580385001)(76796001)(74876001)(74662001)(80022001)(79102001)(19300405004)(16236675002)(47446002)(47976001)(80976001)(74502001)(63696002)(81542001)(53806001)(54316002)(56776001)(66066001)(49866001)(76482001)(50986001)(47736001)(54356001)(69226001)(31966008)(65816001)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:130.129.71.226; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail219-co1 (localhost.localdomain [127.0.0.1]) by mail219-co1 (MessageSwitch) id 1375201482274699_15451; Tue, 30 Jul 2013 16:24:42 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.253]) by mail219-co1.bigfish.com (Postfix) with ESMTP id 35F40C201DD for ; Tue, 30 Jul 2013 16:24:42 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 16:24:34 +0000 Received: from BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 30 Jul 2013 16:24:33 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.731.11; Tue, 30 Jul 2013 16:24:27 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Tue, 30 Jul 2013 16:24:27 +0000 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Comments on draft-boucadair-pcp-nat-reveal Thread-Index: Ac6NQG7vUcLtFNomRmezt8uCk0BVeQ== Date: Tue, 30 Jul 2013 16:24:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.71.226] x-forefront-prvs: 0923977CCA Content-Type: multipart/alternative; boundary="_000_a65a13b1b4a7432e82719d8f2b0f0ed1BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB271.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [pcp] Comments on draft-boucadair-pcp-nat-reveal 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, 30 Jul 2013 16:27:07 -0000 --_000_a65a13b1b4a7432e82719d8f2b0f0ed1BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read this document, but I don't agree that using PCP is the appropriate w= ay to solve this problem. The problem described can and should be solved using the existing NAT MIB d= ocument in the Behave WG. More generally, any scenario requiring querying (but not changing) NAT stat= e by an authorized entity administered by the same organization is really a managem= ent/monitoring function and should be done by the NAT MIB not by extensions to PCP. We don't need multiple ways to do the same thing. -Dave --_000_a65a13b1b4a7432e82719d8f2b0f0ed1BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<personal opinion, no hats>

 

I read this document, but I don’t agree that u= sing PCP is the appropriate way to solve this problem.

The problem described can and should be solved using= the existing NAT MIB document in

the Behave WG.

 

More generally, any scenario requiring querying (but= not changing) NAT state by an

authorized entity administered by the same organizat= ion is really a management/monitoring

function and should be done by the NAT MIB not by ex= tensions to PCP.

 

We don’t need multiple ways to do the same thi= ng.

 

-Dave

--_000_a65a13b1b4a7432e82719d8f2b0f0ed1BY2PR03MB269namprd03pro_-- From internet-drafts@ietf.org Tue Jul 30 22:18:14 2013 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 2E88F21F9F34; Tue, 30 Jul 2013 22:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu11Z7e46uRv; Tue, 30 Jul 2013 22:18:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC3321F9F21; Tue, 30 Jul 2013 22:18:11 -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.60p1 Message-ID: <20130731051811.19756.10653.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 22:18:11 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-description-option-02.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: Wed, 31 Jul 2013 05:18: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 : PCP Description Option Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-description-option-02.txt Pages : 6 Date : 2013-07-30 Abstract: This document extends Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does so by defining a new DESCRIPTION option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-description-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-description-option-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-description-option-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jul 30 22:21:24 2013 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 CB24321F9306; Tue, 30 Jul 2013 22:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBRgbRLfl4Ye; Tue, 30 Jul 2013 22:21:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5823A21F9339; Tue, 30 Jul 2013 22:21:15 -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.60p1 Message-ID: <20130731052115.17868.14136.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 22:21:15 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-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: Wed, 31 Jul 2013 05:21:25 -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 : Learning NAT64 PREFIX64s using PCP Author(s) : Mohamed Boucadair Filename : draft-ietf-pcp-nat64-prefix64-04.txt Pages : 15 Date : 2013-07-30 Abstract: This document defines a new PCP extension to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This extension is needed for successful communications when IPv4 addresses are used in referrals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-nat64-prefix64-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Tue Jul 30 23:50:20 2013 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 D1A4321F9D52 for ; Tue, 30 Jul 2013 23:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnKyHQZBRlOr for ; Tue, 30 Jul 2013 23:50:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8D021F8EC3 for ; Tue, 30 Jul 2013 23:50:11 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DB21022D22B; Wed, 31 Jul 2013 08:50:09 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B35AD35C045; Wed, 31 Jul 2013 08:50:09 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 31 Jul 2013 08:50:09 +0200 From: To: Dave Thaler , "pcp@ietf.org" Date: Wed, 31 Jul 2013 08:50:07 +0200 Thread-Topic: Comments on draft-boucadair-pcp-nat-reveal Thread-Index: Ac6NQG7vUcLtFNomRmezt8uCk0BVeQAd2lQA Message-ID: <94C682931C08B048B7A8645303FDC9F36EE8628FF1@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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_94C682931C08B048B7A8645303FDC9F36EE8628FF1PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.26.63617 Subject: Re: [pcp] Comments on draft-boucadair-pcp-nat-reveal 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, 31 Jul 2013 06:50:20 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EE8628FF1PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, This is not about a monitoring function but about real-time control signali= ng to help a decision-making entity to make appropriate decisions on the po= licy to be enforced for a new session. The correlation between the internal= and external information is maintained by the NAT/PCP server. IMHO, it is = much more simpler to package this new feature with an existing PCP server w= hich interacts with the active NAT mapping table. The proposed PCP optional extension is really simple. We have a working imp= lementation of the QUERY opcode that showed us this is really trivial to su= pport. MIBs are here from a while but this didn't prevented the emergence of alter= native promising approaches (think about SPPI, PIB, YANG, etc.). Deciding w= hich approach is better for a given context is deployment-specific. Note th= at access to management interfaces is restricted to the management purposes= . Relaxing that restriction may not be an option for some. BTW, if your reasoning was applied to SET method, then PCP wouldn't be spec= ified at all! Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dave = Thaler Envoy=E9 : mardi 30 juillet 2013 18:24 =C0 : pcp@ietf.org Objet : [pcp] Comments on draft-boucadair-pcp-nat-reveal I read this document, but I don't agree that using PCP is the appropriate w= ay to solve this problem. The problem described can and should be solved using the existing NAT MIB d= ocument in the Behave WG. More generally, any scenario requiring querying (but not changing) NAT stat= e by an authorized entity administered by the same organization is really a managem= ent/monitoring function and should be done by the NAT MIB not by extensions to PCP. We don't need multiple ways to do the same thing. -Dave --_000_94C682931C08B048B7A8645303FDC9F36EE8628FF1PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

This is not about a monitoring function but about real-time cont= rol signaling to help a decision-making entity to make appropriate decision= s on the policy to be enforced for a new session. The correlation between t= he internal and external information is maintained by the NAT/PCP server. I= MHO, it is much more simpler to package this new feature with an existing P= CP server which interacts with the active NAT mapping table.

 

= Th= e proposed PCP optional extension is really simple. We have a working imple= mentation of the QUERY opcode that showed us this is really trivial to supp= ort.

 

<= p class=3DMsoNormal>MIBs are here from a while but this didn’t prevente= d the emergence of alternative promising approaches (think about SPPI, PIB,= YANG, etc.). Deciding which approach is better for a given context is depl= oyment-specific. Note that access to management interfaces is restricted to= the management purposes. Relaxing that restriction may not be an option fo= r some.

 

BTW, if your reasoning was applied to SET method, then = PCP wouldn’t be specified at all!

 

Cheers,

Med

&= nbsp;

 

De : pcp-bounces= @ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dave ThalerEnvoy=E9 : mardi 30 juillet 2013 18:24
=C0 : pc= p@ietf.org
Objet : [pcp] Comments on draft-boucadair-pcp-nat= -reveal

 

<personal opinion, no hats>

 

I read thi= s document, but I don’t agree that using PCP is the appropriate way t= o solve this problem.

The problem descri= bed can and should be solved using the existing NAT MIB document in

the Behave WG.

 

More generally, any scenario r= equiring querying (but not changing) NAT state by an

authorized entity administered by the same organization is rea= lly a management/monitoring

function and= should be done by the NAT MIB not by extensions to PCP.

 

We don’t n= eed multiple ways to do the same thing.

=  

-Dave

<= /body>= --_000_94C682931C08B048B7A8645303FDC9F36EE8628FF1PUEXCB1Bnante_--