Food Network Newsletter

From dfhgdfh@dgfhh.com Thu Jan 1 05:26:16 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D8728C57D; Thu, 1 Jan 2009 05:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.017 X-Spam-Level: X-Spam-Status: No, score=-35.017 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0R1mxIhw7HY; Thu, 1 Jan 2009 05:26:15 -0800 (PST) Received: from 093105157140.bpl.vectranet.pl (093105157140.bpl.vectranet.pl [93.105.157.140]) by core3.amsl.com (Postfix) with SMTP id E3B8B28CCFE; Thu, 1 Jan 2009 05:10:34 -0800 (PST) Message-ID: Date: Thu, 01 Jan 2009 08:10:28 -0500 From: "Helga Klein" Subject: Check out the Emporio Armani watches! To: p2prg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Helga, I had never seen such beautiful and greatly-performing watches like the ones I found online at http://www.clippeer.com/ We are offering wholesaler prices on all watches during the month of December. http://www.clippeer.com/ Our Franck Muller have all appropriate markings, wordings and engravings same as orginal. Sincerely, Mr Klein From majy@alpha.ocn.ne.jp Thu Jan 1 17:34:29 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340053A6AC5 for ; Thu, 1 Jan 2009 17:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.192 X-Spam-Level: ** X-Spam-Status: No, score=2.192 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZvYsW7tfOWB for ; Thu, 1 Jan 2009 17:34:28 -0800 (PST) Received: from 201-13-171-49.dial-up.telesp.net.br (201-13-171-49.dial-up.telesp.net.br [201.13.171.49]) by core3.amsl.com (Postfix) with SMTP id 058743A6992 for ; Thu, 1 Jan 2009 17:34:21 -0800 (PST) To: Subject: Happier Days Ahead with our products... From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090102013424.058743A6992@core3.amsl.com> Date: Thu, 1 Jan 2009 17:34:21 -0800 (PST)

Please do not reply to this email. To contact Max Volume, please visit us

This email message was sent to . If you do not wish to receive further communications from Max Volume, click here to unsubscribe.
If you've experience any difficulty in being removed from a Max Volume email list, click here for personalized help.

Copyright Â© 2008 Max Volume, Inc. All rights reserved.
65856 A Alaska, Luissvill, AT 43125

