From jari.arkko@lmf.ericsson.se Fri Aug 1 10:37: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 KAA25211 for ; Fri, 1 Aug 2003 10:37:21 -0400 (EDT) Received: from esealnt610.al.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 h71EYSG6016003; Fri, 1 Aug 2003 16:34:28 +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 366FBMQS; Fri, 1 Aug 2003 16:35: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 h71EYLxR024886; Fri, 1 Aug 2003 16:34:21 +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 h71EUume010071; Fri, 1 Aug 2003 16:30:56 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h71EUuN4010070; Fri, 1 Aug 2003 16:30: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 pc7 (111.Red-80-35-167.pooles.rima-tde.net [80.35.167.111]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h71EUrmf010058 for ; Fri, 1 Aug 2003 16:30:54 +0200 (MET DST) Message-Id: <200308011430.h71EUrmf010058@sw.ericsson.se> From: lotterysl@netscape.net Subject: WINNING NOTIFICATION !!! To: ietf-send@standards.ericsson.net Content-Type: text/plain; charset="US-ASCII" Reply-To: lotterysl@netscape.net Date: Fri, 1 Aug 2003 16:31:26 +0200 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk LOTTERY LA PRIMITIVA. C/GUZMAN EL BUENO,137 MADRID - ESPANA. TEL:0034 696 026 500 FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/03 BATCH: 24/00319/IPD RE: AWARD NOTIFICATION FINAL NOTICE. We are pleased to inform you of the announcement, of winners of the LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMMES held on 6 June,2003. Your name is attached to ticket number 004-05117963-198, with serial number 99375 drew the lucky numbers 05-07-11-12-13-27, and consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum pay out of EUROS 647,828,87 Thousand in cash credited to file No:LP/26510460037/03.This is from total prize money of EUROS 80,400,000.00 shared among the twenty two international winners in this category. All participants were selected through a computer ballot system drawn from 25,000 names from Australia,New Zealand, America,Europe, North America and Asia as part of International Promotions Programme, which is conducted annually. CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes Euros 1.1 billion International Lottery. To begin your claim, please contact ESPAÑOL CREDITO SEGURIDAD, MADRID-SPAIN ,PHONE NUMBER (+34 608 701 649) MR JUAN CARLOS REDONDO, FOREIGN OPERATION MANAGERS, Email;(lottery-primitiva@winning.com). For due processing and remittance of your prize money to a designated account . Remember, all prize money must be claimed not later than 10 September 2003. After this date,all funds will be returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every one of your correspondences with the security company . Furthermore, should there be any change of your address,do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions programme. Sincerely, FERNANDO TORRES RODRIGUEZ. -------------------------------------------------------------------- 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 Aug 1 21:01:48 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 VAA19045 for ; Fri, 1 Aug 2003 21:01:47 -0400 (EDT) Received: from esealnt611.al.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 h720vOG6008351; Sat, 2 Aug 2003 02:57: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 QCP8GQDT; Sat, 2 Aug 2003 03:01:04 +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 h720vNxa018132; Sat, 2 Aug 2003 02:57: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 h720rome025444; Sat, 2 Aug 2003 02:53:50 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h720roVH025443; Sat, 2 Aug 2003 02:53: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 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 h720rmme025439 for ; Sat, 2 Aug 2003 02:53:49 +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.6713); Fri, 1 Aug 2003 17:53:44 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Aug 2003 17:53:43 -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); Fri, 1 Aug 2003 17:53:48 -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-01 + issues list Date: Fri, 1 Aug 2003 17:53:14 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F09C9CE04@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: Draft-ietf-send-cga-01 + issues list Thread-Index: AcMyCN5nQ3L8T2FFRS6TN/8DpgTS7AmhSCeA From: "Tuomas Aura" To: X-OriginalArrivalTime: 02 Aug 2003 00:53:48.0212 (UTC) FILETIME=[88520F40:01C35890] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h720rnme025440 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit The above should soon appear in the Internet-Drafts directory. Meanwhile, a temporary copy can be found at: http://www.research.microsoft.com/users/tuomaura/CGA/ draft-ietf-send-cga-01.txt Your comments have been really helpful. Appendix B contains the list of changes since the previous version. The list of major issues with their proposed solutions is at http://www.research.microsoft.com/users/tuomaura/CGA/CGAIssues.aspx The current proposed solutions have been included in draft-01. Please check that all you comments have been taken into account satisfactorily and let me know if I have missed something. 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 Aug 2 06:53:08 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 GAA11185 for ; Sat, 2 Aug 2003 06:53:07 -0400 (EDT) Received: from esealnt611.al.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 h72AoijG024438; Sat, 2 Aug 2003 12:50: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 QCP8JL31; Sat, 2 Aug 2003 12:54:25 +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 h72AocxR010609; Sat, 2 Aug 2003 12:50: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 h72AlGme007571; Sat, 2 Aug 2003 12:47:16 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h72AlGMK007569; Sat, 2 Aug 2003 12:47: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 pc6 (111.Red-80-35-167.pooles.rima-tde.net [80.35.167.111]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h72AlDmf007556 for ; Sat, 2 Aug 2003 12:47:14 +0200 (MET DST) Message-Id: <200308021047.h72AlDmf007556@sw.ericsson.se> From: fredricktaylor00@netscape.net Subject: KIND ATTENTION !! To: ietf-send@standards.ericsson.net Content-Type: text/plain; charset="US-ASCII" Reply-To: fredricktaylor00@netscape.net Date: Sat, 2 Aug 2003 12:47:12 +0200 X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk EXTREMELY CONFIDENTIAL. ATTENTION: THE PRESIDENT/CHAIRMAN. First, may I solicit your confidentiality in this transaction, this by virtue of its nature I am Fredrick Taylor, a cousin to the president Charles Taylor of Liberia. As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes (containing cash of $39.8m)secured in a diplomatic custody in madrid-spain and these diplomatic agents are not aware of the contents of this consignment. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out that the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this funds will be use in capital investments or you advice us on any lucrative project to put the funds into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project. Upon receipt of your positive response, I will suggest we meet possible in madrid-spain for us to work out modalities concerning the investment of the money and/or the ratio you will receive after the collection of the boxes from these diplomatic agents in madrid-spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address.I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Best Regards, F . Taylor. -------------------------------------------------------------------- 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 Aug 3 07:04:28 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 HAA14919 for ; Sun, 3 Aug 2003 07:04:27 -0400 (EDT) Received: from esealnt611.al.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 h73B10G6014928; Sun, 3 Aug 2003 13:01:00 +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 QCP8PK0S; Sun, 3 Aug 2003 13:04:44 +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 h73B0xxa001841; Sun, 3 Aug 2003 13:00:59 +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 h73AvBme011437; Sun, 3 Aug 2003 12:57:11 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h73AvBhx011436; Sun, 3 Aug 2003 12:57: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 mh ([61.99.76.194]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h73Av5me011400 for ; Sun, 3 Aug 2003 12:57:07 +0200 (MET DST) Message-Id: <200308031057.h73Av5me011400@sw.ericsson.se> From: bto9@gte.net To: ietf-send@standards.ericsson.net Subject: Re: what up Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sun, 3 Aug 2003 19:57:15 +0900 X-Mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk
DON'T LOSE ANY MORE MONEY ON YOUR EXISTING HOME LOAN!

whats up. I thought you might be interested in this.

I refinanced my mortgage and this site got me the best financer available
With the money you save, put it towards a new car!

-------------------------------------------------------------------- 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 Aug 4 06:02:04 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 SMTP id GAA21059 for ; Mon, 4 Aug 2003 06:02:04 -0400 (EDT) Received: from esealnt613.al.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 h749x0G6004691; Mon, 4 Aug 2003 11:59:04 +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 P0960DZ4; Mon, 4 Aug 2003 11:59:00 +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 h749wxxa014870; Mon, 4 Aug 2003 11:58:59 +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 h749tame009433; Mon, 4 Aug 2003 11:55:36 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h749tZkX009432; Mon, 4 Aug 2003 11:55: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 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 h749tYme009428 for ; Mon, 4 Aug 2003 11:55:34 +0200 (MET DST) Received: from mta.imail.kolumbus.fi ([193.229.5.109]) by fep07-app.kolumbus.fi with ESMTP id <20030804095534.RPYK1212.fep07-app.kolumbus.fi@mta.imail.kolumbus.fi>; Mon, 4 Aug 2003 12:55:34 +0300 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Date: Mon, 4 Aug 2003 12:55:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030804095534.RPYK1212.fep07-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > While the CGA specification for SEND only talks about > the uses of CGA in SEND, there are other protocols that > will use the same CGA keys and addresses. This raises > the question of related-protocol attacks. In such attacks, > CGA-signed messages from one protocol could be replayed > in another protocol. Yes. We need to ensure that the messages are indeed different when they are signed. > This tag could > either be a short (e.g. 32-bit) IANA-allocated value or > a fixed 128-bit number chosen randomly by us at the protocol > design time. The IANA-allocated type tags are more in line I'd prefer IANA allocation, but we can start by giving SEND a random number in this allocation to reduce the chance of a collision. Say, SEND = 0x1E7F 2003 5E2D C5A1 500D F00D 802E BEE2. Since the value is not communicated over the wire, it can be of any length. > There is also the editorial question of whether the type > tag should be part of the CGA or SEND document. If it is > an IANA-allocated short value, then it seems the CGA documents > should define a new IANA registry and the SEND document > should define an entry in the registry. Sounds good. > Define a randomly chosen 128-bit tag for each SEND message > type (NS, NA, RS, RA, Redirect). Define these tag values in > the SEND document. One of these 5 tags should be prepended Current document includes the whole packet under the digital signature. This includes therefore also the ICMP Type. Would that be sufficient with a single tag value for SEND? --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 Aug 4 07:48: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 SMTP id HAA22602 for ; Mon, 4 Aug 2003 07:48:15 -0400 (EDT) Received: from esealnt612.al.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 h74BjMjG002937; Mon, 4 Aug 2003 13:45:22 +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 NW45DPW8; Mon, 4 Aug 2003 13:45:21 +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 h74BjLxa016766; Mon, 4 Aug 2003 13:45:21 +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 h74BfSme022300; Mon, 4 Aug 2003 13:41:28 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h74BfSFS022299; Mon, 4 Aug 2003 13:41: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 user-r0v5loupze (218-164-101-49.HINET-IP.hinet.net [218.164.101.49]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h74BfKmf022288 for ; Mon, 4 Aug 2003 13:41:26 +0200 (MET DST) Message-Id: <200308041141.h74BfKmf022288@sw.ericsson.se> From: bwill@yahoo.com To: ietf-send@standards.ericsson.net Subject: Re: .. heh Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 4 Aug 2003 19:48:40 +0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk
DON'T LOSE ANY MORE MONEY ON YOUR EXISTING HOME LOAN!

hmm, okay so you want to save some money. take a look..

You really owe it to yourself and your family to take a look,
are you prepared for lower mortgage repayments?

