From jari.arkko@lmf.ericsson.se Thu Jun 5 12:21:32 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05282 for ; Thu, 5 Jun 2003 12:21:31 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55GGbbj025963; Thu, 5 Jun 2003 18:16:37 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGJPC03; Thu, 5 Jun 2003 18:15:43 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h55GFu214733; Thu, 5 Jun 2003 18:15:56 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h55GFH5n001397; Thu, 5 Jun 2003 18:15:17 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h55GFGCs001390; Thu, 5 Jun 2003 18:15:16 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h55GFE5n001267 for ; Thu, 5 Jun 2003 18:15:15 +0200 (MET DST) Message-ID: <013901c32b7d$70d0bbe0$a66015ac@DCLKEMPFTP> From: "James Kempf" To: Subject: SEND Protocol Draft Now Available Date: Thu, 5 Jun 2003 09:13:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, The 01 version of the SEND protocol draft is now available. The draft can be found at: http://www.piuha.net/~jarkko/publications/send/drafts/draft-ietf-send- ipsec-01.txt and should show up in the Internet drafts directory in the next couple days. The CGA draft is still undergoing editing. We will be sending the draft to the review board immediately, and as soon as the draft shows up, we will be issuing WG Last Call to elicit comments. Please read the draft thoroughly and send comments to this list. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 5 12:23:05 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05337 for ; Thu, 5 Jun 2003 12:23:04 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55GIH0J005560; Thu, 5 Jun 2003 18:18:17 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYTCF14; Thu, 5 Jun 2003 18:18:03 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h55GIG214781; Thu, 5 Jun 2003 18:18:16 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h55GI85n001898; Thu, 5 Jun 2003 18:18:08 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h55GI8Rc001896; Thu, 5 Jun 2003 18:18:08 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h55GI65n001892 for ; Thu, 5 Jun 2003 18:18:06 +0200 (MET DST) Message-ID: <013f01c32b7d$d6fcbd60$a66015ac@DCLKEMPFTP> From: "James Kempf" To: Subject: Design Team Now Concluded Date: Thu, 5 Jun 2003 09:16:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, The SEND design team has now concluded. Pekka and I would like to thank Brian Zill and Bill Sommerfeld for their important contribution to the design team. Jari Arkko has agreed to continue as editor of the SEND protocol draft, and Tuomas Aurea as agreed to continue as editor of the CGA draft, collecting and resolving issues on this list as they arise. Thanx to Jari and Tuomas as well for their continuing support. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 5 17:30:30 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18095 for ; Thu, 5 Jun 2003 17:30:29 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55LRQbj005269; Thu, 5 Jun 2003 23:27:26 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVY3GMTQ; Thu, 5 Jun 2003 23:27:39 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h55LQisY023797; Thu, 5 Jun 2003 23:26:44 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h55LQE5n006840; Thu, 5 Jun 2003 23:26:14 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h55LQE4u006839; Thu, 5 Jun 2003 23:26:14 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from alan1.alansis1.com (alan1.alansis1.com [207.134.106.158]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h55LQD5n006834 for ; Thu, 5 Jun 2003 23:26:13 +0200 (MET DST) Message-Id: <12351148@770885831> From: Alansis To: Reply-to: Subject: ADV: $25.00 off your Lead Order! Date: Thu, 5 Jun 2003 17:29:28 -0400 X-MSG-RECIPIENT-ID: MSG_12386079-3096955-alansis1 X-Mailer: Message sent on behalf of client: alansis1 X-Info: Please report any abuse from the part of list owner to abuse-MSG_12386079-3096955-alansis1@alansis1.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-=_bb4cb0db3152f02e64ac6f2b35b2db41b" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a MIME message. If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display MIME multipart messages. --Boundary-=_bb4cb0db3152f02e64ac6f2b35b2db41b Content-Type: text/plain; charset = "iso-8859-1"; Content-Disposition: inline X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id h55LQisY023797 Content-Transfer-Encoding: quoted-printable You have been awarded a gift certificate from Alansis for $25.00 off our = LEADS! =20 http://alansis1.com/d.php?m_z=3DMSG_12386079&l_d=3D1027047279&u_d=3D30969= 55&email=3Dietf-send@standards.ericsson.net Until midnight on June 6, PST, you will receive $25 off of any purchase o= f $50.00 or more. =20 At the moment, we have thousands of fresh new leads for you to view for f= ree. There is absolutely no cost to you to view any of our million leads= . =20 Simply click below to perform your free search of our leads and to redeem= your $25.00 gift certificate. =20 http://alansis1.com/d.php?m_z=3DMSG_12386079&l_d=3D1027047279&u_d=3D30969= 55&email=3Dietf-send@standards.ericsson.net You are receiving this message because you have opted in to receive messa= ges about financial information through Alansis or a Alansis affiliate. I= f you would like to know how your email address was obtained, please emai= l support@Alansis.com=20 This e-mail is an advertisement for Alansis sent to you on 6/5/03 at 3:01= PM PST and is intended to confirm your information. If you would prefer = not to receive any additional e-mail information from Alansis, please ema= il remove@Alansis.com with =93remove=94 in the subject line. Please allow= a reasonable response time not to exceed three (3) days after which you = will be removed from our e-mail database. Alansis is not licensed as a mo= rtgage specialist. Alansis provides a free service to consumers intereste= d in obtaining mortgage information, by introducing consumers to financia= l professionals.=20 Alansis is located at 505 Montgomery Street, 11th Floor, San Francisco, C= A 94111. Alansis may be contacted by e-mail at support@Alansis.com If you believe this is spam, go here: http://alansis1.com/uce.php?m=3DMSG_12386079&en=3Dietf-send@standards.eri= csson.net&uid=3D3096955&c=3Dalansis1 To unsubscribe, point your browser to http://alansis1.com/u1.php?m=3DMSG_= 12386079&em=3Dietf-send@standards.ericsson.net&id=3D3096955&c=3Dalansis1&= us=3D0 Users of the AOL email client may click here to unsubscribe. --Boundary-=_bb4cb0db3152f02e64ac6f2b35b2db41b Content-Type: text/html; charset = "iso-8859-1"; Content-Disposition: inline X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id h55LQisY023797 Content-Transfer-Encoding: quoted-printable Alansis




You are receiving this message because you have opted in to receive m= essages about financial information through Alansis or a Alansis affiliat= e. If you would like to know how your email address was obtained, please = email support@Alansis.com
This e-mail is an advertisement for Alansis sent to you on 6/5/03 at 3:01= PM PST and is intended to confirm your information. If you would prefer = not to receive any additional e-mail information from Alansis, please ema= il remove@Alansis.com with =93remove=94 in the subject line.
Please a= llow a reasonable response time not to exceed three (3) days after which = you will be removed from our e-mail database. Alansis is not licensed as = a mortgage specialist. Alansis provides a free service to consumers inter= ested in obtaining mortgage information, by introducing consumers to fina= ncial professionals.=20 Alansis is located at 505 Montgomery Street, 11th Floor, San Francisco, C= A 94111. Alansis may be contacted by e-mail at support@Alansis.com


If you believe this is spam, click here.
To unsubscribe, click here.

--Boundary-=_bb4cb0db3152f02e64ac6f2b35b2db41b-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 6 08:03:22 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18924 for ; Fri, 6 Jun 2003 08:03:21 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56BvaT3029302; Fri, 6 Jun 2003 13:57:36 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGGQTQJ; Fri, 6 Jun 2003 13:58:43 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h56BvZ220579; Fri, 6 Jun 2003 13:57:35 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h56Bur5n003132; Fri, 6 Jun 2003 13:56:53 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h56Bur71003131; Fri, 6 Jun 2003 13:56:53 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h56Bup5n003126 for ; Fri, 6 Jun 2003 13:56:51 +0200 (MET DST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18768; Fri, 6 Jun 2003 07:56:49 -0400 (EDT) Message-Id: <200306061156.HAA18768@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-send@standards.ericsson.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-send-ipsec-01.txt Date: Fri, 06 Jun 2003 07:56:49 -0400 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : SEcure Neighbor Discovery (SEND) Author(s) : J. Arkko et al. Filename : draft-ietf-send-ipsec-01.txt Pages : 66 Date : 2003-6-5 IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other nodes on the link, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. If not secured, ND protocol is vulnerable to various attacks. This document specifies an extension to IPsec for securing ND. Contrary to the original ND specifications that also called for use of IPsec, this extension does not require the creation of a large number of manually configured security associations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-send-ipsec-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-send-ipsec-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-send-ipsec-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-5120057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-send-ipsec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-send-ipsec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-5120057.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 6 13:05:15 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02523 for ; Fri, 6 Jun 2003 13:05:12 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56H0obj025153; Fri, 6 Jun 2003 19:00:50 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGJV4KC; Fri, 6 Jun 2003 18:59:55 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h56H08200914; Fri, 6 Jun 2003 19:00:08 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h56GxO5n008959; Fri, 6 Jun 2003 18:59:24 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h56GxOfI008958; Fri, 6 Jun 2003 18:59:24 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h56GxL5n008954 for ; Fri, 6 Jun 2003 18:59:22 +0200 (MET DST) Message-ID: <001301c32c4c$c4fae720$a66015ac@DCLKEMPFTP> From: "James Kempf" To: Subject: WG Last Call on draft-ietf-send-ipsec-01.txt Date: Fri, 6 Jun 2003 09:57:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, draft-ietf-send-ipsec-01.txt is now available from the Internet Drafts directory, so we'd like to issue a 2 week Last Call to solicit comments. Please read the draft carefully and submit comments to the list. Last Call expires on June 20, giving us a week to update the document if necessary. Thanx. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 6 15:40:55 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09748 for ; Fri, 6 Jun 2003 15:40:53 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56Jd70J000634; Fri, 6 Jun 2003 21:39:07 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYTJ69Q; Fri, 6 Jun 2003 21:38:52 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h56Jd5205218; Fri, 6 Jun 2003 21:39:05 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h56JcS5n027333; Fri, 6 Jun 2003 21:38:28 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h56JcSEH027332; Fri, 6 Jun 2003 21:38:28 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from alan1.alansis1.com (alan1.alansis1.com [207.134.106.158]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h56JcQ5n027306 for ; Fri, 6 Jun 2003 21:38:26 +0200 (MET DST) Message-Id: <1568197078@96282331> From: Alansis To: Reply-to: Subject: ADV: Announcing Real Time Leads! Date: Tue, 3 Jun 2003 19:21:10 -0400 X-MSG-RECIPIENT-ID: MSG_12385494-3096955-alansis1 X-Mailer: Message sent on behalf of client: alansis1 X-Info: Please report any abuse from the part of list owner to abuse-MSG_12385494-3096955-alansis1@alansis1.com MIME-Version: 1.0 Content-Type: text/plain; charset = "iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by tjatte.sw.ericsson.se id h56Jd5205218 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA09748 Introducing… LIVE LEADS! Alansis is proud to present its Live Leads System! How does it work? www.alansis.com password: 271c7e As soon as an Alansis consumer completes a mortgage application, it is instantaneously posted on the Alansis website, free for you to view! All of our live leads are sold 0 times and have filled out their mortgage application within 24 hours…guaranteed! We’ve taken the liberty of setting you up with a complimentary account: www.alansis.com password: 271c7e Also, for a limited time, get 20% off your first order! Don’t pass up this opportunity to generate new business for yourself or your company! Check out Live Leads today! You are receiving this message because you have opted in to receive messages about financial information through Alansis or a Alansis affiliate. If you would like to know how your email address was obtained, please email support@alansis.com. Alansis is not licensed as a mortgage solicitor, mortgage broker or mortgage lender in any state. Alansis provides a free service to consumers interested in obtaining information regarding mortgage, purchase or debt consolidation loans by introducing consumers to financial professionals. This e-mail is an advertisement for Alansis sent to you on 6-3-03 at 5:45 pm pst and is intended to confirm your information. If you would like to be removed, please email remove@alansis.com with remove in the subject line. If you believe this is spam, please follow the instruction at the bottom of the email. Alansis is located at 505 Montgomery Street, 11th Floor, San Francisco, CA 94111. Alansis may be contacted by e-mail at support@alansis.com. If you believe this is spam, go here: http://alansis1.com/uce.php?m=MSG_12385494&en=ietf-send@standards.ericsson.net&uid=3096955&c=alansis1 To unsubscribe, point your browser to http://alansis1.com/u1.php?m=MSG_12385494&em=ietf-send@standards.ericsson.net&id=3096955&c=alansis1&us=0 Users of the AOL email client may click here to unsubscribe. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 6 16:29:18 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11417 for ; Fri, 6 Jun 2003 16:29:16 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56KODbj001443; Fri, 6 Jun 2003 22:24:14 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGJWFN1; Fri, 6 Jun 2003 22:23:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h56KN2206161; Fri, 6 Jun 2003 22:23:02 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h56KMG5n002606; Fri, 6 Jun 2003 22:22:16 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h56KMGYB002605; Fri, 6 Jun 2003 22:22:16 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h56KMD5n002601 for ; Fri, 6 Jun 2003 22:22:14 +0200 (MET DST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h56KM9D14013; Fri, 6 Jun 2003 23:22:09 +0300 Date: Fri, 6 Jun 2003 23:22:08 +0300 (EEST) From: Pekka Savola To: James Kempf cc: ietf-send@standards.ericsson.net Subject: Re: WG Last Call on draft-ietf-send-ipsec-01.txt In-Reply-To: <001301c32c4c$c4fae720$a66015ac@DCLKEMPFTP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Fri, 6 Jun 2003, James Kempf wrote: > draft-ietf-send-ipsec-01.txt is now available from the Internet Drafts > directory, so we'd like to issue a 2 week Last Call to solicit > comments. Please read the draft carefully and submit comments to the > list. Last Call expires on June 20, giving us a week to update the > document if necessary. Remove all CGA, please. I'll read the spec and comment in detail when this has been done. Proceeding with non-RF technology is completely unacceptable. Thanks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 9 13:25:31 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13367 for ; Mon, 9 Jun 2003 13:25:31 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h59HIET3004629; Mon, 9 Jun 2003 19:18:14 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVY34VZT; Mon, 9 Jun 2003 19:19:18 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h59HIC221574; Mon, 9 Jun 2003 19:18:12 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h59HHS5n025354; Mon, 9 Jun 2003 19:17:28 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h59HHSjl025353; Mon, 9 Jun 2003 19:17:28 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mrson1549.com (80.179.100.73.forward.012.net.il [80.179.100.73]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h59HHH5n025321 for ; Mon, 9 Jun 2003 19:17:19 +0200 (MET DST) Message-Id: <200306091717.h59HHH5n025321@sw.ericsson.se> From: "DEBORAH KABILA" Reply-To: kabila72@ecplaza.net To: ietf-send@standards.ericsson.net Date: Fri, 4 Jan 1980 03:15:01 -0800 Subject: HI FRIEND X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h59HHS5n025350 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Dear friend, RE save our soul I am Mrs. Deborah Kabila, one of the wives of Late President Laurent D. Kabila of Democratic Republic of Congo (DRC). Consequent upon the assassination of my husband, I am in possession of USD 58,000,000 (Fifty Eight Million US Dollars Only) being funds earlier earmarked for special projects. This fund has since been deposited in a security company in West African Country of Togo where I am residing now with my children. It is now my intention to move the said fund out of this place (Togo) to a safer place for the benefit of my children and I, for immediate investment. Based on this that I solicited for your assistance to enable me take this money out of Togo. However, note that my children and I have agreed to give you 20% of the total fund if you can accept the offer of assisting us. Also it will be your responsibility in directing us on a viable business. It is also my intention to relocate and probably take a temporarily resident in your country pending when all the troubles in my country will be resolved. We advised that you look for a house we will buy as soon as we arrived. To conclude this transaction, you will be required to come to Togo to open an account in any bank here in Togo where the security company will deposit the total sum in your favor. From this bank the money will be remitted into your original bank in your country. Immediately this done, all of us will depart Togo to your country, where my children and I are expected to take a temporary resident. Please note that I can not open any Bank account with my name because, My late husband's first son-JOSEPH-who took over power in our country, don't want to see me and my children, He claimed that when our husband was alive, that I was very close to him than any other of his wives including his (Joseph) mother. He also claimed that because of my closeness to him that I was able to get things from him more than others. As a result he has been monitoring me. Infact this one of the main reasons I want to take my children out of our country and any nearby country. Thanking you in advance. Yours faithfully, Deborah Kabila (Mrs.) N/B: Kindly give me your direct telephone,fax and your mobile telephone numbers for more explanations. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 10 03:24:55 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15793 for ; Tue, 10 Jun 2003 03:24:54 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5A7MwT3026260; Tue, 10 Jun 2003 09:22:58 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGG7X8X; Tue, 10 Jun 2003 09:24:20 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5A7MrsY009708; Tue, 10 Jun 2003 09:22:53 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5A7MIme017932; Tue, 10 Jun 2003 09:22:18 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5A7MIUW017931; Tue, 10 Jun 2003 09:22:18 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5A7MGme017927 for ; Tue, 10 Jun 2003 09:22:17 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 6D4AD1C; Tue, 10 Jun 2003 10:31:59 +0300 (EEST) Message-ID: <3EE5875C.3060702@nomadiclab.com> Date: Tue, 10 Jun 2003 10:23:08 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Gonzalo Camarillo , Jonathan Wood Subject: An alternative ASN.1 format Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit We are now implementing the CGA draft, and we had a brief off-line discussion with Tuomas about some details on the ASN.1 encoding. Basically, we would like to have the beginning of the ASN.1 DER encoding to be fixed, making it easier to handle the most common case. Basically, the following modifications would be needed: 1. In the CGA draft, have the auxParameters first and the public key only after that: CGAParameters ::= SEQUENCE { auxParameters CGAAuxParameters, publicKey SubjectPublicKeyInfo } CGAAuxParameters ::= SEQUENCE { modifier OCTET STRING (SIZE 12), routingPrefix OCTET STRING (SIZE 8), collisionCount INTEGER (0..2) } 2. Define a fixed value for the actual public key algorithm used, taking pcks-1 from RFC3279, and defining that there MUST NOT be any parameters. 3. Define that the RSA key MUST be at least 1024 bits long, basically making sure that the corresponding ASN.1 DER encoding always exceeds 127 bytes, requiring the "long" length DER format. 4. Change the main draft accordingly. Opening up the ASN.1 encoding gives the following data structure: SEQUENCE { // SendKeyInformation SEQUENCE { // CGAParameters SEQUENCE { // auxParameters OCTET STRING (SIZE 12), // modifier OCTET STRING (SIZE 8), // routingPrefix INTEGER (0..2) // collisionCount } OPTIONAL, SEQUENCE { // publicKey SEQUENCE { // algorithmIdentifier OBJECT IDENTIFIER, // algorithm ANY OPTIONAL, // parameters }, BITSTRING // subjectPublicKey } } OPTIONAL, SEQUENCE { // signerInfo SEQUENCE { // algorithmIdentifier OBJECT IDENTIFIER, // algorithm ANY OPTIONAL, // parameters }, BITSTRING // subjectPublicKey } OPTIONAL } Assuming these changes, we got the following binary format. This is fairly easy to implement, and also recognize if the format does not match the expected one, and kick such things to the user level. 30 82 LL LL // SendKeyInformation 30 82 LL LL // CGAParameters 30 1b // auxParameters 06 0c MM MM MM MM MM MM MM MM MM MM MM MM // modifier 06 08 RR RR RR RR RR RR RR RR // routingPrefix 02 01 CC // collisionCount 30 82 LL LL // publicKey 30 0b // algorithmId 06 09 // algorithm 2a 86 48 86 f7 0d 01 01 01 // RSA // NO parameters 03 82 LL LL // subjectPublicKey PK PK PK PK ..... PK PK PK // Bit string --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 10 03:27:27 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15818 for ; Tue, 10 Jun 2003 03:27:26 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5A7PH0J025098; Tue, 10 Jun 2003 09:25:17 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGKA1T8; Tue, 10 Jun 2003 09:25:03 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5A7PGsY009743; Tue, 10 Jun 2003 09:25:16 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5A7P6me018048; Tue, 10 Jun 2003 09:25:06 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5A7P6qP018047; Tue, 10 Jun 2003 09:25:06 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5A7P4me018043 for ; Tue, 10 Jun 2003 09:25:04 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id A995D1C; Tue, 10 Jun 2003 10:34:54 +0300 (EEST) Message-ID: <3EE5880B.7080508@nomadiclab.com> Date: Tue, 10 Jun 2003 10:26:03 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Wood Cc: Tuomas Aura , SEND WG , Gonzalo Camarillo Subject: Re: Question about the ASN.1 keying data References: <440D600A-9A9C-11D7-830A-0003930D291E@speakeasy.net> In-Reply-To: <440D600A-9A9C-11D7-830A-0003930D291E@speakeasy.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander wrote >> Assuming these changes, we got the following binary format. >> This is fairly easy to implement, and also recognize >> if the format does not match the expected one, and kick >> such things to the user level. Jonathan Wood wrote: > This sounds like a good idea. > > If the format does not match, why would you kick it to userland > instead of rejecting it? In other words, under what circumstances > would a valid SendKeyInformation not follow this format? Well, the only reason for having ASN.1 in the first place is to allow extensibility. For example, it might be desirable to use DSA keys instead of RSA keys. Furthermore, the second key (signerInfo) is there to allow proxy operations etc. In our implementation we plan to implement only the most common case in the kernel, and all the rest in the user level. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 10 05:48:53 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18736 for ; Tue, 10 Jun 2003 05:48:52 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5A9ktT3028650; Tue, 10 Jun 2003 11:46:55 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGG9BW3; Tue, 10 Jun 2003 11:48:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5A9kqsY015491; Tue, 10 Jun 2003 11:46:52 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5A9kRme005248; Tue, 10 Jun 2003 11:46:27 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5A9kRTi005247; Tue, 10 Jun 2003 11:46:27 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5A9kQme005243 for ; Tue, 10 Jun 2003 11:46:26 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id CC9BF1C; Tue, 10 Jun 2003 12:56:15 +0300 (EEST) Message-ID: <3EE5A92D.1020902@nomadiclab.com> Date: Tue, 10 Jun 2003 12:47:25 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Jonathan Wood , Tuomas Aura , Gonzalo Camarillo Subject: Changing the meaning of sec from 12 bits to 16 bits? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Again, for making our implementation easier... Based on some early performance results that we've heard from Jon, it looks like finding a suitable modifier for sec=1 or sec=2 is currently easily computable, while generating an sec=3 address takes hours or days. Now, comparing a fractional byte number of bits for zero takes somewhat more code than just comparing a whole byte number. Thus, we'd like to suggest that instead of each sec step meaning 12 bits that would be 16. This would have a dual benefit. Firstly, it would allow to make the CGA checking code slightly easier. Secondly, that would protect us better in the future, allowing considerably longer bits hash2 value. Opinions? --Pekka & Gonzalo -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 10 11:54:25 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06461 for ; Tue, 10 Jun 2003 11:54:24 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5AFphT3006724; Tue, 10 Jun 2003 17:51:43 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYT6QXW; Tue, 10 Jun 2003 17:51:28 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5AFpfsY003140; Tue, 10 Jun 2003 17:51:41 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5AFotme021877; Tue, 10 Jun 2003 17:50:55 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5AFotLi021876; Tue, 10 Jun 2003 17:50:55 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from web41806.mail.yahoo.com (web41806.mail.yahoo.com [66.218.93.140]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5AForme021872 for ; Tue, 10 Jun 2003 17:50:54 +0200 (MET DST) Message-ID: <20030610155052.85733.qmail@web41806.mail.yahoo.com> Received: from [65.213.193.49] by web41806.mail.yahoo.com via HTTP; Tue, 10 Jun 2003 08:50:52 PDT Date: Tue, 10 Jun 2003 08:50:52 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Participation To: ietf-send@standards.ericsson.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-800106668-1055260252=:83174" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --0-800106668-1055260252=:83174 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 =================================================================== http://www.caitr.org/internetworking03/index.htm =================================================================== You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials. Registration for the conference is underway - online registration is now available. The early registration discounts are extremely attractive and have been extended through June 15, 2003. To register, go to: http://www.caitr.org/internetworking03/registration.htm Program: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details) Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - Domain Constrained Multicast: A New Approach for IP Multicast Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - An Analysis of Hand-off methods in some WAN and LAN networks Tuesday June 24 Session: Routing Performance - Optimizing Route Convergence - Active Dynamic Routing - Fluid flow network modeling for hop-by-hop feedback control design and analysis Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Problems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: Routing Architecture & QoS - QoS Routing in Networks with Non-Deterministic Information - A new routing architecture: Atomised Routing - Traceroute and BGP AS Path Incongruities - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs : - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-800106668-1055260252=:83174 Content-Type: text/html; charset=us-ascii
 
     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
===================================================================
    http://www.caitr.org/internetworking03/index.htm
===================================================================
 
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.

Registration for the conference is underway - online registration is now available. The early registration discounts are extremely attractive and have been extended through June 15, 2003. To register, go to:
 http://www.caitr.org/internetworking03/registration.htm
 
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
 
Sunday June 22
    Tutorial-1: MPLS VPNs
    Tutorial-2: IPv6
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet
 
Monday June 23
    Welcome and Keynote
 
&n! bsp;   Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing 
      - Network Processing Building Blocks: Enabling the Routers of the Future
 
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
 
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and Performance Analysis of ! the iSCSI Protocol for SCSI over TCP/IP
   !  &n bsp; - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS
      - Mobile Authentication and QoS
      - An Analysis of Hand-off methods in some WAN and LAN networks
 
Tuesday June 24
    Session: Routing Performance
      - Optimizing Route Convergence
      - Active Dynamic Routing 
      - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
    Session:  Applications & Services
      - Securing the Web with Next Generation Encryption Technologies
      - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 
      - A novel EAC semantic for the RTSP protocol
      - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session:  Network Management & Planning
    ! ;  - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature
      - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Problems
      - Design Of Fast Fault Restoration System For WDM Networks
      - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session:  Routing Architecture & QoS
      - QoS Routing in Networks with Non-Deterministic Information
      - A new routing architecture: Atomised Routing
      - Traceroute and BGP AS Path Incongruities
      - QoS routing for Differentiated Services: simulations and prototype experiments
      - Probabilistic routing for QoS improvement in GPS networks
 
We look forward t! o seeing you at the Conference.
 
Regards,
 ! ;Confere nce Technical Co-chairs :
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM
--0-800106668-1055260252=:83174-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 10 17:31:38 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18920 for ; Tue, 10 Jun 2003 17:31:17 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5ALLU0J029741; Tue, 10 Jun 2003 23:21:30 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGHCFV5; Tue, 10 Jun 2003 23:22:54 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5ALLKsY007869; Tue, 10 Jun 2003 23:21:20 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5ALJxme029323; Tue, 10 Jun 2003 23:19:59 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5ALJxSm029322; Tue, 10 Jun 2003 23:19:59 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from usa.net ([211.250.29.162]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5ALJNme029287 for ; Tue, 10 Jun 2003 23:19:41 +0200 (MET DST) Message-ID: <56523bec1ead$ea8ecb7f$cd71f87a@acunjx.tj> From: To: mark.Twain@standards.ericsson.net Subject: Toner Cartridge Prices-per your request Date: Tue, 10 Jun 2003 19:18:19 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_E10_3918_21C6D4F8.B9F486CA" X-Priority: 3 User-Agent: Microsoft Outlook Express 5.00.2919.6700 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk ------=_NextPart_E10_3918_21C6D4F8.B9F486CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_E10_3918_21C6D4F8.B9F486CA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable fgfg
 

VERTEX LASER AND 

COPIER SUPPLIES
 
TAKE ADVANTAGE OF THE SAVINGS WHILE THEY LAST!!!

SPECIAL PRICING ON

PRINTER AND COPIER SUPPLIES
 

 ORDER BY PHONE: 1-888-288-9043
ORDER BY FAX: 1-888-977-1577

***EMAIL REMOVAL LINE: 1-888-248-4930***

 PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER
 
 

      For Hewlett Packard Printers: (Page 2)
ITEM
 DESCRIPTION
MFG #
PRICE
Item #1
Laserjet Series 4L, 4P 
 92274A
$44
Item #2
Laserjet Series 1100,3200
 C4092
 $44
Item #3
 Laserjet Series  2
  92295A
  $49
 Item # 4
 Laserjet Series  2P
 92275A
  $54
 Item #5
 Laserjet Series 5P,6P, 5MP, 6MP
 3603A
 $44
Item #6
 Laserjet Series 5SI,8000
 3909A
$95
 Item #7 
 Laserjet Series 2100, 2200 
 C4096
 $74
 Item #8
 Laserjet Series 8100
 C4182
 $115
 Item #9
Laserjet Series 5L/6L
 3906A
 $39
 Item #10 
Laserjet Series  4V
C3900 
 $95
 Item #11
Laserjet Series 4000
C4127X
 $79
 Item #12
Laserjet Series 3SI/4SI
 92291A 
$54
 Item #13
Laserjet Series 4,4M,5,5M 
92298A
$49
 Item #13A
Laserjet Series 5000
C4129X
$125
 Item #13B
Laserjet Series 1200,3300
C7115A
$59
 Item #13C
Laserjet Series 4100
C8061X
$99
 Item #18
Laserjet Series  3100
3906A
$39
 Item #19
Laserjet Series 4500 Black
C4191 
$69
 Item #20
Laserjet Series 4500 Color
CALL
$89
 
For Hewlett Packand Canon Fax (on Page 2)
ITEM
DESCRIPTION
MFG #
PRICE
Item # 14
Leserfax 500, 700
FX1
$59
Item # 15
Laserfax 5000, 7000
FX2
$64
Item # 16
Laserfax 6000
FX3
$59
Item #17
Laserfax 8500, 9000
FX4
$54
Item #18
Laserfax 3200
3906A
$44

For Lexmark / IBM Machines: (on Page 3)
  ITEM
DESCRIPTION
MFG #
PRICE
Item #1
IBM 4019/4029 
1380200 
$95
Item #2
Optra R,4039, 4049
1382150
$117
Item #3
Optra E310, E312
 12A2202
$89
Item #4
Optra E
 69G8256 
$59
Item #5
Optra S
 1382625 
$135
Item #6
Optra T
  12A5840
$165
Item #7
Optra E410/412
  4K00198 
$115

For Apple Printers: (on Page 8)
ITEM
DESCRIPTION
MFG#
PRICE
Item  #1
Personal LaserWriter
M0089LLA
$54
Item #2
LaserWriter 300PX/ 320-4L,+4ML
M2045GA
$54
Item #3
LaserWriter Select 360
M1960GA
$74
Item #4
LaserWriter 16/ 600 Pro 
M2473GA
$59
Item #5
LaserWriter 12/ 640 PS
M4683GA 
$89
Item #6
Laser Writer NT/2NT
M4532GA
$49

  For Canon Copiers: (Page 10)
ITEM
DESCRIPTION
MFG #
PRICE
Item # 1
PC 6/ 6RE/ 7/ 8/ 11/ 12/ 65
 A30 
$69
Item # 2
PC 300/320/340/360  All 300 Series
 E40 
$89
Item #3
PC 700/720/760  All 700 Series
 E40 
$89
Item #4
PC 900/910/920  All 900 Series
 E40
$89

For Epson and Panasonic Printers:(on Pages 4 & 7)
ITEM
 DESCRIPTION
MFG #
PRICE
Item # 1
Epson 1000/1500
S051011 
$105
Item #2 
Epson EPL7000/8000 
S051200 
$105 
Item #3
Panasonic 90/95 
----------------
$105

 
 
 

NOTES:

University and School Purchase orders welcome. (No Credit approval required. All other Purchase
    orders require credit approval
 Pay by check (C.O.D.), Credit card or purchase order (Net 30 Days)
Shipping charges start at $4.5 per cartridge. Add $1.5 for each additional cartridge. Cartridges
    delivered by Federal Express within 2 to 5 working days depending on your location.
Shipping and billing addresses are required for Purchase Order transactions. Your invoice will
    be attached to your packaging. Please peal and pay within 30 days.
30 day standard return policy (money back guarantee) on all merchandise. 90 day unlimited exchange policy
    for defective merchandise.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

We do not carry:

    - Xerox, Brother, Panasonic, or Fujitsu Products
    - Deskjet/Inkjet or Bubblejet products
     -Any Offbrands besides the ones listed above. All cartridges
          are compatible high yield products.
 
 

DISCLAIMERS:

     All trademarks, brand names and diagrams listed or shown above
are property of their respective holders   and used for descriptive purposes only
.We do not carry any HP OEM  Products.









































------=_NextPart_E10_3918_21C6D4F8.B9F486CA-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 11 15:31:36 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23996 for ; Wed, 11 Jun 2003 15:31:36 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5BJOXcv018089; Wed, 11 Jun 2003 21:24:33 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYP1BXW; Wed, 11 Jun 2003 21:24:58 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5BJNdsY015526; Wed, 11 Jun 2003 21:23:39 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5BJN2me018052; Wed, 11 Jun 2003 21:23:02 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5BJN2rt018051; Wed, 11 Jun 2003 21:23:02 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5BJN1me018047 for ; Wed, 11 Jun 2003 21:23:01 +0200 (MET DST) Received: from kolumbus.fi ([62.248.237.117]) by fep02-app.kolumbus.fi with ESMTP id <20030611192300.WOJJ9070.fep02-app.kolumbus.fi@kolumbus.fi>; Wed, 11 Jun 2003 22:23:00 +0300 Message-ID: <3EE7812F.60905@kolumbus.fi> Date: Wed, 11 Jun 2003 22:21:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG , Jonathan Wood , Tuomas Aura , Gonzalo Camarillo Subject: Re: Changing the meaning of sec from 12 bits to 16 bits? References: <3EE5A92D.1020902@nomadiclab.com> In-Reply-To: <3EE5A92D.1020902@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > Thus, we'd like to suggest that instead of each > sec step meaning 12 bits that would be 16. > > This would have a dual benefit. Firstly, it would allow to > make the CGA checking code slightly easier. Secondly, that > would protect us better in the future, allowing considerably > longer bits hash2 value. > > Opinions? Sounds good to me. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 11 15:31:37 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23998 for ; Wed, 11 Jun 2003 15:31:36 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5BJNb0J027766; Wed, 11 Jun 2003 21:23:37 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP7QMJT; Wed, 11 Jun 2003 21:23:35 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5BJNa200076; Wed, 11 Jun 2003 21:23:36 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5BJMmme018040; Wed, 11 Jun 2003 21:22:48 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5BJMmOe018039; Wed, 11 Jun 2003 21:22:48 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5BJMlme018035 for ; Wed, 11 Jun 2003 21:22:47 +0200 (MET DST) Received: from kolumbus.fi ([62.248.237.117]) by fep02-app.kolumbus.fi with ESMTP id <20030611192247.WOIU9070.fep02-app.kolumbus.fi@kolumbus.fi>; Wed, 11 Jun 2003 22:22:47 +0300 Message-ID: <3EE78121.7000703@kolumbus.fi> Date: Wed, 11 Jun 2003 22:21:05 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG , Gonzalo Camarillo , Jonathan Wood Subject: Re: An alternative ASN.1 format References: <3EE5875C.3060702@nomadiclab.com> In-Reply-To: <3EE5875C.3060702@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > 1. In the CGA draft, have the auxParameters first and > the public key only after that: > > CGAParameters ::= SEQUENCE { > auxParameters CGAAuxParameters, > publicKey SubjectPublicKeyInfo } > > CGAAuxParameters ::= SEQUENCE { > modifier OCTET STRING (SIZE 12), > routingPrefix OCTET STRING (SIZE 8), > collisionCount INTEGER (0..2) } Ok. > 2. Define a fixed value for the actual public key algorithm > used, taking pcks-1 from RFC3279, and defining that there > MUST NOT be any parameters. Ok. > 3. Define that the RSA key MUST be at least 1024 bits > long, basically making sure that the corresponding > ASN.1 DER encoding always exceeds 127 bytes, requiring > the "long" length DER format. I'm very much in favor of a simplified format. But I'd like to understand the 1024 bit requirement better. Does that mean that the key has to have 1024 significant bits, or are upper zero bits allowed? Would there be situations where we'd like to have e.g. RFC 3041 addresses that use a short RSA key? Or is 1024 already short enough? --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 11 15:46:36 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00016 for ; Wed, 11 Jun 2003 15:46:36 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5BJiZ0J029011; Wed, 11 Jun 2003 21:44:35 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGKMXD8; Wed, 11 Jun 2003 21:44:24 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5BJiY200667; Wed, 11 Jun 2003 21:44:34 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5BJiHme019926; Wed, 11 Jun 2003 21:44:17 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5BJiHGi019925; Wed, 11 Jun 2003 21:44:17 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5BJiGme019918 for ; Wed, 11 Jun 2003 21:44:16 +0200 (MET DST) Received: from esunmail ([129.147.58.198]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5BJiFYU019235 for ; Wed, 11 Jun 2003 13:44:15 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGC001W21HQ72@edgemail1.Central.Sun.COM> for ietf-send@standards.ericsson.net; Wed, 11 Jun 2003 13:44:15 -0600 (MDT) Received: from 192.168.1.100 ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGC00JN91HN7S@mail.sun.net> for ietf-send@standards.ericsson.net; Wed, 11 Jun 2003 13:44:14 -0600 (MDT) Date: Wed, 11 Jun 2003 21:43:39 +0200 From: Julien Laganier Subject: Re: Changing the meaning of sec from 12 bits to 16 bits? In-reply-to: <3EE5A92D.1020902@nomadiclab.com> To: SEND WG Message-id: <200306112143.39843.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline User-Agent: KMail/1.5.2 References: <3EE5A92D.1020902@nomadiclab.com> X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5BJiHme019919 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by tjatte.sw.ericsson.se id h5BJiY200667 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA00016 Le Mardi 10 Juin 2003 11:47, Pekka Nikander a écrit : > Again, for making our implementation easier... > > Based on some early performance results that we've heard from > Jon, it looks like finding a suitable modifier for sec=1 or sec=2 > is currently easily computable, while generating an sec=3 address > takes hours or days. This confirms some of my early experiments. > Now, comparing a fractional byte number of bits for zero > takes somewhat more code than just comparing a whole byte > number. Thus, we'd like to suggest that instead of each > sec step meaning 12 bits that would be 16. > > This would have a dual benefit. Firstly, it would allow to > make the CGA checking code slightly easier. Secondly, that > would protect us better in the future, allowing considerably > longer bits hash2 value. > > Opinions? Given that generating a CGA with 12 or 24 bits is quite 'easy', as opposed to a 36 bits generation, I fully agree with this proposal. Thanks, --julien -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 13 14:26:16 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16838 for ; Fri, 13 Jun 2003 14:26:15 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5DIMJG5024654; Fri, 13 Jun 2003 20:22:19 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGHWDGF; Fri, 13 Jun 2003 20:23:53 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5DIM8sY015569; Fri, 13 Jun 2003 20:22:08 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5DIL9me018729; Fri, 13 Jun 2003 20:21:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5DIL9l0018728; Fri, 13 Jun 2003 20:21:09 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5DIL6me018724 for ; Fri, 13 Jun 2003 20:21:07 +0200 (MET DST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA12017; Fri, 13 Jun 2003 11:21:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5DIL4E16509; Fri, 13 Jun 2003 11:21:04 -0700 X-mProtect: <200306131821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqovGvj; Fri, 13 Jun 2003 11:21:03 PDT Message-ID: <3EEA1674.8030102@iprg.nokia.com> Date: Fri, 13 Jun 2003 11:22:44 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Pekka Savola , ietf-send@standards.ericsson.net Subject: Re: WG Last Call on draft-ietf-send-ipsec-01.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit James, Can we get a summary of the IPR claims relating to CGA? And, have the wg chairs evaluated the current draft for compliance with guidelines on intellectual property issues? Fred Templin ftemplin@iprg.nokia.com Pekka Savola wrote: >On Fri, 6 Jun 2003, James Kempf wrote: > > >>draft-ietf-send-ipsec-01.txt is now available from the Internet Drafts >>directory, so we'd like to issue a 2 week Last Call to solicit >>comments. Please read the draft carefully and submit comments to the >>list. Last Call expires on June 20, giving us a week to update the >>document if necessary. >> >> > >Remove all CGA, please. > >I'll read the spec and comment in detail when this has been done. > >Proceeding with non-RF technology is completely unacceptable. > >Thanks. > > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 13 19:20:52 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28221 for ; Fri, 13 Jun 2003 19:20:51 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5DNIvcv009842; Sat, 14 Jun 2003 01:18:57 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYPS8LD; Sat, 14 Jun 2003 01:19:26 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5DNI6sY019135; Sat, 14 Jun 2003 01:18:07 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5DNHVme024657; Sat, 14 Jun 2003 01:17:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5DNHVoH024656; Sat, 14 Jun 2003 01:17:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5DNHSme024652 for ; Sat, 14 Jun 2003 01:17:29 +0200 (MET DST) Message-ID: <006101c33201$ba575eb0$766015ac@DCLKEMPFTP> From: "James Kempf" To: "Fred Templin" Cc: "Pekka Savola" , References: <3EEA1674.8030102@iprg.nokia.com> Subject: Re: WG Last Call on draft-ietf-send-ipsec-01.txt Date: Fri, 13 Jun 2003 16:15:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Fred, > Can we get a summary of the IPR claims relating to CGA? And, > have the wg chairs evaluated the current draft for compliance with > guidelines on intellectual property issues? > You should check the IETF IPR web page (http://www.ietf.org/ipr.html) for the definitive answer on the IPR claims, and we believe the disclosure in the current draft (c.f. Appendix C and the following section containing standard IETF text about IPR) is in compliance. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 13 20:10:59 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29375 for ; Fri, 13 Jun 2003 20:10:58 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5E099G5010834; Sat, 14 Jun 2003 02:09:09 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8BJCS; Sat, 14 Jun 2003 02:09:15 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5E097sY019672; Sat, 14 Jun 2003 02:09:07 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5E08mme029789; Sat, 14 Jun 2003 02:08:48 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5E08mTD029788; Sat, 14 Jun 2003 02:08:48 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5E08kme029781 for ; Sat, 14 Jun 2003 02:08:47 +0200 (MET DST) Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Fri, 13 Jun 2003 17:08:45 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 13 Jun 2003 17:08:44 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Jun 2003 17:08:44 -0700 Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 13 Jun 2003 17:08:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: draft-ietf-send-cga-00 submitted Date: Fri, 13 Jun 2003 17:07:00 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F094FDE80@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: draft-ietf-send-cga-00 submitted Thread-Index: AcMyCN5nQ3L8T2FFRS6TN/8DpgTS7A== From: "Tuomas Aura" To: X-OriginalArrivalTime: 14 Jun 2003 00:08:44.0602 (UTC) FILETIME=[1E9A29A0:01C33209] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5E08lme029785 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit The above should soon appear in the internet-drafts directory. A temporary copy can be found at: http://www.research.microsoft.com/users/tuomaura/CGA/ draft-ietf-send-cga-00.txt Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jun 14 20:45:57 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08664 for ; Sat, 14 Jun 2003 20:45:56 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5F0grcv012620; Sun, 15 Jun 2003 02:42:53 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGHY7WL; Sun, 15 Jun 2003 02:43:44 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5F0g3sY002076; Sun, 15 Jun 2003 02:42:03 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5F0esme004561; Sun, 15 Jun 2003 02:40:54 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5F0erVE004560; Sun, 15 Jun 2003 02:40:53 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5F0epme004556 for ; Sun, 15 Jun 2003 02:40:52 +0200 (MET DST) Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sat, 14 Jun 2003 17:40:50 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sat, 14 Jun 2003 17:40:50 -0700 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 14 Jun 2003 17:40:50 -0700 Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Jun 2003 17:40:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Comments and questions on draft-ietf-send-ipsec-01 Date: Sat, 14 Jun 2003 17:39:03 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F094FDF54@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: Comments and questions on draft-ietf-send-ipsec-01 Thread-Index: AcMy1oTTbiyIBOWCTru0YtODQMV0mw== From: "Tuomas Aura" To: X-OriginalArrivalTime: 15 Jun 2003 00:40:49.0854 (UTC) FILETIME=[C48E0DE0:01C332D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5F0eqme004557 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Here are a few comments and questions on draft-ietf-send-ipsec-01. Tuomas *1* Section 3, first bullet (NUD) The text of the first bullet suggests that there are attacks against NUD where the soliciting node incorrectly deletes a neighbor cache entry. I don't understand how such an attack would be possible, except by blocking NAs. SEND definitely does not prevent such blocking attacks. The text appears to have been copied from draft-ietf-send-psreq-03.txt but that document does not explain any better how the attack is supposed to work. The only attack against NUD that uses spoofed NAs is one where the attacker keeps the address alive (makes it appear reachable) after the address owner has, in fact, become unreachable. Proposal: Either delete this bullet or acknowledge the shortcoming of SEND in this respect. Or if I am wrong and such an attack exists, it should be explained better. Section 13.2 (and Section 4.1.2 of draft-ietf-send-psreq-03.txt) may also need revising. *2* Section 6.2 (Component field) If a router has multiple trust roots and a separate delegation chain for each root, it should be able to send unsolicited Delegation Chain Advertisements for all these chains. But the Component field in the advertisement is not sufficient to tell which certificate belongs to which chain. Proposal: Replace the 16-bit Component field with an 8-bit Chain Number field and an 8-bit Component field. *3* Section 6.5 (Authorization chain) As far as I can understand, the authorization certificate chain consists of a chain of PKCs + one AC. The AC is issued by the subject of the last PKC. This is non-standard usage of PKCs as they are effectively used for authorization rather than for identification. Standard usage would be to have no authorization chains but only a single AC issued directly by whoever issues them. The AC would specify the name of its holder. A separate PKC chain would then be used to resolve the name into a public key. There could be another PKC chain for the issuer of the AC. Obviously, the standard usage is unsatisfactory for SEND. I don't have any better solution to suggest than what is currently in the draft and I believe the authors are fully aware of the problem. Just thought I'd rant a bit about it. *4* Section 6.7, paragraph 2 (storing certificates) The text says that hosts should store *all* certificates retrieved in DCAs. This is vulnerable to DoS attacks. Proposal: "Hosts SHOULD store certificate chains retrieved in Delegation Chain Discovery messages if they start from a root trusted by the host. The certificate chains SHOULD be verified before storing them. Hosts SHOULD NOLT store Delegation Chain Advertisements that do not form a chain starting from a trusted root." *5* Section 7.1.3 (minBits) There is a conflict between the default 768-bit modulus specified here and the minimum 1024-bit modulus required in draft-ietf-send-cga-00. The reason for the 1024-bit minimum is not security but that it makes the implementation of CGA slightly easier if the key lengths start from 1024 bits. Proposal: Either change the default to 1024 bits here or delete the 1024-bit minimum in draft-ietf-send-cga-00. (I don't have any personal preference.) *6* Section 7.1.3 (minSec) There is a conflict between the minSec configuration parameter here and draft-ietf-send-cga-00, which requires the CGA verifier to ignore the value of Sec after CGA verification succeeds. IMO, minSec should always be zero because it is the owner (not the verifier) of a CGA address that should decide the strength of the protection the address owner needs. However, one can envision future extensions of the protocol that are beyond the scope of the current work but might benefit from having the minSec parameter in the SA. Proposal: Add the following text: "This parameter is intended to facilitate future extensions and experimental work. The minSec value SHOULD always be set to zero." I have already softened the corresponding text in draft-ietf-send-cga-00 to match this. *7* Section 7.1.3 (CGA flag) The inbound AH_RSA_Sig SA currently allows the following three combinations of authorization mechanisms: (i) trusted root authorization required, CGA authorization not verified; (ii) CGA authorization required, trusted root authorization not verified; (iii) both trusted root authorization and CGA authorization required. It is impossible to specify the following combination: (iv) either mechanism is ok, the second need not be verified if the first one succeeds. I think the missing combination would be useful for NS, NA and RS. Proposal: Replace the "router authority" flag and the "CGA flag" with an "authorization mechanism" parameter that can get the above 4 values. *8* Section 7.1.4 (replay protection) It is unnecessary to maintain a cache of the full messages received within the allowed Delta (1 hour). It is sufficient to store the latest timestamp received from each specific source address. Proposal: Revise the text to reflect the above. *9* Section 8.4 (outbound SPD and SAD entries) If the AH_RSA_Sig transform in either allows or requires the CGA authorization mechanism to be used, the own address in the Source Address field of the corresponding policy entry MUST be generated as specified in Section 4 of [27]. Proposal: Add the above sentence to section 8.4. *10* Section 8.2.2 (Target Address) The receiver needs to check that the Target Address of the NA is the same address that was used when verifying the AH, i.e. the Target Address must be equal to the IP Source Address. Proposal: "The receiver MUST verify that the Target Address field in the received Neighbor Advertisement is equal to the IP Source Address of the same packet." *11* Sections 9.1-9.2 (Source link-layer address option in NS/RS) If a router solicitation or neighbor solicitation does not contain the Source link-layer address option, there is no security reason for authenticating the solicitation. RFC 2461 says that the option SHOULD be present in the solicitations. Perhaps it is worth repeating here. Proposal: Maybe add the following clarification to sections 9.1.1 and 9.2.1: "RFC 2461 specifies that the Source link-layer address option SHOULD be included in solicitations where the source address in not the unspecified address. Thus, the Source link-layer option SHOULD be included in all secure router/neighbor solicitations. Note that the solicitations MUST be protected with the AH-RSA_Sig transform regardless of whether the option is present or not." *12* Sections 9.2.1-9.2.2 (Source link-layer address option in RA) A router advertisement contains the following two kinds of information: (i) the router's link-local IP address and other router parameters and (ii) the link-layer address corresponding to that link-local IP address. These two parts have different properties when it comes to authorization. The CGA authorization method protects only the IP-address-to-link-layer-address mapping but has no value in protecting the router IP address or parameters. The trusted root obviously protects the router IP address and router parameters. Whether the trusted root authorization also protects the mapping to a link-layer address, can be argued both ways. Anyway, it never makes sense to use only the CGA authorization method for RAs. Proposal: Modify the text in Section 9.2.1: "The outbound security associations used for this MUST be configured with the sender's key pair. The security association MUST be configured to protect the advertisement with the trusted-root authorization method and MAY be configured to additionally protect it with the CGA authorization method." Modify the text in Section 9.2.1: "The inbound security associations used for this MUST be configured to require the trusted-root authorization method and they MAY additionally be configured to require CGA authentication." *13* Section 9.3.1 (Redirect and CGA) Unlike I earlier thought, it actually makes sense to use the CGA authorization mechanism for Redirect messages. The recipient of the Redirect already knows the IP address of the router because it just tried to send a packet via that router. Thus, the CGA authorization method can be used to verify that the Redirect comes from that router. (RFC 2461 Section 8.1 effectively requires the recipient to check that the sender of the Redirect is a router.) Proposal: No changes needed here. Redirect needs to be mentioned in draft-ietf-send-cga along with the other message types. *14* Section 9.3.1 (Target link-layer address option in Redirect) The Target link-layer address option in the Redirect message is an oddity. In all the other types of messages, the AH proves that the node *owns* the IP Source Address and is thus authorized to change its mapping to link-layer addresses. In Redirect, it is not the IP Source Address that is being mapped but the Target Address. The authorization comes from the fact that the sender of the Redirect is a router. Proposal: No changes needed but perhaps this should be discussed in the security considerations. Alternatively, ban the Target link-layer address option in SEND Redirect messages. *15* Section 10.1, 2nd major bullet (insecure DAD) There is nothing wrong here but a small clarification could be added. Proposal: Add the following sentence: "Any insecure Neighbor Advertisements received in response to the insecure Neighbor Solicitation MUST be ignored." *16* Section 10.1, host considerations (SEND for all addresses) Is there any reason why a host could not use SEND for some addresses and ND for others? This seems like an arbitrary and unnecessary limitation. Even if most hosts don't need to use both SEND and ND, some hosts may want to do so. For example, consider multi-homed hosts that have one interface on a physical network that has a SEND router and another interface on a physical network that has no SEND router. It should nevertheless be able to connect to both networks. Proposal: Allow host to use both SEND and ND. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 04:22:29 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26045 for ; Sun, 15 Jun 2003 04:22:28 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5F8K8w2014318; Sun, 15 Jun 2003 10:20:08 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGHZRCJ; Sun, 15 Jun 2003 10:21:48 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5F8K7N03324; Sun, 15 Jun 2003 10:20:07 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5F8JNme015211; Sun, 15 Jun 2003 10:19:23 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5F8JMuA015210; Sun, 15 Jun 2003 10:19:22 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5F8JLme015203 for ; Sun, 15 Jun 2003 10:19:21 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 1C0691C; Sun, 15 Jun 2003 11:29:06 +0300 (EEST) Message-ID: <3EEC2C43.9060302@nomadiclab.com> Date: Sun, 15 Jun 2003 11:20:19 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barbara Fraser Cc: ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Subject: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> In-Reply-To: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Based on our experiences in the SEND WG, I would like to offer the following comments to the IPSEC WG, regarding to the AHbis draft. > 1. Introduction > > .... > > host. ESP may be used to provide the same anti-replay and similar > integrity services, and it also provides a confidentiality > (encryption) service. The primary difference between the integrity > provided by ESP and AH is the extent of the coverage. Specifically, > ESP does not protect any IP header fields unless those fields are > encapsulated by ESP (e.g., via use of tunnel mode). ... Comments: - Even though the text above is true and correct, it may give a wrong impression. The most important difference is packet size. If ESP is used, it is necessary to copy all the important information from the fields that precede ESP into ESP (typically by employing tunneling), thereby making the packet larger. Additionally, if the protocols protected by ESP rely on any fields that precede ESP, ESP processing should check that the fields within the ESP header and the fields outside of it are equal. This is, by no means, trivial, since tunnel mode is not always a solution, depending on context. Hence, I would suggest adding the following piece of text: It should be noticed that some applications (such as IPv6 Neighbor Discovery or Mobile IPv6) rely on the integrity of some of the fields in the IP header. Furthermore, using tunnel mode may not be an option, since the very precense of a tunnel may open attacks. Finally, the incresed packet size caused by tunneling may be unacceptable to some applications. -------------- > 3.2 Integrity Algorithms > > The integrity algorithm employed for the ICV computation is specified > by the SA. For point-to-point communication, suitable integrity > algorithms include keyed Message Authentication Codes (MACs) based on > symmetric encryption algorithms (e.g., AES [AES] or on one-way hash > functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast > communication, a variety of cryptographic strategies for providing > integrity have been developed and research continues in this area. Comment: - In the current SEND working group proposal, a public key algorithm is proposed to be used even for point-to-point communication. However, this probably does not warrant changing the text above. -------------- > 3.4.2 Security Association Lookup > > .... > document.) The SAD entry for the SA also [...] > indicates the key required to validate the ICV. Comment - In the current SEND WG proposal, the SA does not indicate the key to be used. Instead, the AH header itself contains the public key. However, I don't know if the text above should be changed. --Pekka Nikander SEND WG co-chair -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 04:56:55 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26495 for ; Sun, 15 Jun 2003 04:56:54 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5F8sUw2015369; Sun, 15 Jun 2003 10:54:30 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8FT0F; Sun, 15 Jun 2003 10:54:42 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5F8sTN03999; Sun, 15 Jun 2003 10:54:29 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5F8s7me019073; Sun, 15 Jun 2003 10:54:07 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5F8s7FD019072; Sun, 15 Jun 2003 10:54:07 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5F8s6me019068 for ; Sun, 15 Jun 2003 10:54:06 +0200 (MET DST) Received: from kolumbus.fi ([62.248.146.254]) by fep07-app.kolumbus.fi with ESMTP id <20030615085403.VLJX13000.fep07-app.kolumbus.fi@kolumbus.fi>; Sun, 15 Jun 2003 11:54:03 +0300 Message-ID: <3EEC33BF.2000109@kolumbus.fi> Date: Sun, 15 Jun 2003 11:52:15 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: ietf-send@standards.ericsson.net Subject: Re: Comments and questions on draft-ietf-send-ipsec-01 References: <9805B5E65CD0D0479D08B7EB832B369F094FDF54@red-msg-08.redmond.corp.microsoft.com> In-Reply-To: <9805B5E65CD0D0479D08B7EB832B369F094FDF54@red-msg-08.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Thank you Tuomas very much for these comments! Inline. > *1* > Section 3, first bullet (NUD) > > The text of the first bullet suggests that there > are attacks against NUD where the soliciting node > incorrectly deletes a neighbor cache entry. I don't > understand how such an attack would be possible, > except by blocking NAs. SEND definitely does not > prevent such blocking attacks. > > The text appears to have been copied from > draft-ietf-send-psreq-03.txt but that document does > not explain any better how the attack is supposed > to work. The only attack against NUD that uses > spoofed NAs is one where the attacker keeps the > address alive (makes it appear reachable) after the > address owner has, in fact, become unreachable. > Proposal: Either delete this bullet or acknowledge > the shortcoming of SEND in this respect. Or if I am > wrong and such an attack exists, it should be > explained better. Section 13.2 (and Section 4.1.2 of > draft-ietf-send-psreq-03.txt) may also need revising. Right. New text: "NUD is security-sensitive, because an attacker could falsely claim that reachability exists when it in fact does not." > *2* > Section 6.2 (Component field) > > If a router has multiple trust roots and a separate > delegation chain for each root, it should be able to > send unsolicited Delegation Chain Advertisements for > all these chains. But the Component field in the > advertisement is not sufficient to tell which > certificate belongs to which chain. > > Proposal: Replace the 16-bit Component field with an > 8-bit Chain Number field and an 8-bit Component field. You are right, of course about the problem. It does appear only if you run several ADD procedures in parallel. Hmm... this appears to be necessary in some cases, such as when different types of solicitations are sent in. Thinking some more about this... the identifier field appears to be able to distinguish such chains from each other, but only in the case of solicited advertisements, because the Identifier field is zero otherwise. We also have the Trusted Root option, but that appears currently only in the first component. How about making the Trusted Root option appear in all components, and required to be the first option? > *3* > Section 6.5 (Authorization chain) I'll leave this to Pekka and James who have indeed are aware of the problem, I think, and have discussed this with various folks in the IETF. My understanding is that the discussions haven't concluded yet... > *4* > Section 6.7, paragraph 2 (storing certificates) > > The text says that hosts should store *all* > > certificates retrieved in DCAs. This is vulnerable > to DoS attacks. > > Proposal: "Hosts SHOULD store certificate chains > retrieved in Delegation Chain Discovery messages if > they start from a root trusted by the host. The > certificate chains SHOULD be verified before storing > them. Hosts SHOULD NOLT store Delegation Chain > Advertisements that do not form a chain starting > from a trusted root." Yes. Your text looks good. I would like to propose a slight modification of the protocol to make this work better: we can additionally require that the routers send certs starting from the trusted root side of the chain. This makes it possible to store only those certs that really have a verifiable chain to the trusted root. If another order would be allowed, then we would potentially have to store a lot of certificates before being able to verify that the chain ends in the root. Here's the text: "Hosts SHOULD store certificate chains retrieved in Delegation Chain Discovery messages if they start from a root trusted by the host. The certificates chains SHOULD be verified before storing them. Routers are required to send the certificates one by one, starting from the trusted root end of the chain. Except for temporary purposes to allow for message loss and reordering, hosts SHOULD NOT store certificates received in a Delegation Chain Advertisement unless they contain a certificate which can be immediately verified either to the trusted root or to a certificate which has been verified earlier." > *5* > Section 7.1.3 (minBits) > > There is a conflict between the default 768-bit > modulus specified here and the minimum 1024-bit > modulus required in draft-ietf-send-cga-00. The > reason for the 1024-bit minimum is not security but > that it makes the implementation of CGA slightly > easier if the key lengths start from 1024 bits. > > Proposal: Either change the default to 1024 bits > here or delete the 1024-bit minimum in > draft-ietf-send-cga-00. (I don't have any personal > preference.) Changed to 1024. > *6* > Section 7.1.3 (minSec) > > There is a conflict between the minSec configuration > parameter here and draft-ietf-send-cga-00, which > requires the CGA verifier to ignore the value of Sec > after CGA verification succeeds. IMO, minSec should > always be zero because it is the owner (not the > verifier) of a CGA address that should decide the > strength of the protection the address owner needs. > However, one can envision future extensions of the > protocol that are beyond the scope of the current > work but might benefit from having the minSec > parameter in the SA. > > Proposal: Add the following text: "This parameter is > intended to facilitate future extensions and > experimental work. The minSec value SHOULD always be > set to zero." I have already softened the corresponding > text in draft-ietf-send-cga-00 to match this. I added this text. But I would suggest actually deleting minSec, because if we don't have a reason for it now, we shouldn't be specifiying it either. There is no backwards compatibility issue for adding such support later, since this does not relate to on-the-wire issues. > *7* > Section 7.1.3 (CGA flag) > > The inbound AH_RSA_Sig SA currently allows the > following three combinations of authorization > mechanisms: (i) trusted root authorization required, > CGA authorization not verified; (ii) CGA authorization > required, trusted root authorization not verified; > (iii) both trusted root authorization and CGA > authorization required. It is impossible to specify > the following combination: (iv) either mechanism is > ok, the second need not be verified if the first one > succeeds. I think the missing combination would be > useful for NS, NA and RS. > > Proposal: Replace the "router authority" flag and the > "CGA flag" with an "authorization mechanism" parameter > that can get the above 4 values. Excellent idea, thanks! Here's the text: " authorization method This parameter determines the mechanisms through which the authority of the sender is determined. It can have four values: trusted root The authority of the sender is verified as described in Section 6.5. The sender may have additional authorization through the use of CGAs, but this is neither required nor verified. CGA The CGA property of the sender's address is verified as described in [27]. The sender may have additional authority through a trusted root, but this is neither required nor verified. trusted root and CGA Both the trusted root and the CGA verification is required. trusted root or CGA Either the trusted root or the CGA verification is required." > *8* > Section 7.1.4 (replay protection) > > It is unnecessary to maintain a cache of the full > messages received within the allowed Delta (1 hour). > It is sufficient to store the latest timestamp > received from each specific source address. > > Proposal: Revise the text to reflect the above. Right. Thanks. New text: "If anti-replay has been enabled, receivers MUST be configured with an allowed Delta value. They MUST maintain a cache of the last received timestamp value from each specific source address within this time period." > *9* > Section 8.4 (outbound SPD and SAD entries) > > If the AH_RSA_Sig transform in either allows or > requires the CGA authorization mechanism to be used, > the own address in the Source Address field of the > corresponding policy entry MUST be generated as > specified in Section 4 of [27]. > > Proposal: Add the above sentence to section 8.4. Ok. > *10* > Section 8.2.2 (Target Address) > > The receiver needs to check that the Target Address > of the NA is the same address that was used when > verifying the AH, i.e. the Target Address must be > equal to the IP Source Address. > > Proposal: "The receiver MUST verify that the > Target Address field in the received Neighbor > Advertisement is equal to the IP Source Address > of the same packet." Ok, thanks. > *11* > Sections 9.1-9.2 (Source link-layer address > option in NS/RS) > > If a router solicitation or neighbor solicitation > does not contain the Source link-layer address > option, there is no security reason for > authenticating the solicitation. RFC 2461 says that > the option SHOULD be present in the solicitations. > Perhaps it is worth repeating here. > > Proposal: Maybe add the following clarification to > sections 9.1.1 and 9.2.1: > "RFC 2461 specifies that the Source link-layer > address option SHOULD be included in solicitations > where the source address in not the unspecified > address. Thus, the Source link-layer option SHOULD > be included in all secure router/neighbor > solicitations. Note that the solicitations MUST be > protected with the AH-RSA_Sig transform regardless > of whether the option is present or not." Ok, but I don't think we need to say anything in 9.2.1, since there does not appear to be any action related to this. > *12* > Sections 9.2.1-9.2.2 (Source link-layer > address option in RA) > > A router advertisement contains the following two > kinds of information: (i) the router's link-local IP > address and other router parameters and (ii) the > link-layer address corresponding to that link-local > IP address. These two parts have different properties > when it comes to authorization. The CGA authorization > method protects only the IP-address-to-link-layer-address > mapping but has no value in protecting the router > IP address or parameters. The trusted root obviously > protects the router IP address and router parameters. > Whether the trusted root authorization also > protects the mapping to a link-layer address, can > be argued both ways. Anyway, it never makes sense > to use only the CGA authorization method for RAs. I agree, mostly. But the use of CGA to protect routers is still marginally better than plain ND. So I'd rather use a SHOULD than a MUST in your suggested text. > Proposal: Modify the text in Section 9.2.1: > "The outbound security associations used for this > MUST be configured with the sender's key pair. The > security association MUST be configured to protect > the advertisement with the trusted-root > authorization method and MAY be configured to > additionally protect it with the CGA authorization > method." > > Modify the text in Section 9.2.1: > "The inbound security associations used for this > MUST be configured to require the trusted-root > authorization method and they MAY additionally be > configured to require CGA authentication." Put to the draft, with a SHOULD in place of the MUST for the authz method. > *13* > Section 9.3.1 (Redirect and CGA) > > Unlike I earlier thought, it actually makes sense > to use the CGA authorization mechanism for Redirect > messages. The recipient of the Redirect already Hey, I knew this earlier ;-) > knows the IP address of the router because it just > tried to send a packet via that router. Thus, the > CGA authorization method can be used to verify that > the Redirect comes from that router. (RFC 2461 > Section 8.1 effectively requires the recipient to > check that the sender of the Redirect is a router.) > > Proposal: No changes needed here. Redirect needs to > be mentioned in draft-ietf-send-cga along with the > other message types. Ok. > *14* > Section 9.3.1 (Target link-layer address > option in Redirect) > > The Target link-layer address option in the Redirect > message is an oddity. In all the other types of > messages, the AH proves that the node *owns* > the IP > Source Address and is thus authorized to change its > mapping to link-layer addresses. In Redirect, it is > not the IP Source Address that is being mapped but > the Target Address. The authorization comes from the > fact that the sender of the Redirect is a router. > > Proposal: No changes needed but perhaps this should > be discussed in the security considerations. > Alternatively, ban the Target link-layer address > option in SEND Redirect messages. Hmm... I'd rather ban the TLA option here. This problem appears to apply both the trusted root and CGA authz. > *15* > Section 10.1, 2nd major bullet (insecure DAD) > > There is nothing wrong here but a small clarification > could be added. > > Proposal: Add the following sentence: > "Any insecure Neighbor Advertisements received in > response to the insecure Neighbor Solicitation MUST > be ignored." Added. > *16* > Section 10.1, host considerations (SEND for all > addresses) > > Is there any reason why a host could not use SEND > for some addresses and ND for others? This seems like > an arbitrary and unnecessary limitation. > > Even if most hosts don't need to use both SEND and > ND, some hosts may want to do so. For example, > consider multi-homed hosts that have one interface > on a physical network that has a SEND router and > another interface on a physical network that has > no SEND router. It should nevertheless be able to > connect to both networks. > > Proposal: Allow host to use both SEND and ND. Sounds right, but is this for different addresses, different routers, or for different interfaces? I have tentatively edited the draft to say that hosts may have different configs regarding this on different interfaces. Modified draft on the web at http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.txt http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.html http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsecdiff.html --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 05:23:10 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26844 for ; Sun, 15 Jun 2003 05:23:09 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5F9JpG5022808; Sun, 15 Jun 2003 11:19:51 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8FV8X; Sun, 15 Jun 2003 11:20:03 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5F9JlsY005183; Sun, 15 Jun 2003 11:19:47 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5F9JMme022495; Sun, 15 Jun 2003 11:19:22 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5F9JM5r022494; Sun, 15 Jun 2003 11:19:22 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5F9JLme022490 for ; Sun, 15 Jun 2003 11:19:21 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 9DCE81C; Sun, 15 Jun 2003 12:29:09 +0300 (EEST) Message-ID: <3EEC3A57.1020908@nomadiclab.com> Date: Sun, 15 Jun 2003 12:20:23 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Jari Arkko , Tuomas Aura , James Kempf Subject: Should CGA parameters be a separate header instead of being integrated with AH Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Based our (so far limited) implementation experience, I am starting to think that perhaps the CGA public key and parameters should be included in a separate option instead of being integrated into the AH header. In this note I will first briefly explain the current situation, reason for the suggested situation based on our experienc, and finally my proposal for a new design. 1. Current design ================= In draft-ietf-send-ipsec-01.txt, the IPsec AH header is defined to include the following structure: - standard AH headers (Next header, length, SPI, replay counter) - timestamp - Key Information - signature The Key Information field is defined, using ASN.1, to contain cgaParameters, including the CGA key, and signerInfo, which may contain a different key than the CGA key. 2. Why should this be changed ============================= While implementing the current proposal, we seem to end up including the CGA information in at least two separate kernel data structures. Firstly, we need the have the CGA parameters field available for CGA address generation. CGA address generation is performed, in turn, either when the first link local address is generated, or when a host is using autoconfiguration and receives a new routing prefix in an RA. Secondly, we need to have the CGA parameters field available when protecting packets with AH. The reason for this is that the CGA parameters is included the AH header; otherwise they are not needed. Sharing the CGA parameters between AH and address generation is not exactly trivial. Typically, address generation is handled by ND code, controlled with ifconfig(8), and the API between ifconfig and the ND code is based on ioctl(SIOC[CG]IF). On the other hand, AH is part of IPsec, controled with setkey(8), and the API between the user level and kernel is based on PF_KEY. Thus, if we try to inject the CGA parameters data just once to the kernel, we get an ugly dependency between two otherwise fairly independent pieces of code. Alternatively, we have to pass the exactly same data twice to the kernel, and typically even with different user level utilities. Now, if we separated CGA processing completely from AH processing, AH should not know about CGA at all. When sending outbound packets, the ND stack would include a CGA header, and the IPsec processing would included it as a part of the IP packet, making sure that it is located before the AH header (just like HbH options or Routing Header is). On the input side, a separate piece of code (trigged by the next header field) would process the CGA header, drop the packet if the CGA verification fails, and cache the key otherwise. AH would then be able to fetch the key from the cache. In addition to making the implementation cleaner, the new design would have another benefit: It would make CGA independent of AH, making it possible to use it also with e.g. ESP or HIP. 3. Proposal for a new design ============================ I propose that we move the cga parameters from the AH header to a separate header, which MUST precede the AH header: *------------------------------------------------* | IPv6 | CGA | AH | ICMPv6 | ND message | | Header | Header | Header | Header | | *------------------------------------------------* The CGA header would include - cgaParameters, including - auxParameters, just as today - publicKey, just as today The AH header would then include just a hash of the public key, i.e., a key name. Furthermore, I would propose that ASN.1 is not used, since having a full ASN.1 DER parser in kernel code just causes bloat. Instead, I propose the following formats for the new CGA header and revised AH header. --------------------------------------------------------------------- X. CGA Extension Header format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | RES | PAD |CC | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Modifier | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Public key . . (variable length) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the CGA header. Hdr Ext Len 8-bit unsigned integer. Length of the CGA header in 8-octet units, not including the first 8 octets. RESERVED Reserved for future use. MUST be set zero by the sender and SHOULD be ignored by the receiver. CC Collision Count. As defined in [CGA]. PAD Padding length (in octets). Algorithm Public key algorithm, as defined in Section 3.2 in [RFC2535]. All conforming implementations MUST support RSA/MD5. Modifier CGA modifier. As defined in [CGA]. Public key Public key in [RFC2535] format. For RSA, see [RFC2537]. Padded with zeros, if necessary, so that the header length becomes integral with 8-octet units. The number of padding octets (if any) is indicated by the PAD field. Notes: - the extension header DOES NOT include the routing prefix, since it is implicitly available in the source address. --------------------------------------------------------------------- 7.1.2 Integrity Check Value Format [Note that AHbis has renamed the Authentication Data field into Integrity Check Value.] The format of the ICV field in AH depends on the chosen transform. For the AH_RSA_Sig transform, the format is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | Key Information | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Digital Signature (remaining bytes) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The meaning of the fields is described below: Timestamp This 64 bit unsigned integer field contains a timestamp used for replay protection (the Sequence Number field in AH is not used for AH_RSA_Sig). The use of this field is discussed in Section 7.1.4. Key Information A 160-bit long SHA-1 hash of the public key. Digital Signature This variable length field contains the signature made using the sender's private key, over the the whole packet as defined by the usual AH rules [3]. The signature is made using the RSA algorithm and MUST be encoded as private key encryption in PKCS #1 format [17]. The length of this field is determined by the PKCS #1 encoding. --------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 06:41:33 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28043 for ; Sun, 15 Jun 2003 06:41:32 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5FAdcw2019182; Sun, 15 Jun 2003 12:39:38 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYPWT4C; Sun, 15 Jun 2003 12:40:59 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5FAdbN06346; Sun, 15 Jun 2003 12:39:37 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FAd8me002030; Sun, 15 Jun 2003 12:39:08 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5FAd8hT002029; Sun, 15 Jun 2003 12:39:08 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FAd7me002025 for ; Sun, 15 Jun 2003 12:39:07 +0200 (MET DST) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 4FE431C; Sun, 15 Jun 2003 13:48:53 +0300 (EEST) Message-ID: <3EEC4D05.3000306@nomadiclab.com> Date: Sun, 15 Jun 2003 13:40:05 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Jari Arkko , Tuomas Aura , James Kempf Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH References: <3EEC3A57.1020908@nomadiclab.com> In-Reply-To: <3EEC3A57.1020908@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Thinking a little bit more about the proposed change of separating CGA from AH, I realized that the change would create an "implicit" KMP. That is, when the new CGA layer checks a CGA header and caches the public key, it effectively creates a new IPsec SA that can be selected based on the fixed SPI and source address. Now, AHbis states the following: 2.4 Security Parameters Index (SPI) ... For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case AH). If an IPsec implementation supports multicast, then it MUST support multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. ... Each entry in the Security Association Database (SAD) [KA98a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI. ... Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. ... (There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.)... Now, if we employ this new conceptual algorithm from AHbis, and use it also for unicast traffic, and allow the case where the source address is meaningful but the destination is not, in the SA selection, we get the desired behaviour. Comments? BTW, AHbis WC LC closes tomorrow (Monday). --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 08:37:35 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29591 for ; Sun, 15 Jun 2003 08:37:35 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5FCZhcv027801; Sun, 15 Jun 2003 14:35:43 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGK9KDR; Sun, 15 Jun 2003 14:34:46 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5FCYrN08749; Sun, 15 Jun 2003 14:34:53 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FCYIme016695; Sun, 15 Jun 2003 14:34:18 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5FCYIUX016694; Sun, 15 Jun 2003 14:34:18 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FCYHme016690 for ; Sun, 15 Jun 2003 14:34:17 +0200 (MET DST) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 934BA1C; Sun, 15 Jun 2003 15:44:05 +0300 (EEST) Message-ID: <3EEC6806.5020306@nomadiclab.com> Date: Sun, 15 Jun 2003 15:35:18 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura Cc: ietf-send@standards.ericsson.net Subject: Re: Comments and questions on draft-ietf-send-ipsec-01 References: <9805B5E65CD0D0479D08B7EB832B369F094FDF54@red-msg-08.redmond.corp.microsoft.com> In-Reply-To: <9805B5E65CD0D0479D08B7EB832B369F094FDF54@red-msg-08.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Tuomas Aura wrote: > *3* > Section 6.5 (Authorization chain) > > As far as I can understand, the authorization > certificate chain consists of a chain of PKCs + > one AC. The AC is issued by the subject of the last > PKC. This is non-standard usage of PKCs as they are > effectively used for authorization rather than for > identification. > > Standard usage would be to have no authorization > chains but only a single AC issued directly by whoever > issues them. The AC would specify the name of its > holder. A separate PKC chain would then be used to > resolve the name into a public key. There could be > another PKC chain for the issuer of the AC. > > Obviously, the standard usage is unsatisfactory for > SEND. I don't have any better solution to suggest > than what is currently in the draft and I believe > the authors are fully aware of the problem. Just > thought I'd rant a bit about it. As Jari mentioned, we are aware of this problem. We have been conducting off-line discussions with various folks about this issue. RFC3281 currently has a restriction that the Issuer cannot be a hash of a public key. However, the necesassary ASN.1 encoding is there, the RFC just forbids one from using that reature. I have proposed lifting the restriction. However, so far I haven't seen any real response. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 11:10:22 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04285 for ; Sun, 15 Jun 2003 11:10:21 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5FF7iw2029682; Sun, 15 Jun 2003 17:07:44 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGK9S0A; Sun, 15 Jun 2003 17:07:36 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5FF7hN11826; Sun, 15 Jun 2003 17:07:43 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FF78me005468; Sun, 15 Jun 2003 17:07:08 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5FF78Qu005467; Sun, 15 Jun 2003 17:07:08 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FF77me005463 for ; Sun, 15 Jun 2003 17:07:07 +0200 (MET DST) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 9BAE71C for ; Sun, 15 Jun 2003 18:16:51 +0300 (EEST) Message-ID: <3EEC8BD5.5040500@nomadiclab.com> Date: Sun, 15 Jun 2003 18:08:05 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Some architectural thoughts about AH in SEND Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Continuing my thinking in the proposal about separating CGA from AH, partly basing on Ran's comments from our discussion at the SAAG ML. Let me consider a situation where we have a public key based AH with the following properties: - there is a separate SA for each public key - at the receiver end, the correct SA is selected based on a fixed SPI and a source address - other than that, the SAs are pretty standard, i.e. have lifetime etc. In effect, we would have an AH mode that can use AHbis SPD entries, with the difference that the SA selection is based on the source address (and SPI). However, SA selection based on SPI and source address is already *almost* supported in AHbis; the modifications would be minimal and perhaps we can justify them within the remaining AHbis WC LC time. Let us further suppose that we have a public key based KMP that basically associates an IP address with a public key, effectively creating a separate AH SA for each IP address. The SA would have the properties outlined above, and selected based on the source address. There could be two versions of such KMP: - a CGA based version "inline" version, creating an SA after as a part of the process of verifying a CGA extension header - a certificate based version, where a host creates an SA after receiving and verifying a chain of certificates, rooted on a trusted party and ending in an association between an IP addressa and a public key. The basic difference between the two methods are in the authorization implied by the SAs. In the CGA case the only assurance we have is that it is computationally hard to create another public key that maps to the IP address. In the certificate case the assurance flows from the trusted party, and depends on its certification policy. Returning to SEND, in the CGA case we would have a three stage process for processing incoming packets: - create an AH SA based on the CGA extension header - verify the signature in the AH header, using the newly created SA - process the ND payload, with assurance that the source IP address is associated with a public key, and the public key was used in signing the packet, and it is unlikely that there exists currently another node in the link that uses a different public key but wants to use the same IP address I believe that this is functionally equivalent to the current method, but I haven't checked the details. In the certificate case, the process would be distributed over time, into two steps: - initially, the node sends a query for certificates, receives some, and creates the AH SA based on the certificates, - later on, the node receives a packet, and verifies the signature in the AH header, using the SA created ealier - process the ND payload, with assurance the is based on the contents of the certificates, and recorded in the SA. If it is undesirable to record authorization information into the SA, it is even possible to record the router capabilities and other certificate based information into a separate ND level data structure, indexed by the source IP address and valid if and only if the packet has been properly authenticated earlier on. I think that this design could cleanly separate the various aspects of CGA, certificates, header integrity and data origin authentication, and ND based authorization. It even allows further capabilities, such as caching CGA based SAs, querying for CGA/cert based SAs, etc. We could also use a separate SPI for CGA and certificate based authentication, if needed. Thoughts? --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 11:34:52 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04601 for ; Sun, 15 Jun 2003 11:34:52 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5FFXCG5019522; Sun, 15 Jun 2003 17:33:12 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYPX1QJ; Sun, 15 Jun 2003 17:34:33 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5FFXAsY008624; Sun, 15 Jun 2003 17:33:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FFWqme008957; Sun, 15 Jun 2003 17:32:52 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5FFWqa1008956; Sun, 15 Jun 2003 17:32:52 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FFWpme008952 for ; Sun, 15 Jun 2003 17:32:51 +0200 (MET DST) Received: from kolumbus.fi ([62.248.146.254]) by fep07-app.kolumbus.fi with ESMTP id <20030615153250.WCPN13000.fep07-app.kolumbus.fi@kolumbus.fi>; Sun, 15 Jun 2003 18:32:50 +0300 Message-ID: <3EEC9139.8040202@kolumbus.fi> Date: Sun, 15 Jun 2003 18:31:05 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG , Tuomas Aura Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH References: <3EEC3A57.1020908@nomadiclab.com> In-Reply-To: <3EEC3A57.1020908@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > Sharing the CGA parameters between AH and address generation > is not exactly trivial. Typically, address generation is > handled by ND code, controlled with ifconfig(8), and the API > between ifconfig and the ND code is based on ioctl(SIOC[CG]IF). > On the other hand, AH is part of IPsec, controled with setkey(8), > and the API between the user level and kernel is based on PF_KEY. I agree that this can be troublesome. However, while I agree with you that this could be an issue, I'm not sure I agree with the proposed solution. As you know but the rest of the list may not know, I have doubts about the use of AH vs. "application layer" security in ND options. If you think the IPsec - ND coordination is troublesome, I would suggest that we go for ND options instead, with roughly the same format and functionality as we now have in the Authentication Data field. I'm working on a pros-cons analysis and a drafty draft for this approach, and will post it to the list as soon as possible. > Furthermore, I would propose that ASN.1 is not used, since > having a full ASN.1 DER parser in kernel code just causes > bloat. Instead, I propose the following formats for the > new CGA header and revised AH header. Agree with this, though I don't currently see this as a major problem. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 16:22:29 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10101 for ; Sun, 15 Jun 2003 16:22:28 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5FKKWw2010834; Sun, 15 Jun 2003 22:20:33 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGK0JLG; Sun, 15 Jun 2003 22:20:25 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5FKKVN18176; Sun, 15 Jun 2003 22:20:31 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FKJhme014684; Sun, 15 Jun 2003 22:19:43 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5FKJhKT014683; Sun, 15 Jun 2003 22:19:43 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5FKJfme014679 for ; Sun, 15 Jun 2003 22:19:41 +0200 (MET DST) Received: from esunmail ([129.147.58.120]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5FKJfht003179 for ; Sun, 15 Jun 2003 14:19:41 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGJ00MCTHSS40@edgemail1.Central.Sun.COM> for ietf-send@standards.ericsson.net; Sun, 15 Jun 2003 14:19:41 -0600 (MDT) Received: from 192.168.1.100 ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGJ0050YHSIHQ@mail.sun.net> for ietf-send@standards.ericsson.net; Sun, 15 Jun 2003 14:19:40 -0600 (MDT) Date: Sun, 15 Jun 2003 22:17:21 +0200 From: Julien Laganier Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH In-reply-to: <3EEC9139.8040202@kolumbus.fi> To: Jari Arkko , Pekka Nikander Cc: SEND WG , Tuomas Aura Message-id: <200306152217.21507.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5.2 References: <3EEC3A57.1020908@nomadiclab.com> <3EEC9139.8040202@kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Jari Arkko wrote : > > Pekka Nikander wrote: > > > > Sharing the CGA parameters between AH and address generation > > is not exactly trivial. Typically, address generation is > > handled by ND code, controlled with ifconfig(8), and the API > > between ifconfig and the ND code is based on ioctl(SIOC[CG]IF). > > On the other hand, AH is part of IPsec, controled with setkey(8), > > and the API between the user level and kernel is based on PF_KEY. > > I agree that this can be troublesome. However, while I agree > with you that this could be an issue, I'm not sure I agree with > the proposed solution. > > As you know but the rest of the list may not know, I have doubts > about the use of AH vs. "application layer" security in ND options. > If you think the IPsec - ND coordination is troublesome, I would > suggest that we go for ND options instead, with roughly the > same format and functionality as we now have in the Authentication > Data field. I like the idea of having a CGA-based KMP interfaced with IPsec that can then be used by other protocols than ND (e.g. HIP, CGA-based Opportunistic Encryption). As Pekka said, the modifications needed in AH are minimals and allows to have an IPsec based SEND. Thus, because the provided mechanisms (CGA based-KMP) can probably be reused, if this can avoid us to reinvent the wheel yet another time in another situation, IMHO it's worth trying it. > > Furthermore, I would propose that ASN.1 is not used, since > > having a full ASN.1 DER parser in kernel code just causes > > bloat. Instead, I propose the following formats for the > > new CGA header and revised AH header. > > Agree with this, though I don't currently see this as a major > problem. Being capable of implementing SEND within a low memory fingerprint IPv6 stack maybe of considerable interest in the future, so it makes sense to me not to require that each SEND-enabled node implement a full ASN.1 parser. --julien -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 20:34:48 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15303 for ; Sun, 15 Jun 2003 20:34:47 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5G0VYw2019801; Mon, 16 Jun 2003 02:31:34 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGK05M4; Mon, 16 Jun 2003 02:31:26 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5G0VRsY014017; Mon, 16 Jun 2003 02:31:27 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G0UQme018792; Mon, 16 Jun 2003 02:30:26 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5G0UQXf018791; Mon, 16 Jun 2003 02:30:26 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from 163.net ([218.17.65.148]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G0ULmf018646 for ; Mon, 16 Jun 2003 02:30:23 +0200 (MET DST) Message-Id: <200306160030.h5G0ULmf018646@sw.ericsson.se> From: =?GB2312?B?zfjC582o0bbN+A==?= Subject: =?GB2312?B?vdrKoTgwJbXEs6TNvruwt9Esw+K30crU08OjoQ==?= To: ietf-send@standards.ericsson.net Content-Type: text/html;charset="GB2312" Reply-To: spidersz@163.com Date: Mon, 16 Jun 2003 08:30:25 +0800 X-Priority: 3 X-Mailer: FoxMail 3.11 Release [cn] Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk ÎÞ±êÌâÎĵµ

Ö»ÒªÄú¹«Ë¾ÓÐADSL»òÆäËû¿í´ø·½Ê½ÉÏÍø£¬

netPCphone ÍøÂçµç»°½«Á¢¼´ÖúÄú½ÚÊ¡ 80% µÄ³¤Í¾»°·Ñ£¡

¹úÄÚ³¤Í¾0.20Ôª/·ÖÖÓ£¬¹ú¼Ê³¤Í¾0.50Ôª/·ÖÖÓ!

¶À¼ÒÍƳöÃâ·ÑÊÔÓã¬ÂúÒâºó¸¶¿î·þÎñ£¡

²»ÐèÒªÁª½ÓµçÄÔ,²»ÓÃÊäÈëÕʺÅÃÜÂ룬¸úÆÕͨµç»°Ò»ÑùÖ±½ÓʹÓÃ

µçÐÅIDD¼¶µÄͨ»°ÖÊÁ¿

µ¥»ú¼´¿É²¦´òÊÀ½ç¸÷µØ

×ܹ«Ë¾Óë·Ö¹«Ë¾Í¬Ê±°²×°£¬µã¶Ôµã½«ÊµÏÖÁã»°·Ñͨ»°£¡

ÏêÇéÇëä¯ÀÀhttp://voip.3322.net
-------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 20:58:58 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15577 for ; Sun, 15 Jun 2003 20:58:58 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5G0uEG5005544; Mon, 16 Jun 2003 02:56:14 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8HYRP; Mon, 16 Jun 2003 02:56:28 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5G0uBsY014192; Mon, 16 Jun 2003 02:56:11 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G0tbme021297; Mon, 16 Jun 2003 02:55:37 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5G0tbIx021296; Mon, 16 Jun 2003 02:55:37 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G0tZme021292 for ; Mon, 16 Jun 2003 02:55:36 +0200 (MET DST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 15 Jun 2003 20:55:34 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BAD3@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Nikander'" , SEND WG Cc: Jari Arkko , Tuomas Aura , James Kempf Subject: RE: Should CGA parameters be a separate header instead of being i ntegrated with AH Date: Sun, 15 Jun 2003 20:55:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Pekka, Perhaps we don't need a "CGA extension header", couldn't we just use a DST options header which can be located before IPsec headers? Hesham > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Sunday, June 15, 2003 5:20 AM > To: SEND WG > Cc: Jari Arkko; Tuomas Aura; James Kempf > Subject: Should CGA parameters be a separate header instead of being > integrated with AH > > > Based our (so far limited) implementation experience, I am > starting to think that perhaps the CGA public key and > parameters should be included in a separate option instead > of being integrated into the AH header. In this note I will > first briefly explain the current situation, reason for the > suggested situation based on our experienc, and finally my > proposal for a new design. > > 1. Current design > ================= > > In draft-ietf-send-ipsec-01.txt, the IPsec AH header is > defined to include the following structure: > > - standard AH headers (Next header, length, SPI, replay counter) > - timestamp > - Key Information > - signature > > The Key Information field is defined, using ASN.1, to contain > cgaParameters, including the CGA key, and signerInfo, which > may contain a different key than the CGA key. > > 2. Why should this be changed > ============================= > > While implementing the current proposal, we seem to end up > including the CGA information in at least two separate kernel > data structures. Firstly, we need the have the CGA parameters > field available for CGA address generation. CGA address generation > is performed, in turn, either when the first link local address > is generated, or when a host is using autoconfiguration and > receives a new routing prefix in an RA. > > Secondly, we need to have the CGA parameters field available > when protecting packets with AH. The reason for this is that the > CGA parameters is included the AH header; otherwise they are not > needed. > > Sharing the CGA parameters between AH and address generation > is not exactly trivial. Typically, address generation is > handled by ND code, controlled with ifconfig(8), and the API > between ifconfig and the ND code is based on ioctl(SIOC[CG]IF). > On the other hand, AH is part of IPsec, controled with setkey(8), > and the API between the user level and kernel is based on PF_KEY. > > Thus, if we try to inject the CGA parameters data just once to > the kernel, we get an ugly dependency between two otherwise fairly > independent pieces of code. Alternatively, we have to pass the > exactly same data twice to the kernel, and typically even with > different user level utilities. > > Now, if we separated CGA processing completely from AH processing, > AH should not know about CGA at all. When sending outbound packets, > the ND stack would include a CGA header, and the IPsec processing > would included it as a part of the IP packet, making sure that > it is located before the AH header (just like HbH options or > Routing Header is). On the input side, a separate piece of code > (trigged by the next header field) would process the CGA header, > drop the packet if the CGA verification fails, and cache the key > otherwise. AH would then be able to fetch the key from the cache. > > In addition to making the implementation cleaner, the new design > would have another benefit: It would make CGA independent of AH, > making it possible to use it also with e.g. ESP or HIP. > > > 3. Proposal for a new design > ============================ > > I propose that we move the cga parameters from the AH header to > a separate header, which MUST precede the AH header: > > *------------------------------------------------* > | IPv6 | CGA | AH | ICMPv6 | ND message | > | Header | Header | Header | Header | | > *------------------------------------------------* > > The CGA header would include > - cgaParameters, including > - auxParameters, just as today > - publicKey, just as today > > The AH header would then include just a hash of the public > key, i.e., a key name. > > Furthermore, I would propose that ASN.1 is not used, since > having a full ASN.1 DER parser in kernel code just causes > bloat. Instead, I propose the following formats for the > new CGA header and revised AH header. > > --------------------------------------------------------------------- > > X. CGA Extension Header format > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Hdr Ext Len | RES | PAD |CC | Algorithm | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | Modifier | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . Public key . > . (variable length) . > | > > > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Next Header 8-bit selector. Identifies the > type of header > immediately following the CGA header. > > Hdr Ext Len 8-bit unsigned integer. Length of the CGA > header in 8-octet units, not including the > first 8 octets. > > RESERVED Reserved for future use. MUST be set zero > by the sender and SHOULD be ignored by the > receiver. > > CC Collision Count. As defined in [CGA]. > > PAD Padding length (in octets). > > Algorithm Public key algorithm, as defined in > Section 3.2 > in [RFC2535]. All conforming > implementations > MUST support RSA/MD5. > > Modifier CGA modifier. As defined in [CGA]. > > Public key Public key in [RFC2535] format. > For RSA, see > [RFC2537]. Padded with zeros, if necessary, > so that the header length becomes > integral with > 8-octet units. The number of padding octets > (if any) is indicated by the PAD field. > > Notes: > > - the extension header DOES NOT include the routing prefix, since > it is implicitly available in the source address. > > --------------------------------------------------------------------- > > 7.1.2 Integrity Check Value Format > > [Note that AHbis has renamed the Authentication Data field into > Integrity Check Value.] > > The format of the ICV field in AH depends on the chosen > transform. > For the AH_RSA_Sig transform, the format is as follows: > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > + Timestamp > + > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > + > + > | > | > + > + > | Key Information > | > + > + > | > | > + > + > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > . > . > . Digital Signature (remaining bytes) > . > . > . > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The meaning of the fields is described below: > > Timestamp > > This 64 bit unsigned integer field contains a > timestamp used for > replay protection (the Sequence Number field in AH is > not used for > AH_RSA_Sig). The use of this field is discussed in > Section 7.1.4. > > Key Information > > A 160-bit long SHA-1 hash of the public key. > > Digital Signature > > This variable length field contains the signature > made using the > sender's private key, over the the whole packet as > defined by the > usual AH rules [3]. The signature is made using the > RSA algorithm > and MUST be encoded as private key encryption in PKCS > #1 format > [17]. > > The length of this field is determined by the PKCS #1 > encoding. > > --------------------------------------------------------------------- > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jun 15 21:01:12 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15652 for ; Sun, 15 Jun 2003 21:01:11 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5G0xcw2021051; Mon, 16 Jun 2003 02:59:38 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8HY86; Mon, 16 Jun 2003 02:59:53 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5G0xbN24465; Mon, 16 Jun 2003 02:59:37 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G0xTme021501; Mon, 16 Jun 2003 02:59:29 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5G0xTXK021500; Mon, 16 Jun 2003 02:59:29 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G0xRme021495 for ; Mon, 16 Jun 2003 02:59:28 +0200 (MET DST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 15 Jun 2003 20:59:27 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BAD4@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Jari Arkko'" , Pekka Nikander Cc: SEND WG , Tuomas Aura Subject: RE: Should CGA parameters be a separate header instead of being i ntegrated with AH Date: Sun, 15 Jun 2003 20:59:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Jari, One of the advantages I see in an extension header is that CGAs could be used to secure messages other than ND (e.g. BUs). Looking forward to your draft. Hesham > -----Original Message----- > From: Jari Ark [mailto:jari.arkko@kolumbus.fi] > Sent: Sunday, June 15, 2003 11:31 AM > To: Pekka Nikander > Cc: SEND WG; Tuomas Aura > Subject: Re: Should CGA parameters be a separate header > instead of being > integrated with AH > > > > Pekka Nikander wrote: > > > Sharing the CGA parameters between AH and address generation > > is not exactly trivial. Typically, address generation is > > handled by ND code, controlled with ifconfig(8), and the API > > between ifconfig and the ND code is based on ioctl(SIOC[CG]IF). > > On the other hand, AH is part of IPsec, controled with setkey(8), > > and the API between the user level and kernel is based on PF_KEY. > > I agree that this can be troublesome. However, while I agree > with you that this could be an issue, I'm not sure I agree with > the proposed solution. > > As you know but the rest of the list may not know, I have doubts > about the use of AH vs. "application layer" security in ND options. > If you think the IPsec - ND coordination is troublesome, I would > suggest that we go for ND options instead, with roughly the > same format and functionality as we now have in the Authentication > Data field. > > I'm working on a pros-cons analysis and a drafty draft for this > approach, and will post it to the list as soon as possible. > > > Furthermore, I would propose that ASN.1 is not used, since > > having a full ASN.1 DER parser in kernel code just causes > > bloat. Instead, I propose the following formats for the > > new CGA header and revised AH header. > > Agree with this, though I don't currently see this as a major > problem. > > --Jari > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 02:35:37 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03354 for ; Mon, 16 Jun 2003 02:35:37 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5G6WAG5004641; Mon, 16 Jun 2003 08:32:10 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYPZLHW; Mon, 16 Jun 2003 08:33:33 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5G6W8sY016932; Mon, 16 Jun 2003 08:32:08 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G6VQme017356; Mon, 16 Jun 2003 08:31:26 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5G6VQe1017355; Mon, 16 Jun 2003 08:31:26 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G6VPme017345 for ; Mon, 16 Jun 2003 08:31:25 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 5E6991C; Mon, 16 Jun 2003 09:41:07 +0300 (EEST) Message-ID: <3EED6473.3060102@nomadiclab.com> Date: Mon, 16 Jun 2003 09:32:19 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: SEND WG , Jari Arkko , Tuomas Aura , James Kempf Subject: Re: Should CGA parameters be a separate header instead of being i ntegrated with AH References: <748C6D0A58C0F94CA63C198B6674697A0141BAD3@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BAD3@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hesham, Soliman Hesham wrote: > Perhaps we don't need a "CGA extension header", couldn't > we just use a DST options header which can be located > before IPsec headers? Well, technically it could, but I doubt the benefit from that. Firstly, the total size of the packet would be slightly larger. Secondly, it would be technically easier to plug in a new extension header to a live kernel than a new DST OPT. Thirdly, it would have to be a mandatory DST OPT or else the next step (AH / ESP / HIP verification) would fail. Thus, I don't see any real benefit. A new extension header would have the nice benefit that you get a clean ICMP Parameter Problem error message. Well, you would also get one from a DST OPT, too. Hmm. Maybe there would be differences if the CGA ext header is sent to a multicast destionation. I have to think about this. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 03:49:46 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04632 for ; Mon, 16 Jun 2003 03:49:45 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5G7lRw2026747; Mon, 16 Jun 2003 09:47:27 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGH7ZD8; Mon, 16 Jun 2003 09:49:11 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5G7lQN05202; Mon, 16 Jun 2003 09:47:26 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G7kwme026783; Mon, 16 Jun 2003 09:46:59 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5G7kwVj026782; Mon, 16 Jun 2003 09:46:58 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5G7kvme026778 for ; Mon, 16 Jun 2003 09:46:57 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id C76B323; Mon, 16 Jun 2003 10:56:43 +0300 (EEST) Message-ID: <3EED762C.5060306@nomadiclab.com> Date: Mon, 16 Jun 2003 10:47:56 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Cc: Barbara Fraser , tytso@mit.edu, Stephen Kent , SEND WG Subject: AHbis WG LC: need for source address based selectors References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> In-Reply-To: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit One more comment to the AHbis WG LC: AHbis currently states the following: > 2.4 Security Parameters Index (SPI) > > The SPI is an arbitrary 32-bit value that is used by a receiver to > identify the SA to which an incoming packet is bound. For a unicast > SA, the SPI can be used by itself to specify an SA, or it may be used > in conjunction with the IPsec protocol type (in this case AH). > Since, for unicast SAs, the SPI value is generated by the receiver, > whether the value is sufficient to identify an SA by itself, or > whether it must be used in conjunction with the IPsec protocol value > is a local matter. The SPI field is mandatory and this mechanism for > mapping inbound traffic to unicast SAs described above MUST be > supported by all AH implementations. However, in the SEND WG we are using AH with public key crypto, with a fixed SPI. There the key used depends on the sender of the message, not the receiver. Hence, for our purposes neither the SPI alone nor SPI + protocol are enough. We need also the ability to select the SA based on SPI + source address, even for unicast. > If an IPsec implementation supports multicast, then it MUST support > multicast SAs using the following algorithm for mapping inbound IPsec > datagrams to SAs. ... Each entry in the Security Association > Database (SAD) [KA98a] must indicate whether the SA lookup makes use > of the source and destination IP addresses, in addition to the SPI. > ... (There is no current requirement to support SA mapping based on > the source address but not the destination address, thus one of the > possible four values is not meaningful.) .... Since we are using PK crypto, we also need the possibility for selecting the SA based solely on the source address. In fact, for our fixed SPI, the destination address does not have any role, not even whether the destination address is unicast or multicast. I don't know how to handle this so late in the process. I would like to see the text to be sufficiently revised to allow source address based SA selection, so that we could use it directly in SEND. However, I have no idea how the IPSEC WG would feel about that. --Pekka Nikander SEND WG co-chair -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 07:31:13 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08368 for ; Mon, 16 Jun 2003 07:31:13 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GBTCG5028722; Mon, 16 Jun 2003 13:29:12 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYP693N; Mon, 16 Jun 2003 13:30:36 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5GBTBN25829; Mon, 16 Jun 2003 13:29:11 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GBSRme025681; Mon, 16 Jun 2003 13:28:27 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5GBSRPG025680; Mon, 16 Jun 2003 13:28:27 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from albatross.tn.sw.ericsson.se (albatross.tn.sw.ericsson.se [193.180.251.49]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GBSQme025676 for ; Mon, 16 Jun 2003 13:28:26 +0200 (MET DST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GBSQG5028597 for ; Mon, 16 Jun 2003 13:28:26 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8LWLG; Mon, 16 Jun 2003 13:28:42 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5GBSAB8021544 for ; Mon, 16 Jun 2003 14:28:10 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id AE7855F691 for ; Mon, 16 Jun 2003 14:28:39 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 553BB6A901; Mon, 16 Jun 2003 14:28:20 +0300 (EEST) Message-ID: <3EEDA96A.4090303@piuha.net> Date: Mon, 16 Jun 2003 14:26:34 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: Pekka Nikander , SEND WG , Tuomas Aura Subject: Re: Should CGA parameters be a separate header References: <748C6D0A58C0F94CA63C198B6674697A0141BAD4@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BAD4@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > One of the advantages I see in an extension header > is that CGAs could be used to secure messages other > than ND (e.g. BUs). No doubt CGAs could be useful in other contexts. The question is, what's the easiest way to get them in place in those other contexts? A generic extension header, or an "application" specific extension, such as a new mobility option for MIPv6 MH? I simply have the opinion that the latter approach is going to be faster in terms of implementations and standardization, and more robust in terms of the functions it can offer. For instance, is the CGA extension header for a BU going to say something about the care-of address or home address or both? It seems to me that there exists application layer needs and data that should be taken into account, and this may be hard if the solution is too generic. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 07:57:14 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09274 for ; Mon, 16 Jun 2003 07:57:13 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GBuBcv011396; Mon, 16 Jun 2003 13:56:11 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYP7FNK; Mon, 16 Jun 2003 13:56:45 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5GBtIsY004019; Mon, 16 Jun 2003 13:55:18 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GBt6me029302; Mon, 16 Jun 2003 13:55:06 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5GBt6VR029301; Mon, 16 Jun 2003 13:55:06 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from albatross.tn.sw.ericsson.se (albatross.tn.sw.ericsson.se [193.180.251.49]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GBt5me029297 for ; Mon, 16 Jun 2003 13:55:05 +0200 (MET DST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GBt5G5002997 for ; Mon, 16 Jun 2003 13:55:05 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYP7FLK; Mon, 16 Jun 2003 13:56:29 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5GBsnB8023228 for ; Mon, 16 Jun 2003 14:54:49 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id 0A8125F691 for ; Mon, 16 Jun 2003 14:55:19 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 908E96A901 for ; Mon, 16 Jun 2003 14:54:59 +0300 (EEST) Message-ID: <3EEDAFA9.40704@piuha.net> Date: Mon, 16 Jun 2003 14:53:13 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: ND-options based approach instead of AH Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Given that we seem to be opening an architecture discussion about the protocol pieces, I'd like to propose an scheme based solely on Neighbor Discovery options. Functionally, this scheme is almost equivalent to the current mechanism in the WG draft, or the CGA extension header separation proposed by Pekka. However, this scheme offers the following benefits: * The full security solution is in one place, easy to implement and analyze. * The CGA parts are easily separable into a different draft, if the IPR considerations require this. * The security solution can directly use ND layer information, such as Target Address. * Transition scheme appears to be smoother, and requires only one copy of each message broadcast on the link whereas the current approach required two. * No Neighbor Discovery modifications are required, only extensions. * No IPsec extensions or modifications are required. * No extension header numbers are used. A more in-depth list of the differences can be found from http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndopt.html#comptoipsec I have taken the liberty of producing a drafty draft for this approach. The draft is available at: http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndopt.txt http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndopt.html http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndoptdiff.html The draft is intended only for the purposes of discussing alternative solutions. It derives the material largely from the current WG document. It also has open questions. One bigger item is the security differences of the current transition approach vs. the approach I'm suggesting here. Disclaimer: I'm reasonably happy with the current WG draft as well and it works. But given that we started a discussion based on implementation experiences and correlating data in different pieces of the stack, perhaps this approach is something that we should look at. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 08:34:48 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10816 for ; Mon, 16 Jun 2003 08:34:48 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GCSTcv016208; Mon, 16 Jun 2003 14:28:29 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8MGQ0; Mon, 16 Jun 2003 14:27:55 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5GCRasY004727; Mon, 16 Jun 2003 14:27:36 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GCRGme003877; Mon, 16 Jun 2003 14:27:16 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5GCRGuK003876; Mon, 16 Jun 2003 14:27:16 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from penguin.al.sw.ericsson.se (penguin.al.sw.ericsson.se [193.180.251.47]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GCRFme003872 for ; Mon, 16 Jun 2003 14:27:15 +0200 (MET DST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GCREw2017793 for ; Mon, 16 Jun 2003 14:27:14 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLDSJB; Mon, 16 Jun 2003 14:27:08 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5GCQxB8025517 for ; Mon, 16 Jun 2003 15:26:59 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id 6F5405F691 for ; Mon, 16 Jun 2003 15:27:28 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F1D2F6A901; Mon, 16 Jun 2003 15:27:08 +0300 (EEST) Message-ID: <3EEDB5CA.7050601@piuha.net> Date: Mon, 16 Jun 2003 15:19:22 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: SEND WG Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH References: <3EEC3A57.1020908@nomadiclab.com> In-Reply-To: <3EEC3A57.1020908@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, I wanted to ask a clarification... you wrote the following: > Sharing the CGA parameters between AH and address generation > is not exactly trivial. Typically, address generation is > handled by ND code, controlled with ifconfig(8), and the API > between ifconfig and the ND code is based on ioctl(SIOC[CG]IF). > On the other hand, AH is part of IPsec, controled with setkey(8), > and the API between the user level and kernel is based on PF_KEY. ... > Thus, if we try to inject the CGA parameters data just once to > the kernel, we get an ugly dependency between two otherwise fairly > independent pieces of code. Alternatively, we have to pass the > exactly same data twice to the kernel, and typically even with > different user level utilities. ... > In addition to making the implementation cleaner, the new design > would have another benefit: It would make CGA independent of AH, > making it possible to use it also with e.g. ESP or HIP. It is quite easy for me to understand how this works nicely in the receiving end. But was your original intent to get rid of passing the data twice to the kernel? The part that I don't understand is that if the new extension header would be generally useful, it would have to be outside the ND module, right? So how do we avoid setting the CGA parameters both to ND (where the address generation takes place) and to the new extension header code (which should attach the used CGA parameters to the packet)? Or is the intent that the ND module creates the CGA header as well? But then ND would have to sit in two places in the stack path, before and after IPsec. Is this what is intended? --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 09:19:12 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13041 for ; Mon, 16 Jun 2003 09:19:09 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GDGBw2026948; Mon, 16 Jun 2003 15:16:11 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYP756Y; Mon, 16 Jun 2003 15:17:36 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5GDGAN29498; Mon, 16 Jun 2003 15:16:10 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GDFome010845; Mon, 16 Jun 2003 15:15:50 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5GDFoRj010844; Mon, 16 Jun 2003 15:15:50 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GDFnme010840 for ; Mon, 16 Jun 2003 15:15:49 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 59DC41C; Mon, 16 Jun 2003 16:25:31 +0300 (EEST) Message-ID: <3EEDC33C.1080104@nomadiclab.com> Date: Mon, 16 Jun 2003 16:16:44 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Cc: SEND WG Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH References: <3EEC3A57.1020908@nomadiclab.com> <3EEDB5CA.7050601@piuha.net> In-Reply-To: <3EEDB5CA.7050601@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > It is quite easy for me to understand how this works nicely in the > receiving end. But was your original intent to get rid of passing the > data twice to the kernel? .... Or is the intent that the ND module > creates the CGA header as well? Yes. > But then ND would have to sit in two places in the stack path, before > and after IPsec. Is this what is intended? No. IPsec will split and splice the packet anyway, since even in the typical case the packet arrives as a complete packet to IPsec, which then injects AH or ESP. Thus, the ND layer can include the CGA extension header, and IPsec will just neatly place AH on the right place, between the CGA header and the ND payload. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 09:22:30 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13202 for ; Mon, 16 Jun 2003 09:22:24 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GDKWw2027909; Mon, 16 Jun 2003 15:20:32 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8MT89; Mon, 16 Jun 2003 15:20:48 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5GDKUsY006167; Mon, 16 Jun 2003 15:20:30 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GDKLme011139; Mon, 16 Jun 2003 15:20:21 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5GDKL0c011138; Mon, 16 Jun 2003 15:20:21 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GDKKme011134 for ; Mon, 16 Jun 2003 15:20:20 +0200 (MET DST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5GDKIQ8006531; Mon, 16 Jun 2003 16:20:18 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) id h5GDKIsZ006527; Mon, 16 Jun 2003 16:20:18 +0300 Date: Mon, 16 Jun 2003 16:20:18 +0300 Message-Id: <200306161320.h5GDKIsZ006527@burp.tkv.asdf.org> From: Markku Savela To: pekka.nikander@nomadiclab.com CC: jari.arkko@piuha.net, ietf-send@standards.ericsson.net In-reply-to: <3EEDC33C.1080104@nomadiclab.com> (message from Pekka Nikander on Mon, 16 Jun 2003 16:16:44 +0300) Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH References: <3EEC3A57.1020908@nomadiclab.com> <3EEDB5CA.7050601@piuha.net> <3EEDC33C.1080104@nomadiclab.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk > No. IPsec will split and splice the packet anyway, since even > in the typical case the packet arrives as a complete packet > to IPsec, which then injects AH or ESP. Thus, the ND layer can > include the CGA extension header, and IPsec will just neatly > place AH on the right place, between the CGA header and the > ND payload. But, then IPSEC needs to "know" the CGA header. Currently, IPSEC knows about some extension headers (Dest. Opt, Hop By Hop, RTH), and when it bumps into "unknown", it will splice it's headers before that. (e.g., unmodified IPSEC code will put it's headers in front of your proposed CGA header). -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 09:30:13 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13305 for ; Mon, 16 Jun 2003 09:30:12 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GDSLG5020609; Mon, 16 Jun 2003 15:28:21 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGL1AJ6; Mon, 16 Jun 2003 15:28:14 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5GDSIsY006413; Mon, 16 Jun 2003 15:28:18 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GDS2me011851; Mon, 16 Jun 2003 15:28:02 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5GDS2mC011850; Mon, 16 Jun 2003 15:28:02 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GDS1me011846 for ; Mon, 16 Jun 2003 15:28:01 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 7055A1C; Mon, 16 Jun 2003 16:37:49 +0300 (EEST) Message-ID: <3EEDC61F.7000106@nomadiclab.com> Date: Mon, 16 Jun 2003 16:29:03 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markku Savela Cc: jari.arkko@piuha.net, ietf-send@standards.ericsson.net Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH References: <3EEC3A57.1020908@nomadiclab.com> <3EEDB5CA.7050601@piuha.net> <3EEDC33C.1080104@nomadiclab.com> <200306161320.h5GDKIsZ006527@burp.tkv.asdf.org> In-Reply-To: <200306161320.h5GDKIsZ006527@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Markku Savela wrote: >>No. IPsec will split and splice the packet anyway, since even >>in the typical case the packet arrives as a complete packet >>to IPsec, which then injects AH or ESP. Thus, the ND layer can >>include the CGA extension header, and IPsec will just neatly >>place AH on the right place, between the CGA header and the >>ND payload. > > But, then IPSEC needs to "know" the CGA header. Currently, IPSEC knows > about some extension headers (Dest. Opt, Hop By Hop, RTH), and when it > bumps into "unknown", it will splice it's headers before that. (e.g., > unmodified IPSEC code will put it's headers in front of your proposed > CGA header). Yes. That is a set of two line changes. Trivial to implement. In KAME the changes would go to ip6_output.c:ip6_output, plus the necessary .h files. Most of those changes you have to do anyway if you add a new extension header, only about one or two would be IPsec specific. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 17:11:33 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02959 for ; Mon, 16 Jun 2003 17:11:32 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GL9bcv029076; Mon, 16 Jun 2003 23:09:38 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYP0C6F; Mon, 16 Jun 2003 23:10:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5GL8kN15311; Mon, 16 Jun 2003 23:08:46 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GL8Cme011063; Mon, 16 Jun 2003 23:08:12 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5GL8C62011062; Mon, 16 Jun 2003 23:08:12 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GL8Ame011058 for ; Mon, 16 Jun 2003 23:08:11 +0200 (MET DST) Message-ID: <01fc01c3344b$2c12d890$cc6ffea9@DCLKEMPFTP> From: "James Kempf" To: "Jari Arkko" , "Tuomas Aura" Cc: References: <9805B5E65CD0D0479D08B7EB832B369F094FDF54@red-msg-08.redmond.corp.microsoft.com> <3EEC33BF.2000109@kolumbus.fi> Subject: Re: Comments and questions on draft-ietf-send-ipsec-01 Date: Mon, 16 Jun 2003 14:06:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > "Hosts SHOULD store certificate chains retrieved in Delegation Chain > Discovery messages if they start from a root trusted by the host. The > certificates chains SHOULD be verified before storing them. Routers > are required to send the certificates one by one, starting from the > trusted root end of the chain. Except for temporary purposes to allow > for message loss and reordering, hosts SHOULD NOT store certificates > received in a Delegation Chain Advertisement unless they contain a > certificate which can be immediately verified either to the trusted > root or to a certificate which has been verified earlier." > How about: Hosts SHOULD store certificate chains received in Delegation Chain Discovery messages if they start from a root trusted by the host. The certificate chains SHOULD be verified before storing them. Routers MUST send the certificates one by one, starting from the trusted root end of the chain. Except for temporary purposes to allow for message loss and reordering, hosts SHOULD NOT store certificates received in a Delegation Chain Advertisement unless they contain a certificate which can be immediately verified either to the trusted root received as the first certificate in the chain, to a trusted root currently held by the host, or to a certificate which has been verified earlier. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 18:33:44 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06843 for ; Mon, 16 Jun 2003 18:33:43 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GMWucv031671; Tue, 17 Jun 2003 00:32:56 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYP0JT2; Tue, 17 Jun 2003 00:33:31 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5GMW2sY015272; Tue, 17 Jun 2003 00:32:02 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GMVeme021762; Tue, 17 Jun 2003 00:31:40 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5GMVece021761; Tue, 17 Jun 2003 00:31:40 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5GMVcme021757 for ; Tue, 17 Jun 2003 00:31:38 +0200 (MET DST) Message-ID: <028601c33456$d63d28b0$cc6ffea9@DCLKEMPFTP> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" References: <3EEC8BD5.5040500@nomadiclab.com> Subject: Re: Some architectural thoughts about AH in SEND Date: Mon, 16 Jun 2003 15:30:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I like the idea of using a separate CGA header, though we need to make sure it works well on Linux. I particularly like the idea of having two SPIs, one for CGA and another for trusted roots. They always struck me as being separate. However, I have a comment: > In the certificate case, the process would be distributed > over time, into two steps: > > - initially, the node sends a query for certificates, > receives some, and creates the AH SA based on the > certificates, > - later on, the node receives a packet, and verifies > the signature in the AH header, using the SA > created ealier > - process the ND payload, with assurance the is based > on the contents of the certificates, and recorded > in the SA. > I think the sequence goes something like this: - node receives a NS containing an AH header with an unverified IP address. - In the IPsec code, call out to obtain the certificates. . Certificate chain found? Return it. . No certificate chain found? Use DCS/DCA to find and return. - Create IPsec SA based on destination address (note we can't use the source address here because the SA can have a different chain depending on the chain returned). - Process AH header using SA. - Process ND payload if AH verifies packet. I believe the second step is unavoidable for any IPsec SPI that uses public key and certificates, and is not specific to SEND, but how the certificates are retrieved if they are not available will differ. In this case, it is the DCS/DCA, so the SPI becomes specific to SEND. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 16 22:21:57 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13138 for ; Mon, 16 Jun 2003 22:21:56 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H2KGcv006293; Tue, 17 Jun 2003 04:20:16 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYP08MW; Tue, 17 Jun 2003 04:20:51 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5H2JON24462; Tue, 17 Jun 2003 04:19:24 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H2Icme029444; Tue, 17 Jun 2003 04:18:38 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5H2Ic7K029443; Tue, 17 Jun 2003 04:18:38 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H2IZme029435 for ; Tue, 17 Jun 2003 04:18:35 +0200 (MET DST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 16 Jun 2003 22:18:30 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BAD9@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Nikander'" , Soliman Hesham Cc: SEND WG , Jari Arkko , Tuomas Aura , James Kempf Subject: RE: Should CGA parameters be a separate header instead of being i ntegrated with AH Date: Mon, 16 Jun 2003 22:18:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk > Soliman Hesham wrote: > > Perhaps we don't need a "CGA extension header", couldn't > > we just use a DST options header which can be located > > before IPsec headers? > > Well, technically it could, but I doubt the benefit from that. > Firstly, the total size of the packet would be slightly larger. => Not sure I got that. The only difference is the value of the 'type' field right? > Secondly, it would be technically easier to plug in a new > extension header to a live kernel than a new DST OPT. > Thirdly, it would have to be a mandatory DST OPT or else the > next step (AH / ESP / HIP verification) would fail. => By 'mandatory' you mean it has to exist in the packet right? Of course, the same would happen for either header. I just think that we should only define new header types when we have to. Thus, I > don't see any real benefit. > > A new extension header would have the nice benefit that you > get a clean ICMP Parameter Problem error message. Well, you > would also get one from a DST OPT, too. Hmm. Maybe there would > be differences if the CGA ext header is sent to a multicast > destionation. I have to think about this. => Ok Hesham -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 02:17:44 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00016 for ; Tue, 17 Jun 2003 02:17:43 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H6EpG5006044; Tue, 17 Jun 2003 08:14:51 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQAV3H; Tue, 17 Jun 2003 08:16:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5H6EoN00272; Tue, 17 Jun 2003 08:14:50 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H6EGme003965; Tue, 17 Jun 2003 08:14:16 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5H6EF91003964; Tue, 17 Jun 2003 08:14:15 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H6EEme003960 for ; Tue, 17 Jun 2003 08:14:14 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 385B21C; Tue, 17 Jun 2003 09:24:00 +0300 (EEST) Message-ID: <3EEEB1F1.7060304@nomadiclab.com> Date: Tue, 17 Jun 2003 09:15:13 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Francis Dupont Subject: [Fwd: Re: SEND Protocol Document Review] Content-Type: multipart/mixed; boundary="------------090009040106090601020902" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format. --------------090009040106090601020902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please find enclosed Francis Dupond's comments on the current drafts, forwarded with his permission. Francis, thanks a lot for your review! --Pekka & James --------------090009040106090601020902 Content-Type: message/rfc822; name="Re: SEND Protocol Document Review" Content-Disposition: inline; filename="Re: SEND Protocol Document Review" X-Sieve: cmu-sieve 2.0 Return-Path: Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by n97.nomadiclab.com (Postfix) with ESMTP id EBAE11C for ; Sat, 14 Jun 2003 19:25:50 +0300 (EEST) Received: by n2.nomadiclab.com (Postfix) id D0B2322E17; Sat, 14 Jun 2003 19:16:01 +0300 (EEST) Delivered-To: pnr@nomadiclab.com Received: from d2.nomadiclab.com (bastion [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 5D71A22E16 for ; Sat, 14 Jun 2003 19:16:00 +0300 (EEST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by d2.nomadiclab.com (Postfix) with ESMTP id 5C0046CCB0 for ; Sat, 14 Jun 2003 19:15:59 +0300 (EEST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h5EGFsa26428; Sat, 14 Jun 2003 18:15:54 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h5EGFsof022884; Sat, 14 Jun 2003 18:15:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200306141615.h5EGFsof022884@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Cc: "Pekka Nikander" Subject: Re: SEND Protocol Document Review In-reply-to: Your message of Thu, 05 Jun 2003 13:20:15 PDT. <00f801c32b9f$e347e500$896015ac@DCLKEMPFTP> Date: Sat, 14 Jun 2003 18:15:54 +0200 Sender: Francis.Dupont@enst-bretagne.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr MIME-Version: 1.0 Here are my comments about draft-ietf-send-ipsec-01.txt: - 1. Introduction (proposed improvement) security associations needed for protecting ND is impractically large => s/is/can be/ (rationale: it is not always the case, for instance p2p links can be protected with a pair of SAs). - same (comment) approach involves the use of IPsec AH [3] to secure all => don't forget than the IPsec WG still wants to phase out AH, that was voted at a previous IETF meeting. So I suggest you ask the IESG to *not* make AH historic in a close future. IMHO IPsec guys should be happy as soon as AH in no more mandatory... - 2. Terms (spelling) some other parameters using a one-way hash function. => s/a/an/ ? - same (comment) but not both. A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier [2]. => (note that this is discussed in the document). RFC 2401bis is supposed to use only the SPI. IMHO you have to show this document to Stephen Kent in order to support both 2401 and 2401bis context. ESPv3 draft can give good hints if you don't want to read the whole IPsec mailing list archive. - same (comment) Security association database A nominal database containing parameters that are associated with each (active) security association. For inbound and outbound IPsec processing, these databases are separate. => databases are per-interface too. IMHO this is not a problem if we ignore the multiple interfaces attached to the same link case... - 3. Neighbor and Router Discovery Overview (comment) how the messages should be treated. Where this section and the original Neighbor Discovery RFCs are in conflict, the original RFCs take precedence. => I have a real concern with this statement. If this section is not normative, it should be made clearer. I have a proposal: explain that the section should be an appendix but for clarity it is at this place. - same (comment) o The Redirect function is used for automatically redirecting hosts to an alternate router. Redirect is specified in Section 8 of RFC 2461 [6]. It is similar to the ICMPv4 Redirect message [19]. => this is *not* true: IPv6 redirect has 3 functions: - change the router for a better one (the function you described) - change the link-layer address (target == destination). This should be in general by the peer itself with a NA at the exception of the last case. - give the link-layer address of an off-link destination which is in fact on-link. This "external redirect" is used for IPv6 over ATM to implement NHRP short cuts for instance. - same (wording) header consisting of ICMPv6 header and ND message-specific data, and ^ an - same (improvement) The destination addresses used in these messages are as follows: => there are two missing things: - a global statement explaining that ND is local to the link (for all messages). - constraints over the source address too. o Neighbor Solicitation: The destination address is either the solicited-node multicast address, unicast address, or an anycast ^ a address. => source in unspecified (DAD) or a unicast address assigned to the sending interface. Note that in general the source is the same than the one of the triggering packet. o Neighbor Advertisement: The destination address is either a unicast address or the All Nodes multicast address [1]. => source is a unicast address assigned to the sending interface. o Router Solicitation: The destination address is typically the All Routers multicast address [1]. => same than for NS but the unspecified source has no special meaning: it is just an optimization for startup. o Router Advertisement: The destination address can be either a unicast or the All Nodes multicast address [1]. Like the solicitation message, the advertisement is also local to the link only. => source is a link-local address assigned to the sending interface (usually there is only one such address). Please make the second statement (local to the link only) more general. o Redirect: This message is always sent from the router's link-local address to the source address of the packet that triggered the Redirect. Hosts verify that the IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. Rules in [1] dictate that unspecified, => unspecified source is not forbidden. anycast, or multicast addresses may not be used as source addresses. Therefore, the destination address will always be a unicast address. => to deduce that the destination address in the IPv6 header of a redirect (there is a field named "destination address" to help us ;-) is always a unicast address the argument is: - anycasts and multicasts are forbidden as source - unspecified is forbidden as destination (all nodes is used when one'd like to reach any node). - 4. Secure Neighbor Discovery Overview (comment) Optionally, an authorization certificate can specify the prefixes for which the router is allowed to act as a router. => I don't understand at all this statement: prefix discovery is not bound to the default router function... I believe that you mean "is allowed to advertise"?? - same (comment/request for improvement) o Cryptographically Generated Addresses are used to assure that the sender of a Neighbor or Router Advertisement is the owner of an the claimed address. A public-private key pair needs to be generated by all nodes before they can claim an address. => this suggests that all addresses should be CGAs. Of course this is only one of the two cases: - certified addresses (always the case for universal or static IID) - CGAs (which always give local IID) - same (comment) o A new transform for IPsec AH allows public keys to be used on a security association directly without the involvement of a key... => I propose to talk about inline signature, look at SKIP documents. - 6. Authorization Delegation Discovery (wording) Since the newly-connected node likely can not communicate off-link, => s/the/a/ ? = same (same) the router; however, given a chain of appropriately signed ... Similarly, the router, which is already connected to the network, can => s/the/a/ ? - same (comment) The Authorization Delegation Discovery process does not exclude other forms of discovering the certificate chains. For instance, during => IMHO this is the right place to introduce interaction with AAA systems. If you'd like to use SEND in 802.11 hot spots, you have to talk about this! - 6.1 Delegation Chain Solicitation Message Format (wording) Identifier This 16 bit unsigned integer field acts as an identifier to help match advertisements to solicitations. The Identifier => either "help to match" or "help matching" ? - 6.3 Trusted Root Option (comment) => you don't support two root certificates for the same root... I propose to add a name type where one can put a hash of the certificate. For the hash itself the objectDigest seems perfect. - 6.4 Certificate Option (clarification) Cert Type The type of the certificate included in the Name field. This specification defines only one legal value for this field: 1 X.509 Certificate => s/X.509/X.509v3/ - same (wording) Pad Length The amount of padding beyond the end of the Certificate field but within the length specified by the Length field. Padding MUST be set to zero by senders and ignored by receivers. => broken... I propose something like: Pad Length The number of padding octets beyond the end of the Certificate field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers. - same (clarification) Certificate When the Cert Type field is set to 1, the Certificate field contains an X.509 certificate [16]. => s/X.509/X.509v3/ BTW I don't understand why we should not put PKIX certificates? IKEv2 does this, and it can make interoperability between implementations less problematic. - 6.5 Router Authorization Certificate Format (comment) MUST consist of standard Public Key Certificates (PKC, in the sense of [11]) for identity from the trusted root shared with the host to => [11] (PKIX) doesn't use this term... IMHO the right reference is [12] and the introduction text of [12] about PKC and AC should be copied! - 6.5.1 Field Values (comment) => please reorder (acinfo.holder together, etc) - same (comment) acinfo.attributes This field MUST contain a list of prefixes that the router is authorized to route => I disagree: a router is not authorized to route a prefix, it is authorized to advertise/annonce a prefix. About routing perhaps it should be useful to authorize (or not) a router to be a default router? - same (comment) If the router is authorized only to route specific prefixes, the ipAddress values consist of IPv6 addresses in standard RFC 3513 [13] prefix format. => my problem is that ipAddress can't encode prefix in RFC 3513 format (i.e., ipAddress can get a mask but not

/). Please clarify, for instance with an example. RFC 3280 one is: For example, a name constraint for "class C" subnet 10.9.8.0 is represented as the octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 10.9.8.0/255.255.255.0. - 6.6 Processing Rules for Routers (comment) their trusted root. When such advertisements are sent, their timing MUST follow the rules given for Router Advertisements in RFC 2461 [6]. The only defined option that may appear is the Certificate option. At least one such option MUST be present. Router SHOULD also include at least one Trusted Root option to indicate the trusted root on which the Certificate is based. => the wording is too loose about what to do if the chain doesn't fit inside one advertisement message: - fragment DCA in place of distributing certs in DCAs (of course the second is better) - back to back DCAs for long chains etc. - 6.7 Processing Rules for Hosts (comment) o IP Source Address is a unicast address. Note that routers may use multiple addresses, so this address not sufficient for the unique identification of routers. => RA sources are always link-local for this reason. Should we enforce routers to use only link-local source for DCAs? - same (same) attachments to the network. In order to use an advertisement for the verification of a specific Neighbor Discovery message, the host matches the key hash in acinfo.Holder.objectDigestInfo to the public key carried in the IPsec AH Authentication Data field. => so we have a good ID for public keys! - same (same) A host MUST send Delegation Chain Solicitations either to the All-Routers multicast address, if it has not selected a default router yet, or to the default router's IP address if it has already been selected. => note that this address is always a link-local (but not fe80:: if we don't want to make some implementers kill themselves :-). - same (wording) When processing a possible advertisement sent as a response to a => When processing possible advertisements sent as responses to a - 7.1 The AH_RSA_Sig Transform (wording) IPsec DOI [4] Transform ID TBD , however. => s/TBD// - 7.1.1 Reserved SPI Number (same) The AH_RSA_Sig MUST be only be used with the reserved SPI number TBD . => s/TBD// - 7.1.2 Authentication Data Format (same) chosen transform. For the AH_RSA_Sig transform, the format is as follows: ^^^^^ => missing word? (at least poor wording) - 7.1.3 AH_RSA_Sig Security Associations (wording) CGA flag A flag that indicates whether or not the CGA property must be verified. => IMHO the "whether or not" wording should be improved, for instance: CGA flag A flag that indicates whether the CGA property must be or not be verified. (many occurrences) - 7.1.4 Replay Protection (comments) The format is 64 bits, and the contents are the number of milliseconds since January 1, 1970 00:00 UTC. => the millisecond unit is too small for data but not for ND. Perhaps we should add a rationale saying it is not a problem to have no support for more than one ND message per ms. If anti-replay has been enabled, receivers MUST be configured with an allowed Delta value and maintain a cache of messages received within this time period from each specific source address. => is it really important to support not-in-order messages? Reordering link-layers are not so frequent, and we talk about ND... Recommended default value for the allowed Delta is 3,600 seconds. => this is far too large, especially for a single mechanism. o A packet that passes both of the above tests MUST be registered in the cache for the given source address. => it is too soon to register it in the cache: the packet should pass the AH signature check too. o If the cache becomes full, the receiver SHOULD temporarily reduce the Delta value for that source address so that all messages within that value can still be stored. => this doesn't solve the problem but opens doors to DoS... I propose for not reordering link-layers (the reordering case can be supported with small modifs but this should be clearer): - a per-peer (using the source address of received messages as the index) cache entry with: * last received time stamp (TSlast) * date of reception of last message (RDlast) - when a message is received from a new peer (i.e., a new source), the packet is accepted if the timestamp is in the range: - Max_delta < RDnew - TSnew < + Max_delta An entry is created when the signature check passes. - when a message is received from a known peer, the time stamp (TSnew) is checked against the last valid message: TSlast + (RDnew - RDlast) x (1 - allowed_drift) < TSnew and TSnew < TSlast + (RDnew - RDlast) x (1 + allowed_drif) - parameters are max_Delta and allowed_drift (10% ?) For reordering link-layer (i.e., complete rules) we need: - max_link_layer_delay in the last rules - retain only the valid message with the higher timestamp. - 7.1.5 Processing Rules for Senders (comment) o Additionally, if the use of CGA has been specified for the security association, the source address of the packet MUST be constructed as specified in [27]. => move this up: AH construction needs to know addresses. - 7.1.6 Processing Rules for Receivers (comment) Packets that do not pass all the above tests MUST be silently discarded. => this is the place where to update the timestamp cache. Note that "silently discarded" should imply "doesn't update the cache"... - 7.2.1 Destination Agnostic Security Associations (comment) Security associations that use the SPI value specified in Section 7.1.1 MUST be identified solely by the SPI and protocol numbers, not by the destination IP address. => RFc 2401bis removed the protocol number (50 ou 51) too with a very carefull wording (ask Stephen Kent or grep the archive). - 8.1.1 Sending Secure Neighbor Solicitations (comment) The source address of the message MUST NOT be the unspecified address. A Neighbor Solicitation sent as a part of Duplicate Address Detection MUST use as a source address the tentative address for which the Duplicate Address Detection is being run. => NO: NS used in DAD are recognized because they are sent from the unspecified source. You are specifying a new DAD protocol... - same (same) When an interface is initialized, a node MUST join securely-solicited-node multicast address corresponding to each of the IP addresses assigned to the interface. => we need to specify more: what source address for MLD joins for instance... - 8.3 Other Requirements (comment) Hosts that use stateless address autoconfiguration MUST generate a new CGA as specified in Section 4 of [27] for each new autoconfiguration run. => I disagree: nodes should have the choice between using a certified IID or a CGA based IID. My main name-server is a host and I don't want to use CGA for it for many reasons. Of course, I use stateless autoconfig even I've switched from EID64 IID to ::1 IID some months ago. It is outside the scope of this specification to describe the use of trusted root authorization between hosts with dynamically changing addresses. Such dynamically changing addresses may be the result of stateful or stateless address autoconfiguration or through the use of RFC 3041 [9]. If the CGA method is not used, hosts would be required to exchange certificate chains that terminate in a certificate authorizing a host to use an IP address having a particular interface identifier. This specification does not specify the format of such certificates, since there are currently a few cases where such certificates are required by the link layer and it is up to the link layer to provide certification for the interface identifier. This may be the subject of a future specification. => this is not sound with the MUST of the previous paragraph. And not with all the CGA=yes/no in next sections... Please fix this and don't forget that mandatory encumbered technologies like CGA won't pass last calls (so don't make them mandatory). - 9.2.1 Sending Secure Router Advertisements (comment) The source address of the message MUST NOT be the unspecified address. => change to in "MUST be a link-local address". - 9.2.2 Receiving Secure Router Advertisements (same) If source address of the Router Advertisement message is the unspecified address, the message MUST be silently discarded. => same: "is not a link-local address". - 9.3.1 Sending Redirects (same) The source address of the Redirect message MUST NOT be the unspecified address. => same... - 9.3.2 Receiving Redirects (same) If source address of the Redirect message is the unspecified address, the message MUST be silently discarded. => same. BTW IMHO the link-local address requirement should be integrated into the 2. - 10. Co-Existence of SEND and ND (comment) => another solution is to make the legacy ND prefixes off-link. The wording should clarify it is not the case. - 10.1 Behavior Rules (wording) o Nodes configured for SEND MUST listen to the solicited-node multicast address in addition to the securely-solicited-node multicast address. The messages received on the solicited-node multicast address are unprotected, but the SEND node MUST respond to them as follows. ^^^ s/the/a/ Upon seeing a Neighbor Solicitation for an address which is currently assigned to its own interface, the SEND node sends as a ^^^ s/the/a response a Neighbor Solicitation with the following contents: - same (comment) => the standard response to a DAD NS probe is a NA, can you explain the change? - same (spelling) o Hosts configured for SEND MUST use SEND for all of their addresses, including link local addresses. => link-local - same (comment) Secure Router and Neighbor Advertisements MUST use a source address that satisfies the security properties outlined in Section => don't forget that RAs are sent from a link-local address. - same (wording) the other prefixes are on-link. Thus, these hosts will request the ^^^ a router to route packets destined to a host in the other group. The rules regarding Redirect messages above have been provided to ensure that the router performs its routing task and does not instruct the ^^^ a ^^^ hosts to communicate directly. - 11. Performance Considerations (comment) Given that the IPv6 header is covered by the AH integrity protection, it is typically not possible to precompute solicited advertisements. => IMHO anti-replay stuff is enough to make precomputation impossible (:-). - 13.1 Threats to the Local Link Not Covered by SEND (comment) To protect against such attacks, link layer security MUST be used. An example of such for 802 type networks is port-based access control [34]. => can you explain how 802.1X or any link-layer security can help here? I claim that you have no way in the layer 2 or 3 themselves to protect the layer 2 - layer 3 address binding! The only thing that SEND gives is the attacker must be a node one trusts. - same (wording) Solicited Node Multicast Group for the address that they are claiming RFC 2461 [6]. => missing word(s) between the two lines? - 13.2.5 Replay Attacks (comment/wording) Since most SEND nodes are likely to use fairly coarse grained timestamps, as explained in Section 7.1.4, this may affect some nodes. => a millisecond is not so coarse grained. IMHO the statement is more about the fairly large one hour delta... - 13.3 Attacks against SEND Itself (comment) Security associations based on the use of asymmetric cryptography can be vulnerable to Denial-of-Service attacks, particularly when the attacker can guess the SPIs and destination addresses used in the security associations. In SEND this is easy, as both the SPIs and => please avoid the page break here. - same (wording) The Authorization Delegation Discovery process may also be vulnerable to Denial-of-Service attacks. An attack may target a router by request a large number of delegation chains to be discovered for => s/request/requesting/ or s//requiring/ ? - 14. IANA Considerations (wording) This document defines two new Neighbor Discovery [6] options, which => s/two/three/ - Normative References (update) [1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. => RFC 3513, April 2003. - same (presentation) [18] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, . => Standard", FIPS PUB 180-1, April 1995, . - Informative References (update) [26] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-04 (work in progress), March 2003. => -05, April 2003 Thanks Francis.Dupont@enst-bretagne.fr PS: I can't find how to verify certified addresses, even for routers. (this is not in 9.2) --------------090009040106090601020902-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 03:06:59 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01507 for ; Tue, 17 Jun 2003 03:06:58 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H75ocv024642; Tue, 17 Jun 2003 09:05:50 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLHSLX; Tue, 17 Jun 2003 09:04:53 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5H74tsY019986; Tue, 17 Jun 2003 09:04:55 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H74bme012945; Tue, 17 Jun 2003 09:04:37 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5H74b9P012944; Tue, 17 Jun 2003 09:04:37 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H74ame012940 for ; Tue, 17 Jun 2003 09:04:36 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 5A45F1C; Tue, 17 Jun 2003 10:14:24 +0300 (EEST) Message-ID: <3EEEBDC1.9040102@nomadiclab.com> Date: Tue, 17 Jun 2003 10:05:37 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: SEND WG Subject: Re: Some architectural thoughts about AH in SEND References: <3EEC8BD5.5040500@nomadiclab.com> <028601c33456$d63d28b0$cc6ffea9@DCLKEMPFTP> In-Reply-To: <028601c33456$d63d28b0$cc6ffea9@DCLKEMPFTP> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit James Kempf wrote: > I like the idea of using a separate CGA header, though we need to make > sure it works well on Linux. I particularly like the idea of having > two SPIs, one for CGA and another for trusted roots. They always > struck me as being separate. However, I have a comment: > ... > > I think the sequence goes something like this: > > - node receives a NS containing an AH header with an unverified IP > address. Right. However, if we use the source address based SA selection, already the SPD code will notice that there is no SA for the particular pair. The SPD code will kick the issue up to the user level via PF_KEY. > - In the IPsec code, call out to obtain the certificates. > . Certificate chain found? Return it. > . No certificate chain found? Use DCS/DCA to find and return. This can be done all at the user level, as a result to the PF_KEY ACQUIRE generated by the SPD code in the kernel. The user level code can process the certificates, and once it finds or is is able to acquire a proper chain, it installs the new SA with PF_KEY ADD. > - Create IPsec SA based on destination address > (note we can't use the source address here because the SA can > have a different chain depending on the chain returned). Hmm. Why can't we use the source address? That particular SA is only at the receiving end, i.e. the SA *instance* is a local issue. > - Process AH header using SA. Yes. > - Process ND payload if AH verifies packet. There is slightly complication here. The ND code must also be aware about the prefixes that the particular node is permitted to announce. Fortunately we can use the now-verified source address as an index, and either query for the permissions from the user level, or have them cached in the kernel, as a side result of the previously performed SA creation. > I believe the second step is unavoidable for any IPsec SPI that uses > public key and certificates, and is not specific to SEND, but how the > certificates are retrieved if they are not available will differ. In > this case, it is the DCS/DCA, so the SPI becomes specific to SEND. Agreed. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 03:26:53 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01802 for ; Tue, 17 Jun 2003 03:26:52 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H7P6G5017544; Tue, 17 Jun 2003 09:25:06 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLHWS5; Tue, 17 Jun 2003 09:25:00 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5H7P1sY020268; Tue, 17 Jun 2003 09:25:01 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H7Ogme015112; Tue, 17 Jun 2003 09:24:42 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5H7Og4Z015111; Tue, 17 Jun 2003 09:24:42 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H7Ofme015107 for ; Tue, 17 Jun 2003 09:24:41 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 5D9991C; Tue, 17 Jun 2003 10:34:29 +0300 (EEST) Message-ID: <3EEEC276.9080708@nomadiclab.com> Date: Tue, 17 Jun 2003 10:25:42 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: SEND WG Subject: Re: Should CGA parameters be a separate header instead ... References: <748C6D0A58C0F94CA63C198B6674697A0141BAD9@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BAD9@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > Perhaps we don't need a "CGA extension header", couldn't > > > we just use a DST options header which can be located > > > before IPsec headers? > > > > Well, technically it could, but I doubt the benefit from that. > > Firstly, the total size of the packet would be slightly larger. > > => Not sure I got that. The only difference is the value > of the 'type' field right? Let's see. I'm assuming now a full KMP-like CGA, with the ability to create a short lived AH SA. Separate extension header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | RES | PAD |CC | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Modifier | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Public key . . (variable length) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination option: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | |CC | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Modifier | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Public key . . (variable length) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ No big difference in actual length (4 bytes). However, the option data length is limited to 255 bytes, limiting the maximum size of the public key to approximately 227 bytes, meaning that the maximum RSA key size would be about 1760 bits. Thus, I think that the limitation on the maximum key size warrants alone a separate extension header. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 03:42:23 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02072 for ; Tue, 17 Jun 2003 03:42:23 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H7efG5020002; Tue, 17 Jun 2003 09:40:41 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8R4G8; Tue, 17 Jun 2003 09:41:00 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5H7edsY020472; Tue, 17 Jun 2003 09:40:39 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H7eMme017061; Tue, 17 Jun 2003 09:40:22 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5H7eMcl017060; Tue, 17 Jun 2003 09:40:22 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H7eLme017056 for ; Tue, 17 Jun 2003 09:40:21 +0200 (MET DST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5H7e5Q8014870; Tue, 17 Jun 2003 10:40:05 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) id h5H7e5uu014866; Tue, 17 Jun 2003 10:40:05 +0300 Date: Tue, 17 Jun 2003 10:40:05 +0300 Message-Id: <200306170740.h5H7e5uu014866@burp.tkv.asdf.org> From: Markku Savela To: pekka.nikander@nomadiclab.com CC: kempf@docomolabs-usa.com, ietf-send@standards.ericsson.net In-reply-to: <3EEEBDC1.9040102@nomadiclab.com> (message from Pekka Nikander on Tue, 17 Jun 2003 10:05:37 +0300) Subject: Re: Some architectural thoughts about AH in SEND References: <3EEC8BD5.5040500@nomadiclab.com> <028601c33456$d63d28b0$cc6ffea9@DCLKEMPFTP> <3EEEBDC1.9040102@nomadiclab.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk > From: Pekka Nikander > > > > I think the sequence goes something like this: > > > > - node receives a NS containing an AH header with an unverified IP > > address. > > Right. However, if we use the source address based SA selection, > already the SPD code will notice that there is no SA for the > particular pair. The SPD code will > kick the issue up to the user level via PF_KEY. Umm.. this is not exactly the way I thought IPSEC works. If incoming packet requires an SA that does not exist, packet is dropped like a hot potato. No PFKEY negotiation! I think there would be a DOS potential, if any incoming random SPI would cause negotiation attempt! [Although, I may be wrong too, but that's the way the IPSEC version I know, works] Only outgoing traffic can initiate key / SA negotiation. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 04:00:56 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02762 for ; Tue, 17 Jun 2003 04:00:55 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H80Acv032753; Tue, 17 Jun 2003 10:00:10 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLH9C6; Tue, 17 Jun 2003 09:59:13 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5H7xIN04181; Tue, 17 Jun 2003 09:59:18 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H7x5me019142; Tue, 17 Jun 2003 09:59:05 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5H7x4TJ019141; Tue, 17 Jun 2003 09:59:04 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5H7x4me019137 for ; Tue, 17 Jun 2003 09:59:04 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id CB8261C; Tue, 17 Jun 2003 11:08:51 +0300 (EEST) Message-ID: <3EEECA85.2050005@nomadiclab.com> Date: Tue, 17 Jun 2003 11:00:05 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markku Savela Cc: kempf@docomolabs-usa.com, ietf-send@standards.ericsson.net Subject: Re: Some architectural thoughts about AH in SEND References: <3EEC8BD5.5040500@nomadiclab.com> <028601c33456$d63d28b0$cc6ffea9@DCLKEMPFTP> <3EEEBDC1.9040102@nomadiclab.com> <200306170740.h5H7e5uu014866@burp.tkv.asdf.org> In-Reply-To: <200306170740.h5H7e5uu014866@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Markku Savela wrote: >>> - node receives a NS containing an AH header with an unverified IP >>> address. >> >> Right. However, if we use the source address based SA selection, >> already the SPD code will notice that there is no SA for the >> particular pair. The SPD code will >> kick the issue up to the user level via PF_KEY. > > Umm.. this is not exactly the way I thought IPSEC works. If incoming > packet requires an SA that does not exist, packet is dropped like a > hot potato. No PFKEY negotiation! I think there would be a DOS > potential, if any incoming random SPI would cause negotiation attempt! > [Although, I may be wrong too, but that's the way the IPSEC version I > know, works] > > Only outgoing traffic can initiate key / SA negotiation. Oops. Mea culpa. You are right, of course. However, the change to call PF_KEY would be trivial, at least in KAME. I have to think about the DoS aspects. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 08:05:35 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08877 for ; Tue, 17 Jun 2003 08:05:34 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HBwOw2007856; Tue, 17 Jun 2003 13:58:24 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQDNX3; Tue, 17 Jun 2003 13:59:51 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5HBwNN13528; Tue, 17 Jun 2003 13:58:23 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HBvhme020027; Tue, 17 Jun 2003 13:57:43 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5HBvhrt020026; Tue, 17 Jun 2003 13:57:43 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HBvfme020022 for ; Tue, 17 Jun 2003 13:57:42 +0200 (MET DST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08526; Tue, 17 Jun 2003 07:57:40 -0400 (EDT) Message-Id: <200306171157.HAA08526@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-send@standards.ericsson.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-send-cga-00.txt Date: Tue, 17 Jun 2003 07:57:40 -0400 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : Cryptographically Generated Addresses (CGA) Author(s) : T. Aura Filename : draft-ietf-send-cga-00.txt Pages : 16 Date : 2003-6-16 This document describes a method for binding a public signature key to an IPv6 address in Secure Neighbor Discovery (SEND). Cryptographically Generated Addresses (CGA) are IPv6 addresses where the interface identifier is generated by computing a cryptographic one-way hash function from the address owner's public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. SEND protocol messages are protected with an Authentication Header (AH) that contains the public key and the auxiliary parameters and is signed with the corresponding private key. The protection works without a certification authority or other security infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-send-cga-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-send-cga-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-send-cga-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-send-cga-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-send-cga-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075505.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 12:09:35 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24838 for ; Tue, 17 Jun 2003 12:09:34 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HG78w2017927; Tue, 17 Jun 2003 18:07:08 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYG2HGWN; Tue, 17 Jun 2003 18:08:57 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5HG76sY001873; Tue, 17 Jun 2003 18:07:06 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HG6ame022499; Tue, 17 Jun 2003 18:06:36 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5HG6a6b022498; Tue, 17 Jun 2003 18:06:36 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HG6Yme022484 for ; Tue, 17 Jun 2003 18:06:35 +0200 (MET DST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5HG6M4Z009255; Tue, 17 Jun 2003 09:06:22 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5HG6LtK011353; Tue, 17 Jun 2003 12:06:21 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h5HG6Lq3001144; Tue, 17 Jun 2003 12:06:21 -0400 (EDT) Message-Id: <200306171606.h5HG6Lq3001144@thunk.east.sun.com> From: Bill Sommerfeld To: Pekka Nikander cc: Markku Savela , kempf@docomolabs-usa.com, ietf-send@standards.ericsson.net Subject: Re: Some architectural thoughts about AH in SEND In-Reply-To: Your message of "Tue, 17 Jun 2003 11:00:05 +0300." <3EEECA85.2050005@nomadiclab.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 17 Jun 2003 12:06:21 -0400 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk > Oops. Mea culpa. You are right, of course. However, the > change to call PF_KEY would be trivial, at least in KAME. > I have to think about the DoS aspects. similar things are needed under some schemes for detecting lost IPsec state. Rate limiting (on both ends of the PF_KEY channel) would be a large part of any DoS solution. - Bill -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 12:41:17 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25876 for ; Tue, 17 Jun 2003 12:41:16 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HGdTw2020598; Tue, 17 Jun 2003 18:39:29 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQFMDK; Tue, 17 Jun 2003 18:40:56 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5HGdRsY002490; Tue, 17 Jun 2003 18:39:27 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HGd9me026279; Tue, 17 Jun 2003 18:39:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5HGd9Ib026278; Tue, 17 Jun 2003 18:39:09 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HGd7me026274 for ; Tue, 17 Jun 2003 18:39:08 +0200 (MET DST) Message-ID: <001501c334ee$c44ac0c0$7d6015ac@DCLKEMPFTP> From: "James Kempf" To: Subject: Agenda for IETF 57 Date: Tue, 17 Jun 2003 09:37:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Here's the proposed agenda for IETF 57 in Vienna: - Introduction and Agenda Bashing (5 min.) Chairs - Draft Status (5 min.) Chairs draft-ietf-send-psreq-03.txt draft-ietf-send-ipsec-01.txt draft-ietf-send-cga-00.txt - Implementation Report (5 min.) Pekka and James - IPR discussion (10 min) all, with chairs moderating - IPsec, IPsec w. CGA Header, or ND options? (30 min.) - IPsec w. CGA header (3 min) Pekka - ND options (3 min) Jari - technical discussion, all, with James moderating - Summary and Way Forward (5 min). Chairs The bulk of the meeting is devoted to a technical discussion about the current approach and two proposed alternatives. This schedule is not intended to preempt technical discussion on the list, however. We want to continue discussion on the list, and if we get some resolution prior to the meeting, we can forgo the discussion at the meeting. People should also read the draft (WG last call expires this Fri.), so there will be an understanding of the current approach, and post comments to the list. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 12:45:00 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25977 for ; Tue, 17 Jun 2003 12:44:59 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HGhHw2020833; Tue, 17 Jun 2003 18:43:17 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8V528; Tue, 17 Jun 2003 18:43:38 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5HGhGN24721; Tue, 17 Jun 2003 18:43:16 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HGh7me026552; Tue, 17 Jun 2003 18:43:07 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5HGh7Le026551; Tue, 17 Jun 2003 18:43:07 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HGh5me026544 for ; Tue, 17 Jun 2003 18:43:05 +0200 (MET DST) Message-ID: <003301c334ef$500b93f0$7d6015ac@DCLKEMPFTP> From: "James Kempf" To: "Pekka Nikander" Cc: "SEND WG" References: <3EEC8BD5.5040500@nomadiclab.com> <028601c33456$d63d28b0$cc6ffea9@DCLKEMPFTP> <3EEEBDC1.9040102@nomadiclab.com> Subject: Re: Some architectural thoughts about AH in SEND Date: Tue, 17 Jun 2003 09:41:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > Hmm. Why can't we use the source address? That particular SA > is only at the receiving end, i.e. the SA *instance* is a local > issue. > Sounds like we can. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 13:55:44 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28346 for ; Tue, 17 Jun 2003 13:55:44 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HHrvG5001144; Tue, 17 Jun 2003 19:53:57 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYG2HSSB; Tue, 17 Jun 2003 19:55:46 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5HHrusY003594; Tue, 17 Jun 2003 19:53:56 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HHrWme006040; Tue, 17 Jun 2003 19:53:32 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5HHrWjg006039; Tue, 17 Jun 2003 19:53:32 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from web41802.mail.yahoo.com (web41802.mail.yahoo.com [66.218.93.136]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5HHrTme006033 for ; Tue, 17 Jun 2003 19:53:30 +0200 (MET DST) Message-ID: <20030617175328.15662.qmail@web41802.mail.yahoo.com> Received: from [206.149.149.6] by web41802.mail.yahoo.com via HTTP; Tue, 17 Jun 2003 10:53:28 PDT Date: Tue, 17 Jun 2003 10:53:28 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003 - Final Call for Participation To: ietf-send@standards.ericsson.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1411312714-1055872408=:14209" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --0-1411312714-1055872408=:14209 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 =================================================================== http://www.caitr.org/internetworking03/index.htm =================================================================== You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials. Registration for the conference is underway - online registration is available. To register, go to: http://www.caitr.org/internetworking03/registration.htm Program: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details) Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - Domain Constrained Multicast: A New Approach for IP Multicast Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - An Analysis of Hand-off methods in some WAN and LAN networks Tuesday June 24 Session: Routing Performance - Optimizing Route Convergence - Active Dynamic Routing - Fluid flow network modeling for hop-by-hop feedback control design and analysis Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - Non-Elementary Routing and Wavelength Assignment under General Wavelength-Switching Constraints - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: Routing Architecture & QoS - QoS Routing in Networks with Non-Deterministic Information - A new routing architecture: Atomised Routing - Traceroute and BGP AS Path Incongruities - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs : - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-1411312714-1055872408=:14209 Content-Type: text/html; charset=us-ascii
     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
===================================================================
    http://www.caitr.org/internetworking03/index.htm
===================================================================
 
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.

Registration for the conference is underway - online registration is available. To register, go to:
 http://www.caitr.org/internetworking03/registration.htm
 
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
 
Sunday June 22
    Tutorial-1: MPLS VPNs
    Tutorial-2: IPv6
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet
 
Monday June 23
    Welcome and Keynote
 
    Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing 
      - Network Processing Building Blocks: Enabling the Routers of the Future
 
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
 
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP
      - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - ! CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS
      - Mobile Authentication and QoS
      - An Analysis of Hand-off methods in some WAN and LAN networks
 
Tuesday June 24
    Session: Routing Performance
      - Optimizing Route Convergence
      - Active Dynamic Routing 
      - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
    Session:  Applications & Services
      - Securing the Web with Next Generation Encryption Technologies
      - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 
      - A novel EAC semantic for the RTSP protocol
      - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session:  Network Management & Planning
      - Pse! udowire OAM: A Mandatory Yet Often Overlooked Feature
      - Non-Elementary Routing and Wavelength Assignment under General Wavelength-Switching Constraints
      - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session:  Routing Architecture & QoS
      - QoS Routing in Networks with Non-Deterministic Information
      - A new routing architecture: Atomised Routing
      - Traceroute and BGP AS Path Incongruities
      - QoS routing for Differentiated Services: simulations and prototype experiments
      - Probabilistic routing for QoS improvement in GPS networks
 
We look forward to seeing you at the Conference.
 
Regards,
 Conference Technical Co-chairs :
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM
 
--0-1411312714-1055872408=:14209-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 13:56:18 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28365 for ; Tue, 17 Jun 2003 13:56:18 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HHrqG5001133; Tue, 17 Jun 2003 19:53:52 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYG2HSRX; Tue, 17 Jun 2003 19:55:41 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5HHrosY003583; Tue, 17 Jun 2003 19:53:50 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HHrFme006016; Tue, 17 Jun 2003 19:53:15 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5HHrFIq006015; Tue, 17 Jun 2003 19:53:15 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from web41801.mail.yahoo.com (web41801.mail.yahoo.com [66.218.93.135]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5HHrDme006011 for ; Tue, 17 Jun 2003 19:53:13 +0200 (MET DST) Message-ID: <20030617175312.37146.qmail@web41801.mail.yahoo.com> Received: from [206.149.149.6] by web41801.mail.yahoo.com via HTTP; Tue, 17 Jun 2003 10:53:12 PDT Date: Tue, 17 Jun 2003 10:53:12 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003 - Final Call for Participation To: ietf-send@standards.ericsson.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1697882800-1055872392=:34907" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --0-1697882800-1055872392=:34907 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 =================================================================== http://www.caitr.org/internetworking03/index.htm =================================================================== You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials. Registration for the conference is underway - online registration is available. To register, go to: http://www.caitr.org/internetworking03/registration.htm Program: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details) Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - Domain Constrained Multicast: A New Approach for IP Multicast Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - An Analysis of Hand-off methods in some WAN and LAN networks Tuesday June 24 Session: Routing Performance - Optimizing Route Convergence - Active Dynamic Routing - Fluid flow network modeling for hop-by-hop feedback control design and analysis Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - Non-Elementary Routing and Wavelength Assignment under General Wavelength-Switching Constraints - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: Routing Architecture & QoS - QoS Routing in Networks with Non-Deterministic Information - A new routing architecture: Atomised Routing - Traceroute and BGP AS Path Incongruities - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs : - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-1697882800-1055872392=:34907 Content-Type: text/html; charset=us-ascii
     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
===================================================================
    http://www.caitr.org/internetworking03/index.htm
===================================================================
 
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.

Registration for the conference is underway - online registration is available. To register, go to:
 http://www.caitr.org/internetworking03/registration.htm
 
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
 
Sunday June 22
    Tutorial-1: MPLS VPNs
    Tutorial-2: IPv6
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet
 
Monday June 23
    Welcome and Keynote
 
    Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing 
      - Network Processing Building Blocks: Enabling the Routers of the Future
 
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
 
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP
      - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - ! CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS
      - Mobile Authentication and QoS
      - An Analysis of Hand-off methods in some WAN and LAN networks
 
Tuesday June 24
    Session: Routing Performance
      - Optimizing Route Convergence
      - Active Dynamic Routing 
      - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
    Session:  Applications & Services
      - Securing the Web with Next Generation Encryption Technologies
      - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 
      - A novel EAC semantic for the RTSP protocol
      - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session:  Network Management & Planning
      - Pse! udowire OAM: A Mandatory Yet Often Overlooked Feature
      - Non-Elementary Routing and Wavelength Assignment under General Wavelength-Switching Constraints
      - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session:  Routing Architecture & QoS
      - QoS Routing in Networks with Non-Deterministic Information
      - A new routing architecture: Atomised Routing
      - Traceroute and BGP AS Path Incongruities
      - QoS routing for Differentiated Services: simulations and prototype experiments
      - Probabilistic routing for QoS improvement in GPS networks
 
We look forward to seeing you at the Conference.
 
Regards,
 Conference Technical Co-chairs :
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM
 
--0-1697882800-1055872392=:34907-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 14:10:45 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29304 for ; Tue, 17 Jun 2003 14:10:44 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HI9gcv020372; Tue, 17 Jun 2003 20:09:42 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLL67J; Tue, 17 Jun 2003 20:08:45 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5HI8oN27089; Tue, 17 Jun 2003 20:08:50 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HI8Zme007996; Tue, 17 Jun 2003 20:08:35 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5HI8ZTf007994; Tue, 17 Jun 2003 20:08:35 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HI8Xme007983 for ; Tue, 17 Jun 2003 20:08:33 +0200 (MET DST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5HI6YD9012535; Tue, 17 Jun 2003 14:06:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3EED762C.5060306@nomadiclab.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> Date: Tue, 17 Jun 2003 13:59:00 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: AHbis WG LC: need for source address based selectors Cc: ipsec@lists.tislabs.com, Barbara Fraser , tytso@mit.edu, SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk At 10:47 AM +0300 6/16/03, Pekka Nikander wrote: >One more comment to the AHbis WG LC: > >AHbis currently states the following: > >>2.4 Security Parameters Index (SPI) >> >>The SPI is an arbitrary 32-bit value that is used by a receiver to >>identify the SA to which an incoming packet is bound. For a unicast >>SA, the SPI can be used by itself to specify an SA, or it may be >>used >>in conjunction with the IPsec protocol type (in this case AH). >>Since, for unicast SAs, the SPI value is generated by the receiver, >>whether the value is sufficient to identify an SA by itself, or >>whether it must be used in conjunction with the IPsec protocol >>value is a local matter. The SPI field is mandatory and this >>mechanism for >>mapping inbound traffic to unicast SAs described above MUST be >>supported by all AH implementations. > >However, in the SEND WG we are using AH with public key crypto, >with a fixed SPI. There the key used depends on the sender of >the message, not the receiver. Hence, for our purposes neither >the SPI alone nor SPI + protocol are enough. We need also the ability >to select the SA based on SPI + source address, even for unicast. > > >>If an IPsec implementation supports multicast, then it MUST support >>multicast SAs using the following algorithm for mapping inbound >>IPsec >>datagrams to SAs. ... Each entry in the Security Association >>Database (SAD) [KA98a] must indicate whether the SA lookup makes use >>of the source and destination IP addresses, in addition to the SPI. >>... (There is no current requirement to support SA mapping based on >>the source address but not the destination address, thus one of the >>possible four values is not meaningful.) .... > >Since we are using PK crypto, we also need the possibility for >selecting the SA based solely on the source address. In fact, >for our fixed SPI, the destination address does not have any role, >not even whether the destination address is unicast or multicast. > >I don't know how to handle this so late in the process. I would >like to see the text to be sufficiently revised to allow source >address based SA selection, so that we could use it directly in SEND. >However, I have no idea how the IPSEC WG would feel about that. > >--Pekka Nikander > SEND WG co-chair It sounds like SEND would like to use the AH format, but has a processing model that is not aligned with the way IPsec uses SAs in general. We had extensive discussion in this WG about demuxing for inbound IPsec traffic after the MSEC folks expressed concern about the current process last fall. The demuxing spec has been very stable for several YEARS; we tweaked it very slightly for MSEC, after considerable debate and analysis, to accommodate SSM. Your proposed change represents yet another bit of complexity for an IPsec implementation and I question whether the WG ought to agree to such a change at this late date. Steve -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 19:00:29 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15596 for ; Tue, 17 Jun 2003 19:00:28 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HMwZcv032446; Wed, 18 Jun 2003 00:58:35 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8XB6H; Wed, 18 Jun 2003 00:58:06 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5HMvgsY008422; Wed, 18 Jun 2003 00:57:42 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HMvAme014543; Wed, 18 Jun 2003 00:57:10 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5HMvAJJ014542; Wed, 18 Jun 2003 00:57:10 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [195.20.116.97]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HMv1me014526 for ; Wed, 18 Jun 2003 00:57:02 +0200 (MET DST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.13) with SMTP id h5HMv1NX015280 for ; Wed, 18 Jun 2003 01:57:01 +0300 (EEST) Received: (qmail 12600 invoked from network); 17 Jun 2003 22:57:01 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 17 Jun 2003 22:57:01 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.6/8.11.0) id h5HMuxK16204; Wed, 18 Jun 2003 01:56:59 +0300 (EEST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> Date: Wed, 18 Jun 2003 01:55:39 +0300 From: Tero Kivinen To: Stephen Kent Cc: Pekka Nikander , ipsec@lists.tislabs.com, Barbara Fraser , tytso@mit.edu, SEND WG Subject: Re: AHbis WG LC: need for source address based selectors In-Reply-To: References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 11 min Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Kent writes: > >I don't know how to handle this so late in the process. I would > >like to see the text to be sufficiently revised to allow source > >address based SA selection, so that we could use it directly in SEND. > >However, I have no idea how the IPSEC WG would feel about that. ... > considerable debate and analysis, to accommodate SSM. Your proposed > change represents yet another bit of complexity for an IPsec > implementation and I question whether the WG ought to agree to such a > change at this late date. If I undestand correctly Pekka is asking that the document does not say you MUST NOT allow source address based SA selection (I do not thing it currently says so). I assume that if it does not say anything that this is forbidden or even better says that implementation MAY support SA selection based on the SPI and source address, he will be happy. Even if the document says "MAY" to this thing, it does not require anybody to change anything nor does it make any implementations non-conforming. We are simply allowing implementations to also have this kind of features too. I.e adding something like this to the text: "The SPIs from the reserved range may used different demultiplexing algorithms and use source and/or destination address and/or protocols and/or some other information for the actual demultiplexing. A document describing new reserved SPI number MUST also specify the demultiplexing algorithm used for that specific SPI." -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 19:36:43 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16198 for ; Tue, 17 Jun 2003 19:36:43 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HNZMcv001288; Wed, 18 Jun 2003 01:35:22 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQGTH2; Wed, 18 Jun 2003 01:35:59 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5HNYUN06243; Wed, 18 Jun 2003 01:34:30 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5HNYFme022455; Wed, 18 Jun 2003 01:34:15 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5HNYFpR022454; Wed, 18 Jun 2003 01:34:15 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netscape684.com (5144829e.cable.wanadoo.nl [81.68.130.158] (may be forged)) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5HNYAme022440; Wed, 18 Jun 2003 01:34:12 +0200 (MET DST) Message-Id: <200306172334.h5HNYAme022440@sw.ericsson.se> From: SOPHIE KANGA Reply-To: sophikan12@netscape.net Subject: URGENT ASSISTANCE Date: Wed, 18 Jun 2003 01:34:06 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="662cc51b-0749-4dd6-9c08-bfdc3edb5000" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format --662cc51b-0749-4dd6-9c08-bfdc3edb5000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear friend, You may be surprise to receive this letter from me,since you dont know me personally.I am SOPHIE KANGA,the daughter of STEVEN KANGA Who was recently murdered in the land dispute in Zimbabwe. I am glad to say that with the introduction of internet and website, I was opportuned and pleasured to have come across your contact through this satellite media during my search for a reliable and reputable person to handle a very confidential business which involve a transfer of fund to a foreign account and I decided to write you.My late father was among the few black Zimbabwean opposition party rich farmers murdered by the agents of the ruling Government of president Robert mugabe,for his alleged support and sympathy for the Zimbabwean opposition party controlled by the white minority, Before my father's death,he had taken to johannesburg and deposited the sum of thirty eight million united state dollars (US38,000,000)with a Security and Financial Company,the money right now is in NETHERLAND(EUROPE), as if he forseen the looming danger in zimbabwe. The money was deposited in a box as valuable items to avoid over taxed custom clearance. This money was allocated for the purchase of new machinery and chemical product for Agro-allied farms and for establishment of new farms in lesotho and swaziland.This land problems arose when president Robert mugabe introduced a new land act that wholly affected the rich white farmers and some blacks vehemently condemned the "modus operandi"adopted by the government. This result to rampant killings and mob action by the war veterans and some political thugs,precisely more than three thousand( 3,000) people have so far been killed. Heads of government from thewest, especially Britain and united states have voice their condemnation of Mugabe's plans.Subsequently, south Africa development community(S.A.D.C)has continousy supported mugabe's new land act, it is against this background that my entire family who are currently residing in South Africa have decided to transfer my father's wealth and south Africa's government seems to be playing along with them.I am face with the dilemma of investing this money in south Afica for fear of encountering the same experience in the future, since both countries have almost the same political history.Moreso,the south African = foreign exchange policy does not allow such investment,Hence I am seeking = for(political asylum). AS a business person whom i entrusted my future and that of my family into his hands, i must let you know that this transaction is 100% risk free and the nature of your business does not necessarily matter. For your assistance we are offering you 30% of the sum , 60% for me and my family, while 10% will be mapped out for any expenses that we may incurre during this transaction.We wish to invest our money on commecial properties based on your advice. Finally, I will demand for assurance that you will not abandon us when the money gets to your possession/account in your country, If this proposal is accepted please confirm your interest by sending me mail with the above address or (sophikan78@netscape.net) Thanks, SOPHIE KANGA. --662cc51b-0749-4dd6-9c08-bfdc3edb5000-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 22:18:25 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19464 for ; Tue, 17 Jun 2003 22:18:24 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I2Grcv007290; Wed, 18 Jun 2003 04:16:53 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLNAC0; Wed, 18 Jun 2003 04:15:56 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5I2G1N10176; Wed, 18 Jun 2003 04:16:01 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I2FRme019072; Wed, 18 Jun 2003 04:15:27 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I2FRoJ019069; Wed, 18 Jun 2003 04:15:27 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I2FPme019014 for ; Wed, 18 Jun 2003 04:15:25 +0200 (MET DST) Received: from [12.159.173.182] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5I2DPD9013206; Tue, 17 Jun 2003 22:13:25 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> Date: Tue, 17 Jun 2003 22:12:53 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: AHbis WG LC: need for source address based selectors Cc: Pekka Nikander , ipsec@lists.tislabs.com, Barbara Fraser , tytso@mit.edu, SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk At 1:55 AM +0300 6/18/03, Tero Kivinen wrote: >Stephen Kent writes: >> >I don't know how to handle this so late in the process. I would >> >like to see the text to be sufficiently revised to allow source >> >address based SA selection, so that we could use it directly in SEND. >> >However, I have no idea how the IPSEC WG would feel about that. >... >> considerable debate and analysis, to accommodate SSM. Your proposed >> change represents yet another bit of complexity for an IPsec >> implementation and I question whether the WG ought to agree to such a >> change at this late date. > >If I undestand correctly Pekka is asking that the document does not >say you MUST NOT allow source address based SA selection (I do not >thing it currently says so). I assume that if it does not say anything >that this is forbidden or even better says that implementation MAY >support SA selection based on the SPI and source address, he will be >happy. > >Even if the document says "MAY" to this thing, it does not require >anybody to change anything nor does it make any implementations >non-conforming. We are simply allowing implementations to also have >this kind of features too. > >I.e adding something like this to the text: > >"The SPIs from the reserved range may used different demultiplexing >algorithms and use source and/or destination address and/or protocols >and/or some other information for the actual demultiplexing. A >document describing new reserved SPI number MUST also specify the >demultiplexing algorithm used for that specific SPI." Tero, The primary motivation in the IETF for developing standards is to promote interoperability. What you seem to suggest is a that we not preclude someone from saying that they comply with IPsec, even though they would be following a demuxing policy that is not used in any extant implementations and thus would not be interoperable with any of these implementations. This does not promote interoperability; all it does is allow someone to claim conformance with a standard. That does not seem constructive and, as I noted, it only add to complexity. Am I missing something in your suggestion? Steve -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 17 23:10:50 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20611 for ; Tue, 17 Jun 2003 23:10:50 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I38FG5003193; Wed, 18 Jun 2003 05:08:15 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8XZ21; Wed, 18 Jun 2003 05:08:38 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5I38EN11262; Wed, 18 Jun 2003 05:08:14 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I37ime028864; Wed, 18 Jun 2003 05:07:44 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I37i16028863; Wed, 18 Jun 2003 05:07:44 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I37gme028859 for ; Wed, 18 Jun 2003 05:07:43 +0200 (MET DST) Received: from [12.159.173.182] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5I36cD9014775; Tue, 17 Jun 2003 23:06:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <3EEC2C43.9060302@nomadiclab.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> Date: Tue, 17 Jun 2003 23:05:11 -0400 To: Pekka Nikander , Barbara Fraser From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Cc: ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk At 11:20 AM +0300 6/15/03, Pekka Nikander wrote: >Based on our experiences in the SEND WG, I would like >to offer the following comments to the IPSEC WG, regarding >to the AHbis draft. > >> 1. Introduction >> >> .... >> >> host. ESP may be used to provide the same anti-replay and similar >> integrity services, and it also provides a confidentiality >> (encryption) service. The primary difference between the integrity >> provided by ESP and AH is the extent of the coverage. Specifically, >> ESP does not protect any IP header fields unless those fields are >> encapsulated by ESP (e.g., via use of tunnel mode). ... > >Comments: > > - Even though the text above is true and correct, it may give a wrong > impression. The most important difference is packet size. If ESP > is used, it is necessary to copy all the important information from > the fields that precede ESP into ESP (typically by employing > tunneling), thereby making the packet larger. Additionally, if the > protocols protected by ESP rely on any fields that precede ESP, ESP > processing should check that the fields within the ESP header and > the fields outside of it are equal. This is, by no means, trivial, > since tunnel mode is not always a solution, depending on context. > > Hence, I would suggest adding the following piece of text: > > It should be noticed that some applications (such as IPv6 > Neighbor Discovery or Mobile IPv6) rely on the integrity of some > of the fields in the IP header. Furthermore, using tunnel mode > may not be an option, since the very precense of a tunnel may > open attacks. Finally, the incresed packet size caused by > tunneling may be unacceptable to some applications. The extant text is correct. Until SEND has a comprehensive, coherent model for using AH that does not require changes to other parts of IPsec processing, I think it is appropriate to retain the current text. >-------------- > >> 3.2 Integrity Algorithms >> >> The integrity algorithm employed for the ICV computation is specified >> by the SA. For point-to-point communication, suitable integrity >> algorithms include keyed Message Authentication Codes (MACs) based on >> symmetric encryption algorithms (e.g., AES [AES] or on one-way hash >> functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast >> communication, a variety of cryptographic strategies for providing >> integrity have been developed and research continues in this area. > >Comment: > > - In the current SEND working group proposal, a public key algorithm > is proposed to be used even for point-to-point communication. > However, this probably does not warrant changing the text above. No, it does not. >-------------- > >> 3.4.2 Security Association Lookup >> >> .... >> document.) The SAD entry for the SA also [...] >> indicates the key required to validate the ICV. > >Comment > > - In the current SEND WG proposal, the SA does not indicate the key > to be used. Instead, the AH header itself contains the public > key. However, I don't know if the text above should be changed. > This is not consistent with the IPsec specs! Remember that a protocol such as AH is not just syntax; it also encompasses the rules for processing packets. In IPsec, the SAD entry for an SA stores the keys that are employed to process packets. In turn, the SAD entry is located by using the SPI from an inbound packet (for unicast traffic). If SEND wants to use AH then you need to use the protocol (including the processing spec) as defined in IPsec, not just the syntax from 2402. Suggesting that we change AH to accommodate SEND's possible use of it, in a fashion not consistent with the current specs, is asking quite a lot. Steve -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 01:03:15 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23628 for ; Wed, 18 Jun 2003 01:03:14 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I51QG5009142; Wed, 18 Jun 2003 07:01:26 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8YDND; Wed, 18 Jun 2003 07:01:49 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5I51KsY011744; Wed, 18 Jun 2003 07:01:20 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I50mme015845; Wed, 18 Jun 2003 07:00:48 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I50mHe015832; Wed, 18 Jun 2003 07:00:48 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I50jme015792 for ; Wed, 18 Jun 2003 07:00:46 +0200 (MET DST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5I50eq20158 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 18 Jun 2003 01:00:43 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5I52HV06769; Wed, 18 Jun 2003 01:02:17 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h5I50PUe005589; Wed, 18 Jun 2003 01:00:26 -0400 Message-Id: <200306180500.h5I50PUe005589@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, ietf-send@standards.ericsson.net Subject: Re: AHbis WG LC: need for source address based selectors In-reply-to: Your message of "Tue, 17 Jun 2003 22:12:53 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 18 Jun 2003 01:00:23 -0400 From: Michael Richardson Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I think that we are rushing the 2401bis/ESPbis/AHbis. I agree that there are lots of nice things that people want out there (64-bit replay counters, etc.), but I think that for AH in particular, we should let SEND do its thing first. I see no one waiting for AHbis to go forward. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPu/x5IqHRg3pndX9AQFgmgQAqpNV3b48kQSMF1jKopmmVKxqb63By9th Eh0nCyqIGMES655ipAF+rQiw4kT54RPfZmPQYeolXcYGvXokGjxdLCIMwNRzoirF r0okf1SoDOfMSqr+gdroR4repWc9C4/N4ufi1NoiIoBswLaYZa38emclTXZr2UlO 5BzuIqJFZZY= =d5lG -----END PGP SIGNATURE----- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 02:13:00 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06036 for ; Wed, 18 Jun 2003 02:12:59 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I6B9w2003746; Wed, 18 Jun 2003 08:11:09 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8YN61; Wed, 18 Jun 2003 08:11:32 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5I6B8N15904; Wed, 18 Jun 2003 08:11:08 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6ATme023820; Wed, 18 Jun 2003 08:10:29 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I6ATx2023819; Wed, 18 Jun 2003 08:10:29 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [195.20.116.97]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6AOme023813 for ; Wed, 18 Jun 2003 08:10:24 +0200 (MET DST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.13) with SMTP id h5I6AONX020520 for ; Wed, 18 Jun 2003 09:10:24 +0300 (EEST) Received: (qmail 18770 invoked from network); 18 Jun 2003 06:10:23 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 18 Jun 2003 06:10:23 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.6/8.11.0) id h5I6AMf18512; Wed, 18 Jun 2003 09:10:22 +0300 (EEST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16112.509.854857.215970@ryijy.hel.fi.ssh.com> Date: Wed, 18 Jun 2003 09:09:01 +0300 From: Tero Kivinen To: Stephen Kent Cc: Pekka Nikander , ipsec@lists.tislabs.com, Barbara Fraser , tytso@mit.edu, SEND WG Subject: Re: AHbis WG LC: need for source address based selectors In-Reply-To: References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 13 min Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Kent writes: > >"The SPIs from the reserved range may used different demultiplexing ^ => use > >algorithms and use source and/or destination address and/or protocols > >and/or some other information for the actual demultiplexing. A > >document describing new reserved SPI number MUST also specify the ^ => must > >demultiplexing algorithm used for that specific SPI." ... > promote interoperability. What you seem to suggest is a that we not > preclude someone from saying that they comply with IPsec, even though > they would be following a demuxing policy that is not used in any > extant implementations and thus would not be interoperable with any > of these implementations. I have little problems of parsing what you are saying above, but what I said there does not affect interoperability at all, as it does not change any current implemenation to conforming or non-conforming. If the implementation wants to follow the AHbis then it must implement the demux policy that is MUST in it. This text does not change that. What that text says (or at least tries to say) is that there is future work in progress that might use different demuliplexing policies IN ADDITION to the current ones, and those future documents will define them later. What this means to implementator is that if he feels he might be wanting to comply to those (future) documents later he might want to write implementation so that new demultiplexing policies can also be used. The only MUST (or perhaps it should be "must") in my text was for the future document writers, not to any implementator. For implementators we just give hint that "yes, there is work going on, and you might want to create your architecture so that it can handle those future demultiplexing algorithms". > This does not promote interoperability; > all it does is allow someone to claim conformance with a standard. It will be conforming to the AHbis if and only if it implements the demultiplexing algorithms specified as MUST in the AHbis. This text does not change it. It will be conforming to some other future documents if it implements demultiplexing algorithms specified there. This text will not change that either. Only thing I was (trying) to say in the text was that "be prepared, there is other demultiplexing algorithm(s) coming in the future documents". > That does not seem constructive and, as I noted, it only add to > complexity. Adds complexity to where? I do not thing it changes anything in the implementations unless you plan to implement those future documents, and it will not change any bits in the wire, nor can you remove any of the current demultiplexing algorithm currently mandated by AHbis. > Am I missing something in your suggestion? I think so. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 02:24:12 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14797 for ; Wed, 18 Jun 2003 02:24:11 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I6M6G5017112; Wed, 18 Jun 2003 08:22:06 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLNW7J; Wed, 18 Jun 2003 08:22:01 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5I6M1sY013154; Wed, 18 Jun 2003 08:22:01 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6Lime025462; Wed, 18 Jun 2003 08:21:44 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I6LhYK025461; Wed, 18 Jun 2003 08:21:43 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6Lgme025457 for ; Wed, 18 Jun 2003 08:21:42 +0200 (MET DST) Received: (qmail 17133 invoked from network); 18 Jun 2003 06:21:40 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Jun 2003 06:21:40 -0000 Date: Tue, 17 Jun 2003 23:25:03 -0700 Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: SEND WG , Jari Arkko , Tuomas Aura , James Kempf To: Pekka Nikander From: Jonathan Wood In-Reply-To: <3EEC3A57.1020908@nomadiclab.com> Message-Id: <98A280BA-A155-11D7-97AB-0003930D291E@speakeasy.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, June 15, 2003, at 02:20 AM, Pekka Nikander wrote: > > While implementing the current proposal, we seem to end up > including the CGA information in at least two separate kernel > data structures. I haven't found this to be an implementation issue for me (working on Linux), so from an implementation standpoint I don't really care. However... > > In addition to making the implementation cleaner, the new design > would have another benefit: It would make CGA independent of AH, > making it possible to use it also with e.g. ESP or HIP. I think this is a pretty compelling argument. I support this proposal. j -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 02:31:52 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20561 for ; Wed, 18 Jun 2003 02:31:51 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I6Txw2006280; Wed, 18 Jun 2003 08:29:59 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8YR4M; Wed, 18 Jun 2003 08:30:22 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5I6TwN16843; Wed, 18 Jun 2003 08:29:58 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6Tnme025844; Wed, 18 Jun 2003 08:29:49 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I6Tm2C025843; Wed, 18 Jun 2003 08:29:48 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [195.20.116.97]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6Tlme025839 for ; Wed, 18 Jun 2003 08:29:47 +0200 (MET DST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.13) with SMTP id h5I6TlNX020763 for ; Wed, 18 Jun 2003 09:29:47 +0300 (EEST) Received: (qmail 21042 invoked from network); 18 Jun 2003 06:29:47 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 18 Jun 2003 06:29:47 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.6/8.11.0) id h5I6TjJ18523; Wed, 18 Jun 2003 09:29:45 +0300 (EEST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> Date: Wed, 18 Jun 2003 09:28:25 +0300 From: Tero Kivinen To: Stephen Kent Cc: Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences In-Reply-To: References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 16 min X-Total-Time: 16 min Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Kent writes: > syntax from 2402. Suggesting that we change AH to accommodate SEND's > possible use of it, in a fashion not consistent with the current > specs, is asking quite a lot. The SEND is a user of the AH. Are there any other real users for the AH? In earlier days there was people saying that we should remove the whole AH as nobody uses. Now there seems to be SEND that is using it, but they want to do something differently. Do we want to say to our (only?) user that no we do not allow you to do anything differently? Do we want them to create another protocol replacing their use of AH? Another people who have been saying that they want to use AH is Mobile IP people. What do they want? Is the current spec fine with them or do the want similar processing than SEND? Actually they quite often want to do demultiplexing based on the fields inside the mobility or routing header not the outer IP address. I.e they might need different demultiplexing algorithm too. So the real questions are: Is there any use for the AH as it is now specified? What are application(s) / protocol(s) which will use it? If we cannot answer to those questions I think we should drop the current AH from the IPsec WG and say that SEND/Mobile IP etc can specify it so that it will be suitable for them :-) I do not want any generic text saying "someone might want to use it if the phase of the moon is full and ..., and,... and ... export control ... and ... goverment ... and ...". I do want current real word example (where the current AH as specified in the current document) is actually used or is planned to be used. I do NOT see any use for the AH on the VPNs or road warriors IPsec clients. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 02:34:02 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21114 for ; Wed, 18 Jun 2003 02:34:01 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I6WGG5018528; Wed, 18 Jun 2003 08:32:16 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8YSG9; Wed, 18 Jun 2003 08:32:39 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5I6WEN17027; Wed, 18 Jun 2003 08:32:14 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6W2me028885; Wed, 18 Jun 2003 08:32:02 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I6W1nY028884; Wed, 18 Jun 2003 08:32:01 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6Vxme028868 for ; Wed, 18 Jun 2003 08:32:00 +0200 (MET DST) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KX8VPRZEOM9BYRTR@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Wed, 18 Jun 2003 16:27:23 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7E63212C008; Wed, 18 Jun 2003 16:27:21 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 5E8F812C005; Wed, 18 Jun 2003 16:27:21 +1000 (EST) Date: Wed, 18 Jun 2003 16:27:21 +1000 From: Greg Daley Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH To: Jonathan Wood Cc: Pekka Nikander , SEND WG , Jari Arkko , Tuomas Aura , James Kempf Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EF00649.2030304@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <98A280BA-A155-11D7-97AB-0003930D291E@speakeasy.net> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Johnathan, Jonathan Wood wrote: > > On Sunday, June 15, 2003, at 02:20 AM, Pekka Nikander wrote: > >> >> While implementing the current proposal, we seem to end up >> including the CGA information in at least two separate kernel >> data structures. > > > I haven't found this to be an implementation issue for me (working > on Linux), so from an implementation standpoint I don't really care. > However... Sorry if this sounds dumb, but what do you mean not a problem? Not a problem to implement. or: Not a problem, there's no IPR/GPL clash that I can see. I think that especially in the case of Linux, the second issue is not so clear (or clearly not so good). Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 02:39:56 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21308 for ; Wed, 18 Jun 2003 02:39:55 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I6dFcv021574; Wed, 18 Jun 2003 08:39:15 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYG2JK30; Wed, 18 Jun 2003 08:40:14 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5I6cMN17246; Wed, 18 Jun 2003 08:38:22 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6cFme029195; Wed, 18 Jun 2003 08:38:15 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I6cFTc029194; Wed, 18 Jun 2003 08:38:15 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6cCme029188 for ; Wed, 18 Jun 2003 08:38:13 +0200 (MET DST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 697EE92; Wed, 18 Jun 2003 15:38:08 +0900 (JST) To: Tero Kivinen Cc: Stephen Kent , Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG In-reply-to: kivinen's message of Wed, 18 Jun 2003 09:28:25 +0300. <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences From: itojun@iijlab.net Date: Wed, 18 Jun 2003 15:38:08 +0900 Message-Id: <20030618063808.697EE92@coconut.itojun.org> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk >So the real questions are: >Is there any use for the AH as it is now specified? >What are application(s) / protocol(s) which will use it? i believe there are real use of AH, we have been using AH to protect BGP sessions, and i'm about to write up a draft to use AH for protecting RIPng conversation among routers. even if there's very little use of AH in the community, major change to AH that SEND requires would require another IP protocol #, IMHO. itojun -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 02:49:27 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21696 for ; Wed, 18 Jun 2003 02:49:27 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I6liw2009411; Wed, 18 Jun 2003 08:47:44 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLN8LA; Wed, 18 Jun 2003 08:47:39 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5I6lgsY019383; Wed, 18 Jun 2003 08:47:42 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6lSme000844; Wed, 18 Jun 2003 08:47:28 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I6lScv000843; Wed, 18 Jun 2003 08:47:28 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I6lMme000826 for ; Wed, 18 Jun 2003 08:47:26 +0200 (MET DST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5I6lIq20606 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 18 Jun 2003 02:47:20 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5I6msV12872; Wed, 18 Jun 2003 02:48:55 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h5I6l6h6009703; Wed, 18 Jun 2003 02:47:06 -0400 Message-Id: <200306180647.h5I6l6h6009703@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences In-reply-to: Your message of "Wed, 18 Jun 2003 09:28:25 +0300." <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 18 Jun 2003 02:47:05 -0400 From: Michael Richardson Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk I agree strongly with Tero. I said for years that AH would get used - but certainly not for VPNs. That we didn't know where it would be important, that it would be. SEND is a customer here. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 03:16:44 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22345 for ; Wed, 18 Jun 2003 03:16:43 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I7EMw2013400; Wed, 18 Jun 2003 09:14:22 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQ2G8F; Wed, 18 Jun 2003 09:15:50 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5I7EIsY022956; Wed, 18 Jun 2003 09:14:18 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I7Dlme003711; Wed, 18 Jun 2003 09:13:47 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I7Dll9003710; Wed, 18 Jun 2003 09:13:47 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I7Djme003701 for ; Wed, 18 Jun 2003 09:13:45 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id CEF441C; Wed, 18 Jun 2003 10:23:30 +0300 (EEST) Message-ID: <3EF01165.1040906@nomadiclab.com> Date: Wed, 18 Jun 2003 10:14:45 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Cc: Stephen Kent , ipsec@lists.tislabs.com, SEND WG Subject: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> In-Reply-To: <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Steve and Tero, [Taking my SEND WG chair hat firmly *off*, i.e., speaking for myself only.] Stephen Kent wrote: > Until SEND has a comprehensive, coherent model for using AH that does > not require changes to other parts of IPsec processing, ... With all respect, I sincerely believe that SEND will never come up with "a comprehensive, coherent model for using AH that does not require changes to other parts of IPsec processing". More on that below. If you disagree, please try to come up with a scheme where you use AH when you - don't have any IP addresses (i.e. during IPv6 DAD) - do not know in which network you are (public access) - do not trust most nodes in the network (public access) - and are still trying to figure out what node(s) to trust, how much, and in which respects - do not know which of the potentially many trust roots you should use to establish trust with the possibly existing trusted nodes in the otherwise untrusted network - want to operate, at a lower level of security, when you are unable to establish pre-configured trust with anyone - want to make this all *effectively*, without using zillions of messges, since you potentially have to do this each time you roam to a different IP network I still claim that there are situations where the integrity and data origin authentication of the IP header is important. Hence, I firmly believe that the text concerning the relationship between AH and ESP is misleading at best and perhaps even outright wrong. Using tunnel mode is not an answer, at least sometimes. >> - In the current SEND WG proposal, the SA does not indicate the key >> to be used. Instead, the AH header itself contains the public >> key. .... >> > This is not consistent with the IPsec specs! Actually I more or less agree with you, Steve! Indeed, that is one of the reasons why I am proposing changes to the current AH usage in SEND, basically moving the public key from the AH header to a separate extension header, to be placed before the AH header. (See the separate discussion at the SEND WG ML.) > In IPsec, the SAD entry for an SA stores the keys that are employed > to process packets. In turn, the SAD entry is located by using the > SPI from an inbound packet (for unicast traffic). I am very very well aware of that. I quite well remember what I learned while I implemented one of the early BITS IPsec stacks as a part of my PhD work back in 1994-1995. However, sometimes the SPI alone is not very useful, and sometimes using the destination address as a selector is not the right choice. (More on this on the separate thread.) > If SEND wants to use AH then you need to use the protocol (including > the processing spec) as defined in IPsec, not just the syntax from > 2402. Suggesting that we change AH to accommodate SEND's possible use > of it, in a fashion not consistent with the current specs, is asking > quite a lot. I agree. Actually, using the revised suggestion of moving the public key from the AH header to a separate extension header, thereby creating an "implicit" or "inline" one message KMP, seems to simplify issue. However, even in that case it would really make sense to perform SA selection based on the source address. However, I defer that discussion to the other thread. Tero Kivinen wrote: > The SEND is a user of the AH. ... Do we want to say to our > (only?) user that no we do not allow you to do anything differently? As Itojun pointed out (and Steve well knows), SEND is indeed not the only user of AH. Anyway, thanks for your supporting words. We should also remember that RFC2461/2462 explicitly states that AH is the method to be used for protecting IPv6 ND. That is, in fact, quite doable if you have a static environment with pre-configured security associations, PK based or symmetric. However, once you want to use AH in the public access environment, things get harder. See the outline above. > Do we want them to create another protocol replacing their use of AH? This is the very question. There are lots of folks at the SEND WG who believe so. That is, they believe that AH should not be used for securing IPv6 ND, and a separate protocol should be developed instead. > Another people who have been saying that they want to use AH is > Mobile IP people. What do they want? Is the current spec fine with > them or do the want similar processing than SEND? Having been there too (though recently not very actively), I strongly suspect that some of the MIPv6 requirements will be fairly similar to those of SEND. Both deal with IP address mappings, MIP with IP -> IP mappings and ND with IP -> lladdr mappings. > Is there any use for the AH as it is now specified? > What are application(s) / protocol(s) which will use it? I think Itojun answered to these. > If we cannot answer to those questions I think we should drop the > current AH from the IPsec WG and say that SEND/Mobile IP etc can > specify it so that it will be suitable for them :-) Thanks. See the other thread at saag. > I do NOT see any use for the AH on the VPNs or road > warriors IPsec clients. Here I tend to agree with you, Tero, but that is really beside the point of this discussion, IMHO. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 03:36:18 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22811 for ; Wed, 18 Jun 2003 03:36:17 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I7Ygcv030542; Wed, 18 Jun 2003 09:34:42 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQ2MCD; Wed, 18 Jun 2003 09:35:20 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5I7XnN01791; Wed, 18 Jun 2003 09:33:49 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I7XVme006957; Wed, 18 Jun 2003 09:33:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I7XV84006956; Wed, 18 Jun 2003 09:33:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I7XTme006952 for ; Wed, 18 Jun 2003 09:33:29 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 69B831C; Wed, 18 Jun 2003 10:43:17 +0300 (EEST) Message-ID: <3EF01607.3080900@nomadiclab.com> Date: Wed, 18 Jun 2003 10:34:31 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Cc: ipsec@lists.tislabs.com, SEND WG Subject: Re: AHbis WG LC: need for source address based selectors References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Kent wrote: >> Since we are using PK crypto, we also need the possibility for >> selecting the SA based solely on the source address. In fact, for >> our fixed SPI, the destination address does not have any role, not >> even whether the destination address is unicast or multicast. > It sounds like SEND would like to use the AH format, but has a > processing model that is not aligned with the way IPsec uses SAs in > general. Right now, yes indeed. With the proposed change of moving the public key to a separate extension header, thereby generating a one-message "inline" KMP, not really, IMHO. > We had extensive discussion in this WG about demuxing for inbound > IPsec traffic after the MSEC folks expressed concern about the > current process last fall. The demuxing spec has been very stable for > several YEARS; we tweaked it very slightly for MSEC, after > considerable debate and analysis, to accommodate SSM. I sort of followed that discussion, but not very closely. I can't claim that I would remember all the details. > Your proposed change represents yet another bit of complexity for an > IPsec implementation and I question whether the WG ought to agree to > such a change at this late date. I am sorry of the late date. My only excuse is that SEND has only recently progressed to a level where we are able to comment AHbis. Returning to the real question, I actually claim that the proposed change would simplify a typical implementation. According to the current spec, you may have to handle unicast and multicast addresses differently, and you have to implement the restriction that the "use source address, don't use destination address" is forbidden. Remember, IPv6 ND requires multicast, and hence a conforming implementation MUST implement the multicast demultiplexing algorithm anyway. One way of implementing the current specification is to implement the two nominal bits into the SAD database, and all the code required to check the source address, the destionation address, both, or neither. After that, one would *add* the code to forbid the bit pattern indicating that only the source address check sould be made. From an implementation point of view, these restrictions are additional complexity, and removing them would reduce complexity. But maybe you had some other type of complexity in mind? Actually, the minimum change to AHbis would be to remove the paranthesized sentence "(There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.)" Adding some clarifying text, indicating that if only the source address is used for demultiplexing, then whether the destination address is multicast or unicast does not matter, would be helpful, too. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 03:52:52 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23040 for ; Wed, 18 Jun 2003 03:52:52 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5I7pucv001893; Wed, 18 Jun 2003 09:51:56 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8ZKYK; Wed, 18 Jun 2003 09:51:27 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5I7p3N02472; Wed, 18 Jun 2003 09:51:03 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I7ojme008993; Wed, 18 Jun 2003 09:50:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5I7ojGB008992; Wed, 18 Jun 2003 09:50:45 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5I7oime008988 for ; Wed, 18 Jun 2003 09:50:44 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 347F81C; Wed, 18 Jun 2003 11:00:28 +0300 (EEST) Message-ID: <3EF01A0E.3020908@nomadiclab.com> Date: Wed, 18 Jun 2003 10:51:42 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Cc: Tero Kivinen , ipsec@lists.tislabs.com, SEND WG Subject: Re: AHbis WG LC: need for source address based selectors References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Steve and Tero, Tero wrote: >> If I undestand correctly Pekka is asking that the document does not >> say you MUST NOT allow source address based SA selection (I do not >> thing it currently says so). I assume that if it does not say anything >> that this is forbidden or even better says that implementation MAY >> support SA selection based on the SPI and source address, he will be >> happy. I would be quite happy if the AHbis allowed source address based selectors even implicitly. Right now it has the paranthesized sentense saying that the particular nominal bit pattern is not meaningful, thereby implicitly forbidding selecting SA using only the source address. Tero wrote: >> "The SPIs from the reserved range may used different demultiplexing >> algorithms and use source and/or destination address and/or protocols >> and/or some other information for the actual demultiplexing. A >> document describing new reserved SPI number MUST also specify the >> demultiplexing algorithm used for that specific SPI." I don't even need this much to be said. Just removing the paranthesized sentence would be mostly enough. Let me reiterate here why source address based selection would be useful. Right now SEND carries a public signature key and other parameters in the AH header, and uses only one AH SA which extracts the key from the header, checks the validity of the key either with CGA or against certificates, and verifies the signature. I tend to agree with Steve that this is not really consistent with the IPsec model. Hence, what I have proposed is to move the key and associated data from the AH header to a separate extension header that would precede the AH header in processing order. In this scheme, the extension header creates an AH SA on the fly. (Didn't SKIP do something like this?) If CGA is used, the AH SA is only valid for processing this single packet; if certificates is used, the lifetime of the SA depends on what the certs and what the local policy state. When the AH header is handled, the SA is already there, and AH just does the "usual thing", in this case checks the signature. The problem is really how to find the right SA. Destination address is not the answer, since the scheme must work both with multicast and with unicast. With multicast only you perhaps could use a combination of destination and source addresses, but not with unicast. In many cases you don't have any state associated with the destination node, you are just replying to a multicast message. You can't really allocate a new SPI in the inline KMP, since you have only one message, and the destination selects the SPI values to be used. Consequently, the only reasonable field to use for selecting the right SA would be the source address. Furthermore, that would be the logical choice, since the public key is directly related to the source address anyway. I hope this makes this all clearer. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 10:59:03 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11012 for ; Wed, 18 Jun 2003 10:59:02 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5IEthw2014405; Wed, 18 Jun 2003 16:55:43 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLR4XH; Wed, 18 Jun 2003 16:55:35 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5IEtasY000147; Wed, 18 Jun 2003 16:55:36 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IEsqme004261; Wed, 18 Jun 2003 16:54:52 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5IEsqf1004260; Wed, 18 Jun 2003 16:54:52 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IEsnme004256 for ; Wed, 18 Jun 2003 16:54:50 +0200 (MET DST) Message-ID: <00e001c335a9$4bef1250$4204300a@DCLKEMPFTP> From: "James Kempf" To: "Tero Kivinen" , "Stephen Kent" Cc: "Pekka Nikander" , , "Barbara Fraser" , , "SEND WG" References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> Subject: Re: AHbis WG LC: need for source address based selectors Date: Wed, 18 Jun 2003 07:52:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Steve, > The primary motivation in the IETF for developing standards is to > promote interoperability. What you seem to suggest is a that we not > preclude someone from saying that they comply with IPsec, even though > they would be following a demuxing policy that is not used in any > extant implementations and thus would not be interoperable with any > of these implementations. This does not promote interoperability; > all it does is allow someone to claim conformance with a standard. > That does not seem constructive and, as I noted, it only add to > complexity. > > Am I missing something in your suggestion? > I read Tero's suggested text as only applying to a new SPI in the reserved region. It would therefore promote interoperability for that SPI, but should not impact any other. Perhaps the text needs to be strengthened to make this clearer? jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 11:33:44 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12798 for ; Wed, 18 Jun 2003 11:33:44 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5IFVRG5001602; Wed, 18 Jun 2003 17:31:27 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQM3A4; Wed, 18 Jun 2003 17:32:57 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5IFVQsY001171; Wed, 18 Jun 2003 17:31:26 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IFVBme009562; Wed, 18 Jun 2003 17:31:11 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5IFVBq3009561; Wed, 18 Jun 2003 17:31:11 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IFV9me009557 for ; Wed, 18 Jun 2003 17:31:09 +0200 (MET DST) Message-ID: <014801c335ae$5e53aeb0$4204300a@DCLKEMPFTP> From: "James Kempf" To: "Pekka Nikander" , "Tero Kivinen" Cc: "Stephen Kent" , , "SEND WG" References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF01165.1040906@nomadiclab.com> Subject: Re: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) Date: Wed, 18 Jun 2003 08:29:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Just to clarify a bit to what Pekka has said (and with my SEND WG chair hat on). Mobile IP faced some similar issues to what SEND is currently facing in the area of securing binding updates to correspondent nodes, which caused them to abandon AH and develop a new protocol. In SEND, we have a reasonably complete design using AH based on a reserved SPI that would work with RSA, but it does require an implementation for the SA that behaves somewhat differently from the two standard cases of a manual SA or an SA established with IKE. Pekka has suggested some baseline changes in the design that would reduce the IPsec implementation work, so most of these differences are due to the fact the public key is being used, some are due to other factors around the particular application. Depending on what you believe the reserved SPI were for, this could be viewed either as an unnecessary complexity or an extension. That said, there is strong feeling from some security-knowledgable SEND WG members and a major vendor that reviewed the initial design that too many changes would be required in IPsec, and that SEND should also develop a new protocol. We'll be discussing a proposal from Jari Arkko on the list and at the meeting to use ND options rather than AH, despite the fact the AH was specified in RFC 2461/2462. This is something we've been very strongly trying to avoid, since the intent of SEND was to be very conservative. There is no concensus in the WG at the moment about which way to go, since we've just begun the discussion. Now removing my WG chair hat and more or less quietly and inobtrusively slipping on my IAB hat (but not, of course, in any way speaking for the IAB), these two cases where AH has been tried to secure IP signaling traffic and found significant difficulties suggest that there might be a more fundamental problem involving securing IP signaling that might benefit from some additional attention. From Ito-jun's email, it sounds like he has examples of cases where AH out of the box works with securing BGP updates, so the perhaps there is a class of IP signaling security problems that can be solved by AH. Knowing the boundaries of that class might be helpful. jak ----- Original Message ----- From: "Pekka Nikander" To: "Tero Kivinen" Cc: "Stephen Kent" ; ; "SEND WG" Sent: Wednesday, June 18, 2003 12:14 AM Subject: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) > Steve and Tero, > > [Taking my SEND WG chair hat firmly *off*, i.e., speaking for > myself only.] > > Stephen Kent wrote: > > Until SEND has a comprehensive, coherent model for using AH that does > > not require changes to other parts of IPsec processing, ... > > With all respect, I sincerely believe that SEND will never come up > with "a comprehensive, coherent model for using AH that does > not require changes to other parts of IPsec processing". More on that > below. If you disagree, please try to come up with a scheme where > you use AH when you > > - don't have any IP addresses (i.e. during IPv6 DAD) > > - do not know in which network you are (public access) > > - do not trust most nodes in the network (public access) > - and are still trying to figure out what node(s) to trust, > how much, and in which respects > > - do not know which of the potentially many trust roots you > should use to establish trust with the possibly existing > trusted nodes in the otherwise untrusted network > > - want to operate, at a lower level of security, when you > are unable to establish pre-configured trust with anyone > > - want to make this all *effectively*, without using zillions > of messges, since you potentially have to do this each time > you roam to a different IP network > > I still claim that there are situations where the integrity and > data origin authentication of the IP header is important. > Hence, I firmly believe that the text concerning the relationship > between AH and ESP is misleading at best and perhaps even outright > wrong. Using tunnel mode is not an answer, at least sometimes. > > >> - In the current SEND WG proposal, the SA does not indicate the key > >> to be used. Instead, the AH header itself contains the public > >> key. .... > >> > > This is not consistent with the IPsec specs! > > Actually I more or less agree with you, Steve! Indeed, that is > one of the reasons why I am proposing changes to the current AH > usage in SEND, basically moving the public key from the AH header > to a separate extension header, to be placed before the AH header. > (See the separate discussion at the SEND WG ML.) > > > In IPsec, the SAD entry for an SA stores the keys that are employed > > to process packets. In turn, the SAD entry is located by using the > > SPI from an inbound packet (for unicast traffic). > > I am very very well aware of that. I quite well remember what > I learned while I implemented one of the early BITS IPsec stacks > as a part of my PhD work back in 1994-1995. > > However, sometimes the SPI alone is not very useful, and sometimes > using the destination address as a selector is not the right choice. > (More on this on the separate thread.) > > > If SEND wants to use AH then you need to use the protocol (including > > the processing spec) as defined in IPsec, not just the syntax from > > 2402. Suggesting that we change AH to accommodate SEND's possible use > > of it, in a fashion not consistent with the current specs, is asking > > quite a lot. > > I agree. Actually, using the revised suggestion of moving the > public key from the AH header to a separate extension header, > thereby creating an "implicit" or "inline" one message KMP, > seems to simplify issue. However, even in that case it > would really make sense to perform SA selection based on the > source address. However, I defer that discussion to the other > thread. > > Tero Kivinen wrote: > > The SEND is a user of the AH. ... Do we want to say to our > > (only?) user that no we do not allow you to do anything differently? > > As Itojun pointed out (and Steve well knows), SEND is indeed not > the only user of AH. Anyway, thanks for your supporting words. > > We should also remember that RFC2461/2462 explicitly states that > AH is the method to be used for protecting IPv6 ND. That is, in fact, > quite doable if you have a static environment with pre-configured > security associations, PK based or symmetric. However, once you > want to use AH in the public access environment, things get harder. > See the outline above. > > > Do we want them to create another protocol replacing their use of AH? > > This is the very question. There are lots of folks at the > SEND WG who believe so. That is, they believe that AH should > not be used for securing IPv6 ND, and a separate protocol should > be developed instead. > > > Another people who have been saying that they want to use AH is > > Mobile IP people. What do they want? Is the current spec fine with > > them or do the want similar processing than SEND? > > Having been there too (though recently not very actively), I strongly > suspect that some of the MIPv6 requirements will be fairly similar > to those of SEND. Both deal with IP address mappings, MIP with > IP -> IP mappings and ND with IP -> lladdr mappings. > > > Is there any use for the AH as it is now specified? > > What are application(s) / protocol(s) which will use it? > > I think Itojun answered to these. > > > If we cannot answer to those questions I think we should drop the > > current AH from the IPsec WG and say that SEND/Mobile IP etc can > > specify it so that it will be suitable for them :-) > > Thanks. See the other thread at saag. > > > I do NOT see any use for the AH on the VPNs or road > > warriors IPsec clients. > > Here I tend to agree with you, Tero, but that is really beside > the point of this discussion, IMHO. > > --Pekka Nikander > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 12:07:27 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14544 for ; Wed, 18 Jun 2003 12:07:27 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5IG5tcv020052; Wed, 18 Jun 2003 18:05:55 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQMTHY; Wed, 18 Jun 2003 18:06:34 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5IG52N23462; Wed, 18 Jun 2003 18:05:02 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IG4cme013565; Wed, 18 Jun 2003 18:04:38 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5IG4cFB013564; Wed, 18 Jun 2003 18:04:38 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IG4ame013560 for ; Wed, 18 Jun 2003 18:04:37 +0200 (MET DST) Received: (qmail 27435 invoked from network); 18 Jun 2003 16:04:34 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Jun 2003 16:04:34 -0000 Date: Wed, 18 Jun 2003 09:07:52 -0700 Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Pekka Nikander , SEND WG , Jari Arkko , Tuomas Aura , James Kempf To: greg.daley@eng.monash.edu.au From: Jonathan Wood In-Reply-To: <3EF00649.2030304@eng.monash.edu.au> Message-Id: <038F5609-A1A7-11D7-8A68-0003930D291E@speakeasy.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, June 17, 2003, at 11:27 PM, Greg Daley wrote: > Hi Johnathan, > > Jonathan Wood wrote: >> On Sunday, June 15, 2003, at 02:20 AM, Pekka Nikander wrote: >>> >>> While implementing the current proposal, we seem to end up >>> including the CGA information in at least two separate kernel >>> data structures. >> I haven't found this to be an implementation issue for me (working >> on Linux), so from an implementation standpoint I don't really care. >> However... > > Sorry if this sounds dumb, but what do you mean > not a problem? > > Not a problem to implement. > > or: > > Not a problem, there's no IPR/GPL clash that I can see. > > I think that especially in the case of Linux, the > second issue is not so clear (or clearly not so good). Ah, apologies for the ambiguity - I meant "Not a problem to implement." I agree that there is potential for trouble on the latter point you mention. j -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 14:46:49 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20768 for ; Wed, 18 Jun 2003 14:46:48 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5IIigw2005073; Wed, 18 Jun 2003 20:44:42 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP89JG9; Wed, 18 Jun 2003 20:45:08 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5IIieN28287; Wed, 18 Jun 2003 20:44:40 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IIhume003568; Wed, 18 Jun 2003 20:43:56 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5IIhuns003567; Wed, 18 Jun 2003 20:43:56 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from dave.com ([210.104.149.50]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5IIhkme003562 for ; Wed, 18 Jun 2003 20:43:50 +0200 (MET DST) Message-ID: <5e0101c335c5$71a0f830$3eebfd40@Davedfbe> Reply-To: From: To: Dustin@standards.ericsson.net Subject: How To 'Pick Up' Beautiful Women - #1 Best Selling book by John EaganHp Date: Wed, 18 Jun 2003 09:14:22 -0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit HOW TO 'PICK UP' BEAUTIFUL WOMEN by John Eagan, THE BOOK THAT IS GETTING NOTICED! Please read the following information on this book's accomplishments: PENTHOUSE MAGAZINE promoted the author, John Eagan, as a "Miracle Worker" and published a major article praising the book. Penthouse Magazine's July '99 cover says "Getting Beautiful Girls - Self Styled Pick Up Guru Shares His 'Super Techniques.'" According to Penthouse Magazine, John Eagan had to take out an individual named "Bill." Penthouse described it as follows -(page 132) "John's got his work cut out for him with Bill who is in his 40's, balding, wears glasses and sports an ill-advised goatee." Yet Penthouse goes on to say that Bill, using John Eagan's techniques, (page 133) "obtained 3 women's phone numbers that night." On November 20th '99, John Eagan - author of the book "How To Pick Up Beautiful Women" - appeared as a guest on the Howard Stern Radio Show, CBS TV. According to Howard Stern, John Eagan was asked to go out with the E! crew and their hidden cameras to get dates for some of their interns. Howard said the interns were the ugliest guys he could find. John Eagan had to coach the interns with his techniques by speaking into the interns ear pieces. Using John Eagan's techniques, these interns got dates with beautiful girls. Howard said "This guy is no bull, I've seen him in action. He's the real deal." For more information - read on. You can purchase this book directly from Amazon.com at http://www.amazon.com/exec/obidos/ASIN/0964160307/qid=938524192/102-8020158- 8806553 BarnesandNoble.com at http://search.barnesandnoble.com/booksearch/isbnInqui ry.asp?userid=2W4F96PP70&isbn=0964160307&itm=1 Or Borders.com. You can also special order through your local bookstores. The price is $14.95 for this 260+ page paperback which includes Super Techniques guaranteed to work that will make any man invincible when it comes to getting dates with women. "MEN'S FITNESS MAGAZINE" published an article claiming they got dates with every beautiful woman they approached by using techniques from John Eagan's book. The over 260 page book called "How To 'Pick Up' Beautiful Women, Secrets Every Man Should Know" by John Eagan was rated NUMBER 1 by Men's Fitness Magazine after they field tested the top books on the market. Men's Fitness Magazine decided to take on the challenge of employing the techniques of the top books on the market today. Their findings will astound you. "How to 'Pick up' Beautiful Women, Secrets Every Man Should Know" by John Eagan received the highest rating because his techniques got them dates with every beautiful woman they approached. No other book on the market came even close. Why waste your time with anything less than NUMBER 1. You can purchase this book directly from Amazon.com at http://www.amazon.com/exec/obidos/ASIN/0964160307/qid=938524192/102-8020158- 8806553 BarnesandNoble.com at http://search.barnesandnoble.com/booksearch/isbnInqui ry.asp?userid=2W4F96PP70&isbn=0964160307&itm=1 Or Borders.com. You can also special order through your local bookstores. The price is $14.95 for this 260+ page paperback which includes Super Techniques guaranteed to work that will make any man invincible when it comes to getting dates with women. The author, John Eagan has acquired two college degrees and writes a popular sex and dating column for "Muslemag International." He has interviewed over 2000 beautiful women and incorporates that with the latest university studies on dating for this powerful book. He has appeared on many national TV and radio shows. Would you like to find out why: >HOWARD STERN said "This guy is no bull, he's the real deal. I've seen him in action." "Wait until you see how amazing this guy is." >GERALDO RIVERA was quoted as saying, "This book can get men over their shyness." >ROLLING STONE MAG called John's techniques "genius." >DANNY BONADUCE said, "John Eagan is a genius, you could pick anyone up with this book." >SALLY JESSY RAPHAEL was quoted as calling the techniques "Perfect." >GORDON ELLIOTT told his audience, "Take this man's advice." >HARD COPY was quoted as saying, "This book can make women melt." >LEE LEONARD of CNN News was quoted as saying, "I like that, this book is a sure winner." >When CHELSEA PICTURES and the BBC were considering experts for their dating documentary for HBO, they said "We reviewed thousands of dating books and John Eagan's book kept coming to the top." >MEN'S FITNESS MAGAZINE said "He knows the score, man." >MEN'S HEALTH BOOKS "A LIFETIME OF SEX" (Page 88) said "Here at Men's Health Books we like to cite doctors and authorities of similar repute. John Eagan is an authority and he consented to share his findings with us fortunate guys at Men's Health..." Imagine yourself dating a beautiful woman today. Why be left out in the cold - Join the millions of successful men who have already learned the secrets. If you would like to read the Men's Fitness article and the Penthouse article for yourself as well as the introduction to the book along with what other distinguished celebrities had to say about the book, simply look John Eagan up on the internet. You can purchase this book directly from Amazon.com at http://www.amazon.com/exec/obidos/ASIN/0964160307/qid=938524192/102-8020158- 8806553 BarnesandNoble.com at http://search.barnesandnoble.com/booksearch/isbnInqui ry.asp?userid=2W4F96PP70&isbn=0964160307&itm=1 Or Borders.com. You can also special order through your local bookstores. The price is $14.95 for this 260+ page paperback which includes Super Techniques guaranteed to work that will make any man invincible when it comes to getting dates with women. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 16:18:44 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27518 for ; Wed, 18 Jun 2003 16:18:44 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5IKEww2011393; Wed, 18 Jun 2003 22:14:58 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP89TS6; Wed, 18 Jun 2003 22:15:23 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5IKEvN00761; Wed, 18 Jun 2003 22:14:57 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IKEQme015001; Wed, 18 Jun 2003 22:14:26 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5IKEPsf015000; Wed, 18 Jun 2003 22:14:25 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IKEOme014996 for ; Wed, 18 Jun 2003 22:14:24 +0200 (MET DST) Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5IKENYU000236 for ; Wed, 18 Jun 2003 14:14:23 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGP001D41JYMD@edgemail1.Central.Sun.COM> for ietf-send@standards.ericsson.net; Wed, 18 Jun 2003 14:14:23 -0600 (MDT) Received: from 192.168.1.100 ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGP00C8Q1JK12@mail.sun.net> for ietf-send@standards.ericsson.net; Wed, 18 Jun 2003 14:14:12 -0600 (MDT) Date: Wed, 18 Jun 2003 22:14:04 +0200 From: Julien Laganier Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH In-reply-to: <3EEC3A57.1020908@nomadiclab.com> To: Pekka Nikander , SEND WG Cc: Jari Arkko , Tuomas Aura , James Kempf Message-id: <200306182214.04368.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5.2 References: <3EEC3A57.1020908@nomadiclab.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka, Sorry for responding late to this message, but a detail related to your proposal come to my mind. More below... Pekka Nikander wrote: > > (...) > > Now, if we separated CGA processing completely from AH processing, > AH should not know about CGA at all. Here you state that CGA processing could be _completely separated_ from AH processing, so by 'reflexion' I guess that the CGA header processing would not use informations contained in the AH header (please correct me if I misunderstood) => CGA should not known about AH at all. > When sending outbound packets, > the ND stack would include a CGA header, and the IPsec processing > would included it as a part of the IP packet, making sure that > it is located before the AH header (just like HbH options or > Routing Header is). On the input side, a separate piece of code > (trigged by the next header field) would process the CGA header, > drop the packet if the CGA verification fails, and cache the key > otherwise. So the CGA layer cache the key before verifying the signature included in the AH header. > AH would then be able to fetch the key from the cache. And here (in the AH layer) occurs the signature verification. I suspect that caching (at least) 1024 bits of a Public Key for each received CGA-header without verifying signatures (embedded in AH) may be subject to DoS attacks on the memory resources containing the PK cache. On the other hand, you can validate the CGA header by verifying the signature embedded in the AH header before populating the new PK in the cache... in this case I guess I completely your proposal. Thanks, -- Julien Laganier SUN Microsystems Laboratories -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 16:51:20 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29254 for ; Wed, 18 Jun 2003 16:51:19 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5IKoJcv002021; Wed, 18 Jun 2003 22:50:19 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQNR32; Wed, 18 Jun 2003 22:50:57 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5IKnNsY008519; Wed, 18 Jun 2003 22:49:23 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IKmume019980; Wed, 18 Jun 2003 22:48:56 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5IKmuWb019979; Wed, 18 Jun 2003 22:48:56 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5IKmsme019975 for ; Wed, 18 Jun 2003 22:48:55 +0200 (MET DST) Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5IKmrYU019370 for ; Wed, 18 Jun 2003 14:48:53 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGP001XJ35GMD@edgemail1.Central.Sun.COM> for ietf-send@standards.ericsson.net; Wed, 18 Jun 2003 14:48:53 -0600 (MDT) Received: from 192.168.1.100 ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGP00CL435CPN@mail.sun.net> for ietf-send@standards.ericsson.net; Wed, 18 Jun 2003 14:48:52 -0600 (MDT) Date: Wed, 18 Jun 2003 22:48:43 +0200 From: Julien Laganier Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH In-reply-to: <200306182214.04368.julien.laganier@sun.com> To: Pekka Nikander , SEND WG Cc: Jari Arkko , Tuomas Aura , James Kempf Message-id: <200306182248.43987.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5.2 References: <3EEC3A57.1020908@nomadiclab.com> <200306182214.04368.julien.laganier@sun.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Folks, Following what I was thinking... Julien Laganier wrote: > > Pekka Nikander wrote: > > > > (...) > > > > Now, if we separated CGA processing completely from AH processing, > > AH should not know about CGA at all. > > Here you state that CGA processing could be _completely separated_ from AH > processing, so by 'reflexion' I guess that the CGA header processing would > not use informations contained in the AH header (please correct me if I > misunderstood) => CGA should not known about AH at all. Thus not allowing the CGA layer to validate the PK against the RSA signature (only against the source IPv6 CGA). A solution to this problem may be to have the CGA header being signed as well, with the corresponding PK. Thanks, -- Julien Laganier SUN Microsystems Laboratories -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 17:37:05 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01112 for ; Wed, 18 Jun 2003 17:37:04 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5ILZOw2015916; Wed, 18 Jun 2003 23:35:24 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYG233ND; Wed, 18 Jun 2003 23:37:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5ILZNsY009366; Wed, 18 Jun 2003 23:35:23 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5ILYpme025985; Wed, 18 Jun 2003 23:34:51 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5ILYpaa025984; Wed, 18 Jun 2003 23:34:51 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from albatross.tn.sw.ericsson.se (albatross.tn.sw.ericsson.se [193.180.251.49]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5ILYmme025966 for ; Wed, 18 Jun 2003 23:34:48 +0200 (MET DST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5ILYmG5000314 for ; Wed, 18 Jun 2003 23:34:48 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8965D; Wed, 18 Jun 2003 23:35:13 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5ILYWSZ029725 for ; Thu, 19 Jun 2003 00:34:32 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id 361AC5F691 for ; Thu, 19 Jun 2003 00:35:01 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 422CC6A904; Thu, 19 Jun 2003 00:34:40 +0300 (EEST) Message-ID: <3EF0D24B.3080407@piuha.net> Date: Wed, 18 Jun 2003 23:57:47 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander , Stephen Kent Cc: Tero Kivinen , ipsec@lists.tislabs.com, SEND WG Subject: Re: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF01165.1040906@nomadiclab.com> In-Reply-To: <3EF01165.1040906@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Kent wrote: >> Another people who have been saying that they want to use AH is Mobile >> IP people. What do they want? Is the current spec fine with them or do >> the want similar processing than SEND? Mobile IPv6 does not employ AH. Most of the security solution in MIPv6 is in the "application" layer. It does use ESP for one thing, namely the protection of signaling between the mobile node and its home agent where traditional security associations can be assumed to exist. It does place some requirements on IPsec, but the requirements for SEND are tougher. I still think current SEND approach is within the bounds of the IPsec architecture. And I think it would be a good idea for the IETF to think where it will apply AH, and what its future role is. However, I suspect an ND layer solution would be a surer bet, mainly because in SEND it would have access to all information, such as some of the addresses that don't appear in the IP header. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 17:37:07 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01128 for ; Wed, 18 Jun 2003 17:37:06 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5ILZJG5000355; Wed, 18 Jun 2003 23:35:19 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLS66A; Wed, 18 Jun 2003 23:35:15 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5ILZIsY009361; Wed, 18 Jun 2003 23:35:18 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5ILYpme025982; Wed, 18 Jun 2003 23:34:51 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5ILYoJB025979; Wed, 18 Jun 2003 23:34:50 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from albatross.tn.sw.ericsson.se (albatross.tn.sw.ericsson.se [193.180.251.49]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5ILYmme025968 for ; Wed, 18 Jun 2003 23:34:48 +0200 (MET DST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5ILYmG5000317 for ; Wed, 18 Jun 2003 23:34:48 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYG233LK; Wed, 18 Jun 2003 23:36:41 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5ILYWSZ029726 for ; Thu, 19 Jun 2003 00:34:32 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id E06545F698 for ; Thu, 19 Jun 2003 00:35:01 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 14FAA6A902; Thu, 19 Jun 2003 00:34:36 +0300 (EEST) Message-ID: <3EF0CAFF.20106@piuha.net> Date: Wed, 18 Jun 2003 23:26:39 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itojun@iijlab.net Cc: Tero Kivinen , Stephen Kent , Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences References: <20030618063808.697EE92@coconut.itojun.org> In-Reply-To: <20030618063808.697EE92@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit itojun wrote: > even if there's very little use of AH in the community, major change > to AH that SEND requires would require another IP protocol #, IMHO. I'm not sure how significant the changes are, e.g. much of it can be seen as the properties of a new algorithm. Nevertheless, I'm personally in favor of a SEND approach which uses ND options. More details at http://www.piuha.net/~jarkko/publications/send/dafts/draft-send-ndopt.txt --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 22:36:26 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12041 for ; Wed, 18 Jun 2003 22:36:26 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J2XfG5018444; Thu, 19 Jun 2003 04:33:41 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQ3MX4; Thu, 19 Jun 2003 04:35:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5J2XesY013740; Thu, 19 Jun 2003 04:33:40 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J2X4me013020; Thu, 19 Jun 2003 04:33:04 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5J2X4Up013019; Thu, 19 Jun 2003 04:33:04 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J2X1me013013 for ; Thu, 19 Jun 2003 04:33:02 +0200 (MET DST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0A66889; Thu, 19 Jun 2003 11:32:57 +0900 (JST) To: jari.arkko@piuha.net Cc: Tero Kivinen , Stephen Kent , Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG In-reply-to: jari.arkko's message of Wed, 18 Jun 2003 23:26:39 +0300. <3EF0CAFF.20106@piuha.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences From: itojun@iijlab.net Date: Thu, 19 Jun 2003 11:32:57 +0900 Message-Id: <20030619023257.0A66889@coconut.itojun.org> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk >> even if there's very little use of AH in the community, major change >> to AH that SEND requires would require another IP protocol #, IMHO. >I'm not sure how significant the changes are, e.g. much of it can be seen >as the properties of a new algorithm. draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol proposal (not a new algorithm) to me. AH needs to fall into what is defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond what defined in RFC2402. itojun -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 22:46:45 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12141 for ; Wed, 18 Jun 2003 22:46:44 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J2i3w2005021; Thu, 19 Jun 2003 04:44:03 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP805MR; Thu, 19 Jun 2003 04:44:29 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5J2i1sY013854; Thu, 19 Jun 2003 04:44:01 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J2hkme013575; Thu, 19 Jun 2003 04:43:46 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5J2hkNW013574; Thu, 19 Jun 2003 04:43:46 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J2hime013561 for ; Thu, 19 Jun 2003 04:43:44 +0200 (MET DST) Received: from [12.159.173.182] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5J2foDD028955; Wed, 18 Jun 2003 22:41:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> Date: Wed, 18 Jun 2003 22:42:20 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Cc: Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk At 9:28 AM +0300 6/18/03, Tero Kivinen wrote: >Stephen Kent writes: >> syntax from 2402. Suggesting that we change AH to accommodate SEND's >> possible use of it, in a fashion not consistent with the current >> specs, is asking quite a lot. > >The SEND is a user of the AH. Are there any other real users for the >AH? In earlier days there was people saying that we should remove the >whole AH as nobody uses. Now there seems to be SEND that is using it, >but they want to do something differently. Do we want to say to our >(only?) user that no we do not allow you to do anything differently? The way you seem to want to use AH is so different from normal IPsec processing as to warrant having a different protocol, in my view. You can't just appropriate the name of the protocol and its syntax, but change the processing model. >Do we want them to create another protocol replacing their use of AH? >Another people who have been saying that they want to use AH is Mobile >IP people. What do they want? Is the current spec fine with them or do >the want similar processing than SEND? Good question. >Actually they quite often want to do demultiplexing based on the >fields inside the mobility or routing header not the outer IP address. >I.e they might need different demultiplexing algorithm too. Then we have a BIG problem. So far I have not seen a mature proposal from mobile IP that requires what you suggest. > >So the real questions are: > > >Is there any use for the AH as it is now specified? Very little. But, that does not mean that one can redefine it and still have it be part of IPsec. >What are application(s) / protocol(s) which will use it? This is not the right question. The question is whether AH does what you want for SEND. if not, and if the changes are significant, then create a different protocol. >If we cannot answer to those questions I think we should drop the >current AH from the IPsec WG and say that SEND/Mobile IP etc can >specify it so that it will be suitable for them :-) The SEND WG can create its own protocol, but there is no technical rationale for reusing the AH name. Reuse would only cause confusion. >I do not want any generic text saying "someone might want to use it if >the phase of the moon is full and ..., and,... and ... export control >... and ... goverment ... and ...". > >I do want current real word example (where the current AH as specified >in the current document) is actually used or is planned to be used. I >do NOT see any use for the AH on the VPNs or road warriors IPsec >clients. We appear to disagree on the ground rules. You seem to be suggesting that AH is like an abandoned ship, and whoever gets to it first can claim the name and redefine it :-) If IPsec has no continuing use for AH, then maybe we can retire the protocol number after a few years, but we seem to have some folks who suggest otherwise. I think the best course is to define a protocol that does what SEND needs and not try to twist AH into that protocol. Steve -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 18 23:40:11 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13416 for ; Wed, 18 Jun 2003 23:40:10 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J3ZNG5021621; Thu, 19 Jun 2003 05:35:23 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLTX39; Thu, 19 Jun 2003 05:35:19 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5J3ZHsY014460; Thu, 19 Jun 2003 05:35:17 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J3Ypme024776; Thu, 19 Jun 2003 05:34:51 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5J3YpCA024775; Thu, 19 Jun 2003 05:34:51 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J3Ymme024770 for ; Thu, 19 Jun 2003 05:34:49 +0200 (MET DST) Received: from [12.159.173.182] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5J3XSD9000616; Wed, 18 Jun 2003 23:33:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <00e001c335a9$4bef1250$4204300a@DCLKEMPFTP> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> <00e001c335a9$4bef1250$4204300a@DCLKEMPFTP> Date: Wed, 18 Jun 2003 23:32:04 -0400 To: "James Kempf" , "Tero Kivinen" From: Stephen Kent Subject: Re: AHbis WG LC: need for source address based selectors Cc: "Pekka Nikander" , , "Barbara Fraser" , , "SEND WG" , kent@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk At 7:52 AM -0700 6/18/03, James Kempf wrote: >Steve, > >> The primary motivation in the IETF for developing standards is to >> promote interoperability. What you seem to suggest is a that we not >> preclude someone from saying that they comply with IPsec, even >though >> they would be following a demuxing policy that is not used in any >> extant implementations and thus would not be interoperable with any >> of these implementations. This does not promote interoperability; >> all it does is allow someone to claim conformance with a standard. >> That does not seem constructive and, as I noted, it only add to >> complexity. >> >> Am I missing something in your suggestion? >> > >I read Tero's suggested text as only applying to a new SPI in the >reserved region. It would therefore promote interoperability for that >SPI, but should not impact any other. Perhaps the text needs to be >strengthened to make this clearer? > > jak reserved SPIs are a holdover from the early days of IPsec and are generally not used. But, the change in processing that has been proposed is simply not consistent with the overall IPsec processing model and saying that it applies to only this one SPI does not make life better. I'm afraid that this is just a bad fit. Steve -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 00:56:29 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15779 for ; Thu, 19 Jun 2003 00:56:29 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J4tScv020660; Thu, 19 Jun 2003 06:55:28 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP9AGY3; Thu, 19 Jun 2003 06:55:02 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5J4sRsY015314; Thu, 19 Jun 2003 06:54:27 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J4rwme005647; Thu, 19 Jun 2003 06:53:58 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5J4rwZT005646; Thu, 19 Jun 2003 06:53:58 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J4rume005642 for ; Thu, 19 Jun 2003 06:53:56 +0200 (MET DST) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id BD38E1C; Thu, 19 Jun 2003 08:03:43 +0300 (EEST) Message-ID: <3EF14222.5000700@nomadiclab.com> Date: Thu, 19 Jun 2003 07:54:58 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itojun@iijlab.net, jari.arkko@piuha.net Cc: Tero Kivinen , Stephen Kent , ipsec@lists.tislabs.com, James Kempf , SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences References: <20030619023257.0A66889@coconut.itojun.org> In-Reply-To: <20030619023257.0A66889@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Itojun, itojun@iijlab.net wrote: > draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol > proposal (not a new algorithm) to me. AH needs to fall into what is > defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond > what defined in RFC2402. I more or less agree with you. In fact, I have proposed moving the keying material into a separate header, as I have explained in length in other messages. If such a change is made, the role of AH would be within the purpose of RFC2402, IMHO. This issue will be discussed in Vienna; we've reserved time for it at the SEND WG meeting. See the proposed WG agenda at the SEND ML. Now, independent on that, the newest version of the said draft is draft-ietf-send-ipsec-01.txt --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 03:44:02 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03566 for ; Thu, 19 Jun 2003 03:44:02 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J7h0cv005465; Thu, 19 Jun 2003 09:43:00 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGL4X5J; Thu, 19 Jun 2003 09:42:03 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5J7g6sY017985; Thu, 19 Jun 2003 09:42:06 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J7fYme028412; Thu, 19 Jun 2003 09:41:34 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5J7fXoH028411; Thu, 19 Jun 2003 09:41:33 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from penguin.al.sw.ericsson.se (penguin.al.sw.ericsson.se [193.180.251.47]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J7fWme028407 for ; Thu, 19 Jun 2003 09:41:32 +0200 (MET DST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J7fWw2002578 for ; Thu, 19 Jun 2003 09:41:32 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGL4XWA; Thu, 19 Jun 2003 09:41:28 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5J7fFSZ028679 for ; Thu, 19 Jun 2003 10:41:15 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id 34B0D5F691 for ; Thu, 19 Jun 2003 10:41:46 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 362CC6A902; Thu, 19 Jun 2003 10:41:26 +0300 (EEST) Message-ID: <3EF1689E.7040304@piuha.net> Date: Thu, 19 Jun 2003 10:39:10 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Tuomas Aura Subject: arguments in favor of ND-based solutions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Tuomas Aura asked me to send his list of arguments in favor of a ND-option based solution to the list. You will find the list below. We also talked about transition mode in the ND-option case, and Tuomas promised to think about it. I feel that the way I defined it in draft-send-ndopt.txt, it still needs some work... I'm quite happy with the rest of the design but this is still somewhat unclear. --Jari (1) The IPSec architecture is not particularly suitable for SEND and other potential applications of CGA. My main concern is that the IPSec policy only accepts or drops packets. Information about the type and strength of the authentication is lost. There is no way to allow both authenticated and unauthenticated packets of the same type, or to differentiate between different types of authentication. Example: The SEND protocol currently does not allow SEND nodes to receive both secure and insecure ND and RD messages. This limitation is caused by the decision to use IPSec AH. If the authorization data were in the ICMP message options, it would be possible for a host to have both secure and insecure personalities. (2) The IPSec policy selectors will never cover all the possible information that application protocols might want to take into account when verifying the authentication on a packet. Example: RS messages need authentication only if they contain the Source link-layer address option. Similarly, a RA message needs trusted-root+CGA authentication if the Source link-layer option is present and only trusted-root authentication if it is not. (Admittedly, the option SHOULD be present in these cases.) (3) Using the CGA+AH headers in a new protocol might not as straightforward as hoped. The CGA mechanism is typically used for authenticating IP-layer signaling messages where the IP addresses are used in some "funny" way. Otherwise, there would not be the need to prove address ownership. Thus, it will not be sufficient to configure the IPSec policy and SAs for the new applications. It will still be necessary to write application-specific code to tweak the way in which the CGA+AH headers are processed in the specific application. This means that the expected benefits from the layered solution do not materialize. Example: If one tries to sign Mobile IPv6 binding updates with the CGA+AH headers, the address to authenticate is not the source address of the a packet but the home address in the HAO. There is a chicken and egg problem between processing the HOA, CGA+AH, and BU. They will need to be processed as a monolithic message and not as a layered one where the authentication is verified first and the payload processed then. Thus, there is no benefit from slitting the authentication data into separate headers. It could as well be a part of the BU. But as Pekka has pointed our earlier, there is always a way around the limitations of IPSec. My question is, does not make sense to twist the logic of other protocols to fit the IPSec model of thinking? There is another, procedural, issue: (4) Application-specific authentication or authorization mechanisms (new ND options) fall within the charter of the SEND WG. Defining a new general-purpose variation of AH does not. Thus, the process would have to involve other WGs that have different goals, different historical baggage, and different schedule. Synchronizing the work of multiple WGs is guaranteed to either fail or to take years. Moreover, if a new application of CGA needs to change the way in which the authentication data is processed, it will be have to go through the same process. Example: Just take a look at the cross-posted messages between IPSec and SEND. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 04:06:31 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04173 for ; Thu, 19 Jun 2003 04:06:31 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J85ncv010158; Thu, 19 Jun 2003 10:05:49 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP9BJDV; Thu, 19 Jun 2003 10:05:23 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5J84tsY018425; Thu, 19 Jun 2003 10:04:55 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J84nme002115; Thu, 19 Jun 2003 10:04:49 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5J84mrk002114; Thu, 19 Jun 2003 10:04:48 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J84lme002110 for ; Thu, 19 Jun 2003 10:04:47 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 520D423; Thu, 19 Jun 2003 11:14:35 +0300 (EEST) Message-ID: <3EF16EDE.3060506@nomadiclab.com> Date: Thu, 19 Jun 2003 11:05:50 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier Cc: SEND WG , Jari Arkko , Tuomas Aura , James Kempf Subject: Re: Should CGA parameters be a separate header instead of being integrated with AH References: <3EEC3A57.1020908@nomadiclab.com> <200306182214.04368.julien.laganier@sun.com> <200306182248.43987.julien.laganier@sun.com> In-Reply-To: <200306182248.43987.julien.laganier@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Julien Laganier wrote: > Here you state that CGA processing could be _completely separated_ > from AH processing, so by 'reflexion' I guess that the CGA header > processing would not use informations contained in the AH header > (please correct me if I misunderstood) => CGA should not known about > AH at all. Correct. > Thus not allowing the CGA layer to validate the PK against the RSA > signature (only against the source IPv6 CGA). Correct. That would have the additional benefit that the CGA payload could carry any "stuff" that creates a security assocation. Not just a public key, but e.g. a hash chain for hash chain based integrity protection. > A solution to this problem may be to have the CGA header being signed > as well, with the corresponding PK. That would only duplicate functionality and increase packet size. > I suspect that caching (at least) 1024 bits of a Public Key for each > received CGA-header without verifying signatures (embedded in AH) may > be subject to DoS attacks on the memory resources containing the PK > cache. Well, that depends on how long you cache the data. As I have tried to state, my suggestion is to cache the data only for the duration of handling the very packet. Once the packet has been processed, the SA is deleted. AFAIK, this does not change the IPsec conceptual model. IPsec already now has the ability to define an SA lifetime in terms of amount of data processed. Thus, in this case, it is conceptually possible to define that the SA must be deprecated once it has processed exactly as much data as there is in the packet. In implementation terms, the SA can be represented as meta-data associated with the packet. That makes fate-sharing between the SA and the packet very easy. However, what it does is that it preserves the IPsec architecture: you first create an SA using a KMP, and then you use the SA at the IPsec "layer". --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 04:06:36 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04190 for ; Thu, 19 Jun 2003 04:06:35 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J85tcv010185; Thu, 19 Jun 2003 10:05:55 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP9BJ1V; Thu, 19 Jun 2003 10:05:30 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5J852N18697; Thu, 19 Jun 2003 10:05:02 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J84eme002102; Thu, 19 Jun 2003 10:04:40 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5J84eJS002101; Thu, 19 Jun 2003 10:04:40 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J84dme002094 for ; Thu, 19 Jun 2003 10:04:39 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 5F0EC1C; Thu, 19 Jun 2003 11:14:22 +0300 (EEST) Message-ID: <3EF16ED1.3040908@nomadiclab.com> Date: Thu, 19 Jun 2003 11:05:37 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Cc: Tero Kivinen , ipsec@lists.tislabs.com, James Kempf , SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Steve, Tero Kivinen wrote: >> The SEND is a user of the AH. ... A major reason why why SEND currently uses AH is that Bellovin suggested that at the Yokohama BoF. James and I, as WC chairs, felt that we should at least *attempt* the way suggested by an AD. However, as it should be clear from this on-going discussion, it is far from clear if that is the right way. Personally, I believe that it indeed is, but others clearly disagree. Stephen Kent wrote: > The way you seem to want to use AH is so different from normal IPsec > processing as to warrant having a different protocol, in my view. You > can't just appropriate the name of the protocol and its syntax, but > change the processing model. I have already addressed this in a separate message. As a summary of that: if we are speaking about the current WG proposal, I tend to agree with you , but I also think that the issues can be solved fairly easily, with just a minor technical change to AHbis. >> Do we want them to create another protocol replacing their use of AH? > > Good question. Indeed. >> Is there any use for the AH as it is now specified? > > Very little. But, that does not mean that one can redefine it and still > have it be part of IPsec. Just out of curiosity: How do you define IPsec? RFC2401? > The SEND WG can create its own protocol, but there is no technical > rationale for reusing the AH name. Reuse would only cause confusion. In my (in this case very) humble opinion, I think that the question of reusing the AH name depends on the intent of the protocol, not only on its syntax. If the goal is the same, to provide integrity and data origin authentication for the whole IP packet, including the immutable or predictable header fields, then I think that the protocol could and should be called AH. If it uses public key crypto, and thereby creates (conceptual) Security Associations that are associated with the source of the packet rather than the destination, even for unicast, that does not change the intent. OTOH, I do agree that embedding KMP functionality into the AH header does not sound that good an idea. However, it did not appear to me how to separate the KMP functionality before I started to implement the current SEND proposal. AH has a long history. I think it would be better to return to the some early goals of AH rather than to deprecate it and start anew. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 04:50:26 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05421 for ; Thu, 19 Jun 2003 04:50:25 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J8nEcv019262; Thu, 19 Jun 2003 10:49:14 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLV17J; Thu, 19 Jun 2003 10:48:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5J8mJsY019639; Thu, 19 Jun 2003 10:48:19 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J8m0me007793; Thu, 19 Jun 2003 10:48:00 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5J8m0Uv007792; Thu, 19 Jun 2003 10:48:00 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5J8lxme007788 for ; Thu, 19 Jun 2003 10:47:59 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 8136E1C; Thu, 19 Jun 2003 11:57:46 +0300 (EEST) Message-ID: <3EF178FD.1060108@nomadiclab.com> Date: Thu, 19 Jun 2003 11:49:01 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Cc: SEND WG , Tuomas Aura Subject: Re: arguments in favor of ND-based solutions References: <3EF1689E.7040304@piuha.net> In-Reply-To: <3EF1689E.7040304@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I will try to write down a drafty draft about the inline KMP + AH approach today. Unfortunately I am leaving for a vacation tomorrow, and therefore I don't have more time but just this day. Now, some comments on Jari's argumentation: Jari Arkko wrote: > (1) The IPSec architecture is not particularly suitable for > SEND and other potential applications of CGA. My main concern > is that the IPSec policy only accepts or drops packets. > Information about the type and strength of the authentication > is lost. There is no way to allow both authenticated and > unauthenticated packets of the same type, or to differentiate > between different types of authentication. Well, based on the discussion that is going on at the saag ML, I think that a number of people disagree with you. I do agree that the current SPD based IPsec "architecture" makes that limitation. However, at least some implementations (KAME in particular) do carry already now some metadata up from IPsec to the upper parts of the TCP/IP stack. RFC2401 does not forbid that; it just does not mandate that, either. Now, I think that in the long run we should enhance the interface from IPsec up, and annotate the packets with more information. However, even that is *not* needed for SEND. For SEND it is perfectly enough to use the source address as a key, and only indicate whether a particular source address was authenticated or not. > Example: The SEND protocol currently does not allow SEND > nodes to receive both secure and insecure ND and RD > messages. This limitation is caused by the decision to > use IPSec AH. Well, to be more precise, this is a decision caused by the current use of a single SA at IPsec AH. This could be changed. > If the authorization data were in the > ICMP message options, it would be possible for a host > to have both secure and insecure personalities. So could a host that separates CGA and AH, and annotates each address separately whether it is a secured or insecured address. I've already implemented the main parts of the CGA related things on KAME; the AH modifications must wait. > (2) The IPSec policy selectors will never cover all the > possible information that application protocols might > want to take into account when verifying the authentication > on a packet. Here I agree with you. However, it may not be necessary to use the selectors to cover all. If AH can verify the integrity and data origin authenticity of a packet, and associate the packet with a unique SA, that is sufficient. The protocols upwards in the stack can then use the SA as a reference point when considering the validity of application specific fields. > Example: RS messages need authentication only if they > contain the Source link-layer address option. The ND layer can check whether the RS message carries the said option, and if it does, drop the message if the associated metadata indicates that the packet was not authenticated. If the packet was authenticated, the ND layer can compare the Source LL address with the credentials associated with the SA or source IP address, and make its decision based on the credentials. > Similarly, > a RA message needs trusted-root+CGA authentication if > the Source link-layer option is present and only > trusted-root authentication if it is not. (Admittedly, > the option SHOULD be present in these cases.) I don't think we need CGA even if the src ll option is present. If you trust a node to be a router, you should believe it also to be trustworthy enough to select its own IP address. Anyway, it can spoof any node in any case, since it is the router. > (3) Using the CGA+AH headers in a new protocol might not > as straightforward as hoped. The CGA mechanism is > typically used for authenticating IP-layer > signaling messages where the IP addresses are used in > some "funny" way. Otherwise, there would not be the need > to prove address ownership. Thus, it will not be sufficient > to configure the IPSec policy and SAs for the new > applications. It will still be necessary to write > application-specific code to tweak the way in > which the CGA+AH headers are processed in the > specific application. This means that the expected > benefits from the layered solution do not materialize. Jari, here I must respectfully disagree, though mostly based on gut feeling only. Could you please give an example of this application-specific tweaking in the case of SEND? And how come does that tweaking to be done at CGA or AH processing, not only at the application level? > Example: If one tries to sign Mobile IPv6 binding updates > with the CGA+AH headers, the address to authenticate is not > the source address of the a packet but the home address > in the HAO. That is mainly a limitation of the current MIPv6 design. If RO BUs were sent with the HoA as the source address, this problem would not appear. IMHO, HAO is a hack, and it should not be used until there is a binding in effect. Hence, you should not use HAO when you send an initial binding. (I don't have time right now to think about your alledged chicken-and-egg problem. Maybe we can return to it later.) > But as Pekka has pointed our earlier, there is always > a way around the limitations of IPSec. My question is, > does not make sense to twist the logic of other protocols > to fit the IPSec model of thinking? Indeed. This is a very good, architectural question, which should gain much more attention! > (4) Application-specific authentication or authorization > mechanisms (new ND options) fall within the charter of the > SEND WG. Defining a new general-purpose variation of AH > does not. Thus, the process would have to involve other WGs > that have different goals, different historical baggage, > and different schedule. Synchronizing the work of multiple > WGs is guaranteed to either fail or to take years. Moreover, > if a new application of CGA needs to change the way in which > the authentication data is processed, it will be have to > go through the same process. The SEND charter states: 2) A protocol for assuring authenticatable distribution of public keys, that allows for example tying a public key to a node's IP address or interface ID, ..., will be designed. Hence, desiging a generic CGA extension header does fit into the SEND charter. Continuing, 3) The use of the key distribution protocol and public key cryptographic scheme for calculating digital signatures in IPsec AH and/or ESP headers will be specified. Hence, using AH to carry a PK signature does fall within the charter as well. I do agree that mixing these two together, the way it is currently done, may be considered as stretching the charter. I am sorry that I have not perceived that earlier. However, keeping 2) and 3) separate does not need to involve other WGs, since the work would clearly fall within the charter. So far, the only real change that SEND requires to AHbis is to allow an AH to be selected based on the SPI and the source address only (perhaps with the protocol field). The reason for that is the desire to use PK crypto, not the usage of CGA. Making the change would involve removing one paranthesized sentence from AHbis. More would be better, but just that single change would suffice. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 06:31:33 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07719 for ; Thu, 19 Jun 2003 06:31:33 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JATDw2005189; Thu, 19 Jun 2003 12:29:13 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLV53G; Thu, 19 Jun 2003 12:29:09 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5JATAsY021936; Thu, 19 Jun 2003 12:29:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JASjme019973; Thu, 19 Jun 2003 12:28:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JASjoC019972; Thu, 19 Jun 2003 12:28:45 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JASime019968 for ; Thu, 19 Jun 2003 12:28:44 +0200 (MET DST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5JASi905410 for ; Thu, 19 Jun 2003 13:28:44 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 19 Jun 2003 13:28:41 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 13:28:43 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 13:28:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: SEND protocol document review Date: Thu, 19 Jun 2003 13:28:42 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB31@esebe023.ntc.nokia.com> Thread-Topic: SEND protocol document review Thread-Index: AcM2TY6Jdo6lAikYRKiOMHlmfmJP2w== From: To: Cc: X-OriginalArrivalTime: 19 Jun 2003 10:28:43.0192 (UTC) FILETIME=[8EC14B80:01C3364D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5JASime019969 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Please find below our review of draft-ietf-send-ipsec-01. Best regards, Pasi Eronen & Valtteri Niemi --------------------------------------------------------------------------- Overall, our biggest complaint about this document is that it seems the use of certificates instead of CGAs for Neighbor Discovery (not Router Discovery) is not really thought out yet. We believe the document would probably be significantly easier to understand and analyze if the CGA case was described separately from the non-CGA case. This could mean splitting to two separate documents, or at least to separate sections within one document (consider such a split especially for sections 4 and 8). Other comments follow: o Section 4: Good text, but perhaps would be even clearer if Router Discovery would be mentioned before Address Autoconfiguration and Redirect. Also, the list of destination address rules is perhaps in the wrong place. Section 6 --------- This section might be easier to read if it would be split to two parts: one describing what sort of certificates are used, and a second section specifying how the certificates are transported over ICMPv6. The certificate transport is relatively straight-forward, but the description of certificate chains could benefit from some clarifications and examples showing at least one valid certificate chain. Also, if certificates are used for both RD and non-CGA ND, any differences should be described (e.g., in the ND case, would a PKC chain ending in an iPAddress subjectAltName be sufficient, or do we also need the AC?) Especially the selection of Attribute Authorities (valid AC issuers) seems a bit strange. The "trusted root" refers to valid PKC issuers, right? And then all CAs (PKC issuers) in the PKC path (from the trust anchor to the router's PKC) are also considered AAs. Unfortunately, RFC 3281 (section 4.5) explicitly forbids this! If this is done anyway, it should be at least well explained and justified. Another aspect that requires clarification is the requirements placed on the PKC chain. At the minimum, the spec should say what requirements are placed on subjectName, subjectAltName, and keyUsage. Preferably the spec should also give some recommendations for interoperability (see draft-ietf-ipsec-pki-profile-02 for example). Also, when specifying this, the SEND spec should probably refer to the PKIX profile (RFC 3280) rather than X.509 itself. Several other points related to this section: o Section 6.3 (editorial): In PKIX-speak, the correct term would probably be "trust anchor", not "trusted root". o Sections 6.3 and 6.6 (technical): Presumably, the "trusted root" should contain the issuer of the first certificate in the chain? But for X.509 certs, that's a Distinguished Name, not FQDN. So, should the "trusted root" option contain a DER-encoded Issuer DN instead of FQDN? Using AltSubjectName (correct spelling is subjectAltName, BTW) seems to make it more difficult for the router to decide which certificate to send, since its own certificate doesn't necessarily have the CA's dNSName (though it may be included in issuerAltName extension). o Section 6.5.1: The definition of the Holder field is a bit vague, and goes against the recommendations of RFC3281 (if this is intentional, at least the reasons for doing so should be documented). Our interpretation is that RFC3281, in this particular scenario would strongly recommend using the baseCertificateID syntax (instead of entityName or objectDigestInfo). Also, even if entityName or objectDigestInfo is used, RFC3281 recommends using only one of them, and recommends using only one entityName (not multiple), and says that if entityName is used, it MUST match the PKC certificate. o Section 6.5.1: If objectDigestInfo is used with digestedObjectType=publicKey, RFC3281 already specifies how objectDigest field must be calculated (section 7.3). o Section 6.5.1: Normative reference to an expired Internet-Draft (for the AuthorizedSubnetPrefix) probably isn't a good idea. Since it seems that the pkix-x509-ipaddr-as-extn draft is dead, either the relevant definitions should be copied here, or documented in a new, separate internet draft. Section 7 --------- It seems that AH_RSA_Sig does not integrate very well with the standard IPsec architecture, and it may well be that the alternative recently discussed on SEND mailing list (drop IPsec, and integrate the cryptographic parts to ND messages) could a be better choice. If we stick with AH, at least the following issues need to be addressed. However, especially the replay protection issue (below) seems to be rather difficult to fix in an elegent way. o Section 7.1.2 (technical/editorial): Any particular reason why the document refers to PKCS#1 v1.5 (almost 10 years old) instead of PKCS#1 v2.1 (2002)? The newer version includes the old 1.5 algorithms, but has substantial editorial improvements (also, 1.5 didn't include SHA-1 OIDs). PKCS#1 v2.1 is also published as RFC 3447 (informational). o Section 7.1.2 (technical): This does not specify the hash algorithm for the RSA signature. (The hash algorithm that was used can be deduced from the PKCS1.5 signature, but still SEND should specify what the sender should select). Might something like "The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash as defined in [PKCSv21]." be better? o Section 7.1.2 (technical): If the signature is calculated "over the the [sic] whole packet as defined by the usual AH rules [3]", the Timestamp and Key Information fields won't get included in the calculation (the usual AH rules say that the whole Authentication Data part is set to zero for this calculation). o Section 7.1.2 (technical): AH requires that the Authentication Data field must be multiple of 32 bits (for IPv4) or 64 bits (IPv6). This means that in some cases, additional padding must be added to the end of the Authentication Data field. While the draft says that "The length of this field [Digital Signature] is determined by the PKCS #1 encoding.", the PKCS#1 RSA signature does not actually include a length field. Adding a new length field to tell where the signature value ends and padding starts would probably be the easiest solution. It's not absolutely necessary, though, since the signature value has always the same length as the RSA modulus (in its "raw" form -- which can be different than the DER encoding of RSAPublicKey.modulus field). Another complication related to this is that the length of the signature field must be known before signing. o Section 7.1.3 (technical): Is it possible to configure more than one trusted root? o Section 7.1.3 (technical): Definition of "minbits" (sort of) assumes that all intermediate certificates are also signed with RSA. In general, this doesn't have to be true: a certificate for peer's RSA key could be signed with elliptic curve DSA or something else for which the "minbits" doesn't make sense. Also, "minbits" is just one example of a policy specifying what sort of certificate chains are acceptable and what are not. For instance, we could require revocation checks (CRL lookup, or OCSP). Maybe these shouldn't be in the SA at all, so perhaps "minbits" could be redefined to refer just to the peer key? (If it's needed at all) o Sections 7.1.4 and 7.1.2 (technical) The document is less than clear when timestamp anti-replay protection should be enabled for inbound security associations, and how nodes without accurate clocks should work. Note that in normal AH, only checking sequence numbers is optional--generating them is not. In AH_RSA_Sig, we can have a situation where the sender has bad clock and generates completely bogus timestamps, but the receiver would like to check them -- and has no way of signalling this to the sender. For instance, if the timestamp checking is enabled for all inbound Neighbor Advertisement messages, then all messages from nodes with bad clocks are dropped. But replays of solicited advertisements could be prevented by nonces alone... (One alternative would be that the sender of the solicited NA copies the timestamp value from the solicitation, just like nonce, but this sounds like an ugly protocol layering violation to me). A similar problem applies to Neighbor Solicitations. If timestamp checking is enabled for all inbound NSs, nodes with bad clocks can't get our address. If we don't check timestamps, replays are possible (and as described in psreq-03 section 4.1.1, there are cases when a node may create neighbor cache entries based on Solicitation messages). So, a sensible rule might be that "in case of invalid timestamp, still respond to the message, but don't create a neighbor cache entry", right? (Again, this seems to break protocol layering) One possible solution to these layering violations (between AH_RSA_Sig and ICMPv6) would be to move the timestamp (and thus all replay protection) to the ICMPv6 layer, by adding a new option similar to Nonce. Or move the nonce to AH layer (but we can't see a simple way to do this). o Section 7.2 (technical) This section actually proposes quite a radical change to IPsec processing! The destination-agnostic SAs are indeed covered by the (uncontroversial) changes in ESPv3/AHv3. However, selecting an inbound SA based on ICMPv6 type code is not. The SPD selectors indeed contain a field for port number where this could be stored. However, in normal IPsec processing, the SPD is checked only after the packet has been authenticated -- so it can't be used to select an SA for inbound packets (the example policy entries in Sections 8.4 and 9.5 also assume that SPD is consulted before selecting SA). But using the ICMPv6 type for selecting inbound SA would also be some sort of protocol layering violation.... Fixing this might be possible rather easily. One possible way to refactor this would be the following: - Always create exactly two special inbound SAs (with two different special SPIs), one for plain AH_RSA_Sig and other one for AH_RSA_Sig+CGA verification (hosts which don't support CGA can treat these two identically; sender can select which to use). This should remove the need to have a separate CGA flag. - Move most of the fields from the inbound SAs to inbound SPD entries (except CGA flag). Sections 9-11 ------------- o Section 9.2.2 (technical/editorial): When Router Advertisements protected only with CGA (but not trusted root) are useful? If they are, document reasons... o Section 9.3.2 (editorial): These requirements duplicate some of the requirements already described in RFC2461 (section 8.1). E.g. RFC2461 already says that unspecified source address is not allowed, and must match the current routing table. o Section 10: What about co-existence of nodes using CGA and those not using CGA? o Section 10.1 (editorial/technical): If SEND nodes don't try do detect if the same address is used by a non-SEND node, why DAD Neighbor Solicitations are sent to the normal solicited-node multicast address, too? o Section 10.1 (technical): The spec says that "Hosts configured for SEND MUST use SEND for all of their addresses, including link local addresses.". Are hosts allowed to use SEND on one link, and not use SEND on some other link? o Section 10.1 (technical): "Secure Router and Neighbor Advertisements MUST use a source address that satisfies the security properties outlined in Section 9. Unless this address is link-local, it MUST belong to one of the advertised secure prefixes. Similarly, source addresses for insecure advertisements MUST belong to one of the advertised insecure prefixes, unless the address is link-local." This changes RFC261 requirements (the source address of Router Advertisements is always a link-local address). If this is intentional, document justifications. o Section 11 (editorial): In phrase "Signatures related to the use of the AH_RSA_Sig transform MAY be precomputed for Multicast Neighbor and Router Advertisements.", perhaps "..precomputed for unsolicited (multicast) Neighbor and Router..." would be clearer. --------------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 07:44:05 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10094 for ; Thu, 19 Jun 2003 07:44:04 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JBd3G5001895; Thu, 19 Jun 2003 13:39:03 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQR28T; Thu, 19 Jun 2003 13:40:36 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5JBd2sY023719; Thu, 19 Jun 2003 13:39:02 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JBcPme029504; Thu, 19 Jun 2003 13:38:25 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JBcPja029503; Thu, 19 Jun 2003 13:38:25 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from falcon.al.sw.ericsson.se (falcon.al.sw.ericsson.se [193.180.251.52]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JBcOme029499 for ; Thu, 19 Jun 2003 13:38:24 +0200 (MET DST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JBdHcv012222 for ; Thu, 19 Jun 2003 13:39:17 +0200 Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYG2RV0P; Thu, 19 Jun 2003 13:40:19 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5JBc7SZ014008 for ; Thu, 19 Jun 2003 14:38:07 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id 1CF1C5F691 for ; Thu, 19 Jun 2003 14:38:38 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6DC5F6A902; Thu, 19 Jun 2003 14:38:17 +0300 (EEST) Message-ID: <3EF1A007.7070301@piuha.net> Date: Thu, 19 Jun 2003 14:35:35 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: ietf-send@standards.ericsson.net, valtteri.niemi@nokia.com Subject: Re: SEND protocol document review References: <052E0C61B69C3741AFA5FE88ACC775A608BB31@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB31@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Thank you Pasi and Valtteri for your in-depth review! > Overall, our biggest complaint about this document is that it seems the > use of certificates instead of CGAs for Neighbor Discovery (not Router > Discovery) is not really thought out yet. We believe the document would I agree that ND cert usage is less baked than the rest of the spec. > probably be significantly easier to understand and analyze if the CGA > case was described separately from the non-CGA case. This could mean > splitting to two separate documents, or at least to separate sections > within one document (consider such a split especially for sections 4 > and 8). The CGA and Signature options that I outlined in draft-send-ndopt.txt might help the situation as well. More later, --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 07:57:17 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10793 for ; Thu, 19 Jun 2003 07:57:16 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JBtDw2020679; Thu, 19 Jun 2003 13:55:14 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP9DG01; Thu, 19 Jun 2003 13:55:42 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5JBtAsY024178; Thu, 19 Jun 2003 13:55:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JBssme001664; Thu, 19 Jun 2003 13:54:54 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JBssQN001663; Thu, 19 Jun 2003 13:54:54 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from albatross.tn.sw.ericsson.se (albatross.tn.sw.ericsson.se [193.180.251.49]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JBsrme001659 for ; Thu, 19 Jun 2003 13:54:53 +0200 (MET DST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JBsrG5005335 for ; Thu, 19 Jun 2003 13:54:53 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQRMVG; Thu, 19 Jun 2003 13:56:25 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5JBsaSZ014983 for ; Thu, 19 Jun 2003 14:54:36 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id BC13C5F691 for ; Thu, 19 Jun 2003 14:55:06 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B14E66A902; Thu, 19 Jun 2003 14:54:46 +0300 (EEST) Message-ID: <3EF1A3FB.4070901@piuha.net> Date: Thu, 19 Jun 2003 14:52:27 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: SEND WG , Tuomas Aura Subject: Re: arguments in favor of ND-based solutions References: <3EF1689E.7040304@piuha.net> <3EF178FD.1060108@nomadiclab.com> In-Reply-To: <3EF178FD.1060108@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > Now, some comments on Jari's argumentation: Just a point of clarification. These arguments were from Tuomas, though I do agree with them. --jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 09:44:10 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17602 for ; Thu, 19 Jun 2003 09:44:09 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JDfwG5026445; Thu, 19 Jun 2003 15:41:59 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP91ANR; Thu, 19 Jun 2003 15:42:27 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5JDfvN01667; Thu, 19 Jun 2003 15:41:57 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JDfWme015125; Thu, 19 Jun 2003 15:41:32 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JDfWru015124; Thu, 19 Jun 2003 15:41:32 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JDfVme015120 for ; Thu, 19 Jun 2003 15:41:31 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id CB21A1C; Thu, 19 Jun 2003 16:51:16 +0300 (EEST) Message-ID: <3EF1BDC8.7020100@nomadiclab.com> Date: Thu, 19 Jun 2003 16:42:32 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Stephen Kent , Tero Kivinen , RJ Atkinson , hipsec@lists.freeswan.org Subject: Pekka Nikander's vacation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I will be on vacation from *now* until the Friday before the Vienna meeting. I will process my e-mail occasionally, but most probably I will not be able to answer. However, during the next three days or so, I will still be able to use some time for e-mail processing, and therefore I *may* be able to continue the dicussion on-going at SEND, IPSEC and SAAG. James will take care of the SEND chairing during my vacation. If you have something important, send me a personal message, and my vacation program will give instructions on how to reach me. --Pekka Nikander SEND WG co-chair -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 09:50:17 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17946 for ; Thu, 19 Jun 2003 09:50:16 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JDlqG5027881; Thu, 19 Jun 2003 15:47:52 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQSG8M; Thu, 19 Jun 2003 15:49:25 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5JDlpN01884; Thu, 19 Jun 2003 15:47:51 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JDlfme016475; Thu, 19 Jun 2003 15:47:41 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JDlfEn016474; Thu, 19 Jun 2003 15:47:41 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JDldme016470 for ; Thu, 19 Jun 2003 15:47:40 +0200 (MET DST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17821; Thu, 19 Jun 2003 09:47:37 -0400 (EDT) Message-Id: <200306191347.JAA17821@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-send@standards.ericsson.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nikander-send-ipsec-00.txt Date: Thu, 19 Jun 2003 09:47:36 -0400 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : Secure Neighbor Discovery using separate CGA extension header Author(s) : P. Nikander Filename : draft-nikander-send-ipsec-00.txt Pages : 16 Date : 2003-6-19 The Secure Neighbor Discovery (SEND) Working Group has produced an Internet Draft that proposes to use an IPsec AH header that carries both a public key and a signature. However, based on the recent discussion at the mailing lists it seems that such a usage of AH is considered inappropriate at least by some members of the IPSEC WG. In this draft we introduce an alternative method, where a separate extension header is used to carry the public key, and the AH header only contains a signature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-send-ipsec-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-send-ipsec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nikander-send-ipsec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19100221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nikander-send-ipsec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nikander-send-ipsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19100221.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 11:10:46 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24122 for ; Thu, 19 Jun 2003 11:10:45 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JF87w2022529; Thu, 19 Jun 2003 17:08:07 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQSWYZ; Thu, 19 Jun 2003 17:09:40 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5JF85N05159; Thu, 19 Jun 2003 17:08:05 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JF7dme026572; Thu, 19 Jun 2003 17:07:39 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JF7dUl026571; Thu, 19 Jun 2003 17:07:39 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JF7Zme026566 for ; Thu, 19 Jun 2003 17:07:36 +0200 (MET DST) Message-ID: <002d01c33673$c578e7c0$416015ac@dclkempt40> From: "James Kempf" To: , Cc: "Tero Kivinen" , "Stephen Kent" , "Pekka Nikander" , "Barbara Fraser" , , , "SEND WG" References: <20030619023257.0A66889@coconut.itojun.org> Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Date: Thu, 19 Jun 2003 08:02:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Itojun, > >> even if there's very little use of AH in the community, major change > >> to AH that SEND requires would require another IP protocol #, IMHO. > >I'm not sure how significant the changes are, e.g. much of it can be seen > >as the properties of a new algorithm. > > draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol > proposal (not a new algorithm) to me. AH needs to fall into what is > defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond > what defined in RFC2402. Could you clarify? What specifically leads you to conclude that SEND should be a new algorithm? I'm particularly interested in understanding what your feelings are about what should and should not be legitimately included under one of the reserved SPI before a protocol should be separated. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 12:38:10 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29964 for ; Thu, 19 Jun 2003 12:38:09 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JGa4cv014077; Thu, 19 Jun 2003 18:36:04 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQTCRJ; Thu, 19 Jun 2003 18:36:44 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5JGZ2sY001690; Thu, 19 Jun 2003 18:35:02 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JGYQme007824; Thu, 19 Jun 2003 18:34:26 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JGYQxs007823; Thu, 19 Jun 2003 18:34:26 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JGYNme007816 for ; Thu, 19 Jun 2003 18:34:24 +0200 (MET DST) Message-ID: <019b01c3367f$e5620a60$416015ac@dclkempt40> From: "James Kempf" To: Subject: Draft on IP Header Option for CGA Date: Thu, 19 Jun 2003 09:29:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka has written a draft on using an IP Header Option for CGA. It is in draft-nikander-send-ipsec-00.txt. Please read and post comments to the list. We will be dicussing this topic in Vienna. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 18:48:34 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24108 for ; Thu, 19 Jun 2003 18:48:33 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JMl5cv030265; Fri, 20 Jun 2003 00:47:05 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLY5WL; Fri, 20 Jun 2003 00:46:09 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5JMkBN17301; Fri, 20 Jun 2003 00:46:11 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JMjdme024507; Fri, 20 Jun 2003 00:45:39 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JMjcvA024501; Fri, 20 Jun 2003 00:45:38 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JMjame024460 for ; Fri, 20 Jun 2003 00:45:37 +0200 (MET DST) Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 15:45:35 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 15:45:35 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Jun 2003 15:45:35 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jun 2003 15:45:35 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jun 2003 15:45:34 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 19 Jun 2003 15:45:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: DT's review of draft-ietf-send-ipsec-01.txt Date: Thu, 19 Jun 2003 15:45:32 -0700 Message-ID: Thread-Topic: DT's review of draft-ietf-send-ipsec-01.txt Thread-Index: AcM2tH1zXCs/NQW8Qf+yg2hF0UNS0A== From: "Dave Thaler" To: X-OriginalArrivalTime: 19 Jun 2003 22:45:33.0214 (UTC) FILETIME=[7DFB4BE0:01C336B4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5JMjbme024483 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit The biggest problem with this document is that the coexistence mechanism appears to be fundamentally flawed (see comments on section 10). Comments on substance follow. There's an even longer list of typos and grammatical errors which I'll send in a separate message. 1) Section 6 states: > Similarly, the router, which is already connected to the network, can > if necessary communicate off-link and construct the certificate > chain. This should be clarified with "in some cases". If the router is not connected to the Internet, this may not be possible. 2) Sections 6.1 and 6.2 describe an Identifier field, but does not specify how it is set in a solicitation or in an unsolicited advertisement. E.g. if it is always set to 1, it doesn't seem very useful. Likewise, if each host starts with 1 and increments, it's also less useful since hosts can collide. I think it should be randomly generated if possible. 3) Sections 6.3 and 6.4 both specify options with a variable-length field followed by padding. However, they use two different encodings for no good reason. One specifies the length of the field, and the other specifies the length of the padding. Instead, both options should be consistent. 4) Section 6.4 says: > When the Name Type field is set to 1, the Name field contains the > Fully Qualified Domain Name of the trusted root, for example > "trustroot.operator.com". More guidance is needed to prevent interoperability problems. Is the string null-terminated (I assume no)? Are internationalized domain names legal? What is the encoding? (UTF-8? Unicode? ...) 5) Section 6.5 says: > RFC 3281. If the GeneralName attribute is a dNSName, it MUST be > resolvable to a global unicast address assigned to the router. If > the GeneralName attribute is an iPAddress, it MUST be a global > unicast address assigned to the router. For purposes of facilitating For people not familiar with X.509, is it easy to explain in 1-2 sentences what it is used for? (That is, why is it a MUST above?) As is, it sounds suspiciously like a security hole. 6) Section 6.5.1 says: > This field MUST contain a list of prefixes that the router is > authorized to route, or the unspecified prefix if the router This wording is particularly problematic. Routers route packets not prefixes. They _advertise_ prefixes in RA's and in routing protocols. It's similarly unclear whether the prefix list is what remote prefixes it's allowed to advertise as off-link routes in RA's (e.g. ::/0 if it can be a default router on the link), or whether the prefix list is what local prefixes it's allowed to advertise as on-link routes in RA's. I'm guessing the latter, but I can think of arguments for restricting both. 7) Sections 6.6 and 6.7 appear to contradict each other. 6.6 says: > SHOULD send an advertisement without any certificates. In this case > the router SHOULD include the Trusted Root options which were > solicited. Hence the Trusted Root option is legal in an advertisement. 6.7 says: > packet processed in the normal manner. The only defined option that > may appear is the Certificate option. An advertisement that passes Hence the Trusted Root option is not legal in an advertisement. 8) Section 7.1.2 and reference [27] contradict each other. 7.1.2 says: > CGAParameters ::= SEQUENCE { > publicKey SubjectPublicKeyInfo, > auxParameters CGAAuxParameters OPTIONAL } whereas [27] now has the opposite order. It would be better to not copy the definition here at all, and just refer to [27] for the definition. 9) Section 7.1.3 talks about a minbits parameter. It doesn't really say how the value should be determined. Some guidance would be helpful. 10) 7.1.4 says: > source address. A packet that has already been seen from the same > source with the same Timestamp field value MUST be silently > discard. Since the granularity of the field is in milliseconds, you need to specify that a node must not send two SEND messages during the same millisecond. However, this restriction may be problematic in some scenarios. 11) Section 10: > operate as two separate logical links, and packets between a secure > and insecure node always go through the router. This is actually false (at least as currently specified), and I'm worried that this whole section (and perhaps others) may be completely broken as a result. Specifically, multicast packets sent from a node will not go through the router. The model is especially broken when there are applications/protocols using link-scoped groups (e.g., LLMNR). Nodes may exchange link-local addresses which then cannot be used in unicast communication. Put another way, nodes can send packets which appear to leave the scope of the unicast address, since a packet received can have a link-local source address from a separate logical link. This violates the Addressing Architecture RFC. If there is some way of fixing this, ensuring that even link-scoped multicast groups are disjoint, then I believe the reason to have a separate solicited-node range completely goes away, and the protocol becomes much simpler. 12) Section 10.1: > One effect of this is that secure hosts can not communicate with > insecure hosts using link-local addresses, and vice versa. Another false statement (as currently specified). See above. > The above rules require secure nodes to ignore all insecure Neighbor > and Router Discovery messages, and all insecure nodes to ignore all This statement contradicts section 10.1 that describes how to respond to (not ignore) insecure solicitations. -Dave -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 18:49:33 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24136 for ; Thu, 19 Jun 2003 18:49:33 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JMmacv030375; Fri, 20 Jun 2003 00:48:36 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP9GJHY; Fri, 20 Jun 2003 00:48:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5JMlgsY008006; Fri, 20 Jun 2003 00:47:42 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JMlame024632; Fri, 20 Jun 2003 00:47:36 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JMlav9024631; Fri, 20 Jun 2003 00:47:36 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JMlYme024622 for ; Fri, 20 Jun 2003 00:47:35 +0200 (MET DST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 15:47:33 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Jun 2003 15:47:33 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jun 2003 15:47:33 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jun 2003 15:47:32 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 19 Jun 2003 15:47:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: DT's review of draft-ietf-send-ipsec-01.txt, part 2 Date: Thu, 19 Jun 2003 15:47:32 -0700 Message-ID: Thread-Topic: DT's review of draft-ietf-send-ipsec-01.txt, part 2 Thread-Index: AcM2tMTQJIflgz8nTlu8m6E388GJvw== From: "Dave Thaler" To: X-OriginalArrivalTime: 19 Jun 2003 22:47:32.0824 (UTC) FILETIME=[C5465580:01C336B4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5JMlame024628 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Typos and grammatical errors (see separate email for technical issues): Abstract: > to active neighbors. If not secured, ND protocol is vulnerable to ^ Insert "the". > securing ND. Contrary to the original ND specifications that also ^^^^^^^^ Should be "Unlike" (nothing in here is contrary to ND). Section 1: > certified by a trusted root, and a zero-configuration mechanism for ^ Insert "is used". > to establish authorization delegation chain to a common trusted root. ^ Insert "an". > and Router Discovery. A few small changes are required in the > Neighbor Discovery protocol and these are discussed in Section 5. Move this last sentence to the beginning of the paragraph so the sections are mentioned in order. Section 2: > of IP traffic encompassed by this policy entry. Separate entries > for inbound and outbound traffic is required [2]. ^^ Should be "are". Section 3: > how the messages should be treated. Where this section and the ^^^^^ Should be "If" (Where implies there are definitely known contradictions). > one of its interfaces runs first the DAD procedure to verify that ^^^^^^^^^^ Should be "first runs". > Discovery and Duplicate Address Detection have an effect to the ^^ Should be "on". However, this whole bullet item seems to have forward references to things mentioned in the Router Discovery bullet item. Hence it would be good to move it down after that for readability. > header consisting of ICMPv6 header and ND message-specific data, and ^ Insert "an". > o Neighbor Solicitation: The destination address is either the > solicited-node multicast address, unicast address, or an anycast ^ Insert "a". > unicast or the All Nodes multicast address [1]. Like the ^ Here, and for every other occurrence of All Nodes (and all-nodes, since the draft is currently inconsistent in which syntax is used throughout), insert "link-scoped". Per RFC 3513, there are two All Nodes multicast addresses, and you mean the link-scoped one. > o Router Solicitation: The destination address is typically the All > Routers multicast address [1]. ^ Same thing. Insert "link-scoped". However, why is the wording different for this bullet item? This one describes the "typical" case where all the others describe what is legal. Section 4: > IPsec AH is used in to protect Neighbor and Router Discovery ^^ Delete "in". > o Cryptographically Generated Addresses are used to assure that the > sender of a Neighbor or Router Advertisement is the owner of an > the claimed address. A public-private key pair needs to be ^^ Delete "an". Also, other sections of this draft (e.g. 13.2.1.2) contradict this wording. Here it says that CGA's are used (implying it's unconditional). Elsewhere it says that either CGAs or trusted roots are used. > o IPsec security policy database and security association database ^ Insert "The". Section 5: > o The use of the unspecified address as a source address is > discouraged. Say why it's discouraged. (E.g. to allow responses to go to just the soliciting node rather than to all nodes). Section 5.1: > Duplicate Address Detection uses the tentative address for which the > Duplicate Address Detection is being run. ^^^ Delete "the". > The use of the unspecified address is avoided in Router > Solicitations, if possible. RFC 2461 requires that Router > Solicitations sent from the unspecified address do not cause a > modification in the Neighbor Cache. This paragraph is unclear. Is the point that you _want_ RS's to cause a modification in the neighbor cache? If so, say so. Section 6: > Nodes multicast address. These messages are separate from the rest > of the Neighbor Discovery in order to reduce the effect of the ^^^ Delete "the". > of the Neighbor Discovery in order to reduce the effect of the > potentially voluminous certificate chain information to other ^^ Should be "on". Section 6.1: > the address of the hosts' default router. ^^^^^^ Should probably be "host's". > The ICMP checksum [8].. ^^ Delete extra period. Section 6.2: > The ICMP checksum [8].. ^^ Delete extra period. > advertisement may be stored and taken in use before all the ^^^^^^^^^^^^ I don't know what that means. Should this be "used"? > One certificate is provided in Certificate option, to establish ^ Insert "each". > a (part of) certificate chain to a trusted root. ^ Insert "a". Section 6.5: > one AC corresponding to one trust root and all interfaces and ^^^^^ Here and in many other places in this section the term is "trust" root, whereas in other sections (2, 6.3, etc) it's "trusted" root. Be consistent throughout. Section 6.6: > Routers MAY send unsolicited Delegation Chain Advertisements for > their trusted root. When such advertisements are sent, their timing ^^^^ Shouldn't this be "root(s)"? > Rate limitation of Delegation Chain Advertisements is performed as ^^^^^^^^^^ Should be "limiting". Section 7.1.2: > The contents of the Key Information field are represented as ASN.1 > DER-encoded data item of the following type: ^ Insert "an". > (The normative definition of the type CGAParameters is in in > [27]). ^^^^^ Delete extra "in". Also, here it says "normative" but [27] is not listed as a normative reference. This seems like a contradiction so a different term would be better. Section 7.1.3: > The minimum acceptable Sec value, if CGA verification is required > (see Section 2 in [27]. ^ Missing ")". > A flag that indicates whether or not the CGA is used. ^^^ Delete "the". Section 7.1.4: > If anti-replay has been enabled, receivers MUST be configured with an > allowed Delta value and maintain a cache of messages received within ^ Insert "SEND". (I assume you don't mean ALL packets.) > source with the same Timestamp field value MUST be silently > discard. ^^^^^^^ Should be "discarded". Section 7.2.2: > using ICMP and ICMPv6 Type field as a selector. ^ Insert "the". Section 8.1.1: > initialized, a node MUST join securely-solicited-node multicast ^ Insert "the". Section 8.1.2: > Neighbor Solicitation messages received without an IPsec AH header ^^^^^^ Delete "header". The H already stands for Header. Either use "AH" or "Authentication Header", but never "AH header". Many other occurrences in this document (the CGA document is fine). > If source address of the Neighbor Solicitation message is the ^ Insert "the". Section 8.2.2: > If source address of the Neighbor Advertisement message is the ^ Insert "the". Section 8.3: > identifier. This specification does not specify the format of such > certificates, since there are currently a few cases where such ^ Delete "a". Section 8.4: > This section shows example security policy and security associations > database entries for the protection of Neighbor Solicitation and ^ Should just be "association" not plural. > security policy data base along with the inbound security ^^^^^^^^^ Should be "database" for consistency with the rest of the document. > The following table summarizes outbound security policy database: ^ Insert "the". Section 9.2.2: > authorization mechanism (CGA or trusted root), the minimum allowable > key size, and optionally with the information related to the trusted > root and the acceptable minSec value. ^^^ Since minSec is specific to CGA, shouldn't this be "or", just like you say "CGA or trusted root" as the mechanism? Same in 9.1.2, 9.3.2. Section 9.3.2: > If source address of the Redirect message is the unspecified address, ^ Insert "the". Section 10.1: > containing the insecure prefixes MUST be sent without AH header. ^ Insert "an" (and delete "header"). Section 10.2: > data base configuration required for the co-existence of SEND and ^^^^^^^^^ Should be "database". Section 13.2.4: > header be calculated using the public key of a host that can prove ^^^^ Should be "node" (can be a router or a host). > Prefix Information Options. The router proves it authorization by ^^ Should be "its". > showing an attribute certificate containing the specific prefix or ^^^^^^^^^ Should be "authorization" (per the terminology section). Section 13.3: > to Denial-of-Service attacks. An attack may target a router by > request a large number of delegation chains to be discovered for ^^^^^^^ Should be "requesting". > certificate chains and their verification. Hosts SHOULD also > prioritize advertisements sent as a response to their requests above > multicast advertisements. ^^^^^^^^^ Shouldn't this be "unsolicited"? Finally, can the page breaks between Appendices A, B, C be removed? (The page count can be decreased by several pages.) -Dave -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 18:53:50 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24227 for ; Thu, 19 Jun 2003 18:53:49 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JMrDcv030597; Fri, 20 Jun 2003 00:53:13 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQ4DNN; Fri, 20 Jun 2003 00:53:54 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5JMqJN17443; Fri, 20 Jun 2003 00:52:19 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JMqCme024890; Fri, 20 Jun 2003 00:52:12 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JMqCAF024889; Fri, 20 Jun 2003 00:52:12 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JMqAme024868 for ; Fri, 20 Jun 2003 00:52:10 +0200 (MET DST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 15:52:09 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Jun 2003 15:52:09 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 15:52:09 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jun 2003 15:52:08 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 19 Jun 2003 15:52:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: DT's review of draft-ietf-send-cga-00.txt Date: Thu, 19 Jun 2003 15:52:08 -0700 Message-ID: Thread-Topic: DT's review of draft-ietf-send-cga-00.txt Thread-Index: AcM2tWk+Y4VG344IQN20l9YzeIPjeQ== From: "Dave Thaler" To: X-OriginalArrivalTime: 19 Jun 2003 22:52:08.0624 (UTC) FILETIME=[69AA1300:01C336B5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5JMqBme024886 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit I found lots of typos and grammatical errors (although far fewer than in the SEND draft), but here I'll just list the comments on actual substance... 1) The title of the document is "Cryptographically Generated Addresses (CGA)". However, the content is currently limited to their use in SEND. Hence, a more appropriate title would be "Securing IPv6 Neighbor Discovery Using Cryptographically Generated Addresses (CGAs)", since it is not a generic spec. 2) On the other hand, I'd prefer the existing title, but the document as specified appears to preclude the use of CGAs in general. Specifically, since the u and g bits MUST be 0 (as opposed to 1, as they were before in both Aura's spec and in Arkko's), there is now no way to distinguish a CGA from another address, and hence it becomes impossible to prevent spoofing of a CGA. This seems like a major design flaw. I don't see this mentioned in Appendix B, why is the more general use of CGA in the future now being prevented? (Since a SEND node now would drop any packet with g,u = 1, one cannot interoperate with a node that does that.) The simple fix is to just remove the statement about dropping if u and g are not 0. 3) Section 7.1 states: > The purpose of CGA addresses is to prevent stealing and spoofing of > IPv6 addresses in the secure neighbor discovery protocol. I strongly disagree with this statement. The purpose of CGA addresses is to prevent stealing and spoofing of IPv6 addresses _in general_. The purpose is not limited to SEND. 4) Section 6 seems to imply that only that section is specific to SEND, and the rest are generally applicable. As mentioned above, I don't believe that is true, as the other sections appear to preclude any use outside of SEND. 5) Section 7.2 states: > The effectiveness of the hash extension depends of the assumption > that the computational capacity of the attacker and the address > generator will grow and the same (potentially exponential) rate. > This is clearly not true if the addresses are generated on low-end > mobile devices. Why is it "clearly" not true? I don't think it's obvious that Moore's law does not apply to low-end mobile devices. Do you have a well-known reference that indicates it does not? 6) Re appendix A: "TBW"? -Dave -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 18:55:05 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24268 for ; Thu, 19 Jun 2003 18:55:04 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JMsWcv030682; Fri, 20 Jun 2003 00:54:32 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLY63K; Fri, 20 Jun 2003 00:53:35 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5JMrcsY008126; Fri, 20 Jun 2003 00:53:38 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JMrXme024964; Fri, 20 Jun 2003 00:53:33 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5JMrXgK024963; Fri, 20 Jun 2003 00:53:33 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5JMrVme024959 for ; Fri, 20 Jun 2003 00:53:32 +0200 (MET DST) Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 15:53:30 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 15:53:30 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Jun 2003 15:53:30 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 15:53:30 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jun 2003 15:53:29 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 19 Jun 2003 15:53:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: DT's review of draft-ietf-send-cga-00.txt, part 2 Date: Thu, 19 Jun 2003 15:53:29 -0700 Message-ID: Thread-Topic: DT's review of draft-ietf-send-cga-00.txt, part 2 Thread-Index: AcM2tZmbOBFXEMduS5+7YTSMCogA3Q== From: "Dave Thaler" To: X-OriginalArrivalTime: 19 Jun 2003 22:53:29.0486 (UTC) FILETIME=[99DCA2E0:01C336B5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5JMrWme024960 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Typos and grammatical errors (see separate email for technical issues): Section 1: > computing a cryptographic hash of the public key. This kind of IPv6 > addresses are called cryptographically generated addresses (CGA). ^^^ Should be "is" since the subject is singular ("kind"). > limit of the interface identifier, and the implications CGA > addresses on privacy. ^ Insert "of". Section 2: > The above definition can be stated in terms of the following two > bit masks: ^^^ Should be "three". Section 4: > RECOMMENDED to that the initial modifier value in step (1) is ^^ Delete "to". > fast. Nodes that implement CGA generation MAY set the security > parameter Sec to always 0. In that case, steps (2)-(3) of the ^ Insert "be". Section 5: > specification may define situations where a it is acceptable for ^ Delete "a". Section 6.1: > sNodes that use the Secure Neighbor Discovery (SEND) protocol and ^ Delete "s". > Note that the node MAY use trusted-root authorization mechanism ^ Insert "a". > instead or in addition to the CGA authorization mechanism ^ Insert "of". > SendKeyInformation ::= SEQUENCE { > cgaParameters CGAParameters OPTIONAL, > signerInfo SubjectPublicKeyInfo OPTIONAL } Would be better to delete this and just refer to [AKSZ03] for the definition of SendKeyInformation so you don't have to rev this spec if it changes. Section 6.2: > verification of the CGA property, the receiver must verify the MUST ^^^^^^^^^^^^^^^ > verify the source address of the packet as described in Section 5. Delete duplicate "must verify the". Section 7.1: > It is important to understand that that attacker can create a new ^^^^ Should be "an". Section 7.2: > The effectiveness of the hash extension depends of the assumption ^^ Should be "on". > generator will grow and the same (potentially exponential) rate. ^^^ Should be "at". > problem. (If CGA address were used as a part of a strong ^^^^^^^ Should be "addresses". Section 7.3: > its appearances of the local link. As long as the node keeps using ^^^^^^^^^^^^^^ I don't know how to interpret this. Please reword. "appearances on" is better, but it's still unclear what "appearances" means. -Dave -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 19 22:15:23 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29864 for ; Thu, 19 Jun 2003 22:15:22 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5K2DNG5022522; Fri, 20 Jun 2003 04:13:23 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLZ2JR; Fri, 20 Jun 2003 04:13:20 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5K2DMN22192; Fri, 20 Jun 2003 04:13:22 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5K2Cjme026827; Fri, 20 Jun 2003 04:12:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5K2Cjfb026826; Fri, 20 Jun 2003 04:12:45 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5K2Cgme026822 for ; Fri, 20 Jun 2003 04:12:43 +0200 (MET DST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 2E40E89; Fri, 20 Jun 2003 11:12:38 +0900 (JST) To: "James Kempf" Cc: jari.arkko@piuha.net, "Tero Kivinen" , "Stephen Kent" , "Pekka Nikander" , "Barbara Fraser" , ipsec@lists.tislabs.com, tytso@mit.edu, "SEND WG" In-reply-to: kempf's message of Thu, 19 Jun 2003 08:02:14 MST. <002d01c33673$c578e7c0$416015ac@dclkempt40> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences From: itojun@iijlab.net Date: Fri, 20 Jun 2003 11:12:38 +0900 Message-Id: <20030620021238.2E40E89@coconut.itojun.org> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk >> >> even if there's very little use of AH in the community, major change >> >> to AH that SEND requires would require another IP protocol #, IMHO. >> >I'm not sure how significant the changes are, e.g. much of it can be seen >> >as the properties of a new algorithm. >> >> draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol >> proposal (not a new algorithm) to me. AH needs to fall into what is >> defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond >> what defined in RFC2402. > >Could you clarify? What specifically leads you to conclude that SEND should >be a new algorithm? I'm particularly interested in understanding what your >feelings are about what should and should not be legitimately included under >one of the reserved SPI before a protocol should be separated. none of existing algorithm for AH defines structure within AH authentication data. therefore i assume AH algorithm to be some crypto-checksum algorithm, not a new protocol definition. for instance, if you write a program to support the draft, SEND use of AH would require certain amount of new code for parsing SEND authentication data packet format, not just a set of calls to crypto- checksum algorithm. AH packet processing should not be that different depending on SPI value. itojun -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 20 01:54:30 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06246 for ; Fri, 20 Jun 2003 01:54:29 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5K5ptw2010816; Fri, 20 Jun 2003 07:51:55 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLZZZA; Fri, 20 Jun 2003 07:51:52 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5K5psN26825; Fri, 20 Jun 2003 07:51:54 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5K5pHme001892; Fri, 20 Jun 2003 07:51:17 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5K5pH3O001891; Fri, 20 Jun 2003 07:51:17 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from localhost.localdomain (ua64d22hel.dial.kolumbus.fi [62.248.149.64]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5K5pGme001887 for ; Fri, 20 Jun 2003 07:51:16 +0200 (MET DST) Received: from kolumbus.fi (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h5K5mwtF006104; Fri, 20 Jun 2003 08:48:58 +0300 Message-ID: <3EF2A049.80901@kolumbus.fi> Date: Fri, 20 Jun 2003 08:48:57 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Thaler CC: ietf-send@standards.ericsson.net Subject: Re: DT's review of draft-ietf-send-ipsec-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Thank you Dave very much for your review! I'll have to respond in detail later, but for now just the following: > 11) Section 10: > > operate as two separate logical links, and packets between a secure > > and insecure node always go through the router. > > This is actually false (at least as currently specified), and I'm > worried that this whole section (and perhaps others) may be > completely > broken as a result. Specifically, multicast packets sent from a node > > will not go through the router. The model is especially broken when > there are applications/protocols using link-scoped groups (e.g., > LLMNR). > Nodes may exchange link-local addresses which then cannot be used in > unicast communication. Put another way, nodes can send packets which > appear to leave the scope of the unicast address, since a packet > received > can have a link-local source address from a separate logical link. > This violates the Addressing Architecture RFC. I think I see the problem. Yes, this is serious for the co-existence functionality. Thanks for noting this. > If there is some way of fixing this, ensuring that even link-scoped > multicast groups are disjoint, then I believe the reason to have > a separate solicited-node range completely goes away, and the > protocol > becomes much simpler. Hmm... to me, it seems rather hard to invent a way to have disjoint multicast groups. Sending to a multicast destination does not appear to require any ND operations, so its hard to see how SEND could intervene and assign different addresses. But I'm not a multicast expert, so perhaps you have some ideas? Maybe a new link-local multicast address range? But what would be the impacts of that. In any case, if you look at draft-arkko-send-ndopt-00.txt (to appear, see http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndopt.txt) there's a very different co-existence mode. Basically, I gave up with the two-logical link approach and simply added application-level policies for deciding when SEND-nodes can accept plain ND, and plain ND nodes always accept all SEND messages. I think this would solve your problem as well. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 20 07:37:16 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26761 for ; Fri, 20 Jun 2003 07:37:15 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5KBZBw2015973; Fri, 20 Jun 2003 13:35:11 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQW4XP; Fri, 20 Jun 2003 13:36:46 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5KBZ7sY019578; Fri, 20 Jun 2003 13:35:07 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5KBYdme016796; Fri, 20 Jun 2003 13:34:39 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5KBYcsx016795; Fri, 20 Jun 2003 13:34:38 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5KBYbme016791 for ; Fri, 20 Jun 2003 13:34:37 +0200 (MET DST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26183; Fri, 20 Jun 2003 07:34:35 -0400 (EDT) Message-Id: <200306201134.HAA26183@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-send@standards.ericsson.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-arkko-send-ndopt-00.txt Date: Fri, 20 Jun 2003 07:34:35 -0400 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SEcure Neighbor Discovery (SEND) Author(s) : J. Arkko Filename : draft-arkko-send-ndopt-00.txt Pages : 56 Date : 2003-6-19 IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other nodes on the link, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. If not secured, ND protocol is vulnerable to various attacks. This document specifies security mechanisms for ND. Contrary to the original ND specifications, these mechanisms do not make use of IPsec. The purpose of this draft is to present an alternative to the current approach in the Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arkko-send-ndopt-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-arkko-send-ndopt-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-arkko-send-ndopt-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19154230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-arkko-send-ndopt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-arkko-send-ndopt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154230.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jun 21 01:06:32 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19975 for ; Sat, 21 Jun 2003 01:06:32 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5L54rcv017480; Sat, 21 Jun 2003 07:04:54 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGL8245; Sat, 21 Jun 2003 07:03:57 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5L53usY007041; Sat, 21 Jun 2003 07:03:56 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5L536me012903; Sat, 21 Jun 2003 07:03:06 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5L536Ku012899; Sat, 21 Jun 2003 07:03:06 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from emztd2571.com (80.179.101.203.forward.012.net.il [80.179.101.203]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5L52wme012871 for ; Sat, 21 Jun 2003 07:03:02 +0200 (MET DST) Message-Id: <200306210503.h5L52wme012871@sw.ericsson.se> From: "PRINCESS GRACE ABONIME" Reply-To: graceabonime111@netscape.net To: ietf-send@standards.ericsson.net Date: Sat, 21 Jun 2003 06:02:58 +0100 Subject: URGENT ASSISTANCE X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5L535me012889 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id h5L53usY007041 Content-Transfer-Encoding: quoted-printable The Palace of King of Ogoni Kingdom, Ogoni Oil producing community, Rivers State Nigeria. Dear Sir, I am Princess Grace , daughter of HRH King Solomon Abonime, the king of Ogoni Kingdom. I am 25 years old and a graduate of Mass Communication. My father was the king of Ogoni Kingdom the highest oil producing area in Nigeria. He was in charge of reviving royalties from the multi-national oil companies and government on behalf of the oil producing communities in Nigeria. After the hanging of the Ogoni Nine(9) including Ken Saro Wiwa by the late dictator General Sani Abacha, my father suffered stroke and died in August27th last year. But before his death, he called me and told me he has Nine Million Five hundred and= sixty thousand Dollars (USD9,560,000.00) cash in his possession, specially deposited in a Security vault company here. He advised me not to tell anybody except my mother who is the last wife of the (8) eight wives that he married. My mother did not bear any male child for him. Which implies that all my father=92s properties, companies e.t.c., we have no share in them because my mother has no male child according to African Tradition. My father therefore secretly gave me all the relevant documents of the said money, and told me that I should use this money with my mother and my younger sisters because he knows that tradtionally, if he dies we cannnot get anything, as inheritance. He importantly advised me that I should seek foreign assistannce and that I should not invest this money here in Nigeria because of his other wives and male children who happen to be my elders. I am soliciting for your immediate assistance to get a Bungalow for us, where I will live with my mother and two younger sisters and further advise me where and how I will invest the balance money overseas, possibly on products of your company and other profitable ventures. I believe that by the special grace of God, you will help us move this money out of Nigeria to any country of your choice where we can invest this money judiciously with you. You are entitled to a reasonable part of this money based on our agreement, and God will bless you as you help us. PLease i needed you to kindly send me your office phone and fax number in= cluding your cell phone where io can reach you at all timer for oral comm= unication regards to further development of this transaction. Looking forward to hear from you as soon as possible. Regards. Princess Grace Abonime=20 -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jun 21 15:47:25 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14447 for ; Sat, 21 Jun 2003 15:47:25 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5LJiTw2010221; Sat, 21 Jun 2003 21:44:30 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP9NFC7; Sat, 21 Jun 2003 21:45:06 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5LJiDsY016658; Sat, 21 Jun 2003 21:44:14 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5LJh2me021551; Sat, 21 Jun 2003 21:43:02 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5LJh2Ah021550; Sat, 21 Jun 2003 21:43:02 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from onmo3223.com ([217.78.79.176]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5LJgume021541 for ; Sat, 21 Jun 2003 21:42:59 +0200 (MET DST) Message-Id: <200306211942.h5LJgume021541@sw.ericsson.se> From: "Sigidi Ayize" Reply-To: sigidi_ayize@epatra.com To: ietf-send@standards.ericsson.net Date: Sat, 21 Jun 2003 20:44:01 -0700 Subject: Hi....(Urgent) X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5LJh1me021547 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit I write to inform you of my desire to acquire estates or landed properties in your country on behalf of the Director of Contract and Finance Allocations of the Department of Transportation in South Africa. Considering his very strategic and influential position, he wants the transaction to be strictly confidential as much as possible. He further wants his identity to remain undisclosed at least for now, until the completion of transaction. Hence our desire to have an overseas agent. I have therefore been directed to inquire if you would agree to act as our overseas agent in order to actualize this transaction. The deal in brief is that the funds with which we intend to carry out our proposed investments in your country is presently in a coded account at the South Africa Apex bank (South Africa Reserve Bank) and we need your assistance to transfer the funds to your country in a convenient bank account that will be provided by you before we can put the funds into use in your country. For this, you shall be considered to have executed a contract for the Department of Transportation for which payment should be effected to you by Department, The contract sum of which shall run into US$30.5Million (Thirty Million, Five Hundred Dollars) of which your share shall be 20% if you agree to be our overseas agent. As soon as payment is effected, and the amount mentioned above is successfully transfered into your account, we intend to use our own share in acquiring some estates and setting up trust accounts abroad. For this too you shall also serve as our agent. In the light of the above, I would like you to forward to me the following information's: 1. Your company name and address if any. 2. Your personal fax number. 3. Your personal telephone number for easy communication. You are requested to communicate your accpetance of this proposal through this email. After which we shall discuss in details the modalities for seeing this transaction through. Your quick response will be highly appreciate. Thanks in anticipation of your cooperation. Yours faithfully, SIGIDI AYIZE -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jun 23 13:06:08 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29035 for ; Mon, 23 Jun 2003 13:06:07 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5NH06G5007581; Mon, 23 Jun 2003 19:00:06 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGMFXJH; Mon, 23 Jun 2003 19:00:06 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5NH05N03302; Mon, 23 Jun 2003 19:00:05 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5NGxIme007767; Mon, 23 Jun 2003 18:59:18 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5NGxIha007766; Mon, 23 Jun 2003 18:59:18 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5NGxGme007762 for ; Mon, 23 Jun 2003 18:59:16 +0200 (MET DST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5NGpOD9013565; Mon, 23 Jun 2003 12:51:24 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3EF01165.1040906@nomadiclab.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF01165.1040906@nomadiclab.com> Date: Mon, 23 Jun 2003 12:52:52 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) Cc: Tero Kivinen , ipsec@lists.tislabs.com, SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk At 10:14 AM +0300 6/18/03, Pekka Nikander wrote: >Steve and Tero, > >[Taking my SEND WG chair hat firmly *off*, i.e., speaking for > myself only.] > >Stephen Kent wrote: >>Until SEND has a comprehensive, coherent model for using AH that does >>not require changes to other parts of IPsec processing, ... > >With all respect, I sincerely believe that SEND will never come up >with "a comprehensive, coherent model for using AH that does >not require changes to other parts of IPsec processing". More on that >below. If you disagree, please try to come up with a scheme where >you use AH when you > > - don't have any IP addresses (i.e. during IPv6 DAD) > > - do not know in which network you are (public access) > > - do not trust most nodes in the network (public access) > - and are still trying to figure out what node(s) to trust, > how much, and in which respects > > - do not know which of the potentially many trust roots you > should use to establish trust with the possibly existing > trusted nodes in the otherwise untrusted network > > - want to operate, at a lower level of security, when you > are unable to establish pre-configured trust with anyone > > - want to make this all *effectively*, without using zillions > of messges, since you potentially have to do this each time > you roam to a different IP network I don't disagree that SEND has a number of security constraints with which it must deal. However, AH was not designed to address this set of constraints and thus trying to twist AH to meet the needs of SEND is inappropriate. >I still claim that there are situations where the integrity and >data origin authentication of the IP header is important. >Hence, I firmly believe that the text concerning the relationship >between AH and ESP is misleading at best and perhaps even outright >wrong. Using tunnel mode is not an answer, at least sometimes. The IPsec WG does not seem to share this view, based on previous, extensive discussions. We rarely have circumstances where AH makes more sense than ESP in either tunnel or transport mode. And, there is a strong desire in the WG to simplify the IPsec specs, which runs counter to your suggestion. > >>>- In the current SEND WG proposal, the SA does not indicate the key >>> to be used. Instead, the AH header itself contains the public >>>key. .... >>> >>This is not consistent with the IPsec specs! > >Actually I more or less agree with you, Steve! Indeed, that is >one of the reasons why I am proposing changes to the current AH >usage in SEND, basically moving the public key from the AH header >to a separate extension header, to be placed before the AH header. >(See the separate discussion at the SEND WG ML.) There is NO public key in the AH header. There is a place for an ICV. >>In IPsec, the SAD entry for an SA stores the keys that are employed >>to process packets. In turn, the SAD entry is located by using the >>SPI from an inbound packet (for unicast traffic). > >I am very very well aware of that. I quite well remember what >I learned while I implemented one of the early BITS IPsec stacks >as a part of my PhD work back in 1994-1995. > >However, sometimes the SPI alone is not very useful, and sometimes >using the destination address as a selector is not the right choice. >(More on this on the separate thread.) I don't think this WG has identified a set of contexts in which the current SA selection mechanisms are not sufficient. We made some changes to accommodate MSEc requirements, but it's very late in the process to assert that there needs to be fundamental changes to this mechanism. >>If SEND wants to use AH then you need to use the protocol (including >>the processing spec) as defined in IPsec, not just the syntax from >>2402. Suggesting that we change AH to accommodate SEND's possible use >>of it, in a fashion not consistent with the current specs, is asking >>quite a lot. > >I agree. Actually, using the revised suggestion of moving the >public key from the AH header to a separate extension header, >thereby creating an "implicit" or "inline" one message KMP, >seems to simplify issue. However, even in that case it >would really make sense to perform SA selection based on the >source address. However, I defer that discussion to the other >thread. As noted above, there was NEVER a provision to carry ANY key in the AH header, so this whole thread seem rather odd to me. >Tero Kivinen wrote: >>The SEND is a user of the AH. ... Do we want to say to our >>(only?) user that no we do not allow you to do anything differently? > >As Itojun pointed out (and Steve well knows), SEND is indeed not >the only user of AH. Anyway, thanks for your supporting words. > >We should also remember that RFC2461/2462 explicitly states that >AH is the method to be used for protecting IPv6 ND. That is, in fact, >quite doable if you have a static environment with pre-configured >security associations, PK based or symmetric. However, once you >want to use AH in the public access environment, things get harder. >See the outline above. The RFC numbers cited above obviously refer to specs issued after the IPsec specs were published. I don't think the IPsec WG can be responsible for what other WGs may choose to say about how to use the protocols developed here, but I think it fair to say that maybe someone made an assertion without thinking it through. >>Do we want them to create another protocol replacing their use of AH? > >This is the very question. There are lots of folks at the >SEND WG who believe so. That is, they believe that AH should >not be used for securing IPv6 ND, and a separate protocol should >be developed instead. I'm all in favor of that, if the alternative is to make the sort of changes you suggest to AH, to accommodate SEND requirements. >>Another people who have been saying that they want to use AH is >>Mobile IP people. What do they want? Is the current spec fine with >>them or do the want similar processing than SEND? > >Having been there too (though recently not very actively), I strongly >suspect that some of the MIPv6 requirements will be fairly similar >to those of SEND. Both deal with IP address mappings, MIP with >IP -> IP mappings and ND with IP -> lladdr mappings. We have had interactions with folks about mobile IPv6 and its uses of IPsec. A previous version of the ID was held up in the IESG because it seemed to suggest changes to IPsec that had not been agreed to by this WG. Steve -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 24 11:24:11 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20281 for ; Tue, 24 Jun 2003 11:24:09 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5OFLjw2019863; Tue, 24 Jun 2003 17:21:45 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYR2KHX; Tue, 24 Jun 2003 17:23:33 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5OFLhsY015991; Tue, 24 Jun 2003 17:21:43 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5OFL7me015652; Tue, 24 Jun 2003 17:21:07 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5OFL7T4015651; Tue, 24 Jun 2003 17:21:07 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5OFL5me015647 for ; Tue, 24 Jun 2003 17:21:06 +0200 (MET DST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 24 Jun 2003 08:21:04 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Jun 2003 08:21:04 -0700 Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Jun 2003 08:21:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: SEND+ND mixed mode (instead of ND to SEND transition) Date: Tue, 24 Jun 2003 08:18:52 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F09678103@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: SEND+ND mixed mode (instead of ND to SEND transition) Thread-Index: AcM3zWm/qBu5ABwFQHuvk7XInlBf7wBfEQ5gAEWsyzA= From: "Tuomas Aura" To: X-OriginalArrivalTime: 24 Jun 2003 15:21:04.0022 (UTC) FILETIME=[39F84B60:01C33A64] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5OFL6me015648 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit This is a proposal for a new, simpler transition mechanism. (Thanks to Jari Arkko and Dave Thaler for input.) It is unnecessary to have a separate transition mode. SEND hosts are likely to always encounter networks with nodes and routers that do not support SEND. They may also be connected at the same time to multiple networks and routers, some of which are secure and some insecure. Thus, a mixed mode with both secure and insecure hosts and routers on the same network should be the default mode for SEND hosts. SEND nodes should be able to fall back to insecure ND when communicating with insecure on-link nodes. Also, routers should be able to serve both SEND hosts and insecure hosts. The key to implementing the mixed default mode is that SEND nodes receive both secure and insecure ND and RD messages but give priority to secure ones. "Secure" messages are ones that contain a valid signature option, and "insecure" messages are ones that contain no signature option. SEND nodes need to send only secure messages. ND nodes obviously will send only insecure messages. ND nodes will (per RFC 2461) ignore the unknown options and will treat secure messages in the same way as they treat insecure ones. Addresses, subnet prefixes, interfaces. networks are not divided to "secure" and "insecure". SEND routers and hosts follow the protocols defined in RFC 2461 and RFC 2462 with the following exceptions: - All solicitations sent by as SEND node SHOULD be secure. - Unsolicited Neighbor and Router Advertisements sent by a SEND router SHOULD be secure. Solicited advertisements MUST be secure if the solicitation was secure, and SHOULD be secure if the solicitation was insecure. - Secure solicitations MUST contain the Nonce option. Secure advertisements sent in response to a secure solicitation MUST contain a copy of the Nonce option from the solicitation. Unsolicited advertisements and ones sent in response to an insecure solicitation MUST NOT contain the Nonce option. - A SEND node that uses the CGA the authorization mechanism for protecting Neighbor Solicitations SHOULD perform Duplicate Address Detection (DAD) as follows. If DAD indicates the tentative address is already in use, generate a new tentative CGA address. If after 3 consecutive attempts no non-unique address was generated, log a system error and give up attempting to generate an address for that interface. When performing DAD for the first tentative address, accept both secure and insecure Neighbor Advertisements received as response to the Neighbor Solicitations. When performing DAD for the second or third tentative address, ignore insecure Neighbor Advertisements. - The node SHOULD have a configuration option that causes it to ignore insecure advertisements even when performing DAD for the first tentative address. This configuration option SHOULD be disabled by default. (This is recovery mechanism for the unlikely case that attacks against the first address become common.) - Neighbor Cache, Prefix List and Default Router list entries have a secure/insecure flag that indicates whether the message that caused the creation or last update of the entry was secure or insecure. Received insecure messages MUST NOT cause changes to existing secure entries in the Neighbor Cache, Prefix List or Default Router List. Received secure messages cause an update of the matching entries and flagging of them as secure. - The conceptual sending algorithm is modified so that an insecure router is selected only if there is no reachable secure router for the prefix. That is, the algorithm for selecting a default router favors reachable secure routers over reachable insecure ones. - A SEND node MAY have a configuration option that causes it to ignore all insecure ND, RD and Redirect messages. (This can be used to enforce SEND-only networks.) The mixed default mode should make transition much easier as it allows gradual transition and it is not necessary to phase out insecure equipment, such as printers. There does not seem to be any particular disadvantages to the default mixed mode. As far as I know, the decision to not allow mixed operation in the current SEND main draft was made solely because of the desire to live with the limitations of IPSec. It is straightforward to implement the mixed mode in Jari's ND-option-based protocol. It might be possible to implement the mixed mode with the CGA+AH headers and IPSec API changes proposed by Pekka Nikander. The key point here is we must not end up with an inferior transition mechanism (as in the current main draft) just because IPSec does not support anything better. Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jun 24 23:55:17 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05125 for ; Tue, 24 Jun 2003 23:55:01 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5OITEG5003556; Tue, 24 Jun 2003 20:29:14 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGJH3DQ; Tue, 24 Jun 2003 20:31:29 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5OITAsY019985; Tue, 24 Jun 2003 20:29:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5OISZme008724; Tue, 24 Jun 2003 20:28:35 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5OISZ0G008723; Tue, 24 Jun 2003 20:28:35 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from globalgiftware.net ([202.103.180.83]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5OISIme008705; Tue, 24 Jun 2003 20:28:24 +0200 (MET DST) Message-ID: Reply-To: ceowoqp@globalgiftware.net From: ceowoqp@globalgiftware.net To: AOL@standards.ericsson.net, Users@standards.ericsson.net Subject: Toner Date: Wed, 25 Jun 2003 04:50:07 +1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_26C_9D6F_B281C2BA.9E368778" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_26C_9D6F_B281C2BA.9E368778 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_26C_9D6F_B281C2BA.9E368778 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable GT TONER SUPPLIES Laser printer and computer supplies 1

GTTO= NER SUPPLIES
Laser printer and computer supplies
1-888-662-2256
1-866-237-7397


Dont= Miss it!

Save up to = 40% from retail price on laser printer toner cartridges,
copier and fax cartridges.

Hp-Canon-Lexmark-Epson-Panasonic-Apple-Xerox

Order by phone

1-866-237-7397 or  1-888-662-2256<= font face=3D"Times New Roman" color=3D"#808000">

Order by e-mail: 

gt1000@cable.net.co=

E-mail remo= val:

gt1000@cable.net.co=

 

University and/or School purchase orders WELCOME. = ;

= WE ACCEPT ALL MAJOR CREDIT CARDS!

Our cartridge prices are as follows:
(please order by item number)

> =
Item

HP

Price
1 9= 2274A Toner Cartridge for LaserJet 4L, 4ML, 4P, 4MP $47= 50
2 C= 4092A Black Toner Cartridge for LaserJet 1100A, ASE, 3200SE $45= 50
2A C= 7115A Toner Cartridge For HP LaserJet 1000, 1200, 3330 $55= 50
2B C= 7115X High Capacity Toner Cartridge for HP LaserJet 1000, 1200, 3330 $65= 50
3 9= 2295A Toner Cartridge for LaserJet II, IID, III, IIID $49= 50
4 9= 2275A Toner Cartridge for LaserJet IIP, IIP+, IIIP $55= 50
5 C= 3903A Toner Cartridge for LaserJet 5P, 5MP, 6P, 6Pse, 6MP, 6Pxi $46= 50
6 C= 3909A Toner Cartridge for LaserJet 5Si, 5SiMX, 5Si Copier, 8000 $92= 50
7 C= 4096A Toner Cartridge for LaserJet 2100, 2200DSE, 2200DTN $72= 50
8 C= 4182X UltraPrecise High Capacity Toner Cartridge for LaserJet 8100 Series= $12= 5.50
9 C= 3906A Toner Cartridge for LaserJet 5L, 5L Xtra, 6Lse, 6L, 6Lxi, 3100se <= /td> $42= 50
9A C= 3906A Toner Cartridge for LaserJet 3100, 3150 $42= 50
10 C= 3900A Black Toner Cartridge for HP LaserJet 4MV, 4V $89= 50
11 C= 4127A Black Toner Cartridge for LaserJet 4000SE, 4000N, 4000T, 4000TN $76= 50
11A C= 8061A Black Laser Toner for HP LaserJet 4100, 4100N $76= 50
11B C= 8061X High Capacity Toner Cartridge for LJ4100, 4100N $85= 50
11C C= 4127X High Capacity Black Cartridge for LaserJet 4000SE,4000N,4000T,4000TN $84= 50
12 9= 2291A Toner Cartridge for LaserJet IIISi, 4Si, 4SiMX $57= 50
13 9= 2298A Toner Cartridge for LaserJet 4, 4 Plus, 4M, 4M Plus, 5, 5se, 5M, 5N $46= 50
14 C= 4129X High Capacity Black Toner Cartridge for LaserJet 5000N $97= 50
15 L= ASERFAX 500, 700 (FX1) $49= 00
16 L= ASERFAX 5000, 7000 (FX2) $54= 00
17 L= ASERFAX (FX3) $49= 00
18 L= ASERFAX (FX4) $49= 00
Item

HP COLOR=

Price
C1 C= 4194a Toner Cartridge, Yellow (color lj 4500/4550 series) $89= 50
C2 C= 4193a Toner Cartridge, Magenta (color lj 4500/4550 series)

LEXMARK

Price
19 1= 380520 High Yield Black Laser Toner for 4019, 4019E, 4028, 4029, 6, 10, 10L $10= 9.50
20 1= 382150 High Yield Toner for 3112, 3116, 4039-10+, 4049- Model 12L,16R, Optra <= /td> $10= 9.50
S= 051009 Toner Cartridge for Epson EPL7000, 7500, 8000+ $11= 5.50
25A S= 051009 LP-3000 PS 7000 $11= 5.50
26 A= S051011 Imaging Cartridge for ActionLaser-1000, 1500 $99= 50
26A A= S051011 EPL-5000, EPL-5100, EPL-5200 $99= 50
Item

PANASONIC

Price
27 N= ec series 2 models 90 and 95
 		 $10= 9.50
Item

APPLE

Price
28 2= 473G/A Laser Toner for LaserWriter Pro 600, 630, LaserWriter 16/600 PS
 		 $57= 50
29 1= 960G/A Laser Toner for Apple LaserWriter Select, 300, 310, 360 $71= 50
30 M= 2045G/A Toner Cartridge for Laserwriter 300, 320 (74A) $52= 50
31 M= 6002 Toner Cartridge for Laserwriter IINT, IINTX, IISC, IIF, IIG (95A) = $47= 50
31A M= 0089LL/A Toner Cartridge for Laserwriter LS, NT, NTR, SC (75A) $55= 50
32 M= 4683G/A Laser Toner for LaserWriter 12, 640PS $85= 50
Item

CANON

Price
33 F= ax CFX-L3500, CFX-4000 CFX-L4500, CFX-L4500IE & IF FX3 $49= 50
33A L= -250, L-260i, L-300 FX3 $49= 50
33B L= ASER CLASS 2060, 2060P, 4000 FX3  $49= 50
34 L= ASER CLASS 5000, 5500, 7000, 7100, 7500, 6000 FX2 $49= 50
34A L= BP-200V, LBP-8 II, IIR, IIIT, IIIR EP-S $49= 50
35 F= AX 5000 FX2  $49= 50
36 L= ASER CLASS 8500, 9000, 9000L, 9000MS, 9500, 9500 MS, 9500 S FX4  $49= 50
36A F= ax L700,720,760,770,775,777,780,785,790, & L3300 FX1 $49= 50
36B L= -800, L-900 FX4 $49= 50
37 A= 30R Toner Cartridge for PC-6, 6RE, 7, 11, 12 $59= 50
38 E= -40 Toner Cartridge for PC-720, 740, 770, 790,795, 920, 950, 980 $85= 50
38A E= -20 Toner Cartridge for PC-310, 325, 330, 330L, 400, 420, 430 $85= 50
Item

XEROX

Price
39 6= R900 75A $55= 50
40 6= R903 98A $42= 50
44 6= R899 74A $47= 50
45 6= R928 96A $72= 50
46 6= R926 27X $8Customer  Satisfaction guaranteed !

If you are ordering by e-mail or c.o.d. please fill out an order
form with the following information:  = ;         

= phone number
company name
first and last name
street address
city, state zip code        


If you are ordering b= y purchase order please fill out an order form
with the following information:       &nb= sp;   

purchase or= der number
phone number
company or school name
shipping address and billing address
city, state zip code        

Order Now

1-866-237-7397 or&nbs= p; 1-888-662-2256<= font face=3D"Times New Roman" color=3D"#808000">

All trade marks and brand names listed above are property of the respec= tive
holders and used for descriptive purposes only.

To view our acrobat catologe click here

------=_NextPart_26C_9D6F_B281C2BA.9E368778-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 25 02:00:44 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07311 for ; Wed, 25 Jun 2003 02:00:44 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5P5vlG5011302; Wed, 25 Jun 2003 07:57:47 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYRLTSW; Wed, 25 Jun 2003 07:59:37 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5P5vjsY000757; Wed, 25 Jun 2003 07:57:45 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5P5vDme018458; Wed, 25 Jun 2003 07:57:13 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5P5vD3F018457; Wed, 25 Jun 2003 07:57:13 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from sina.com.cn ([218.19.0.105]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5P5v4mf018447 for ; Wed, 25 Jun 2003 07:57:09 +0200 (MET DST) Message-Id: <200306250557.h5P5v4mf018447@sw.ericsson.se> From: =?GB2312?B?s8LWx8H6?= <777man@sina.com.cn> Subject: =?GB2312?B?z/LE+s3GvPbSu7/uuN/Q1Lzbsci1xLfAu/DHvaOos8LWx8H6o6k=?= To: ietf-send@standards.ericsson.net Content-Type: text/plain;charset="GB2312" Reply-To: 777man@sina.com.cn Date: Wed, 25 Jun 2003 13:57:01 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2615.200 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk ÄúºÃ! ·Ç³£¸ßÐËÄܹ»ÓëÄúÁªÏµ, ÎҽгÂÖÇÁú£¬Ö÷Òª´ÓÊÂÍøÂ簲ȫµÄ²úÆ·ÏúÊÛ¹¤×÷£¬ÎÒ´ÓһλÅóÓÑ´¦µÃÖªÄúµÄE-MAIL µØÖ·£¬²¢ÇÒ±»¸æÖªÄú¶ÔÍøÂ簲ȫ·Ç³£¸ÐÐËȤ£¬ËùÒÔðÃÁµØ¸øÄãдÕâ·âÐÅ£¬Èç¹ûÕâ·âПøÄú´øÀ´²»±ã£¬»¹ÇëÔ­Á£¡ ÎÒÏÖÔÚ¸øÄúÍƼöÒ»¸öеÄÆ·ÅƵķÀ»ðǽ²úÆ·£¬¾ÍÊÇÀ´×Ô¹úºãÁªºÏµÄËÙͨ·À»ðǽ£¬±±¾©¹úºãÁªºÏ¿Æ¼¼ÓÐÏÞ¹«Ë¾³ÉÁ¢ÓÚ2002Äê12Ô£¬ÊDZ±¾©¹úºã¼¯ÍŹ«Ë¾ÏÂÊôµÄ¸ßм¼ÊõÆóÒµ¡£¹«Ë¾Á¢×ã¹úÄÚÊг¡£¬µ÷ÑÐÕþ¸®¡¢µçÐÅ¡¢½ðÈÚ¡¢ÖÐСÆóÒµµÈ¸÷ÀàÓû§ÍøÂ簲ȫÐèÇóÌص㣬ÒÔ×ÔÓм¼Êõ×ÔÐпª·¢ÍøÂ簲ȫ²úÆ·£¬ÍƳöÊʺÏÉÏÊöÓû§ÐèÇóµÄ²úÆ·ºÍ½â¾ö·½°¸£¬ÌṩÓÐЧµÄ°²È«·þÎñ¡£Í¬Ê±ÎÒÃÇ»á¸ù¾ÝÊг¡ÐèÇóÌصãÊÊʱÍƳö¸ü¾ß¾ºÕùÁ¦µÄÆäËû°²È«²úÆ·¡£ Ä¿Ç°ÒÑÔÚÊг¡³É¹¦ÍƳöµÄ²úÆ·ÓйúºãËÙͨϵÁзÀ»ðǽ£¬¹²·ÖAºÍB ϵÁУ¬ÆäÖÐAϵÁÐÖ÷ÒªÕë¶Ô´óÖÐÐÍÆóÒµÒÔ¼°µçÐż¶ÆóÒµ£¬¶øBϵÁзÀ»ðǽÖ÷ÒªÕë¶ÔÖÐСÐÍÆóÒµ£¬ËäÈ»BϵÁзÀ»ðǽÖ÷Òª¿Í»§Ä¿±êËø¶¨ÔÚÖÐСÐÍÆóÒµ£¬µ«ÊÇËûµÄÐÔÄÜÓëÄ¿Ç°Êг¡ÉϵİÙÕ×ÏßËÙÏà±ÈÈ´Ò»µãÒ²²»Ñ·É«£¬Ëü³ýÁ˲»Ö§³ÖVLAN£¬Á÷Á¿¼Æ·Ñ£¬×¨ÓüÓÃÜÓ²¼þºÍ¸ºÔؾùºâÍ⣬ÆäËû·À»ðǽµÄ¹¦Äܶ¼Ö§³Ö£¬±ÈÈçÖ§³Ö͸Ã÷ºÍ·ÓÉģʽ£¬Ö§³ÖIP/MAC°ó¶¨£¬Ö§³ÖÓëÈëÇÖ¼ì²âµÄÁª¶¯£¬Ö§³ÖVPNÍø¹ØµÈ£¬ÁíÍâËü»¹¾ßÓÐÓÅÔ½µÄÐԼ۱ȣ¬B100-3·À»ðǽ֧³Ö100Õ×´ø¿í£¬×î´ó²¢·¢Á¬½ÓÊý´ïµ½5Íò¸ö£¬×î¼Ñ״̬ʱÓû§¿É´ïµ½100¸ö£¬¶øÕâÑùÒ»¿îÐÔÄÜÓÅÔ½µÄ·À»ðǽÏÖÔÚµÄÇþµÀ¼Û¸ñÖ»ÓÐ8600ÔªÈËÃñ±Ò£¬ÏàÐÅÄúÒ»¶¨ÓÐÐËȤ¡£ ÎÒÃÇÏàÐÅͨ¹ý±±¾©¹úºãÁªºÏ¿Æ¼¼ÓÐÏÞ¹«Ë¾ºÍÄúµÄ¹²Í¬Å¬Á¦£¬¶ÔÓÚ¹úºãËÙͨ·À»ðǽ²úÆ·µÄÊг¡¸²¸ÇÃæ¡¢Êг¡Õ¼ÓÐÂʽ«»á´øÀ´·ÉËÙµÄÔö³¤ºÍÏÔÖøÌá¸ß¡£ÎÒÃÇÒ²³ä·ÖÐÅÈÎÄú¶ÔÓÚÄúËùÔÚÇøÓòµÄÊг¡¿ªÍØÄÜÁ¦ºÍ²úÆ·ÇþµÀÏúÊÛÄÜÁ¦¡£ Ôڹ㷺ºÏ×÷ºÍË«Ó®Ô­Ôò»ù´¡ÉÏ£¬ÎÒÃÇΪ´úÀíÉ̽¨Á¢ÁËÈ«·½Î»µÄÅàѵ֧³ÖºÍ¼¼Êõ·þÎñÖ§³Ö£¬Í¬Ê±¿¼Âǵ½°²È«²úÆ·µÄÌصãÎÒÃÇÍƳöÁ˼«¾ßÓÅÊƵÄÊг¡ÍƹãÖ§³ÖºÍ½â¾ö·½°¸Ö§³ÖµÈ£¬ÖÔÐĵػ¶Ó­Äú¼ÓÈë¹úºãËÙͨ´úÀíÉÌ´ó¼ÒÍ¥£¬ÄúµÄ¼ÓÃ˽«ÎªÎÒÃÇÔöÌíÁËеĻîÁ¦ºÍÉú»ú£¬ÈÃÎÒÃÇЯÊÖ²¢½ø£¬¹²´´ÃÀºÃδÀ´¡£ ÖÔÐÄÏ£ÍûÎÒÃǽ«À´Äܹ»Óлú»áºÏ×÷,ÄúÈç¹û¶Ô¼¼ÊõÉÏÓÐʲôÒÉÎÊ»ò»¹¶Ô²úÆ·½øÐÐÉîÈëµÄÁ˽⣬¿ÉÒÔÖµçÎÒÃÇ020-87564813»òÖ±½Ó·ÃÎÊÎÒ¹«Ë¾µÄÍøÕ¾: www.goldenhope.com.cn ,ÎÒ¶ÔÓÚÇþµÀÕþ²ßµÄÒÉÎÊ¿ÉÒÔÖ±½ÓÓëÎÒÁªÏµ13822194195 ²¢×£ ¹¤×÷Óä¿ì,ÉíÌ彡¿µ! ______________________________________ ÍøÂçÐèÒª±£»¤£¬ÎÒÀ´ÎªÄú±£ÕÏ£¡ ±±¾©¹úºãÁªºÏ¿Æ¼¼ÓÐÏÞ¹«Ë¾¹ãÖÝ°ìÊ´¦ ÍøÂ簲ȫ²úÆ·¸ºÔðÈË ³ÂÖÇÁú ¹ãÖÝÊÐÌìºÓÇøÖÐɽ´óµÀ20ºÅÃ÷Ðù´óÏÃB×ù2109 Tel:020-87564813 Fax:020-87564813ת ÊÖ»ú:13822194195 www.goldenhope.com.cn E-MAIL: 777man@sina.com.cn -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 25 05:27:30 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05496 for ; Wed, 25 Jun 2003 05:27:30 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5P9QVcv009950; Wed, 25 Jun 2003 11:26:31 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYRNPG0; Wed, 25 Jun 2003 11:27:22 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5P9PTsY006152; Wed, 25 Jun 2003 11:25:29 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5P9Otme016718; Wed, 25 Jun 2003 11:24:55 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5P9OtA1016717; Wed, 25 Jun 2003 11:24:55 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5P9Orme016707 for ; Wed, 25 Jun 2003 11:24:53 +0200 (MET DST) Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5P9Oqvc007666 for ; Wed, 25 Jun 2003 03:24:52 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HH10084365FZJ@edgemail1.Central.Sun.COM> for ietf-send@standards.ericsson.net; Wed, 25 Jun 2003 03:24:52 -0600 (MDT) Received: from gbl-dhcp-198-240.europe.research.sun.com ([194.2.198.240]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HH100FQG65D93@mail.sun.net> for ietf-send@standards.ericsson.net; Wed, 25 Jun 2003 03:24:51 -0600 (MDT) Date: Wed, 25 Jun 2003 11:24:43 +0200 From: Julien Laganier Subject: Re: SEND+ND mixed mode (instead of ND to SEND transition) In-reply-to: <9805B5E65CD0D0479D08B7EB832B369F09678103@red-msg-08.redmond.corp.microsoft.com> To: Tuomas Aura , ietf-send@standards.ericsson.net Message-id: <200306251124.43824.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline User-Agent: KMail/1.5.2 References: <9805B5E65CD0D0479D08B7EB832B369F09678103@red-msg-08.redmond.corp.microsoft.com> X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5P9Osme016714 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id h5P9PTsY006152 Content-Transfer-Encoding: quoted-printable Le Mardi 24 Juin 2003 17:18, Tuomas Aura a =E9crit : > This is a proposal for a new, simpler transition mechanism. > (Thanks to Jari Arkko and Dave Thaler for input.) > > It is unnecessary to have a separate transition mode. SEND > hosts are likely to always encounter networks with nodes > and routers that do not support SEND. They may also be > connected at the same time to multiple networks and routers, > some of which are secure and some insecure. Thus, a mixed > mode with both secure and insecure hosts and routers on the > same network should be the default mode for SEND hosts. > SEND nodes should be able to fall back to insecure ND when > communicating with insecure on-link nodes. Also, routers > should be able to serve both SEND hosts and insecure hosts. > > The key to implementing the mixed default mode is that > SEND nodes receive both secure and insecure ND and RD > messages but give priority to secure ones. "Secure" messages > are ones that contain a valid signature option, and > "insecure" messages are ones that contain no signature > option. I like the idea of a default mixed mode for SEND. Sounds straightforward = to=20 deploy. > As far as I know, the decision to not allow mixed operation > in the current SEND main draft was made solely because of > the desire to live with the limitations of IPSec. It is > straightforward to implement the mixed mode in Jari's > ND-option-based protocol. > > It might be possible to implement the mixed mode with the > CGA+AH headers and IPSec API changes proposed by Pekka > Nikander. The key point here is we must not end up with an > inferior transition mechanism (as in the current main draft) > just because IPSec does not support anything better. Some IPsec implementations have a SPD allowing to specify that some traff= ic=20 MAY use IPsec (KAME does that, you can specify 'require' or 'use' for an = SPD=20 entry). In this case, an incoming packet can be processed by the IPsec la= yer=20 if it is secured via AH and/or ESP, or just bypass the IPsec layer if it = is=20 not secured.=20 On implementation of this type it should not be a problem to implement mi= xed=20 mode SEND. At the opposite It looks difficult to implement this on a=20 _standard_ IPsec layer. Thanks, --julien -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 25 05:34:00 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05579 for ; Wed, 25 Jun 2003 05:34:00 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5P9Utw2015774; Wed, 25 Jun 2003 11:30:56 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP0CR09; Wed, 25 Jun 2003 11:30:45 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5P9UssY006307; Wed, 25 Jun 2003 11:30:54 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5P9Ulme018029; Wed, 25 Jun 2003 11:30:47 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5P9UlVe018028; Wed, 25 Jun 2003 11:30:47 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5P9Uime018021 for ; Wed, 25 Jun 2003 11:30:45 +0200 (MET DST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 71E849A; Wed, 25 Jun 2003 18:30:41 +0900 (JST) To: Julien Laganier Cc: Tuomas Aura , ietf-send@standards.ericsson.net In-reply-to: Julien.Laganier's message of Wed, 25 Jun 2003 11:24:43 +0200. <200306251124.43824.julien.laganier@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SEND+ND mixed mode (instead of ND to SEND transition) From: itojun@iijlab.net Date: Wed, 25 Jun 2003 18:30:41 +0900 Message-Id: <20030625093041.71E849A@coconut.itojun.org> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk >Some IPsec implementations have a SPD allowing to specify that some traffic >MAY use IPsec (KAME does that, you can specify 'require' or 'use' for an SPD >entry). In this case, an incoming packet can be processed by the IPsec layer >if it is secured via AH and/or ESP, or just bypass the IPsec layer if it is >not secured. while the description about KAME "use/require" is accurate, it does not help in the SEND/ND mixture scenario. if SEND node transmits a packet with AH to ND node, ND node will silently discard it (with "unknown SPI" logs) as ND node has no key for it. if SEND mechanism is defined as a ND option, such problem does not happen (just as Tuomas described). itojun -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 25 12:10:20 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19228 for ; Wed, 25 Jun 2003 12:10:19 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5PG81cv027134; Wed, 25 Jun 2003 18:08:01 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NSLDX07F; Wed, 25 Jun 2003 18:07:04 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5PG71sY026567; Wed, 25 Jun 2003 18:07:01 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PG6Ime008504; Wed, 25 Jun 2003 18:06:18 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5PG6IEG008503; Wed, 25 Jun 2003 18:06:18 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PG6Gme008499 for ; Wed, 25 Jun 2003 18:06:16 +0200 (MET DST) Message-ID: <011601c33b32$f5d386f0$636015ac@dclkempt40> From: "James Kempf" To: Subject: Comments from Francis DuPont on CGA Draft Date: Wed, 25 Jun 2003 09:00:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Francis DuPont is on the SEND review board. He sent the comments below on the CGA draft. Comments? jak ----------------------------------- Everywhere: please remove trailing spaces at end of lines. Abstract (wording) cryptographic one-way hash function from the address owner's public => "owner's" is an involuntary joke? (same) (same) SEND protocol messages are protected with an Authentication Header (AH) that contains the public key and the auxiliary parameters and is signed => please add a "can" verb somewhere because CGA is not the only mechanism. Table of Contents (wording, multiple) 1. Introduction...................................................2 2. The CGA Address Format.........................................3 => s/The // 3. The CGA Parameters and the Hash Values.........................4 => s/The // 4. CGA Generation.................................................5 5. CGA Verification...............................................6 6. The CGA Authorization Mechanism for SEND.......................8 => s/The // 1. Introduction identifier (i.e. rightmost 64 bits) of the IPv6 address by ^ => i.e., (please add a comma after i.e. and e. g. everywhere) (same) (wording) This kind of IPv6 addresses are called cryptographically generated addresses (CGA). => singular/plural mismatch. I propose This kind of IPv6 addresses is called a cryptographically generated address (CGA). (same) (wording) More specifically, this document specifies ^: 2. The CGA Address Format (wording) => s/The // (same) (forgotten update) Mask2 (64 bits) = 0xfcfffffffffffff8 Mask3 (64 bits) = 0xfffffffffffffff8 => I am afraid that the masks are for the previous version where the Sec bits were right-most. If it is not the case, please explain the trailing 8 (in place of f). BTW the masks are 0x1cff..f and 0x1ff..f (same) (presentation) Hash1 & Mask2 == interface identifier & Mask3 Hash2 & Mask1 == 0x0000000000000000000000000000 => please align the equations: Hash1 & Mask2 == interface identifier & Mask3 Hash2 & Mask1 == 0x0000000000000000000000000000 3. The CGA Parameters and the Hash Values (wording) => s/The // (same) (remark) CGAParameters ::= SEQUENCE { auxParameters CGAAuxParameters, publicKey SubjectPublicKeyInfo } => SubjectPublicKeyInfo is a SEQUENCE so it can't be made optional without a tag. (same) (spelling) DER-encoding. The 64-bit Hash1 is obtained by taking the leftmost 64 bits of then 160-bit SHA-1 hash value. ^ 4. CGA Generation (wording) Sec values is infeasible with today's technology. => s/today's/current/ ? 5. CGA Verification (wording) specification may define situations where a it is acceptable for ^^^^ the verifier to set higher minSec values. 6. The CGA Authorization Mechanism for SEND (wording) => s/The // 6.1 Sending SEND Messages (spelling) at least 1024 bits long. ^ (same) (ASN.1 issue) SendKeyInformation ::= SEQUENCE { cgaParameters CGAParameters OPTIONAL, signerInfo SubjectPublicKeyInfo OPTIONAL } => both CGAParameters and SubjectPublicKeyInfo are SEQUENCEs so a tag is needed. I recommend IMPLICIT tagging as: SendKeyInformation ::= SEQUENCE { cgaParameters [0] IMPLICIT CGAParameters OPTIONAL, signerInfo [1] IMPLICIT SubjectPublicKeyInfo OPTIONAL } The effect is the SEQUENCE byte (30, constructed 10) will be replaced by A0 or A1... Note that in fact only one member needs a tag but by convention usually all optional members get one. 6.2 Receiving SEND messages (wording) verification of the CGA property, the receiver must verify the MUST ^^^^^^^^^^^^^^^^^^^^ verify the source address of the packet as described in Section 5. ^^^^^^ (same) (spelling) and the contents of the CGAParameters structure from the Key ^ (same) (same) the SEND message and ignore its contents. ^ 7.2 Hash extension (request) This increases the cost of address generation approximately by a factor of 2^(16*Sec). It also increases the cost of brute-force => I'd like to know what is the delay to compute a Sec 1, 2, ... on current stock hardware (it takes 2 seconds or 2 hours). This should go in appendix A. Normative References (wording, multiple) [Bra97] Scott Bradner. Key words for use in RFCs to indicate requirement levels. RFC 2119, IETF Network Working Group, March ^^^^^^^^^^^^^^^^^^^^^ => there are some comments in the IETF mailing list about this. It seems the "Network Working Group" is old history... Informative References (ascii) [AAK+02] Jari Arkko, Tuomas Aura, James Kempf, Vesa-Matti M"ntyl", Pekka Nikander, and Michael Roe. Securing IPv6 neighbor => non ASCII characters, code 0204. (same) (request) [Nik01] Pekka Nikander. A scaleable architecture for IPv6 address ownership. Internet-draft, March 2001. Work in Progress. => please add the name of the draft. Appendix A. Example of CGA Generation (request) TBW => yes, TBW! Appendix B. Changes since draft-aura-cga-pre01 (request) o Sec is now encoded in the three leftmost bits of the 64-bit interface identifier. Earlier, it was encoded in the three rightmost bits. Using the rightmost bits would distort the distribution of solicited-node multicast addresses. => please check the document has been updated *everywhere*. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 25 12:39:09 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20585 for ; Wed, 25 Jun 2003 12:38:53 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5PGc9cv004363; Wed, 25 Jun 2003 18:38:09 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYRRVKA; Wed, 25 Jun 2003 18:39:01 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5PGb8N06410; Wed, 25 Jun 2003 18:37:08 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PGasme012209; Wed, 25 Jun 2003 18:36:54 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5PGass2012208; Wed, 25 Jun 2003 18:36:54 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PGaqme012204 for ; Wed, 25 Jun 2003 18:36:53 +0200 (MET DST) Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PGapvc028766 for ; Wed, 25 Jun 2003 10:36:51 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HH1008CHQ5EZJ@edgemail1.Central.Sun.COM> for ietf-send@standards.ericsson.net; Wed, 25 Jun 2003 10:36:51 -0600 (MDT) Received: from 192.168.1.100 ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HH100F1BQ5A8Z@mail.sun.net> for ietf-send@standards.ericsson.net; Wed, 25 Jun 2003 10:36:50 -0600 (MDT) Date: Wed, 25 Jun 2003 18:36:41 +0200 From: Julien Laganier Subject: Re: SEND+ND mixed mode (instead of ND to SEND transition) In-reply-to: <20030625093041.71E849A@coconut.itojun.org> To: itojun@iijlab.net Cc: Tuomas Aura , ietf-send@standards.ericsson.net Message-id: <200306251836.41200.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5.2 References: <20030625093041.71E849A@coconut.itojun.org> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT itojun@iijlab.net wrote : > > >Some IPsec implementations have a SPD allowing to specify that some > > traffic MAY use IPsec (KAME does that, you can specify 'require' or 'use' > > for an SPD entry). In this case, an incoming packet can be processed by > > the IPsec layer if it is secured via AH and/or ESP, or just bypass the > > IPsec layer if it is not secured. > > while the description about KAME "use/require" is accurate, it does not > help in the SEND/ND mixture scenario. if SEND node transmits a packet > with AH to ND node, ND node will silently discard it (with "unknown > SPI" logs) as ND node has no key for it. I agree with that, but I need to explain more deeply what I have in mind for SEND mixed mod. (more below) > if SEND mechanism is defined > as a ND option, such problem does not happen (just as Tuomas described). I agree. Let's explain more precisely my thoughts: On SEND enabled nodes, the SPD specify that link-local communications MAY use AH. The SEND layer has an API to make the CGA layer add a CGA header on some of the packets sent, and add meta-data to the packet causing it to be authenticated by AH. On the sending side : o When a SEND nodes want to send a packet to a non-SEND node, it doesn't attach to it the CGA header containing the public key. Thus, the IPsec layer will not find any public key for this (SPI, src_addr) tuple, causing the packet to bypass IPsec processing and being sent without AH. o At the opposite, when a SEND nodes want to send a packet to a SEND node, it attach to it a CGA header containing the public key used to generate the source address of the packet. Thus, the IPsec layer will find the corresponding public key (for this SPI, src_addr), and authenticate it with AH. A node wanting to send ND signalling to both secure and insecure nodes could send two times the same message, an insecure and a secure one. On the receiving side : o a SEND node will receive packets with a CGA header allowing AH to process the packet. The SEND layer will find the associated metadata in the CGA header. o a SEND node will receive packets without a CGA header, nor AH. The SEND layer will find not find the associated metadatas, thus being aware of the insecure nature of this packet. o A non-SEND node will receive packets without CGA and AH header, and rejects the others. Thoughts? Thanks, --julien -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 25 14:09:51 2003 Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23395 for ; Wed, 25 Jun 2003 14:09:51 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5PI90cv028852; Wed, 25 Jun 2003 20:09:00 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP0HL54; Wed, 25 Jun 2003 20:07:52 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5PI7rN08960; Wed, 25 Jun 2003 20:07:53 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PI7Fme023453; Wed, 25 Jun 2003 20:07:15 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5PI7F4e023452; Wed, 25 Jun 2003 20:07:15 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PI7Cme023444 for ; Wed, 25 Jun 2003 20:07:13 +0200 (MET DST) Message-ID: <022c01c33b43$d8c89ee0$636015ac@dclkempt40> From: "James Kempf" To: "Julien Laganier" , Cc: "Tuomas Aura" , References: <20030625093041.71E849A@coconut.itojun.org> <200306251836.41200.julien.laganier@sun.com> Subject: Re: SEND+ND mixed mode (instead of ND to SEND transition) Date: Wed, 25 Jun 2003 11:01:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > On SEND enabled nodes, the SPD specify that link-local communications MAY use > AH. The SEND layer has an API to make the CGA layer add a CGA header on some > of the packets sent, and add meta-data to the packet causing it to be > authenticated by AH. > > On the sending side : > > o When a SEND nodes want to send a packet to a non-SEND node, it doesn't > attach to it the CGA header containing the public key. Thus, the IPsec layer > will not find any public key for this (SPI, src_addr) tuple, causing the > packet to bypass IPsec processing and being sent without AH. > Problem is, some of the packets are multicast (for DAD). These are the ones that cause the most trouble, since the SEND node needs to monitor whether a nonSEND node is claiming its address. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 25 14:41:47 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24824 for ; Wed, 25 Jun 2003 14:41:46 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5PIZDw2001255; Wed, 25 Jun 2003 20:35:13 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP0HQ55; Wed, 25 Jun 2003 20:35:04 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5PIZBsY029683; Wed, 25 Jun 2003 20:35:11 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PIYnme027267; Wed, 25 Jun 2003 20:34:49 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5PIYnV3027266; Wed, 25 Jun 2003 20:34:49 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from penguin.al.sw.ericsson.se (penguin.al.sw.ericsson.se [193.180.251.47]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PIYmme027262 for ; Wed, 25 Jun 2003 20:34:48 +0200 (MET DST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5PIYmw2001211 for ; Wed, 25 Jun 2003 20:34:48 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NSLDYNQF; Wed, 25 Jun 2003 20:34:51 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5PIYVSZ007542 for ; Wed, 25 Jun 2003 21:34:31 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id 6205E5F691 for ; Wed, 25 Jun 2003 21:35:02 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E70666A903; Wed, 25 Jun 2003 21:34:41 +0300 (EEST) Message-ID: <3EF9EABC.1020600@piuha.net> Date: Wed, 25 Jun 2003 21:32:28 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier Cc: itojun@iijlab.net, Tuomas Aura , ietf-send@standards.ericsson.net Subject: Re: SEND+ND mixed mode (instead of ND to SEND transition) References: <20030625093041.71E849A@coconut.itojun.org> <200306251836.41200.julien.laganier@sun.com> In-Reply-To: <200306251836.41200.julien.laganier@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Julien Laganier wrote: > A node wanting to send ND signalling to both secure and insecure nodes could > send two times the same message, an insecure and a secure one. Yes, this looks like it can work. Interesting! But it implies twice the amount of overhead from ND traffic. How significant is this? I don't know, but at least it is a factor that should be considered. In addition, the coupling to IPsec processing is pretty tight. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 25 18:48:47 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08927 for ; Wed, 25 Jun 2003 18:48:32 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5PMfTG5002415; Thu, 26 Jun 2003 00:41:29 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP020CF; Thu, 26 Jun 2003 00:41:21 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5PMfNsY004200; Thu, 26 Jun 2003 00:41:23 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PMeome027485; Thu, 26 Jun 2003 00:40:50 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5PMeos0027484; Thu, 26 Jun 2003 00:40:50 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5PMemme027480 for ; Thu, 26 Jun 2003 00:40:49 +0200 (MET DST) Received: from [10.1.71.211] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5PMc4Dh011829; Wed, 25 Jun 2003 18:39:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <3EF16ED1.3040908@nomadiclab.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF16ED1.3040908@nomadiclab.com> Date: Wed, 25 Jun 2003 18:07:58 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Cc: Tero Kivinen , ipsec@lists.tislabs.com, James Kempf , SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk At 11:05 AM +0300 6/19/03, Pekka Nikander wrote: >>>Is there any use for the AH as it is now specified? >> >>Very little. But, that does not mean that one can redefine it and >>still have it be part of IPsec. > >Just out of curiosity: How do you define IPsec? RFC2401? RFC 2401 defines IPsec processing and semantics. ESP and AH are the two subscriber traffic protocols whose syntax is separately defined. We put the common processing and context discussion in 2401, to avoid repetition. I do not view AH and ESP as protocols that should be viewed outside of the context of 2401. > >>The SEND WG can create its own protocol, but there is no technical >>rationale for reusing the AH name. Reuse would only cause confusion. > >In my (in this case very) humble opinion, I think that the question >of reusing the AH name depends on the intent of the protocol, not >only on its syntax. If the goal is the same, to provide integrity >and data origin authentication for the whole IP packet, including the >immutable or predictable header fields, then I think that the protocol >could and should be called AH. If it uses public key crypto, and >thereby creates (conceptual) Security Associations that are associated >with the source of the packet rather than the destination, even for >unicast, that does not change the intent. > >OTOH, I do agree that embedding KMP functionality into the AH header >does not sound that good an idea. However, it did not appear to me how >to separate the KMP functionality before I started to implement the >current SEND proposal. Embedding key management data in the transit traffic headers is what SKIP proposed a long time ago. The IPsec WG spent over 2 years arguing about this before we adopted IKE. >AH has a long history. I think it would be better to return to the >some early goals of AH rather than to deprecate it and start anew. Some of the early goals are no longer relevant, e.g., because of the advent of integrity-only ESP. Steve -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jun 25 22:15:07 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21185 for ; Wed, 25 Jun 2003 22:15:06 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5Q28IG5014605; Thu, 26 Jun 2003 04:08:19 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYR45DZ; Thu, 26 Jun 2003 04:10:11 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h5Q28IN21565; Thu, 26 Jun 2003 04:08:18 +0200 (MET DST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5Q27Xme026616; Thu, 26 Jun 2003 04:07:33 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5Q27Xtn026614; Thu, 26 Jun 2003 04:07:33 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5Q27Ume026593 for ; Thu, 26 Jun 2003 04:07:31 +0200 (MET DST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 7123F9F; Thu, 26 Jun 2003 11:07:27 +0900 (JST) To: jari.arkko@piuha.net Cc: Julien Laganier , Tuomas Aura , ietf-send@standards.ericsson.net In-reply-to: jari.arkko's message of Wed, 25 Jun 2003 21:32:28 +0300. <3EF9EABC.1020600@piuha.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SEND+ND mixed mode (instead of ND to SEND transition) From: itojun@iijlab.net Date: Thu, 26 Jun 2003 11:07:27 +0900 Message-Id: <20030626020727.7123F9F@coconut.itojun.org> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk >> A node wanting to send ND signalling to both secure and insecure nodes could >> send two times the same message, an insecure and a secure one. >Yes, this looks like it can work. Interesting! But it implies twice >the amount of overhead from ND traffic. How significant is this? >I don't know, but at least it is a factor that should be considered. >In addition, the coupling to IPsec processing is pretty tight. for a receiving SEND-capable node, it would be confusing. - if SEND packet comes in then ND, do you want to update ND cache state, or ignore ND? - if ND packet comes in then SEND, do you want to create ND cache on receipt of the first ND packet? what do you do against second packet? note that we shouldn't be peeking L2 header so it is not distinguishable from (sort of) replay attack. itojun -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jun 26 01:14:43 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26278 for ; Thu, 26 Jun 2003 01:14:27 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5Q5APG5024158; Thu, 26 Jun 2003 07:10:25 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP0LC26; Thu, 26 Jun 2003 07:10:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5Q5ANsY008436; Thu, 26 Jun 2003 07:10:23 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5Q59Zme000249; Thu, 26 Jun 2003 07:09:35 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5Q59Ze8000248; Thu, 26 Jun 2003 07:09:35 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from falcon.al.sw.ericsson.se (falcon.al.sw.ericsson.se [193.180.251.52]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5Q59Xme000243 for ; Thu, 26 Jun 2003 07:09:33 +0200 (MET DST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5Q5AXcv018971 for ; Thu, 26 Jun 2003 07:10:33 +0200 Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N4L8LT3N; Thu, 26 Jun 2003 07:09:34 +0200 Received: from trinity.ericsson.fi (trinity [131.160.206.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5Q59FSZ005000 for ; Thu, 26 Jun 2003 08:09:15 +0300 (EET DST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by trinity.ericsson.fi (Postfix) with ESMTP id C31945F691 for ; Thu, 26 Jun 2003 08:09:47 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 59CE16A902; Thu, 26 Jun 2003 08:09:27 +0300 (EEST) Message-ID: <3EFA7F80.80305@piuha.net> Date: Thu, 26 Jun 2003 08:07:12 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itojun@iijlab.net Cc: Julien Laganier , Tuomas Aura , ietf-send@standards.ericsson.net Subject: Re: SEND+ND mixed mode (instead of ND to SEND transition) References: <20030626020727.7123F9F@coconut.itojun.org> In-Reply-To: <20030626020727.7123F9F@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: > for a receiving SEND-capable node, it would be confusing. > - if SEND packet comes in then ND, do you want to update ND cache state, > or ignore ND? > - if ND packet comes in then SEND, do you want to create ND cache on > receipt of the first ND packet? what do you do against second packet? I suppose you'd have to use the same kind of rules as Tuomas outlined for the ND option case, i.e., an insecure advertisement should not override a secure one etc. But this requires a tight coupling between the IPsec and ND code, essentially you have to be able to tell whether the packet was protected or not, and possibly even how it was protected. In addition, sending the same messages twice does not look very pretty. All this would be much simpler with the ND option approach. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 27 01:34:12 2003 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05824 for ; Fri, 27 Jun 2003 01:33:56 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5QIQGG5004006; Thu, 26 Jun 2003 20:26:16 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NV4RAXLP; Thu, 26 Jun 2003 20:28:10 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5QIQFEo001420; Thu, 26 Jun 2003 20:26:15 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5QIPPme012750; Thu, 26 Jun 2003 20:25:25 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5QIPP5O012749; Thu, 26 Jun 2003 20:25:25 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5QIPNme012740 for ; Thu, 26 Jun 2003 20:25:24 +0200 (MET DST) Received: (qmail 29051 invoked from network); 26 Jun 2003 18:25:22 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Jun 2003 18:25:22 -0000 Date: Thu, 26 Jun 2003 11:28:51 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: SEND IPSec Implementation Update From: Jonathan Wood To: ietf-send@standards.ericsson.net Content-Transfer-Encoding: 7bit Message-Id: <093C4CBB-A804-11D7-BD95-0003930D291E@speakeasy.net> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit We (DoCoMo Labs) have been implementing draft-ietf-send-ipsec-01.txt on Linux 2.5.x. One of the goals is to determine just how much we need to twist the Linux IPSec implementation. We have found the answer to be "a lot". One of our implementation goals has been to reserve the option of pushing to user-space things like ASN.1 parsing, RSA encryption and decryption, and cert chain retrieval and processing. The motivation for doing so is that all incoming and many outgoing packets are processed in the interrupt context (more precisely, the bottom half context, for those familiar with Linux), where you don't want to be doing time consuming operations. We also want to keep ASN.1 bloat to a minimum in the kernel. It turns out that we would need to muddy considerably the IPSec and IPv6 stack implementation to enable userspace offload if we need to do it from either extension header parsing or an AH transform. Without diving into detail too much, pausing ext header and AH transform processing in mid-step and then restarting it later is quite nasty. The semantics of AH processing in Linux also create problems for a SEND implementation. Linux IPSec is very modular. Digest transforms all implement a common, clean interface. Digest callers (such as AH processing code, both inbound and outbound) simply provide the transform with a chunk of bytes and ask it to compute the digest according to its parameters. SEND, however, requires that the digest do much more. First, the transform needs to know if the packet is outbound or inbound. If inbound, the transform needs to verify the CGA and the crypto signature, and make the decision on whether to drop or accept itself. Enabling these semantics would require new interfaces on the digest code, and some mechanism to allow AH to decide whether it should use the traditional or SEND semantics when processing a packet. So we believe that while SEND as currently specified is doable, it won't be pretty, and will probably have a very difficult time being accepted into the mainstream Linux kernel. draft-nikander-send-ipsec-00.txt encounters most of the same problems discussed above, since we would still need to pause in the middle of ext header and AH header processing. draft-arkko-send-ndopt-00.txt, on the other hand, looks right now like it can avoid all these problems, since we are not bound by the semantics of AH processing, and by the time we get to a ND option, it is easy to pause and restart later if we need to do some heavy crypto lifting, or retrieve a cert chain. j -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jun 27 21:47:52 2003 Received: from penguin.al.sw.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29525 for ; Fri, 27 Jun 2003 21:47:37 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5S1iqw2011535; Sat, 28 Jun 2003 03:44:52 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW47Z062; Sat, 28 Jun 2003 03:46:50 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h5S1ioEo028723; Sat, 28 Jun 2003 03:44:50 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h5S1hwme023990; Sat, 28 Jun 2003 03:43:58 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h5S1hw7Q023989; Sat, 28 Jun 2003 03:43:58 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from 2mails2029.com ([192.116.121.210]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h5S1hmme023981 for ; Sat, 28 Jun 2003 03:43:54 +0200 (MET DST) Message-Id: <200306280143.h5S1hmme023981@sw.ericsson.se> From: "MRS.MARYAM ABACHA" Reply-To: hassan_abacha@37.com To: ietf-send@standards.ericsson.net Date: Fri, 27 Jun 2003 18:43:53 -0700 Subject: PLS. CALL ME IMMEDIATELY @ 234-8033123607 X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h5S1hvme023986 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit DEAR URGENT NEED OF A BUSNIESS PARTNER/CONFIDANT MY NAME IS MRS.MARYAM ABACHA, THE WIFE OF THE LATE HEAD OF STATE OF THE FEDERAL REPUBLIC OF NIGERIA, GENARAL SANNI ABACHA. I GOT YOUR NAME AND EMAIL ADDRESS IN YOUR COUNTRY'S ELECTRONIC EMAIL DIRECTORY. IT IS FOUR YEARS SINCE MY HUSBAND PASSED AWAY AND THE TIGHT GRIP ON MY HUSBAND'S ASSESTS BOTH HOME AND ABROAD IS NOW TELLING ON THE FAMILY,SINCE THE NEW CIVILAIN REGIME CAME INTO PLACE. I AM NOW IN URGENT NEED OF A PARTNER/CONFIDANT THROUGH WHOM I CAN DEPOSIT SOME MONEY IN HIS/HER BANK ACCOUNT AND ALSO INVEST IT FOR ME IN GOOD BUSINESS. THIS MONEY WAS DEPOSITED BY MY LATE HUSBAND IN A SECURITY COMPANY IN ABROAD WITH THE ASSISTANCE OF A DIPLOMAT, AMOUNTING TO THE SUM OF (US$30,000,000.00DOLLARS ONLY).THE PARTNER I SEEK MUST BE ONE THAT IS TRUSTWORTHY,AND READY TO TRAVEL TO CLAIM THE COSIGNMENTS(FUNDS)IN THE COUNTRY WHERE THE SECURITY COMPANY IS.ALSO,YOU MUST SEND ME A LETTER OF ASSURANCE THAT HE/SHE IS NOT GOING TO BETRAY ME IN THIS BUSINESS. PLEASE,IF YOU LACK SUCH CAPABILITY TO HANDLE A TRANSACTION OF THIS MAGNITUDE DO NOT HESITATE TO LINK ME TO A RELIABLE FRIEND, OLD SCHOOL MATE OR A COMMUNITY LEADER WITH A RELIABLE GRIP ON THE SYSTEM. THIS IS VERY IMPORTANT. THE DETAILS OF WHAT WOULD ACCRUE TO PAY FOR YOUR EFFORTS WILL BE DISCLOSE TO YOU WHEN YOU INDICATE YOUR INTEREST. YOU ARE TO WORK DIRECTLY WITH THE DIPLOMAT AND MY FAMILY ATTORNEY,AS I HAVE BEEN UNDER HOUSE ARREST FOR THE PAST TWO YEARS.IAM WILLING AND READY TO OFFER YOU 25% OF THE TOTAL SUM AS YOUR OWN SHARE FOR HELPING IN THE REALISATION OF THIS INVESTMENT WHILE 65% WILL BE FOR MY INVESTMENT IN YOUR LINE OF PRODUCT AND SERVICE IN A JOINT VENTURE WITH YOU, THE REMAINING 10% HAS BEEN SET ASIDE TO OFF-SET ALL EXPENSES TO BE INCURED DURING THIS TRANSACTION. BE FURTHER INFORMED THAT THESE FUND IS SECURED IN A SECURITY VAULT WITH A SECURITY COMPANY. YOU ARE REQUIRED TO SEND TO ME YOUR TELEPHONE AND FAX NUMBERS SO THAT MY FAMILY ATTORNEY CAN HAVE CONTACT WITH YOU. YOU CAN REACH ME ON MY PRIVATE MOBILE LINE; 234-8033-123-607 REGARDS, FROM DR.(MRS).MARYAM ABACHA. N/B: REPLY STRICTLY AND ONLY TO MY PRIVATE EMAIL ADDRESSES BELOW FOR SECURITY REASONS. email address:hassan_abacha@37.com or aisha_abacha2@www.com -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------