From o_cpeine@abraminterstate.com Thu Jan 1 21:12:36 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94AE43A6A43 for ; Thu, 1 Jan 2009 21:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.367 X-Spam-Level: X-Spam-Status: No, score=-38.367 tagged_above=-999 required=5 tests=[BAYES_80=2, DNS_FROM_OPENWHOIS=1.13, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvZxX9TwyxjD for ; Thu, 1 Jan 2009 21:12:36 -0800 (PST) Received: from 85-18-136-97.fastres.net (85-18-136-97.fastres.net [85.18.136.97]) by core3.amsl.com (Postfix) with SMTP id 4AA7628C1A9 for ; Thu, 1 Jan 2009 21:11:50 -0800 (PST) To: Subject: We have you been, honey? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090102051151.4AA7628C1A9@core3.amsl.com> Date: Thu, 1 Jan 2009 21:11:50 -0800 (PST)

Having trouble viewing this email?
Click here to view as a webpage.

From asp@acyd.com.mx Fri Jan 2 01:23:17 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1050F3A63CB; Fri, 2 Jan 2009 01:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.892 X-Spam-Level: X-Spam-Status: No, score=-17.892 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1icFaQsWBFz1; Fri, 2 Jan 2009 01:23:16 -0800 (PST) Received: from 20151098074.user.veloxzone.com.br (20151098074.user.veloxzone.com.br [201.51.98.74]) by core3.amsl.com (Postfix) with SMTP id 677033A68B6; Fri, 2 Jan 2009 01:22:56 -0800 (PST) Message-ID: Date: Fri, 02 Jan 2009 04:22:48 -0500 From: "Everette Friend" Subject: Breitling watch for a New Year Gift! To: p2prg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Everette, If you've waited to get your Patek Phillipe watch, this is the right time to go for it. http://www.peonmeld.com/ Take advantage of our christmas specials and get yourself {$WATCH$} watch that you've always wanted! http://www.peonmeld.com/ Our Patek Phillipe have all appropriate markings, wordings and engravings same as orginal. Sincerely, Mr Friend From adashi@nho.hosp.go.jp Fri Jan 2 13:02:32 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D98B3A68C0; Fri, 2 Jan 2009 13:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.533 X-Spam-Level: X-Spam-Status: No, score=-12.533 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3bG1lla+Eic; Fri, 2 Jan 2009 13:02:31 -0800 (PST) Received: from ppp91-122-78-177.pppoe.avangarddsl.ru (ppp91-122-78-177.pppoe.avangarddsl.ru [91.122.78.177]) by core3.amsl.com (Postfix) with SMTP id 5E46B28C0E5; Fri, 2 Jan 2009 13:02:10 -0800 (PST) Message-ID: Date: Fri, 02 Jan 2009 16:02:01 -0500 From: "Bernadine Montoya" Subject: Vacheron Constantin watch models from 2009! To: p2prg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Bernadine, How about buying yourself a two Omega watches the same day? It's not impossible, mostly when you can get them for a couple hundred bucks http://www.peonmine.com/ Get two deeply discounted watches and take an extra 15% discount. http://www.peonmine.com/ Our Omega have all appropriate markings, wordings and engravings same as orginal. Sincerely, Mr Montoya From meade@meadeoptical.com Sat Jan 3 11:40:52 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F123A6821; Sat, 3 Jan 2009 11:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.016 X-Spam-Level: X-Spam-Status: No, score=-71.016 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtjBr14oTfLg; Sat, 3 Jan 2009 11:40:50 -0800 (PST) Received: from chello089074034080.chello.pl (chello089074034080.chello.pl [89.74.34.80]) by core3.amsl.com (Postfix) with SMTP id DA8963A69BF; Sat, 3 Jan 2009 11:40:37 -0800 (PST) Message-ID: Date: Sat, 03 Jan 2009 14:40:27 -0500 From: "Bryan Robles" Subject: Jaeger LeCoultre better than you could imagine! To: p2prg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Bryan, New Year is the time to get Chopard watch, and the only place to get top notch watches that look and perform exactly like the originals is http://www.wanemake.com/ Take advantage of our christmas specials and get yourself {$WATCH$} watch that you've always wanted! http://www.wanemake.com/ Our Chopard have Weights/feels and looks exactly same as original. Sincerely, Mr Robles From martin.cormick@agcba.gov.ar Sat Jan 3 14:59:09 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235A43A6894 for ; Sat, 3 Jan 2009 14:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.586 X-Spam-Level: X-Spam-Status: No, score=-21.586 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_HEXIP=2.204, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DK=1.009, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHaHNYelj09C for ; Sat, 3 Jan 2009 14:59:09 -0800 (PST) Received: from 0x50a146c0.naenxx8.dynamic.dsl.tele.dk (0x50a146c0.naenxx8.dynamic.dsl.tele.dk [80.161.70.192]) by core3.amsl.com (Postfix) with SMTP id EAA5C3A63EC for ; Sat, 3 Jan 2009 14:59:07 -0800 (PST) To: Subject: Returned mail: Over quota From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090103225907.EAA5C3A63EC@core3.amsl.com> Date: Sat, 3 Jan 2009 14:59:07 -0800 (PST)

From lunchmote@aktiespararna.se Sun Jan 4 22:44:24 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4D03A6A97 for ; Sun, 4 Jan 2009 22:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.06 X-Spam-Level: X-Spam-Status: No, score=-22.06 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJPxdgHn7miP for ; Sun, 4 Jan 2009 22:44:24 -0800 (PST) Received: from alsde.edu (unknown [121.247.129.69]) by core3.amsl.com (Postfix) with SMTP id 565213A6ABB for ; Sun, 4 Jan 2009 22:44:22 -0800 (PST) To: Subject: Don't disappear now! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105064423.565213A6ABB@core3.amsl.com> Date: Sun, 4 Jan 2009 22:44:22 -0800 (PST)

From mediates88@4sportscards.com Sun Jan 4 22:52:53 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54533A6A97 for ; Sun, 4 Jan 2009 22:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.962 X-Spam-Level: X-Spam-Status: No, score=-34.962 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XpofhOAyvCd for ; Sun, 4 Jan 2009 22:52:53 -0800 (PST) Received: from 007-jamesbond.com (unknown [59.180.188.164]) by core3.amsl.com (Postfix) with SMTP id 7D4E43A6ABB for ; Sun, 4 Jan 2009 22:52:50 -0800 (PST) To: Subject: Your order 67311 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105065251.7D4E43A6ABB@core3.amsl.com> Date: Sun, 4 Jan 2009 22:52:50 -0800 (PST)

From 671steps_forev@surecast.com Sun Jan 4 23:11:21 2009 Return-Path: <671steps_forev@surecast.com> X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01ECE3A6A5A; Sun, 4 Jan 2009 23:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.622 X-Spam-Level: X-Spam-Status: No, score=-15.622 tagged_above=-999 required=5 tests=[AWL=6.547, BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwe2ddRJc6T0; Sun, 4 Jan 2009 23:11:20 -0800 (PST) Received: from host-81-190-221-72.wroclaw.mm.pl (host-81-190-221-72.wroclaw.mm.pl [81.190.221.72]) by core3.amsl.com (Postfix) with SMTP id AB79D3A6AD4; Sun, 4 Jan 2009 23:11:05 -0800 (PST) Message-ID: Date: Mon, 05 Jan 2009 02:11:02 -0500 From: "Justine Mock" Subject: Gucci watch for a New Year Gift! To: p2prg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Justine, I had never seen such beautiful and greatly-performing watches like the ones I found online at http://www.wanewall.com/ From kaspars@amf.lv Mon Jan 5 05:53:23 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06A63A6868 for ; Mon, 5 Jan 2009 05:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.563 X-Spam-Level: X-Spam-Status: No, score=-23.563 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NH7Y3m9cgl1s for ; Mon, 5 Jan 2009 05:53:23 -0800 (PST) Received: from altmancos.com (unknown [189.24.48.97]) by core3.amsl.com (Postfix) with SMTP id E7B673A67AB for ; Mon, 5 Jan 2009 05:53:21 -0800 (PST) To: Subject: Non delivery report: 5.9.4 (Spam SLS/RBL) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105135321.E7B673A67AB@core3.amsl.com> Date: Mon, 5 Jan 2009 05:53:21 -0800 (PST)

Tue, 6 Jan 2009 01:15:21 +0100

Home

HAPPY CHRISTMAS CLICK HERE

From masae@384.jp Tue Jan 6 05:57:26 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B2A3A685C for ; Tue, 6 Jan 2009 05:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.773 X-Spam-Level: X-Spam-Status: No, score=-34.773 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_DHCP=1.295, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biT5YaB-txkk for ; Tue, 6 Jan 2009 05:57:20 -0800 (PST) Received: from nv-71-49-133-112.dhcp.embarqhsd.net (nv-71-49-133-112.dhcp.embarqhsd.net [71.49.133.112]) by core3.amsl.com (Postfix) with SMTP id 77BD73A699E for ; Tue, 6 Jan 2009 05:57:18 -0800 (PST) To: Subject: Returned mail: Over quota From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090106135719.77BD73A699E@core3.amsl.com> Date: Tue, 6 Jan 2009 05:57:18 -0800 (PST)

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

C2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 From pana-bounces@ietf.org Tue Jan 6 12:26:16 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793B93A692F; Tue, 6 Jan 2009 12:26:16 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7403A6817 for ; Tue, 6 Jan 2009 12:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH5IXhAFj1vS for ; Tue, 6 Jan 2009 12:26:13 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 6B8983A67A5 for ; Tue, 6 Jan 2009 12:26:13 -0800 (PST) Received: from steelhead.localdomain (tarij-62.tari.toshiba.com [172.30.24.110]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n06KNg5f042916; Tue, 6 Jan 2009 15:23:42 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.69) (envelope-from ) id 1LKIUk-0000t6-KQ; Tue, 06 Jan 2009 15:25:46 -0500 Date: Tue, 6 Jan 2009 15:25:46 -0500 From: Yoshihiro Ohba To: Qin Wu Message-ID: <20090106202546.GK31353@steelhead.localdomain> References: <20081025144337.GA20427@steelhead.localdomain> <00c701c96338$7120c060$ff5afea9@D50B3A3B0629485> <20081222203954.GC7742@steelhead.localdomain> <000f01c964ad$ba33b340$1c0ca40a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <000f01c964ad$ba33b340$1c0ca40a@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Basavaraj Patil , pana@ietf.org Subject: Re: [Pana] I-D: draft-ietf-pana-preauth X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org Hi Qin, Sorry for my delayed response. Please see my comments below. On Tue, Dec 23, 2008 at 11:22:46AM +0800, Qin Wu wrote: > Dear Yoshihiro: > Thank for your reply, please see my followup comments below. > -Qin > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: "wuqin" > Cc: "Basavaraj Patil" ; > Sent: Tuesday, December 23, 2008 4:39 AM > Subject: Re: [Pana] I-D: draft-ietf-pana-preauth > > > > Hi Qin, > > > > Thank you very much for the review! Please see my comments below. > > > > On Sun, Dec 21, 2008 at 02:50:41PM +0800, wuqin wrote: > >> > >> 1. Introduction > >> > >> The Protocol for carrying Authentication for Network Access (PANA) > >> [RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA > >> (PANA Authentication Agent) in the access network. If the PaC is a > >> mobile device and is capable of moving one access network to another > >> while running its applications, it is critical for the PaC to perform > >> a handover seamlessly without degrading the performance of the > >> applications during the handover period. When the handover requires > >> the PaC to establish a PANA session with the PAA in the new access > >> network, the signaling to establish the PANA session should be > >> completed as fast as possible. > >> > >> [Qin]:Before the mobile device moves, is it true to establish a PANA session with the PAA in the new access network? > > > > Yes. > > > >> How to keep this PANA session uninterruption during the mobile device moves? Which identifier is used to distinguish > >> this PANA session? the old IP address allocated in the old access network? the new IP address allocated in the new access network? > > > > The PANA session is identified by the Session Identifier defined in > > RFC 5141. In the case of PANA pre-authentication, the old IP address > > allocated in the old access network is used for establishing the PANA > > session with the PAA in another access network. > [Qin] The Mobile IP protocol allows the mobile move from one link to another link without changing its "home address". In this way, the transport and high-layer connection can be maintained. In PANA pre-authentication scenario, When the mobile attachs to the new link, the old IP address (i.e., old Care of address) will not be available, Before the mobile gets a new IP address, How can you keep the PANA session uninterruption? I am not sure what 'interruption' means here, but the PANA session is supposed to exist until one of session termination events occur, and handover is not listed as a session termination event. Please see the definition of PANA Session in Section 2 of RFC 5191 for the session termination events. > >> > >> This document defines an extension to the PANA protocol [RFC5191] > >> used for proactively executing EAP authentication and establishing a > >> PANA SA (Security Association) between a PaC in an access network and > >> > >> [Qin]:It mentions after Pre-authentication, PANA SA is required to be established, However > >> withouth key materials derivation and delivery, a PANA SA can not be established. So key materials > >> derivation and delivery mechanism is one integral part of PANA Pre-authentication, is it true? > >> How to perform key materials derivation and delivery during the pre-authentication? > > > > Key derivation and delivery for the candidate PAA is performed in the > > same as normal PANA session, i.e., an MSK is derived and delivered to > > the PAA from EAP server. > [Qin] Since the key derivation and delivery happen before PANA SA establishment and after the successful pre-authentication, the key derivation and delivery is a integral part of pre-authentication. Yes, and we assume the same key derivation and delivery mechanism as for the normal EAP authentication is used for pre-authentication. > >> > >> a PAA in another access network to which the PaC may move. The > >> proposed method operates across multiple AAA domains. > >> > >> [Qin]:What I understand PANA authentication here is one kind of user authentication, However without network entry,i.e., the PaC attaching to the new access network, why the new access network allow a PaC in the previous access network establish a PANA SA with a PAA in the new access network? I wonder for network security consideration, whether a PaC far away from the new Access network can get permission to be remote authentication? > > > > Well, it depends on network access policies which is out of scope of > > this draft. If a PaC is communicating with the candidate PAA from an > > access network that is not allowed for pre-authentication based on the > > policies, then pre-authentication attempt can be rejected. > [Qin] So you agree in some scenario, pana-preauthentication does not work. Actually if my understanding is correct, the existing access network owned by the operator does not support this feature,does it? I guess I miss your point here. I think nothing is wrong if the existing access network owned by the operator does not support pre-authentication. > >> > >> The extension to the PANA protocol is designed to realize direct pre-authentication > >> defined in [I-D.ietf-hokey-preauth-ps]. > >> > >> [Qin]Why PANA protocol is only used to realize direct pre-authentication? Why indirect pre-authentication > >> can not be realized based PANA protocol? > > > > I think technicaly it is possible to use PANA for indirect > > pre-authentication (described in draft-ietf-hokey-preauth-ps) as well. > > However, in indirect pre-autentication, the role of the serving > > authenticator is just forwarding EAP messages between peer and > > candidate authenticator, and hence no EAP peer or authenticator state > > needs to be maintained on the serving authenticator with regard to > > pre-authentication. So I would think that it may be too much for the > > serving authenticator to use PANA for indirect pre-authentication. > [Qin] I can not agree. In the draft-ietf-hokey-preauth-ps-05, it said Indirect pre- > authentication is needed if the peer cannot discover the candidate > authenticator's IP address or if IP communication is not available > due to security or network topology reasons. > It seems what you explain is not consistent with the text mentioned above. > Actually, if the serving authenticator can perform pre-authentication on behalf of the mobile, it will alleviate the overhead of the mobile greatly. What I meant is, there are two pre-authentication sceanarios (i.e., direct pre-auth and indirect pre-auth) and PANA pre-auth is defined as one solution for direct pre-auth. The draft-ietf-hokey-preauth-ps I-D does not mention which pre-authentication scenario is better. > >> > >> When a CPAA with which the PaC has a pre-authorization SA becomes the > >> SPAA due to, e.g., movement of the PaC, the PaC performs an IP > >> address update procedure defined in Section 5.6 of [RFC5191] in order > >> to update the SPAA with the PaC's new address obtained from the new > >> serving network. PANA-Notification-Request (PNR) and PANA- > >> Notification-Answer (PNA) messages with 'P' (Ping) bit set are used > >> for this purpose. The completion of the IP address update procedure > >> will change the pre-authorization SA to a post-authorization SA. In > >> this case, the 'E' MUST NOT be set in the PNR and PNA messages and > >> subsequent PANA messages. > >> > >> [Qin]It seems the IP address udpate procedure is a part of pre-authentication, > >> without IP address udpate, Pre-authentication can not be regarded as completion. > >> However before the IP address is updated, how to make PANA pre-authentication > >> keep service continuity? > > > > According to RFC 5193, the PaC dynamically or statically configures an > > IP address prior to running PANA. So we assume that the new IP > > address is configured prior to completion of post-authorization with > > CPAA. This is certainly possible if lower-layer security for the > > target access network is bootstrapped using the MSK established by > > PANA pre-authentication before obtaining the new IP address. > [Qin] I am confused here. > First, Why the target access network needs to be bootstrapped? I only heard about Bootstapping for the Mobile terminal. I meant bootstrapping the mobile terminal for the target access network. > Second, Since the pre-authoration SA is identified with the old IP address, When the Mobile moves the the target access network and has not obtained the new IP address, the old IP address will not be available, it means the pre-authorization SA is invalid. the PANA session will be interrupted for a while during the handover. In this situation, the PANA pre-authentication should depend on the layer 2 security before the pre-authorization SA becomes the post-authorization SA. When and How is the layer 2 security established? > Before the mobile moves to the target network, whether the layer 2 connection should be maintained? Please see my first comment above how the PANA session is supposed to stay during handover. For enabling L2 ciphering before the pre-authorization SA becomes post-authorization SA, I am assuming use of pana-pemk (http://tools.ietf.org/html/draft-ohba-pana-pemk-02). If this mechanism is not available, then the target access network would have to either allow IP address acquisition before L2 ciphering is enabled or provide no L2 ciphering. > >> > >> If there is another CPAA with which the PaC has a pre-authorization > >> SA and the PaC wants to keep the pre-authorization SA after the > >> change of SPAA, the PaC also performs an IP address update procedure > >> [Qin] Do you mean PANA pre-authentication can work for dual radio case or something else? > > > > PANA pre-authentication can work with single and dual radios (but > > effectiveness for dual radio case may not be so large). > [Qin] I have to point out one thing here, > Dual radios case means the mobile attachs to the old link and the new link simutaneously. Since the PANA pre-authentication support dual radio case, it means not only L3 connection (PANA session) but also L2 connection exist between the peer and the candidate authentication before the mobile moves to the target network, do they? Yes. > >> > >> defined in Section 5.6 of [RFC5191] in order to update the CPAA with > >> the PaC's new address. PNR and PNA messages with 'P' (Ping) bit set > >> is used for this purpose. In this case, the 'E' (prE-authentication) > >> bit MUST be set in the PNR and PNA messages and subsequent PANA > >> messages. The IP address update procedure with the CPAA will not > >> change the pre-authorization SA to a post-authorization SA. > >> > >> [Qin] At the first time when the PaC establish SA with one CPAA, the IP address update procedure > >> with this CPAA can change the pre-authentication SA to a post-authroziation SA? However,At the second time when the Pac establish SA with another CPAA, why the IP adress update procedure with this CPAA can not change the pre-authorization to a post authorization SA? > > > > It depends on 'E' bit settings. If the IP address changes but with > > 'E' bit set, > [Qin]It is a typo here? what you want to said here is "If the IP address changes but without 'E' bit set" This not a typo. If 'E' bit is set for an established PANA session with a pre-authorization SA, then it means that the pre-authorization SA is kept as it is without migrating to post-authorization SA. > >then migration from pre-authentication SA to > > post-authentication SA will not occur. On the other hand, the CPAA > > should allow migration from pre-authentication SA to > > post-authentication SA only from an interface that serves for its > > access network to avoid undesired upgrading to post-authentication SA > > by a remote node. We can add some text on it. > [Qin] It will be better. OK. > My understanding is only when the candidate network is a target network, the pre-authorization SA can become post-ahorization SA. Yes. > Upon one of candidate network becomes the target network, the other candidate network can not be viewed as the target network. also the pre-authoriation SA can not be allowed to become post-authorizaiton SA, it that right? That's right. > > >> > >> > >> The pre-authorization SA and the corresponding PANA session between > >> the PaC and a CPAA is deleted by entering the termination phase of > >> the PANA protocol. > >> > >> Example call flows for PaC-initiated pre-authentication and PAA- > >> initiated pre-authentication are shown in Figure 1 and Figure 2, > >> respectively. > >> [Qin]In the example call flows, which steps are used to generate keying materials? > >> which step is used to establish the SA? > >> How many roundtrips exchange it takes to perform pre-authentication between PaC and CPAA? how long it takes to complete > >> a full pre-authentication? what's the handover performance improvement in constrast with EAP pre-authentication? > > > > Keying material is established with CPAA in the last PAR/PAN exchange > > with 'C' bit set, in the same way as RFC 5191. > Message exchanges > > between PaC and CPAA for pre-authentication are the same as RFC 5191, > > the number of roundtrips depend on the EAP method, > [Qin] what i concern here is in Figure 1: PaC-initiated Pre-authentication Call Flow, there are four piece of message changes before Pre-authroziation, after that, there are two piece of message changes to establish keying materials, It seems you indicate one EAP method is used here. So I suggest to add some text to clarify it. Thanks. Sure, we can add some text that EAP authentication is performed over the PAR-PAN exchanges. > in the same way as > > RFC 5191. The only difference is additional 'E' bit is used in PANA > > pre-auth. > >I don't understand the last question since PANA > > pre-authentication is an EAP pre-authentication. > [Qin] Yeah, the pana is just a protocol to carry EAP message. Thank for your correcting me. > >> > >> 5. Authorization and Accounting Considerations > >> > >> A pre-authorization and a post-authorization for the PaC may have > >> different authorization policies. For example, the pre-authorization > >> policy may not allow the PaC to sent or receive packets through an > >> Enforcement Point (EP) that is under control of the CPAA, while both > >> the pre-authorization and post-authorization policies may allow > >> installing credentials to the EP, where the credentials are used for > >> establishing a security association for per-packet cryptographic > >> filtering. > >> > >> In an access network where accounting is performed, accounting starts > >> when the pre-authorization SA becomes the post-authorization SA by > >> default. > >> [Qin] What's the main difference between pre-authorization SA and post-authorization SA? > >> Only IP address that distinguish these two SA? > > > > We distinguish the two SA based on the 'E' bit settings. It may be > > possible to use IP address solely to distinguish the two SAs, e.g., > > PANA message from IP address that do not belong to the realm of the > > PAA could be associated with a pre-authorization SA. However, I would > > not recommend that scheme because it will be vulnerable to IP address > > spoofing. IMO, it's securer to use proteced indication based on 'E' > > bit (note that 'E' bit is protected in the last PAR/PAN exchange). > [Qin] I want to point out whether or not use IP address to distinguish the two SA, each SA should include IP address. > Also I don't think use on bit of 'E' is more secure than use one IP address. I believe 'E' bit is more secure than IP address because 'E' bit is protected once PANA SA is established while IP address is not protected. Regards, Yoshihiro Ohba > > Thanks, > > Yoshihiro Ohba > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana From kless@abbottexcellence.com Tue Jan 6 13:59:47 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF483A69D2 for ; Tue, 6 Jan 2009 13:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.717 X-Spam-Level: X-Spam-Status: No, score=-4.717 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnFp6M2-F0A7 for ; Tue, 6 Jan 2009 13:59:46 -0800 (PST) Received: from pc-91-92-241-201.cm.vtr.net (pc-91-92-241-201.cm.vtr.net [201.241.92.91]) by core3.amsl.com (Postfix) with SMTP id 786673A69B1 for ; Tue, 6 Jan 2009 13:59:44 -0800 (PST) To: Subject: Here is my number From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090106215945.786673A69B1@core3.amsl.com> Date: Tue, 6 Jan 2009 13:59:44 -0800 (PST)

From admiss@ndnu.edu Tue Jan 6 14:45:25 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E323A69C9; Tue, 6 Jan 2009 14:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.586 X-Spam-Level: X-Spam-Status: No, score=-24.586 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNeEAZkxvydX; Tue, 6 Jan 2009 14:45:25 -0800 (PST) Received: from 190-82-230-243.adsl.tie.cl (190-82-230-243.adsl.tie.cl [190.82.230.243]) by core3.amsl.com (Postfix) with SMTP id 3EC183A6B01; Tue, 6 Jan 2009 14:45:13 -0800 (PST) Message-ID: From: "Kennith Adair" Date: Tue, 06 Jan 2009 17:45:08 -0500 Subject: Tag Heuer cheaper than you could imagine! To: p2prg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Kennith, Looking for a Breitling watch that no one can tell from the original? You're in luck, because we have the best copies http://www.mindmay.com/ Get two deeply discounted watches and take an extra 15% discount. http://www.mindmay.com/ Our Breitling have Weights/feels and looks exactly same as original. Sincerely, Mr Adair From noe@airsight.de Wed Jan 7 15:08:17 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4AF3A6905 for ; Wed, 7 Jan 2009 15:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.507 X-Spam-Level: X-Spam-Status: No, score=-31.507 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOBAgcV1Q83n for ; Wed, 7 Jan 2009 15:08:16 -0800 (PST) Received: from alexmannjobs.com (unknown [190.244.20.55]) by core3.amsl.com (Postfix) with SMTP id CE2C53A67FB for ; Wed, 7 Jan 2009 15:08:15 -0800 (PST) To: Subject: Can't you answer the call? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107230815.CE2C53A67FB@core3.amsl.com> Date: Wed, 7 Jan 2009 15:08:15 -0800 (PST)

From pana-bounces@ietf.org Thu Jan 8 01:29:39 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6AE28C155; Thu, 8 Jan 2009 01:29:39 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 826C928C157 for ; Thu, 8 Jan 2009 01:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTE+1qPCJe4d for ; Thu, 8 Jan 2009 01:29:36 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id ECFEA28C14B for ; Thu, 8 Jan 2009 01:29:35 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD500C41BLEQE@szxga03-in.huawei.com> for pana@ietf.org; Thu, 08 Jan 2009 17:27:14 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD500HGWBLEPR@szxga03-in.huawei.com> for pana@ietf.org; Thu, 08 Jan 2009 17:27:14 +0800 (CST) Received: from w53375a ([10.164.12.28]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD500ID3BLDOK@szxml05-in.huawei.com> for pana@ietf.org; Thu, 08 Jan 2009 17:27:14 +0800 (CST) Date: Thu, 08 Jan 2009 17:27:11 +0800 From: Qin Wu To: Yoshihiro Ohba Message-id: <01dd01c97173$491ee8f0$1c0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <20081025144337.GA20427@steelhead.localdomain> <00c701c96338$7120c060$ff5afea9@D50B3A3B0629485> <20081222203954.GC7742@steelhead.localdomain> <000f01c964ad$ba33b340$1c0ca40a@china.huawei.com> <20090106202546.GK31353@steelhead.localdomain> Cc: Basavaraj Patil , pana@ietf.org Subject: Re: [Pana] I-D: draft-ietf-pana-preauth X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org Hi, Yoshihiro: Thanks for your reply. Please see inline. Best Regards! Qin Wu ----- Original Message ----- From: "Yoshihiro Ohba" To: "Qin Wu" Cc: ; "Basavaraj Patil" Sent: Wednesday, January 07, 2009 4:25 AM Subject: Re: [Pana] I-D: draft-ietf-pana-preauth > Hi Qin, > > Sorry for my delayed response. Please see my comments below. > > On Tue, Dec 23, 2008 at 11:22:46AM +0800, Qin Wu wrote: >> Dear Yoshihiro: >> Thank for your reply, please see my followup comments below. >> -Qin >> ----- Original Message ----- >> From: "Yoshihiro Ohba" >> To: "wuqin" >> Cc: "Basavaraj Patil" ; >> Sent: Tuesday, December 23, 2008 4:39 AM >> Subject: Re: [Pana] I-D: draft-ietf-pana-preauth >> >> >> > Hi Qin, >> > >> > Thank you very much for the review! Please see my comments below. >> > >> > On Sun, Dec 21, 2008 at 02:50:41PM +0800, wuqin wrote: >> >> >> >> 1. Introduction >> >> >> >> The Protocol for carrying Authentication for Network Access (PANA) >> >> [RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA >> >> (PANA Authentication Agent) in the access network. If the PaC is a >> >> mobile device and is capable of moving one access network to another >> >> while running its applications, it is critical for the PaC to perform >> >> a handover seamlessly without degrading the performance of the >> >> applications during the handover period. When the handover requires >> >> the PaC to establish a PANA session with the PAA in the new access >> >> network, the signaling to establish the PANA session should be >> >> completed as fast as possible. >> >> >> >> [Qin]:Before the mobile device moves, is it true to establish a PANA session with the PAA in the new access network? >> > >> > Yes. >> > >> >> How to keep this PANA session uninterruption during the mobile device moves? Which identifier is used to distinguish >> >> this PANA session? the old IP address allocated in the old access network? the new IP address allocated in the new access network? >> > >> > The PANA session is identified by the Session Identifier defined in >> > RFC 5141. In the case of PANA pre-authentication, the old IP address >> > allocated in the old access network is used for establishing the PANA >> > session with the PAA in another access network. >> [Qin] The Mobile IP protocol allows the mobile move from one link to another link without changing its "home address". In this way, the transport and high-layer connection can be maintained. In PANA pre-authentication scenario, When the mobile attachs to the new link, the old IP address (i.e., old Care of address) will not be available, Before the mobile gets a new IP address, How can you keep the PANA session uninterruption? > > I am not sure what 'interruption' means here, but the PANA session is > supposed to exist until one of session termination events occur, and > handover is not listed as a session termination event. Please see the > definition of PANA Session in Section 2 of RFC 5191 for the session > termination events. [Qin] From the defintion of pana session in section 2 of RFC5191, the termination event usually happen in case of failure or authentication exception. I can not see any mechanism to keep session continuity. I wonder whether PANA session need to support mobility? What's the relationship between PANA session and mobile IP session? >> >> >> >> This document defines an extension to the PANA protocol [RFC5191] >> >> used for proactively executing EAP authentication and establishing a >> >> PANA SA (Security Association) between a PaC in an access network and >> >> >> >> [Qin]:It mentions after Pre-authentication, PANA SA is required to be established, However >> >> withouth key materials derivation and delivery, a PANA SA can not be established. So key materials >> >> derivation and delivery mechanism is one integral part of PANA Pre-authentication, is it true? >> >> How to perform key materials derivation and delivery during the pre-authentication? >> > >> > Key derivation and delivery for the candidate PAA is performed in the >> > same as normal PANA session, i.e., an MSK is derived and delivered to >> > the PAA from EAP server. >> [Qin] Since the key derivation and delivery happen before PANA SA establishment and after the successful pre-authentication, the key derivation and delivery is a integral part of pre-authentication. > > Yes, and we assume the same key derivation and delivery mechanism as > for the normal EAP authentication is used for pre-authentication. [Qin] Thanks for your clarification. >> >> >> >> a PAA in another access network to which the PaC may move. The >> >> proposed method operates across multiple AAA domains. >> >> >> >> [Qin]:What I understand PANA authentication here is one kind of user authentication, However without network entry,i.e., the PaC attaching to the new access network, why the new access network allow a PaC in the previous access network establish a PANA SA with a PAA in the new access network? I wonder for network security consideration, whether a PaC far away from the new Access network can get permission to be remote authentication? >> > >> > Well, it depends on network access policies which is out of scope of >> > this draft. If a PaC is communicating with the candidate PAA from an >> > access network that is not allowed for pre-authentication based on the >> > policies, then pre-authentication attempt can be rejected. >> [Qin] So you agree in some scenario, pana-preauthentication does not work. Actually if my understanding is correct, the existing access network owned by the operator does not support this feature,does it? > > I guess I miss your point here. I think nothing is wrong if the > existing access network owned by the operator does not support > pre-authentication. [Qin] You are right. I just want to get your confirmation about whether the existing access network can support pre-authentication mechanism. It is not important now. >> >> >> >> The extension to the PANA protocol is designed to realize direct pre-authentication >> >> defined in [I-D.ietf-hokey-preauth-ps]. >> >> >> >> [Qin]Why PANA protocol is only used to realize direct pre-authentication? Why indirect pre-authentication >> >> can not be realized based PANA protocol? >> > >> > I think technicaly it is possible to use PANA for indirect >> > pre-authentication (described in draft-ietf-hokey-preauth-ps) as well. >> > However, in indirect pre-autentication, the role of the serving >> > authenticator is just forwarding EAP messages between peer and >> > candidate authenticator, and hence no EAP peer or authenticator state >> > needs to be maintained on the serving authenticator with regard to >> > pre-authentication. So I would think that it may be too much for the >> > serving authenticator to use PANA for indirect pre-authentication. >> [Qin] I can not agree. In the draft-ietf-hokey-preauth-ps-05, it said Indirect pre- >> authentication is needed if the peer cannot discover the candidate >> authenticator's IP address or if IP communication is not available >> due to security or network topology reasons. >> It seems what you explain is not consistent with the text mentioned above. >> Actually, if the serving authenticator can perform pre-authentication on behalf of the mobile, it will alleviate the overhead of the mobile greatly. > > What I meant is, there are two pre-authentication sceanarios (i.e., > direct pre-auth and indirect pre-auth) and PANA pre-auth is defined as > one solution for direct pre-auth. The draft-ietf-hokey-preauth-ps I-D > does not mention which pre-authentication scenario is better. [Qin] Correct. Actually what i concern here is in the model(Peer-CA-AAA)model, more threats will be introduced for layer 3 authentication without association with the CA. >> >> >> >> When a CPAA with which the PaC has a pre-authorization SA becomes the >> >> SPAA due to, e.g., movement of the PaC, the PaC performs an IP >> >> address update procedure defined in Section 5.6 of [RFC5191] in order >> >> to update the SPAA with the PaC's new address obtained from the new >> >> serving network. PANA-Notification-Request (PNR) and PANA- >> >> Notification-Answer (PNA) messages with 'P' (Ping) bit set are used >> >> for this purpose. The completion of the IP address update procedure >> >> will change the pre-authorization SA to a post-authorization SA. In >> >> this case, the 'E' MUST NOT be set in the PNR and PNA messages and >> >> subsequent PANA messages. >> >> >> >> [Qin]It seems the IP address udpate procedure is a part of pre-authentication, >> >> without IP address udpate, Pre-authentication can not be regarded as completion. >> >> However before the IP address is updated, how to make PANA pre-authentication >> >> keep service continuity? >> > >> > According to RFC 5193, the PaC dynamically or statically configures an >> > IP address prior to running PANA. So we assume that the new IP >> > address is configured prior to completion of post-authorization with >> > CPAA. This is certainly possible if lower-layer security for the >> > target access network is bootstrapped using the MSK established by >> > PANA pre-authentication before obtaining the new IP address. >> [Qin] I am confused here. >> First, Why the target access network needs to be bootstrapped? I only heard about Bootstapping for the Mobile terminal. > > I meant bootstrapping the mobile terminal for the target access network. [Qin] okay, I see. >> Second, Since the pre-authoration SA is identified with the old IP address, When the Mobile moves the the target access network and has not obtained the new IP address, the old IP address will not be available, it means the pre-authorization SA is invalid. the PANA session will be interrupted for a while during the handover. In this situation, the PANA pre-authentication should depend on the layer 2 security before the pre-authorization SA becomes the post-authorization SA. When and How is the layer 2 security established? >> Before the mobile moves to the target network, whether the layer 2 connection should be maintained? > > Please see my first comment above how the PANA session is supposed to stay during handover. > For enabling L2 ciphering before the pre-authorization SA becomes > post-authorization SA, I am assuming use of pana-pemk > (http://tools.ietf.org/html/draft-ohba-pana-pemk-02). If this > mechanism is not available, then the target access network would have > to either allow IP address acquisition before L2 ciphering is enabled > or provide no L2 ciphering. [Qin] As I replied for your first comments, I can not see. As regarding L2 ciphering enabling, What i understand here is not a L2 connection maintenance but a key distribution. What's more, in some scenarios, the PAC can not establish L2 connection with Candidate PAA before Pac moves to the candidate PAA. based on this, it seems only dual radio case can work for PANA pre-authentication, i.e., the Pac not only attach to the old link but also attach to the new link before the Pac moves to the new PAA. >> >> >> >> If there is another CPAA with which the PaC has a pre-authorization >> >> SA and the PaC wants to keep the pre-authorization SA after the >> >> change of SPAA, the PaC also performs an IP address update procedure >> >> [Qin] Do you mean PANA pre-authentication can work for dual radio case or something else? >> > >> > PANA pre-authentication can work with single and dual radios (but >> > effectiveness for dual radio case may not be so large). >> [Qin] I have to point out one thing here, >> Dual radios case means the mobile attachs to the old link and the new link simutaneously. Since the PANA pre-authentication support dual radio case, it means not only L3 connection (PANA session) but also L2 connection exist between the peer and the candidate authentication before the mobile moves to the target network, do they? > > Yes. >> >> >> >> defined in Section 5.6 of [RFC5191] in order to update the CPAA with >> >> the PaC's new address. PNR and PNA messages with 'P' (Ping) bit set >> >> is used for this purpose. In this case, the 'E' (prE-authentication) >> >> bit MUST be set in the PNR and PNA messages and subsequent PANA >> >> messages. The IP address update procedure with the CPAA will not >> >> change the pre-authorization SA to a post-authorization SA. >> >> >> >> [Qin] At the first time when the PaC establish SA with one CPAA, the IP address update procedure >> >> with this CPAA can change the pre-authentication SA to a post-authroziation SA? However,At the second time when the Pac establish SA with another CPAA, why the IP adress update procedure with this CPAA can not change the pre-authorization to a post authorization SA? >> > >> > It depends on 'E' bit settings. If the IP address changes but with >> > 'E' bit set, >> [Qin]It is a typo here? what you want to said here is "If the IP address changes but without 'E' bit set" > > This not a typo. If 'E' bit is set for an established PANA session > with a pre-authorization SA, then it means that the pre-authorization > SA is kept as it is without migrating to post-authorization SA. > >> >then migration from pre-authentication SA to >> > post-authentication SA will not occur. On the other hand, the CPAA >> > should allow migration from pre-authentication SA to >> > post-authentication SA only from an interface that serves for its >> > access network to avoid undesired upgrading to post-authentication SA >> > by a remote node. We can add some text on it. >> [Qin] It will be better. > > OK. > >> My understanding is only when the candidate network is a target network, the pre-authorization SA can become post-ahorization SA. > > Yes. > >> Upon one of candidate network becomes the target network, the other candidate network can not be viewed as the target network. also the pre-authoriation SA can not be allowed to become post-authorizaiton SA, it that right? > > That's right. > >> >> >> >> >> >> >> The pre-authorization SA and the corresponding PANA session between >> >> the PaC and a CPAA is deleted by entering the termination phase of >> >> the PANA protocol. >> >> >> >> Example call flows for PaC-initiated pre-authentication and PAA- >> >> initiated pre-authentication are shown in Figure 1 and Figure 2, >> >> respectively. >> >> [Qin]In the example call flows, which steps are used to generate keying materials? >> >> which step is used to establish the SA? >> >> How many roundtrips exchange it takes to perform pre-authentication between PaC and CPAA? how long it takes to complete >> >> a full pre-authentication? what's the handover performance improvement in constrast with EAP pre-authentication? >> > >> > Keying material is established with CPAA in the last PAR/PAN exchange >> > with 'C' bit set, in the same way as RFC 5191. >> Message exchanges >> > between PaC and CPAA for pre-authentication are the same as RFC 5191, >> > the number of roundtrips depend on the EAP method, >> [Qin] what i concern here is in Figure 1: PaC-initiated Pre-authentication Call Flow, there are four piece of message changes before Pre-authroziation, after that, there are two piece of message changes to establish keying materials, It seems you indicate one EAP method is used here. So I suggest to add some text to clarify it. Thanks. > > Sure, we can add some text that EAP authentication is performed over > the PAR-PAN exchanges. [Qin] Good. >> in the same way as >> > RFC 5191. The only difference is additional 'E' bit is used in PANA >> > pre-auth. >> >I don't understand the last question since PANA >> > pre-authentication is an EAP pre-authentication. >> [Qin] Yeah, the pana is just a protocol to carry EAP message. Thank for your correcting me. >> >> >> >> 5. Authorization and Accounting Considerations >> >> >> >> A pre-authorization and a post-authorization for the PaC may have >> >> different authorization policies. For example, the pre-authorization >> >> policy may not allow the PaC to sent or receive packets through an >> >> Enforcement Point (EP) that is under control of the CPAA, while both >> >> the pre-authorization and post-authorization policies may allow >> >> installing credentials to the EP, where the credentials are used for >> >> establishing a security association for per-packet cryptographic >> >> filtering. >> >> >> >> In an access network where accounting is performed, accounting starts >> >> when the pre-authorization SA becomes the post-authorization SA by >> >> default. >> >> [Qin] What's the main difference between pre-authorization SA and post-authorization SA? >> >> Only IP address that distinguish these two SA? >> > >> > We distinguish the two SA based on the 'E' bit settings. It may be >> > possible to use IP address solely to distinguish the two SAs, e.g., >> > PANA message from IP address that do not belong to the realm of the >> > PAA could be associated with a pre-authorization SA. However, I would >> > not recommend that scheme because it will be vulnerable to IP address >> > spoofing. IMO, it's securer to use proteced indication based on 'E' >> > bit (note that 'E' bit is protected in the last PAR/PAN exchange). >> [Qin] I want to point out whether or not use IP address to distinguish the two SA, each SA should include IP address. >> Also I don't think use on bit of 'E' is more secure than use one IP address. > > I believe 'E' bit is more secure than IP address because 'E' bit is > protected once PANA SA is established while IP address is not protected. [Qin] What i undestand SA is setup in the Pac and PAA and Each SA will at least contain SPI, src IP address, dst IP address. what you understand 'E' bit will be encrypted during the 'E'bit is carried in the PANA message, am i right? So I guess we talk about the different thing. > Regards, > Yoshihiro Ohba > > >> > Thanks, >> > Yoshihiro Ohba >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www.ietf.org/mailman/listinfo/pana >> _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana From julie.baigent@airsouthwest.com Thu Jan 8 08:02:13 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788A13A6AEB for ; Thu, 8 Jan 2009 08:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.395 X-Spam-Level: X-Spam-Status: No, score=-25.395 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1qechjvsxaG for ; Thu, 8 Jan 2009 08:02:12 -0800 (PST) Received: from almaden.ibm.com (unknown [69.79.51.39]) by core3.amsl.com (Postfix) with SMTP id 228D33A68E0 for ; Thu, 8 Jan 2009 08:02:10 -0800 (PST) To: Subject: Returned mail: User unknown From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090108160211.228D33A68E0@core3.amsl.com> Date: Thu, 8 Jan 2009 08:02:10 -0800 (PST)

From pana-bounces@ietf.org Fri Jan 9 09:32:55 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E108228C127; Fri, 9 Jan 2009 09:32:55 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B28728C127 for ; Fri, 9 Jan 2009 09:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aboxLkBKEdcC for ; Fri, 9 Jan 2009 09:32:53 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 784BB3A6835 for ; Fri, 9 Jan 2009 09:32:53 -0800 (PST) Received: from steelhead.localdomain (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n09HTmvN076265; Fri, 9 Jan 2009 12:30:13 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.69) (envelope-from ) id 1LLJvd-00053Q-LH; Fri, 09 Jan 2009 11:09:45 -0500 Date: Fri, 9 Jan 2009 11:09:40 -0500 From: Yoshihiro Ohba To: Qin Wu Message-ID: <20090109160940.GA10401@steelhead.localdomain> References: <20081025144337.GA20427@steelhead.localdomain> <00c701c96338$7120c060$ff5afea9@D50B3A3B0629485> <20081222203954.GC7742@steelhead.localdomain> <000f01c964ad$ba33b340$1c0ca40a@china.huawei.com> <20090106202546.GK31353@steelhead.localdomain> <01dd01c97173$491ee8f0$1c0ca40a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <01dd01c97173$491ee8f0$1c0ca40a@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Basavaraj Patil , pana@ietf.org Subject: Re: [Pana] I-D: draft-ietf-pana-preauth X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org Hi Qin, On Thu, Jan 08, 2009 at 05:27:11PM +0800, Qin Wu wrote: (snip) > [Qin] From the defintion of pana session in section 2 of RFC5191, the termination event usually happen in case of failure or authentication exception. I can not see any mechanism to keep session continuity. > I wonder whether PANA session need to support mobility? What's the relationship between PANA session and mobile IP session? Mobility aspect is considered in Section 5.6 of RFC 5191, and there is no need for a home address that does not change in order to maintain the IP address change for PANA session. This is because PANA does not carry any application traffic unlike Mobile IP. > > > > What I meant is, there are two pre-authentication sceanarios (i.e., > > direct pre-auth and indirect pre-auth) and PANA pre-auth is defined as > > one solution for direct pre-auth. The draft-ietf-hokey-preauth-ps I-D > > does not mention which pre-authentication scenario is better. > [Qin] Correct. Actually what i concern here is in the model(Peer-CA-AAA)model, more threats will be introduced for layer 3 authentication without association with the CA. Can you elaborate on new threats you consider? > > > > Please see my first comment above how the PANA session is supposed to stay during handover. > > For enabling L2 ciphering before the pre-authorization SA becomes > > post-authorization SA, I am assuming use of pana-pemk > > (http://tools.ietf.org/html/draft-ohba-pana-pemk-02). If this > > mechanism is not available, then the target access network would have > > to either allow IP address acquisition before L2 ciphering is enabled > > or provide no L2 ciphering. > [Qin] As I replied for your first comments, I can not see. Please see my response above for why home address is not needed to maintain the PANA session across IP address changes. > As regarding L2 ciphering enabling, What i understand here is not a L2 connection maintenance but a key distribution. > What's more, in some scenarios, the PAC can not establish L2 connection with Candidate PAA before Pac moves to the candidate PAA. > based on this, it seems only dual radio case can work for PANA pre-authentication, i.e., the Pac not only attach to the old link but also attach to the new link before the Pac moves to the new PAA. There is no need to establish L2 connection in the candidate network before the PaC moves to the candidate PAA. > >> [Qin] I want to point out whether or not use IP address to distinguish the two SA, each SA should include IP address. > >> Also I don't think use on bit of 'E' is more secure than use one IP address. > > > > I believe 'E' bit is more secure than IP address because 'E' bit is > > protected once PANA SA is established while IP address is not protected. > [Qin] What i undestand SA is setup in the Pac and PAA and Each SA will at least contain SPI, src IP address, dst IP address. > what you understand 'E' bit will be encrypted during the 'E'bit is carried in the PANA message, am i right? > So I guess we talk about the different thing. 'E' bit is integrity protected, not encrypted. We don't use the term SPI for PANA. Details on PANA SA is described in Section 5.3 of RFC 5191. Thanks, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana From morton@acmebrick.com Fri Jan 9 18:05:44 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494893A6930 for ; Fri, 9 Jan 2009 18:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.647 X-Spam-Level: X-Spam-Status: No, score=-23.647 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWcoHCKZmazA for ; Fri, 9 Jan 2009 18:05:43 -0800 (PST) Received: from 201-92-64-159.dsl.telesp.net.br (201-92-64-159.dsl.telesp.net.br [201.92.64.159]) by core3.amsl.com (Postfix) with SMTP id 2D0923A63D3 for ; Fri, 9 Jan 2009 18:05:41 -0800 (PST) To: Subject: Your order 06435 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110020542.2D0923A63D3@core3.amsl.com> Date: Fri, 9 Jan 2009 18:05:41 -0800 (PST)

From machadoo@ahrana.gov.br Sat Jan 10 05:07:31 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231AF28C198 for ; Sat, 10 Jan 2009 05:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.391 X-Spam-Level: X-Spam-Status: No, score=-29.391 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+waA3AM60Do for ; Sat, 10 Jan 2009 05:07:30 -0800 (PST) Received: from potts.plus.com (potts.plus.com [195.166.158.210]) by core3.amsl.com (Postfix) with SMTP id 62CBC28C0D9 for ; Sat, 10 Jan 2009 05:07:28 -0800 (PST) To: Subject: Re: Order status 45063 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110130729.62CBC28C0D9@core3.amsl.com> Date: Sat, 10 Jan 2009 05:07:28 -0800 (PST)

From nistracion@alcer.info Sat Jan 10 10:24:56 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240023A6A84 for ; Sat, 10 Jan 2009 10:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.202 X-Spam-Level: X-Spam-Status: No, score=-46.202 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4F4RT-JeISwa for ; Sat, 10 Jan 2009 10:24:55 -0800 (PST) Received: from adm.fukuoka-u.ac.jp (unknown [89.250.164.209]) by core3.amsl.com (Postfix) with SMTP id 84DC63A68C8 for ; Sat, 10 Jan 2009 10:24:52 -0800 (PST) To: Subject: Your order 51050 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110182453.84DC63A68C8@core3.amsl.com> Date: Sat, 10 Jan 2009 10:24:52 -0800 (PST)

From myers@acutecprecision.com Mon Jan 12 00:57:50 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1161528C2D7 for ; Mon, 12 Jan 2009 00:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.241 X-Spam-Level: X-Spam-Status: No, score=-14.241 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_IS_SMALL6=0.556, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KBw1WYbeIP2 for ; Mon, 12 Jan 2009 00:57:49 -0800 (PST) Received: from aget.gr (unknown [78.128.4.242]) by core3.amsl.com (Postfix) with SMTP id 41E7528C2D0 for ; Mon, 12 Jan 2009 00:57:47 -0800 (PST) To: Subject: RE: Message 76821 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112085748.41E7528C2D0@core3.amsl.com> Date: Mon, 12 Jan 2009 00:57:47 -0800 (PST)

From m.hayamazwai@amada.co.jp Mon Jan 12 02:16:51 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9C428C30D for ; Mon, 12 Jan 2009 02:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.204 X-Spam-Level: X-Spam-Status: No, score=-26.204 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-CB7Hy1TSUl for ; Mon, 12 Jan 2009 02:16:51 -0800 (PST) Received: from advdigtech.com (unknown [81.213.125.151]) by core3.amsl.com (Postfix) with SMTP id DA84E28C305 for ; Mon, 12 Jan 2009 02:16:49 -0800 (PST) To: Subject: Your order 80489 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112101649.DA84E28C305@core3.amsl.com> Date: Mon, 12 Jan 2009 02:16:49 -0800 (PST)

From creativeservices@matthau.com Mon Jan 12 07:06:42 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03CCF3A69F0; Mon, 12 Jan 2009 07:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.737 X-Spam-Level: X-Spam-Status: No, score=-12.737 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DSL=1.129, HELO_MISMATCH_NET=0.611, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqJidbAVYJGl; Mon, 12 Jan 2009 07:06:41 -0800 (PST) Received: from 190.75-108-69.dyn.dsl.cantv.net (unknown [190.75.108.69]) by core3.amsl.com (Postfix) with SMTP id E47643A6955; Mon, 12 Jan 2009 07:06:26 -0800 (PST) X-Originating-IP: 150.56.68.64 by smtp.190.75.108.69; Mon, 12 Jan 2009 11:00:14 -0300 Message-ID: Subject: Jaeger LeCoultre watch models from 2009! Date: Mon, 12 Jan 2009 09:06:14 -0500 From: "Kerry Jenkins" To: "Tony Wood" Content-Type: text/plain; Content-Transfer-Encoding: 7bit Dear Tony, Looking for a Breitling? How about getting two, one for you and one for your spouse? http://www.tallrole.com/ From ariella@fashiondirect.ca Mon Jan 12 23:55:39 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93833A6936; Mon, 12 Jan 2009 23:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvnIFh6j+WGi; Mon, 12 Jan 2009 23:55:39 -0800 (PST) Received: from cable201-233-108-148.epm.net.co (cable201-233-108-148.epm.net.co [201.233.108.148]) by core3.amsl.com (Postfix) with SMTP id 37B163A67D1; Mon, 12 Jan 2009 23:55:23 -0800 (PST) X-Originating-IP: 104.32.0.218 by smtp.201.233.108.148; Tue, 13 Jan 2009 05:55:10 -0100 Message-ID: Subject: Vacheron Constantin better than you could imagine! Date: Tue, 13 Jan 2009 01:55:10 -0500 From: "Socorro Donovan" To: "Kristy Gilbert" Content-Type: text/plain; Content-Transfer-Encoding: 7bit Dear Kristy, Looking for a Gucci? How about getting two, one for you and one for your spouse? http://www.tallroll.com/ The best news is that in January (2009) you can buy two watches and get an extra 15% off your purchase! http://www.tallroll.com/ Our Gucci watches have all appropriate markings, wordings and engravings same as orginal. Sincerely, Mr Gilbert From kathy_turner@agri-fab.com Tue Jan 13 01:07:12 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDBA3A68FC for ; Tue, 13 Jan 2009 01:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.442 X-Spam-Level: X-Spam-Status: No, score=-21.442 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btZSOei9Wd1Q for ; Tue, 13 Jan 2009 01:07:12 -0800 (PST) Received: from host92-37-dynamic.7-79-r.retail.telecomitalia.it (host92-37-dynamic.7-79-r.retail.telecomitalia.it [79.7.37.92]) by core3.amsl.com (Postfix) with SMTP id 2ED1B3A677C for ; Tue, 13 Jan 2009 01:07:07 -0800 (PST) To: Subject: Re: Order status 40314 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113090709.2ED1B3A677C@core3.amsl.com> Date: Tue, 13 Jan 2009 01:07:07 -0800 (PST)

From contracts@msp-asia.com Tue Jan 13 09:29:07 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8D428C127; Tue, 13 Jan 2009 09:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.451 X-Spam-Level: X-Spam-Status: No, score=-38.451 tagged_above=-999 required=5 tests=[AWL=-2.483, BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjH-z+9srvi0; Tue, 13 Jan 2009 09:29:06 -0800 (PST) Received: from 187-41-124-91.pool.ukrtel.net (187-41-124-91.pool.ukrtel.net [91.124.41.187]) by core3.amsl.com (Postfix) with SMTP id BB5583A67D7; Tue, 13 Jan 2009 09:28:43 -0800 (PST) X-Originating-IP: 179.92.68.224 by smtp.91.124.41.187; Tue, 13 Jan 2009 20:28:30 +0400 Message-ID: Subject: Gucci cheaper than you could imagine! Date: Tue, 13 Jan 2009 11:28:30 -0500 From: "Amanda Barton" To: "Harriet Cornell" Content-Type: text/plain; Content-Transfer-Encoding: 7bit Dear Harriet, Looking for a Tag Heuer? How about getting two, one for you and one for your spouse? http://www.tallrole.com/ With top notch customer service and super warranty, we stand behind our watches. http://www.tallrole.com/ Our Tag Heuer watches have perfect weight and feel same as orginal. Sincerely, Mr Cornell From czb@cnpolice.sina.net Tue Jan 13 18:24:46 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C623A6A4A; Tue, 13 Jan 2009 18:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.301 X-Spam-Level: X-Spam-Status: No, score=-19.301 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1upvBdNoJNLO; Tue, 13 Jan 2009 18:24:45 -0800 (PST) Received: from 212-237-20-190.adsl.terra.cl (212-237-20-190.adsl.terra.cl [190.20.237.212]) by core3.amsl.com (Postfix) with SMTP id 831923A6AA7; Tue, 13 Jan 2009 18:24:35 -0800 (PST) X-Originating-IP: 169.172.119.60 by smtp.190.20.237.212; Tue, 13 Jan 2009 20:20:22 -0500 Message-ID: Subject: Emporio Armani watch models from 2009! Date: Tue, 13 Jan 2009 20:24:22 -0500 From: "Alvaro Laird" To: "Reed Hatch" Content-Type: text/plain; Content-Transfer-Encoding: 7bit Dear Reed, Looking for a Chopard watch that no one can tell from the original? You're in luck, because we have the best copies http://www.tallrole.com/ We are offering wholesaler prices on all watches during the month of January 2009. http://www.tallrole.com/ Our Chopard watches have all appropriate markings, wordings and engravings same as orginal. Sincerely, Mr Hatch From mail@alexandriametalfinishers.com Wed Jan 14 02:43:57 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7673A68BC for ; Wed, 14 Jan 2009 02:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.962 X-Spam-Level: X-Spam-Status: No, score=-10.962 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFTyaZQyEoGK for ; Wed, 14 Jan 2009 02:43:55 -0800 (PST) Received: from alphatechconcepts.com (unknown [59.183.31.44]) by core3.amsl.com (Postfix) with SMTP id D03083A686C for ; Wed, 14 Jan 2009 02:43:53 -0800 (PST) To: Subject: Your order 95851 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114104353.D03083A686C@core3.amsl.com> Date: Wed, 14 Jan 2009 02:43:53 -0800 (PST)

From graphics@screenmaster.net Wed Jan 14 06:20:39 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42F23A69D3; Wed, 14 Jan 2009 06:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.174 X-Spam-Level: X-Spam-Status: No, score=-88.174 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT--YMDVbNS0; Wed, 14 Jan 2009 06:20:39 -0800 (PST) Received: from tdev227-127.codetel.net.do (unknown [201.229.227.127]) by core3.amsl.com (Postfix) with SMTP id ED19928C1A4; Wed, 14 Jan 2009 06:20:08 -0800 (PST) X-Originating-IP: 144.0.8.144 by smtp.201.229.227.127; Wed, 14 Jan 2009 18:15:53 +0500 Message-ID: Subject: Vacheron Constantin cheaper than you could imagine! Date: Wed, 14 Jan 2009 08:19:53 -0500 From: "Mercedes Jewell" To: "Lance Rodrigues" Content-Type: text/plain; Content-Transfer-Encoding: 7bit Dear Lance, How about buying yourself a two Omega watches the same day? It's not impossible, mostly when you can get them for a couple hundred bucks http://kellycue.narod.ru Get two deeply discounted watches and take an extra 15% discount. http://kellycue.narod.ru Our Omega watches have perfect weight and feel same as orginal. Sincerely, Mr Rodrigues From pana-bounces@ietf.org Thu Jan 15 01:38:46 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2593A688D; Thu, 15 Jan 2009 01:38:46 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CDC3A67E6 for ; Thu, 15 Jan 2009 01:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt8CtMHB54nx for ; Thu, 15 Jan 2009 01:38:44 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 2D1DE3A67A1 for ; Thu, 15 Jan 2009 01:38:44 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LNOgD2xJ1-000SnH; Thu, 15 Jan 2009 04:38:29 -0500 From: "Alper Yegin" To: "'Basavaraj Patil'" , References: In-Reply-To: Date: Thu, 15 Jan 2009 11:38:20 +0200 Message-ID: <04b201c976f5$0367a900$0a36fb00$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclxypjwUb/ucBgcPkWQM0vASiINfQFJoSXQ Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18n5hQK+G2Oi2MW4NFa/uWCUCWtxNA+35eIWYM I4EWMGRhtlI5h94uPrVM40doy9/oVqU83JBdIWxUm2pNOafUJ8 9B+0wQQ8aCHSBTDZj3hjA== Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org Here are my comments. - "The PCI message MUST be unicast." Not sure why we have such a constraint. Does using a non-unicast address break anything? If not, let's not be constraining the spec unnecessarily. Not that I see any use for this right away, but I don't see a reason to prohibit future possibilities unless we see a value in having such a constraint. - "Once the PaC and CPAA have agreed on performing pre-authentication using the 'S' (Start) and 'E' (prE-authentication) bits, the subsequent PANA messages exchanged between them MUST have the 'E' (prE-authentication) bit set." Not forever, right? We shall state "... MUST have the 'E' bit set until CPAA becomes SPAA of the PaC". - I didn't understand the utility of "Pre-authorization SA" and "Pre-authorization SA" distinction. There is only one PANA SA. It does not change when the PaC attaches to the target network. - In an access network where accounting is performed, accounting starts when the pre-authorization SA becomes the post-authorization SA by default. Depending on the pre-authorization policy, accounting may start immediately after the pre-authorization SA is established. This spec should not care when acct starts. - Since the mechanism described in this document is designed to work across multiple access networks, each EP in the serving network SHOULD be configured to allow PANA messages to be forwarded between a PaC and a CPAA only if the PaC has a post-authorization SA with the SPAA in order to avoid an unauthorized PaC to initiate pre- authentication. Not sure why we have to say anything like that. PANA pre-auth is just UDP. Unless the serving network "intends to block" pre-auth, it would not be preventing pre-auth. An EP should allow PANA messages from unauthorized only if they are destined to SPAA. So, it should not blindly allow PANA messages. They may not only allow pre-authentication (not that harmful), but they may even piggyback some data to punch a hole through EP. I guess this is what the spec intends to talk about, but it was not that clear to me from reading it. - The pre-authentication mechanism defined in this document does not have an issue on context binding in which link-layer independent context carried over pre-authentication signaling is bound to the link-layer specific context [I-D.ietf-hokey-preauth-ps], because the same EAP transport protocol (i.e., PANA) is used for normal authentication and pre-authentication in the candidate network. This does not even describe what the issue could be. I don't see a value in having this paragraph here. Editorial: - If the PaC is a mobile device and is capable of moving one access network to another while running its applications, s/moving one/moving from one - allow the PaC to sent or receive packets s/sent/send Thank you. Alper > -----Original Message----- > From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On Behalf Of > Basavaraj Patil > Sent: Thursday, January 08, 2009 9:52 PM > To: pana@ietf.org > Subject: [Pana] WG LC: Pre-authentication Support for PANA > > > > Hello, > > This is a WG last call for I-D: Pre-authentication Support for PANA > . > > The last call will end on January 22nd, 09. Please send your comments > to the mailing list prior to the deadline. > > -Chairs > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana From mkp@anadolu.edu.tr Thu Jan 15 02:13:33 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372FD3A68DB for ; Thu, 15 Jan 2009 02:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.694 X-Spam-Level: X-Spam-Status: No, score=-13.694 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69cHj91rgf87 for ; Thu, 15 Jan 2009 02:13:26 -0800 (PST) Received: from adsl-186-49.globonet.hu (adsl-186-49.globonet.hu [82.144.186.49]) by core3.amsl.com (Postfix) with SMTP id 5871C3A67E6 for ; Thu, 15 Jan 2009 02:13:22 -0800 (PST) To: Subject: RE: message 48412 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115101324.5871C3A67E6@core3.amsl.com> Date: Thu, 15 Jan 2009 02:13:22 -0800 (PST)

From pana-bounces@ietf.org Thu Jan 15 12:05:27 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D1A3A69E8; Thu, 15 Jan 2009 12:05:27 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4AC3A68B6 for ; Thu, 15 Jan 2009 12:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2NR14AOWuZl for ; Thu, 15 Jan 2009 12:05:25 -0800 (PST) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by core3.amsl.com (Postfix) with SMTP id 3F8603A6891 for ; Thu, 15 Jan 2009 12:05:25 -0800 (PST) Received: (qmail 28372 invoked from network); 15 Jan 2009 20:03:03 -0000 Received: from unknown (67.160.38.190) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 15 Jan 2009 20:03:02 -0000 From: "Glen Zorn" To: "'Alper Yegin'" , "'Basavaraj Patil'" References: <04b201c976f5$0367a900$0a36fb00$@yegin@yegin.org> In-Reply-To: <04b201c976f5$0367a900$0a36fb00$@yegin@yegin.org> Date: Thu, 15 Jan 2009 12:02:25 -0800 Organization: Network Zen Message-ID: <004401c9774c$302794d0$9076be70$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclxypjwUb/ucBgcPkWQM0vASiINfQFJoSXQABZ4/YA= Content-Language: en-us Cc: pana@ietf.org Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org Second try: is it the opinion of the WG Chairs that there is firm consensus around this document? If so, may I ask what this determination is based upon, given the ongoing discussions on this list? > -----Original Message----- > From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On Behalf Of > Alper Yegin > Sent: Thursday, January 15, 2009 1:38 AM > To: 'Basavaraj Patil'; pana@ietf.org > Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA > > Here are my comments. > > > - "The PCI message MUST be unicast." > > Not sure why we have such a constraint. Does using a non-unicast > address > break anything? If not, let's not be constraining the spec > unnecessarily. > Not that I see any use for this right away, but I don't see a reason to > prohibit future possibilities unless we see a value in having such a > constraint. > > > - "Once the PaC and CPAA have agreed on performing pre-authentication > using the 'S' (Start) and 'E' (prE-authentication) bits, the > subsequent PANA messages exchanged between them MUST have the 'E' > (prE-authentication) bit set." > > Not forever, right? We shall state "... MUST have the 'E' bit set until > CPAA > becomes SPAA of the PaC". > > - I didn't understand the utility of "Pre-authorization SA" and > "Pre-authorization SA" distinction. There is only one PANA SA. It does > not > change when the PaC attaches to the target network. > > - In an access network where accounting is performed, accounting > starts > when the pre-authorization SA becomes the post-authorization SA by > default. Depending on the pre-authorization policy, accounting may > start immediately after the pre-authorization SA is established. > > > This spec should not care when acct starts. > > - Since the mechanism described in this document is designed to work > across multiple access networks, each EP in the serving network > SHOULD be configured to allow PANA messages to be forwarded between > a > PaC and a CPAA only if the PaC has a post-authorization SA with the > SPAA in order to avoid an unauthorized PaC to initiate pre- > authentication. > > Not sure why we have to say anything like that. PANA pre-auth is just > UDP. > Unless the serving network "intends to block" pre-auth, it would not be > preventing pre-auth. > > An EP should allow PANA messages from unauthorized only if they are > destined > to SPAA. > So, it should not blindly allow PANA messages. They may not only allow > pre-authentication (not that harmful), but they may even piggyback some > data > to punch a hole through EP. I guess this is what the spec intends to > talk > about, but it was not that clear to me from reading it. > > - The pre-authentication mechanism defined in this document does not > have an issue on context binding in which link-layer independent > context carried over pre-authentication signaling is bound to the > link-layer specific context [I-D.ietf-hokey-preauth-ps], because the > same EAP transport protocol (i.e., PANA) is used for normal > authentication and pre-authentication in the candidate network. > > > This does not even describe what the issue could be. I don't see a > value in > having this paragraph here. > > > Editorial: > > - If the PaC is a > mobile device and is capable of moving one access network to another > while running its applications, > > s/moving one/moving from one > > > - allow the PaC to sent or receive packets > > s/sent/send > > > Thank you. > > Alper > > > > > > > -----Original Message----- > > From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On Behalf > Of > > Basavaraj Patil > > Sent: Thursday, January 08, 2009 9:52 PM > > To: pana@ietf.org > > Subject: [Pana] WG LC: Pre-authentication Support for PANA > > > > > > > > Hello, > > > > This is a WG last call for I-D: Pre-authentication Support for PANA > > . > > > > The last call will end on January 22nd, 09. Please send your comments > > to the mailing list prior to the deadline. > > > > -Chairs > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jan 15 12:19:17 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8D73A69F6; Thu, 15 Jan 2009 12:19:17 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98CD3A69F6 for ; Thu, 15 Jan 2009 12:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhBEddGAo576 for ; Thu, 15 Jan 2009 12:19:14 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7DF783A69B0 for ; Thu, 15 Jan 2009 12:19:14 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0FKIrqT023946; Thu, 15 Jan 2009 22:18:57 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 22:18:40 +0200 Received: from vaebe112.NOE.Nokia.com ([10.160.244.81]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 22:18:39 +0200 Received: from 172.19.60.146 ([172.19.60.146]) by vaebe112.NOE.Nokia.com ([10.160.244.81]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jan 2009 20:18:39 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 15 Jan 2009 14:18:50 -0600 From: Basavaraj Patil To: ext Glen Zorn , Alper Yegin Message-ID: Thread-Topic: [Pana] WG LC: Pre-authentication Support for PANA Thread-Index: AclxypjwUb/ucBgcPkWQM0vASiINfQFJoSXQABZ4/YAAAN42UQ== In-Reply-To: <004401c9774c$302794d0$9076be70$@net> Mime-version: 1.0 X-OriginalArrivalTime: 15 Jan 2009 20:18:39.0938 (UTC) FILETIME=[7450DA20:01C9774E] X-Nokia-AV: Clean Cc: pana@ietf.org Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org Hi Glen, Firm consensus might be a stretch of terminology. The chairs believe that this document is useful in the context of PANA. This has been echoed by people in the room at previous IETF meetings. And hence the current WG LC to progress the document. -Raj On 1/15/09 2:02 PM, "ext Glen Zorn" wrote: > Second try: is it the opinion of the WG Chairs that there is firm consensus > around this document? If so, may I ask what this determination is based > upon, given the ongoing discussions on this list? > >> -----Original Message----- >> From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On Behalf Of >> Alper Yegin >> Sent: Thursday, January 15, 2009 1:38 AM >> To: 'Basavaraj Patil'; pana@ietf.org >> Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA >> >> Here are my comments. >> >> >> - "The PCI message MUST be unicast." >> >> Not sure why we have such a constraint. Does using a non-unicast >> address >> break anything? If not, let's not be constraining the spec >> unnecessarily. >> Not that I see any use for this right away, but I don't see a reason to >> prohibit future possibilities unless we see a value in having such a >> constraint. >> >> >> - "Once the PaC and CPAA have agreed on performing pre-authentication >> using the 'S' (Start) and 'E' (prE-authentication) bits, the >> subsequent PANA messages exchanged between them MUST have the 'E' >> (prE-authentication) bit set." >> >> Not forever, right? We shall state "... MUST have the 'E' bit set until >> CPAA >> becomes SPAA of the PaC". >> >> - I didn't understand the utility of "Pre-authorization SA" and >> "Pre-authorization SA" distinction. There is only one PANA SA. It does >> not >> change when the PaC attaches to the target network. >> >> - In an access network where accounting is performed, accounting >> starts >> when the pre-authorization SA becomes the post-authorization SA by >> default. Depending on the pre-authorization policy, accounting may >> start immediately after the pre-authorization SA is established. >> >> >> This spec should not care when acct starts. >> >> - Since the mechanism described in this document is designed to work >> across multiple access networks, each EP in the serving network >> SHOULD be configured to allow PANA messages to be forwarded between >> a >> PaC and a CPAA only if the PaC has a post-authorization SA with the >> SPAA in order to avoid an unauthorized PaC to initiate pre- >> authentication. >> >> Not sure why we have to say anything like that. PANA pre-auth is just >> UDP. >> Unless the serving network "intends to block" pre-auth, it would not be >> preventing pre-auth. >> >> An EP should allow PANA messages from unauthorized only if they are >> destined >> to SPAA. >> So, it should not blindly allow PANA messages. They may not only allow >> pre-authentication (not that harmful), but they may even piggyback some >> data >> to punch a hole through EP. I guess this is what the spec intends to >> talk >> about, but it was not that clear to me from reading it. >> >> - The pre-authentication mechanism defined in this document does not >> have an issue on context binding in which link-layer independent >> context carried over pre-authentication signaling is bound to the >> link-layer specific context [I-D.ietf-hokey-preauth-ps], because the >> same EAP transport protocol (i.e., PANA) is used for normal >> authentication and pre-authentication in the candidate network. >> >> >> This does not even describe what the issue could be. I don't see a >> value in >> having this paragraph here. >> >> >> Editorial: >> >> - If the PaC is a >> mobile device and is capable of moving one access network to another >> while running its applications, >> >> s/moving one/moving from one >> >> >> - allow the PaC to sent or receive packets >> >> s/sent/send >> >> >> Thank you. >> >> Alper >> >> >> >> >> >>> -----Original Message----- >>> From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On Behalf >> Of >>> Basavaraj Patil >>> Sent: Thursday, January 08, 2009 9:52 PM >>> To: pana@ietf.org >>> Subject: [Pana] WG LC: Pre-authentication Support for PANA >>> >>> >>> >>> Hello, >>> >>> This is a WG last call for I-D: Pre-authentication Support for PANA >>> . >>> >>> The last call will end on January 22nd, 09. Please send your comments >>> to the mailing list prior to the deadline. >>> >>> -Chairs >>> >>> _______________________________________________ >>> Pana mailing list >>> Pana@ietf.org >>> https://www.ietf.org/mailman/listinfo/pana >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jan 15 12:30:40 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513353A69B0; Thu, 15 Jan 2009 12:30:40 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7582F3A6891 for ; Thu, 15 Jan 2009 12:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOwC2DnV+ryT for ; Thu, 15 Jan 2009 12:30:38 -0800 (PST) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id 662993A69A9 for ; Thu, 15 Jan 2009 12:30:38 -0800 (PST) Received: (qmail 31336 invoked from network); 15 Jan 2009 20:29:13 -0000 Received: from unknown (67.160.38.190) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 15 Jan 2009 20:29:11 -0000 From: "Glen Zorn" To: "'Basavaraj Patil'" , "'Alper Yegin'" References: <004401c9774c$302794d0$9076be70$@net> In-Reply-To: Date: Thu, 15 Jan 2009 12:28:34 -0800 Organization: Network Zen Message-ID: <004e01c9774f$d71ccb40$855661c0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclxypjwUb/ucBgcPkWQM0vASiINfQFJoSXQABZ4/YAAAN42UQAADikw Content-Language: en-us Cc: pana@ietf.org Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org Basavaraj Patil [mailto:basavaraj.patil@nokia.com] writes: > Hi Glen, > > Firm consensus might be a stretch of terminology. > The chairs believe that this document is useful in the context of PANA. That would certainly be a good rationale for the document's adoption as WH item; however, my understanding is that LC normally signifies that the document is complete (unless you are planning to follow the recently popular method of issuing multiple "Last" Calls). > This has been echoed by people in the room at previous IETF meetings. > And > hence the current WG LC to progress the document. > > -Raj > > > On 1/15/09 2:02 PM, "ext Glen Zorn" wrote: > > > Second try: is it the opinion of the WG Chairs that there is firm > consensus > > around this document? If so, may I ask what this determination is > based > > upon, given the ongoing discussions on this list? > > > >> -----Original Message----- > >> From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On Behalf > Of > >> Alper Yegin > >> Sent: Thursday, January 15, 2009 1:38 AM > >> To: 'Basavaraj Patil'; pana@ietf.org > >> Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA > >> > >> Here are my comments. > >> > >> > >> - "The PCI message MUST be unicast." > >> > >> Not sure why we have such a constraint. Does using a non-unicast > >> address > >> break anything? If not, let's not be constraining the spec > >> unnecessarily. > >> Not that I see any use for this right away, but I don't see a reason > to > >> prohibit future possibilities unless we see a value in having such a > >> constraint. > >> > >> > >> - "Once the PaC and CPAA have agreed on performing pre- > authentication > >> using the 'S' (Start) and 'E' (prE-authentication) bits, the > >> subsequent PANA messages exchanged between them MUST have the > 'E' > >> (prE-authentication) bit set." > >> > >> Not forever, right? We shall state "... MUST have the 'E' bit set > until > >> CPAA > >> becomes SPAA of the PaC". > >> > >> - I didn't understand the utility of "Pre-authorization SA" and > >> "Pre-authorization SA" distinction. There is only one PANA SA. It > does > >> not > >> change when the PaC attaches to the target network. > >> > >> - In an access network where accounting is performed, accounting > >> starts > >> when the pre-authorization SA becomes the post-authorization SA > by > >> default. Depending on the pre-authorization policy, accounting > may > >> start immediately after the pre-authorization SA is established. > >> > >> > >> This spec should not care when acct starts. > >> > >> - Since the mechanism described in this document is designed to > work > >> across multiple access networks, each EP in the serving network > >> SHOULD be configured to allow PANA messages to be forwarded > between > >> a > >> PaC and a CPAA only if the PaC has a post-authorization SA with > the > >> SPAA in order to avoid an unauthorized PaC to initiate pre- > >> authentication. > >> > >> Not sure why we have to say anything like that. PANA pre-auth is > just > >> UDP. > >> Unless the serving network "intends to block" pre-auth, it would not > be > >> preventing pre-auth. > >> > >> An EP should allow PANA messages from unauthorized only if they are > >> destined > >> to SPAA. > >> So, it should not blindly allow PANA messages. They may not only > allow > >> pre-authentication (not that harmful), but they may even piggyback > some > >> data > >> to punch a hole through EP. I guess this is what the spec intends to > >> talk > >> about, but it was not that clear to me from reading it. > >> > >> - The pre-authentication mechanism defined in this document does > not > >> have an issue on context binding in which link-layer independent > >> context carried over pre-authentication signaling is bound to the > >> link-layer specific context [I-D.ietf-hokey-preauth-ps], because > the > >> same EAP transport protocol (i.e., PANA) is used for normal > >> authentication and pre-authentication in the candidate network. > >> > >> > >> This does not even describe what the issue could be. I don't see a > >> value in > >> having this paragraph here. > >> > >> > >> Editorial: > >> > >> - If the PaC is a > >> mobile device and is capable of moving one access network to > another > >> while running its applications, > >> > >> s/moving one/moving from one > >> > >> > >> - allow the PaC to sent or receive packets > >> > >> s/sent/send > >> > >> > >> Thank you. > >> > >> Alper > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On > Behalf > >> Of > >>> Basavaraj Patil > >>> Sent: Thursday, January 08, 2009 9:52 PM > >>> To: pana@ietf.org > >>> Subject: [Pana] WG LC: Pre-authentication Support for PANA > >>> > >>> > >>> > >>> Hello, > >>> > >>> This is a WG last call for I-D: Pre-authentication Support for PANA > >>> . > >>> > >>> The last call will end on January 22nd, 09. Please send your > comments > >>> to the mailing list prior to the deadline. > >>> > >>> -Chairs > >>> > >>> _______________________________________________ > >>> Pana mailing list > >>> Pana@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pana > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jan 15 12:35:03 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D7B3A6842; Thu, 15 Jan 2009 12:35:03 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2802B3A67AB for ; Thu, 15 Jan 2009 12:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocFGfA52RTYz for ; Thu, 15 Jan 2009 12:35:01 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 15FFE3A68B6 for ; Thu, 15 Jan 2009 12:35:01 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0FKY5o1009561; Thu, 15 Jan 2009 14:34:43 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 22:34:41 +0200 Received: from vaebe112.NOE.Nokia.com ([10.160.244.81]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 22:34:42 +0200 Received: from 172.19.60.146 ([172.19.60.146]) by vaebe112.NOE.Nokia.com ([10.160.244.81]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jan 2009 20:34:41 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 15 Jan 2009 14:34:52 -0600 From: Basavaraj Patil To: ext Glen Zorn , Alper Yegin Message-ID: Thread-Topic: [Pana] WG LC: Pre-authentication Support for PANA Thread-Index: AclxypjwUb/ucBgcPkWQM0vASiINfQFJoSXQABZ4/YAAAN42UQAADikwAACBMNE= In-Reply-To: <004e01c9774f$d71ccb40$855661c0$@net> Mime-version: 1.0 X-OriginalArrivalTime: 15 Jan 2009 20:34:42.0048 (UTC) FILETIME=[B1C73000:01C97750] X-Nokia-AV: Clean Cc: pana@ietf.org Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org On 1/15/09 2:28 PM, "ext Glen Zorn" wrote: > Basavaraj Patil [mailto:basavaraj.patil@nokia.com] writes: > >> Hi Glen, >> >> Firm consensus might be a stretch of terminology. >> The chairs believe that this document is useful in the context of PANA. > > That would certainly be a good rationale for the document's adoption as WH > item; however, my understanding is that LC normally signifies that the > document is complete (unless you are planning to follow the recently popular > method of issuing multiple "Last" Calls). Don't plan on issuing multiple last calls... So AFAICT this document is viewed as being complete. Are there opinions that would contradict that view? What specifically is considered as being incomplete that would impede the LC process? > >> This has been echoed by people in the room at previous IETF meetings. >> And >> hence the current WG LC to progress the document. >> >> -Raj >> >> >> On 1/15/09 2:02 PM, "ext Glen Zorn" wrote: >> >>> Second try: is it the opinion of the WG Chairs that there is firm >> consensus >>> around this document? If so, may I ask what this determination is >> based >>> upon, given the ongoing discussions on this list? >>> >>>> -----Original Message----- >>>> From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On Behalf >> Of >>>> Alper Yegin >>>> Sent: Thursday, January 15, 2009 1:38 AM >>>> To: 'Basavaraj Patil'; pana@ietf.org >>>> Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA >>>> >>>> Here are my comments. >>>> >>>> >>>> - "The PCI message MUST be unicast." >>>> >>>> Not sure why we have such a constraint. Does using a non-unicast >>>> address >>>> break anything? If not, let's not be constraining the spec >>>> unnecessarily. >>>> Not that I see any use for this right away, but I don't see a reason >> to >>>> prohibit future possibilities unless we see a value in having such a >>>> constraint. >>>> >>>> >>>> - "Once the PaC and CPAA have agreed on performing pre- >> authentication >>>> using the 'S' (Start) and 'E' (prE-authentication) bits, the >>>> subsequent PANA messages exchanged between them MUST have the >> 'E' >>>> (prE-authentication) bit set." >>>> >>>> Not forever, right? We shall state "... MUST have the 'E' bit set >> until >>>> CPAA >>>> becomes SPAA of the PaC". >>>> >>>> - I didn't understand the utility of "Pre-authorization SA" and >>>> "Pre-authorization SA" distinction. There is only one PANA SA. It >> does >>>> not >>>> change when the PaC attaches to the target network. >>>> >>>> - In an access network where accounting is performed, accounting >>>> starts >>>> when the pre-authorization SA becomes the post-authorization SA >> by >>>> default. Depending on the pre-authorization policy, accounting >> may >>>> start immediately after the pre-authorization SA is established. >>>> >>>> >>>> This spec should not care when acct starts. >>>> >>>> - Since the mechanism described in this document is designed to >> work >>>> across multiple access networks, each EP in the serving network >>>> SHOULD be configured to allow PANA messages to be forwarded >> between >>>> a >>>> PaC and a CPAA only if the PaC has a post-authorization SA with >> the >>>> SPAA in order to avoid an unauthorized PaC to initiate pre- >>>> authentication. >>>> >>>> Not sure why we have to say anything like that. PANA pre-auth is >> just >>>> UDP. >>>> Unless the serving network "intends to block" pre-auth, it would not >> be >>>> preventing pre-auth. >>>> >>>> An EP should allow PANA messages from unauthorized only if they are >>>> destined >>>> to SPAA. >>>> So, it should not blindly allow PANA messages. They may not only >> allow >>>> pre-authentication (not that harmful), but they may even piggyback >> some >>>> data >>>> to punch a hole through EP. I guess this is what the spec intends to >>>> talk >>>> about, but it was not that clear to me from reading it. >>>> >>>> - The pre-authentication mechanism defined in this document does >> not >>>> have an issue on context binding in which link-layer independent >>>> context carried over pre-authentication signaling is bound to the >>>> link-layer specific context [I-D.ietf-hokey-preauth-ps], because >> the >>>> same EAP transport protocol (i.e., PANA) is used for normal >>>> authentication and pre-authentication in the candidate network. >>>> >>>> >>>> This does not even describe what the issue could be. I don't see a >>>> value in >>>> having this paragraph here. >>>> >>>> >>>> Editorial: >>>> >>>> - If the PaC is a >>>> mobile device and is capable of moving one access network to >> another >>>> while running its applications, >>>> >>>> s/moving one/moving from one >>>> >>>> >>>> - allow the PaC to sent or receive packets >>>> >>>> s/sent/send >>>> >>>> >>>> Thank you. >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On >> Behalf >>>> Of >>>>> Basavaraj Patil >>>>> Sent: Thursday, January 08, 2009 9:52 PM >>>>> To: pana@ietf.org >>>>> Subject: [Pana] WG LC: Pre-authentication Support for PANA >>>>> >>>>> >>>>> >>>>> Hello, >>>>> >>>>> This is a WG last call for I-D: Pre-authentication Support for PANA >>>>> . >>>>> >>>>> The last call will end on January 22nd, 09. Please send your >> comments >>>>> to the mailing list prior to the deadline. >>>>> >>>>> -Chairs >>>>> >>>>> _______________________________________________ >>>>> Pana mailing list >>>>> Pana@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pana >>>> >>>> >>>> _______________________________________________ >>>> Pana mailing list >>>> Pana@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pana >>> >>> >> > > _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jan 15 14:33:55 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FE53A6918; Thu, 15 Jan 2009 14:33:55 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B20A3A68F2 for ; Thu, 15 Jan 2009 14:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNldAXFxcLa7 for ; Thu, 15 Jan 2009 14:33:53 -0800 (PST) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id E88EA3A6830 for ; Thu, 15 Jan 2009 14:33:52 -0800 (PST) Received: (qmail 30681 invoked from network); 15 Jan 2009 22:33:36 -0000 Received: from unknown (67.160.38.190) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 15 Jan 2009 22:33:35 -0000 From: "Glen Zorn" To: "'Basavaraj Patil'" , "'Alper Yegin'" References: <004e01c9774f$d71ccb40$855661c0$@net> In-Reply-To: Date: Thu, 15 Jan 2009 14:32:57 -0800 Organization: Network Zen Message-ID: <005c01c97761$37bf5970$a73e0c50$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclxypjwUb/ucBgcPkWQM0vASiINfQFJoSXQABZ4/YAAAN42UQAADikwAACBMNEAA5ukAA== Content-Language: en-us Cc: pana@ietf.org Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org Basavaraj Patil [mailto:basavaraj.patil@nokia.com] writes: > On 1/15/09 2:28 PM, "ext Glen Zorn" wrote: > > > Basavaraj Patil [mailto:basavaraj.patil@nokia.com] writes: > > > >> Hi Glen, > >> > >> Firm consensus might be a stretch of terminology. > >> The chairs believe that this document is useful in the context of > PANA. > > > > That would certainly be a good rationale for the document's adoption > as WH > > item; however, my understanding is that LC normally signifies that > the > > document is complete (unless you are planning to follow the recently > popular > > method of issuing multiple "Last" Calls). > > Don't plan on issuing multiple last calls... > So AFAICT this document is viewed as being complete. Are there opinions > that > would contradict that view? As I've mentioned several times, I believe that this draft is the subject of ongoing discussion, that last pair of messages of which were posted just before and _after_ you issued last call. Perhaps you were unaware (although you were copied directly on both messages) of the debate? Do you consider the discussion to be irrelevant? It just seems rather irregular to me. > What specifically is considered as being > incomplete that would impede the LC process? > > > > >> This has been echoed by people in the room at previous IETF > meetings. > >> And > >> hence the current WG LC to progress the document. > >> > >> -Raj > >> > >> > >> On 1/15/09 2:02 PM, "ext Glen Zorn" wrote: > >> > >>> Second try: is it the opinion of the WG Chairs that there is firm > >> consensus > >>> around this document? If so, may I ask what this determination is > >> based > >>> upon, given the ongoing discussions on this list? > >>> > >>>> -----Original Message----- > >>>> From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On > Behalf > >> Of > >>>> Alper Yegin > >>>> Sent: Thursday, January 15, 2009 1:38 AM > >>>> To: 'Basavaraj Patil'; pana@ietf.org > >>>> Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA > >>>> > >>>> Here are my comments. > >>>> > >>>> > >>>> - "The PCI message MUST be unicast." > >>>> > >>>> Not sure why we have such a constraint. Does using a non-unicast > >>>> address > >>>> break anything? If not, let's not be constraining the spec > >>>> unnecessarily. > >>>> Not that I see any use for this right away, but I don't see a > reason > >> to > >>>> prohibit future possibilities unless we see a value in having such > a > >>>> constraint. > >>>> > >>>> > >>>> - "Once the PaC and CPAA have agreed on performing pre- > >> authentication > >>>> using the 'S' (Start) and 'E' (prE-authentication) bits, the > >>>> subsequent PANA messages exchanged between them MUST have > the > >> 'E' > >>>> (prE-authentication) bit set." > >>>> > >>>> Not forever, right? We shall state "... MUST have the 'E' bit set > >> until > >>>> CPAA > >>>> becomes SPAA of the PaC". > >>>> > >>>> - I didn't understand the utility of "Pre-authorization SA" and > >>>> "Pre-authorization SA" distinction. There is only one PANA SA. It > >> does > >>>> not > >>>> change when the PaC attaches to the target network. > >>>> > >>>> - In an access network where accounting is performed, accounting > >>>> starts > >>>> when the pre-authorization SA becomes the post-authorization SA > >> by > >>>> default. Depending on the pre-authorization policy, accounting > >> may > >>>> start immediately after the pre-authorization SA is > established. > >>>> > >>>> > >>>> This spec should not care when acct starts. > >>>> > >>>> - Since the mechanism described in this document is designed to > >> work > >>>> across multiple access networks, each EP in the serving network > >>>> SHOULD be configured to allow PANA messages to be forwarded > >> between > >>>> a > >>>> PaC and a CPAA only if the PaC has a post-authorization SA with > >> the > >>>> SPAA in order to avoid an unauthorized PaC to initiate pre- > >>>> authentication. > >>>> > >>>> Not sure why we have to say anything like that. PANA pre-auth is > >> just > >>>> UDP. > >>>> Unless the serving network "intends to block" pre-auth, it would > not > >> be > >>>> preventing pre-auth. > >>>> > >>>> An EP should allow PANA messages from unauthorized only if they > are > >>>> destined > >>>> to SPAA. > >>>> So, it should not blindly allow PANA messages. They may not only > >> allow > >>>> pre-authentication (not that harmful), but they may even piggyback > >> some > >>>> data > >>>> to punch a hole through EP. I guess this is what the spec intends > to > >>>> talk > >>>> about, but it was not that clear to me from reading it. > >>>> > >>>> - The pre-authentication mechanism defined in this document > does > >> not > >>>> have an issue on context binding in which link-layer > independent > >>>> context carried over pre-authentication signaling is bound to > the > >>>> link-layer specific context [I-D.ietf-hokey-preauth-ps], > because > >> the > >>>> same EAP transport protocol (i.e., PANA) is used for normal > >>>> authentication and pre-authentication in the candidate network. > >>>> > >>>> > >>>> This does not even describe what the issue could be. I don't see a > >>>> value in > >>>> having this paragraph here. > >>>> > >>>> > >>>> Editorial: > >>>> > >>>> - If the PaC is a > >>>> mobile device and is capable of moving one access network to > >> another > >>>> while running its applications, > >>>> > >>>> s/moving one/moving from one > >>>> > >>>> > >>>> - allow the PaC to sent or receive packets > >>>> > >>>> s/sent/send > >>>> > >>>> > >>>> Thank you. > >>>> > >>>> Alper > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On > >> Behalf > >>>> Of > >>>>> Basavaraj Patil > >>>>> Sent: Thursday, January 08, 2009 9:52 PM > >>>>> To: pana@ietf.org > >>>>> Subject: [Pana] WG LC: Pre-authentication Support for PANA > >>>>> > >>>>> > >>>>> > >>>>> Hello, > >>>>> > >>>>> This is a WG last call for I-D: Pre-authentication Support for > PANA > >>>>> . > >>>>> > >>>>> The last call will end on January 22nd, 09. Please send your > >> comments > >>>>> to the mailing list prior to the deadline. > >>>>> > >>>>> -Chairs > >>>>> > >>>>> _______________________________________________ > >>>>> Pana mailing list > >>>>> Pana@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/pana > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pana mailing list > >>>> Pana@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/pana > >>> > >>> > >> > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana From netebuc@anapsardegna.it Thu Jan 15 15:27:45 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7FC28C150 for ; Thu, 15 Jan 2009 15:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.819 X-Spam-Level: X-Spam-Status: No, score=-41.819 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxHkN36HZT1v for ; Thu, 15 Jan 2009 15:27:38 -0800 (PST) Received: from advbiol.com (unknown [201.46.61.64]) by core3.amsl.com (Postfix) with SMTP id C29D128C14B for ; Thu, 15 Jan 2009 15:27:34 -0800 (PST) To: Subject: Re: admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115232735.C29D128C14B@core3.amsl.com> Date: Thu, 15 Jan 2009 15:27:34 -0800 (PST)

From bt@gmbinternational.com Thu Jan 15 16:17:15 2009 Return-Path: X-Original-To: ietfarch-pana-archive@core3.amsl.com Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472513A68D0; Thu, 15 Jan 2009 16:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.838 X-Spam-Level: X-Spam-Status: No, score=-82.838 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA-qPpeMy0xX; Thu, 15 Jan 2009 16:17:13 -0800 (PST) Received: from c-98-223-102-24.hsd1.in.comcast.net (c-98-223-102-24.hsd1.in.comcast.net [98.223.102.24]) by core3.amsl.com (Postfix) with SMTP id 683DC3A63EC; Thu, 15 Jan 2009 16:17:10 -0800 (PST) X-Originating-IP: 17.84.128.128 by smtp.98.223.102.24; Thu, 15 Jan 2009 18:11:54 -0500 Message-ID: Subject: Patek Phillipe better than you could imagine! Date: Thu, 15 Jan 2009 18:16:54 -0500 From: "Quincy Busby" To: "Cara Chandler" Content-Type: text/plain; Content-Transfer-Encoding: 7bit Dear Cara, Looking for a IWC watch that no one can tell from the original? You're in luck, because we have the best copies http://hallssl.narod.ru Take advantage of our christmas specials and get yourself IWC watch that you've always wanted! http://hallssl.narod.ru Our IWC watches have perfect weight and feel same as orginal. Sincerely, Mr Chandler From pana-bounces@ietf.org Fri Jan 16 03:22:39 2009 Return-Path: X-Original-To: pana-archive@megatron.ietf.org Delivered-To: ietfarch-pana-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB61F28C20D; Fri, 16 Jan 2009 03:22:39 -0800 (PST) X-Original-To: pana@core3.amsl.com Delivered-To: pana@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAEF3A6847 for ; Fri, 16 Jan 2009 03:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDilq2OY3hiN for ; Fri, 16 Jan 2009 03:22:37 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id D50273A6821 for ; Fri, 16 Jan 2009 03:22:37 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LNmmI0RxF-000SlH; Fri, 16 Jan 2009 06:22:22 -0500 From: "Alper Yegin"

Hello pana-archive

Shipped Privately And Discreetly To Your Door!

Hello pana-archive

Shipped Privately And Discreetly To Your Door!