-------------------------------------------------------------------- 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 Aug 4 10:20:39 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 SMTP id KAA28630 for ; Mon, 4 Aug 2003 10:20:38 -0400 (EDT) Received: from esealnt612.al.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 h74EIXG6005212; Mon, 4 Aug 2003 16:18: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 NW451KVW; Mon, 4 Aug 2003 16:18:33 +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 h74EIWxa019507; Mon, 4 Aug 2003 16:18:32 +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 h74EFBme010963; Mon, 4 Aug 2003 16:15:11 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h74EFBPd010960; Mon, 4 Aug 2003 16:15: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 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 h74EF9me010898 for ; Mon, 4 Aug 2003 16:15:10 +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 KAA27540; Mon, 4 Aug 2003 10:15:04 -0400 (EDT) Message-Id: <200308041415.KAA27540@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-01.txt Date: Mon, 04 Aug 2003 10:15:03 -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-01.txt Pages : 26 Date : 2003-8-4 This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses where the interface identifier is generated by computing a cryptographic one-way hash function from a 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. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message 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-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-cga-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-cga-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-8-4094252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-send-cga-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-send-cga-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-4094252.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 Mon Aug 4 11:02:41 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 SMTP id LAA00713 for ; Mon, 4 Aug 2003 11:02:40 -0400 (EDT) Received: from esealnt613.al.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 h74F0IG6013755; Mon, 4 Aug 2003 17:00:18 +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 P097BCK0; Mon, 4 Aug 2003 17:00:18 +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 h74F0Hxa020187; Mon, 4 Aug 2003 17:00: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 h74Ev1me015775; Mon, 4 Aug 2003 16:57:01 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h74Ev1Yb015774; Mon, 4 Aug 2003 16:57: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 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 h74Euxme015762 for ; Mon, 4 Aug 2003 16:56:59 +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.6713); Mon, 4 Aug 2003 07:56:57 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 04 Aug 2003 07:56:46 -0700 Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Aug 2003 07:56:57 -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: Type tags and pseudo-messages (RE: ) Date: Mon, 4 Aug 2003 07:56:19 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F09C9D085@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: Type tags and pseudo-messages (RE: ) Thread-Index: AcNabqNjbmlnOBvHSPKOVZ4uInQxEwAJTwXw From: "Tuomas Aura" To: Cc: X-OriginalArrivalTime: 04 Aug 2003 14:56:57.0308 (UTC) FILETIME=[A69901C0:01C35A98] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h74Ev0me015768 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Jari Arkko wrote: > I'd prefer IANA allocation, but we can start by > giving SEND a random number in this allocation to > reduce the chance of a collision. Say, SEND = > 0x1E7F 2003 5E2D C5A1 500D F00D 802E BEE2. Yes, you can do that. Except that I would prefer the value to be really generated in random. (Two "random" values invented by C001 D00Ds are more likely to collide than two random numbers.)) > Current document includes the whole packet under the digital > signature. This includes therefore also the ICMP Type. Would > that be sufficient with a single tag value for SEND? If, indeed, the whole packet is signed, then the SEND needs only one tag value because the ICMP Type can be used to differentiate between SEND messages. Otherwise, it is a matter of taste where to put the part of the type tag that differentiates between the different SEND messages. The way the new CGA spec is written, it allows for consecutive type tag values to be used for SEND messages, starting from a random one. But I'm just as happy to use only one tag for SEND. BTW, I believe that we should not be signing the entire packet. I'd rather define pseudo-message that contains only the relevant fields and sign that. Some arguments for signing pseudo-messages: (1) We need to define some kind of pseudo-messages anyway because some IP header fields and the signature itself need to be excluded from the signed part. (2) If the entire packet is singed, it becomes necessary to guess the size of the signature before signing. This may be relatively easy but ugly anyway. (3) Protocol extensions, such as proxy ND and RD, may need to include the signed SEND message in another message or to have multiple signatures on a single SEND message. 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 Aug 5 21:13:20 2003 Received: from penguin (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04890 for ; Tue, 5 Aug 2003 21:13:19 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h761A2CD027989; Wed, 6 Aug 2003 03:10:02 +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 P097MT3L; Wed, 6 Aug 2003 03:10: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 h7619uxR029857; Wed, 6 Aug 2003 03:09: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 h7614qme009914; Wed, 6 Aug 2003 03:04:52 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7614qVp009913; Wed, 6 Aug 2003 03:04: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 winning96.com (node-c-1599.a2000.nl [62.194.21.153]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h7614gme009903 for ; Wed, 6 Aug 2003 03:04:46 +0200 (MET DST) Message-Id: <200308060104.h7614gme009903@sw.ericsson.se> From: Foundation Lottery International To: ietf-send@standards.ericsson.net Reply-To: foundationlottery@winning.com Subject: Congratulations, You Have Won !!! Date: Wed, 06 Aug 2003 03:04:13 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9048fbeb-f426-4dce-abba-7fd641bbbebe" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format --9048fbeb-f426-4dce-abba-7fd641bbbebe Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FROM: FUNDATION LOTTERY INTERNATIONAL INTERNATIONAL PROMOTION/PRIZE AWARD DEPT. REF: FLI/272-USTI490/059 BATCH: HFD/15/097/PTNL RE: WINNING FINAL NOTIFICATION Sir/Madam We are pleased to inform you of the result of the Lottery Winners International programs held on the 1st August 2003. Your e-mail address attached to ticket number 20511465897-6291 with serial number 472-971103 drew lucky numbers 8-66-97-22-71-64 which consequently won in the 2nd category, you have therefore been approved for a lump um pay out of US$ 500,000.00 (Five Hundred Thousand United States Dollars) CONGRATULATIONS!!! Due to mix up of some numbers and names, we ask that you keep your winning information very confidential till your claims has been processed and your prize/money Remitted to you. This is part of our security protocol to avoid double claiming and unwarranted abuse of this program by some participants. All participants were selected through a computer ballot system drawn from over 200,000,000 company and 300,000,000 individual email addresses and names from all over the world. This promotional program takes place annually. We hope with part of your winning you will take part in our next year USD100 million international lottery. To file for your claim, please contact our/your fiducial agent MR. CLIFFORD SMITH of the, CLASSIC LINKS AGENCY TEL: +31-630 554 655 FAX: +31-641 321 855 Email: clasiclinkagency@netscape.net Note that all winning must be claimed not later than 29th of August 2003. After this date all unclaimed, funds will be included in the next stake. Please note in order to avoid unnecessary delays and complications please remember to quote your reference number and batch numbers in all correspondence. Furthermore, should there be any change of address do inform our agent as soon as possible. Congratulations once more from our members of staff and thank you for being part of our promotional program. Note: Anybody under the age of 18 is automatically disqualified. Sincerely yours, Mrs. Helen Van Hall Lottery Coordinator. --9048fbeb-f426-4dce-abba-7fd641bbbebe-- -------------------------------------------------------------------- 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 Aug 5 21:50:12 2003 Received: from albatross (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05998 for ; Tue, 5 Aug 2003 21:50:11 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h761l5Qm009172; Wed, 6 Aug 2003 03:47:06 +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 QCQQBCR1; Wed, 6 Aug 2003 03:48:32 +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 h761l4xa015248; Wed, 6 Aug 2003 03:47:04 +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 h761htme014364; Wed, 6 Aug 2003 03:43:55 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h761htdI014363; Wed, 6 Aug 2003 03:43: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 mail.com (80-28-168-35.adsl.nuria.telefonica-data.net [80.28.168.35]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h761hemf014358; Wed, 6 Aug 2003 03:43:41 +0200 (MET DST) Message-Id: <200308060143.h761hemf014358@sw.ericsson.se> From: "Carlos Sánchez" Subject: Re: Carlos Sanchez Reply-To: CarlosSan@hotmaill.com.cnri.reston.va.us X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Date: Wed, 6 Aug 2003 03:49:37 +0200 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tjatte.sw.ericsson.se id h761l4xa015248 Content-Transfer-Encoding: quoted-printable Navegando por Internet encontr=E9 ese sitio curioso con algunas noticias = que te puede interesar. Un Abrazo Carlos S=E1nchez http://www.lacarcajada.com/news/vermais.htm -------------------------------------------------------------------- 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 Aug 5 22:32:25 2003 Received: from penguin (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07028 for ; Tue, 5 Aug 2003 22:32:24 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h762UDCD005305; Wed, 6 Aug 2003 04:30: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 QCP9BSPA; Wed, 6 Aug 2003 04:34:05 +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 h762UCxa015547; Wed, 6 Aug 2003 04:30:12 +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 h762Qjme025848; Wed, 6 Aug 2003 04:26:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h762QjIU025847; Wed, 6 Aug 2003 04:26: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 311bb92ac2f649a ([211.49.118.39]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h762Qfme025840 for ; Wed, 6 Aug 2003 04:26:43 +0200 (MET DST) Message-Id: <200308060226.h762Qfme025840@sw.ericsson.se> From: btploblaw@email.com To: ietf-send@standards.ericsson.net Subject: Re: hey Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 6 Aug 2003 11:24:50 +0900 X-Mailer: AOL 7.0 for Windows US sub 118 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk
DON'T LOSE ANY MORE MONEY ON YOUR EXISTING HOME LOAN!

we could all use some extra money at the end of the week!

I refinanced my mortgage and this site got me the best financer available
are you prepared for lower mortgage repayments?

-------------------------------------------------------------------- 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 Aug 6 00:06:55 2003 Received: from penguin (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08306 for ; Wed, 6 Aug 2003 00:06:55 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7644mCD011223; Wed, 6 Aug 2003 06:04:48 +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 P097NSLJ; Wed, 6 Aug 2003 06:04: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 h7644exR001676; Wed, 6 Aug 2003 06:04: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 h7641Lme013187; Wed, 6 Aug 2003 06:01:21 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7641LDJ013186; Wed, 6 Aug 2003 06:01: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 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 h7641Jme013182 for ; Wed, 6 Aug 2003 06:01:20 +0200 (MET DST) Message-ID: <019001c35bcf$6b8b8750$616015ac@dclkempt40> From: "James Kempf" To: Subject: Fw: ID Tracker State Update Notice: draft-ietf-send-psreq Date: Tue, 5 Aug 2003 21:01:30 -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 ----- Original Message ----- From: "The IESG" To: ; Sent: Thursday, July 31, 2003 11:48 AM Subject: ID Tracker State Update Notice: draft-ietf-send-psreq > 'State Changes to AD Evaluation from Publication Requested by Margaret Wasserman' > > > -------------------------------------------------------------------- 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 Aug 6 03:37:50 2003 Received: from penguin (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08612 for ; Wed, 6 Aug 2003 03:37:49 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h767YtCD005729; Wed, 6 Aug 2003 09:34:55 +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 QCQQCJG5; Wed, 6 Aug 2003 09:36:22 +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 h767Ysxa018442; Wed, 6 Aug 2003 09:34: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 h767Veme009596; Wed, 6 Aug 2003 09:31:40 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h767VesH009595; Wed, 6 Aug 2003 09: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 coolre4269.com ([81.199.84.94]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h767VKme009576 for ; Wed, 6 Aug 2003 09:31:25 +0200 (MET DST) Message-Id: <200308060731.h767VKme009576@sw.ericsson.se> From: "DR.(MRS).MARIAM ABACHA." Reply-To: drmariama@rediffmail.com To: ietf-send@standards.ericsson.net Date: Wed, 7 Aug 2002 08:30:39 -0700 Subject: YOU ARE MY HOPE!!!!!!!!!!! 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 h767Vdme009592 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit My Dear, It is with heartfelt hope that I write to seek your co-operation and assistance in the context stated below:May I first introduce my self: I am DR.(MRS.) MARIAM ABACHA,the wife of Late General Sani Abacha (former Military head of state and President of the Federal Republic of Nigeria) who died suddenly on 8th June 1998. I got your contact through the help of my sister-inlaw that works with the Canadian Chambers of Commerce and Tourrism,due,I did not disclose to her my humble intention for a honest foreigner who will help save my life and my children. Having noted the confidence reposed on your person by the sponsor of the recommendation, I became convinced of your capability and goodwill to assist me in receiving the sum of US$20 Million secretly willed in my favour by the late general (my husband). This money was kept in a Security Company in Amsterdam Holland and I have all documents with me as of when it was deposited in a Security Vault for safe keeping.This money has been defaced for Security reasons and also to avoid it been spent by unauthorized persons.We have been deliberating on how to invest this fund abroad in a confidential manner until we came to a conclusion to use it to buy houses and part of it will be used for non-speculative investments in your country.However,the current civilian administration of retired General Olusegun Obasanjo(The President of the Federal Republic of Nigeria) is seeking vengeance on the Abacha family because of the life prison jail sentence confirmed on him by my late husband while in office. In pursuit of this vendetta,the present Government have resolved to freeze all known assets of General Sani Abacha including properties at home and abroad and are presently embarking on to seize the various bank accounts of my husband in Switzerland,UK and Australia. In fact, the attack on our family (The Abacha's) is so devastated to an extent of seizing our travelling passport,family accounts and even trying some members of our family in court for offences allegedly committed by my late husband..My first son Mohammed Abacha who was arristed and incacerated for the past 3years was just reliese from prison on the agreement to refund $1.5 Billion to the Federal Government of Nigeria allegedly stollen by my late Husband.We are not ready to comply to this as most of the family assets and bank accounts abroad have been Freezen by the Obasanjo regime. In view of this grevious threat to our Economic and personal survival,our family trustee have secretly protected the will,The Security Company has called me to do something about claiming this consignment because of the demurrage it is incurring and I told them we would come and claim it very soon but they seriously advised me to move the fund into an overseas amount, hence the reason why I have chosen you and hope that you will come to my full assistance and unlimited co-operation.In the meantime,there is a travelling embargo on us(the whole family members) and our local accounts are seized. We are currently living on goodwill of people who believe we cannot be held responsible for the sins of my late husband. In view of this plight, I expect you to be trustworthy and kind enough to respond to this distressed call to save me and my children from a hopeless future. And if you agree to help, we will compensate you sincerely for your candid effort in this regard with 25% of the total amount of $20 Million US Dollars. In that case, when the money ($20 Million) is moved into your discrete account, you will be allowed to withdraw 25% in your favour,while 10% has been set aside for any expenses you might incur (There are demurrage to pay before the fund is sign and claimed by you.)during the process of securing this fund. The remaining 65% will be invested meaningfully for my children's future. My cousin (DR.HASSAN USMAN) has perfected arrangements with the Trust Company concerned and has been assured 100% risk free and safe operation.What I demand from you now is to arrange to visit the Finance Company where this money is being deposited and claim it as the bona-fide owner. And in due course, all contacts must be made through DR.HASSAN USMAN through his Telephone: 234-80-330-78104. E-mail address: hassan1@hknetmail.com or hassanus@rediffmail.com I look forward to your quick response while thanking you for your co-operation. In view of all above details, I request you to keep this letter and co-operation highly confidential. Best wishes, DR.(MRS). MARIAM ABACHA. ABACHAS LODGE,KANO. -------------------------------------------------------------------- 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 Aug 6 13:25:52 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25548 for ; Wed, 6 Aug 2003 13:25:51 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h76HN07W023439; Wed, 6 Aug 2003 19:23:01 +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 QL9BS6FX; Wed, 6 Aug 2003 19:26:54 +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 h76HMxxa003471; Wed, 6 Aug 2003 19:22:59 +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 h76HJXme020398; Wed, 6 Aug 2003 19:19:33 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h76HJXsF020397; Wed, 6 Aug 2003 19:19: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 yahoo.com (host201-77.pool217141.interbusiness.it [217.141.77.201]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with SMTP id h76HJSme020382; Wed, 6 Aug 2003 19:19:29 +0200 (MET DST) Message-ID: <80a901c35c3c$5767f610$fe365503@scsproxcttg> Reply-To: larameds2003eebw@yahoo.com From: larameds2003eebw@yahoo.com To: AOL@standards.ericsson.net, Users@standards.ericsson.net Subject: TkwhruflaRe: your request Date: Thu, 07 Aug 2003 02:01:13 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIME-Autoconverted: from base64 to 8bit by sw.ericsson.se id h76HJWme020384 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tjatte.sw.ericsson.se id h76HMxxa003471 Content-Transfer-Encoding: quoted-printable Qqhmv Health Care is a major problem in the U.S.... Insurance companies have raised premiums 30% or more and businesses are cutting back on giving hea= lt insurance... =20 Walking around without any health care protection is like playing Russian roulette with yourself and your family. Click Here For A FREE Health Care Consultation. National Health Care Plan's Complete Care Plan is designed for the follow= ing: =BB Everyone Gets Accepted! =BB Pre-Existing Conditions are OK!!! =BB Personal or family emergency's ($3000 Accident Protection) =BB Discounts up to 80% on medical services =BB Discounts up to 80% off on prescription drugs =BB Dental exams & X-Rays at no charge =BB Doctor Visits & Chiropractic Care as Low as $20 =BB Eye Exams only $35 =20 Stop Receiving the offers -------------------------------------------------------------------- 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 Aug 7 04:31:36 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04505 for ; Thu, 7 Aug 2003 04:31:35 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h778Sp7W029703; Thu, 7 Aug 2003 10:28:52 +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 QL80C6MC; Thu, 7 Aug 2003 10:28:51 +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 h778Soxa012254; Thu, 7 Aug 2003 10:28: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 h778PCme023660; Thu, 7 Aug 2003 10:25:12 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h778PC9n023659; Thu, 7 Aug 2003 10:25: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 albatross-ext.wise.edt.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 h778PBme023654 for ; Thu, 7 Aug 2003 10:25:11 +0200 (MET DST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h778PB7W028896 for ; Thu, 7 Aug 2003 10:25:11 +0200 (MEST) Received: from ESEALNT444.al.sw.ericsson.se ([153.88.251.48]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL9BXR2F; Thu, 7 Aug 2003 10:29:06 +0200 Received: by esealnt444 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Aug 2003 10:26:05 +0200 Message-ID: <5C4558D7439F544BB750F319BF15BC23C448B1@esealmw110> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: =?ISO-8859-1?Q?John_Klasa_=28=C4L/EAB=29?= To: "'ietf-send@standards.ericsson.net'" Subject: test pls ignore Date: Thu, 7 Aug 2003 10:25:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Precedence: bulk X-SMTP-HELO: mail.telia.com X-SMTP-MAIL-FROM: john.klasa@telia.com X-SMTP-RCPT-TO: john.klasa@ericsson.com -------------------------------------------------------------------- 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 Aug 7 09:59:53 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12920 for ; Thu, 7 Aug 2003 09:59:52 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h77DvbgM002270; Thu, 7 Aug 2003 15:57: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 QL80FRR4; Thu, 7 Aug 2003 15:57:37 +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 h77Dvaxa019904; Thu, 7 Aug 2003 15:57: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 h77DsAme004677; Thu, 7 Aug 2003 15:54:10 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h77DsAOx004676; Thu, 7 Aug 2003 15:54: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 fep20-app.kolumbus.fi (fep20-0.kolumbus.fi [193.229.0.47]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h77Ds9me004672 for ; Thu, 7 Aug 2003 15:54:09 +0200 (MET DST) Received: from mta.imail.kolumbus.fi ([193.229.5.110]) by fep20-app.kolumbus.fi with ESMTP id <20030807135408.HVVE26118.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi>; Thu, 7 Aug 2003 16:54:08 +0300 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: Type tags and pseudo-messages Date: Thu, 7 Aug 2003 16:54:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030807135408.HVVE26118.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > Yes, you can do that. Except that I would prefer the value to be > really generated in random. (Two "random" values invented by > C001 D00Ds are more likely to collide than two random numbers.)) Ok! >>> Current document includes the whole packet under the digital >>> signature. This includes therefore also the ICMP Type. Would >>> that be sufficient with a single tag value for SEND? > > > If, indeed, the whole packet is signed, then the SEND needs only > one tag value because the ICMP Type can be used to differentiate > between SEND messages. Otherwise, it is a matter of taste where > to put the part of the type tag that differentiates between the > different SEND messages. The way the new CGA spec is written, it > allows for consecutive type tag values to be used for SEND messages, > starting from a random one. But I'm just as happy to use only one > tag for SEND. Ok, lets do that then. > BTW, I believe that we should not be signing the entire packet. > I'd rather define pseudo-message that contains only the relevant > fields and sign that. Some arguments for signing pseudo-messages: > > (1) We need to define some kind of pseudo-messages anyway because > some IP header fields and the signature itself need to be excluded > from the signed part. Not the header fields, since this is local traffic. Francis pointed this out earlier. But yes for the signature itself. > (2) If the entire packet is singed, it becomes necessary to guess > the size of the signature before signing. This may be relatively easy > but ugly anyway. Yes. > (3) Protocol extensions, such as proxy ND and RD, may need to > include the signed SEND message in another message or to have > multiple signatures on a single SEND message. Perhaps. But I think its more likely that we'd have a Certificate option somewhere to carry the authorization of the original address owner to the new node. Allright. How about this text: Digital Signature This variable length field contains the signature made using the sender's private key, over the the following sequence of octets: 1. The 128-bit CGA Message Type [27] value for SEND, 0xXXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX (To be generated randomly). 2. The 128-bit Source Address field from the IP header. 3. The 128-bit Destination Address field from the IP header. 4. The 32-bit ICMP header, i.e., the Type, Code, and Checksum fields. 5. The Neighbor Discovery message header, i.e., the Reserved field in the Router Solicitation message, the Cur Hop Limit, M, O, Reserved, Router Lifetime, Reachable Time, and Retrans Timer fields in the Router Advertisement message, Reserved and Target Address fields in the Neighbor Solicitation message, R, S, O, Reserved, and Target Address fields in the Neighbor Advertisement message, and Reserved, Target Address, and Destination Address fields in the Redirect message. 6. All options preceding the Signature option. -------------------------------------------------------------------- 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 Aug 7 10:24:43 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16451 for ; Thu, 7 Aug 2003 10:24:42 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h77EMm7W017753; Thu, 7 Aug 2003 16:22:48 +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 QL80FY14; Thu, 7 Aug 2003 16:22:47 +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 h77EMdxR017169; Thu, 7 Aug 2003 16:22: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 h77EJUme008390; Thu, 7 Aug 2003 16:19:30 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h77EJUgl008388; Thu, 7 Aug 2003 16:19:30 +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 h77EJRme008381 for ; Thu, 7 Aug 2003 16:19:28 +0200 (MET DST) Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Aug 2003 07:19:30 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Aug 2003 07:19:20 -0700 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 07 Aug 2003 07:19:23 -0700 Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Aug 2003 07:19: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: RE: Type tags and pseudo-messages Date: Thu, 7 Aug 2003 07:18:38 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F09D63A4E@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: Type tags and pseudo-messages Thread-Index: AcNc629VH2qP71TuQR2Xfc4PoHiufAAAugZw From: "Tuomas Aura" To: Cc: X-OriginalArrivalTime: 07 Aug 2003 14:19:29.0336 (UTC) FILETIME=[E9F0F380:01C35CEE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h77EJSme008382 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Sounds good to me. Is far as I can see, this is unambiguous and easy to compute. Tuomas Jari wore: > Digital Signature > > This variable length field contains the signature made using the > sender's private key, over the the following sequence of octets: > > 1. The 128-bit CGA Message Type [27] value for SEND, 0xXXXX XXXX > XXXX XXXX XXXX XXXX XXXX XXXX (To be generated randomly). > > 2. The 128-bit Source Address field from the IP header. > > 3. The 128-bit Destination Address field from the IP header. > > 4. The 32-bit ICMP header, i.e., the Type, Code, and Checksum > fields. > > 5. The Neighbor Discovery message header, i.e., the Reserved > field in the Router Solicitation message, the Cur Hop Limit, > M, O, Reserved, Router Lifetime, Reachable Time, and Retrans > Timer fields in the Router Advertisement message, Reserved and > Target Address fields in the Neighbor Solicitation message, R, > S, O, Reserved, and Target Address fields in the Neighbor > Advertisement message, and Reserved, Target Address, and > Destination Address fields in the Redirect message. > > 6. All options preceding the Signature option. -------------------------------------------------------------------- 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 Aug 7 10:28:06 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16590 for ; Thu, 7 Aug 2003 10:28:05 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h77EQQgM008280; Thu, 7 Aug 2003 16:26:26 +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 QL9JWQ9Z; Thu, 7 Aug 2003 16:26:25 +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 h77EQPxR017278; Thu, 7 Aug 2003 16:26:25 +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 h77ENbme008742; Thu, 7 Aug 2003 16:23:37 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h77ENbRn008741; Thu, 7 Aug 2003 16:23: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 zdemail04.zdem.compaq.com (zdemail04.zdem.compaq.com [161.114.112.28]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h77EName008727 for ; Thu, 7 Aug 2003 16:23:36 +0200 (MET DST) Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.86.63]) by zdemail04.zdem.compaq.com (Postfix) with ESMTP id CA3B0E47 for ; Thu, 7 Aug 2003 16:23:33 +0200 (CEST) Received: from frqexc01.emea.cpqcorp.net ([16.188.101.34]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 7 Aug 2003 16:23:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35CEF.7AF08318" Subject: Just another test, ignore Date: Thu, 7 Aug 2003 16:23:32 +0200 Message-ID: Thread-Topic: Just another test, ignore Thread-Index: AcNc73l9zOgJK7i/R6qqC4VqewsL0w== From: "Westerback, Hans" To: X-OriginalArrivalTime: 07 Aug 2003 14:23:33.0520 (UTC) FILETIME=[7B7C7900:01C35CEF] Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C35CEF.7AF08318 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hans Westerback=20 Hewlett-Packard Sverige AB UNIX Server Operations @ Ericsson Visiting Adress: G=F6talandsv=E4gen 230, =C4lvsj=F6 Tel: +46-8-568 626 52 Fax: +46-8-568 60 200 mailto:hans.westerback@hp.com =20 ------_=_NextPart_001_01C35CEF.7AF08318 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just another test, ignore

Hans Westerback
Hewlett-Packard Sverige AB
UNIX Server Operations @ Ericsson
Visiting Adress: G=F6talandsv=E4gen = 230, =C4lvsj=F6
Tel: +46-8-568 626 52
Fax: +46-8-568 60 200
mailto:hans.westerback@hp.com


=A0


------_=_NextPart_001_01C35CEF.7AF08318-- -------------------------------------------------------------------- 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 Aug 15 16:43:42 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13183 for ; Fri, 15 Aug 2003 16:43:40 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7FKeJ7W013778; Fri, 15 Aug 2003 22:40:19 +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 Q9LK9SHH; Fri, 15 Aug 2003 22:40: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 h7FKe9xR025464; Fri, 15 Aug 2003 22:40:09 +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 h7FKaKme003294; Fri, 15 Aug 2003 22:36:20 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7FKaK3v003293; Fri, 15 Aug 2003 22:36:20 +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 h7FKaHme003288 for ; Fri, 15 Aug 2003 22:36:18 +0200 (MET DST) Message-ID: <03a201c3636c$e84e76e0$976015ac@dclkempt40> From: "James Kempf" To: Subject: Call for Journal Papers: Next Generation Mobile Security Date: Fri, 15 Aug 2003 13:36:29 -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 Wireless Personal Communications special issue on: "Security for Next Generation Mobile Communications" Guest Editors: Anand Prasad, DoCoMo Comm. Labs. Europe GmbH James Kempf, DoCoMo Comm. Labs. USA, Inc. The special session on "Security for Next Generation Mobile Communications" in WPMC 2003 held in Yokosuka, Japan, received five high quality papers which inspired the editors of the Kulwer journal to publish a special issue. This call for papers requests researchers interested in publishing a high quality paper in the field of next generation communications security for mobile communications systems to contribute papers to the journal. We are moving towards an era where "always-on" devices will provide communication anywhere, anytime and any kind of service. The "always-on" mobile device usage model faces new security issues. Long term secure sessions and simple security for multiple services challenge the current state of security technology. In addition, the trend towards heterogeneous networks, also known as "Beyond 3G" or B3G, integrates various heterogeneous access network technologies underneath a common IP layer. The different access network technologies have their own security requirements and mechanisms, making the integration of multiple access technologies for simple network access more challenging. In addition, many existing security protocols re- implement common security operations at different layers of the stack. A more modularized architecture, allowing common operations like certificate exchanged to be reused, would simplify many protocols and reduce implementation overhead. Finally, the trend toward software defined radio may require a new approach to security in order to accommodate dynamically reconfigurable spectrum usage. In this special issue our focus will be particularly on network layer security for next generation mobile networks. Possible topics are: . Modularized security architectures and implementations for reduced footprint, . Security issues related to mobility in heterogonous networks . Location privacy, . Opportunistic security, . Security for ad hoc networks, . Lightweight security infrastructure (ex. lightweight key distribution), . Bridging the divide between traditional AAA and e-commerce techniques for authentication and authorization, . Security techniques for software defined radio and dynamic spectrum usage. More information about the journal, including formatting instructions, can be found at: http://www.kluweronline.com/issn/0929-6212 Important dates: Submission of manuscripts : 1 December 2003 Notification of acceptance : 1 March 2004 Final Manuscripts Due : 1 April 2004 Publication of Feature Topic : second half 2004 Submissions should be sent to one of the guest editors: Anand R. Prasad Dr. James Kempf DoCoMo Comm. Labs. Europe GmbH DoCoMo Comm. Labs. USA, Inc. Landsberger strasse 308-312 181 Metro Drive, Suite 300 80687 Munich San Jose, CA 95110 Germany USA E-mail: prasad@docomolab-euro.com E-mail: kempf@docomolabs-usa.com -------------------------------------------------------------------- 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 Aug 21 14:14:30 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18342 for ; Thu, 21 Aug 2003 14:14:29 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7LIB6Av001033; Thu, 21 Aug 2003 20:11:10 +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 Q9LMN8YY; Thu, 21 Aug 2003 20:11:06 +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 h7LIB4xa029879; Thu, 21 Aug 2003 20:11:04 +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 h7LI76me014772; Thu, 21 Aug 2003 20:07:06 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7LI76f4014771; Thu, 21 Aug 2003 20:07: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 fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h7LI74me014767 for ; Thu, 21 Aug 2003 20:07:04 +0200 (MET DST) Received: from kolumbus.fi ([62.248.146.248]) by fep06-app.kolumbus.fi with ESMTP id <20030821180625.QPRS2570.fep06-app.kolumbus.fi@kolumbus.fi>; Thu, 21 Aug 2003 21:06:25 +0300 Message-ID: <3F4509A6.6080001@kolumbus.fi> Date: Thu, 21 Aug 2003 21:04:22 +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: Francis Dupont CC: SEND WG Subject: issue 18: aaa interactions 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, I'm going through the open issues we have in the SEND protocol. One of them was raised by you Francis on AAA interactions. Here's the discussion we had: > Francis Dupont writes: "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! > > ------ > > Jari Arkko responds to Francis Dupont: Do you have a specific > suggestion regarding the interaction? Do you wish to download certs > from the AAA, or what? Now, I've been thinking about this a little bit. If this is *only* about the discovery of the cert chains via AAA, then it might be that, for instance, the 802.11 link layer authentication process has already learned something about the network's certificates. For instance, if 802.11 is running EAP TLS, and the authentication is terminated directly at the AP/router, then the host already has the cert chain from a trusted root to the router. The only question at that point is whether the cert chain is usable for other purpose, i.e. whether the authorizations are sufficient for both purposes. TLS certs are a bit special, as are SEND certs... Also, cert-based authentication which terminates at the local router may be rare in practise. In any case, to move forward my proposal is that we simply add some text explaining that as a side effect of attaching to the network, it may be that the host already has some cert chains from the network, and that it MAY use them in order to optimize (skip) the SEND cert retrival. Does that work for you? --Jari P.S. The issue list is at http://www.piuha.net/~jarkko/publications/send/issues/ -------------------------------------------------------------------- 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 Aug 21 17:29:19 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01477 for ; Thu, 21 Aug 2003 17:29:18 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7LLQiAv021321; Thu, 21 Aug 2003 23:26:44 +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 Q9LMPJBY; Thu, 21 Aug 2003 23:26: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 h7LLQVxR027382; Thu, 21 Aug 2003 23:26:33 +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 h7LLN9me008815; Thu, 21 Aug 2003 23:23:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7LLN9vW008814; Thu, 21 Aug 2003 23:23: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 fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h7LLN8me008810 for ; Thu, 21 Aug 2003 23:23:08 +0200 (MET DST) Received: from kolumbus.fi ([62.248.146.248]) by fep06-app.kolumbus.fi with ESMTP id <20030821212229.RSLP2570.fep06-app.kolumbus.fi@kolumbus.fi> for ; Fri, 22 Aug 2003 00:22:29 +0300 Message-ID: <3F45379A.6060800@kolumbus.fi> Date: Fri, 22 Aug 2003 00:20:26 +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: SEND WG Subject: issue 6: millisecond timestamp granularity 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 Issue 6 is about the granularity of timestamps in the SEND protocol. This is relevant for unsolicited advertisements, as I think we'll be using nonces for the others. If the granularity is coarse, the sender might have to delay sending the advertisement until real time advances into a new value within the given granularity. This is not a practical problem right now. OTOH it would be good to design the protocol so that we won't hit a hard limit, should something change in the future. Michael Richardsson made a suggestion in Vienna that we move to fixed point binary scheme, perhaps allocating 16 bits for the fractions of the second. This would be about 20 microseconds granularity. (Clearly, if you clocks don't have this granularity, you can advance them in bigger steps.) I like Michael's suggestion. It seems simple to implement. Lets do it. Any objections? --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 Aug 21 18:10:48 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04116 for ; Thu, 21 Aug 2003 18:10:47 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7LM6931009619; Fri, 22 Aug 2003 00:06: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 Q9LMPQ3H; Fri, 22 Aug 2003 00:06:08 +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 h7LM67xR027991; Fri, 22 Aug 2003 00:06: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 h7LM2tme013882; Fri, 22 Aug 2003 00:02:55 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7LM2shU013881; Fri, 22 Aug 2003 00:02: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 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 h7LM2qme013875 for ; Fri, 22 Aug 2003 00:02:53 +0200 (MET DST) Message-ID: <021401c3682f$fc4ef350$806015ac@dclkempt40> From: "James Kempf" To: "Jari Arkko" , "SEND WG" References: <3F45379A.6060800@kolumbus.fi> Subject: Re: issue 6: millisecond timestamp granularity Date: Thu, 21 Aug 2003 15:02:59 -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 Sounds fine to me. jak ----- Original Message ----- From: "Jari Arkko" To: "SEND WG" Sent: Thursday, August 21, 2003 2:20 PM Subject: issue 6: millisecond timestamp granularity > > Issue 6 is about the granularity of timestamps in the SEND > protocol. This is relevant for unsolicited advertisements, > as I think we'll be using nonces for the others. > > If the granularity is coarse, the sender might have to > delay sending the advertisement until real time advances > into a new value within the given granularity. This > is not a practical problem right now. OTOH it would > be good to design the protocol so that we won't hit a hard > limit, should something change in the future. > > Michael Richardsson made a suggestion in Vienna that > we move to fixed point binary scheme, perhaps allocating > 16 bits for the fractions of the second. This would be > about 20 microseconds granularity. (Clearly, if you > clocks don't have this granularity, you can advance them > in bigger steps.) > > I like Michael's suggestion. It seems simple to > implement. Lets do it. Any objections? > > --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 Thu Aug 21 18:53:53 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07251 for ; Thu, 21 Aug 2003 18:53:52 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7LMplAv029436; Fri, 22 Aug 2003 00:51:47 +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 QXY03TA7; Fri, 22 Aug 2003 00:52:15 +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 h7LMpkxa002522; Fri, 22 Aug 2003 00:51:46 +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 h7LMmHme019030; Fri, 22 Aug 2003 00:48:17 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7LMmH2o019029; Fri, 22 Aug 2003 00:48: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 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 h7LMmEme019024 for ; Fri, 22 Aug 2003 00:48:15 +0200 (MET DST) Message-ID: <024801c36836$562e6670$806015ac@dclkempt40> From: "James Kempf" To: Subject: Issue 24: Does 802.1X help against issues not handled in SEND? Date: Thu, 21 Aug 2003 15:48:27 -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 Issue 24 was raised by one of the reviewers: >> - 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. Specifically, the attack that is mentioned in the Security Considerations section is: > On an insecure link layer that > allows nodes to spoof the link layer address of other nodes, an > attacker could disrupt IP service by sending out a Neighbor > Advertisement having the source address on the link layer frame of a > victim, a valid CGA with valid AH signature corresponding to itself, > and a Target Link-layer Address extension corresponding to the > victim. The attacker could then proceed to cause a traffic stream to > bombard the victim in a DoS attack. The 802.1x standard [0] provides a mechanism by which a host can be authenticated to a particular point of attachment to a LAN (called a "port" in the standard). If the MAC on frames sent by a host does not correspond to the MAC of the host originally authenticated to this port, then the point of attachment drops the frames. Authorization to use the port is determined by the MAC address of the host that originally authenticated to the port. The way 802.1x protects against this attack is that, if a host authenticated to a particular port attempts to spoof the MAC address of another host, the port will drop the frames. Naturally, this requires that all ports by which hosts can attach to the LAN use 802.1x authentication. In addition, this won't work for shared media such as multiple hosts authenticated through the same 802.11 AP (which acts as a single port for all hosts), but it will work on 802.3 switched LANs. 802.1x does not provide protection for the layer 2 frame - layer 3 packet address binding in traffic (that is, real time filtering to check this binding), and neither does SEND. 802.1x provides authentication and filtering of MAC address to port, SEND provides protection for the layer 2 - layer 3 binding *information* in the ND packet, via the CGA address (authorization to use the address via the public key) and the signature on the packet (authentication of contents as from authorized IP address possessor). IEEE is additionally starting some work on secure link layer (see: http://www.ieee802.org/linksec/ for more information) that might result in modifications to the 802 link security architecture. These may possibly eliminate any residual threats. Comments? jak [0] IEEE, "Port Based Access Control", IEEE Std 802.1X-2001, June, 2001. -------------------------------------------------------------------- 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 Aug 21 21:12:53 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12483 for ; Thu, 21 Aug 2003 21:12:52 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7M0snAv011629; Fri, 22 Aug 2003 02:54:49 +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 QY1JZBKX; Fri, 22 Aug 2003 02:55:25 +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 h7M0smxa003883; Fri, 22 Aug 2003 02:54:48 +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 h7M0pRme005778; Fri, 22 Aug 2003 02:51:27 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7M0pRIX005777; Fri, 22 Aug 2003 02:51: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 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 h7M0pNme005771 for ; Fri, 22 Aug 2003 02:51:24 +0200 (MET DST) Date: Thu, 21 Aug 2003 17:53:10 -0700 Subject: Re: issue 18: aaa interactions From: Alper Yegin To: Jari Arkko , Francis Dupont CC: SEND WG Message-ID: In-Reply-To: <3F4509A6.6080001@kolumbus.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > In any case, to move forward my proposal is that we simply > add some text explaining that as a side effect of attaching > to the network, it may be that the host already has some > cert chains from the network, and that it MAY use them in > order to optimize (skip) the SEND cert retrival. Does > that work for you? It might even be the case that the cert used is not part of any chain and the solution does not rely on global PKI. For example, a more practical solution could be to deliver a public key for the visited domain to the host during the access AAA. This PK can be produced by the access network and its delivery to the host can be protected by the local security association created during AAA. This solution skips the cert chain discovery and removes the dependency on any PKI. Furthermore, we shouldn't even assume that secure router discovery will always be used along with secure neighbor discovery. One can run a network where potentially malicious hosts are always on one side of a bridge and the bridge filters "router advertisements" coming from that side. Alper -------------------------------------------------------------------- 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 Aug 21 22:58:14 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16562 for ; Thu, 21 Aug 2003 22:58:14 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7M2ZE31028247; Fri, 22 Aug 2003 04:35:14 +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 QXY0PXM4; Fri, 22 Aug 2003 04:35: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 h7M2ZAxR001533; Fri, 22 Aug 2003 04: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 h7M2Vime024489; Fri, 22 Aug 2003 04:31:44 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7M2VihL024488; Fri, 22 Aug 2003 04:31: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 ftmail.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 h7M2Veme024481 for ; Fri, 22 Aug 2003 04:31:40 +0200 (MET DST) Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 21 Aug 2003 22:31:37 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CA6@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alper Yegin'" , Jari Arkko , Francis Dupont Cc: SEND WG Subject: RE: issue 18: aaa interactions Date: Thu, 21 Aug 2003 22:31:35 -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 > Furthermore, we shouldn't even assume that secure router > discovery will > always be used along with secure neighbor discovery. One can > run a network > where potentially malicious hosts are always on one side of > a bridge and the > bridge filters "router advertisements" coming from that side. => Yes, which should be done anyway. Can this recommendation make its way to the draft somehow? Hesham > > Alper > > -------------------------------------------------------------------- > 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 Fri Aug 22 04:30:42 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10854 for ; Fri, 22 Aug 2003 04:30:41 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7M8OWAv012041; Fri, 22 Aug 2003 10:24:32 +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 Q9LMTN3B; Fri, 22 Aug 2003 10:24:31 +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 h7M8OVxa008329; Fri, 22 Aug 2003 10:24:31 +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 h7M8Jjme012985; Fri, 22 Aug 2003 10:19:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7M8JjmJ012984; Fri, 22 Aug 2003 10:19: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 mailout2.samsung.com ([203.254.224.25]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h7M8Jgme012953 for ; Fri, 22 Aug 2003 10:19:44 +0200 (MET DST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HK000004HR9U3@mailout2.samsung.com> for ietf-send@standards.ericsson.net; Fri, 22 Aug 2003 17:18:45 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HK000AW9HR84V@mailout2.samsung.com> for ietf-send@standards.ericsson.net; Fri, 22 Aug 2003 17:18:45 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HK000B9NHR8KV@mmp1.samsung.com> for ietf-send@standards.ericsson.net; Fri, 22 Aug 2003 17:18:44 +0900 (KST) Date: Fri, 22 Aug 2003 17:19:14 +0900 From: Soohong Daniel Park Subject: RE: I-D ACTION:draft-ietf-send-cga-01.txt In-reply-to: <200308041415.KAA27540@ietf.org> To: ietf-send@standards.ericsson.net Cc: tuomaura@microsoft.com Message-id: <005401c36886$12a02f60$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi SEND Simple questions If we use a cga mechanism on the all host, don't we need a DAD procedure to verify the address uniqueness ? or not related ? Thanks Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics -------------------------------------------------------------------- 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 Aug 22 05:48:08 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13873 for ; Fri, 22 Aug 2003 05:48:08 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7M9gD31000685; Fri, 22 Aug 2003 11:42:13 +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 Q9LM4GMZ; Fri, 22 Aug 2003 11:42:12 +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 h7M9gCxa009543; Fri, 22 Aug 2003 11:42:12 +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 h7M9cpme022246; Fri, 22 Aug 2003 11:38:51 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7M9cpMA022245; Fri, 22 Aug 2003 11:38: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 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 h7M9cnme022240 for ; Fri, 22 Aug 2003 11:38:50 +0200 (MET DST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Aug 2003 02:38:48 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Aug 2003 02:38:52 -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); Fri, 22 Aug 2003 02:38:48 -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: Delegation chains starting from a CGA Date: Fri, 22 Aug 2003 02:37:14 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F0A012185@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: Delegation chains starting from a CGA Thread-Index: AcNoWUPifvI66cIqQtOeFHLjYZ6gnwANFzVA From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 22 Aug 2003 09:38:48.0223 (UTC) FILETIME=[300D4AF0:01C36891] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h7M9cpme022242 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit For proxy ND, it would be useful to be able to start a delegation chain from a CGA. That is, the public key that was used to generate the address would issue a certificate (or the first certificate in a chain) that authorizes another public key to sign ND messages for it. I think the only change required to the spec is a flag ("Proxy flag") in the Signature Option to indicate that the there is a delegation chain to be discovered that starts from the CGA public key. 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 Fri Aug 22 08:06:44 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19247 for ; Fri, 22 Aug 2003 08:06:43 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7MC2g31002821; Fri, 22 Aug 2003 14:02:42 +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 QY1J82C5; Fri, 22 Aug 2003 14:03: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 h7MC2XxR012254; Fri, 22 Aug 2003 14:02:34 +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 h7MBx9me009271; Fri, 22 Aug 2003 13:59:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7MBx9W5009270; Fri, 22 Aug 2003 13:59: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 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 h7MBx7me009266 for ; Fri, 22 Aug 2003 13:59:08 +0200 (MET DST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Aug 2003 04:59:06 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Aug 2003 02:12:11 -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); Fri, 22 Aug 2003 02:12:10 -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: RE: I-D ACTION:draft-ietf-send-cga-01.txt Date: Fri, 22 Aug 2003 02:10:36 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F0A012184@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: I-D ACTION:draft-ietf-send-cga-01.txt Thread-Index: AcNohjAq59jKO/ElQ7WevPQwY4v8KAAAIiLA From: "Tuomas Aura" To: "Soohong Daniel Park" , X-OriginalArrivalTime: 22 Aug 2003 09:12:10.0061 (UTC) FILETIME=[77791FD0:01C3688D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h7MBx8me009267 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit There was some discussion on CGA and DAD on this list in July. There are arguments both for and against DAD. CGA addresses have at least 59 bits of entropy and accidental collisions are very unlikely. On the other hand, implementation and configuration errors might lead to collisions. But the "to DAD or not to DAD" question is not specific to CGA addresses. Exactly the same arguments apply to RFC-3041 addresses (which have 62 bits of entropy if generated with a good PRNG; slightly less if generated as specified in RFC 3041). EUI-64 identifiers are, in theory, unique. However, the widespread practice of cloning MAC addresses makes occasional collisions between two EUI-64s quite likely. Conclusion: The DAD question is not specific to CGA addresses. Therefore, it should be discusses separately from SEND. For the time being, we assume that DAD is required. Tuomas > -----Original Message----- > From: Soohong Daniel Park [mailto:soohong.park@samsung.com] > Sent: 22 August 2003 09:19 > To: ietf-send@standards.ericsson.net > Cc: Tuomas Aura > Subject: RE: I-D ACTION:draft-ietf-send-cga-01.txt > > Hi SEND > > Simple questions > > If we use a cga mechanism on the all host, don't we > need a DAD procedure to verify the address uniqueness ? > or not related ? > > Thanks > > Daniel (Soohong Daniel Park) > Mobile Platform Lab,SAMSUNG Electronics > > > > -------------------------------------------------------------------- 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 Aug 22 11:57:33 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04223 for ; Fri, 22 Aug 2003 11:57:32 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7MFrbAv029058; Fri, 22 Aug 2003 17:53:37 +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 QXYZ4X1Y; Fri, 22 Aug 2003 17:53:37 +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 h7MFraxa017625; Fri, 22 Aug 2003 17:53: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 h7MFnKme007675; Fri, 22 Aug 2003 17:49:20 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7MFnK5A007674; Fri, 22 Aug 2003 17:49:20 +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 h7MFnHme007667 for ; Fri, 22 Aug 2003 17:49:18 +0200 (MET DST) Message-ID: <010901c368c4$ddb41070$806015ac@dclkempt40> From: "James Kempf" To: "Soohong Daniel Park" , Cc: References: <005401c36886$12a02f60$b7cbdba8@daniel7209> Subject: Re: I-D ACTION:draft-ietf-send-cga-01.txt Date: Fri, 22 Aug 2003 08:48:43 -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 Statistically, there is always the probability of conflict. The probability is miniscule if the random number generator used to generate the keys is good enough, but there is always a probability. jak ----- Original Message ----- From: "Soohong Daniel Park" To: Cc: Sent: Friday, August 22, 2003 1:19 AM Subject: RE: I-D ACTION:draft-ietf-send-cga-01.txt > Hi SEND > > Simple questions > > If we use a cga mechanism on the all host, don't we > need a DAD procedure to verify the address uniqueness ? > or not related ? > > Thanks > > Daniel (Soohong Daniel Park) > Mobile Platform Lab,SAMSUNG Electronics > > > > > -------------------------------------------------------------------- > 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 Aug 24 23:57:02 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10064 for ; Sun, 24 Aug 2003 23:57:01 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7P3r7Av023722; Mon, 25 Aug 2003 05:53:07 +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 QXY5CXZS; Mon, 25 Aug 2003 05:53:06 +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 h7P3r5xa014733; Mon, 25 Aug 2003 05:53:05 +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 h7P3n4me013637; Mon, 25 Aug 2003 05:49:04 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7P3n4S2013636; Mon, 25 Aug 2003 05:49: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 ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h7P3n1me013628 for ; Mon, 25 Aug 2003 05:49:02 +0200 (MET DST) Received: from localhost ([130.194.13.85]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KZVNT2WES88ZE1MK@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 25 Aug 2003 12:46:19 +1000 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id D7580159210; Mon, 25 Aug 2003 10:51:38 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id C7989120009; Mon, 25 Aug 2003 10:51:38 +1000 (EST) Date: Mon, 25 Aug 2003 10:51:38 +1000 From: Greg Daley Subject: Re: Delegation chains starting from a CGA To: Tuomas Aura Cc: SEND WG Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F495D9A.9030107@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <9805B5E65CD0D0479D08B7EB832B369F0A012185@red-msg-08.redmond.corp.microsoft.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Tuomas, Tuomas Aura wrote: > For proxy ND, it would be useful to be able to start > a delegation chain from a CGA. That is, the public > key that was used to generate the address would issue > a certificate (or the first certificate in a chain) > that authorizes another public key to sign ND messages > for it. > > I think the only change required to the spec is a flag > ("Proxy flag") in the Signature Option to indicate that > the there is a delegation chain to be discovered that > starts from the CGA public key. I think that so long as we have a reason to trust the MAC address provided by the proxying router, then this is OK. As an aside, is it safe to assume that proxy devices are routers? If it is, we should be able to send a DCS to the router, with a common root of the solicited address. (of course, we'd then have to have some sort of ND cache entry for that device). If there's no existing ND state (for example, if the router is non-RA advertising for a link, or doesn't set SLLAO in RA), we'd need to perform NS/NA (for the proxier) and then the DCS/DCA exchanges. This seems to be a lot of signalling when we don't actually trust the proxy advertisement. Not that this is a killer, if it is carefully controlled. Did you have something else in mind? Greg Daley -------------------------------------------------------------------- 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 Aug 25 13:11:31 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00345 for ; Mon, 25 Aug 2003 13:11:30 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7PH7FAv017242; Mon, 25 Aug 2003 19:07:18 +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 QXY52MMS; Mon, 25 Aug 2003 19:07: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 h7PH6wxR017339; Mon, 25 Aug 2003 19:06:58 +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 h7PH2wme004878; Mon, 25 Aug 2003 19:02:58 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7PH2wmZ004877; Mon, 25 Aug 2003 19:02: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 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 h7PH2ume004873 for ; Mon, 25 Aug 2003 19:02:56 +0200 (MET DST) Message-ID: <027101c36b2a$c2e7b770$806015ac@dclkempt40> From: "James Kempf" To: Subject: Issue 21: RA source is Link Local Date: Mon, 25 Aug 2003 10:03:09 -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 RFC 2461 requires that RAs be sent with a Link Local address. Issue 21 is whether the same restriction should be put on DCA. Proposed solution: yes. Comments? 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 Aug 25 15:03:27 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09683 for ; Mon, 25 Aug 2003 15:03:27 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7PJ0m31025334; Mon, 25 Aug 2003 21:00:48 +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 QXZALTL6; Mon, 25 Aug 2003 21:01:27 +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 h7PJ0exR019345; Mon, 25 Aug 2003 21:00: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 h7PIv7me018246; Mon, 25 Aug 2003 20:57:07 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7PIv7nb018245; Mon, 25 Aug 2003 20:57: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 h7PIv5me018233 for ; Mon, 25 Aug 2003 20:57:06 +0200 (MET DST) Message-ID: <030401c36b3a$b57a1d20$806015ac@dclkempt40> From: "James Kempf" To: Subject: Issue 14: Is CGA-only RD protection useful? Date: Mon, 25 Aug 2003 11:57:18 -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 Issue 14 received some discussion in Vienna. The question was raised by one of the reviewers whether having CGA-only protection on RAs would be sufficient for securing router discovery. This is independent of whether a router would use CGA for neighbor discovery. The best approach to an answer would seem to me to be to be to look at the threats to RD in draft-ietf-send-psreq-03.txt and see whether CGA protection will satisfy them. This email attempts that analysis. Threats to RD are described in Section 4.2 of draft-ietf-send-psreq-03.txt. The following threats are discussed: 1) Malicious Last Hop Router - the attacking node sends legitimate-looking IPv6 RAs, or responds to a victim node's RSs with legitimate-looking IPv6 RAs, in an attempt to get the victim to use it as the default router. 2) Default router is 'killed' - the attacking node uses one of a variety of means to spoof other nodes into believing that the default router on the link has died, in which case, by RFC 2461, the nodes revert to using link local addresses only. One of these means involves sending out a bogus RA for the default router with lifetime 0. 3) Bogus On-Link Prefix - the attacking node sends a spoofed subnet prefix to trick the victim into either using the prefix for an incorrect autoconfigured address or into thinking that the prefix is on-link so that the victim uses link local addressing instead of a global IPv6 unicast address, by sending a legitimate-seeming RA. 4) Bogus Link Parameters - the attacking node sends bogus link parameters (like whether or not stateful address configuration should be used) by sending a legitimate-seeming RA. The protection provided by CGAs is fairly simple: a receiver of a message signed by the sender and verifiable with the sender's public key has the assurance that the message was, in fact, sent from the CGA. In the absence of any network element or any additional processing between the router and the host, CGAs would seem insufficient to address all the threats above, though they would address 2, since the victim could clearly identify that the bogus RA did not issue from the legitimate default router. A malicious host could construct a CGA from its public key and use its private key to sign a bogus RA. The RA would be verifiable as issuing from the correct IPv6 address, but the RA would contain bogus information designed to launch an attack. Since there is no IP network element between the host and the router in the standard IP subnet architecture, this would suggest that CGA-only RD authentication is not sufficient to address all the threats. If, however, there exists a Layer 2 network element between the host and the router that is programmable such that it can perform sufficient Layer 3 processing to cryptographically verify the RA signature and filter on the CGA, then CGA-only RA security may be useful. The Layer 2 network element could be programmed with an ACL of CGAs for known good routers, and only pass RAs for those whose CGAs match the signatures and the ACL. Depending on the Layer 2 technology and the network element, some part of the subnet may still be vulnerable. For example, if the Layer 2 technology was multi-access prior to the filtering device, some number of hosts may be exposed to the bogus RA. Note that such a filtering device would still be subject to attack if CGAs were not employed, since the device could not verify the RA as issuing from the source address, providing an opening for an attacker. The following are possible actions the WG could take w.r.t. resolving this issue in the draft: A) Since the IP subnet architecture does not admit of devices between the host and router, the potential solution involving a Layer 2 filtering device is not of interest in an IETF standard. Therefore, the draft should state that CGA-only solutions are not sufficient for protecting RD in SEND. B) As a practical matter, some Layer 2 technologies of interest support such filtering devices, and adding the kind of Layer 3 filtering and network management functions described above to such devices for CGA-only protection is not all that difficult. Since a CGA-only solution may be simpler from a deployment and network management perspective in some networks than requiring routers to have certificates, the CGA-only solution should be fully articulated in a separate section in the draft. C) As in A), but mention the CGA-only solution in passing, and don't encourage it as a part of SEND. Suggest it is up to Layer 2 standardization bodies to incorporate this functionality in their specifications. WG members are encouraged to discuss these alternatives, express their preference, or suggest an additional alternative that I've missed. 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 Aug 25 18:18:02 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20204 for ; Mon, 25 Aug 2003 18:18:00 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7PMFxAv015128; Tue, 26 Aug 2003 00:15: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 Q9LNQR0Y; Tue, 26 Aug 2003 00:15:58 +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 h7PMFwxa029757; Tue, 26 Aug 2003 00:15:58 +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 h7PMCfme011764; Tue, 26 Aug 2003 00:12:41 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7PMCfiC011761; Tue, 26 Aug 2003 00:12: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 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 h7PMCcme011747 for ; Tue, 26 Aug 2003 00:12:39 +0200 (MET DST) Message-ID: <037b01c36b56$06a56d10$806015ac@dclkempt40> From: "James Kempf" To: Subject: Issue 20: Francis Dupont's certificate issue and the general issue of a Certificate Profile Date: Mon, 25 Aug 2003 15:12:51 -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 raised several issues about the certificate format in his review of the SEND draft. Rather than address these specific issues, however, I'd like to open the discussion somewhat wider, to include exactly what SEND should do w.r.t. a certificate profile for certifying advertised subnet prefixes by routers. A certificate profile for SEND seems advisable, since interoperability for certification verification is otherwise not assured, and such profiles have been necessary in other cases (example: TLS). The approach taken in draft-ietf-send-ipsec was to use RFC 3281 Attribute Certificates. The text in that draft specified certain conventions in using Attribute Certificates for SEND that would allow a host to determine whether a router was certified by a trusted intermediary to advertise a collection of subnet prefixes. Francis' comments addressed certain of the details specified in the draft that involved adapting Attribute Certificates to SEND. The specification in the draft did not include any support for certified prefix delegation. RFC 3281 forbids Attribute Certificate chains, so the specification included identity certification delegation through a chain of Identity Certificates, with the chain ending in an Attribute Certificate signed by the holder of the key certified in the last Identity Certificate. The host could certify the public key and thereby determine that the router was authorized to route the prefixes in the Attribute Certificate, but it couldn't trace back the prefix delegation. Subsequent discussion on the list and in Vienna established that some WG members wanted the ability to trace prefix delegation back to the trusted intermediary. There was some discussion in Vienna and on the list about modifying RFC 3281 to allow Attribute Certificate chains for this purpose. An alternative would be an Identity Certificate chain along with a set of paired Attribute Certificates for each prefix delegation. Russ Housley, AD for Security, recently advised Pekka and I that the PKIX WG has been dealing with the same issue in the context of SBGP. The goal there is to allow any entity that receives a prefix delegation - ISPs, enterprises, routers, etc. - to verify the delegation. The solution is described in draft-ietf-pkix-x509-ipaddr-as-extn-01.txt. This draft is now in Last Call in the PKIX WG. In this solution, no Attribute Certificates are used. Instead, the delegating entity adds a few attributes to a standard Identity Certificate and signs the certificate, thereby certifying the prefix delegation. The draft supports a variety of delegation designations, one being a prefix format similar to that specified in draft-ietf-send-ipsec. In Appendix C, the draft goes on to argue that Attribute Certificates are the wrong mechanism for address prefix delegation because: 1) The certificates used for prefix delegation are used exclusively for that purpose, so their lifetimes would match exactly that of an Identify Certificate used to certify identity. One reason for using Attribute Certificates cited in RFC 3281 is that the lifetimes of the attribute certification and identity certification would differ. 2) The certificate hierarchy is constructed so that the certificate issuer is also authoritative for the prefix delegation authorization. For example, if an ISP receives a certified delegation from an RIR, then the RIR is both the certificate issuer and the source of certification for the prefix delegation authorization. Another reason for using Attribute Certificates cited in RFC 3281 is that the issuer of the Identity Certificate and Attribute Certificate are different. Appendix C goes on to list several other requirements for applicability of Attribute Certificates in RFC 3281 that it claims are not applicable to certifying prefix delegation. With reference to the above discussion, the following are possible alternatives for generating a certificate profile: A) We could ignore prefix delegation and even prefix certification entirely, and just have the host certify the router's identity. The certificate profile would specify standard RFC 3280 Identity Certificates with perhaps some conventions on the name used for identity determination, but no special prefix attributes. Later, if prefix certification or delegation certification becomes important, the modified profile could be specified in a separate draft. B) We could ignore prefix delegation but provide support for prefix certification by using Attribute Certificates, as in draft-ietf-send-ipsec. Again, if delegation certification proved important, it could later be specified in a separate draft. C) We could support delegation using a parallel Attribute Certificate chain, along with the Identity Certificate chain. Each Attribute Certificate would be signed by the public key certified by the holder of the delgeating authority's Identity Certificate. Note that this might require a change in the DCA mechanism to handle the increased (potentially double) certificate exchange load. D) We could talk to Russ and Steve Bellovin about opening up RFC 3281 to allow Attribute Certificate chains to support prefix delegation certification. We would probably have to specify the certificate profile for SEND in a separate draft if we did this, since modifications for RFC 3281 might take a while. E) We could support delegation through using the mechanism described in draft-ietf-pkix-x509, with perhaps some minor specification of conventions to satisfy SEND requirements. Comment from the WG on these options, preferences, and any additional options that might have been missed is invited. 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 Aug 26 03:09:11 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20765 for ; Tue, 26 Aug 2003 03:09:10 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7Q76B31024393; Tue, 26 Aug 2003 09:06:12 +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 QY1KWKVW; Tue, 26 Aug 2003 09:07: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 h7Q75wxR029272; Tue, 26 Aug 2003 09:05:58 +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 h7Q71vme001074; Tue, 26 Aug 2003 09:01:57 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7Q71vWr001073; Tue, 26 Aug 2003 09:01:57 +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 h7Q71rme001064 for ; Tue, 26 Aug 2003 09:01:56 +0200 (MET DST) Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KZX8Y9QQ9K8ZE4PQ@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Tue, 26 Aug 2003 16:02:06 +1000 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 85E22158005; Tue, 26 Aug 2003 16:02:05 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id 72C2412000A; Tue, 26 Aug 2003 16:02:05 +1000 (EST) Date: Tue, 26 Aug 2003 16:02:05 +1000 From: Greg Daley Subject: Re: Issue 21: RA source is Link Local To: James Kempf Cc: ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F4AF7DD.2010608@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: <027101c36b2a$c2e7b770$806015ac@dclkempt40> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: > RFC 2461 requires that RAs be sent with a Link Local address. Issue 21 is > whether the same restriction should be put on DCA. > > Proposed solution: yes. > > Comments? I've got some odd ideas for wanting to do DCA from off-network, but understand that in general on-link only is best. Is there any effective difference between requiring link-local and requiring ttl of 255 (with LL or global)? 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 Tue Aug 26 12:02:44 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12452 for ; Tue, 26 Aug 2003 12:02:43 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7QG02Av028939; Tue, 26 Aug 2003 18:00:05 +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 QXZA40VS; Tue, 26 Aug 2003 18:00:43 +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 h7QFxtxa019602; Tue, 26 Aug 2003 17:59: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 h7QFuQme005703; Tue, 26 Aug 2003 17:56:26 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7QFuQQa005702; Tue, 26 Aug 2003 17:56: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 h7QFuOme005698 for ; Tue, 26 Aug 2003 17:56:25 +0200 (MET DST) Message-ID: <00b601c36bea$9fd8a300$806015ac@dclkempt40> From: "James Kempf" To: Cc: References: <027101c36b2a$c2e7b770$806015ac@dclkempt40> <3F4AF7DD.2010608@eng.monash.edu.au> Subject: Re: Issue 21: RA source is Link Local Date: Tue, 26 Aug 2003 08:56: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 > > RFC 2461 requires that RAs be sent with a Link Local address. Issue 21 is > > whether the same restriction should be put on DCA. > > > > Proposed solution: yes. > > > > Comments? > > I've got some odd ideas for wanting to do DCA > from off-network, but understand that in general > on-link only is best. > > Is there any effective difference between requiring > link-local and requiring ttl of 255 (with LL or global)? > TTL of 255 and dropping any received packet with a TTL less than that will effectively limit to on link. Link local addresses are an additional mechanism for that, and having DCA use them is consistent with RFC 2461, which is why it is being recommended. In general, I'm not sure it is advisable to do DCA from off-link. There is an issue with fragmentation. Certs tend to be large, and if they are sent using UDP multihop, they can get fragmented and dropped by routers that don't handle fragmentation properly, which typically isn't a problem with a single link. This problem occurs frequently with IKE, for example, and the IPsec WG has yet to face up to how to handle it. The design team discussed whether to put in mechanism to handle fragmentation or certificate compression, but it would make DCA much more complicated, and it is not clear at this point whether the extra complication is necessary, if the off link uses result from only 10% of the cases. If they are more like 50%, we can put in fragmentation support later. 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 Aug 26 13:51:42 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17059 for ; Tue, 26 Aug 2003 13:51:41 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7QHlv31003740; Tue, 26 Aug 2003 19:47:57 +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 QXY5QYRA; Tue, 26 Aug 2003 19:47:57 +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 h7QHltxa020920; Tue, 26 Aug 2003 19:47: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 h7QHiame018422; Tue, 26 Aug 2003 19:44:36 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7QHiaAw018421; Tue, 26 Aug 2003 19:44: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 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 h7QHiXme018414 for ; Tue, 26 Aug 2003 19:44:34 +0200 (MET DST) Received: (qmail 20137 invoked from network); 26 Aug 2003 17:44:32 -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 Aug 2003 17:44:32 -0000 Date: Tue, 26 Aug 2003 10:44:31 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: timestamp cache From: Jonathan Wood To: SEND WG Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'd like to get some clarification on timestamp management - what is going into the next draft? One thing which has not been clear to me thus far is what to do when the cache becomes full - how should we decide which entries to throw out? We need a strategy that does not allow an attacker to flush a timestamp cache with bogus entries as a prelude to performing a replay attack. Thanks, Jonathan -------------------------------------------------------------------- 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 Aug 26 20:34:51 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26860 for ; Tue, 26 Aug 2003 20:34:50 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7R0VgAv018051; Wed, 27 Aug 2003 02:31:42 +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 Q9LN7S04; Wed, 27 Aug 2003 02:31: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 h7R0VcxR024377; Wed, 27 Aug 2003 02:31: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 h7R0SEme010074; Wed, 27 Aug 2003 02:28:14 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7R0SD5l010073; Wed, 27 Aug 2003 02:28: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 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 h7R0SBme010069 for ; Wed, 27 Aug 2003 02:28:12 +0200 (MET DST) Date: Tue, 26 Aug 2003 17:29:00 -0700 Subject: Re: Issue 14: Is CGA-only RD protection useful? From: Alper Yegin To: James Kempf , Message-ID: In-Reply-To: <030401c36b3a$b57a1d20$806015ac@dclkempt40> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi James, I agree that relying on filtering capabilities in the access network for solving router advertisement authorization problem cannot be "the IETF SEND standard solution." But nevertheless, I think this should be noted as one possible way to solve "the problem." Also stating the applicability of such a solution, optionally along with its strengths/weaknesses, etc. would be useful. After all, network administrators should understand not only the problem and one of its solutions, but also other solutions and how they might relate to each other. At the end, they'd be the one to choose among these solutions. On the CGA point: Physical access, MACsec or IPsec-based control already helps enabling filtering. What does CGA-based approach add to this? Alper > Issue 14 received some discussion in Vienna. The question was raised by one > of the reviewers whether having CGA-only protection on RAs would be > sufficient for securing router discovery. This is independent of whether a > router would use CGA for neighbor discovery. > > The best approach to an answer would seem to me to be to be to look at the > threats to RD in draft-ietf-send-psreq-03.txt and see whether CGA protection > will satisfy them. This email attempts that analysis. > > Threats to RD are described in Section 4.2 of draft-ietf-send-psreq-03.txt. > The following threats are discussed: > > 1) Malicious Last Hop Router - the attacking node sends legitimate-looking > IPv6 RAs, or responds to a victim node's RSs with legitimate-looking IPv6 > RAs, in an attempt to get the victim to use it as the default router. > > 2) Default router is 'killed' - the attacking node uses one of a variety of > means to spoof other nodes into believing that the default router on the > link has died, in which case, by RFC 2461, the nodes revert to using link > local addresses only. One of these means involves sending out a bogus RA for > the default router with lifetime 0. > > 3) Bogus On-Link Prefix - the attacking node sends a spoofed subnet prefix > to trick the victim into either using the prefix for an incorrect > autoconfigured address or into thinking that the prefix is on-link so that > the victim uses link local addressing instead of a global IPv6 unicast > address, by sending a legitimate-seeming RA. > > 4) Bogus Link Parameters - the attacking node sends bogus link parameters > (like whether or not stateful address configuration should be used) by > sending a legitimate-seeming RA. > > The protection provided by CGAs is fairly simple: a receiver of a message > signed by the sender and verifiable with the sender's public key has the > assurance that the message was, in fact, sent from the CGA. > > In the absence of any network element or any additional processing between > the router and the host, CGAs would seem insufficient to address all the > threats above, though they would address 2, since the victim could clearly > identify that the bogus RA did not issue from the legitimate default router. > A malicious host could construct a CGA from its public key and use its > private key to sign a bogus RA. The RA would be verifiable as issuing from > the correct IPv6 address, but the RA would contain bogus information > designed to launch an attack. Since there is no IP network element between > the host and the router in the standard IP subnet architecture, this would > suggest that CGA-only RD authentication is not sufficient to address all the > threats. > > If, however, there exists a Layer 2 network element between the host and the > router that is programmable such that it can perform sufficient Layer 3 > processing to cryptographically verify the RA signature and filter on the > CGA, then CGA-only RA security may be useful. The Layer 2 network element > could be programmed with an ACL of CGAs for known good routers, and only > pass RAs for those whose CGAs match the signatures and the ACL. Depending on > the Layer 2 technology and the network element, some part of the subnet may > still be vulnerable. For example, if the Layer 2 technology was multi-access > prior to the filtering device, some number of hosts may be exposed to the > bogus RA. Note that such a filtering device would still be subject to attack > if CGAs were not employed, since the device could not verify the RA as > issuing from the source address, providing an opening for an attacker. > > The following are possible actions the WG could take w.r.t. resolving this > issue in the draft: > > A) Since the IP subnet architecture does not admit of devices between the > host and router, the potential solution involving a Layer 2 filtering device > is not of interest in an IETF standard. Therefore, the draft should state > that CGA-only solutions are not sufficient for protecting RD in SEND. > > B) As a practical matter, some Layer 2 technologies of interest support such > filtering devices, and adding the kind of Layer 3 filtering and network > management functions described above to such devices for CGA-only protection > is not all that difficult. Since a CGA-only solution may be simpler from a > deployment and network management perspective in some networks than > requiring routers to have certificates, the CGA-only solution should be > fully articulated in a separate section in the draft. > > C) As in A), but mention the CGA-only solution in passing, and don't > encourage it as a part of SEND. Suggest it is up to Layer 2 standardization > bodies to incorporate this functionality in their specifications. > > WG members are encouraged to discuss these alternatives, express their > preference, or suggest an additional alternative that I've missed. > > jak > > > > > > > > > > -------------------------------------------------------------------- > 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 Aug 27 11:20:08 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08013 for ; Wed, 27 Aug 2003 11:20:07 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7RFGT31006265; Wed, 27 Aug 2003 17:16:34 +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 QXZA0BZ8; Wed, 27 Aug 2003 17:17: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 h7RFGMxR016929; Wed, 27 Aug 2003 17:16:22 +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 h7RFCjme009532; Wed, 27 Aug 2003 17:12:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7RFCieu009531; Wed, 27 Aug 2003 17:12: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 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 h7RFCgme009524 for ; Wed, 27 Aug 2003 17:12:43 +0200 (MET DST) Message-ID: <003f01c36cad$b1de6530$806015ac@dclkempt40> From: "James Kempf" To: "Alper Yegin" , References: Subject: Re: Issue 14: Is CGA-only RD protection useful? Date: Wed, 27 Aug 2003 08:12:55 -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 So are you in favor of A, B, or C? jak ----- Original Message ----- From: "Alper Yegin" To: "James Kempf" ; Sent: Tuesday, August 26, 2003 5:29 PM Subject: Re: Issue 14: Is CGA-only RD protection useful? > Hi James, > > I agree that relying on filtering capabilities in the access network for > solving router advertisement authorization problem cannot be "the IETF SEND > standard solution." But nevertheless, I think this should be noted as one > possible way to solve "the problem." Also stating the applicability of such > a solution, optionally along with its strengths/weaknesses, etc. would be > useful. After all, network administrators should understand not only the > problem and one of its solutions, but also other solutions and how they > might relate to each other. At the end, they'd be the one to choose among > these solutions. > > On the CGA point: Physical access, MACsec or IPsec-based control already > helps enabling filtering. What does CGA-based approach add to this? > > Alper > > > > > Issue 14 received some discussion in Vienna. The question was raised by one > > of the reviewers whether having CGA-only protection on RAs would be > > sufficient for securing router discovery. This is independent of whether a > > router would use CGA for neighbor discovery. > > > > The best approach to an answer would seem to me to be to be to look at the > > threats to RD in draft-ietf-send-psreq-03.txt and see whether CGA protection > > will satisfy them. This email attempts that analysis. > > > > Threats to RD are described in Section 4.2 of draft-ietf-send-psreq-03.txt. > > The following threats are discussed: > > > > 1) Malicious Last Hop Router - the attacking node sends legitimate-looking > > IPv6 RAs, or responds to a victim node's RSs with legitimate-looking IPv6 > > RAs, in an attempt to get the victim to use it as the default router. > > > > 2) Default router is 'killed' - the attacking node uses one of a variety of > > means to spoof other nodes into believing that the default router on the > > link has died, in which case, by RFC 2461, the nodes revert to using link > > local addresses only. One of these means involves sending out a bogus RA for > > the default router with lifetime 0. > > > > 3) Bogus On-Link Prefix - the attacking node sends a spoofed subnet prefix > > to trick the victim into either using the prefix for an incorrect > > autoconfigured address or into thinking that the prefix is on-link so that > > the victim uses link local addressing instead of a global IPv6 unicast > > address, by sending a legitimate-seeming RA. > > > > 4) Bogus Link Parameters - the attacking node sends bogus link parameters > > (like whether or not stateful address configuration should be used) by > > sending a legitimate-seeming RA. > > > > The protection provided by CGAs is fairly simple: a receiver of a message > > signed by the sender and verifiable with the sender's public key has the > > assurance that the message was, in fact, sent from the CGA. > > > > In the absence of any network element or any additional processing between > > the router and the host, CGAs would seem insufficient to address all the > > threats above, though they would address 2, since the victim could clearly > > identify that the bogus RA did not issue from the legitimate default router. > > A malicious host could construct a CGA from its public key and use its > > private key to sign a bogus RA. The RA would be verifiable as issuing from > > the correct IPv6 address, but the RA would contain bogus information > > designed to launch an attack. Since there is no IP network element between > > the host and the router in the standard IP subnet architecture, this would > > suggest that CGA-only RD authentication is not sufficient to address all the > > threats. > > > > If, however, there exists a Layer 2 network element between the host and the > > router that is programmable such that it can perform sufficient Layer 3 > > processing to cryptographically verify the RA signature and filter on the > > CGA, then CGA-only RA security may be useful. The Layer 2 network element > > could be programmed with an ACL of CGAs for known good routers, and only > > pass RAs for those whose CGAs match the signatures and the ACL. Depending on > > the Layer 2 technology and the network element, some part of the subnet may > > still be vulnerable. For example, if the Layer 2 technology was multi-access > > prior to the filtering device, some number of hosts may be exposed to the > > bogus RA. Note that such a filtering device would still be subject to attack > > if CGAs were not employed, since the device could not verify the RA as > > issuing from the source address, providing an opening for an attacker. > > > > The following are possible actions the WG could take w.r.t. resolving this > > issue in the draft: > > > > A) Since the IP subnet architecture does not admit of devices between the > > host and router, the potential solution involving a Layer 2 filtering device > > is not of interest in an IETF standard. Therefore, the draft should state > > that CGA-only solutions are not sufficient for protecting RD in SEND. > > > > B) As a practical matter, some Layer 2 technologies of interest support such > > filtering devices, and adding the kind of Layer 3 filtering and network > > management functions described above to such devices for CGA-only protection > > is not all that difficult. Since a CGA-only solution may be simpler from a > > deployment and network management perspective in some networks than > > requiring routers to have certificates, the CGA-only solution should be > > fully articulated in a separate section in the draft. > > > > C) As in A), but mention the CGA-only solution in passing, and don't > > encourage it as a part of SEND. Suggest it is up to Layer 2 standardization > > bodies to incorporate this functionality in their specifications. > > > > WG members are encouraged to discuss these alternatives, express their > > preference, or suggest an additional alternative that I've missed. > > > > jak > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > 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 Aug 27 16:58:46 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08048 for ; Wed, 27 Aug 2003 16:58:45 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7RKu131008519; Wed, 27 Aug 2003 22:56:01 +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 QY1LD6CY; Wed, 27 Aug 2003 22:56: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 h7RKtjxR023724; Wed, 27 Aug 2003 22:55: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 h7RKqGme020771; Wed, 27 Aug 2003 22:52:16 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7RKqFDq020770; Wed, 27 Aug 2003 22:52: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 h7RKqDme020766 for ; Wed, 27 Aug 2003 22:52:14 +0200 (MET DST) Date: Wed, 27 Aug 2003 13:53:00 -0700 Subject: Re: Issue 14: Is CGA-only RD protection useful? From: Alper Yegin To: James Kempf , Message-ID: In-Reply-To: <003f01c36cad$b1de6530$806015ac@dclkempt40> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > So are you in favor of A, B, or C? D) Mention the possibility of filtering unauthorized RAs by relying on the physical access or crypto-based access authorization (i.e., using MACsec or IPsec). Such a solution is applicable when the hosts cannot directly communicate with each other without going through an access network device (such as an access point or access router) where this fitlering can take place. I would not suggest CGA-based RA filtering for the text, unless someone explains its benefits over the existing ways to check authorization. Alper > > jak > > ----- Original Message ----- > From: "Alper Yegin" > To: "James Kempf" ; > > Sent: Tuesday, August 26, 2003 5:29 PM > Subject: Re: Issue 14: Is CGA-only RD protection useful? > > >> Hi James, >> >> I agree that relying on filtering capabilities in the access network for >> solving router advertisement authorization problem cannot be "the IETF > SEND >> standard solution." But nevertheless, I think this should be noted as one >> possible way to solve "the problem." Also stating the applicability of > such >> a solution, optionally along with its strengths/weaknesses, etc. would be >> useful. After all, network administrators should understand not only the >> problem and one of its solutions, but also other solutions and how they >> might relate to each other. At the end, they'd be the one to choose among >> these solutions. >> >> On the CGA point: Physical access, MACsec or IPsec-based control already >> helps enabling filtering. What does CGA-based approach add to this? >> >> Alper >> >> >> >>> Issue 14 received some discussion in Vienna. The question was raised by > one >>> of the reviewers whether having CGA-only protection on RAs would be >>> sufficient for securing router discovery. This is independent of whether > a >>> router would use CGA for neighbor discovery. >>> >>> The best approach to an answer would seem to me to be to be to look at > the >>> threats to RD in draft-ietf-send-psreq-03.txt and see whether CGA > protection >>> will satisfy them. This email attempts that analysis. >>> >>> Threats to RD are described in Section 4.2 of > draft-ietf-send-psreq-03.txt. >>> The following threats are discussed: >>> >>> 1) Malicious Last Hop Router - the attacking node sends > legitimate-looking >>> IPv6 RAs, or responds to a victim node's RSs with legitimate-looking > IPv6 >>> RAs, in an attempt to get the victim to use it as the default router. >>> >>> 2) Default router is 'killed' - the attacking node uses one of a variety > of >>> means to spoof other nodes into believing that the default router on the >>> link has died, in which case, by RFC 2461, the nodes revert to using > link >>> local addresses only. One of these means involves sending out a bogus RA > for >>> the default router with lifetime 0. >>> >>> 3) Bogus On-Link Prefix - the attacking node sends a spoofed subnet > prefix >>> to trick the victim into either using the prefix for an incorrect >>> autoconfigured address or into thinking that the prefix is on-link so > that >>> the victim uses link local addressing instead of a global IPv6 unicast >>> address, by sending a legitimate-seeming RA. >>> >>> 4) Bogus Link Parameters - the attacking node sends bogus link > parameters >>> (like whether or not stateful address configuration should be used) by >>> sending a legitimate-seeming RA. >>> >>> The protection provided by CGAs is fairly simple: a receiver of a > message >>> signed by the sender and verifiable with the sender's public key has the >>> assurance that the message was, in fact, sent from the CGA. >>> >>> In the absence of any network element or any additional processing > between >>> the router and the host, CGAs would seem insufficient to address all the >>> threats above, though they would address 2, since the victim could > clearly >>> identify that the bogus RA did not issue from the legitimate default > router. >>> A malicious host could construct a CGA from its public key and use its >>> private key to sign a bogus RA. The RA would be verifiable as issuing > from >>> the correct IPv6 address, but the RA would contain bogus information >>> designed to launch an attack. Since there is no IP network element > between >>> the host and the router in the standard IP subnet architecture, this > would >>> suggest that CGA-only RD authentication is not sufficient to address all > the >>> threats. >>> >>> If, however, there exists a Layer 2 network element between the host and > the >>> router that is programmable such that it can perform sufficient Layer 3 >>> processing to cryptographically verify the RA signature and filter on > the >>> CGA, then CGA-only RA security may be useful. The Layer 2 network > element >>> could be programmed with an ACL of CGAs for known good routers, and only >>> pass RAs for those whose CGAs match the signatures and the ACL. > Depending on >>> the Layer 2 technology and the network element, some part of the subnet > may >>> still be vulnerable. For example, if the Layer 2 technology was > multi-access >>> prior to the filtering device, some number of hosts may be exposed to > the >>> bogus RA. Note that such a filtering device would still be subject to > attack >>> if CGAs were not employed, since the device could not verify the RA as >>> issuing from the source address, providing an opening for an attacker. >>> >>> The following are possible actions the WG could take w.r.t. resolving > this >>> issue in the draft: >>> >>> A) Since the IP subnet architecture does not admit of devices between > the >>> host and router, the potential solution involving a Layer 2 filtering > device >>> is not of interest in an IETF standard. Therefore, the draft should > state >>> that CGA-only solutions are not sufficient for protecting RD in SEND. >>> >>> B) As a practical matter, some Layer 2 technologies of interest support > such >>> filtering devices, and adding the kind of Layer 3 filtering and network >>> management functions described above to such devices for CGA-only > protection >>> is not all that difficult. Since a CGA-only solution may be simpler from > a >>> deployment and network management perspective in some networks than >>> requiring routers to have certificates, the CGA-only solution should be >>> fully articulated in a separate section in the draft. >>> >>> C) As in A), but mention the CGA-only solution in passing, and don't >>> encourage it as a part of SEND. Suggest it is up to Layer 2 > standardization >>> bodies to incorporate this functionality in their specifications. >>> >>> WG members are encouraged to discuss these alternatives, express their >>> preference, or suggest an additional alternative that I've missed. >>> >>> jak >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> 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 Aug 27 17:55:01 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11536 for ; Wed, 27 Aug 2003 17:55:01 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7RLqDAv000477; Wed, 27 Aug 2003 23:52:13 +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 QXZBBQB3; Wed, 27 Aug 2003 23:52: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 h7RLqBxR024674; Wed, 27 Aug 2003 23:52: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 h7RLn7me027989; Wed, 27 Aug 2003 23:49:07 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7RLn7GI027988; Wed, 27 Aug 2003 23:49: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 h7RLn4me027981 for ; Wed, 27 Aug 2003 23:49:05 +0200 (MET DST) Message-ID: <02c501c36ce5$11239100$806015ac@dclkempt40> From: "James Kempf" To: "Alper Yegin" , References: Subject: Re: Issue 14: Is CGA-only RD protection useful? Date: Wed, 27 Aug 2003 14:49:18 -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 > > So are you in favor of A, B, or C? > > D) Mention the possibility of filtering unauthorized RAs by relying on the > physical access or crypto-based access authorization (i.e., using MACsec or > IPsec). Such a solution is applicable when the hosts cannot directly > communicate with each other without going through an access network device > (such as an access point or access router) where this fitlering can take > place. > By physical access I assume you mean a lock on the door, for example? By MACsec I assume you mean cryptographic protection on the MAC layer, or possibly the kind of port-based filtering done by 802.1x? Can you explain how IPsec would work in this context? > I would not suggest CGA-based RA filtering for the text, unless someone > explains its benefits over the existing ways to check authorization. > What existing ways? The reason SEND was chartered is that the security in RFC 2461 was considered inadequate (note: if you are thinking of AAA-based solutions, not every access network will deploy AAA). 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 Aug 27 20:49:56 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24176 for ; Wed, 27 Aug 2003 20:49:55 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7S0liAv016734; Thu, 28 Aug 2003 02:47:44 +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 QXZBCNCW; Thu, 28 Aug 2003 02:48:29 +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 h7S0lhxa023382; Thu, 28 Aug 2003 02:47: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 h7S0iNme020275; Thu, 28 Aug 2003 02:44:23 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7S0iMlr020274; Thu, 28 Aug 2003 02:44: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 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 h7S0iKme020270 for ; Thu, 28 Aug 2003 02:44:21 +0200 (MET DST) Date: Wed, 27 Aug 2003 17:45:09 -0700 Subject: Re: Issue 14: Is CGA-only RD protection useful? From: Alper Yegin To: James Kempf , Message-ID: In-Reply-To: <02c501c36ce5$11239100$806015ac@dclkempt40> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit >> D) Mention the possibility of filtering unauthorized RAs by relying on the >> physical access or crypto-based access authorization (i.e., using MACsec > or >> IPsec). Such a solution is applicable when the hosts cannot directly >> communicate with each other without going through an access network device >> (such as an access point or access router) where this fitlering can take >> place. >> > > By physical access I assume you mean a lock on the door, for example? For example, an access point has two sides: wireless, and wired. In various deployments, the wired side is protected by physical security (e.g., doors, walls, hard-to-reach areas, etc.). This is also where the routers would connect. In that case, the access point can filter out any router advertisements sent from the wireless side while allowing any sent from the wired side. The assumption is, only service provider's devices are allowed to access the wired segment. And this is guaranteed by physical security. > > By MACsec I assume you mean cryptographic protection on the MAC layer, or > possibly the kind of port-based filtering done by 802.1x? Possible combination of the two.. In the aforementioned network, if the physical security is not adequate (or you don't want to automatically authorize any node connected to the wired segment as a "router") then you can load a list of MAC addresses (or client IDs which are bound to MAC addresses upon 802.1X - if used) as ACL, and the AP filters out any router advertisement if it does not arrive on a MACsecured packet with an authorized identifier. > > Can you explain how IPsec would work in this context? Similar to the L2 case... > > >> I would not suggest CGA-based RA filtering for the text, unless someone >> explains its benefits over the existing ways to check authorization. >> > > What existing ways? The reason SEND was chartered is that the security in > RFC 2461 was considered inadequate (note: if you are thinking of AAA-based > solutions, not every access network will deploy AAA). We are just talking about how to prevent unauthorized router advertisements, which is just one half of SEND. Current approach of SEND WG is to use certificates to prove authorization for an advertisement. As I understand from your original e-mail, the WG is also considering a filter-based approach where CGAs are used as the "authentication/authorization method." What I'm saying is, yes, filter-based approaches are valid, but asking why we need a CGA-based scheme where physical security, MACsec, or IPsec-based filtering can be used. This has nothing to do with using CGAs for solving the address ownership problem (the other half of SEND). Alper -------------------------------------------------------------------- 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 Aug 28 14:22:28 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06729 for ; Thu, 28 Aug 2003 14:22:27 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7SIJHAv024310; Thu, 28 Aug 2003 20:19:17 +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 QXZBLKDQ; Thu, 28 Aug 2003 20:20:05 +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 h7SIJFxa009479; Thu, 28 Aug 2003 20:19: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 h7SIFRme011229; Thu, 28 Aug 2003 20:15:27 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7SIFROn011225; Thu, 28 Aug 2003 20: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 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 h7SIFPme011167 for ; Thu, 28 Aug 2003 20:15:26 +0200 (MET DST) Message-ID: <032b01c36d90$624c1f60$956015ac@dclkempt40> From: "James Kempf" To: "Alper Yegin" , References: Subject: Re: Issue 14: Is CGA-only RD protection useful? Date: Thu, 28 Aug 2003 11:15:38 -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 > > By physical access I assume you mean a lock on the door, for example? > > For example, an access point has two sides: wireless, and wired. In various > deployments, the wired side is protected by physical security (e.g., doors, > walls, hard-to-reach areas, etc.). This is also where the routers would > connect. In that case, the access point can filter out any router > advertisements sent from the wireless side while allowing any sent from the > wired side. The assumption is, only service provider's devices are allowed > to access the wired segment. And this is guaranteed by physical security. > These comments have nothing to do with Issue 14: whether CGA alone can be used for RAs. These comments have to do with deployment alternatives for RA security, which is outside the scope of SEND. The SEND charter only deals with security enhancements to the protocol defined in RFC 2461 & 2462, not deployment issues. > > > > By MACsec I assume you mean cryptographic protection on the MAC layer, or > > possibly the kind of port-based filtering done by 802.1x? > > Possible combination of the two.. In the aforementioned network, if the > physical security is not adequate (or you don't want to automatically > authorize any node connected to the wired segment as a "router") then you > can load a list of MAC addresses (or client IDs which are bound to MAC > addresses upon 802.1X - if used) as ACL, and the AP filters out any router > advertisement if it does not arrive on a MACsecured packet with an > authorized identifier. > Again, this is an alternative deployment that is outside the scope of the SEND charter. > > > > Can you explain how IPsec would work in this context? > > Similar to the L2 case... > Another deployment issue. > > > > > >> I would not suggest CGA-based RA filtering for the text, unless someone > >> explains its benefits over the existing ways to check authorization. > >> > > > > What existing ways? The reason SEND was chartered is that the security in > > RFC 2461 was considered inadequate (note: if you are thinking of AAA-based > > solutions, not every access network will deploy AAA). > > We are just talking about how to prevent unauthorized router advertisements, > which is just one half of SEND. Current approach of SEND WG is to use > certificates to prove authorization for an advertisement. As I understand > from your original e-mail, the WG is also considering a filter-based > approach where CGAs are used as the "authentication/authorization method." > What I'm saying is, yes, filter-based approaches are valid, but asking why > we need a CGA-based scheme where physical security, MACsec, or IPsec-based > filtering can be used. > > This has nothing to do with using CGAs for solving the address ownership > problem (the other half of SEND). > With regard to the original point of this email thread, I interpret your response to be that you don't see any need to mention CGA-based RA filtering in the draft, i.e. alternative A, because there are existing filter-based alternatives that satisfy any requirement for non-cert based RA security. Your alternative D involves deployment issues, which, as I've stated, are outside of SEND's scope, and therefore not appropriate for insertion in the WG draft. If you are interested in pursuing these deployment issues, I'd suggest talking to the OPS ADs about scheduling a BOF. Unlike other WGs, the SEND WG has made very strenuous attempts to stay focussed on completing its charter as quickly as possible, and not wandering off into trying to solve all the problems of local link security. Anybody else have some comments specifically on the intended focus of the email thread? 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 Aug 28 15:43:34 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12130 for ; Thu, 28 Aug 2003 15:43:33 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7SJbN31009148; Thu, 28 Aug 2003 21:37:23 +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 QY1LL0AY; Thu, 28 Aug 2003 21:38:24 +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 h7SJb7xR020925; Thu, 28 Aug 2003 21:37: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 h7SJXnme020523; Thu, 28 Aug 2003 21:33:49 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h7SJXnDm020522; Thu, 28 Aug 2003 21:33: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 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 h7SJXlme020516 for ; Thu, 28 Aug 2003 21:33:47 +0200 (MET DST) Date: Thu, 28 Aug 2003 12:34:37 -0700 Subject: Re: Issue 14: Is CGA-only RD protection useful? From: Alper Yegin To: James Kempf , Message-ID: In-Reply-To: <032b01c36d90$624c1f60$956015ac@dclkempt40> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > These comments have nothing to do with Issue 14: whether CGA alone can be > used for RAs. The relevance, if it wasn't clear in my message, is this: - If SEND WG wants to talk about how to "filter out" router advertisements on an enforcement point, it does not have to invent new CGA-based mechanisms, the already existing ones are good enough. > These comments have to do with deployment alternatives for RA > security, which is outside the scope of SEND. The SEND charter only deals > with security enhancements to the protocol defined in RFC 2461 & 2462, not > deployment issues. Sure, but acknowledging presence of these alternatives, considering possible co-existence, and interaction if there is any, is a good thing, imo. Good examples are the Mobile IPv6 draft and RFC3344. They do not dodge the "link-layer mobility" issue as not for Mobile IP WG to deal with, instead they acknowledge its presence, solution to the problem, strengths and weaknesses. Just briefly, of course. Alper > >>> >>> By MACsec I assume you mean cryptographic protection on the MAC layer, > or >>> possibly the kind of port-based filtering done by 802.1x? >> >> Possible combination of the two.. In the aforementioned network, if the >> physical security is not adequate (or you don't want to automatically >> authorize any node connected to the wired segment as a "router") then you >> can load a list of MAC addresses (or client IDs which are bound to MAC >> addresses upon 802.1X - if used) as ACL, and the AP filters out any router >> advertisement if it does not arrive on a MACsecured packet with an >> authorized identifier. >> > > Again, this is an alternative deployment that is outside the scope of the > SEND charter. > >>> >>> Can you explain how IPsec would work in this context? >> >> Similar to the L2 case... >> > > Another deployment issue. > >>> >>> >>>> I would not suggest CGA-based RA filtering for the text, unless someone >>>> explains its benefits over the existing ways to check authorization. >>>> >>> >>> What existing ways? The reason SEND was chartered is that the security > in >>> RFC 2461 was considered inadequate (note: if you are thinking of > AAA-based >>> solutions, not every access network will deploy AAA). >> >> We are just talking about how to prevent unauthorized router > advertisements, >> which is just one half of SEND. Current approach of SEND WG is to use >> certificates to prove authorization for an advertisement. As I understand >> from your original e-mail, the WG is also considering a filter-based >> approach where CGAs are used as the "authentication/authorization method." >> What I'm saying is, yes, filter-based approaches are valid, but asking why >> we need a CGA-based scheme where physical security, MACsec, or IPsec-based >> filtering can be used. >> >> This has nothing to do with using CGAs for solving the address ownership >> problem (the other half of SEND). >> > > With regard to the original point of this email thread, I interpret your > response to be that you don't see any need to mention CGA-based RA filtering > in the draft, i.e. alternative A, because there are existing filter-based > alternatives that satisfy any requirement for non-cert based RA security. > Your alternative D involves deployment issues, which, as I've stated, are > outside of SEND's scope, and therefore not appropriate for insertion in the > WG draft. > > If you are interested in pursuing these deployment issues, I'd suggest > talking to the OPS ADs about scheduling a BOF. Unlike other WGs, the SEND WG > has made very strenuous attempts to stay focussed on completing its charter > as quickly as possible, and not wandering off into trying to solve all the > problems of local link security. > > Anybody else have some comments specifically on the intended focus of the > email thread? > > 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 Sun Aug 31 21:15:59 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16626 for ; Sun, 31 Aug 2003 21:15:58 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h811AZAv005570; Mon, 1 Sep 2003 03:10:35 +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 Q9LPRFPK; Mon, 1 Sep 2003 03:10:34 +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 h811AYxa021553; Mon, 1 Sep 2003 03:10:34 +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 h8116Lme018656; Mon, 1 Sep 2003 03:06:21 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8116Lsm018655; Mon, 1 Sep 2003 03:06: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 ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8116Jme018650 for ; Mon, 1 Sep 2003 03:06:20 +0200 (MET DST) Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L05BM3QX8U8ZEXLD@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 1 Sep 2003 10:44:55 +1000 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 012E323C005; Mon, 01 Sep 2003 10:44:55 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id E0A76164007; Mon, 01 Sep 2003 10:44:54 +1000 (EST) Date: Mon, 01 Sep 2003 10:44:54 +1000 From: Greg Daley Subject: Re: Issue 21: RA source is Link Local To: James Kempf Cc: ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F529686.50205@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: <027101c36b2a$c2e7b770$806015ac@dclkempt40> <3F4AF7DD.2010608@eng.monash.edu.au> <00b601c36bea$9fd8a300$806015ac@dclkempt40> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: >>>RFC 2461 requires that RAs be sent with a Link Local address. Issue 21 >> > is > >>>whether the same restriction should be put on DCA. >>> >>>Proposed solution: yes. >>> >>>Comments? >> >>I've got some odd ideas for wanting to do DCA >>from off-network, but understand that in general >>on-link only is best. >> >>Is there any effective difference between requiring >>link-local and requiring ttl of 255 (with LL or global)? >> > > > TTL of 255 and dropping any received packet with a TTL less than that will > effectively limit to on link. Link local addresses are an additional > mechanism for that, and having DCA use them is consistent with RFC 2461, > which is why it is being recommended. I think consistency is valid, considering that we're aiming at interworking with existing ND solutions (although this is a new message). I'd prefer that there's really only one mechanism required to ensure link-only reach of the DCA, though, if it is sufficient. Guaranteeing this with hop count 255 may be so. Whether the address is link-local seems to be less relevant for that purpose. > In general, I'm not sure it is advisable to do DCA from off-link. There is > an issue with fragmentation. Certs tend to be large, and if they are sent > using UDP multihop, they can get fragmented and dropped by routers that > don't handle fragmentation properly, which typically isn't a problem with a > single link. This problem occurs frequently with IKE, for example, and the > IPsec WG has yet to face up to how to handle it. The design team discussed > whether to put in mechanism to handle fragmentation or certificate > compression, but it would make DCA much more complicated, and it is not > clear at this point whether the extra complication is necessary, if the off > link uses result from only 10% of the cases. If they are more like 50%, we > can put in fragmentation support later. > Thanks, It's nice to know some additional issues here. I must admit that I haven't looked at the draft recently though, and were unaware that we were talking about using UDP (although the same is likely to apply to other Datagram oriented communications). Certainly, we don't want to overcomplicate DCA or SEND. I'm not going to propose any odd ideas like this until the RFC comes out, and I still think the odd ideas would work. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------