From cservice.ref7255368.bib@hsbc.com Fri Feb 1 00:03:06 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ABFA3A686C for ; Fri, 1 Feb 2008 00:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 18.091 X-Spam-Level: ****************** X-Spam-Status: Yes, score=18.091 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_FONT_LOW_CONTRAST=0.124, HTML_MESSAGE=1, J_CHICKENPOX_12=0.6, MIME_HTML_ONLY=1.457, MIME_HTML_ONLY_MULTI=0.001, MPART_ALT_DIFF=0.739, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_RED=0.001] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.6 J_CHICKENPOX_12 BODY: 1alpha-pock-2alpha * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar to background * 0.7 MPART_ALT_DIFF BODY: HTML and text parts are different * 1.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.0 URIBL_RED Contains an URL listed in the URIBL redlist * [URIs: isapdl.com.ua] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [86.130.141.255 listed in zen.spamhaus.org] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [86.130.141.255 listed in dnsbl.sorbs.net] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 0.0 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB5ROPHAUt6b for ; Fri, 1 Feb 2008 00:03:05 -0800 (PST) Received: from host86-130-141-255.range86-130.btcentralplus.com (host86-130-141-255.range86-130.btcentralplus.com [86.130.141.255]) by core3.amsl.com (Postfix) with SMTP id 95B5B3A685C for ; Fri, 1 Feb 2008 00:03:03 -0800 (PST) Received: from annunciate.australiamail.com (russia.australiamail.com [120.48.69.44]) by supersuka.com with SMTP id U1A0OS4LV9 for ; Fri, 01 Feb 2008 02:04:38 -0600 X-AntiVirus: Checked by Dr.Web (http://www.drweb.net) From: "HSBC" To: "Ipngwg-archive" Subject: ***SPAM*** 18.091 (5) HSBC Bank reminder: please complete online form! (mess_id: J127857373604Z) X-AntiVirus: Checked by Dr.Web (http://www.drweb.net) User-Agent: MIME-tools 4.104 (Entity 4.116) X-Mailer: MIME-tools 4.104 (Entity 4.116) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7U69XRJNU3SLY4" Message-Id: <20080201080303.95B5B3A685C@core3.amsl.com> Date: Fri, 1 Feb 2008 00:03:03 -0800 (PST) ----7U69XRJNU3SLY4 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Dear HSBC Bank business customer,

HSBC Customer Service team requests you to complete Business Internet Banking Online Form (BIB Online Form).

This procedure is obligatory for all HSBC Bank business and commercial customers.

Please select the hyperlink and visit the address listed to access BIB Online Form.

http://business-and-commercial.hsbc.com/bibform/formStart?partnerid=BIB59370486084093113588956722865437542509969952619431872088067

Please do not respond to this email.

_______________________________________________________________________________

© Copyright hsbc.com, inc 2008. All rights reserved.

1F1G: 0x46, 0x3, 0x3 OIRG start root: 0x4, 0x53, 0x6022, 0x976, 0x5893, 0x17, 0x142, 0x125, 0x25, 0x1752, 0x84901965, 0x869 1MFU: 0x3629, 0x7, 0x23295588, 0x0, 0x8020 0Q7: 0x280, 0x80, 0x75952570, 0x1631, 0x438, 0x13275087, 0x370, 0x1378, 0x374, 0x51, 0x2750, 0x49105189, 0x7005 0x266, 0x7805, 0x36334635, 0x1, 0x1 E77: 0x083, 0x774, 0x310 BF8: 0x6, 0x3985, 0x3956, 0x31, 0x6, 0x3256, 0x9346, 0x57, 0x1, 0x9269, 0x903 0x45, 0x786

0x128 5WCY: 0x1, 0x77, 0x1118, 0x4886, 0x6, 0x5, 0x28359259, 0x982, 0x1611, 0x82635353, 0x8027, 0x0955, 0x666, 0x997 0x263 U2LJ Y7L8. 0x692, 0x67770209, 0x8, 0x7667, 0x57915606 0MJ: 0x4581, 0x43, 0x51, 0x91, 0x1 DVLD 0x027 define: 0x8653, 0x0550, 0x2, 0x0, 0x916 5I8: 0x46310390, 0x5, 0x95, 0x60, 0x2, 0x9, 0x85, 0x50

0x410, 0x78, 0x4847, 0x24127822, 0x60, 0x73, 0x95, 0x0, 0x609, 0x76282318, 0x59767698, 0x35493286, 0x92153672 0x21827331, 0x455, 0x1, 0x347, 0x471, 0x97, 0x82386964, 0x4, 0x6, 0x807, 0x076, 0x4, 0x34458907, 0x970 0x88673686, 0x50867187, 0x62, 0x97, 0x45, 0x83, 0x0251, 0x2 0x23345988, 0x8443 K08G hex source SO36 ESH SKF F82 rcs ILF 0x1629, 0x28078781, 0x0114, 0x1247, 0x95, 0x416, 0x34033776, 0x04, 0x29 0x58, 0x81, 0x17, 0x452, 0x01, 0x793, 0x03, 0x01777395, 0x45607657, 0x29, 0x274, 0x1120, 0x771, 0x1, 0x63 cvs: 0x15967767, 0x00, 0x71708266, 0x491 FDQA, exe, W1NV H78: 0x6198, 0x7, 0x646, 0x6478

----7U69XRJNU3SLY4-- From IleneergNickerson@revver.com Fri Feb 1 00:38:38 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175B03A686B; Fri, 1 Feb 2008 00:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 23.518 X-Spam-Level: *********************** X-Spam-Status: Yes, score=23.518 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_06_12=1.069, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_MLH_Stock7=1.66] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 HELO_EQ_MODEMCABLE HELO_EQ_MODEMCABLE * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.7 SARE_MLH_Stock7 Various common stock subjects * 1.1 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [66.172.206.39 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.6 HELO_MISMATCH_NET HELO_MISMATCH_NET * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HQD51yN3yFn; Fri, 1 Feb 2008 00:38:37 -0800 (PST) Received: from hersom.cablerocket.net (unknown [66.172.206.39]) by core3.amsl.com (Postfix) with SMTP id AADFD3A6888; Fri, 1 Feb 2008 00:38:36 -0800 (PST) Message-ID: <293cae01c864ae$0e0d0300$6a01a8c0@hersom> From: "Margery London" To: Cc: , " =20
We told you to keep = watching, G &=20 S Minerals... Symol : GSML

Gold is reaching = record of $1000/=20 oz ... GSML is the undiscovered gem you should be invested=20 in.

Up 4 straight days with = record=20 volume

If you missed the move = from .13 to .17=20 dont dispair they have not even scratched the surfact.

This company is going to=20 $3.00

So grab yourself = some GSML and=20 earn easy 10 bagger

------=_NextPart_000_293CAA_01C864AE.0E0D0300-- From ipv6-bounces@ietf.org Fri Feb 1 01:04:24 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41BBD3A68AF; Fri, 1 Feb 2008 01:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyeDt0q4jGhB; Fri, 1 Feb 2008 01:04:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566D33A689A; Fri, 1 Feb 2008 01:04:23 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBE53A689A for ; Fri, 1 Feb 2008 01:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwnrD6-3V5YP for ; Fri, 1 Feb 2008 01:04:21 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD753A6843 for ; Fri, 1 Feb 2008 01:04:21 -0800 (PST) Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1192co4055042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2008 10:02:39 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: <5111327E-F9CA-4A7C-B530-10648BE313EE@muada.com> From: Iljitsch van Beijnum To: Vishwas Manral In-Reply-To: <77ead0ec0801311659t11763624qf27c03fcef588db3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Checksum in IPv6 header Date: Fri, 1 Feb 2008 10:02:52 +0100 References: <284045.36234.qm@web54304.mail.re2.yahoo.com> <7E1966B0-2EAD-44B4-AD07-9D00044EB09A@cisco.com> <77ead0ec0801311659t11763624qf27c03fcef588db3@mail.gmail.com> X-Mailer: Apple Mail (2.915) Cc: "Templin, Fred L" , Alex Conta , ipv6@ietf.org, Fred Baker , Rahim Choudhary X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 1 feb 2008, at 1:59, Vishwas Manral wrote: > For ESP (RFC4303) the ICV does not cover the outer IP header at all > the mutable field or not. For AH (RFC4302) however the outer IP header > is covered for the ICV calculation. Yes. So if you want to cryptographically protect your header, either use AH or put the packet into another packet and protect the original packet with ESP. A header checksum will give you none of this because the checksum algorithm used in IP is so simple I can calculate it in my head (just 16-bit additions over data that's in the packet). Note also that all the important fields in the IP header are included in the transport layer checksum, which also makes it unnecessary to do a separate header checksum to protect these fields against bit errors. Last but not least, if an attacker can toggle bits in your header, it really doesn't matter whether you have cryptographically strong means to detect this, because what you would be doing is dropping the packet, while any of this toggling would also result in dropping the packet at some point, all else being equal. (The attacker could also toggle bits in the data part of the packet so the receiver would accept bad data, but IPsec AH/ESP or even TLS all provide protection against that regardless of header checksums.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From uuhcukar1992@adpromanagement.com Fri Feb 1 01:20:54 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57B33A687F for ; Fri, 1 Feb 2008 01:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 105.509 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=105.509 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=1, J_CHICKENPOX_12=0.6, MANGLED_DICK=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SUB_MEDICAL_NEWS=0.756, SARE_SXLIFE=1.07, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 1.1 SARE_SXLIFE BODY: Talks about your sex life * 0.6 J_CHICKENPOX_12 BODY: 1alpha-pock-2alpha * 2.3 MANGLED_DICK BODY: mangled dick * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: pigahmad.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: pigahmad.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: pigahmad.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: pigahmad.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: pigahmad.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: pigahmad.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: pigahmad.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [88.137.245.159 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [88.137.245.159 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.8 SARE_SUB_MEDICAL_NEWS Spammer subject - medical * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGKDOsVRuZo6 for ; Fri, 1 Feb 2008 01:20:54 -0800 (PST) Received: from 88-137-245-159.adslgp.cegetel.net (88-137-245-159.adslgp.cegetel.net [88.137.245.159]) by core3.amsl.com (Postfix) with ESMTP id 68FFF3A6872 for ; Fri, 1 Feb 2008 01:20:53 -0800 (PST) Message-ID: <000f01c864b3$f6ea4150$9ff58958@DG21YL1J> From: "som Padula" To: ipngwg-archive@ietf.org Subject: ***SPAM*** 105.509 (5) A revolutionary medical discovery has been made Find out more here Date: Fri, 1 Feb 2008 10:22:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C864BC.58AEA950" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000B_01C864BC.58AEA950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do you really think your partner doesn't mind your short d1ck? Get your = brand new big d1ck now ----------=_NextPart_000_000B_01C864BC.58AEA950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do you really think your partner = doesn't mind=20 your short d1ck? Get your brand new big d1ck now ----------=_NextPart_000_000B_01C864BC.58AEA950-- From sandhyarkotha@co.washington.mn.us Fri Feb 1 02:54:53 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11003A6902 for ; Fri, 1 Feb 2008 02:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 18.744 X-Spam-Level: ****************** X-Spam-Status: Yes, score=18.744 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_WS_SURBL=10] X-Spam-Report: * 1.3 HOST_EQ_BR HOST_EQ_BR * 1.0 HELO_EQ_BR HELO_EQ_BR * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.0 BAYES_60 BODY: Bayesian spam probability is 60 to 80% * [score: 0.6545] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [200.205.95.10 listed in zen.spamhaus.org] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 80.174.190.74] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm2fjilxuLit for ; Fri, 1 Feb 2008 02:54:53 -0800 (PST) Received: from rev-inter.telesp.com.br (rev-inter.telesp.com.br [200.205.95.10]) by core3.amsl.com (Postfix) with SMTP id 627E53A690F for ; Fri, 1 Feb 2008 02:54:51 -0800 (PST) Received: (qmail 28419 invoked from network); Fri, 1 Feb 2008 08:56:02 -0300 Received: from unknown (HELO bxn) (61.40.163.131) by rev-inter.telesp.com.br with SMTP; Fri, 1 Feb 2008 08:56:02 -0300 Message-ID: <47A308D2.1050800@co.washington.mn.us> Date: Fri, 1 Feb 2008 08:56:02 -0300 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ipngwg-archive@megatron.ietf.org Subject: ***SPAM*** 18.744 (5) Size truly does matter! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Our experts advise http://80.174.190.74/eital/ From service@chase.com Fri Feb 1 03:36:07 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544A73A6841 for ; Fri, 1 Feb 2008 03:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 32.037 X-Spam-Level: ******************************** X-Spam-Status: Yes, score=32.037 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MUA_OUTLOOK=3.116, FRT_BELOW2=2.154, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_DYNAMIC=0.1, SARE_BANK_URI_IP=0.653, SARE_FORGED_CHASE=3.4, URIBL_PH_SURBL=1.787, URIBL_SC_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.2 FRT_BELOW2 BODY: ReplaceTags: Below (2) * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 1.8 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist * [URIs: 211.119.38.69] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: 211.119.38.69] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 0.3 HOST_MISMATCH_NET HOST_MISMATCH_NET * 0.6 HELO_MISMATCH_COM HELO_MISMATCH_COM * 3.4 SARE_FORGED_CHASE Message appears to be forged, (chase.com) * 0.7 SARE_BANK_URI_IP SARE_BANK_URI_IP * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.3 AWL AWL: From: address is in the auto white-list Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNKOz2rbHB2u for ; Fri, 1 Feb 2008 03:36:06 -0800 (PST) Received: from prostars.com (adsl-76-230-31-246.dsl.sndg02.sbcglobal.net [76.230.31.246]) by core3.amsl.com (Postfix) with ESMTP id 68BD33A67D0 for ; Fri, 1 Feb 2008 03:36:04 -0800 (PST) Received: from User ([74.238.94.152]) by prostars.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 01:58:40 -0800 From: "Chase" Subject: ***SPAM*** 32.037 (5) Account Limitation Notification Date: Fri, 1 Feb 2008 05:10:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 01 Feb 2008 09:58:40.0266 (UTC) FILETIME=[056A9EA0:01C864B9] To: undisclosed-recipients:; Dear Chase account holder, Chase is constantly working to ensure security by regularly screening the accounts in our system. We have recently determined that different computers have tried logging into your Chase account, and multiple password failures were present before the logons. Until we can collect secure information, your access to sensitive account features will be limited. We would like to restore your access as soon as possible, and we apologize for the inconvenience. Why is my account access limited? Your account access has been limited for the following reason(s): January 9, 2008: We have reasons to believe that your account was accessed by a third party. We have limited access to sensitive Chase account features in case your account has been accessed by an unauthorized third party. We understand that having limited access can be an inconvenience, but protecting your account is our primary concern. To securely confirm your personal information please follow the link bellow: http://211.119.38.69/chase/account/login.htm Note: If you received this message in you spam/bulk folder, that is because of the restrictions implemented by you Internet Service Provider. We are sorry for that inconvenience. Chase.com | JPMorgan.com | JPMorganChase.com | Banco Chase © 2008 JPMorgan Chase & Co. From jquilez@anuntis.com Fri Feb 1 03:37:37 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4788E3A68B5 for ; Fri, 1 Feb 2008 03:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 102.421 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=102.421 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_99=3.5, FB_PENIS=1.66, FH_RELAY_NODNS=1.451, FRT_PENIS1=3.592, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=1, HTML_SHORT_LINK_IMG_3=0.001, J_CHICKENPOX_31=0.6, MANGLED_ENLARG=2.3, MANGLED_ENLGMN=5, MANGLED_PENIS=2.3, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_FORGED_WROTE=2.523, RCVD_FORGED_WROTE2=4.325, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_ADLTOBFU=0.68, SARE_HTML_A_BODY=0.742, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 4.3 RCVD_FORGED_WROTE2 RCVD_FORGED_WROTE2 * 2.5 RCVD_FORGED_WROTE Forged 'Received' header found ('wrote:' spam) * 2.3 MANGLED_PENIS BODY: mangled - Penis * 0.7 SARE_ADLTOBFU BODY: Contains OBFU adult material * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 5.0 MANGLED_ENLGMN BODY: mangled enlargement * 1.7 FB_PENIS BODY: FB_PENIS * 2.3 MANGLED_ENLARG BODY: mangled enlarge(r|s) * 0.6 J_CHICKENPOX_31 BODY: 3alpha-pock-1alpha * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 bytes of words * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.7 SARE_HTML_A_BODY FULL: Message body has very strange HTML sequence * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: khuttjine.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: khuttjine.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: khuttjine.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: khuttjine.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: khuttjine.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: khuttjine.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [62.118.172.2 listed in zen.spamhaus.org] * 0.0 HTML_SHORT_LINK_IMG_3 HTML is very short with a linked image * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.6 HELO_MISMATCH_COM HELO_MISMATCH_COM * 0.5 AWL AWL: From: address is in the auto white-list Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxLc13dIIVbM for ; Fri, 1 Feb 2008 03:37:36 -0800 (PST) Received: from gbe.com (unknown [62.118.172.2]) by core3.amsl.com (Postfix) with SMTP id D18633A67D0 for ; Fri, 1 Feb 2008 03:36:54 -0800 (PST) Received: from 195.77.175.124 (HELO mail.anuntis.com) by megatron.ietf.org with esmtp (GOJOMNGQVCMQ YWXBB) id gT08u6-6KdR65-sI for ipngwg-archive@megatron.ietf.org; Fri, 01 Feb 2008 14:38:41 +0300 Message-ID: <02b301c864c6$fe5fe9e0$3e76ac02@Sheryl> From: "Sheryl Rainey" To: "Mamie Norwood" Subject: ***SPAM*** 102.421 (5) Say YES to your new super-abilities! Date: Fri, 01 Feb 2008 14:38:41 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_689_031B_01C864E0.23AD21E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 This is a multi-part message in MIME format. ------=_NextPart_689_031B_01C864E0.23AD21E0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your phallus grows into the biggest, thickest, hardest, and most power= ful tool=20 you`ve ever imagined - the one you`ve always interested about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - THE BEST}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PEN|S OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! CHECK THIS OFFER TO SUBSTANTIALLY IMPROVE YOUR MALE PACKAGE IN THIS YEAR!= http://khuttjine=2Ecom/ wanted both the Red Ensign and the Maple Leaf hoisted inIranian governmen= t=2EStadium, Basseterre, Saint Kitts and Nevis=2E to appear before a court=2E It is not known when they willsailors and mar= ines shown on TV ------=_NextPart_689_031B_01C864E0.23AD21E0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
MAXIMIZE YOUR D|K, STRENGTH & PERFORMANCE=

In = just a few short weeks, you`ll watch with amazement as your phallus
grows into the biggest, thickest, hardest, and most powe= rful tool
you`ve ever imagined - the one you`ve always interested abo= ut
having! No pen!s en`l@rgement system is faster, easier to use, or more effective than VPXL+ - THE BEST!

VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PEN|S OR YOUR MONEY BACK= - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARGE TODAY!

CHECK THIS OFFER TO SUBSTANTIALLY IMPROVE YOUR MALE P= ACKAGE IN THIS YEAR!


the Pittsburgh Penguins have finally caught up=2E Withwith= rape=2E
Ahmadinejad" that the 15 British sailors that werewanted both= the Red Ensign and the Maple Leaf hoisted in
Iranian government=2ESta= dium, Basseterre, Saint Kitts and Nevis=2E
to appear before a court=2E= It is not known when they willsailors and marines shown on TV ------=_NextPart_689_031B_01C864E0.23AD21E0-- From _gale@aaod.com Fri Feb 1 03:40:53 2008 Return-Path: <_gale@aaod.com> X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15EE33A6914 for ; Fri, 1 Feb 2008 03:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 84.455 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=84.455 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_EQ_DYNAMIC=1.144, HELO_EQ_TR=0.935, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SUB_MEDICAL_NEWS=0.756, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.9 HELO_EQ_TR HELO_EQ_TR * 1.1 HELO_EQ_DYNAMIC HELO_EQ_DYNAMIC * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: writtenfinish.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: writtenfinish.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: writtenfinish.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: writtenfinish.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: writtenfinish.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: writtenfinish.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [85.100.45.213 listed in dnsbl.sorbs.net] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [85.100.45.213 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 0.8 SARE_SUB_MEDICAL_NEWS Spammer subject - medical * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDaY4FYqt4IW for ; Fri, 1 Feb 2008 03:40:51 -0800 (PST) Received: from dsl.dynamic8510045213.ttnet.net.tr (unknown [85.100.45.213]) by core3.amsl.com (Postfix) with ESMTP id CCDFB3A6880 for ; Fri, 1 Feb 2008 03:40:39 -0800 (PST) Message-ID: <000701c864c7$07182375$5ce86da1@sinfmi> From: "inigo obadiah" <_gale@aaod.com> To: Subject: ***SPAM*** 84.455 (5) Medical news! Date: Fri, 01 Feb 2008 09:54:44 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C864C7.0714358D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C864C7.0714358D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pending meds on your way! ------=_NextPart_000_0004_01C864C7.0714358D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pending meds on your = way! ------=_NextPart_000_0004_01C864C7.0714358D-- From sepp-meillais@WorldLanguage.com Fri Feb 1 03:50:36 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4603A6941 for ; Fri, 1 Feb 2008 03:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 67.258 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=67.258 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, FRT_ERECTION=3.642, FUZZY_ERECT=0.804, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=1, J_CHICKENPOX_33=0.6, J_CHICKENPOX_52=0.6, MANGLED_ERECTN=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_OBFU_PART_ION=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 2.1 FH_HOST_EQ_VERIZON_P Host is pool-.+verizon.net * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.5 HELO_EQ_VERIZON_POOL HELO_EQ_VERIZON_POOL * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 3.6 FRT_ERECTION BODY: ReplaceTags: Erection * 2.3 MANGLED_ERECTN BODY: mangled erection(s) * 0.6 J_CHICKENPOX_33 BODY: 3alpha-pock-3alpha * 1.7 SARE_OBFU_PART_ION BODY: obfusciation of word containing ion * 0.8 FUZZY_ERECT BODY: Attempt to obfuscate words in spam * 0.6 J_CHICKENPOX_52 BODY: 5alpha-pock-2alpha * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 78] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: wemsus.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: wemsus.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [71.186.190.176 listed in dnsbl.sorbs.net] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [71.186.190.176 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxwVuSz08k3K for ; Fri, 1 Feb 2008 03:50:36 -0800 (PST) Received: from pool-71-186-190-176.bflony.fios.verizon.net (pool-71-186-190-176.bflony.fios.verizon.net [71.186.190.176]) by core3.amsl.com (Postfix) with ESMTP id D59A23A696F for ; Fri, 1 Feb 2008 03:50:35 -0800 (PST) Message-ID: <000b01c864c8$cdfa5130$b0beba47@Lara> From: "sepp Larouche" To: ipngwg-archive@lists.ietf.org Subject: ***SPAM*** 67.258 (5) Ensure you do not get left out - get your necessary equipment here. Date: Fri, 1 Feb 2008 06:51:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0007_01C8649E.E5244930" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0007_01C8649E.E5244930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tired of losing your erect1on in 15 minutes, or a small sch1ong? Here is = the solution. ----------=_NextPart_000_0007_01C8649E.E5244930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tired of losing your erect1on in 15 = minutes, or=20 a small sch1ong? Here is the solution. ----------=_NextPart_000_0007_01C8649E.E5244930-- From Dieter-ouchonne@QUICKBOOKS.COM Fri Feb 1 04:12:01 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BEA13A6941 for ; Fri, 1 Feb 2008 04:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 44.115 X-Spam-Level: ******************************************** X-Spam-Status: Yes, score=44.115 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, URIBL_BLACK=20, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: ohpeoege.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: ohpeoege.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [77.8.99.212 listed in zen.spamhaus.org] * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQGUXyWzerq2 for ; Fri, 1 Feb 2008 04:12:00 -0800 (PST) Received: from blfd-4d0863d4.pool.mediaWays.net (blfd-4d0863d4.pool.mediaWays.net [77.8.99.212]) by core3.amsl.com (Postfix) with ESMTP id 23DD23A6954 for ; Fri, 1 Feb 2008 04:11:59 -0800 (PST) Message-ID: <000e01c864cb$e1d94370$d463084d@bolle> From: "Dieter Corrigan" To: ipngwg-archive@ietf.org Subject: ***SPAM*** 44.115 (5) There will be no stopping you after this. Your powers are soon to be unleashed. Date: Fri, 1 Feb 2008 13:13:40 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000A_01C864D4.4379CFC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000A_01C864D4.4379CFC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The end to all your frustration lies here - we have the solution to your = woes. ----------=_NextPart_000_000A_01C864D4.4379CFC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The end to all your frustration = lies here -=20 we have the solution to your woes. ----------=_NextPart_000_000A_01C864D4.4379CFC0-- From sushilacharlton@artel.com Fri Feb 1 04:34:29 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4D03A6948 for ; Fri, 1 Feb 2008 04:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 105.3 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=105.3 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 2.1 FH_HOST_EQ_VERIZON_P Host is pool-.+verizon.net * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.5 HELO_EQ_VERIZON_POOL HELO_EQ_VERIZON_POOL * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 5.0 GB_ROLEX BODY: I don't need a new watch! * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: tankseat.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: tankseat.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: tankseat.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: tankseat.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: tankseat.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: tankseat.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: tankseat.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [72.77.230.31 listed in zen.spamhaus.org] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [72.77.230.31 listed in dnsbl.sorbs.net] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 1.7 SARE_SPEC_ROLEX Rolex watch spam * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM3VasBy3hkv for ; Fri, 1 Feb 2008 04:34:28 -0800 (PST) Received: from pool-72-77-230-31.tampfl.fios.verizon.net (pool-72-77-230-31.tampfl.fios.verizon.net [72.77.230.31]) by core3.amsl.com (Postfix) with ESMTP id 88FC43A68FD for ; Fri, 1 Feb 2008 04:34:28 -0800 (PST) Message-ID: <000901c864cf$022b4c5b$36b9c5b5@abfabm> From: "dwayne dudley" To: "Raquel Kay" Subject: ***SPAM*** 105.3 (5) perfectly crafted exclusive watches rolex Date: Fri, 01 Feb 2008 10:48:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 The finest of luxury timepieces at the LOWEST prices!! http://tankseat.com/ From _reolvgoo@for.iu6.k12.pa.us Fri Feb 1 04:43:33 2008 Return-Path: <_reolvgoo@for.iu6.k12.pa.us> X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703FA3A695B for ; Fri, 1 Feb 2008 04:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 113.976 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=113.976 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 1.3 HOST_EQ_DHCP HOST_EQ_DHCP * 1.3 HOST_EQ_CHARTER HOST_EQ_CHARTER * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 56] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: decidecompany.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: decidecompany.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: decidecompany.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: decidecompany.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: decidecompany.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: decidecompany.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: decidecompany.com] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [68.191.95.188 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [68.191.95.188 listed in dnsbl.sorbs.net] * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: decidecompany.com] * 0.3 HOST_MISMATCH_COM HOST_MISMATCH_COM * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7Af0tHMJoSL for ; Fri, 1 Feb 2008 04:43:32 -0800 (PST) Received: from [68.191.95.188] (68-191-95-188.dhcp.thbd.la.charter.com [68.191.95.188]) by core3.amsl.com (Postfix) with ESMTP id 7861B3A6956 for ; Fri, 1 Feb 2008 04:43:31 -0800 (PST) Message-ID: <000601c864d0$42ed9220$bc5fbf44@denise2657a7a2> From: "Kolbjorn Forsberg" <_reolvgoo@for.iu6.k12.pa.us> To: ipngwg-archive@ietf.org Subject: ***SPAM*** 113.976 (5) renejt Date: Fri, 1 Feb 2008 06:45:01 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0002_01C8649D.F8532220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0002_01C8649D.F8532220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Helpfull in Hard Cases. Helpfull in Hard Cases. ----------=_NextPart_000_0002_01C8649D.F8532220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Helpfull in Hard Cases.
Helpfull in Hard = Cases. ----------=_NextPart_000_0002_01C8649D.F8532220-- From mailman-bounces@core3.amsl.com Fri Feb 1 06:00:37 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D9929520A for ; Fri, 1 Feb 2008 05:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBSUZEp8Zets for ; Fri, 1 Feb 2008 05:56:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CAFB293891 for ; Fri, 1 Feb 2008 05:33:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipngwg-archive@lists.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:03 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/ipv6/ipngwg-archive%40lists.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:04:24 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1394B28E0BD for ; Fri, 1 Feb 2008 05:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5sdVmzNQkLk for ; Fri, 1 Feb 2008 05:58:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8412944E9 for ; Fri, 1 Feb 2008 05:33:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipngwg-archive@lists.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:00 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/ipv6/ipngwg-archive%40lists.ietf.org From ipv6-bounces@ietf.org Fri Feb 1 06:36:45 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9CD293640; Fri, 1 Feb 2008 06:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.63 X-Spam-Level: X-Spam-Status: No, score=0.63 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB9dvt2e+NNf; Fri, 1 Feb 2008 06:36:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D0D295612; Fri, 1 Feb 2008 06:15:13 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C5328D674 for ; Fri, 1 Feb 2008 05:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2NJR0bYmjwB for ; Fri, 1 Feb 2008 05:33:25 -0800 (PST) Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.4.197]) by core3.amsl.com (Postfix) with ESMTP id A302D28D07B for ; Fri, 1 Feb 2008 05:07:38 -0800 (PST) Received: from alnostro (ool-44c63439.dyn.optonline.net [68.198.52.57]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JVK00CL99V9QZ61@mta2.srv.hcvlny.cv.net> for ipv6@ietf.org; Fri, 01 Feb 2008 08:09:12 -0500 (EST) Date: Fri, 01 Feb 2008 08:09:02 -0500 From: Alex Conta Subject: RE: Checksum in IPv6 header In-reply-to: To: "'Manfredi, Albert E'" Message-id: <002701c864d3$9da03b20$6501a8c0@alnostro> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0799277596==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0799277596== Content-type: multipart/alternative; boundary="Boundary_(ID_hBas8nVixSm+V2MC2y8Bhw)" This is a multi-part message in MIME format. --Boundary_(ID_hBas8nVixSm+V2MC2y8Bhw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I am not seeing the problem. The "non-secure IPv6 link" you're mentioning is a "virtual link", over a "real" physical link. The "real" physical link, the "real" L2, provides the error detection, which uncovers packet errors in the IPv6 tunnel packets, like on any other IPv6 packet. -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Thursday, January 31, 2008 3:09 PM To: Alex Conta Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header [....] _____ From: Alex Conta [mailto:aconta@optonline.net] Sent: Thursday, January 31, 2008 12:50 PM To: 'Rahim Choudhary'; Templin, Fred L; 'Fred Baker' Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header The reason is IPsec tunnels, where encrypted packets are tunneled through a non-secure IPv6 link. In such cases, you can't count on L2 checksums when going across the tunnel boundaries. Or did I miss part of that recent thread? Bert --Boundary_(ID_hBas8nVixSm+V2MC2y8Bhw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
I am not seeing the problem.
 
The "non-secure IPv6 link" you're mentioning is a "virtual link", over a "real" physical link. The "real" physical link, the "real" L2, provides the error detection, which uncovers packet errors in the IPv6 tunnel packets, like on any other IPv6 packet.
 
-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Thursday, January 31, 2008 3:09 PM
To: Alex Conta
Cc: ipv6@ietf.org
Subject: RE: Checksum in IPv6 header
 [....] 
From: Alex Conta [mailto:aconta@optonline.net]
Sent: Thursday, January 31, 2008 12:50 PM
To: 'Rahim Choudhary'; Templin, Fred L; 'Fred Baker'
Cc: ipv6@ietf.org
Subject: RE: Checksum in IPv6 header
The reason is IPsec tunnels, where encrypted packets are tunneled through a non-secure IPv6 link. In such cases, you can't count on L2 checksums when going across the tunnel boundaries. Or did I miss part of that recent thread?
 
Bert
 
--Boundary_(ID_hBas8nVixSm+V2MC2y8Bhw)-- --===============0799277596== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0799277596==-- From EltondigestibleMelton@newscientist.com Fri Feb 1 07:17:12 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB2628C5F7; Fri, 1 Feb 2008 07:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 18.86 X-Spam-Level: ****************** X-Spam-Status: Yes, score=18.86 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_RMML_Stock7=1.64] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.6 SARE_RMML_Stock7 BODY: SARE_RMML_Stock7 * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [41.201.230.183 listed in zen.spamhaus.org] * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 1.5 DNS_FROM_RFC_BOGUSMX RBL: Envelope sender in * bogusmx.rfc-ignorant.org * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.6 HELO_MISMATCH_NET HELO_MISMATCH_NET * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH-AH-SAa8pX; Fri, 1 Feb 2008 07:17:11 -0800 (PST) Received: from poste01ne9z3yz.mshome.net (unknown [41.201.230.183]) by core3.amsl.com (Postfix) with SMTP id DFD7628D546; Fri, 1 Feb 2008 06:39:40 -0800 (PST) Message-ID: <0d8101c864e0$844ed570$0600a8c0@poste01ne9z3yz> From: "Elton Bruce" To: Subject: ***SPAM*** 18.86 (5) Market investor alert Date: Fri, 1 Feb 2008 15:41:00 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D7D_01C864E0.844ED570" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 This is a multi-part message in MIME format. ------=_NextPart_000_0D7D_01C864E0.844ED570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We told you to keep watching, G & S Minerals... Symol : GSML Gold is reaching record of $1000/ oz ... GSML is the undiscovered gem = you should be invested in. Up 4 straight days with record volume If you missed the move from .13 to .17 dont dispair they have not even = scratched the surfact. This company is going to $3.00 So grab yourself some GSML and earn easy 10 bagger ------=_NextPart_000_0D7D_01C864E0.844ED570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
We told you to keep = watching, G &=20 S Minerals... Symol : GSML

Gold is reaching = record of $1000/=20 oz ... GSML is the undiscovered gem you should be invested=20 in.

Up 4 straight days with = record=20 volume

If you missed the move = from .13 to .17=20 dont dispair they have not even scratched the surfact.

This company is going to=20 $3.00

So grab yourself = some GSML and=20 earn easy 10 bagger

------=_NextPart_000_0D7D_01C864E0.844ED570-- From ipv6-bounces@ietf.org Fri Feb 1 07:27:53 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2E728C363; Fri, 1 Feb 2008 07:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.384 X-Spam-Level: X-Spam-Status: No, score=0.384 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_20=-0.74, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBC8OutpAp4c; Fri, 1 Feb 2008 07:27:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B264B3A6B52; Fri, 1 Feb 2008 07:22:47 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4773A6B4E for ; Fri, 1 Feb 2008 07:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR43Ktuqu+t7 for ; Fri, 1 Feb 2008 07:22:45 -0800 (PST) Received: from web54306.mail.re2.yahoo.com (web54306.mail.re2.yahoo.com [206.190.49.116]) by core3.amsl.com (Postfix) with SMTP id 22CA328C7FF for ; Fri, 1 Feb 2008 07:11:05 -0800 (PST) Received: (qmail 7057 invoked by uid 60001); 1 Feb 2008 15:12:39 -0000 X-YMail-OSG: a98ckH8VM1lYrN5chsPqXEZw5E2UbLo6b..DH2SLlX9Qt6ukQKqiscpOlew3nw8VzcgdwImnlEOBmtAihkvDmg2HzB_MZMuWm_Zm6DuD6aGmzBvYB7UfdrQG7Y0BX0mOI08Q1CjCjzmeMWXk8uMveg-- Received: from [208.97.217.4] by web54306.mail.re2.yahoo.com via HTTP; Fri, 01 Feb 2008 07:12:39 PST Date: Fri, 1 Feb 2008 07:12:39 -0800 (PST) From: Rahim Choudhary Subject: Re: Checksum in IPv6 header To: Iljitsch van Beijnum , Vishwas Manral In-Reply-To: <5111327E-F9CA-4A7C-B530-10648BE313EE@muada.com> MIME-Version: 1.0 Message-ID: <386586.5512.qm@web54306.mail.re2.yahoo.com> Cc: "Templin, Fred L" , Alex Conta , ipv6@ietf.org, Fred Baker , Rahim Choudhary X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2046141821==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============2046141821== Content-Type: multipart/alternative; boundary="0-540809334-1201878759=:5512" Content-Transfer-Encoding: 8bit --0-540809334-1201878759=:5512 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Yes I meant it in the sense Wishwas explained it. And I also meant it in the sense of someone maliciously toggling bits. Let me say a word about the latter. Assuming that layer 2 CRC will be kosher after the bits have been maliciously toggled in the mutable fields of the front IPv6 header. This could happen because the bits were toggled leaving the CRC intact or they were toggled and the CRC was also recalculated. Now if the change is in the muteable fields (DSCP, TTL) then no IPSec measure seems to be able to detect that. This could be a vulnerability that either causes the packets to drop on the way (TTL manipulation) or assigns them to the wrong class (DSCP manipulation). Moreover as Wishwas pointed out, if only ESP is used without AH (and the support for AH is now not a MUST but a MAY) then we have a bigger problem. Now the front IPv6 header is entirely unprotected including the to and from addresses (Iljitsch please note that no matter how many encapsulations are made, there will always be a first header). The packets can end up at unintended destinations. This is serious from security point of view. And if IPSec is not used then there is a whole new swing of security issues. Admittedly all these are also possible for IPv4. The point is that IPv6 did not use an opportunity to fix any of this. And ironically the popular perception is that IPv6 is more secure than IPv4. Iljitsch van Beijnum wrote: On 1 feb 2008, at 1:59, Vishwas Manral wrote: > For ESP (RFC4303) the ICV does not cover the outer IP header at all > the mutable field or not. For AH (RFC4302) however the outer IP header > is covered for the ICV calculation. Yes. So if you want to cryptographically protect your header, either use AH or put the packet into another packet and protect the original packet with ESP. A header checksum will give you none of this because the checksum algorithm used in IP is so simple I can calculate it in my head (just 16-bit additions over data that's in the packet). Note also that all the important fields in the IP header are included in the transport layer checksum, which also makes it unnecessary to do a separate header checksum to protect these fields against bit errors. Last but not least, if an attacker can toggle bits in your header, it really doesn't matter whether you have cryptographically strong means to detect this, because what you would be doing is dropping the packet, while any of this toggling would also result in dropping the packet at some point, all else being equal. (The attacker could also toggle bits in the data part of the packet so the receiver would accept bad data, but IPsec AH/ESP or even TLS all provide protection against that regardless of header checksums.) --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. --0-540809334-1201878759=:5512 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Yes I meant it in the sense Wishwas explained it. And I also meant it in the sense of someone maliciously toggling bits. Let me say a word about the latter.
 
Assuming that layer 2 CRC will be kosher after the bits have been maliciously toggled in the mutable fields of the front IPv6 header. This could happen because the bits were toggled leaving the CRC intact or they were toggled and the CRC was also recalculated.
 
Now if the change is in the muteable fields (DSCP, TTL) then no IPSec measure seems to be able to detect that. This could be a vulnerability that either causes the packets to drop on the way (TTL manipulation) or assigns them to the wrong class (DSCP manipulation).
 
Moreover as Wishwas pointed out, if only ESP is used without AH (and the support for AH is now not a MUST but a MAY) then we have a bigger problem. Now the front IPv6 header is entirely unprotected including the to and from addresses (Iljitsch please note that no matter how many encapsulations are made, there will always be a first header). The packets can end up at unintended destinations. This is serious from security point of view.
 
And if IPSec is not used then there is a whole new swing of security issues.
 
Admittedly all these are also possible for IPv4. The point is that IPv6 did not use an opportunity to fix any of this. And ironically the popular perception is that IPv6 is more secure than IPv4.
 


Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 1 feb 2008, at 1:59, Vishwas Manral wrote:

> For ESP (RFC4303) the ICV does not cover the outer IP header at all
> the mutable field or not. For AH (RFC4302) however the outer IP header
> is covered for the ICV calculation.

Yes. So if you want to cryptographically protect your header, either
use AH or put the packet into another packet and protect the original
packet with ESP.

A header checksum will give you none of this because the checksum
algorithm used in IP is so simple I can calculate it in my head (just
16-bit additions over data that's in the packet).

Note also that all the important fields in the IP header are included
in the transport layer checksum, which also makes it unnecessary to do
a separate header checksum to protect these fields against bit errors.

Last but not least, if an attacker can toggle bits in your header, it
really doesn't matter whether you have cryptographically strong means
to detect this, because what you would be doing is dropping the
packet, while any of this toggling would also result in dropping the
packet at some point, all else being equal. (The attacker could also
toggle bits in the data part of the packet so the receiver would
accept bad data, but IPsec AH/ESP or even TLS all provide protection
against that regardless of header checksums.)

Looking for last minute shopping deals? Find them fast with Yahoo! Search. --0-540809334-1201878759=:5512-- --===============2046141821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2046141821==-- From ipv6-bounces@ietf.org Fri Feb 1 07:29:55 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BB128C53A; Fri, 1 Feb 2008 07:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gENOQ-LHFOHO; Fri, 1 Feb 2008 07:29:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF6F3A6C34; Fri, 1 Feb 2008 07:26:47 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20083A6C2F for ; Fri, 1 Feb 2008 07:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZHD72lRKmNx for ; Fri, 1 Feb 2008 07:26:45 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 134EB28C540 for ; Fri, 1 Feb 2008 07:19:02 -0800 (PST) Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m11FIstr060638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2008 16:18:55 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: <819C6563-6788-4202-857D-F0FE122F5488@muada.com> From: Iljitsch van Beijnum To: Rahim Choudhary In-Reply-To: <386586.5512.qm@web54306.mail.re2.yahoo.com> Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Checksum in IPv6 header Date: Fri, 1 Feb 2008 16:19:08 +0100 References: <386586.5512.qm@web54306.mail.re2.yahoo.com> X-Mailer: Apple Mail (2.915) Cc: "Templin, Fred L" , Alex Conta , ipv6@ietf.org, Fred Baker X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 1 feb 2008, at 16:12, Rahim Choudhary wrote: > Now if the change is in the muteable fields (DSCP, TTL) then no > IPSec measure seems to be able to detect that. This could be a > vulnerability that either causes the packets to drop on the way (TTL > manipulation) or assigns them to the wrong class (DSCP manipulation). Who cares? If an attacker can flip your bits she can also flip the most significant bit in the destination address and you'll never receive that packet. The only thing a cryptographic hash over the header would give you there is the ability to drop the packet even sooner. And how exactly are you going to have a HMAC or some such over header fields? That requires having secret keying material in EVERY ROUTER ALONG THE PATH. Can we please stop this discussion? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 1 07:36:28 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA7F28C165; Fri, 1 Feb 2008 07:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_05=-1.11, J_CHICKENPOX_82=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGV3aSY0zFLh; Fri, 1 Feb 2008 07:36:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B589E28C563; Fri, 1 Feb 2008 07:29:58 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE2B28C558 for ; Fri, 1 Feb 2008 07:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 380Lg1UO1zCL for ; Fri, 1 Feb 2008 07:29:56 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.179]) by core3.amsl.com (Postfix) with ESMTP id ACEF33A6888 for ; Fri, 1 Feb 2008 07:26:53 -0800 (PST) Received: by el-out-1112.google.com with SMTP id j27so545576elf.25 for ; Fri, 01 Feb 2008 07:28:23 -0800 (PST) Received: by 10.143.159.11 with SMTP id l11mr2246237wfo.15.1201879702704; Fri, 01 Feb 2008 07:28:22 -0800 (PST) Received: by 10.142.102.19 with HTTP; Fri, 1 Feb 2008 07:28:22 -0800 (PST) Message-ID: <77ead0ec0802010728w2931dc99y7eff9f84df4cb212@mail.gmail.com> Date: Fri, 1 Feb 2008 07:28:22 -0800 From: "Vishwas Manral" To: "Iljitsch van Beijnum" Subject: Re: Checksum in IPv6 header In-Reply-To: <819C6563-6788-4202-857D-F0FE122F5488@muada.com> MIME-Version: 1.0 Content-Disposition: inline References: <386586.5512.qm@web54306.mail.re2.yahoo.com> <819C6563-6788-4202-857D-F0FE122F5488@muada.com> Cc: "Templin, Fred L" , Alex Conta , ipv6@ietf.org, Rahim Choudhary , Fred Baker X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Iljitsh, You have a point when you say that if a malicious router could toggle some bits, it could as well drop the packet. However there is one small part you miss. In the above case the router can only affect traffic going through it. It could be an attack if toggling bits on the flows through a router, the router could actually affect flows not going through the router. However if it could bump up the priority(in the simplest terms) of the packets going through it, it could affect the flows of packets on other routers, as the packets needing the highest priority would considerably increase. Its an issue but a slightly of a lesser priority. Thanks, Vishwas On Feb 1, 2008 7:19 AM, Iljitsch van Beijnum wrote: > On 1 feb 2008, at 16:12, Rahim Choudhary wrote: > > > Now if the change is in the muteable fields (DSCP, TTL) then no > > IPSec measure seems to be able to detect that. This could be a > > vulnerability that either causes the packets to drop on the way (TTL > > manipulation) or assigns them to the wrong class (DSCP manipulation). > > Who cares? > > If an attacker can flip your bits she can also flip the most > significant bit in the destination address and you'll never receive > that packet. The only thing a cryptographic hash over the header would > give you there is the ability to drop the packet even sooner. > > And how exactly are you going to have a HMAC or some such over header > fields? That requires having secret keying material in EVERY ROUTER > ALONG THE PATH. > > Can we please stop this discussion? > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From cphelps@ultrahighaccuracy.com Fri Feb 1 08:11:38 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71673A6989 for ; Fri, 1 Feb 2008 08:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 97.246 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=97.246 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: tenbestshops.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: tenbestshops.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [121.190.180.138 listed in zen.spamhaus.org] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: tenbestshops.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: tenbestshops.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: tenbestshops.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: tenbestshops.com] * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: tenbestshops.com] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XKjJ7l9ImWN for ; Fri, 1 Feb 2008 08:11:37 -0800 (PST) Received: from [121.190.180.138] (unknown [121.190.180.138]) by core3.amsl.com (Postfix) with ESMTP id 10FB03A68B6 for ; Fri, 1 Feb 2008 08:09:23 -0800 (PST) Received: from [121.190.180.138] by mail-fwd.verio-web.com; Sat, 2 Feb 2008 01:37:04 +0900 Date: Sat, 2 Feb 2008 01:37:04 +0900 From: "Scot Phelps" X-Mailer: The Bat! (v3.5) Home Reply-To: cphelps@ultrahighaccuracy.com X-Priority: 3 (Normal) Message-ID: <759361689.41930036863872@ultrahighaccuracy.com> To: ipngwg-archive@ietf.org Subject: ***SPAM*** 97.246 (5) AllProductsHealthyLife MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------777E3567E35DA1" ------------777E3567E35DA1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit New generation extra-strength med, for the treatment of ED only in men. Benefits: 6-8 Hour Response Period; Improves Focus; Accelerates Recovery from Prior I|\|tercourse; Amplified Passion and Desire; Rapid-Absorption of the Chemical Component; Increased Staaamina and Libido; Psychological Confidence and Relief; Helpfull in Hard Cases. If you experience some lapses in your sexual life, please, do not hesitate or make your life worse. Just a blue-pill will cure all your doubts and restore the life you will not help enjoying. http://tenbestshops.com (Wait a moment until the page will be loaded entirely) ------------777E3567E35DA1 Content-Type: text/html; charset=windows-1250 Content-Transfer-Encoding: 7bit New generation extra-strength med, for the treatment of ED only in men.

Benefits:
6-8 Hour Response Period;
Improves Focus;
Accelerates Recovery from Prior I|\|tercourse;
Amplified Passion and Desire;
Rapid-Absorption of the Chemical Component;
Increased Staaaamina and Libido;
Psychological Confidence and Relief;
Helpfull in Hard Cases.

If you experience some lapses in your sexual life, please, do not hesitate or make your life worse.
Just a blue-pill will cure all your doubts and restore the life you will not help enjoying.

http://tenbestshops.com
(Wait a moment until the page will be loaded entirely) ------------777E3567E35DA1-- From ipv6-bounces@ietf.org Fri Feb 1 08:18:48 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E408128C1EE; Fri, 1 Feb 2008 08:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tavuSQX35yQz; Fri, 1 Feb 2008 08:18:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5863A6812; Fri, 1 Feb 2008 08:18:42 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78193A6847 for ; Fri, 1 Feb 2008 08:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGsEZDZx7UFm for ; Fri, 1 Feb 2008 08:18:40 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.176]) by core3.amsl.com (Postfix) with ESMTP id EBDCD3A6812 for ; Fri, 1 Feb 2008 08:18:39 -0800 (PST) Received: by el-out-1112.google.com with SMTP id j27so571722elf.25 for ; Fri, 01 Feb 2008 08:20:14 -0800 (PST) Received: by 10.142.108.14 with SMTP id g14mr2290707wfc.52.1201882813652; Fri, 01 Feb 2008 08:20:13 -0800 (PST) Received: by 10.142.102.19 with HTTP; Fri, 1 Feb 2008 08:20:13 -0800 (PST) Message-ID: <77ead0ec0802010820y363e487bta38ab129fd94c1fa@mail.gmail.com> Date: Fri, 1 Feb 2008 08:20:13 -0800 From: "Vishwas Manral" To: "Iljitsch van Beijnum" Subject: Re: Checksum in IPv6 header In-Reply-To: <5111327E-F9CA-4A7C-B530-10648BE313EE@muada.com> MIME-Version: 1.0 Content-Disposition: inline References: <284045.36234.qm@web54304.mail.re2.yahoo.com> <7E1966B0-2EAD-44B4-AD07-9D00044EB09A@cisco.com> <77ead0ec0801311659t11763624qf27c03fcef588db3@mail.gmail.com> <5111327E-F9CA-4A7C-B530-10648BE313EE@muada.com> Cc: "Templin, Fred L" , Alex Conta , ipv6@ietf.org, Fred Baker , Rahim Choudhary X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Iljitsch, I agree with you. However if you take note of RFC4301 - the IPsec base RFC, the AH has been downgraded to a MAY support. So not all machines will support AH. I agree we can do without checksum, am just trying to fill in when I feel there is some additional information that discussion could gain from. Thanks, Vishwas On Feb 1, 2008 1:02 AM, Iljitsch van Beijnum wrote: > On 1 feb 2008, at 1:59, Vishwas Manral wrote: > > > For ESP (RFC4303) the ICV does not cover the outer IP header at all > > the mutable field or not. For AH (RFC4302) however the outer IP header > > is covered for the ICV calculation. > > Yes. So if you want to cryptographically protect your header, either > use AH or put the packet into another packet and protect the original > packet with ESP. > > A header checksum will give you none of this because the checksum > algorithm used in IP is so simple I can calculate it in my head (just > 16-bit additions over data that's in the packet). > > Note also that all the important fields in the IP header are included > in the transport layer checksum, which also makes it unnecessary to do > a separate header checksum to protect these fields against bit errors. > > Last but not least, if an attacker can toggle bits in your header, it > really doesn't matter whether you have cryptographically strong means > to detect this, because what you would be doing is dropping the > packet, while any of this toggling would also result in dropping the > packet at some point, all else being equal. (The attacker could also > toggle bits in the data part of the packet so the receiver would > accept bad data, but IPsec AH/ESP or even TLS all provide protection > against that regardless of header checksums.) > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 1 08:47:34 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0BD28C1BE; Fri, 1 Feb 2008 08:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.785 X-Spam-Level: X-Spam-Status: No, score=0.785 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_50=0.001, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X93Mt8E1hxBx; Fri, 1 Feb 2008 08:47:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0453A68B0; Fri, 1 Feb 2008 08:47:33 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA6C3A68B0 for ; Fri, 1 Feb 2008 08:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJmhHEEhysow for ; Fri, 1 Feb 2008 08:47:30 -0800 (PST) Received: from web54307.mail.re2.yahoo.com (web54307.mail.re2.yahoo.com [206.190.49.117]) by core3.amsl.com (Postfix) with SMTP id 689263A67F2 for ; Fri, 1 Feb 2008 08:47:30 -0800 (PST) Received: (qmail 35018 invoked by uid 60001); 1 Feb 2008 16:49:04 -0000 X-YMail-OSG: xyAcieMVM1nEiKYZnAfiZTPi6FcgIHVo0_O3IkQvbRjPeCbBNunuv_IIc6kLmt3YTNQo7ankvSUDHQTEUHKPEZbctTlLXc65yQ.OKzAxSWD_xqj90alWQVGkWGMsPQ-- Received: from [208.97.217.4] by web54307.mail.re2.yahoo.com via HTTP; Fri, 01 Feb 2008 08:49:04 PST Date: Fri, 1 Feb 2008 08:49:04 -0800 (PST) From: Rahim Choudhary Subject: Re: Checksum in IPv6 header To: Vishwas Manral In-Reply-To: <77ead0ec0802010820y363e487bta38ab129fd94c1fa@mail.gmail.com> MIME-Version: 1.0 Message-ID: <879425.34033.qm@web54307.mail.re2.yahoo.com> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2134766935==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============2134766935== Content-Type: multipart/alternative; boundary="0-1832897909-1201884544=:34033" Content-Transfer-Encoding: 8bit --0-1832897909-1201884544=:34033 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Another point to note is this. In the case that a packet checksum/hash is used, a corrupted packet gets dropped on its way, whereas without such a checksum/hash it is dropped at the destination. Thus additional network resources are consumed. All this is assuming that layer 2 CRC has been circumvented. Vishwas Manral wrote: Hi Iljitsch, I agree with you. However if you take note of RFC4301 - the IPsec base RFC, the AH has been downgraded to a MAY support. So not all machines will support AH. I agree we can do without checksum, am just trying to fill in when I feel there is some additional information that discussion could gain from. Thanks, Vishwas On Feb 1, 2008 1:02 AM, Iljitsch van Beijnum wrote: > On 1 feb 2008, at 1:59, Vishwas Manral wrote: > > > For ESP (RFC4303) the ICV does not cover the outer IP header at all > > the mutable field or not. For AH (RFC4302) however the outer IP header > > is covered for the ICV calculation. > > Yes. So if you want to cryptographically protect your header, either > use AH or put the packet into another packet and protect the original > packet with ESP. > > A header checksum will give you none of this because the checksum > algorithm used in IP is so simple I can calculate it in my head (just > 16-bit additions over data that's in the packet). > > Note also that all the important fields in the IP header are included > in the transport layer checksum, which also makes it unnecessary to do > a separate header checksum to protect these fields against bit errors. > > Last but not least, if an attacker can toggle bits in your header, it > really doesn't matter whether you have cryptographically strong means > to detect this, because what you would be doing is dropping the > packet, while any of this toggling would also result in dropping the > packet at some point, all else being equal. (The attacker could also > toggle bits in the data part of the packet so the receiver would > accept bad data, but IPsec AH/ESP or even TLS all provide protection > against that regardless of header checksums.) > --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-1832897909-1201884544=:34033 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Another point to note is this. In the case that a packet checksum/hash is used, a corrupted packet gets dropped on its way, whereas without such a checksum/hash it is dropped at the destination. Thus additional network resources are consumed. All this is assuming that layer 2 CRC has been circumvented.
 
 

Vishwas Manral <vishwas.ietf@gmail.com> wrote:
Hi Iljitsch,

I agree with you. However if you take note of RFC4301 - the IPsec base
RFC, the AH has been downgraded to a MAY support. So not all machines
will support AH. I agree we can do without checksum, am just trying to
fill in when I feel there is some additional information that
discussion could gain from.

Thanks,
Vishwas

On Feb 1, 2008 1:02 AM, Iljitsch van Beijnum wrote:
> On 1 feb 2008, at 1:59, Vishwas Manral wrote:
>
> > For ESP (RFC4303) the ICV does not cover the outer IP header at all
> > the mutable field or not. For AH (RFC4302) however the outer IP header
> > is covered for the ICV calculation.
>
> Yes. So if you want to cryptographically protect your header, either
> use AH or put the packet into another packet and protect the original
> packet with ESP.
>
> A header checksum will give you none of this because the checksum
> algorithm used in IP is so simple I can calculate it in my head (just
> 16-bit additions over data that's in the packet).
>
> Note also that all the important fields in the IP header are included
> in the transport layer checksum, which also makes it unnecessary to do
> a separate header checksum to protect these fields against bit errors.
>
> Last but not least, if an attacker can toggle bits in your header, it
> really doesn't matter whether you have cryptographically strong means
> to detect this, because what you would be doing is dropping the
> packet, while any of this toggling would also result in dropping the
> packet at some point, all else being equal. (The attacker could also
> toggle bits in the data part of the packet so the receiver would
> accept bad data, but IPsec AH/ESP or even TLS all provide protection
> against that regardless of header checksums.)
>

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-1832897909-1201884544=:34033-- --===============2134766935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2134766935==-- From vendite@ups.edu Fri Feb 1 09:47:26 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5A13A688A for ; Fri, 1 Feb 2008 09:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 52.689 X-Spam-Level: **************************************************** X-Spam-Status: Yes, score=52.689 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.0 HELO_EQ_BR HELO_EQ_BR * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 190.18.51.224] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 190.18.51.224] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [201.8.57.185 listed in zen.spamhaus.org] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 190.18.51.224] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [201.8.57.185 listed in dnsbl.sorbs.net] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.4 HELO_MISMATCH_BR HELO_MISMATCH_BR Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNBTinRj2rcU for ; Fri, 1 Feb 2008 09:47:25 -0800 (PST) Received: from 201008057185.user.veloxzone.com.br (unknown [201.8.57.185]) by core3.amsl.com (Postfix) with SMTP id 389233A681A for ; Fri, 1 Feb 2008 09:47:24 -0800 (PST) Received: from [87.179.166.157] (helo=zshy) by 201008057185.user.veloxzone.com.br with smtp (Exim 4.62 (FreeBSD)) id 1JL05-0002bW-HA; Fri, 1 Feb 2008 14:53:26 -0300 Message-ID: <47A35B8A.4000702@ups.edu> Date: Fri, 1 Feb 2008 14:48:58 -0300 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: ipngwg-archive@lists.ietf.org Subject: ***SPAM*** 52.689 (5) The Dance of Love Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My Love http://190.18.51.224/ From montes@wattspohn.com Fri Feb 1 09:57:15 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BEB3A67F2 for ; Fri, 1 Feb 2008 09:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 48.391 X-Spam-Level: ************************************************ X-Spam-Status: Yes, score=48.391 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_ILLEGAL_IP=1.908, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134, TVD_RCVD_IP=1.931, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 3.5 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split * IP) * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 2.1 TVD_FINGER_02 TVD_FINGER_02 * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 1.9 RCVD_ILLEGAL_IP Received: contains illegal IP address * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 92.114.161.153] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 92.114.161.153] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [84.102.225.191 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [84.102.225.191 listed in dnsbl.sorbs.net] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLrnSRLMFm0A for ; Fri, 1 Feb 2008 09:57:14 -0800 (PST) Received: from 191.225.102-84.rev.gaoland.net (191.225.102-84.rev.gaoland.net [84.102.225.191]) by core3.amsl.com (Postfix) with SMTP id BCFF53A693A for ; Fri, 1 Feb 2008 09:57:12 -0800 (PST) Received: (qmail 7448 invoked from network); Fri, 1 Feb 2008 18:58:41 +0100 Received: from unknown (HELO wzz) (225.197.165.97) by 191.225.102-84.rev.gaoland.net with SMTP; Fri, 1 Feb 2008 18:58:41 +0100 Message-ID: <001201c864fc$13ffb340$61a5c5e1@wzz> From: To: Subject: ***SPAM*** 48.391 (5) The Moon & Stars Date: Fri, 1 Feb 2008 18:58:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Our Love Will Last http://92.114.161.153/ From radelast@WAGNEREQUIPMENTCO.COM Fri Feb 1 10:38:42 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C22E28C51F for ; Fri, 1 Feb 2008 10:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 94.415 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=94.415 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) * 1.2 HELO_EQ_TELESP HELO_EQ_TELESP * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.3 HOST_EQ_BR HOST_EQ_BR * 1.0 HELO_EQ_BR HELO_EQ_BR * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: bjoogehhy.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: bjoogehhy.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: bjoogehhy.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: bjoogehhy.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: bjoogehhy.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [201.92.142.238 listed in zen.spamhaus.org] * 1.7 SARE_RECV_SPAM_DOMN02 Email passed through apparent spammer domain * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGWSUY3xkcYS for ; Fri, 1 Feb 2008 10:38:40 -0800 (PST) Received: from 201-92-142-238.dsl.telesp.net.br (201-92-142-238.dsl.telesp.net.br [201.92.142.238]) by core3.amsl.com (Postfix) with ESMTP id F3A4F28C4C5 for ; Fri, 1 Feb 2008 10:38:19 -0800 (PST) Message-ID: <000f01c8650a$4b5948c0$ee8e5cc9@usuario473feb5> From: "Corine cai" To: ipngwg-archive@ietf.org Subject: ***SPAM*** 94.415 (5) Ever wanted a GIANT ROD? Click here for one. Date: Fri, 1 Feb 2008 16:40:26 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C864F1.260C10C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000B_01C864F1.260C10C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Amaze your chick with your new legendary manhood. ----------=_NextPart_000_000B_01C864F1.260C10C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Amaze your chick with your new = legendary=20 manhood. ----------=_NextPart_000_000B_01C864F1.260C10C0-- From _valittet@DBC-NJ.COM Fri Feb 1 11:38:21 2008 Return-Path: <_valittet@DBC-NJ.COM> X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1713A6915 for ; Fri, 1 Feb 2008 11:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 83.13 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=83.13 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.2 HOST_EQ_IT HOST_EQ_IT * 0.6 HELO_EQ_IT HELO_EQ_IT * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: rghpseopga.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: rghpseopga.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: rghpseopga.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: rghpseopga.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: rghpseopga.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: rghpseopga.com] * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWFx5hEL2ZF9 for ; Fri, 1 Feb 2008 11:38:20 -0800 (PST) Received: from host154-70-static.29-87-b.business.telecomitalia.it (host154-70-static.29-87-b.business.telecomitalia.it [87.29.70.154]) by core3.amsl.com (Postfix) with ESMTP id CF6C43A685A for ; Fri, 1 Feb 2008 11:38:18 -0800 (PST) Message-ID: <001001c8650a$395af600$9a461d57@user0c17588aed> From: "Elmeri Mangum" <_valittet@DBC-NJ.COM> To: ipngwg-archive@lists.ietf.org Subject: ***SPAM*** 83.13 (5) Give the girls what they want with your long and hard instrument. Date: Fri, 1 Feb 2008 20:39:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C86512.9B1F5E00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000C_01C86512.9B1F5E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Give the girls what they want with your long and hard instrument. ----------=_NextPart_000_000C_01C86512.9B1F5E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Give the girls what they want = with your=20 long and hard instrument. ----------=_NextPart_000_000C_01C86512.9B1F5E00-- From ipv6-bounces@ietf.org Fri Feb 1 12:34:59 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A7E28C29A; Fri, 1 Feb 2008 12:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqOamG1mnVk1; Fri, 1 Feb 2008 12:34:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3907C3A6976; Fri, 1 Feb 2008 12:34:58 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B38F3A6976 for ; Fri, 1 Feb 2008 12:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feaKm4RPo8hd for ; Fri, 1 Feb 2008 12:34:56 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 400983A696E for ; Fri, 1 Feb 2008 12:34:56 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m11KaTR5000410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Feb 2008 14:36:30 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m11KaTSP015173; Fri, 1 Feb 2008 12:36:29 -0800 (PST) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m11KaEab014698; Fri, 1 Feb 2008 12:36:29 -0800 (PST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 15:36:14 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Checksum in IPv6 header Date: Fri, 1 Feb 2008 15:36:08 -0500 Message-ID: In-Reply-To: <002701c864d3$9da03b20$6501a8c0@alnostro> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Checksum in IPv6 header Thread-Index: Achk06ZmephDioyQTkmn1maEVrQXwQAPjKNg References: <002701c864d3$9da03b20$6501a8c0@alnostro> From: "Manfredi, Albert E" To: "Alex Conta" X-OriginalArrivalTime: 01 Feb 2008 20:36:14.0742 (UTC) FILETIME=[16DC6B60:01C86512] Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0540640945==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0540640945== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86512.132CB1C1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86512.132CB1C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But there's no reason to believe that the L2 is the same as you enter the tunnel. You're going through a router, often to a different link layer. The L2 overhead is stripped off and replaced. =20 Bert =20 ________________________________ From: Alex Conta [mailto:aconta@optonline.net]=20 Sent: Friday, February 01, 2008 8:09 AM To: Manfredi, Albert E Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header =09 =09 I am not seeing the problem.=20 =20 The "non-secure IPv6 link" you're mentioning is a "virtual link", over a "real" physical link. The "real" physical link, the "real" L2, provides the error detection, which uncovers packet errors in the IPv6 tunnel packets, like on any other IPv6 packet. =20 -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]=20 Sent: Thursday, January 31, 2008 3:09 PM To: Alex Conta Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header [....]=20 =09 ________________________________ From: Alex Conta [mailto:aconta@optonline.net]=20 Sent: Thursday, January 31, 2008 12:50 PM To: 'Rahim Choudhary'; Templin, Fred L; 'Fred Baker' Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header The reason is IPsec tunnels, where encrypted packets are tunneled through a non-secure IPv6 link. In such cases, you can't count on L2 checksums when going across the tunnel boundaries. Or did I miss part of that recent thread? =20 Bert =20 ------_=_NextPart_001_01C86512.132CB1C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
But=20 there's no reason to believe that the L2 is the same as you enter the = tunnel.=20 You're going through a router, often to a different link layer. The L2 = overhead=20 is stripped off and replaced.
 
Bert
 

From: Alex Conta = [mailto:aconta@optonline.net]=20
Sent: Friday, February 01, 2008 8:09 AM
To: = Manfredi,=20 Albert E
Cc: ipv6@ietf.org
Subject: RE: Checksum = in IPv6=20 header

I am=20 not seeing the problem.
 
The=20 "non-secure IPv6 link" you're mentioning is a "virtual link", over a = "real"=20 physical link. The "real" physical link,=20 the "real" L2, provides the error detection, which = uncovers=20 packet errors in the IPv6 tunnel packets, like on any other IPv6=20 packet.
 
-----Original Message-----
From: = Manfredi,=20 Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: = Thursday,=20 January 31, 2008 3:09 PM
To: Alex Conta
Cc:=20 ipv6@ietf.org
Subject: RE: Checksum in IPv6=20 header
 [....] 
From: Alex Conta=20 [mailto:aconta@optonline.net]
Sent: Thursday, January = 31, 2008=20 12:50 PM
To: 'Rahim Choudhary'; Templin, Fred L; 'Fred=20 Baker'
Cc: ipv6@ietf.org
Subject: RE: Checksum = in IPv6=20 header
The reason is IPsec tunnels, where = encrypted=20 packets are tunneled through a non-secure IPv6 link. In such cases, = you=20 can't count on L2 checksums when going across the tunnel boundaries. = Or did=20 I miss part of that recent = thread?
 
Bert
 
------_=_NextPart_001_01C86512.132CB1C1-- --===============0540640945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0540640945==-- From Wilford.Milligan@primarygames.com Fri Feb 1 13:02:29 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00F33A69E8 for ; Fri, 1 Feb 2008 13:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 82.778 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=82.778 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_06_12=1.069, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, SUBJ_ALL_CAPS=2.077, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 2.1 FH_HOST_EQ_VERIZON_P Host is pool-.+verizon.net * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 1.1 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 2.1 SUBJ_ALL_CAPS Subject is all capitals * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: gravewards.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: gravewards.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: gravewards.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: gravewards.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: gravewards.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: gravewards.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [72.80.114.239 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [72.80.114.239 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 0.3 HOST_MISMATCH_NET HOST_MISMATCH_NET * 0.6 HELO_MISMATCH_COM HELO_MISMATCH_COM Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCq7LLeCSIWT for ; Fri, 1 Feb 2008 13:02:29 -0800 (PST) Received: from pc16192.myhome.westell.com (pool-72-80-114-239.nycmny.east.verizon.net [72.80.114.239]) by core3.amsl.com (Postfix) with SMTP id DC7F23A69B2 for ; Fri, 1 Feb 2008 13:02:28 -0800 (PST) Date: Fri, 1 Feb 2008 16:03:19 +0500 Message-ID: 4c6c01c86515$f7cc0240$2701a8c0@PC16192 From: "Dr Wilford Milligan" To: ipngwg-archive@ietf.org Subject: ***SPAM*** 82.778 (5) (!) IMPORTANT MIME-Version: 1.0 X-Priority: 3 (Normal) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Do you want to resolve your sexual troubles? You dont know how? Here a recipe for you.... Use link to learn more... http://www.gravewards.com/ Best regards and have a hot love From ipv6-bounces@ietf.org Sat Feb 2 12:38:09 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61033A69D2; Sat, 2 Feb 2008 12:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7KvXLe5UIdw; Sat, 2 Feb 2008 12:38:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0261B3A6A46; Sat, 2 Feb 2008 12:38:09 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121BB3A6A46 for ; Sat, 2 Feb 2008 12:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjvzhNXAwsks for ; Sat, 2 Feb 2008 12:38:06 -0800 (PST) Received: from outgoing02.lava.net (pie.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b8c]) by core3.amsl.com (Postfix) with ESMTP id F0B923A69D2 for ; Sat, 2 Feb 2008 12:38:05 -0800 (PST) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id ED323170FD9; Sat, 2 Feb 2008 10:39:40 -1000 (HST) Date: Sat, 2 Feb 2008 10:39:40 -1000 (HST) From: Antonio Querubin To: Rahim Choudhary Subject: Re: Checksum in IPv6 header In-Reply-To: <879425.34033.qm@web54307.mail.re2.yahoo.com> Message-ID: References: <879425.34033.qm@web54307.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; boundary="===============2134766935==" Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============2134766935== Content-Type: TEXT/Plain; charset=US-ASCII; format=flowed On Fri, 1 Feb 2008, Rahim Choudhary wrote: > Another point to note is this. In the case that a packet checksum/hash > is used, a corrupted packet gets dropped on its way, whereas without > such a checksum/hash it is dropped at the destination. Thus additional > network resources are consumed. All this is assuming that layer 2 CRC > has been circumvented. Router CPU is also a network resource and would be consumed if checksum was required - adding to overall latency, possibly additional hardware costs... Antonio Querubin whois: AQ7-ARIN --===============2134766935== Content-Type: TEXT/PLAIN; charset=us-ascii Content-ID: Content-Description: Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2134766935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2134766935==-- From ipv6-bounces@ietf.org Sat Feb 2 15:29:48 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AFE13A6AED; Sat, 2 Feb 2008 15:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv3gz57oo3vO; Sat, 2 Feb 2008 15:29:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516153A6A77; Sat, 2 Feb 2008 15:29:47 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F433A6AD2 for ; Sat, 2 Feb 2008 15:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DFrriiAUbs1 for ; Sat, 2 Feb 2008 15:29:44 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C0AAB3A6A8F for ; Sat, 2 Feb 2008 15:29:44 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Feb 2008 15:31:21 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m12NVLjI016338; Sat, 2 Feb 2008 15:31:21 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m12NVKwh021269; Sat, 2 Feb 2008 23:31:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Feb 2008 15:31:20 -0800 Received: from [10.242.56.213] ([10.21.76.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Feb 2008 15:31:19 -0800 In-Reply-To: References: <879425.34033.qm@web54307.mail.re2.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <4F00C143-FFF8-4A36-A9A3-2DDC44F7D35D@cisco.com> From: Fred Baker Subject: Re: Checksum in IPv6 header Date: Sun, 3 Feb 2008 01:31:06 +0200 To: Antonio Querubin X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 02 Feb 2008 23:31:19.0880 (UTC) FILETIME=[B6D30480:01C865F3] Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ipv6@ietf.org, Rahim Choudhary X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 in the big scheme of things, a checksum is peanuts compared to the other things a router does. People have decided to not check it and cited this as an argument. In our experience tweaks like this makes almost no difference whatsoever, and are often an indicator of the quality of the rest of the thing you're buying. On Feb 2, 2008, at 10:39 PM, Antonio Querubin wrote: > On Fri, 1 Feb 2008, Rahim Choudhary wrote: > >> Another point to note is this. In the case that a packet checksum/ >> hash is used, a corrupted packet gets dropped on its way, whereas >> without such a checksum/hash it is dropped at the destination. >> Thus additional network resources are consumed. All this is >> assuming that layer 2 CRC has been circumvented. > > Router CPU is also a network resource and would be consumed if > checksum was required - adding to overall latency, possibly > additional hardware costs... > > > Antonio Querubin > whois: AQ7- > ARIN------------------------------------------------------------------ > -- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- iD8DBQFHpP06bjEdbHIsm0MRArytAKCcGqp7TnacEV/IZ+kd0vt0mu9ERgCcD2jC wbN/4j6kL4ppNoKasi9EXCs= =Qkdb -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 3 13:46:04 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581493A6D75; Sun, 3 Feb 2008 13:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.819 X-Spam-Level: X-Spam-Status: No, score=0.819 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns7yvxQfjxxe; Sun, 3 Feb 2008 13:46:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6053C3A6D74; Sun, 3 Feb 2008 13:45:56 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336663A6D5B for ; Sun, 3 Feb 2008 13:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH8zmzzgW4iY for ; Sun, 3 Feb 2008 13:45:54 -0800 (PST) Received: from smtp2.mail.adnap.net.au (smtp2.mail.adnap.net.au [203.6.132.66]) by core3.amsl.com (Postfix) with ESMTP id 18EE93A6D74 for ; Sun, 3 Feb 2008 13:45:45 -0800 (PST) Received: from 122-49-140-247.ip.adam.com.au ([122.49.140.247] helo=mail.nosense.org) by smtp2.mail.adnap.net.au with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JLmfe-000IOx-6c; Mon, 04 Feb 2008 08:16:38 +1030 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 2B2824571; Mon, 4 Feb 2008 08:17:17 +1030 (CST) Date: Mon, 4 Feb 2008 08:17:16 +1030 From: Mark Smith To: Antonio Querubin Subject: Re: Checksum in IPv6 header Message-Id: <20080204081716.b75e42e1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <879425.34033.qm@web54307.mail.re2.yahoo.com> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.3; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Cc: ipv6@ietf.org, Rahim Choudhary X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Sat, 2 Feb 2008 10:39:40 -1000 (HST) Antonio Querubin wrote: > On Fri, 1 Feb 2008, Rahim Choudhary wrote: > > > Another point to note is this. In the case that a packet checksum/hash > > is used, a corrupted packet gets dropped on its way, whereas without > > such a checksum/hash it is dropped at the destination. Thus additional > > network resources are consumed. All this is assuming that layer 2 CRC > > has been circumvented. > > Router CPU is also a network resource and would be consumed if checksum > was required - adding to overall latency, possibly additional hardware > costs... > And route aggregation is probably more of a cause of packet non-delivery than checksums failing. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ArnulfooffspringMckay@assumptionoep.com Tue Feb 5 10:33:46 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id F3DFD3A6946; Tue, 5 Feb 2008 10:53:04 -0800 (PST) Received: from dfz8k821.buffalo.rr.com (cpe-74-78-157-152.buffalo.res.rr.com [74.78.157.152]) by mail.ietf.org (Postfix) with SMTP id 0296C3A832F; Mon, 4 Feb 2008 20:26:04 -0800 (PST) Message-ID: From: "Valentin Coffey" To: Cc: , =20
If you have your own = business and=20 require IMMEDIATE money to spend ANY way you like or require Extra money = to=20 give your company a boost or want A low interest loan - NO STRINGS=20 ATTACHED!
=20
Don't worry about = approval... your=20 credit will not disqualify you!
=20
http://beartb.net.cn/
------=_NextPart_000_F812_01C867AF.6BCAF520-- From RonjohnsKim@typepad.com Tue Feb 5 10:34:25 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 249B13A6C37; Tue, 5 Feb 2008 10:52:59 -0800 (PST) Received: from desktop1.domain (unknown [190.1.17.184]) by mail.ietf.org (Postfix) with SMTP id AF4BD3A7493; Mon, 4 Feb 2008 15:20:48 -0800 (PST) Received: from prophylactic by typepad.com with SMTP id elR1gAWZJF for ; Sun, 3 Feb 2008 21:21:53 -0100 From: "Javier Garrett" To: Cc: , Date: Mon, 4 Feb 2008 15:20:48 -0800 (PST) Players from the United States and around the world! Huge progressive jackpots, slots, multi-hand, and single-hand blackjack. Our casino is for you and everyone else who likes to win! $2400 welcome bonus will be deposited in your new casino account! http://flybza.com.cn/ From nrobeciw1965@albanyomsgroup.net Tue Feb 5 10:37:32 2008 Return-Path: X-Original-To: ipngwg-archive@lists.ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 95ACA3A6D29; Tue, 5 Feb 2008 10:43:09 -0800 (PST) Received: from [151.16.82.25] (unknown [151.16.82.25]) by mail.ietf.org (Postfix) with ESMTP id 5994528CEB8 for ; Tue, 5 Feb 2008 07:13:14 -0800 (PST) Message-ID: <001201c86809$db61e740$19521097@home41258e2b4d> From: "wilfried Czyzewicz" To: ipngwg-archive@lists.ietf.org Subject: Don't envy others when you can now also increase your manhood the natural way Date: Tue, 5 Feb 2008 16:14:52 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000E_01C86812.3D264F40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000E_01C86812.3D264F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yesterday, I banged my ex girlfriend, and she was amazed at how large I = was now ----------=_NextPart_000_000E_01C86812.3D264F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yesterday, I banged my ex = girlfriend, and=20 she was amazed at how large I was now ----------=_NextPart_000_000E_01C86812.3D264F40-- From rtmoraaw2002@agenciaparejas.com Tue Feb 5 10:38:27 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 2192C3A6A14; Tue, 5 Feb 2008 10:52:55 -0800 (PST) Received: from pool-138-89-191-149.nwrk.east.verizon.net (unknown [138.89.191.149]) by mail.ietf.org (Postfix) with ESMTP id 38B2528C556 for ; Tue, 5 Feb 2008 07:32:54 -0800 (PST) Message-ID: <000c01c8680c$92989ab0$95bf598a@DesignApparel> From: "cumhur tigges" To: ipngwg-archive@ietf.org Subject: No pain No hassle 100% Safe d1ck enlargement pills from herbal extracts Date: Tue, 5 Feb 2008 10:34:18 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C867E2.A9C292B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0008_01C867E2.A9C292B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Increase your pen1s size naturally with enlargement pills made from 100% = herbal ingredients ----------=_NextPart_000_0008_01C867E2.A9C292B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Increase your pen1s size naturally = with=20 enlargement pills made from 100% herbal ingredients ----------=_NextPart_000_0008_01C867E2.A9C292B0-- From EmanuelhereWilkins@govexec.com Tue Feb 5 10:39:00 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 7BA823A9C75; Tue, 5 Feb 2008 10:52:58 -0800 (PST) Received: from lbm.noos.fr (m12.net81-64-197.noos.fr [81.64.197.12]) by mail.ietf.org (Postfix) with SMTP id 8D8513A7A6C; Mon, 4 Feb 2008 17:30:18 -0800 (PST) Received: from sourdough by govexec.com with SMTP id jNisQI5WOe for ; Sat, 5 Jan 2008 02:31:33 -0100 From: "Toby Mathis" To: , Date: Mon, 4 Feb 2008 17:30:18 -0800 (PST) Play your favorite games and get $2400 welcome bonus. Come find out. Download our casino in 20 seconds to get $2400 richer when you join. Come find out. http://beartf.cn/ From affairs40@hurley-younggroup.com Tue Feb 5 10:39:26 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id E9FEB3A6AB3; Tue, 5 Feb 2008 10:52:50 -0800 (PST) Received: from [212.220.183.210] (unknown [212.220.183.210]) by mail.ietf.org (Postfix) with ESMTP id 6F6D83A9CD5 for ; Tue, 5 Feb 2008 03:55:06 -0800 (PST) Received: from [212.220.183.210] by smtp.secureserver.net; Tue, 5 Feb 2008 16:56:39 +0500 Message-ID: <01c86818$1328bd80$d2b7dcd4@affairs40> From: "Andre Stephenson" To: Subject: NewOfferForOurCustomersCustomerSupport Date: Tue, 5 Feb 2008 16:56:39 +0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 AllProductsBestsellersHealthyLife http://earsuit.com From LacyorthonormalPereira@people.com Tue Feb 5 10:43:29 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id B11B83A7075; Tue, 5 Feb 2008 10:52:51 -0800 (PST) Received: from dell01.hsd1.ma.comcast.net (c-66-30-63-213.hsd1.ma.comcast.net [66.30.63.213]) by mail.ietf.org (Postfix) with SMTP id 61CE528C41C; Tue, 5 Feb 2008 05:31:31 -0800 (PST) Message-ID: <312fa01c867fb$a0429730$d53f1e42@Dell01> From: "Maura Darling" To: , =20
If you have your own = business and=20 want IMMEDIATE ready money to spend ANY way you like or want Extra money = to=20 give your company a boost or need A low interest loan - NO STRINGS=20 ATTACHED!
=20
Don't worry about = approval... your=20 credit score will not disqualify you!
=20
http://beartd.cn/
------=_NextPart_000_312F6_01C867FB.A0429730-- From rakciks@alive-dream.com Tue Feb 5 10:43:42 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 5AD323A76B6; Tue, 5 Feb 2008 10:53:03 -0800 (PST) Received: from host-89-228-245-95.kalisz.mm.pl (host-89-228-245-95.kalisz.mm.pl [89.228.245.95]) by mail.ietf.org (Postfix) with ESMTP id D02043A805E for ; Mon, 4 Feb 2008 19:23:07 -0800 (PST) Message-ID: <001001c867a6$a6dca810$5ff5e459@p572961fead7a4> From: "dinca rebeck" To: ipngwg-archive@ietf.org Subject: Blow your lady away with the largest d1ck she has seen in her life. Date: Tue, 5 Feb 2008 04:24:44 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C867AF.08A11010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Antivirus: avast! (VPS 080204-0, 2008-02-04), Outbound message X-Antivirus-Status: Clean ----------=_NextPart_000_000C_01C867AF.08A11010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life will never be the same again once you click here. ----------=_NextPart_000_000C_01C867AF.08A11010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life will never be the same again = once you=20 click here. ----------=_NextPart_000_000C_01C867AF.08A11010-- From doris0@umc.com Tue Feb 5 10:45:01 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 123623A738E; Tue, 5 Feb 2008 10:52:48 -0800 (PST) Received: from p57AEEC6D.dip.t-dialin.net (p57AEEC6D.dip.t-dialin.net [87.174.236.109]) by mail.ietf.org (Postfix) with ESMTP id B4BAD3A9153 for ; Tue, 5 Feb 2008 01:24:06 -0800 (PST) Message-ID: <000801c867d9$0188e78b$ac5517a4@liiqxq> From: "boris bronson" To: Subject: BUY CIIALIS GENERIC, order ciialis Date: Tue, 05 Feb 2008 07:38:15 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C867D9.0187C8D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C867D9.0187C8D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable headache; indigestion; back pain; muscle aches; flushing; stuffy or = runny nose; or temporary blue tint in vision or difficulty telling the = difference between the colors blue and green (uncommon). FDA has approved new labels for C1alis special pri.ces ------=_NextPart_000_0005_01C867D9.0187C8D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

headache; indigestion; back pain; muscle aches; flushing; stuffy or = runny nose; or temporary blue tint in vision or difficulty telling the = difference between the colors blue and green (uncommon).

FDA has approved = new labels for C1alis special pri.ces

------=_NextPart_000_0005_01C867D9.0187C8D0-- From waynedudick@avalonbay.com Tue Feb 5 10:46:03 2008 Return-Path: X-Original-To: ipngwg-archive@lists.ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id F175D3A7B20; Tue, 5 Feb 2008 10:52:54 -0800 (PST) Received: from dsl.static.85-105-38075.ttnet.net.tr (unknown [85.105.148.187]) by mail.ietf.org (Postfix) with SMTP id 11FD23A88DF for ; Mon, 4 Feb 2008 22:33:12 -0800 (PST) Received: from werox ([220.113.213.108]) by dsl.static.85-105-38075.ttnet.net.tr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 08:34:46 +0200 Message-ID: <47A80386.7070400@avalonbay.com> Date: Tue, 5 Feb 2008 08:34:46 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ipngwg-archive@lists.ietf.org Subject: Come Dance with Me Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Our Love Nest http://24.8.241.168/ From dabraham1@rcn.com Tue Feb 5 10:46:29 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 384043A6953; Tue, 5 Feb 2008 10:37:56 -0800 (PST) Received: from 200.175.131.175.adsl.gvt.net.br (200.175.131.175.adsl.gvt.net.br [200.175.131.175]) by mail.ietf.org (Postfix) with ESMTP id 8B3D328C7B1 for ; Tue, 5 Feb 2008 05:43:04 -0800 (PST) Message-ID: <000701c867fd$030e0e24$82f77aa4@tygmeesj> From: "haslett byoung" To: Subject: Most widely used blue-pill to treat E_D Date: Tue, 05 Feb 2008 11:57:15 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C867FD.0309DCA4" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C867FD.0309DCA4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Newly formulated and chemically improved med for the treatment of ED = only in men, extremely enhancing male activity. Benefits: 36-48 Hour' Response Period; Concentration Peak; Non-Stoppable Desire ; Innerved Stamina; Rapid Chemical Uptake; Sensational Hardness and Firmness; Prolonged Activity; Piece and Fantasy in Mind. You can buy it and find a lot more information about our products at = SEATWAIT dot COM. Just a small-pill will cure all your doubts and restore the life you = will not help enjoying. ------=_NextPart_000_0004_01C867FD.0309DCA4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Newly formulated and chemically improved med = for the treatment of ED only in men, extremely enhancing male = activity.

Benefits:
36-48 Hour' Response Period;
Concentration Peak;
Non-Stoppable Desire ;
Innerved Stamina;
Rapid Chemical Uptake;
Sensational Hardness and Firmness;
Prolonged Activity;
Piece and Fantasy in Mind.

You can buy it and find a lot more information about our products at = SEATWAIT dot COM.

Just a small-pill will cure all your doubts = and restore the life you will not help enjoying.

------=_NextPart_000_0004_01C867FD.0309DCA4-- From c.patterson@verizon.net Tue Feb 5 10:46:39 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id EB78A3A6ABA; Tue, 5 Feb 2008 10:37:56 -0800 (PST) Received: from gateway.iiap.res.in (gateway.iiap.res.in [124.30.128.132]) by mail.ietf.org (Postfix) with ESMTP id 855453A8107 for ; Mon, 4 Feb 2008 19:30:52 -0800 (PST) Message-ID: <000901c867a7$074c78b8$96a3a1a3@xjyrbj> From: "lazarus bing" To: Subject: Get more size for your enjoyment! Date: Tue, 05 Feb 2008 01:45:01 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C867A7.07499329" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C867A7.07499329 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =09The meds you need, reliable and hassle free!=20 =09Top products of top brands. Low pricing, discounts, flawless customer = support. =09Millions of customers just can't be wrong! =09thusstill.com =09 =20 ------=_NextPart_000_0006_01C867A7.07499329 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=09

The meds = you need, reliable and hassle free!
=09Top products of top brands. Low pricing, discounts, flawless customer = support.
=20 =09Millions of customers just can't be wrong!

=09 =09
------=_NextPart_000_0006_01C867A7.07499329-- From clientserviceteam.refZ040401392L.bib@hsbc.com Tue Feb 5 10:46:49 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D4DF63A6DA7; Tue, 5 Feb 2008 10:47:46 -0800 (PST) Received: from 81.184.90.134.dyn.user.ono.com (81.184.90.134.dyn.user.ono.com [81.184.90.134]) by mail.ietf.org (Postfix) with SMTP id 2DCB73AA155 for ; Tue, 5 Feb 2008 04:45:56 -0800 (PST) Received: from triode.net.au (unknown [75.136.191.181]) by momhut.com with SMTP id VJWZ6SXR0F for ; Tue, 05 Feb 2008 06:47:30 -0600 Received: from tenchiclub.com (HELO personify.tenchiclub.com [108.142.32.32]) by smapxsmap.net with SMTP id IDBNNUUX10 for ; Tue, 05 Feb 2008 10:39:30 -0200 From: "HSBC" To: "Ipngwg-archive" Subject: customer notice: details confirmation! (message id: ff299675316ay) X-Originating-IP: 105.96.132.195 X-Mailer: Internet Mail Service (5.5.2650.21) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9D553MWCUX_J1Q9" Message-Id: <20080205124557.2DCB73AA155@mail.ietf.org> Date: Tue, 5 Feb 2008 04:45:56 -0800 (PST) ----9D553MWCUX_J1Q9 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Dear HSBC Bank business customer,

HSBC Customer Service team requests you to complete Business Internet Banking Online Form (BIB Online Form).

This procedure is obligatory for all HSBC Bank business and commercial customers.

Please select the hyperlink and visit the address listed to access BIB Online Form.

http://business-and-commercial.hsbc.com/bibform/formStart?partnerid=BIB769342956744930945115621892053921537981216512635312817

Please do not respond to this email.

-------------------------------------------------------

© Copyright hsbc.com, inc 2008. All rights reserved.

0x73255824, 0x78, 0x3, 0x55075407, 0x5712, 0x47847631, 0x1956 TH42, 984, O5N, H7N4, rcs, 7P56, 8AB, 3B3P. 0x41095375, 0x6880 PAA: 0x10, 0x44730962, 0x0, 0x4534, 0x48956210, 0x3, 0x4, 0x03843095 file: 0x57, 0x3298, 0x73, 0x4602, 0x62667752, 0x540, 0x05, 0x8 0TH7: 0x5559, 0x419, 0x070, 0x7309, 0x5718, 0x526, 0x307, 0x91, 0x8, 0x976, 0x538, 0x02, 0x21990304, 0x17025344, 0x8 0x46, 0x37, 0x2, 0x99 include: 0x92055619, 0x775, 0x6, 0x9362, 0x7372, 0x61798402, 0x80 common: 0x76, 0x05, 0x77, 0x00877490, 0x64683587, 0x96, 0x6371, 0x45539728, 0x354, 0x459

0x64, 0x27914531, 0x0, 0x63 0x30765519, 0x8962, 0x01, 0x28, 0x9918, 0x11, 0x5, 0x1059, 0x7, 0x456, 0x57146187, 0x844 include: 0x71941348, 0x99 3770, XSKT, 0RS 0x7, 0x1956 DYP: 0x3739, 0x6065, 0x387, 0x51, 0x17820631, 0x397 BUNK PZZ function revision api engine TTRK NO1O FNA. 0x721, 0x974, 0x6, 0x74, 0x924, 0x55, 0x5, 0x0, 0x05, 0x10035455 0x37646212, 0x8, 0x2, 0x0, 0x6 GZP: 0x8699, 0x4, 0x27, 0x34167053, 0x01913027, 0x12, 0x2, 0x49, 0x02, 0x67977817, 0x4, 0x47899728, 0x295

04LM: 0x11221293, 0x70008572, 0x49260449, 0x08276040, 0x93, 0x67075164, 0x6789, 0x7, 0x992, 0x76, 0x696, 0x87351253, 0x847 HWI: 0x114, 0x0, 0x6, 0x148, 0x46, 0x01, 0x1, 0x8, 0x814, 0x2, 0x931, 0x893, 0x78040309, 0x1 root: 0x698, 0x5, 0x56, 0x8634, 0x78, 0x02, 0x75007917, 0x6, 0x52, 0x0, 0x23038874 0x06, 0x1, 0x53459230, 0x59, 0x41810867, 0x2, 0x59159857, 0x35, 0x3 GI6, common, exe, hex, 87J, hex, N817. TDV: 0x93154253, 0x694 revision: 0x81205603 RYX: 0x20144244, 0x5921 revision LIRQ Q79N GK0T end engine interface I9VU ZJUO: 0x4020, 0x7, 0x37, 0x1830, 0x3, 0x554, 0x86, 0x39, 0x275, 0x18066037, 0x11

----9D553MWCUX_J1Q9-- From LeonasophisticateTrent@32hours7minutes.com Tue Feb 5 10:46:58 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 850DB3A6904; Tue, 5 Feb 2008 10:52:46 -0800 (PST) Received: from pccgaspar1.uacj.mx (unknown [148.210.31.79]) by mail.ietf.org (Postfix) with SMTP id 234F23A8E41; Tue, 5 Feb 2008 00:10:45 -0800 (PST) Received: from innards by 32hours7minutes.com with SMTP id 1vtfFj4M0V for ; Tue, 5 Feb 2008 01:02:04 +0700 From: "Becky Gunter" To: Subject: Our safe, secure games will get you smiling Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20080205081045.234F23A8E41@mail.ietf.org> Date: Tue, 5 Feb 2008 00:10:45 -0800 (PST) We're serious about fun. Players from the United States and around the world! We have it all! Our safe, secure games will get you smiling when you start seeing dollars pouring in. http://beartg.net.cn/ From jrapacz@inforelay.com Tue Feb 5 10:47:42 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 2FE9D3A77F6; Tue, 5 Feb 2008 10:38:06 -0800 (PST) Received: from ms57.hinet.net (unknown [212.48.152.149]) by mail.ietf.org (Postfix) with SMTP id 4BFF43A8B59 for ; Mon, 4 Feb 2008 23:17:42 -0800 (PST) Received: from 69.26.178.252 (HELO mx2.sitelutions.com) by ietf.org with esmtp (LXNEIMFCLA TPKRP) id clLAzy-U05SGV-LF for ipngwg-archive@ietf.org; Tue, 05 Feb 2008 10:19:22 +0300 Message-ID: <000301c867c7$6e3662f0$c0a800bc@Alisha> From: "Alisha P. Enriquez" To: "Helene B. Aaron" Subject: Your gifts on these holidays will be the most memorable! Date: Tue, 05 Feb 2008 10:19:22 +0300 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


-------------------------------------------------------------------------= -
EMAIL ID: hR79E From depsalcl1993@GutenFoods.com Tue Feb 5 10:48:05 2008 Return-Path: X-Original-To: ipngwg-archive@lists.ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 4CAE23A7620; Tue, 5 Feb 2008 10:37:52 -0800 (PST) Received: from 200-168-172-214.dsl.telesp.net.br (200-168-172-214.dsl.telesp.net.br [200.168.172.214]) by mail.ietf.org (Postfix) with ESMTP id 3C4973A7DA6 for ; Mon, 4 Feb 2008 18:42:59 -0800 (PST) Message-ID: <000f01c867a1$13c089c0$d6aca8c8@sysserver> From: "mehmet Konts" To: ipngwg-archive@lists.ietf.org Subject: Enlarge your d1ck to unprecedented lengths. Date: Tue, 5 Feb 2008 00:44:49 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C86790.5037B9C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000B_01C86790.5037B9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Real men have a real dick, don't be left behind. ----------=_NextPart_000_000B_01C86790.5037B9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Real men have a real dick, don't = be left=20 behind. ----------=_NextPart_000_000B_01C86790.5037B9C0-- From kayli@altern.org Tue Feb 5 10:56:34 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 0D5873A7F75; Tue, 5 Feb 2008 10:52:47 -0800 (PST) Received: from mail.rrhlawfirm.com (unknown [207.144.169.3]) by mail.ietf.org (Postfix) with SMTP id 2191F3A88A0 for ; Mon, 4 Feb 2008 22:30:07 -0800 (PST) Received: (qmail 17941 invoked from network); Tue, 5 Feb 2008 01:27:27 -0500 Received: from unknown (HELO vfqse) (103.31.176.212) by mail.rrhlawfirm.com with SMTP; Tue, 5 Feb 2008 01:27:27 -0500 Message-ID: <000601c867c0$2da7e9e0$d4b01f67@vfqse> From: To: Subject: Our Love Will Last Date: Tue, 5 Feb 2008 01:27:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 When Love Comes Knocking http://121.135.110.242/ From hadrian@poloralphlauren.com Tue Feb 5 11:00:35 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id A367D3A6E9F; Tue, 5 Feb 2008 10:52:49 -0800 (PST) Received: from host114-9-dynamic.11-87-r.retail.telecomitalia.it (host114-9-dynamic.11-87-r.retail.telecomitalia.it [87.11.9.114]) by mail.ietf.org (Postfix) with ESMTP id B2EE43A84A0 for ; Mon, 4 Feb 2008 20:58:24 -0800 (PST) Message-ID: <000601c867b3$03b6c4d5$2348a2ae@ipjjuth> From: "albatros tom" To: Subject: Time Limited Offer! Buy CIAALIS Today And Get 25% OFF! Date: Tue, 05 Feb 2008 03:12:35 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C867B3.03B559AA" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C867B3.03B559AA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tadalafil is usually taken when needed before sexual activity. The = effects of tadalafil may last for up to 36 hours or more. Your doctor = will determine how often you can take tadalafil. Do not take tadalafil = more often than is directed by your doctor. C|al_is 20mg x 10 p1lls =3D $89.95 only for 1,49 per p|ll ------=_NextPart_000_0003_01C867B3.03B559AA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tadalafil is usually taken when needed before sexual activity. The = effects of tadalafil may last for up to 36 hours or more. Your doctor = will determine how often you can take tadalafil. Do not take tadalafil = more often than is directed by your doctor.

C|al_is 20mg x = 10 p1lls =3D $89.95 only for 1,49 per p|ll

------=_NextPart_000_0003_01C867B3.03B559AA-- From woodrow@my-deja.com Tue Feb 5 11:01:19 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 886C63A71C7; Tue, 5 Feb 2008 10:52:58 -0800 (PST) Received: from c-68-36-90-51.hsd1.nj.comcast.net (c-68-36-90-51.hsd1.nj.comcast.net [68.36.90.51]) by mail.ietf.org (Postfix) with ESMTP id C431B28C35A for ; Tue, 5 Feb 2008 05:23:07 -0800 (PST) Message-ID: <000701c867fa$077e97f4$c33ec496@hhggm> From: "joel beth" To: Subject: Viagra $1,41 per pill. 100mg x 10 pills = $59.95. Date: Tue, 05 Feb 2008 11:37:26 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C867FA.077D549E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C867FA.077D549E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable dizziness, nausea, or angina (pain, tightness, discomfort, numbness, or = tingling in the chest, arms, neck, or jaw).Viagra $1,41 per pill. 100mg = x 10 pills =3D $59.95. New Low Priice Stoore ------=_NextPart_000_0004_01C867FA.077D549E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable dizziness, nausea, or angina (pain, tightness, discomfort, = numbness, or tingling in the chest, arms, neck, or jaw). Viagra $1,41 = per pill. 100mg x 10 pills =3D $59.95. New Low Priice = Stoore ------=_NextPart_000_0004_01C867FA.077D549E-- From rprof@edwardjones.com Tue Feb 5 11:01:32 2008 Return-Path: X-Original-To: ipngwg-archive@lists.ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 02AB63A6B6E; Tue, 5 Feb 2008 10:57:46 -0800 (PST) Received: from dsl-241-246-37.telkomadsl.co.za (dsl-241-246-37.telkomadsl.co.za [41.241.246.37]) by mail.ietf.org (Postfix) with SMTP id 602A328D83E for ; Tue, 5 Feb 2008 09:28:41 -0800 (PST) Received: (qmail 18058 invoked from network); Tue, 5 Feb 2008 19:30:07 +0200 Received: from unknown (HELO ici) (97.221.139.61) by dsl-241-246-37.telkomadsl.co.za with SMTP; Tue, 5 Feb 2008 19:30:07 +0200 Message-ID: <47A89D1F.1030404@edwardjones.com> Date: Tue, 5 Feb 2008 19:30:07 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ipngwg-archive@lists.ietf.org Subject: I Love You Because Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit When I'm With You http://74.129.224.115/ From jchovan@peoplepc.com Tue Feb 5 11:02:22 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 087543A7E31; Tue, 5 Feb 2008 10:38:03 -0800 (PST) Received: from 220-117.96-97.tampabay.res.rr.com (220-117.96-97.tampabay.res.rr.com [97.96.117.220]) by mail.ietf.org (Postfix) with ESMTP id DF1083A9A33 for ; Tue, 5 Feb 2008 03:21:24 -0800 (PST) Message-ID: <000801c867e9$04896f5b$2c7318b1@laqsujng> From: "adler de'an" To: Subject: What you will learn from us will change your sensual life for better! Date: Tue, 05 Feb 2008 09:35:35 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C867E9.048948D6" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C867E9.048948D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Newly formulated and chemically improved med for the treatment of ED = only in men, extremely enhancing male activity. Benefits: 36-48 Hour' Response Period; Concentration Peak; Non-Stoppable Desire ; Innerved Stamina; Rapid Chemical Uptake; Sensational Hardness and Firmness; Prolonged Activity; Piece and Fantasy in Mind. You can buy it and find a lot more information about our products at = SEATWAIT dot COM. Just a small-pill will cure all your doubts and restore the life you = will not help enjoying. ------=_NextPart_000_0005_01C867E9.048948D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Newly formulated and chemically improved med = for the treatment of ED only in men, extremely enhancing male = activity.

Benefits:
36-48 Hour' Response Period;
Concentration Peak;
Non-Stoppable Desire ;
Innerved Stamina;
Rapid Chemical Uptake;
Sensational Hardness and Firmness;
Prolonged Activity;
Piece and Fantasy in Mind.

You can buy it and find a lot more information about our products at = SEATWAIT dot COM.

Just a small-pill will cure all your doubts = and restore the life you will not help enjoying.

------=_NextPart_000_0005_01C867E9.048948D6-- From GraciehaneyNadeau@rascalstorebels.net Tue Feb 5 11:03:52 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id E58883A7881; Tue, 5 Feb 2008 10:52:52 -0800 (PST) Received: from lastxp.myhome.westell.com (pool-72-76-2-167.nwrknj.east.verizon.net [72.76.2.167]) by mail.ietf.org (Postfix) with SMTP id 697D13A98BB; Tue, 5 Feb 2008 03:03:14 -0800 (PST) Received: from aphid by rascalstorebels.net with SMTP id et0ARFxWfP for ; Tue, 5 Feb 2008 06:04:56 -1000 From: "Jolene Kurtz" To: Subject: We know how to treat our players Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20080205110314.697D13A98BB@mail.ietf.org> Date: Tue, 5 Feb 2008 03:03:14 -0800 (PST) Our casino is for you and everyone else who likes to win! If you're in the US or anywhere else, join your new casino paradise. When YOU WIN, we win! Best offer in gambling history . http://bearth.net.cn/ From jrainsnn@intomart.nl Tue Feb 5 11:04:43 2008 Return-Path: X-Original-To: ipngwg-archive@ietf.org Delivered-To: ietfarch-ipngwg-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 17DF33A69B3; Tue, 5 Feb 2008 10:52:52 -0800 (PST) Received: from web1.co.uk (unknown [88.239.140.76]) by mail.ietf.org (Postfix) with SMTP id 66F693A99A0 for ; Tue, 5 Feb 2008 03:14:53 -0800 (PST) Received: from 195.49.158.18 (HELO dns3.gfk.de) by ietf.org with esmtp (UFKIKGHDEDJ QPEYJ) id 5MJfyK-yiD6bq-Qw for ipngwg-archive@ietf.org; Tue, 05 Feb 2008 13:16:23 +0000 Message-ID: <0ce601c867f9$4dd63260$c0a8010a@Ruth> From: "Ruth Hewitt" To: "Nicole Lindsay" Subject: Did you know that the larger and thicker your... Date: Tue, 05 Feb 2008 13:16:23 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_3300_0D4E_01C867F9.4DD63260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 This is a multi-part message in MIME format. ------=_NextPart_3300_0D4E_01C867F9.4DD63260 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your pen!s grows into the hardest, biggest, ,thickest and most powerfu= l tool=20 you`ve ever imagined - the one you`ve always fantasized about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - THE BEST}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PHALLUS OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! TRY IS TODAY TO SUBSTANTIALLY IMPROVE YOUR MALE PACKAGE IN THIS YEAR! http://nbnibsee=2Ecom/ The agreement for the oil pipelineUnited's Scott Parker=2E Bayern Munich = midfielderSergeant Alison Eleam, Christchurch's central area negotiations between the three countries and was salutedlatitudes of the = Northern Hemisphere=2E ------=_NextPart_3300_0D4E_01C867F9.4DD63260 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
VPXL+: THE WORLD'S #1 PEN|S= EN'L@RGEMENT FORMULA!

In just= a few short weeks,=20 you`ll watch with amazement as your pen!s
grows into the hardest, big= gest, ,thickest and most powerful tool
you`ve ever imagined - the one you`ve always fantasized about
having!= No pen!s en`l@rgement=20 system is faster, easier to use, or
more effective than VPXL+= - THE BEST!

VPXL+ IS=20 GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PH= ALLUS OR=20 YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARG= E TODAY!

TRY IS TODAY TO SUBSTANTIALLY IMP= ROVE YOUR MALE PACKAGE IN THIS YEAR!



and Bulgaria, Kostas Karamanlis and Sergei Stanishevreturns for i= ndividuals are back online=2E
Line has been a huge success for our guests and for ourThe agreement for = the oil pipeline
United's Scott Parker=2E Bayern Munich midfielderSerg= eant Alison Eleam, Christchurch's central area
negotiations between th= e three countries and was salutedlatitudes of the Northern Hemisphere=2E<= /FONT> ------=_NextPart_3300_0D4E_01C867F9.4DD63260-- From ipv6-bounces@ietf.org Wed Feb 6 18:48:54 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719A83A6D3D; Wed, 6 Feb 2008 18:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.492 X-Spam-Level: X-Spam-Status: No, score=0.492 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_20=-0.74, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DogHQrTB2kqZ; Wed, 6 Feb 2008 18:48:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512FD3A690D; Wed, 6 Feb 2008 18:48:53 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58F93A690D for ; Wed, 6 Feb 2008 18:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R-nIs-X7jgk for ; Wed, 6 Feb 2008 18:48:52 -0800 (PST) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by core3.amsl.com (Postfix) with ESMTP id DF0B53A67FC for ; Wed, 6 Feb 2008 18:48:51 -0800 (PST) Received: from alnostro (ool-44c63439.dyn.optonline.net [68.198.52.57]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JVU001JML7TWFM0@mta1.srv.hcvlny.cv.net> for ipv6@ietf.org; Wed, 06 Feb 2008 21:50:22 -0500 (EST) Date: Wed, 06 Feb 2008 21:50:10 -0500 From: Alex Conta Subject: RE: Checksum in IPv6 header In-reply-to: To: "'Manfredi, Albert E'" Message-id: <001d01c86934$27f34790$6501a8c0@alnostro> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0749013950==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0749013950== Content-type: multipart/alternative; boundary="Boundary_(ID_0LAhnn9P5nlBphT1PhvNPA)" This is a multi-part message in MIME format. --Boundary_(ID_0LAhnn9P5nlBphT1PhvNPA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Yes, the L2 header is replaced at the end of each L2 segment/hop. The L2 error detection will do the job - discard and report erroneous packet - on each L2 segment/hop. One or more L2 segments/hops may correspond to one IP hop, so a packet error detection and discard on any of the L2 segments/hops will be equivalent to the IP hop error detection and discard. Alex -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Friday, February 01, 2008 3:36 PM To: Alex Conta Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header But there's no reason to believe that the L2 is the same as you enter the tunnel. You're going through a router, often to a different link layer. The L2 overhead is stripped off and replaced. Bert _____ From: Alex Conta [mailto:aconta@optonline.net] Sent: Friday, February 01, 2008 8:09 AM To: Manfredi, Albert E Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header I am not seeing the problem. The "non-secure IPv6 link" you're mentioning is a "virtual link", over a "real" physical link. The "real" physical link, the "real" L2, provides the error detection, which uncovers packet errors in the IPv6 tunnel packets, like on any other IPv6 packet. -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Thursday, January 31, 2008 3:09 PM To: Alex Conta Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header [....] _____ From: Alex Conta [mailto:aconta@optonline.net] Sent: Thursday, January 31, 2008 12:50 PM To: 'Rahim Choudhary'; Templin, Fred L; 'Fred Baker' Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header The reason is IPsec tunnels, where encrypted packets are tunneled through a non-secure IPv6 link. In such cases, you can't count on L2 checksums when going across the tunnel boundaries. Or did I miss part of that recent thread? Bert --Boundary_(ID_0LAhnn9P5nlBphT1PhvNPA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
Yes, the L2 header is replaced at the end of each L2 segment/hop. The L2 error detection will do the job - discard and report erroneous packet -  on each L2 segment/hop.
One or more L2 segments/hops may correspond to one IP hop, so a packet error detection and discard on any of the L2 segments/hops will be equivalent to the IP hop error detection and discard.
 
Alex 
 
 -----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Friday, February 01, 2008 3:36 PM
To: Alex Conta
Cc: ipv6@ietf.org
Subject: RE: Checksum in IPv6 header

But there's no reason to believe that the L2 is the same as you enter the tunnel. You're going through a router, often to a different link layer. The L2 overhead is stripped off and replaced.
 
Bert
 

From: Alex Conta [mailto:aconta@optonline.net]
Sent: Friday, February 01, 2008 8:09 AM
To: Manfredi, Albert E
Cc: ipv6@ietf.org
Subject: RE: Checksum in IPv6 header

I am not seeing the problem.
 
The "non-secure IPv6 link" you're mentioning is a "virtual link", over a "real" physical link. The "real" physical link, the "real" L2, provides the error detection, which uncovers packet errors in the IPv6 tunnel packets, like on any other IPv6 packet.
 
-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Thursday, January 31, 2008 3:09 PM
To: Alex Conta
Cc: ipv6@ietf.org
Subject: RE: Checksum in IPv6 header
 [....] 
From: Alex Conta [mailto:aconta@optonline.net]
Sent: Thursday, January 31, 2008 12:50 PM
To: 'Rahim Choudhary'; Templin, Fred L; 'Fred Baker'
Cc: ipv6@ietf.org
Subject: RE: Checksum in IPv6 header
The reason is IPsec tunnels, where encrypted packets are tunneled through a non-secure IPv6 link. In such cases, you can't count on L2 checksums when going across the tunnel boundaries. Or did I miss part of that recent thread?
 
Bert
 
--Boundary_(ID_0LAhnn9P5nlBphT1PhvNPA)-- --===============0749013950== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0749013950==-- From ipv6-bounces@ietf.org Fri Feb 8 14:15:07 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED01A28C5D5; Fri, 8 Feb 2008 14:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25VEpqXFTrAV; Fri, 8 Feb 2008 14:15:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA72628C3B8; Fri, 8 Feb 2008 14:15:02 -0800 (PST) X-Original-To: ipv6@ietf.org Delivered-To: ipv6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AEA233A80D0; Fri, 8 Feb 2008 14:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-compression-nego-v2-02.txt Message-Id: <20080208221501.AEA233A80D0@core3.amsl.com> Date: Fri, 8 Feb 2008 14:15:01 -0800 (PST) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Negotiation for IPv6 datagram compression using IPv6 Control Protocol Author(s) : S. Varada Filename : draft-ietf-ipv6-compression-nego-v2-02.txt Pages : 8 Date : 2008-2-8 The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP. This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-compression-nego-v2-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ipv6-compression-nego-v2-02.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-ipv6-compression-nego-v2-02.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: <2008-2-8140602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-compression-nego-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-compression-nego-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-2-8140602.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon Feb 11 12:30:05 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9965F28C33B; Mon, 11 Feb 2008 12:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK+xSlNC-UbZ; Mon, 11 Feb 2008 12:30:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2683A6D19; Mon, 11 Feb 2008 12:30:04 -0800 (PST) X-Original-To: ipv6@ietf.org Delivered-To: ipv6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E365A3A6D19; Mon, 11 Feb 2008 12:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-6man-node-req-bis-00.txt Message-Id: <20080211203002.E365A3A6D19@core3.amsl.com> Date: Mon, 11 Feb 2008 12:30:01 -0800 (PST) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IPv6 Node Requirements RFC 4294-bis Author(s) : J. Loughney Filename : draft-ietf-6man-node-req-bis-00.txt Pages : 20 Date : 2008-02-07 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-6man-node-req-bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-6man-node-req-bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-11122721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6man-node-req-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6man-node-req-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-11122721.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon Feb 11 12:30:14 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAA028C427; Mon, 11 Feb 2008 12:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cIi6yNwbabF; Mon, 11 Feb 2008 12:30:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE0D28C2A3; Mon, 11 Feb 2008 12:30:08 -0800 (PST) X-Original-To: ipv6@ietf.org Delivered-To: ipv6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E6BA03A6A96; Mon, 11 Feb 2008 12:30:02 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-6man-reserved-iids-00.txt Message-Id: <20080211203002.E6BA03A6A96@core3.amsl.com> Date: Mon, 11 Feb 2008 12:30:02 -0800 (PST) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Reserved IPv6 Interface Identifiers Author(s) : S. Krishnan Filename : draft-ietf-6man-reserved-iids-00.txt Pages : 11 Date : 2008-02-08 Interface Identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-reserved-iids-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-6man-reserved-iids-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-6man-reserved-iids-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-11122832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6man-reserved-iids-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6man-reserved-iids-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-11122832.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon Feb 11 13:59:34 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7B93A6CEB; Mon, 11 Feb 2008 13:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W62Aanrfclr; Mon, 11 Feb 2008 13:59:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7A93A6C86; Mon, 11 Feb 2008 13:59:33 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37E33A6C12 for ; Mon, 11 Feb 2008 13:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpArM54e9cMM for ; Mon, 11 Feb 2008 13:59:31 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 921863A6B57 for ; Mon, 11 Feb 2008 13:59:31 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1BM0lDH020781 for ; Tue, 12 Feb 2008 00:00:54 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 00:00:47 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 16:00:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: I-D Action:draft-ietf-6man-node-req-bis-00.txt Date: Mon, 11 Feb 2008 16:00:38 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533AFFD77A@daebe104.NOE.Nokia.com> In-Reply-To: <20080211203002.E365A3A6D19@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-6man-node-req-bis-00.txt Thread-Index: Achs7SHnA4FpAf9QSDGvNEuIwcuYxQAC+ogQ References: <20080211203002.E365A3A6D19@core3.amsl.com> From: To: X-OriginalArrivalTime: 11 Feb 2008 22:00:40.0130 (UTC) FILETIME=[8A32CA20:01C86CF9] X-Nokia-AV: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, I have updated this draft. I had to wrestle with the nroff to get it into xml. I spent too much time with that, so I ended up mostly updating the references and fixing the errata. I have not done to much editorial control, checking on what has changed on the many RFC updates since this was issued. That is my next task, I will try to spin a quick revision. John >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] >Sent: 11 February, 2008 12:30 >To: i-d-announce@ietf.org >Cc: ipv6@ietf.org >Subject: I-D Action:draft-ietf-6man-node-req-bis-00.txt > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. >This draft is a work item of the IPv6 Maintenance Working >Group of the IETF. > > > Title : IPv6 Node Requirements RFC 4294-bis > Author(s) : J. Loughney > Filename : draft-ietf-6man-node-req-bis-00.txt > Pages : 20 > Date : 2008-02-07 > >This document defines requirements for IPv6 nodes. It is >expected that IPv6 will be deployed in a wide range of devices >and situations. >Specifying the requirements for IPv6 nodes allows IPv6 to >function well and interoperate in a large number of situations >and deployments. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-00.txt > >To remove yourself from the I-D Announcement list, send a >message to i-d-announce-request@ietf.org with the word >unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >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-6man-node-req-bis-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-6man-node-req-bis-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant >mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > >Below is the data which will enable a MIME compliant mail >reader implementation to automatically retrieve the ASCII >version of the Internet-Draft. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 11 14:32:18 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4E23A6DB2; Mon, 11 Feb 2008 14:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ccTLoQVGuPy; Mon, 11 Feb 2008 14:32:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DEE33A6D71; Mon, 11 Feb 2008 14:32:14 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18113A6D3A for ; Mon, 11 Feb 2008 14:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVIEWTheuXW1 for ; Mon, 11 Feb 2008 14:32:12 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.184]) by core3.amsl.com (Postfix) with ESMTP id AAD373A6D6B for ; Mon, 11 Feb 2008 14:32:11 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id a46so2015314rne.10 for ; Mon, 11 Feb 2008 14:33:36 -0800 (PST) Received: by 10.142.240.9 with SMTP id n9mr499404wfh.6.1202769215441; Mon, 11 Feb 2008 14:33:35 -0800 (PST) Received: by 10.142.102.19 with HTTP; Mon, 11 Feb 2008 14:33:35 -0800 (PST) Message-ID: <77ead0ec0802111433h12e3d8aj511679d84bd693fd@mail.gmail.com> Date: Mon, 11 Feb 2008 14:33:35 -0800 From: "Vishwas Manral" To: john.loughney@nokia.com Subject: Re: I-D Action:draft-ietf-6man-node-req-bis-00.txt In-Reply-To: <19EBBEC503C3B5469070E0A6674A533AFFD77A@daebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080211203002.E365A3A6D19@core3.amsl.com> <19EBBEC503C3B5469070E0A6674A533AFFD77A@daebe104.NOE.Nokia.com> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi John, The draft states: The DES-CBC encryption algorithm [28] SHOULD NOT be supported within ESP. Security issues related to the use of DES are discussed in 'DESDIFF', 'DESINT', and 'DESCRACK'. DES-CBC is still listed as required by the existing IPsec RFCs, but updates to these RFCs will be published in the near future. DES provides 56 bits of protection, which is no longer considered sufficient. You reference RFC4835 and the RFC already makes DES-CBC as a SHOULD-NOT. I think you can totally remove this section. As the IPsec RFC already talks about it. The draft states: Since ESP encryption and authentication are both optional, support for the NULL encryption algorithm [27] and the NULL authentication algorithm [24] MUST be provided to maintain consistency with the way these services are negotiated. The IPsec RFC clearly states that NULL authentication algorithm is now a MAY and not a MUST - from RFC4303 the below: However, this standard does not require ESP implementations to offer an encryption-only service. Thanks, Vishwas On Feb 11, 2008 2:00 PM, wrote: > Hi all, > > I have updated this draft. I had to wrestle with the nroff to get it > into xml. I spent > too much time with that, so I ended up mostly updating the references > and fixing the errata. > > I have not done to much editorial control, checking on what has changed > on the many RFC > updates since this was issued. That is my next task, I will try to spin > a quick revision. > > John > > > >-----Original Message----- > >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > >Sent: 11 February, 2008 12:30 > >To: i-d-announce@ietf.org > >Cc: ipv6@ietf.org > >Subject: I-D Action:draft-ietf-6man-node-req-bis-00.txt > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > >This draft is a work item of the IPv6 Maintenance Working > >Group of the IETF. > > > > > > Title : IPv6 Node Requirements RFC 4294-bis > > Author(s) : J. Loughney > > Filename : draft-ietf-6man-node-req-bis-00.txt > > Pages : 20 > > Date : 2008-02-07 > > > >This document defines requirements for IPv6 nodes. It is > >expected that IPv6 will be deployed in a wide range of devices > >and situations. > >Specifying the requirements for IPv6 nodes allows IPv6 to > >function well and interoperate in a large number of situations > >and deployments. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-00.txt > > > >To remove yourself from the I-D Announcement list, send a > >message to i-d-announce-request@ietf.org with the word > >unsubscribe in the body of the message. > >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > >to change your subscription settings. > > > >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-6man-node-req-bis-00.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html or > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-ietf-6man-node-req-bis-00.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > >mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail > >reader implementation to automatically retrieve the ASCII > >version of the Internet-Draft. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 12 10:48:20 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420F428CD48; Tue, 12 Feb 2008 10:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkbhYo5f93J5; Tue, 12 Feb 2008 10:48:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1772E28CD20; Tue, 12 Feb 2008 10:48:19 -0800 (PST) X-Original-To: ipv6@ietf.org Delivered-To: ipv6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1C06A28C53D; Tue, 12 Feb 2008 10:48:18 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Negotiation for IPv6 datagram compression using IPv6 Control Protocol' to Proposed Standard Message-Id: <20080212184818.1C06A28C53D@core3.amsl.com> Date: Tue, 12 Feb 2008 10:48:18 -0800 (PST) Cc: 6man chair <6man-chairs@tools.ietf.org>, Internet Architecture Board , 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The IESG has approved the following document: - 'Negotiation for IPv6 datagram compression using IPv6 Control Protocol ' as a Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-compression-nego-v2-02.txt Technical Summary The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. The IPv6 Control Protocol (IPv6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for the IPv6 interface over PPP. This specification defines the compression parameter for use in IPv6 datagram compression over PPP. Working Group Summary This document was created as a result of WG discussion on advancing IPv6-over-PPP to Draft Standard. The shepherd's view is that this document has strong consensus in the WG. Protocol Quality This document has been reviewed by members of the IPv6 working group, the IPv6 working group chairs, and the chair of the PPPEXT working group. Jari Arkko has reviewed this specification for the IESG. The specification has also once already been in the IESG review in 2007, and was returned due to the need to separate the parts that advance to DS and these parts (that do not satisfy the DS advancement criteria). Note to RFC Editor Remove text from Section 2.1 as follows: OLD: [14] for IPv6 Header Compression (004f), And remove reference [14]. Replace the IANA Considerations section with the following text: No specific action is needed for the assignment of a value for the Type field of IPv6 datagram compression option specified in this specification. The current assignment is up-to-date in the registry "PPP IPV6CP CONFIGURATION OPTIONS " for item IPv6-Compression-Protocol (2) at [4]. However, the RFC reference for that item should be changed to XXXX (the RFC number for this RFC). No action is needed either for the assignment of the IPV6-Compression-Protocol values, as such values have already been defined by other documents listed in Section 2.1. Values for this field are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol. As a result, future allocation of these values is governed by RFC 3818 [8] that requires IETF Consensus. Current values are are in the registry "IPv6-Compression-Protocol Types". However, the RFC reference for that registry should be changed to XXXX (the RFC number for this RFC). Please add a new section after the IANA Considerations section: X. Management Considerations From an operational point of view the status of the negotiation and the compression algorithm on the link should be observable by an operator managing a network. There is no standard management interface that covers this at the time of the writing of this specification. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 13 00:40:35 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CEE28C70C; Wed, 13 Feb 2008 00:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4tnH-fMC+Sf; Wed, 13 Feb 2008 00:40:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DA228C42E; Wed, 13 Feb 2008 00:40:34 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55AA28C27A; Wed, 13 Feb 2008 00:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE43m1VUC2B3; Wed, 13 Feb 2008 00:40:33 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A663A28C394; Wed, 13 Feb 2008 00:40:32 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1D8frNR030578; Wed, 13 Feb 2008 10:41:53 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 10:41:52 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 10:41:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Update for ikev2-ipv6-config draft Date: Wed, 13 Feb 2008 10:41:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update for ikev2-ipv6-config draft Thread-Index: AchuHEdhVZlP14l1SVOMEXeOKcj+Nw== From: To: X-OriginalArrivalTime: 13 Feb 2008 08:41:52.0544 (UTC) FILETIME=[47F50A00:01C86E1C] X-Nokia-AV: Clean Cc: ipsec@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, I have posted a new version of the ikev2-ipv6-config draft (http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-ipv6-config) which incorporates some new ideas based on good discussions in Vancouver (Hemant and Dave, thanks!). In particular, Section 5 has new text discussing the most important design choices to be made, and Appendix A has additional solution sketches for several design choice combinations. Section 6 still proposes the same solution as in draft version -01; that is, point-to-point link model where prefixes are assigned in IKEv2 configuration payloads, and access control is enforced by IPsec (traffic selectors in SAD/SPD). To me this seems to be the simplest solution -- however, the additional sketches in Appendix A should make it easier to compare different alternatives; and comments about them would be especially welcome! Best regards, Pasi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 21 02:16:20 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60C228CADA; Thu, 21 Feb 2008 02:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru1xGuF0sfbI; Thu, 21 Feb 2008 02:16:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685D328CA97; Thu, 21 Feb 2008 02:16:17 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D3E28CAA7 for ; Thu, 21 Feb 2008 02:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMJ7CdzrSSHU for ; Thu, 21 Feb 2008 02:16:12 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 1CCAE28CA9A for ; Thu, 21 Feb 2008 02:16:11 -0800 (PST) Received: from andrew.nttv6.net ([192.47.163.201]) by mail.nttv6.net (8.14.2/8.14.1) with ESMTP id m1LAG4tt031292 for ; Thu, 21 Feb 2008 19:16:04 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-ID: <47BD4F2A.2040308@nttv6.net> Date: Thu, 21 Feb 2008 19:15:06 +0900 From: Arifumi Matsumoto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: toward sloving the address selection problems X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.16.178.5]); Thu, 21 Feb 2008 19:16:04 +0900 (JST) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Folks, Now that draft-ietf-6man-addr-select-sol was approved as an 6man wg item, I'd like to start discussion about which one we should standardize. The applicability comparison figure in section 4.1 shows that each mechanism has different applicability domain and the conclusion is that a right solution should be adopted in the right place. That doesn't mean we should standardize all the mechanisms described in this draft, but IMHO the best mechanism should be standardized if we are motivated enough to solve the address selection problems in one or multiple cases. When we looked at the above-mentioned figure, we know that shim6 is almost ready and shim6 is suitable for rather dynamically changing and unmanaged network. However, for enterprise/soho network and consumer network, we don't have a standardized way of solving address selection problems described in the problem statement draft. As I presented at Vancouver, ( http://www.ietf.org/proceedings/07dec/slides/6man-9.pdf : page4) one of our motivations is to replace a NAT-box aided IPv4 site that is attached to multiple disjoint network with an address selection mechiansim aided IPv6 network. In this case, the topology of the network is very static and hosts at the downstream of the NAT box is not always managed. From our analysis, policy distribution method seems to best meet the requirements and, moreover, this was most discussed at v6ops and supported by many people. I remember dhc chairs are ready to welcome this proposal if this is accepted by ipv6 people. I'd like to have everyone's comments on moving this mechiansm forward to dhc working group. -- Arifumi Matsumoto IP Technology Expert Team Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 21 10:16:33 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4482828C852; Thu, 21 Feb 2008 10:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.745 X-Spam-Level: X-Spam-Status: No, score=0.745 tagged_above=-999 required=5 tests=[AWL=1.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKnpNJX8jW6K; Thu, 21 Feb 2008 10:16:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC0B3A6D0E; Thu, 21 Feb 2008 10:16:31 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBEB3A6D02 for ; Thu, 21 Feb 2008 10:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY1i0ZWqlEzA for ; Thu, 21 Feb 2008 10:16:29 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E156D3A6D01 for ; Thu, 21 Feb 2008 10:16:28 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1LIGAs0001052 for ; Thu, 21 Feb 2008 20:16:22 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 20:14:15 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 20:14:15 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 20:14:15 +0200 Received: from [172.19.74.185] (dadhcp-172019074185.americas.nokia.com [172.19.74.185]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1LIECIN008061 for ; Thu, 21 Feb 2008 20:14:13 +0200 Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Bob Hinden Subject: Call for Agenda Items Date: Thu, 21 Feb 2008 10:14:12 -0800 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 21 Feb 2008 18:14:15.0369 (UTC) FILETIME=[912E4390:01C874B5] X-Nokia-AV: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, The 6man WG has a meeting slot during IETF 71 in Philadelphia. The chairs are beginning to pull together the meeting agenda. If you have a presentation request, please e-mail those to the chairs (6man- chairs@tools.ietf.org). Regards, Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 21 19:12:54 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F05B3A6856; Thu, 21 Feb 2008 19:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCWxr1+rXlXC; Thu, 21 Feb 2008 19:12:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC143A6BBA; Thu, 21 Feb 2008 19:12:53 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885A43A6BFC for ; Thu, 21 Feb 2008 19:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8SEIh53nTFk for ; Thu, 21 Feb 2008 19:12:49 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by core3.amsl.com (Postfix) with ESMTP id 59FC43A6BBA for ; Thu, 21 Feb 2008 19:12:10 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so656518wri.25 for ; Thu, 21 Feb 2008 19:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=nAuYoIA70EITR1D5j6ZgYnDUGd9WcPLOjlEAU6ehxW4=; b=CQh900TujJH3Z2wjfnLZ5+DLjF0kEqUkBltyNORmKmArgZ+9nAJ8A6SNvehFrr9raGq87huKyseE1onT/j0qLZ+aKW2psZnr594kyWhIjr+aKHU+ENVFGlhc7INnP+pCwlsQOXmvQZ6/WCjNByDi+AMzZt019oPYxMWcjSyflVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=RdhagdGWh81DxWsrPB/DZzVXfnTZ5Hriaj1pIsumEJRO36YE69uAblg0ZIuO3ueMgRsklxn9+PMeKz03qHoBln7FFjtnddntbDBfbs4Z+8cKvDlTdSme6Cd4RPZnM/i2PpasOEjZJDj2ExdZ5UwDoiVjKf4Cjzi84SYhjCYWyHg= Received: by 10.141.178.5 with SMTP id f5mr7306960rvp.112.1203649925125; Thu, 21 Feb 2008 19:12:05 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id q20sm1319159pog.5.2008.02.21.19.12.03 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Feb 2008 19:12:04 -0800 (PST) Message-ID: <47BE3D81.5010201@gmail.com> Date: Fri, 22 Feb 2008 16:12:01 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Loughney Subject: Re: I-D Action:draft-ietf-6man-node-req-bis-00.txt References: <20080211203002.E365A3A6D19@core3.amsl.com> In-Reply-To: <20080211203002.E365A3A6D19@core3.amsl.com> Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org John, Thanks for taking this on. Please can we have a list of changes from RFC 4294, as a permanent Appendix (i.e., not to be removed by the RFC Editor)? At the moment it's very hard to spot the changes, even with a diff, especially since you changed from symbolic to numeric references. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 21 19:32:52 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550313A6BFD; Thu, 21 Feb 2008 19:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR-fCams9VeH; Thu, 21 Feb 2008 19:32:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D533A6BF2; Thu, 21 Feb 2008 19:32:51 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39963A6BC4 for ; Thu, 21 Feb 2008 19:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QR42jaa425L for ; Thu, 21 Feb 2008 19:32:49 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.179]) by core3.amsl.com (Postfix) with ESMTP id B058128C291 for ; Thu, 21 Feb 2008 19:32:35 -0800 (PST) Received: by el-out-1112.google.com with SMTP id j27so451881elf.25 for ; Thu, 21 Feb 2008 19:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ET0h/hg64T9VtrVx6TZZ7zpGBS/HmN7unZrezeN1RBc=; b=Dht2425LKNWrLuOdsZ1Wg+/c2MsOAKJvfRkuENWmZTnsa1A/I8OFu6HJMbQsVh39fy6SP6FZk+YmvEBc8sYicqKzGLzZ5ZfZf9lK4gUzzwQlK6Cchr2SBq44YDuvmN0RL2C+HF7D/l5Dj2Xn1wsxTnf0zfhhkqrz6F/RQbletUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rlVKamgr5mOCYpH8IPfWuRP/zfuME0jeIiN8DQ2xCL3qtEscdNPKsZM4n1kaQ3BBFSOVw6J2284K0ENs22kJs/y5eMYXrU6yIIpMKGyZh12qDcu55vWdzMJrlAlbcxag3mft5byBPc/hMeSOJwAOf9DxuZe6aEAYeGoA0SwpYII= Received: by 10.142.77.11 with SMTP id z11mr8331690wfa.98.1203651150357; Thu, 21 Feb 2008 19:32:30 -0800 (PST) Received: by 10.143.164.14 with HTTP; Thu, 21 Feb 2008 19:32:30 -0800 (PST) Message-ID: <77ead0ec0802211932k4dbbe51end210c83cf062a7c1@mail.gmail.com> Date: Thu, 21 Feb 2008 19:32:30 -0800 From: "Vishwas Manral" To: "Brian E Carpenter" Subject: Re: I-D Action:draft-ietf-6man-node-req-bis-00.txt In-Reply-To: <47BE3D81.5010201@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080211203002.E365A3A6D19@core3.amsl.com> <47BE3D81.5010201@gmail.com> Cc: John Loughney , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Brian, You actually bring a very important issue. As a protocol implementor, I feel we need to keep track of changes for all RFC's and drafts. As we support one version of the RFC or draft the document changes so often these days. It is hard to keep track of all changes done to a document from a particular version. Thanks, Vishwas On Thu, Feb 21, 2008 at 7:12 PM, Brian E Carpenter wrote: > John, > > Thanks for taking this on. > > Please can we have a list of changes from RFC 4294, as a permanent > Appendix (i.e., not to be removed by the RFC Editor)? > > At the moment it's very hard to spot the changes, even with a diff, > especially since you changed from symbolic to numeric references. > > Brian > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 22 07:36:02 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B7728C9B4; Fri, 22 Feb 2008 07:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3njkfQnWJ263; Fri, 22 Feb 2008 07:35:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5867E28C2B9; Fri, 22 Feb 2008 07:35:58 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D46128C2B9 for ; Fri, 22 Feb 2008 07:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg4aiso2oXQE for ; Fri, 22 Feb 2008 07:35:56 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 51AC328C25A for ; Fri, 22 Feb 2008 07:35:56 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1MFZVRl016171; Fri, 22 Feb 2008 17:35:48 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 17:35:31 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 09:35:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: I-D Action:draft-ietf-6man-node-req-bis-00.txt Date: Fri, 22 Feb 2008 09:35:23 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A0109A042@daebe104.NOE.Nokia.com> In-Reply-To: <47BE3D81.5010201@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-6man-node-req-bis-00.txt Thread-Index: Ach1ALc6AObM8kXbTaaI/ZPaH9JQ2QAZ7mBQ References: <20080211203002.E365A3A6D19@core3.amsl.com> <47BE3D81.5010201@gmail.com> From: To: X-OriginalArrivalTime: 22 Feb 2008 15:35:24.0161 (UTC) FILETIME=[8A8D1710:01C87568] X-Nokia-AV: Clean Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Brian, I will fix the references, I had some issues with them when converting from nroff to xml. I have the fix. I will also create a list of changes as well, that is a good point. John >-----Original Message----- >From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >Sent: 21 February, 2008 19:12 >To: Loughney John (Nokia-OCTO/PaloAlto) >Cc: 6man >Subject: Re: I-D Action:draft-ietf-6man-node-req-bis-00.txt > >John, > >Thanks for taking this on. > >Please can we have a list of changes from RFC 4294, as a >permanent Appendix (i.e., not to be removed by the RFC Editor)? > >At the moment it's very hard to spot the changes, even with a >diff, especially since you changed from symbolic to numeric references. > > Brian > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 24 20:55:35 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC5B28C447; Sun, 24 Feb 2008 20:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsyTfjsgnl3O; Sun, 24 Feb 2008 20:55:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE6328C1C9; Sun, 24 Feb 2008 20:55:34 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3336C28C1C9 for ; Sun, 24 Feb 2008 20:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvfxbpJZlZYq for ; Sun, 24 Feb 2008 20:55:32 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D053E3A697D for ; Sun, 24 Feb 2008 20:55:31 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1P4tAJv022722 for ; Mon, 25 Feb 2008 06:55:23 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 06:53:54 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 22:53:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Updates to Node Requirements-bis Date: Sun, 24 Feb 2008 22:53:52 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis Thread-Index: Ach3amr9x4XfbXfOQt2P9TiB9jK8eQ== From: To: X-OriginalArrivalTime: 25 Feb 2008 04:53:53.0521 (UTC) FILETIME=[6B94C610:01C8776A] X-Nokia-AV: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, I am issuing a quick rev to the Node Req.-bis. There are a couple of bugs, with respect to the references, that I need to fix still, but I switched to using Symbolic References, and added a quick & dirty list of changes from RFC4294. One question, I assume that I should include "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095 in the document. Any other suggestions of things that should still be included in the draft? thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Feb 24 22:30:06 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94A928C521; Sun, 24 Feb 2008 22:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1sdfKc89rZ5; Sun, 24 Feb 2008 22:30:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6349328C379; Sun, 24 Feb 2008 22:30:04 -0800 (PST) X-Original-To: ipv6@ietf.org Delivered-To: ipv6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BA7E928C1A3; Sun, 24 Feb 2008 22:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-6man-node-req-bis-01.txt Message-Id: <20080225063001.BA7E928C1A3@core3.amsl.com> Date: Sun, 24 Feb 2008 22:30:01 -0800 (PST) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IPv6 Node Requirements RFC 4294-bis Author(s) : J. Loughney Filename : draft-ietf-6man-node-req-bis-01.txt Pages : 20 Date : 2008-02-24 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-6man-node-req-bis-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-6man-node-req-bis-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: <2008-02-24221507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6man-node-req-bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6man-node-req-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24221507.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon Feb 25 08:25:49 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F503A6E16; Mon, 25 Feb 2008 08:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsl2Ljk19yw2; Mon, 25 Feb 2008 08:25:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539C728C1C7; Mon, 25 Feb 2008 08:21:19 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0587E3A6D40 for ; Mon, 25 Feb 2008 08:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id parcQT8OYq3p for ; Mon, 25 Feb 2008 08:21:17 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 67FC028C6C6 for ; Mon, 25 Feb 2008 08:19:49 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1PGJTQY002392 for ; Mon, 25 Feb 2008 18:19:41 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 18:19:29 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 18:19:29 +0200 Received: from [209.157.142.166] (daec-linuxvpn058118.americas.nokia.com [10.241.58.118]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1PGJQIB019980; Mon, 25 Feb 2008 18:19:27 +0200 In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Bob Hinden Subject: Re: Updates to Node Requirements-bis Date: Mon, 25 Feb 2008 08:19:31 -0800 To: "Loughney John (Nokia-OCTO/PaloAlto)" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 25 Feb 2008 16:19:29.0093 (UTC) FILETIME=[324AEF50:01C877CA] X-Nokia-AV: Clean Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org John, > > One question, I assume that I should include "Deprecation of Type 0 > Routing Headers in IPv6", RFC 5095 in the document. Any other > suggestions of things that should still be included in the draft? I agree that should be included. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 08:39:41 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5039628C53B; Mon, 25 Feb 2008 08:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOe5vqNZeIeu; Mon, 25 Feb 2008 08:39:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F0B28C5DD; Mon, 25 Feb 2008 08:37:38 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECE028C307 for ; Mon, 25 Feb 2008 08:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3SGOBwOIOQf for ; Mon, 25 Feb 2008 08:37:33 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3F28D28C631 for ; Mon, 25 Feb 2008 08:36:39 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2008 11:36:33 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1PGaX1a018270; Mon, 25 Feb 2008 11:36:33 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1PEakJR011750; Mon, 25 Feb 2008 14:36:46 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:36:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Updates to Node Requirements-bis Date: Mon, 25 Feb 2008 11:36:32 -0500 Message-ID: In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis Thread-Index: Ach3amr9x4XfbXfOQt2P9TiB9jK8eQAYaHOg References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> From: "Hemant Singh (shemant)" To: , X-OriginalArrivalTime: 25 Feb 2008 16:36:32.0827 (UTC) FILETIME=[947C58B0:01C877CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1375; t=1203957393; x=1204821393; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Updates=20to=20Node=20Requirements-bis |Sender:=20 |To:=20,=20; bh=+Dk6HYiXHH0PUuw5jrvlrFyoNH8YOBgyDmTLkQQS3IU=; b=ZP/H4JgVXIjOTseHmwmoscA4U4Pl6YDSVMjwzIkb2C8wQjQQTdu1bNfDBr nHP+8Feet7ag3/BgsDjDVLSeASVo517RMFVtZl8HXmgsou6/0woVgrS4RPau NlDYUwp2FP; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org John, It would be nice to have requirements traceability in the IPv6 Node requirements document. We know you have listed all of the documents where everything came from, but it would be good to say which parts came from which documents. Some traceability is already done in the document, but it would be good to have traceability for all of the requirements. For example, saying that "this requirement stems from section x.y.z of RFCXXXX". Thanks. Wes & Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of john.loughney@nokia.com Sent: Sunday, February 24, 2008 11:54 PM To: ipv6@ietf.org Subject: Updates to Node Requirements-bis Hi all, I am issuing a quick rev to the Node Req.-bis. There are a couple of bugs, with respect to the references, that I need to fix still, but I switched to using Symbolic References, and added a quick & dirty list of changes from RFC4294. One question, I assume that I should include "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095 in the document. Any other suggestions of things that should still be included in the draft? thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 09:08:37 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F5928C81E; Mon, 25 Feb 2008 09:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_BAYES_5x8=0.8, SARE_BAYES_6x8=0.8, SARE_BAYES_7x8=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiCmScEMemK9; Mon, 25 Feb 2008 09:08:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF4928C637; Mon, 25 Feb 2008 09:06:05 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F5E28C58F for ; Mon, 25 Feb 2008 09:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+TqM3C9FoiK for ; Mon, 25 Feb 2008 09:06:02 -0800 (PST) Received: from clyde.disa.mil (clyde.disa.mil [164.117.144.159]) by core3.amsl.com (Postfix) with SMTP id 73A6728C64B for ; Mon, 25 Feb 2008 09:03:12 -0800 (PST) Received: from maine.disanet.disa-u.mil ([164.117.144.160]) by clyde.disa.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Feb 2008 12:03:05 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) Date: Mon, 25 Feb 2008 12:03:02 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis (UNCLASSIFIED) Thread-Index: Ach3amr9x4XfbXfOQt2P9TiB9jK8eQAYaHOgAAEEGPA= References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> From: "Duncan, Richard J CTR DISA JITC" To: "Hemant Singh (shemant)" , , X-OriginalArrivalTime: 25 Feb 2008 17:03:05.0967 (UTC) FILETIME=[4A1237F0:01C877D0] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1313585647==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1313585647== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00E3_01C877A6.607A3F80" This is a multi-part message in MIME format. ------=_NextPart_000_00E3_01C877A6.607A3F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE John- Is there also anyway the new node requirements RFC could be somewhat reconciled with the new US Government IPv6 Profile and the DoD IPv6 Profile? It would probably keep the confusion down a bit. 01010011 01100101 01101101 01110000 01100101 01110010 01000110 01101001 Jeremy Duncan Joint Interoperability Test Command IPv6 Test and Evaluation ManTech Telecommunications & Information Systems Office: 703-814-8384 Cell: 520-226-1789 __________________________________________________ -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Monday, February 25, 2008 11:37 AM To: john.loughney@nokia.com; ipv6@ietf.org Subject: RE: Updates to Node Requirements-bis John, It would be nice to have requirements traceability in the IPv6 Node requirements document. We know you have listed all of the documents where everything came from, but it would be good to say which parts came from which documents. Some traceability is already done in the document, but it would be good to have traceability for all of the requirements. For example, saying that "this requirement stems from section x.y.z of RFCXXXX". Thanks. Wes & Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of john.loughney@nokia.com Sent: Sunday, February 24, 2008 11:54 PM To: ipv6@ietf.org Subject: Updates to Node Requirements-bis Hi all, I am issuing a quick rev to the Node Req.-bis. There are a couple of bugs, with respect to the references, that I need to fix still, but I switched to using Symbolic References, and added a quick & dirty list of changes from RFC4294. One question, I assume that I should include "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095 in the document. Any other suggestions of things that should still be included in the draft? thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_00E3_01C877A6.607A3F80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQXTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEMDCCA5mgAwIBAgIDEAu1MA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTUwHhcNMDcwOTA1MDAwMDAwWhcN MTAwOTA0MjM1OTU5WjB+MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTETMBEGA1UECxMKQ09OVFJBQ1RPUjEkMCIGA1UEAxMb RFVOQ0FOLlJJQ0hBUkQuSi4xMDQxODMyNDQwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCi R3wjZTGP27H0sUevF1gVrxL7yquOwIdEKHDewCF2Q4cktclY471UUFtbf29tsTBnTYeF3Hn6jGMN zuWI1DO9lrRq8+4vyaSU7vGWBESftsdksb5QkHvPt0Imo5OB9652BPja+sNLmDHi/GyWT3f0i2PU ak6R1FBp7KhQrwydQQIDAQABo4IB2zCCAdcwDgYDVR0PAQH/BAQDAgUgMCYGA1UdEQQfMB2BG3Jp Y2hhcmQuZHVuY2FuLmN0ckBkaXNhLm1pbDAfBgNVHSMEGDAWgBSVtYx4q51WMzz0SKOcWO2xZIqK njAdBgNVHQ4EFgQUL3IW+qwAjH7ULvWGf2cexMnagRQwFgYDVR0gBA8wDTALBglghkgBZQIBCwkw gdUGA1UdHwSBzTCByjA0oDKgMIYuaHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RE9EJTIwRU1B SUwlMjBDQS0xNTCBkaCBjqCBi4aBiGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWlsL2NuJTNkRE9EJTIw RU1BSUwlMjBDQS0xNSUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1l bnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkwbQYIKwYBBQUHAQEE YTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwl MjBDQS0xNTAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwDQYJKoZIhvcNAQEFBQAD gYEABKywcrZrLob+BG4TA58c04o0duisKZAtVDtH+w8BJkZsAIhEVDPmiQ6Nyd4c3Q8c2ioQ+3QA 22Zzu2hYg6Vao+n8ZWohF45h0nbfXygp69l0hTfI5OHqqwpOpRl3Ji8XTiGRY3oBoN43PYv0S/h4 5yo5OYh4LHr9z7743PnPMOIwggQyMIIDGqADAgECAgEbMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTA2MDYxNDE2Mzg0NVoXDTEyMDYxNDE1Mzg0 NVowXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0xNTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAtWmVn6W25J88858A1ZoVB/zWOa7Z1rxWdsAm4DuPgalpZopKK8K1SmJRXtf7 eoDjQRaaw2bz4fyEinyH/cu7yCqmvdYXc1UZl5B7RIT8v2huinVqBM5IGdOqwrkAHmRUiF875Jvw yEcVUt8rxMploMFsA69LbIPWtuk4ZRalEIMCAwEAAaOCAYEwggF9MA4GA1UdDwEB/wQEAwIBhjAf BgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQUlbWMeKudVjM89EijnFjt sWSKip4wDAYDVR0kBAUwA4ABADAPBgNVHRMBAf8EBTADAQH/MDAGA1UdIAQpMCcwCwYJYIZIAWUC AQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCwowgdkGA1UdHwSB0TCBzjA4oDagNIYyaHR0cDov L2NybC5nZHMuZGlzYS5taWwvZ2V0Y3JsP0RvRCUyMFJvb3QlMjBDQSUyMDIwgZGggY6ggYuGgYhs ZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNvdSUzZFBL SSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NlcnRpZmljYXRl cmV2b2NhdGlvbmxpc3Q7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQCK+a1cpxe8yEyZpSqfatss ieq+c/mTtqsE0/tk0KLFaoXHyB4PKxcp/acaqDnqP3ykk6u7fbQgY3l/AUYkiqipXi4yTFGG2Y/0 wl/cktLfT5MIybmgxXJceMuWB27JCwB4F7755vm1pYh+ge1Hj6iL/vqbRYIrQlv4IaVVEtYWtPPN apuG2KwzJRQOFTmRNkzA3QixuFh2PnuDYxoX2UYLnUPxztVnMxGYVMJ4USdUjSs3mwk7PUq/Byqm exT4HOMe/R3YYmeZquIPzKaGzSp9p3q9lxPkr/fxiXDtHcMnQbYIRXAwieLXog7Wad3VxELVvrLL tnbBa5kEXr6Z8PWsMIIEezCCA+SgAwIBAgIDEAuYMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTUwHhcNMDcwOTA1MDAwMDAwWhcNMTAwOTA0MjM1OTU5 WjB+MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTETMBEGA1UECxMKQ09OVFJBQ1RPUjEkMCIGA1UEAxMbRFVOQ0FOLlJJQ0hB UkQuSi4xMDQxODMyNDQwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCw68e1AqYIvIE7P/5g TzIKvNq6sk/Gcx/jlE3Zpm/ll89TYkcyiKdVnlLmz6Jv2RvRi0NGs8Tccb0CrygD4d9GAxQwE1WZ LSJQWZLuxlnAlZXyxkYXrKRjMobgcvh/5z7sS+z43YESefwi1mIYBrQnn1dhjnKvxkvmDI6KiWma sQIDAQABo4ICJjCCAiIwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFJW1jHirnVYzPPRIo5xY 7bFkioqeMB0GA1UdDgQWBBTrEr/aMUv64HSEQe4hCbNOZErWOTAWBgNVHSAEDzANMAsGCWCGSAFl AgELCTCB1QYDVR0fBIHNMIHKMDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9ET0Ql MjBFTUFJTCUyMENBLTE1MIGRoIGOoIGLhoGIbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2RE T0QlMjBFTUFJTCUyMENBLTE1JTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292 ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTApBgNVHSUE IjAgBgorBgEEAYI3FAICBggrBgEFBQcDBAYIKwYBBQUHAwIwRgYDVR0RBD8wPYEbcmljaGFyZC5k dW5jYW4uY3RyQGRpc2EubWlsoB4GCisGAQQBgjcUAgOgEAwOMTA0MTgzMjQ0MEBtaWwwbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0xNTAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwDQYJKoZIhvcN AQEFBQADgYEAtBvwm//NKC7RmEjkgCEim4FKpStL7afxw8n/M3z7nbHodrhZkzY4hytSYA5FjKFV q8uaE0lJF0ZkEX0k457Z/E2WVrlbItf0arwh+eTR9np1b5l12wv6ogSM0GvQNXtvReinfTDFtBIN rbPbz1Cc7GT6OAMGc38QjtNw1IWk7OQxggKxMIICrQIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYD VQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQD Ew9ET0QgRU1BSUwgQ0EtMTUCAxALmDAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAyMjUxNzAzMDRaMCMGCSqGSIb3DQEJBDEWBBSHa0Vq BQwo1vS1qyVoAa+SPxFmVjBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEE AYI3EAQxZjBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTUCAxALtTB1Bgsq hkiG9w0BCRACCzFmoGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0xNQIDEAu1 MA0GCSqGSIb3DQEBAQUABIGAlXjwXmhJDHPNWzqFp+GHijNufbXei77zy7WNAMXJeXMUyPqh48iY pGG4EUQtyDUKbJIuCVbpLCI6dBXS9kiisxpR7Ar7plK++F+kezrWeCO4OKH5ZQumVfIcfIhd1c/W FNnlm+ZyDPbAadu96qBn1Cg8u34mAlQOMzUOFzTsSDYAAAAAAAA= ------=_NextPart_000_00E3_01C877A6.607A3F80-- --===============1313585647== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1313585647==-- From ipv6-bounces@ietf.org Mon Feb 25 09:11:34 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBE23A6D7C; Mon, 25 Feb 2008 09:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ9suKk6DzF8; Mon, 25 Feb 2008 09:11:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865A73A6D2B; Mon, 25 Feb 2008 09:09:58 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A90A28C6EC for ; Mon, 25 Feb 2008 09:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-2xqOJREc6R for ; Mon, 25 Feb 2008 09:09:56 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 5AB6328C6F5 for ; Mon, 25 Feb 2008 09:08:27 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1PH8jK6011541; Mon, 25 Feb 2008 11:09:33 -0600 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 19:07:42 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:07:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) Date: Mon, 25 Feb 2008 11:06:36 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis (UNCLASSIFIED) Thread-Index: Ach3amr9x4XfbXfOQt2P9TiB9jK8eQAYaHOgAAEEGPAAABy2IA== References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> From: To: , X-OriginalArrivalTime: 25 Feb 2008 17:07:30.0563 (UTC) FILETIME=[E7C85D30:01C877D0] X-Nokia-AV: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jeremy, >Is there also anyway the new node requirements RFC could be >somewhat reconciled with the new US Government IPv6 Profile >and the DoD IPv6 Profile? >It would probably keep the confusion down a bit. Would you be able to provide a summary of the differences? Also, are the US Government & the DoD IPv6 profiles publically available? What we could potentially do is look at resolving any major conflicts, if possible - or at least have an informative appendix covering this. Thoughts? John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 09:36:05 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4469D3A6DC3; Mon, 25 Feb 2008 09:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.931 X-Spam-Level: X-Spam-Status: No, score=0.931 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_BAYES_5x8=0.8, SARE_BAYES_6x8=0.8, SARE_BAYES_7x8=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JysPKn4XDaq3; Mon, 25 Feb 2008 09:36:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC5D3A6D83; Mon, 25 Feb 2008 09:32:46 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33D73A6D6D for ; Mon, 25 Feb 2008 09:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsvyRPLDFs6H for ; Mon, 25 Feb 2008 09:32:41 -0800 (PST) Received: from ionians.disa.mil (ionians.disa.mil [164.117.82.23]) by core3.amsl.com (Postfix) with SMTP id 9EA4328C6F6 for ; Mon, 25 Feb 2008 09:30:53 -0800 (PST) Received: from maine.disanet.disa-u.mil ([164.117.144.160]) by ionians.disa.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Feb 2008 12:30:47 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) Date: Mon, 25 Feb 2008 12:30:38 -0500 Message-ID: In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis (UNCLASSIFIED) Thread-Index: Ach3amr9x4XfbXfOQt2P9TiB9jK8eQAYaHOgAAEEGPAAABy2IAAAwSXg References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> <19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> From: "Duncan, Richard J CTR DISA JITC" To: , X-OriginalArrivalTime: 25 Feb 2008 17:30:47.0731 (UTC) FILETIME=[288F4830:01C877D4] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0876954457==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0876954457== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0101_01C877AA.3E6F3400" This is a multi-part message in MIME format. ------=_NextPart_000_0101_01C877AA.3E6F3400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE John- I can give you the 2 documents: DoD IPv6 Standards Profile, Version 2: http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_product_profile_v2.pdf US Government IPv6 Profile Version 1, Draft 2: http://www.antd.nist.gov/usgv6/usgv6-v1-draft2.pdf I would suggest you look at it in the context of the RFC. The reason is because these two are different as well. 01010011 01100101 01101101 01110000 01100101 01110010 01000110 01101001 Jeremy Duncan Joint Interoperability Test Command IPv6 Test and Evaluation ManTech Telecommunications & Information Systems Office: 703-814-8384 Cell: 520-226-1789 __________________________________________________ -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, February 25, 2008 12:07 PM To: Duncan, Richard J CTR DISA JITC; ipv6@ietf.org Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) Jeremy, >Is there also anyway the new node requirements RFC could be somewhat >reconciled with the new US Government IPv6 Profile and the DoD IPv6 >Profile? >It would probably keep the confusion down a bit. Would you be able to provide a summary of the differences? Also, are the US Government & the DoD IPv6 profiles publically available? What we could potentially do is look at resolving any major conflicts, if possible - or at least have an informative appendix covering this. Thoughts? John Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0101_01C877AA.3E6F3400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQXTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEMDCCA5mgAwIBAgIDEAu1MA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTUwHhcNMDcwOTA1MDAwMDAwWhcN MTAwOTA0MjM1OTU5WjB+MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTETMBEGA1UECxMKQ09OVFJBQ1RPUjEkMCIGA1UEAxMb RFVOQ0FOLlJJQ0hBUkQuSi4xMDQxODMyNDQwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCi R3wjZTGP27H0sUevF1gVrxL7yquOwIdEKHDewCF2Q4cktclY471UUFtbf29tsTBnTYeF3Hn6jGMN zuWI1DO9lrRq8+4vyaSU7vGWBESftsdksb5QkHvPt0Imo5OB9652BPja+sNLmDHi/GyWT3f0i2PU ak6R1FBp7KhQrwydQQIDAQABo4IB2zCCAdcwDgYDVR0PAQH/BAQDAgUgMCYGA1UdEQQfMB2BG3Jp Y2hhcmQuZHVuY2FuLmN0ckBkaXNhLm1pbDAfBgNVHSMEGDAWgBSVtYx4q51WMzz0SKOcWO2xZIqK njAdBgNVHQ4EFgQUL3IW+qwAjH7ULvWGf2cexMnagRQwFgYDVR0gBA8wDTALBglghkgBZQIBCwkw gdUGA1UdHwSBzTCByjA0oDKgMIYuaHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RE9EJTIwRU1B SUwlMjBDQS0xNTCBkaCBjqCBi4aBiGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWlsL2NuJTNkRE9EJTIw RU1BSUwlMjBDQS0xNSUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1l bnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkwbQYIKwYBBQUHAQEE YTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwl MjBDQS0xNTAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwDQYJKoZIhvcNAQEFBQAD gYEABKywcrZrLob+BG4TA58c04o0duisKZAtVDtH+w8BJkZsAIhEVDPmiQ6Nyd4c3Q8c2ioQ+3QA 22Zzu2hYg6Vao+n8ZWohF45h0nbfXygp69l0hTfI5OHqqwpOpRl3Ji8XTiGRY3oBoN43PYv0S/h4 5yo5OYh4LHr9z7743PnPMOIwggQyMIIDGqADAgECAgEbMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTA2MDYxNDE2Mzg0NVoXDTEyMDYxNDE1Mzg0 NVowXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0xNTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAtWmVn6W25J88858A1ZoVB/zWOa7Z1rxWdsAm4DuPgalpZopKK8K1SmJRXtf7 eoDjQRaaw2bz4fyEinyH/cu7yCqmvdYXc1UZl5B7RIT8v2huinVqBM5IGdOqwrkAHmRUiF875Jvw yEcVUt8rxMploMFsA69LbIPWtuk4ZRalEIMCAwEAAaOCAYEwggF9MA4GA1UdDwEB/wQEAwIBhjAf BgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQUlbWMeKudVjM89EijnFjt sWSKip4wDAYDVR0kBAUwA4ABADAPBgNVHRMBAf8EBTADAQH/MDAGA1UdIAQpMCcwCwYJYIZIAWUC AQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCwowgdkGA1UdHwSB0TCBzjA4oDagNIYyaHR0cDov L2NybC5nZHMuZGlzYS5taWwvZ2V0Y3JsP0RvRCUyMFJvb3QlMjBDQSUyMDIwgZGggY6ggYuGgYhs ZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNvdSUzZFBL SSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NlcnRpZmljYXRl cmV2b2NhdGlvbmxpc3Q7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQCK+a1cpxe8yEyZpSqfatss ieq+c/mTtqsE0/tk0KLFaoXHyB4PKxcp/acaqDnqP3ykk6u7fbQgY3l/AUYkiqipXi4yTFGG2Y/0 wl/cktLfT5MIybmgxXJceMuWB27JCwB4F7755vm1pYh+ge1Hj6iL/vqbRYIrQlv4IaVVEtYWtPPN apuG2KwzJRQOFTmRNkzA3QixuFh2PnuDYxoX2UYLnUPxztVnMxGYVMJ4USdUjSs3mwk7PUq/Byqm exT4HOMe/R3YYmeZquIPzKaGzSp9p3q9lxPkr/fxiXDtHcMnQbYIRXAwieLXog7Wad3VxELVvrLL tnbBa5kEXr6Z8PWsMIIEezCCA+SgAwIBAgIDEAuYMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTUwHhcNMDcwOTA1MDAwMDAwWhcNMTAwOTA0MjM1OTU5 WjB+MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTETMBEGA1UECxMKQ09OVFJBQ1RPUjEkMCIGA1UEAxMbRFVOQ0FOLlJJQ0hB UkQuSi4xMDQxODMyNDQwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCw68e1AqYIvIE7P/5g TzIKvNq6sk/Gcx/jlE3Zpm/ll89TYkcyiKdVnlLmz6Jv2RvRi0NGs8Tccb0CrygD4d9GAxQwE1WZ LSJQWZLuxlnAlZXyxkYXrKRjMobgcvh/5z7sS+z43YESefwi1mIYBrQnn1dhjnKvxkvmDI6KiWma sQIDAQABo4ICJjCCAiIwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFJW1jHirnVYzPPRIo5xY 7bFkioqeMB0GA1UdDgQWBBTrEr/aMUv64HSEQe4hCbNOZErWOTAWBgNVHSAEDzANMAsGCWCGSAFl AgELCTCB1QYDVR0fBIHNMIHKMDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9ET0Ql MjBFTUFJTCUyMENBLTE1MIGRoIGOoIGLhoGIbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2RE T0QlMjBFTUFJTCUyMENBLTE1JTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292 ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTApBgNVHSUE IjAgBgorBgEEAYI3FAICBggrBgEFBQcDBAYIKwYBBQUHAwIwRgYDVR0RBD8wPYEbcmljaGFyZC5k dW5jYW4uY3RyQGRpc2EubWlsoB4GCisGAQQBgjcUAgOgEAwOMTA0MTgzMjQ0MEBtaWwwbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0xNTAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwDQYJKoZIhvcN AQEFBQADgYEAtBvwm//NKC7RmEjkgCEim4FKpStL7afxw8n/M3z7nbHodrhZkzY4hytSYA5FjKFV q8uaE0lJF0ZkEX0k457Z/E2WVrlbItf0arwh+eTR9np1b5l12wv6ogSM0GvQNXtvReinfTDFtBIN rbPbz1Cc7GT6OAMGc38QjtNw1IWk7OQxggKxMIICrQIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYD VQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQD Ew9ET0QgRU1BSUwgQ0EtMTUCAxALmDAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAyMjUxNzMwNDVaMCMGCSqGSIb3DQEJBDEWBBQpF+dp +h/e/ewg35YHA5wE2C6zRDBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEE AYI3EAQxZjBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTUCAxALtTB1Bgsq hkiG9w0BCRACCzFmoGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0xNQIDEAu1 MA0GCSqGSIb3DQEBAQUABIGAbjVcEBRz//C10SUPVhSFIVLBgezFA2x/b0UTx48Ykr62L+M9Qbti nAOwBS1TjtLVmKGHpgPoGVsZt2ptCzgi+OT3+BEFxMQlI1wUXn8wGtRx9+OYt5fdmmxdW8GaJViw 3Sm+uNcE3zB8t9bSq35O9bt5ruSTWhn0EeOdFleT0wUAAAAAAAA= ------=_NextPart_000_0101_01C877AA.3E6F3400-- --===============0876954457== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0876954457==-- From ipv6-bounces@ietf.org Mon Feb 25 10:27:21 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C0828C780; Mon, 25 Feb 2008 10:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=-2.804, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_BAYES_5x8=0.8, SARE_BAYES_6x8=0.8, SARE_BAYES_7x8=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBAJpxWnzpzk; Mon, 25 Feb 2008 10:27:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F16428C709; Mon, 25 Feb 2008 10:23:38 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CBA828C37C for ; Mon, 25 Feb 2008 10:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcmXYB6WNiCR for ; Mon, 25 Feb 2008 10:23:36 -0800 (PST) Received: from mailgate-internal2.sri.com (mailgate-internal2.SRI.COM [128.18.84.104]) by core3.amsl.com (Postfix) with SMTP id 5F18828C868 for ; Mon, 25 Feb 2008 10:21:14 -0800 (PST) Received: from localhost (HELO mailgate-internal2.SRI.COM) (127.0.0.1) by mailgate-internal2.sri.com with SMTP; 25 Feb 2008 18:21:06 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal2.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2008022510210630816 for ; Mon, 25 Feb 2008 10:21:06 -0800 Received: from [192.168.2.105] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JWT00IRT4B4IFJ3@mail.sri.com> for ipv6@ietf.org; Mon, 25 Feb 2008 10:21:06 -0800 (PST) Date: Mon, 25 Feb 2008 13:21:06 -0500 From: Ed Jankiewicz Subject: Re: Updates to Node Requirements-bis (UNCLASSIFIED) In-reply-to: To: ipv6@ietf.org Message-id: <47C30712.1000103@sri.com> MIME-version: 1.0 References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> <19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Cc: john.loughney@nokia.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I recently took a pass through both the USG and DoD documents to identify differences. I am also planning to compare the DoD doc against this draft. I will gladly share those comparisons with this list, and hope to have it done this week, certainly before the IETF meeting in two weeks. Duncan, Richard J CTR DISA JITC wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > John- > > I can give you the 2 documents: > > DoD IPv6 Standards Profile, Version 2: > http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_product_profile_v2.pdf > > US Government IPv6 Profile Version 1, Draft 2: > http://www.antd.nist.gov/usgv6/usgv6-v1-draft2.pdf > > I would suggest you look at it in the context of the RFC. The reason is > because these two are different as well. > > > 01010011 01100101 01101101 01110000 01100101 01110010 01000110 01101001 > > Jeremy Duncan > > Joint Interoperability Test Command > IPv6 Test and Evaluation > ManTech Telecommunications & Information Systems > Office: 703-814-8384 > Cell: 520-226-1789 > __________________________________________________ > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, February 25, 2008 12:07 PM > To: Duncan, Richard J CTR DISA JITC; ipv6@ietf.org > Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) > > Jeremy, > > >> Is there also anyway the new node requirements RFC could be somewhat >> reconciled with the new US Government IPv6 Profile and the DoD IPv6 >> Profile? >> It would probably keep the confusion down a bit. >> > > Would you be able to provide a summary of the differences? Also, are the US > Government & the DoD IPv6 profiles publically available? > > What we could potentially do is look at resolving any major conflicts, if > possible - or at least have an informative appendix covering this. > > Thoughts? > John > Classification: UNCLASSIFIED > Caveats: NONE > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 10:38:09 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C513A6D34; Mon, 25 Feb 2008 10:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.475 X-Spam-Level: X-Spam-Status: No, score=0.475 tagged_above=-999 required=5 tests=[AWL=-1.688, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_BAYES_5x8=0.8, SARE_BAYES_6x8=0.8, SARE_BAYES_7x8=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhAYG94fGcWa; Mon, 25 Feb 2008 10:38:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F297728C80D; Mon, 25 Feb 2008 10:27:49 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BD828C7CA for ; Mon, 25 Feb 2008 10:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjj3Y4J5SOiU for ; Mon, 25 Feb 2008 10:27:48 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4EB4C28C9EE for ; Mon, 25 Feb 2008 10:26:09 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1PIPXpn024674; Mon, 25 Feb 2008 20:25:41 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 20:25:08 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 12:24:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) Date: Mon, 25 Feb 2008 12:23:55 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A010C3FA7@daebe104.NOE.Nokia.com> In-Reply-To: <47C30712.1000103@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis (UNCLASSIFIED) Thread-Index: Ach32zeYSohaSc7hSk2ZWycpW+NyywAAEhGA References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> <19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> <47C30712.1000103@sri.com> From: To: , X-OriginalArrivalTime: 25 Feb 2008 18:24:54.0956 (UTC) FILETIME=[B80E7EC0:01C877DB] X-Nokia-AV: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Ed, That would be great. If the comparison is useful, we can then include it as an appendix or at least discuss some of the differences. thanks, John >-----Original Message----- >From: ext Ed Jankiewicz [mailto:edward.jankiewicz@sri.com] >Sent: 25 February, 2008 10:21 >To: ipv6@ietf.org >Cc: Duncan, Richard J CTR DISA JITC; Loughney John >(Nokia-OCTO/PaloAlto) >Subject: Re: Updates to Node Requirements-bis (UNCLASSIFIED) > >I recently took a pass through both the USG and DoD documents >to identify differences. I am also planning to compare the >DoD doc against this draft. I will gladly share those >comparisons with this list, and hope to have it done this >week, certainly before the IETF meeting in two weeks. > >Duncan, Richard J CTR DISA JITC wrote: >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> John- >> >> I can give you the 2 documents: >> >> DoD IPv6 Standards Profile, Version 2: >> >http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_product_profile_v2.pdf >> >> US Government IPv6 Profile Version 1, Draft 2: >> http://www.antd.nist.gov/usgv6/usgv6-v1-draft2.pdf >> >> I would suggest you look at it in the context of the RFC. >The reason >> is because these two are different as well. >> >> >> 01010011 01100101 01101101 01110000 01100101 01110010 01000110 >> 01101001 >> >> Jeremy Duncan >> >> Joint Interoperability Test Command >> IPv6 Test and Evaluation >> ManTech Telecommunications & Information Systems >> Office: 703-814-8384 >> Cell: 520-226-1789 >> __________________________________________________ >> >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: Monday, February 25, 2008 12:07 PM >> To: Duncan, Richard J CTR DISA JITC; ipv6@ietf.org >> Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) >> >> Jeremy, >> >> >>> Is there also anyway the new node requirements RFC could be >somewhat >>> reconciled with the new US Government IPv6 Profile and the DoD IPv6 >>> Profile? >>> It would probably keep the confusion down a bit. >>> >> >> Would you be able to provide a summary of the differences? Also, are >> the US Government & the DoD IPv6 profiles publically available? >> >> What we could potentially do is look at resolving any major >conflicts, >> if possible - or at least have an informative appendix covering this. >> >> Thoughts? >> John >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> >> >---------------------------------------------------------------------- >> -- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > >-- >Ed Jankiewicz - SRI International >Fort Monmouth Branch Office - IPv6 Research Supporting DISA >Standards Engineering Branch >732-389-1003 or ed.jankiewicz@sri.com > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 12:52:01 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE73928C7DB; Mon, 25 Feb 2008 12:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaEcX8xo0Z6X; Mon, 25 Feb 2008 12:51:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49AB528C7D0; Mon, 25 Feb 2008 12:40:31 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A073A6D68 for ; Mon, 25 Feb 2008 12:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ycQbdB3hUv3 for ; Mon, 25 Feb 2008 12:40:29 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 488373A6F32 for ; Mon, 25 Feb 2008 12:34:21 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2008 15:34:15 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1PKYF0g025365; Mon, 25 Feb 2008 15:34:15 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1PKXuJt011680; Mon, 25 Feb 2008 20:34:15 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 15:34:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: New Version Notification for draft-wbeebee-on-link-and-off-link-determination-02 Date: Mon, 25 Feb 2008 15:34:13 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-wbeebee-on-link-and-off-link-determination-02 Thread-Index: Ach34fgHonT+f/b1Rvm4HLyWuO35bAAClmHQ From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 25 Feb 2008 20:34:13.0822 (UTC) FILETIME=[C8B37DE0:01C877ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1637; t=1203971655; x=1204835655; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20=2 0=20=20=20=20=20=20=20=20draft-wbeebee-on-link-and-off-link- determination-02=20 |Sender:=20 |To:=20; bh=Gm2lstAIEpG2a1VqjOzF/7ZmPE0hqZ3gdjVitpVxs24=; b=qzj8NBJ1LkNUlHdNQPuXG7H6Up54Z/fTvx1CQBesVHV130G64n38ff9yep Ct1Jfd7H3gD0KHK6sY6Bu5Qx9I4BiUKnfhEowEPzCo4LHOvPwJ7krb74mDCV 17Gwb3yFtM; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Folks, We have recast our draft into an "IPv6 Subnet Model" draft. After discussing with Thomas Narten and Erik Nordmark it was felt that the IPv6 subnet model is really not explained anywhere in any existing IPv6 document. That is why we recast our draft and also welcomed Erik as a co-author to our draft - please see the text of the new Abstract below. The new version has a lot of sections removed from the old draft. A very short new version now exists for review. http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d etermination-02.txt Thanks. Hemant, Wes, and Erik. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, February 25, 2008 1:59 PM To: Hemant Singh (shemant) Cc: Wes Beebee (wbeebee); erik.nordmark@sun.com Subject: New Version Notification for draft-wbeebee-on-link-and-off-link-determination-02 A new version of I-D, draft-wbeebee-on-link-and-off-link-determination-02.txt has been successfuly submitted by Hemant Singh and posted to the IETF repository. Filename: draft-wbeebee-on-link-and-off-link-determination Revision: 02 Title: IPv6 Subnet Model Creation_date: 2008-02-25 WG ID: Independent Submission Number_of_pages: 9 Abstract: IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has turned out to cause interoperability problems. This note spells out the most important difference; that an IPv6 address isn't automatically associated with an IPv6 on-link subnet prefix. The IETF Secretariat. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 13:56:12 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EBA28CC44; Mon, 25 Feb 2008 13:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LA5gc+c95hrE; Mon, 25 Feb 2008 13:56:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E894B28C6CF; Mon, 25 Feb 2008 13:34:19 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048E528C6CB for ; Mon, 25 Feb 2008 13:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX6k+GoCTUNQ for ; Mon, 25 Feb 2008 13:34:17 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 3DD5B28C763 for ; Mon, 25 Feb 2008 13:25:42 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m1PLPIpJ016361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Feb 2008 15:25:24 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m1PLPIsI007835; Mon, 25 Feb 2008 13:25:18 -0800 (PST) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m1PLPBQ3007561; Mon, 25 Feb 2008 13:25:18 -0800 (PST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 16:24:49 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) Date: Mon, 25 Feb 2008 16:24:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis (UNCLASSIFIED) Thread-Index: Ach3amr9x4XfbXfOQt2P9TiB9jK8eQAYaHOgAAEEGPAAABy2IAAAwSXgAAdsPoA= References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> From: "Manfredi, Albert E" To: "Duncan, Richard J CTR DISA JITC" , , X-OriginalArrivalTime: 25 Feb 2008 21:24:49.0366 (UTC) FILETIME=[DA06BF60:01C877F4] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Duncan, Richard J CTR DISA JITC > John- > > I can give you the 2 documents: > > DoD IPv6 Standards Profile, Version 2: > http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_product_profile_v2.pdf > > US Government IPv6 Profile Version 1, Draft 2: > http://www.antd.nist.gov/usgv6/usgv6-v1-draft2.pdf > > I would suggest you look at it in the context of the RFC. > The reason is > because these two are different as well. I would agree that someone should reconcile, or at least identify, all the differences, although I don't know that it should be the IETF. I would expect that the rationale for the differences does not lie within the IETF? One difference between RFC 4294 and I-D 4294-bis is that AH was demoted from a MUST to a MAY. Is a specific reference identitied, and I just missed it maybe? I noticed that the latest NIST IPv6 Profile accommodates this change. One MUST that the NIST IPv6 Profile introduced was mandating of OSPFv3 as the routing protocol. Is this because RIPng is not beiong adopted in practice? Small networks should do well with RIPng, I would think, unless RIPng is never used in practice. And in principle, there could be a case made for static routing tables in special cases. I'm not sure why the routing protocol mandate for all Government nets. Same applies to IKEv2. The IETF does not mandate its use, while NIST does. One detail I'm not clear on is whether or why routers, which may well be in non-secure spaces, are required to support ESP. I-D 4294-bis doesn't elaborate - it just says "nodes" must. Older versions of the NIST IPv6 Profile said that routers had to support AH to protect the routing protocols. My assumption is that this rationale, protection of routing protocols, is why now NIST is mandating that routers support ESP, now that AH has been demoted to a MAY. A brief clarification would be welcome. Another mandate in the NIST IPv6 Profile is that both tunneling and dual stack mechanisms be supported in Government networks. But what about small networks that already support dual stacks? They should have no reason to use tunneling as a mechanism for IPv6 transition? Those are some of the issues I saw. I'm sure there are many I didn't focus on. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 16:49:19 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89CD3A6D60; Mon, 25 Feb 2008 16:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmAgECtn-AHH; Mon, 25 Feb 2008 16:49:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F6F28C37C; Mon, 25 Feb 2008 16:27:50 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B013C28C356 for ; Mon, 25 Feb 2008 16:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7U5X4GBtvaw for ; Mon, 25 Feb 2008 16:27:48 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 6ECF328C47F for ; Mon, 25 Feb 2008 16:20:47 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k40so3034201wah.25 for ; Mon, 25 Feb 2008 16:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=UvYs98mnLYDsEtc+Nn6OGmbWFMQGaeTJ0gXgj8Qcydc=; b=UV6Av0bTpq8miQ7F3Xz0or29LLyQvsE0/lL3rpsCtnCIfXC2AEjh3hwosRaaf2R6wk/8pa47I+/pNMZ7LJOHaDWCsYmSyIedcACmzYaIFVa/ebGyUqvJ61ZzZ1EtAFY/8B9i2/czBKLUPXj9Iil44WHk7RE0biS2uVh0NLnpY4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FW7sESQv8N1IKckY1EAA53+uI8/DCaZErBRFnu8nNBnl6aPkMnBHk/HK3mKaKpdKrZDQrvJ2ThPL/P3LB8uyldfAOu+X5720KJvhXcX50aRDcsnpCJrRR69ij/wVoGcpD1JWqWGgops/jXWAfF5YyAX0Q9IOaiMtaGENs+hoijA= Received: by 10.115.92.2 with SMTP id u2mr4496993wal.139.1203985240944; Mon, 25 Feb 2008 16:20:40 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m40sm10593375wag.0.2008.02.25.16.20.39 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Feb 2008 16:20:40 -0800 (PST) Message-ID: <47C35B55.7040709@gmail.com> Date: Tue, 26 Feb 2008 13:20:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: Updates to Node Requirements-bis References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> In-Reply-To: Cc: john.loughney@nokia.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2008-02-26 10:24, Manfredi, Albert E wrote: >> -----Original Message----- >> From: Duncan, Richard J CTR DISA JITC > >> John- >> >> I can give you the 2 documents: >> >> DoD IPv6 Standards Profile, Version 2: >> http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_product_profile_v2.pdf >> >> US Government IPv6 Profile Version 1, Draft 2: >> http://www.antd.nist.gov/usgv6/usgv6-v1-draft2.pdf >> >> I would suggest you look at it in the context of the RFC. >> The reason is >> because these two are different as well. > > I would agree that someone should reconcile, or at least identify, all > the differences, although I don't know that it should be the IETF. I > would expect that the rationale for the differences does not lie within > the IETF? The IETF's job is to make the Internet work better (RFC 3935) so we obviously have to give that priority. It would certainly be useful to understand why the DISA and NIST profiles differ from the IETF's profile, but aligning with DISA and NIST shouldn't be a goal in itself as far as I can see. > > One difference between RFC 4294 and I-D 4294-bis is that AH was demoted > from a MUST to a MAY. Is a specific reference identitied, and I just > missed it maybe? I noticed that the latest NIST IPv6 Profile > accommodates this change. As does IPsec (RFC 4301 section 3.2 first paragraph). > > One MUST that the NIST IPv6 Profile introduced was mandating of OSPFv3 > as the routing protocol. Is this because RIPng is not beiong adopted in > practice? Small networks should do well with RIPng, I would think, > unless RIPng is never used in practice. And in principle, there could be > a case made for static routing tables in special cases. I'm not sure why > the routing protocol mandate for all Government nets. > > Same applies to IKEv2. The IETF does not mandate its use, while NIST > does. See RFC 4301 section 3.2 *last* paragraph. The problem is that the real world is slow to move to IKEv2. It's important to describe what's real, I think. The NIST requirement is "interesting" given the state of products. > > One detail I'm not clear on is whether or why routers, which may well be > in non-secure spaces, are required to support ESP. I-D 4294-bis doesn't > elaborate - it just says "nodes" must. Older versions of the NIST IPv6 > Profile said that routers had to support AH to protect the routing > protocols. My assumption is that this rationale, protection of routing > protocols, is why now NIST is mandating that routers support ESP, now > that AH has been demoted to a MAY. A brief clarification would be > welcome. Would you want to ship a router that couldn't protect the network layer? > Another mandate in the NIST IPv6 Profile is that both tunneling and dual > stack mechanisms be supported in Government networks. But what about > small networks that already support dual stacks? They should have no > reason to use tunneling as a mechanism for IPv6 transition? That's an operational issue, not a node requirement. Would you want to ship a stack that could support a dual stack but not use it to tunnel? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 17:47:23 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3EB28CB9F; Mon, 25 Feb 2008 17:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=-1.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUgfsUIvwaRW; Mon, 25 Feb 2008 17:47:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2F03A6EAA; Mon, 25 Feb 2008 17:38:23 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A885D3A6EA6 for ; Mon, 25 Feb 2008 17:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-wzULGQKWqn for ; Mon, 25 Feb 2008 17:38:21 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id F107528C48F for ; Mon, 25 Feb 2008 17:30:08 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m1Q1U009014193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Feb 2008 17:30:00 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m1Q1U0Gu024857; Mon, 25 Feb 2008 17:30:00 -0800 (PST) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m1Q1U00B024802; Mon, 25 Feb 2008 17:30:00 -0800 (PST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 20:29:59 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Updates to Node Requirements-bis Date: Mon, 25 Feb 2008 20:29:59 -0500 Message-ID: In-Reply-To: <47C35B55.7040709@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis Thread-Index: Ach4DW2HKh0ui8lPSg+r5UITz4iNnAABIRyQ References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> <47C35B55.7040709@gmail.com> From: "Manfredi, Albert E" To: "Brian E Carpenter" X-OriginalArrivalTime: 26 Feb 2008 01:29:59.0461 (UTC) FILETIME=[19ED1D50:01C87817] Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > To: Manfredi, Albert E > > I would agree that someone should reconcile, or at least > > identify, all > > the differences, although I don't know that it should be the IETF. > The IETF's job is to make the Internet work better (RFC 3935) so we > obviously have to give that priority. It would certainly be useful > to understand why the DISA and NIST profiles differ from the IETF's > profile, but aligning with DISA and NIST shouldn't be a goal in itself > as far as I can see. Typically, the NIST requirements seem more stringent. My only point is that if any explanation for differences is deemed desirable, I would expect that DISA or NIST be the ones who explain why these differences were introduced. I think we agree. The IETF can only guess at reasons. > > Same applies to IKEv2. The IETF does not mandate its use, while NIST > > does. > > See RFC 4301 section 3.2 *last* paragraph. The problem is that > the real world is slow to move to IKEv2. It's important to describe > what's real, I think. The NIST requirement is "interesting" given > the state of products. I-D 4294-bis says in Section 9.4: An implementation MUST support the manual configuration of the security key and SPI. The SPI configuration is needed in order to delineate between multiple keys. Key management SHOULD be supported. Examples of key management systems include IKEv2 [RFC4306] and Kerberos; S/MIME and TLS include key management functions. Where key refresh, anti-replay features of AH and ESP, or on-demand creation of Security Associations (SAs) is required, automated keying MUST be supported. So automatic key exchange is not considered mandatory by the IETF in all cases, but it is mandatory in the NIST Profile. At least, that's how I read that. > > My assumption is that this rationale, protection > > of routing > > protocols, is why now NIST is mandating that routers > > support ESP, now > > that AH has been demoted to a MAY. A brief clarification would be > > welcome. > > Would you want to ship a router that couldn't protect the > network layer? Depends what you mean. A router located in a non-secure space can be expected to protect the way it populates its routing tables. That's about it, though. AH seemed a good way to do that, but ESP, for the purpose of protecting RIPng or OSPFv3 messages, should be fine too, I think. Expecting more than that seems like wishful thinking, IF the routers are in non-secure spaces. Encypting spoofed messages coming from non-secure hosts does not make these any more secure. What would make these more secure is ESP host-to-host, or ESP tunneled between security gateways. > > Another mandate in the NIST IPv6 Profile is that both > > tunneling and dual > > stack mechanisms be supported in Government networks. > That's an operational issue, not a node requirement. Would you want > to ship a stack that could support a dual stack but not use it > to tunnel? Yes. If I provide a special-purpose network that provides dual-stack, why should I have the added burden of supporting tunneling that I will never use? My preferred approach is to not require features that won't be used, but allow them to be added if necessary, in the future. This saves development time and testing efforts. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 18:31:18 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F1B3A6A10; Mon, 25 Feb 2008 18:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtBdq1edPFnk; Mon, 25 Feb 2008 18:31:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1873A6811; Mon, 25 Feb 2008 18:31:04 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FA63A6820 for ; Mon, 25 Feb 2008 18:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBrJnSNhkE9G for ; Mon, 25 Feb 2008 18:31:02 -0800 (PST) Received: from 122x218x96x122.ap122.ftth.ucom.ne.jp (unknown [IPv6:2002:7ada:607a:0:8102:7ada:607a:0]) by core3.amsl.com (Postfix) with ESMTP id AD4D53A67FF for ; Mon, 25 Feb 2008 18:31:01 -0800 (PST) Received: from coin (localhost [127.0.0.1]) by 122x218x96x122.ap122.ftth.ucom.ne.jp (Postfix) with ESMTP id 8F7826BADB for ; Tue, 26 Feb 2008 11:30:52 +0900 (JST) Received: from coin.bbtec.net (localhost [127.0.0.1]) by coin (Postfix) with ESMTP id 068486C7E9 for ; Tue, 26 Feb 2008 11:30:52 +0900 (JST) Date: Tue, 26 Feb 2008 11:30:52 +0900 Message-ID: From: FUJIKAWA Kenji To: ipv6@ietf.org Subject: Use longest-matching prefix to the next hop User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.7 Emacs/22.1 (i386--netbsdelf) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, I am submitting an ID, http://www.ietf.org/proceedings/staging/draft-fujikawa-ipv6-src-addr-selection-02.txt and suggesting in the draft that, Before Rule 8 (Use longest matching prefix) in section 5. (Source Address Selection) in RFC3484, the rule using longest-matching prefix to the next hop is to be added. The following is an example, where the Rule 8 selects the roundabout path via ISP3, while the method of using longest-matching prefix to the next hop selects the shortest and best path, when EN sends a packet to CN. # In the previous IETF meeting I only showed a single router case. # but this method is adaptable and useful to the multiple router case. I would like to ask if 6man people is interested in this topic, and this can become working group item. +---+ |CN | +-+-+ | 2001:db8:2001::CN | +---+---+2001:db8:2000:/36 | | +---------+ ISP2 | | | | | +-------+ | +---+---+2001:db8:1000:/36 +-------+2001:db8:3000::/36 | | | | | ISP1 +-------------------+ ISP3 | | | | | +---+---+ +---+---+ | | | | +----------+ +--------+ 2001:db8:1000:R1| |2001:db8:3000:R3 +-+-+ +-+-+ 2001:db8:1001::/48|R1 | |R3 |2001:db8:3001::/48 +-+-+ +-+-+ 2001:db8:1001:1:R1| |2001:db8:3001:1:R3 | | --+---+---+-- 2001:db8:1001:1:EN | 2001:db8:3001:1:EN +-+-+ |EN | +---+ Routing Tables: R1: Destination Next Hop 2001:db8:1000::/36 address_of_ISP1's_router 2001:db8:2000::/36 address_of_ISP1's_router R3: 2001:db8:3000::/36 address_of_ISP3's_router EN: Destination Next Hop 2001:db8:1000::/36 2001:db8:1001:1:R1 2001:db8:2000::/36 2001:db8:1001:1:R1 2001:db8:3000::/36 2001:db8:3001:1:R3 Any questions and comments are welcome. Regards, ------------------------------------------------------------------ FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan Mail: fujikawa@root-hq.com, hudikaha@gmail.com WWW: http://www23.atwiki.jp/hudikaha/ Skype: fujikawakenji -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 20:29:00 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5528928C33F; Mon, 25 Feb 2008 20:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96V5z35FIL9P; Mon, 25 Feb 2008 20:28:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B9F3A697E; Mon, 25 Feb 2008 20:28:58 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58223A697E for ; Mon, 25 Feb 2008 20:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rfUxF6zTpLO for ; Mon, 25 Feb 2008 20:28:55 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id AE0793A67FC for ; Mon, 25 Feb 2008 20:28:55 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1Q4Sm7V027531 for ; Mon, 25 Feb 2008 23:28:48 -0500 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1Q4SmVq027527; Mon, 25 Feb 2008 23:28:48 -0500 Received: from IMCSRV7.MITRE.ORG ([129.83.20.57]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 23:28:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Updates to Node Requirements-bis Date: Mon, 25 Feb 2008 23:27:57 -0500 Message-ID: <0AC4B700F00DBB4C94F95727E0991414D83E88@IMCSRV7.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis thread-index: Ach4DW2HKh0ui8lPSg+r5UITz4iNnAABIRyQAAXdnWA= References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> <47C35B55.7040709@gmail.com> From: "Dunn, Jeffrey H." To: "Manfredi, Albert E" , "Brian E Carpenter" X-OriginalArrivalTime: 26 Feb 2008 04:28:48.0305 (UTC) FILETIME=[14D0CA10:01C87830] Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Colleagues, Although I do not speak for either DISA or NIST, I believe that the spirit of Jeremy's request was that the specifications (RFCs) required by the DISA and NIST documents be considered for inclusion in the updated node requirements document. I am working on he deltas between the NIST draft 1 and 2, and the DISR. Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Manfredi, Albert E Sent: Monday, February 25, 2008 8:30 PM To: Brian E Carpenter Cc: ipv6@ietf.org Subject: RE: Updates to Node Requirements-bis > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > To: Manfredi, Albert E > > I would agree that someone should reconcile, or at least > > identify, all > > the differences, although I don't know that it should be the IETF. > The IETF's job is to make the Internet work better (RFC 3935) so we > obviously have to give that priority. It would certainly be useful > to understand why the DISA and NIST profiles differ from the IETF's > profile, but aligning with DISA and NIST shouldn't be a goal in itself > as far as I can see. Typically, the NIST requirements seem more stringent. My only point is that if any explanation for differences is deemed desirable, I would expect that DISA or NIST be the ones who explain why these differences were introduced. I think we agree. The IETF can only guess at reasons. > > Same applies to IKEv2. The IETF does not mandate its use, while NIST > > does. > > See RFC 4301 section 3.2 *last* paragraph. The problem is that > the real world is slow to move to IKEv2. It's important to describe > what's real, I think. The NIST requirement is "interesting" given > the state of products. I-D 4294-bis says in Section 9.4: An implementation MUST support the manual configuration of the security key and SPI. The SPI configuration is needed in order to delineate between multiple keys. Key management SHOULD be supported. Examples of key management systems include IKEv2 [RFC4306] and Kerberos; S/MIME and TLS include key management functions. Where key refresh, anti-replay features of AH and ESP, or on-demand creation of Security Associations (SAs) is required, automated keying MUST be supported. So automatic key exchange is not considered mandatory by the IETF in all cases, but it is mandatory in the NIST Profile. At least, that's how I read that. > > My assumption is that this rationale, protection > > of routing > > protocols, is why now NIST is mandating that routers > > support ESP, now > > that AH has been demoted to a MAY. A brief clarification would be > > welcome. > > Would you want to ship a router that couldn't protect the > network layer? Depends what you mean. A router located in a non-secure space can be expected to protect the way it populates its routing tables. That's about it, though. AH seemed a good way to do that, but ESP, for the purpose of protecting RIPng or OSPFv3 messages, should be fine too, I think. Expecting more than that seems like wishful thinking, IF the routers are in non-secure spaces. Encypting spoofed messages coming from non-secure hosts does not make these any more secure. What would make these more secure is ESP host-to-host, or ESP tunneled between security gateways. > > Another mandate in the NIST IPv6 Profile is that both > > tunneling and dual > > stack mechanisms be supported in Government networks. > That's an operational issue, not a node requirement. Would you want > to ship a stack that could support a dual stack but not use it > to tunnel? Yes. If I provide a special-purpose network that provides dual-stack, why should I have the added burden of supporting tunneling that I will never use? My preferred approach is to not require features that won't be used, but allow them to be added if necessary, in the future. This saves development time and testing efforts. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 20:45:43 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D9928C517; Mon, 25 Feb 2008 20:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=-1.958, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj6zlmNbdPMs; Mon, 25 Feb 2008 20:45:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A409128C47A; Mon, 25 Feb 2008 20:45:42 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8913028C464 for ; Mon, 25 Feb 2008 20:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUw108TqzJAQ for ; Mon, 25 Feb 2008 20:45:40 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 62A5528C40B for ; Mon, 25 Feb 2008 20:45:40 -0800 (PST) Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 26 Feb 2008 10:15:33 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1Q4jWd5011361; Tue, 26 Feb 2008 12:45:32 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1Q4jPRq016582; Tue, 26 Feb 2008 04:45:26 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 12:45:25 +0800 Received: from [192.168.101.34] ([10.75.234.55]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 12:45:24 +0800 In-Reply-To: References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <8FADFC92-6969-4BA0-8FD7-28655F8BC623@cisco.com> From: Fred Baker Subject: Re: Updates to Node Requirements-bis (UNCLASSIFIED) Date: Tue, 26 Feb 2008 12:45:15 +0800 To: "Manfredi, Albert E" X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 26 Feb 2008 04:45:24.0911 (UTC) FILETIME=[66D6CBF0:01C87832] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=937; t=1204001132; x=1204865132; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Updates=20to=20Node=20Requirements-bis= 20(UNCLASSIFIED) |Sender:=20; bh=7BkOPnBfZ7eCjVtyG4HRP7b6N7PVvYn5iQklso1DxkY=; b=XX8P5k1B0Mbm+/lUwUxeasn8eo2hHKthY5yJXx55dp+bCFr7AH2GxlDf2h XojhXFdIA/bmzWYFjB4hJnu8ldMqhF8dZGOAf0C68wO9s2vF1TyFYyUI7jmR 90eUT6Ttda/ZDg0gO0L3gmvebJXFA/1n0fTX+FK4lLRhs6Z+pbb4M=; Authentication-Results: hkg-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Cc: john.loughney@nokia.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 26, 2008, at 5:24 AM, Manfredi, Albert E wrote: > One detail I'm not clear on is whether or why routers, which may > well be in non-secure spaces, are required to support ESP. I-D 4294- > bis doesn't elaborate - it just says "nodes" must. The question, at least in my mind, isn't whether they always have to use it, but whether sometimes it is appropriate to use. If it is sometimes appropriate, then it has to be implemented and supported whether or not it is configured. Operationally, I think that SSH/SSL is the mechanism most people use to secure network management, which raises a question as to the real need for IPsec in the router. That is a discussion that should be had with the operational community. -----BEGIN PGP SIGNATURE----- iD8DBQFHw5lbbjEdbHIsm0MRAvkQAJ9P5GadUuq6B2jw/bU7U7lZUcnPfwCgnQRk Kp3PRdrqjVfRP0vvhK8RVP0= =fVnR -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 20:50:03 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A188228C47A; Mon, 25 Feb 2008 20:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tA37ibFmpHQo; Mon, 25 Feb 2008 20:50:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A844A3A6805; Mon, 25 Feb 2008 20:50:02 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FEFF3A6805 for ; Mon, 25 Feb 2008 20:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzGHxPjK6TEC for ; Mon, 25 Feb 2008 20:50:00 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id C91CB3A67D2 for ; Mon, 25 Feb 2008 20:49:59 -0800 (PST) Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 26 Feb 2008 10:19:53 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1Q4npv7012131; Tue, 26 Feb 2008 12:49:51 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1Q4npRk017475; Tue, 26 Feb 2008 04:49:51 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 12:49:51 +0800 Received: from [192.168.101.34] ([10.75.234.55]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 12:49:50 +0800 In-Reply-To: References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <4B11770E-DE43-46AD-97F2-CB91C2299EB0@cisco.com> From: Fred Baker Subject: Re: Updates to Node Requirements-bis (UNCLASSIFIED) Date: Tue, 26 Feb 2008 12:49:51 +0800 To: "Duncan, Richard J CTR DISA JITC" X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 26 Feb 2008 04:49:50.0904 (UTC) FILETIME=[05621B80:01C87833] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1252; t=1204001391; x=1204865391; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Updates=20to=20Node=20Requirements-bis= 20(UNCLASSIFIED) |Sender:=20; bh=BSkGVN/6FiGSr4ZGYahajYVGtJBhj1+ACdiuHMImytY=; b=WsjNEPD4u2GCLfZeTjm/Ap9mXoqcLaye0sSajq1eKHQ8LynHmx7hXFqXIj HlxNBGndQjgYNCPvXQd5+cVgvz98ELGzQJpsNzaPGAQ09Nlb22H0tkTLgkct JrZkji3oAU8BC5t2BIUbiyQSTPEwA8+1xUbpmbjGTHEmVkd41qpjo=; Authentication-Results: hkg-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Cc: john.loughney@nokia.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 26, 2008, at 1:03 AM, Duncan, Richard J CTR DISA JITC wrote: > Is there also anyway the new node requirements RFC could be > somewhat reconciled with the new US Government IPv6 Profile and the > DoD IPv6 Profile? I find myself of two minds here. From one perspective, is there a desire that the two be identical? If so, is there any chance that the authors of those profiles could talk with the IETF about their lines of reasoning? My sense is that the profiles are just that - that whatever the IETF may have thought on a topic, that NIST and DoD have each chosen to think differently, and that a vendor looking at the issues needs to review each of the relevant sets of requirements. From the other perspective, whether or not the two are identical, there are obviously different lines of reasoning here, and the IETF (gasp) might be incorrect on one point or another. Which brings me back to - is there any chance that not only the differences could be summarized, but the reasoning behind the differences? -----BEGIN PGP SIGNATURE----- iD8DBQFHw5pvbjEdbHIsm0MRAvNhAJ0frCOhEJPDxMiiz6ULX6125oknrwCaAke5 GB9zD6i4UmWfIbHDVuAyO+Q= =3PyU -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 21:42:53 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5CE28C39E; Mon, 25 Feb 2008 21:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.628 X-Spam-Level: * X-Spam-Status: No, score=1.628 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x7OZeJUjTt2; Mon, 25 Feb 2008 21:42:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA4128C120; Mon, 25 Feb 2008 21:42:51 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6003A67D0 for ; Mon, 25 Feb 2008 21:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6eu8SCTMDvT for ; Mon, 25 Feb 2008 21:42:49 -0800 (PST) Received: from pacdcimo02.cable.comcast.com (PacdcIMO02.cable.comcast.com [24.40.8.146]) by core3.amsl.com (Postfix) with ESMTP id 781B428C120 for ; Mon, 25 Feb 2008 21:42:06 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.17198848; Tue, 26 Feb 2008 00:41:39 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 00:41:39 -0500 Received: from 169.223.13.205 ([169.223.13.205]) by PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Feb 2008 05:41:39 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Tue, 26 Feb 2008 13:41:37 +0800 Subject: Making IPsec *not* mandatory in Node Requirement ( was Re: Updates to Node Requirements-bis (UNCLASSIFIED)) From: Alain Durand To: Fred Baker , Message-ID: Thread-Topic: Making IPsec *not* mandatory in Node Requirement ( was Re: Updates to Node Requirements-bis (UNCLASSIFIED)) Thread-Index: Ach4M0FrBBfbm4HnRsOuIyUC4UvFOgABv9Vs In-Reply-To: <4B11770E-DE43-46AD-97F2-CB91C2299EB0@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 26 Feb 2008 05:41:39.0560 (UTC) FILETIME=[42495E80:01C8783A] Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The latest draft: draft-ietf-6man-node-req-bis-00.txt still lists IPsec as mandatory to implement. As I mentioned last IETF meeting, this is creating a problem for certain kind of devices, like cable modems, who have a very limited memory footprint. Those devices operate in an environment where IPsec is not used and mandating its implementation has a serious cost: it means that legacy devices cannot be upgraded to IPv6... In DOCSIS 3.0, the decision was to NOT require IPsec implementation on those devices. I'm sure other environment have made or will make similar choices. Moreover, to make the point more general, we are specifying/buying many other types of devices where we know that IPsec will never be used. Why should the vendor of those devices have to implement it? Because one day I might decide to deploy it? IMHO, this is not a good think, because in the meantime, I will have to run extra code which means extra bugs, more memory and more risks of miss-configuration. I would like to suggest that the node requirements remove any mention of IPsec being mandatory to implement and instead includes text in the line of: "if you are going to implement IPsec, here is what you should/must do". - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 22:01:21 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0790828C2E7; Mon, 25 Feb 2008 22:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGA6OLu23Iem; Mon, 25 Feb 2008 22:01:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218783A6B0C; Mon, 25 Feb 2008 22:01:20 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C753A67D2 for ; Mon, 25 Feb 2008 22:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hww8NCUr44im for ; Mon, 25 Feb 2008 22:01:18 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 943C728C1B9 for ; Mon, 25 Feb 2008 22:01:17 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m1Q60x7Z009354; Tue, 26 Feb 2008 08:01:00 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m1Q60vYh009351; Tue, 26 Feb 2008 08:00:59 +0200 Date: Tue, 26 Feb 2008 08:00:57 +0200 (EET) From: Pekka Savola To: "Manfredi, Albert E" Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) In-Reply-To: Message-ID: References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92.1/5996/Tue Feb 26 01:26:09 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: john.loughney@nokia.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Mon, 25 Feb 2008, Manfredi, Albert E wrote: > One MUST that the NIST IPv6 Profile introduced was mandating of OSPFv3 > as the routing protocol. Is this because RIPng is not beiong adopted in > practice? Small networks should do well with RIPng, I would think, > unless RIPng is never used in practice. And in principle, there could be > a case made for static routing tables in special cases. I'm not sure why > the routing protocol mandate for all Government nets. IS-IS is currently probably more widely used for IPv6 routing than OSPFv3. Given that there are multiple good options that any reasonable network could deploy, I don't see why the IETF should make a recommendation in this space. NIST's goal was probably, "some implementations on the field just support static and maybe RIPng. We want to mandate something more scalable, and OSPFv3 is as good an option as any". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Feb 25 23:54:05 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC0628C24C; Mon, 25 Feb 2008 23:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCrsVTzdtYgp; Mon, 25 Feb 2008 23:54:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2754F3A68B1; Mon, 25 Feb 2008 23:54:04 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29603A692D for ; Mon, 25 Feb 2008 23:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td0tIzovMMrt for ; Mon, 25 Feb 2008 23:54:01 -0800 (PST) Received: from tomato.taca.jp (tomato.taca.jp [202.214.123.64]) by core3.amsl.com (Postfix) with ESMTP id 41DAE3A68D9 for ; Mon, 25 Feb 2008 23:53:58 -0800 (PST) Received: from localhost (unknown [202.214.123.64]) by tomato.taca.jp (Postfix) with ESMTP id 3DB4633CCC; Tue, 26 Feb 2008 16:53:42 +0900 (JST) Date: Tue, 26 Feb 2008 16:53:31 +0900 (JST) Message-Id: <20080226.165331.14652621.nov@tahi.org> To: alain_durand@cable.comcast.com Subject: Re: Making IPsec *not* mandatory in Node Requirement From: Nobuo OKABE In-Reply-To: References: <4B11770E-DE43-46AD-97F2-CB91C2299EB0@cisco.com> X-Mailer: Mew version 5.2.51 on Emacs 22.1.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: john.loughney@nokia.com, ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Alan, Could you please show us detailed evidences or something about your sugestion? We have raised the same kind of discussion at the very beginning of Node Requirement activities (draft-okabe-ipv6-lcna-minreq-XX) about 2002. At that moment, the consensus was not to remove IPsec from standard by the state of the art. At least, that was my understanding. Here are the record of that discussion: http://www.taca.jp/internet-draft/feedback-01/summary.html http://www.taca.jp/internet-draft/feedback-01/maillist.html Then, we have tried to develop IPsec solution on small embedded devices with reasonable footprint/performance. Through our experience, precisely speaking, heavy part is not IPsec body but key exchange protocols, e.g. ike and ikev2, if you can use cryptographic hardware (ex. AES and SHA1). (and crypt h/w seems common for small embedded devices, today.) By our IPsec implementation experience on 16-bits CPU system, object code size of IPsec body is not so big: SADB handling + Inbound/Outbound IPsec processing = 8kbytes However, we gave up to implement ike and ikev2 on embedded devices because of their complexity and the use of public-key crypt. Instead, we standardized Kerberos based IPsec key exchange protocol as KINK (RFC4430) with cisco people. Roughly speaking, KINK can be implemented with small footprint (45kbytes) and reasonable processing time (70msec/exchange, w/o waiting time) on 16-bits CPU system. The following paper shows some of data: http://hiroshi1.hongo.wide.ad.jp/hiroshi/papers/2007/indin2007-Okabe.pdf I understand that our approach may be not universal but specific. However, for me, your sugestion seems too rough to change the consensus. I would be happy if I see your evidence. I hope that the records and the experiences described above helps the discussion. Thanks, From: Alain Durand Subject: Making IPsec *not* mandatory in Node Requirement ( was Re: Updates to Node Requirements-bis (UNCLASSIFIED)) Date: Tue, 26 Feb 2008 13:41:37 +0800 > The latest draft: draft-ietf-6man-node-req-bis-00.txt > still lists IPsec as mandatory to implement. > > As I mentioned last IETF meeting, this is creating a problem for certain > kind of devices, like cable modems, who have a very limited memory > footprint. Those devices operate in an environment where IPsec is not used > and mandating its implementation has a serious cost: it means that legacy > devices cannot be upgraded to IPv6... > > In DOCSIS 3.0, the decision was to NOT require IPsec implementation on those > devices. I'm sure other environment have made or will make similar choices. > > Moreover, to make the point more general, we are specifying/buying many > other types of devices where we know that IPsec will never be used. Why > should the vendor of those devices have to implement it? Because one day I > might decide to deploy it? IMHO, this is not a good think, because in the > meantime, I will have to run extra code which means extra bugs, more memory > and more risks of miss-configuration. > > I would like to suggest that the node requirements remove any mention of > IPsec being mandatory to implement and instead includes text in the line of: > "if you are going to implement IPsec, here is what you should/must do". > > - Alain. ----- Nobuo Okabe (Yokogawa Electric Corporation) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 00:49:17 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F9A28C457; Tue, 26 Feb 2008 00:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.629 X-Spam-Level: * X-Spam-Status: No, score=1.629 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bez7ftSRqZ9n; Tue, 26 Feb 2008 00:49:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649563A6B1F; Tue, 26 Feb 2008 00:49:13 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DDC3A6C1C for ; Tue, 26 Feb 2008 00:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFFR7LBIdMeS for ; Tue, 26 Feb 2008 00:49:11 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id B44CF3A6BA3 for ; Tue, 26 Feb 2008 00:49:10 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.13706820; Tue, 26 Feb 2008 03:48:43 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 03:48:43 -0500 Received: from 169.223.13.205 ([169.223.13.205]) by PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Feb 2008 08:48:42 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Tue, 26 Feb 2008 16:48:36 +0800 Subject: Re: Making IPsec *not* mandatory in Node Requirement From: Alain Durand To: Nobuo OKABE Message-ID: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4UD+9E3hsSscPSmSK5QyvmC18mAABCARb In-Reply-To: <20080226.165331.14652621.nov@tahi.org> Mime-version: 1.0 X-OriginalArrivalTime: 26 Feb 2008 08:48:43.0510 (UTC) FILETIME=[64483960:01C87854] Cc: john.loughney@nokia.com, ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The problem is that some of those devices have really limited memory and they already do (too?) many things, so there is no room left... Some vendors had to go back at their code and spend a lot of time and effort to clean things up to make room for the very basic IPv6 code, so every kb count. The whole idea of asking them to do extra efforts to implement a functionality that is not needed and that will introduce bugs & instability is not very appealing. Again, this last argument applies also to devices that do not have memory problems: if I do not need functionality X, I'd rather like not to have it implemented as it will lower the operational risks. In other words, what functionality goes into a device is a business decision that is driven by the application considered. The node requirement document is a good place to say: if you want functionality X, here is what you have to do to make sure it interoperates well, it is not the place to make business decisions. If IPsec was used ubiquitously, I'd probably have another opinion. The reality is that today, IPsec usage is more the exception than the rule (at least in my environment), and I do not see this changing soon. - Alain. On 2/26/08 3:53 PM, "Nobuo OKABE" wrote: > Hi Alan, > > Could you please show us detailed evidences > or something about your sugestion? > > We have raised the same kind of discussion at the very beginning of > Node Requirement activities (draft-okabe-ipv6-lcna-minreq-XX) about 2002. > > At that moment, the consensus was not to remove IPsec from standard > by the state of the art. At least, that was my understanding. > > Here are the record of that discussion: > http://www.taca.jp/internet-draft/feedback-01/summary.html > http://www.taca.jp/internet-draft/feedback-01/maillist.html > > Then, we have tried to develop IPsec solution > on small embedded devices with reasonable footprint/performance. > > Through our experience, precisely speaking, > heavy part is not IPsec body > but key exchange protocols, e.g. ike and ikev2, > if you can use cryptographic hardware (ex. AES and SHA1). > (and crypt h/w seems common for small embedded devices, today.) > > By our IPsec implementation experience on 16-bits CPU system, > object code size of IPsec body is not so big: > SADB handling + Inbound/Outbound IPsec processing = 8kbytes > > However, we gave up to implement ike and ikev2 on embedded devices > because of their complexity and the use of public-key crypt. > > Instead, we standardized Kerberos based IPsec key exchange protocol > as KINK (RFC4430) with cisco people. > Roughly speaking, KINK can be implemented with small footprint (45kbytes) > and reasonable processing time (70msec/exchange, w/o waiting time) > on 16-bits CPU system. > > The following paper shows some of data: > http://hiroshi1.hongo.wide.ad.jp/hiroshi/papers/2007/indin2007-Okabe.pdf > > I understand that our approach may be not universal but specific. > However, for me, your sugestion seems too rough to change the consensus. > I would be happy if I see your evidence. > > I hope that the records and the experiences described above > helps the discussion. > > Thanks, > > From: Alain Durand > Subject: Making IPsec *not* mandatory in Node Requirement ( was Re: Updates to > Node Requirements-bis (UNCLASSIFIED)) > Date: Tue, 26 Feb 2008 13:41:37 +0800 > >> The latest draft: draft-ietf-6man-node-req-bis-00.txt >> still lists IPsec as mandatory to implement. >> >> As I mentioned last IETF meeting, this is creating a problem for certain >> kind of devices, like cable modems, who have a very limited memory >> footprint. Those devices operate in an environment where IPsec is not used >> and mandating its implementation has a serious cost: it means that legacy >> devices cannot be upgraded to IPv6... >> >> In DOCSIS 3.0, the decision was to NOT require IPsec implementation on those >> devices. I'm sure other environment have made or will make similar choices. >> >> Moreover, to make the point more general, we are specifying/buying many >> other types of devices where we know that IPsec will never be used. Why >> should the vendor of those devices have to implement it? Because one day I >> might decide to deploy it? IMHO, this is not a good think, because in the >> meantime, I will have to run extra code which means extra bugs, more memory >> and more risks of miss-configuration. >> >> I would like to suggest that the node requirements remove any mention of >> IPsec being mandatory to implement and instead includes text in the line of: >> "if you are going to implement IPsec, here is what you should/must do". >> >> - Alain. > > ----- Nobuo Okabe (Yokogawa Electric Corporation) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 01:51:37 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869973A6C1F; Tue, 26 Feb 2008 01:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-pw17apITCs; Tue, 26 Feb 2008 01:51:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2D13A6969; Tue, 26 Feb 2008 01:51:36 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB013A6969 for ; Tue, 26 Feb 2008 01:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68QnwRXKDKif for ; Tue, 26 Feb 2008 01:51:34 -0800 (PST) Received: from tomato.taca.jp (tomato.taca.jp [202.214.123.64]) by core3.amsl.com (Postfix) with ESMTP id 0D0193A67F8 for ; Tue, 26 Feb 2008 01:51:34 -0800 (PST) Received: from localhost (unknown [202.214.123.64]) by tomato.taca.jp (Postfix) with ESMTP id D4DEF33CBA; Tue, 26 Feb 2008 18:51:27 +0900 (JST) Date: Tue, 26 Feb 2008 18:51:16 +0900 (JST) Message-Id: <20080226.185116.88241061.nov@tahi.org> To: alain_durand@cable.comcast.com Subject: Re: Making IPsec *not* mandatory in Node Requirement From: Nobuo OKABE In-Reply-To: References: <20080226.165331.14652621.nov@tahi.org> X-Mailer: Mew version 5.2.51 on Emacs 22.1.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: john.loughney@nokia.com, ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Alain, I really know the situation what you are saying. And there is other fact: Practical activities usually take over standardized specification. Anyway, aggressive vendors sometimes remove unused functions even though those are specified as MUST. So, the discussion you rose may be related to not only technical one but also motto/spirit of IETF's standardization activity. # "practical vs. principle"-like...I cannot find appropriate words in English. Then, I have opposite ideas. Principal: In the future, implementation issue will be solved somehow (ex. crypt h/w). So security requirement should be remained. Practical: If there is something MUST item which almost implementations ignore, it can harm the value of standardization itself. Hmm....I think that standardized spec should be targeted to not everything but the majority. There is no rule but has some exception. But what is the majority?.....Hmm.... Thanks, From: Alain Durand Subject: Re: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 16:48:36 +0800 > The problem is that some of those devices have really limited memory and > they already do (too?) many things, so there is no room left... Some vendors > had to go back at their code and spend a lot of time and effort to clean > things up to make room for the very basic IPv6 code, so every kb count. > > The whole idea of asking them to do extra efforts to implement a > functionality that is not needed and that will introduce bugs & instability > is not very appealing. > > Again, this last argument applies also to devices that do not have memory > problems: if I do not need functionality X, I'd rather like not to have it > implemented as it will lower the operational risks. > > In other words, what functionality goes into a device is a business decision > that is driven by the application considered. The node requirement document > is a good place to say: if you want functionality X, here is what you have > to do to make sure it interoperates well, it is not the place to make > business decisions. > > If IPsec was used ubiquitously, I'd probably have another opinion. The > reality is that today, IPsec usage is more the exception than the rule (at > least in my environment), and I do not see this changing soon. > > - Alain. > > > On 2/26/08 3:53 PM, "Nobuo OKABE" wrote: > > > Hi Alan, > > > > Could you please show us detailed evidences > > or something about your sugestion? > > > > We have raised the same kind of discussion at the very beginning of > > Node Requirement activities (draft-okabe-ipv6-lcna-minreq-XX) about 2002. > > > > At that moment, the consensus was not to remove IPsec from standard > > by the state of the art. At least, that was my understanding. > > > > Here are the record of that discussion: > > http://www.taca.jp/internet-draft/feedback-01/summary.html > > http://www.taca.jp/internet-draft/feedback-01/maillist.html > > > > Then, we have tried to develop IPsec solution > > on small embedded devices with reasonable footprint/performance. > > > > Through our experience, precisely speaking, > > heavy part is not IPsec body > > but key exchange protocols, e.g. ike and ikev2, > > if you can use cryptographic hardware (ex. AES and SHA1). > > (and crypt h/w seems common for small embedded devices, today.) > > > > By our IPsec implementation experience on 16-bits CPU system, > > object code size of IPsec body is not so big: > > SADB handling + Inbound/Outbound IPsec processing = 8kbytes > > > > However, we gave up to implement ike and ikev2 on embedded devices > > because of their complexity and the use of public-key crypt. > > > > Instead, we standardized Kerberos based IPsec key exchange protocol > > as KINK (RFC4430) with cisco people. > > Roughly speaking, KINK can be implemented with small footprint (45kbytes) > > and reasonable processing time (70msec/exchange, w/o waiting time) > > on 16-bits CPU system. > > > > The following paper shows some of data: > > http://hiroshi1.hongo.wide.ad.jp/hiroshi/papers/2007/indin2007-Okabe.pdf > > > > I understand that our approach may be not universal but specific. > > However, for me, your sugestion seems too rough to change the consensus. > > I would be happy if I see your evidence. > > > > I hope that the records and the experiences described above > > helps the discussion. > > > > Thanks, > > > > From: Alain Durand > > Subject: Making IPsec *not* mandatory in Node Requirement ( was Re: Updates to > > Node Requirements-bis (UNCLASSIFIED)) > > Date: Tue, 26 Feb 2008 13:41:37 +0800 > > > >> The latest draft: draft-ietf-6man-node-req-bis-00.txt > >> still lists IPsec as mandatory to implement. > >> > >> As I mentioned last IETF meeting, this is creating a problem for certain > >> kind of devices, like cable modems, who have a very limited memory > >> footprint. Those devices operate in an environment where IPsec is not used > >> and mandating its implementation has a serious cost: it means that legacy > >> devices cannot be upgraded to IPv6... > >> > >> In DOCSIS 3.0, the decision was to NOT require IPsec implementation on those > >> devices. I'm sure other environment have made or will make similar choices. > >> > >> Moreover, to make the point more general, we are specifying/buying many > >> other types of devices where we know that IPsec will never be used. Why > >> should the vendor of those devices have to implement it? Because one day I > >> might decide to deploy it? IMHO, this is not a good think, because in the > >> meantime, I will have to run extra code which means extra bugs, more memory > >> and more risks of miss-configuration. > >> > >> I would like to suggest that the node requirements remove any mention of > >> IPsec being mandatory to implement and instead includes text in the line of: > >> "if you are going to implement IPsec, here is what you should/must do". > >> > >> - Alain. > > > > ----- Nobuo Okabe (Yokogawa Electric Corporation) ----- Nobuo Okabe (Yokogawa Electric Corporation) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 02:06:00 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9243A6C38; Tue, 26 Feb 2008 02:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjcOon8fcTwi; Tue, 26 Feb 2008 02:05:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1463A6B52; Tue, 26 Feb 2008 02:05:50 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C8C3A69FF for ; Tue, 26 Feb 2008 02:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwCaxhqhdOKB for ; Tue, 26 Feb 2008 02:05:48 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 8504B3A6B52 for ; Tue, 26 Feb 2008 02:05:47 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m1QA57F5015381; Tue, 26 Feb 2008 12:05:07 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m1QA57VE015377; Tue, 26 Feb 2008 12:05:07 +0200 Date: Tue, 26 Feb 2008 12:05:07 +0200 (EET) From: Pekka Savola To: Alain Durand Subject: the role of the node "requirements" document In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92.1/5996/Tue Feb 26 01:26:09 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: john.loughney@nokia.com, ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, 26 Feb 2008, Alain Durand wrote: > The problem is that some of those devices have really limited memory and > they already do (too?) many things, so there is no room left... Some vendors > had to go back at their code and spend a lot of time and effort to clean > things up to make room for the very basic IPv6 code, so every kb count. > > The whole idea of asking them to do extra efforts to implement a > functionality that is not needed and that will introduce bugs & instability > is not very appealing. > > Again, this last argument applies also to devices that do not have memory > problems: if I do not need functionality X, I'd rather like not to have it > implemented as it will lower the operational risks. I think this discussion somewhat misses the point because some folks feel informational roadmap documents have more weight than they actually do (according to IETF procedures, or even in practice in vendors' feature planning). (E.g., there was similar discussion about RFC4614.) The node requirements document, despite its misleading title, is INFORMATIONAL. It does not represent IETF consensus, so even if the document would say every IPv6 node MUST implement IPsec, it would mean basically nothing. Where is a Standards Track or BCP document that says IPsec is mandatory? If vendors need to make tradeoffs of what they implement or don't implement, that's their call. They can't call that product to be "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC number which mandates IPsec). That's all. The product also might not get IPv6 ready logo certifications and such, but that's not IETF's business anyway. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 05:06:44 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EEC428C3B7; Tue, 26 Feb 2008 05:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3waM2YAHTWUv; Tue, 26 Feb 2008 05:06:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344F828C292; Tue, 26 Feb 2008 05:06:43 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D05828C2E0 for ; Tue, 26 Feb 2008 05:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie2ZXKZXZB3H for ; Tue, 26 Feb 2008 05:06:39 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 69DE728C292 for ; Tue, 26 Feb 2008 05:06:39 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2008 05:06:33 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1QD6X9t024360; Tue, 26 Feb 2008 05:06:33 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1QD6BRY015265; Tue, 26 Feb 2008 13:06:31 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 08:06:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Tue, 26 Feb 2008 08:06:12 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach4Xz+YRvQ5QfooQQSWyAZwcdbLpQAFGJIA References: From: "Hemant Singh (shemant)" To: "Pekka Savola" , "Alain Durand" X-OriginalArrivalTime: 26 Feb 2008 13:06:12.0861 (UTC) FILETIME=[5CD01AD0:01C87878] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3655; t=1204031193; x=1204895193; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20the=20role=20of=20the=20node=20=22requi rements=22=20document |Sender:=20; bh=ZSDq+iQ18g2Fy62veyA3FgV06Xsngc61pb1Sm98TH4I=; b=eOYXyJRwDP4c6MBnlVYE5ryqBwrWiDJ/7UVddw6s9/wOpdrWoCqo2yme67 +cSHa9Ly8QJ3DTXRzEiOWXhsPygvIHdw8D5MIp8Xh0MCU9uQ1cTthynql0E1 h78OlgviGu; Authentication-Results: sj-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: john.loughney@nokia.com, ipv6@ietf.org, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Pekka, The node requirement draft as I read it from http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt is on Standards Track. Did I miss anything because you think this node requirement doc is an INFORMATIONAL draft? As for IPSec and IPv6, indeed it is true that IPSec is mandatory for IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security Architecture for the Internet Protocol). Snipped from the RFC's is section 10 shown below between square brackets. [10. Conformance Requirements All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document.] I totally appreciate Alain's concern for cable modem devices with limited memory for IPv6 but the problem is that IPv6 community decided as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. Cable IPv6 standards came much later. We will have to see what common ground can be met to address Alain's concern. Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Pekka Savola Sent: Tuesday, February 26, 2008 5:05 AM To: Alain Durand Cc: john.loughney@nokia.com; ipv6@ietf.org; Fred Baker (fred) Subject: the role of the node "requirements" document On Tue, 26 Feb 2008, Alain Durand wrote: > The problem is that some of those devices have really limited memory > and they already do (too?) many things, so there is no room left... > Some vendors had to go back at their code and spend a lot of time and > effort to clean things up to make room for the very basic IPv6 code, so every kb count. > > The whole idea of asking them to do extra efforts to implement a > functionality that is not needed and that will introduce bugs & > instability is not very appealing. > > Again, this last argument applies also to devices that do not have > memory > problems: if I do not need functionality X, I'd rather like not to > have it implemented as it will lower the operational risks. I think this discussion somewhat misses the point because some folks feel informational roadmap documents have more weight than they actually do (according to IETF procedures, or even in practice in vendors' feature planning). (E.g., there was similar discussion about RFC4614.) The node requirements document, despite its misleading title, is INFORMATIONAL. It does not represent IETF consensus, so even if the document would say every IPv6 node MUST implement IPsec, it would mean basically nothing. Where is a Standards Track or BCP document that says IPsec is mandatory? If vendors need to make tradeoffs of what they implement or don't implement, that's their call. They can't call that product to be "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC number which mandates IPsec). That's all. The product also might not get IPv6 ready logo certifications and such, but that's not IETF's business anyway. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 06:37:45 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B2328C488; Tue, 26 Feb 2008 06:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXSw52F8Rvga; Tue, 26 Feb 2008 06:37:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C433A6BEF; Tue, 26 Feb 2008 06:37:44 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE5128C359 for ; Tue, 26 Feb 2008 06:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUJD1K8FawHL for ; Tue, 26 Feb 2008 06:27:52 -0800 (PST) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.26.33]) by core3.amsl.com (Postfix) with ESMTP id 577C728C4EB for ; Tue, 26 Feb 2008 06:27:44 -0800 (PST) Received: from ([128.244.206.192]) by piper.jhuapl.edu with ESMTP id 5502121.67666731; Tue, 26 Feb 2008 09:27:16 -0500 Message-ID: <47C421C3.7070806@innovationslab.net> Date: Tue, 26 Feb 2008 09:27:15 -0500 From: Brian Haberman User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: the role of the node "requirements" document References: In-Reply-To: X-Mailman-Approved-At: Tue, 26 Feb 2008 06:37:42 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hemant, Take a look at the category for RFC 4294 at http://tools.ietf.org/html/rfc4294. It is Informational and no discussion has occurred to change that classification for this update. Regards, Brian Hemant Singh (shemant) wrote: > Pekka, > > The node requirement draft as I read it from > > http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt > > is on Standards Track. Did I miss anything because you think this node > requirement doc is an INFORMATIONAL draft? > > As for IPSec and IPv6, indeed it is true that IPSec is mandatory for > IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is > mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security > Architecture for the Internet Protocol). Snipped from the RFC's is > section 10 shown below between square brackets. > > [10. Conformance Requirements > > All IPv4 systems that claim to implement IPsec MUST comply with all > requirements of the Security Architecture document. All IPv6 systems > MUST comply with all requirements of the Security Architecture > document.] > > I totally appreciate Alain's concern for cable modem devices with > limited memory for IPv6 but the problem is that IPv6 community decided > as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. > Cable IPv6 standards came much later. We will have to see what common > ground can be met to address Alain's concern. > > Hemant > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Pekka Savola > Sent: Tuesday, February 26, 2008 5:05 AM > To: Alain Durand > Cc: john.loughney@nokia.com; ipv6@ietf.org; Fred Baker (fred) > Subject: the role of the node "requirements" document > > On Tue, 26 Feb 2008, Alain Durand wrote: >> The problem is that some of those devices have really limited memory >> and they already do (too?) many things, so there is no room left... >> Some vendors had to go back at their code and spend a lot of time and >> effort to clean things up to make room for the very basic IPv6 code, > so every kb count. >> The whole idea of asking them to do extra efforts to implement a >> functionality that is not needed and that will introduce bugs & >> instability is not very appealing. >> >> Again, this last argument applies also to devices that do not have >> memory >> problems: if I do not need functionality X, I'd rather like not to >> have it implemented as it will lower the operational risks. > > I think this discussion somewhat misses the point because some folks > feel informational roadmap documents have more weight than they actually > do (according to IETF procedures, or even in practice in vendors' > feature planning). (E.g., there was similar discussion about > RFC4614.) > > The node requirements document, despite its misleading title, is > INFORMATIONAL. It does not represent IETF consensus, so even if the > document would say every IPv6 node MUST implement IPsec, it would mean > basically nothing. > > Where is a Standards Track or BCP document that says IPsec is mandatory? > > If vendors need to make tradeoffs of what they implement or don't > implement, that's their call. They can't call that product to be > "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or > claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC number > which mandates IPsec). That's all. > > The product also might not get IPv6 ready logo certifications and such, > but that's not IETF's business anyway. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 06:41:45 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62BA28C527; Tue, 26 Feb 2008 06:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTf6NxiEUQrh; Tue, 26 Feb 2008 06:41:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F89228C4FD; Tue, 26 Feb 2008 06:41:43 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A458D28C4FD for ; Tue, 26 Feb 2008 06:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slRlnOVWgxrF for ; Tue, 26 Feb 2008 06:41:41 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 43F7C28C4EA for ; Tue, 26 Feb 2008 06:41:41 -0800 (PST) Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.113]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 14:41:34 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Tue, 26 Feb 2008 14:42:01 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach4Xz+YRvQ5QfooQQSWyAZwcdbLpQAFGJIAAAPf6mA= References: From: To: X-OriginalArrivalTime: 26 Feb 2008 14:41:34.0573 (UTC) FILETIME=[AF3811D0:01C87885] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > I totally appreciate Alain's concern for cable modem devices > with limited memory for IPv6 but the problem is that IPv6 > community decided as far back as 1998 with RFC 2401 that > IPSec is mandatory for IPv6. The events of 1998 are irrelevant. The fact is that this website clearly does not consider IPsec to be part of the IPv6 core protocols and therefore lots of implementations will not have it. Cable boxes are not much different from general purpose computers running Linux. In fact, they may use Linux for all I know. In any case, they are complex devices and if you looked at an architecture diagram for them they would like rather like a network in a box with many functions on separate chips (or areas of an FPGA) all communicating with various internal protocols and busses. But IPv6 is not just for devices like that. It was also intended to be something that could be implemented on embedded devices that often use 8-bit CPUs with the IP stack written in carefully handcoded assembly language. TINI is an example of such a device but there are hundreds of them out there and manufacturers continue to introduce new 8-bit microcontrollers all the time. If you have any contacts with Yokogawa in Japan, they have a lot of experience in this area and will be able to give a better idea of how common it is to implement IPv6 without IPsec. WIDE people may also know more about this. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 06:44:10 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE11D28C55D; Tue, 26 Feb 2008 06:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0QLqeiSIQZm; Tue, 26 Feb 2008 06:44:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2DD28C4B7; Tue, 26 Feb 2008 06:44:00 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1765B28C44D for ; Tue, 26 Feb 2008 06:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVaQ3T1pwXFz for ; Tue, 26 Feb 2008 06:43:58 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E36BB28C552 for ; Tue, 26 Feb 2008 06:43:52 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1QEhC3G015784; Tue, 26 Feb 2008 16:43:44 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 16:43:38 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 08:42:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Tue, 26 Feb 2008 08:42:12 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A010C451D@daebe104.NOE.Nokia.com> In-Reply-To: <47C421C3.7070806@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach4hTPkd+5vwLraSj2WAQiY2eAhMQAAHocQ References: <47C421C3.7070806@innovationslab.net> From: To: , X-OriginalArrivalTime: 26 Feb 2008 14:42:45.0933 (UTC) FILETIME=[D9C0BDD0:01C87885] X-Nokia-AV: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, If people feel that further disclaimers are needed in the current bis draft to ensure that people understand that it only meant as an informative compendium, then I am happy to add that extra text. John >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >Behalf Of ext Brian Haberman >Sent: 26 February, 2008 06:27 >To: ipv6@ietf.org >Subject: Re: the role of the node "requirements" document > >Hemant, > Take a look at the category for RFC 4294 at >http://tools.ietf.org/html/rfc4294. It is Informational and >no discussion has occurred to change that classification for >this update. > >Regards, >Brian > > >Hemant Singh (shemant) wrote: >> Pekka, >> >> The node requirement draft as I read it from >> >> >http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.tx >> t >> >> is on Standards Track. Did I miss anything because you think >this node >> requirement doc is an INFORMATIONAL draft? >> >> As for IPSec and IPv6, indeed it is true that IPSec is mandatory for >> IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is >> mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security >> Architecture for the Internet Protocol). Snipped from the RFC's is >> section 10 shown below between square brackets. >> >> [10. Conformance Requirements >> >> All IPv4 systems that claim to implement IPsec MUST >comply with all >> requirements of the Security Architecture document. All >IPv6 systems >> MUST comply with all requirements of the Security Architecture >> document.] >> >> I totally appreciate Alain's concern for cable modem devices with >> limited memory for IPv6 but the problem is that IPv6 >community decided >> as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. >> Cable IPv6 standards came much later. We will have to see >what common >> ground can be met to address Alain's concern. >> >> Hemant >> >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf >> Of Pekka Savola >> Sent: Tuesday, February 26, 2008 5:05 AM >> To: Alain Durand >> Cc: john.loughney@nokia.com; ipv6@ietf.org; Fred Baker (fred) >> Subject: the role of the node "requirements" document >> >> On Tue, 26 Feb 2008, Alain Durand wrote: >>> The problem is that some of those devices have really >limited memory >>> and they already do (too?) many things, so there is no room left... >>> Some vendors had to go back at their code and spend a lot >of time and >>> effort to clean things up to make room for the very basic IPv6 code, >> so every kb count. >>> The whole idea of asking them to do extra efforts to implement a >>> functionality that is not needed and that will introduce bugs & >>> instability is not very appealing. >>> >>> Again, this last argument applies also to devices that do not have >>> memory >>> problems: if I do not need functionality X, I'd rather like not to >>> have it implemented as it will lower the operational risks. >> >> I think this discussion somewhat misses the point because some folks >> feel informational roadmap documents have more weight than they >> actually do (according to IETF procedures, or even in >practice in vendors' >> feature planning). (E.g., there was similar discussion about >> RFC4614.) >> >> The node requirements document, despite its misleading title, is >> INFORMATIONAL. It does not represent IETF consensus, so even if the >> document would say every IPv6 node MUST implement IPsec, it >would mean >> basically nothing. >> >> Where is a Standards Track or BCP document that says IPsec >is mandatory? >> >> If vendors need to make tradeoffs of what they implement or don't >> implement, that's their call. They can't call that product to be >> "RFC4294 compliant", "RFC4301 compliant", claim it supports >IPsec, or >> claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC >> number which mandates IPsec). That's all. >> >> The product also might not get IPv6 ready logo certifications and >> such, but that's not IETF's business anyway. >> >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 07:43:26 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3620928C454; Tue, 26 Feb 2008 07:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.911, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcOK-F8eY1VA; Tue, 26 Feb 2008 07:43:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9179A28C388; Tue, 26 Feb 2008 07:43:24 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E9628C1BA for ; Tue, 26 Feb 2008 07:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQn-bGTySlMW for ; Tue, 26 Feb 2008 07:43:18 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 29DB33A6B33 for ; Tue, 26 Feb 2008 07:43:18 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m1QFh4Px008421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Feb 2008 07:43:07 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m1QFh47o027922; Tue, 26 Feb 2008 07:43:04 -0800 (PST) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m1QFh34u027909; Tue, 26 Feb 2008 07:43:04 -0800 (PST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 10:43:02 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) Date: Tue, 26 Feb 2008 10:43:02 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis (UNCLASSIFIED) Thread-Index: Ach4PPscI2rEE49RTsO5j6dzkpxhfAAUAZIg References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> From: "Manfredi, Albert E" To: "Pekka Savola" X-OriginalArrivalTime: 26 Feb 2008 15:43:02.0411 (UTC) FILETIME=[45577DB0:01C8788E] Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > NIST's goal was probably, "some implementations on the field just > support static and maybe RIPng. We want to mandate something more > scalable, and OSPFv3 is as good an option as any". I completely agree. And, if the NIST Profile were directed at commodity router vendors, e.g. for enterprise networks of Govt agencies, there would be some logic in that. However, all IPv6 networks owned and operated by the Government are not that sort of network. This is similar to Alain Durand's point about cable modems, where you want the smallest possible memory footprint when supplying the needed services. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 07:53:22 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1F13A6C82; Tue, 26 Feb 2008 07:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Puipg7amjf-m; Tue, 26 Feb 2008 07:53:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7D53A6BA0; Tue, 26 Feb 2008 07:53:17 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC703A6BA0 for ; Tue, 26 Feb 2008 07:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aiZRUcUAVG2 for ; Tue, 26 Feb 2008 07:53:10 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 316193A6837 for ; Tue, 26 Feb 2008 07:53:10 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Feb 2008 10:53:02 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1QFr1jh014566; Tue, 26 Feb 2008 10:53:01 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1QFqnJv016751; Tue, 26 Feb 2008 15:53:02 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 10:52:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Tue, 26 Feb 2008 10:52:55 -0500 Message-ID: In-Reply-To: <47C421C3.7070806@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach4hS9zUEw6/L+/Sm2VvDMkERfXLwAChqSg References: <47C421C3.7070806@innovationslab.net> From: "Hemant Singh (shemant)" To: "Brian Haberman" , X-OriginalArrivalTime: 26 Feb 2008 15:52:55.0596 (UTC) FILETIME=[A6E856C0:01C8788F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4550; t=1204041182; x=1204905182; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20the=20role=20of=20the=20node=20=22requi rements=22=20document |Sender:=20 |To:=20=22Brian=20Haberman=22=20, =20; bh=kQL3gcgfSU7ITnpmhzf1Iym2aVnl5nZ3BIbZO94WF7k=; b=J5qQxYeGZpr+uJ2Sn/iY6dRLj+mfS2aastzUrGvRmOxRjfc2WUsw1yJmZB 3ilisyjvMdn8o1y5jK/yhEAOT20s5WTy7xLi7M+9i02CsV5W91BKcAJ1C+fn 32wi4eMwEH; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian, Indeed, I know that RFC4294 is INFORMATIONAL. I got confused because I see the new node-req-bis draft URL snipped below to be on Standards Track. http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt Sorry, if I am missing some IETF process. I was expecting the bis draft above to be INFORMATIONAL as well. Thanks. Best Regards. Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Tuesday, February 26, 2008 9:27 AM To: ipv6@ietf.org Subject: Re: the role of the node "requirements" document Hemant, Take a look at the category for RFC 4294 at http://tools.ietf.org/html/rfc4294. It is Informational and no discussion has occurred to change that classification for this update. Regards, Brian Hemant Singh (shemant) wrote: > Pekka, > > The node requirement draft as I read it from > > http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.tx > t > > is on Standards Track. Did I miss anything because you think this node > requirement doc is an INFORMATIONAL draft? > > As for IPSec and IPv6, indeed it is true that IPSec is mandatory for > IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is > mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security > Architecture for the Internet Protocol). Snipped from the RFC's is > section 10 shown below between square brackets. > > [10. Conformance Requirements > > All IPv4 systems that claim to implement IPsec MUST comply with all > requirements of the Security Architecture document. All IPv6 systems > MUST comply with all requirements of the Security Architecture > document.] > > I totally appreciate Alain's concern for cable modem devices with > limited memory for IPv6 but the problem is that IPv6 community decided > as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. > Cable IPv6 standards came much later. We will have to see what common > ground can be met to address Alain's concern. > > Hemant > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of Pekka Savola > Sent: Tuesday, February 26, 2008 5:05 AM > To: Alain Durand > Cc: john.loughney@nokia.com; ipv6@ietf.org; Fred Baker (fred) > Subject: the role of the node "requirements" document > > On Tue, 26 Feb 2008, Alain Durand wrote: >> The problem is that some of those devices have really limited memory >> and they already do (too?) many things, so there is no room left... >> Some vendors had to go back at their code and spend a lot of time and >> effort to clean things up to make room for the very basic IPv6 code, > so every kb count. >> The whole idea of asking them to do extra efforts to implement a >> functionality that is not needed and that will introduce bugs & >> instability is not very appealing. >> >> Again, this last argument applies also to devices that do not have >> memory >> problems: if I do not need functionality X, I'd rather like not to >> have it implemented as it will lower the operational risks. > > I think this discussion somewhat misses the point because some folks > feel informational roadmap documents have more weight than they > actually do (according to IETF procedures, or even in practice in vendors' > feature planning). (E.g., there was similar discussion about > RFC4614.) > > The node requirements document, despite its misleading title, is > INFORMATIONAL. It does not represent IETF consensus, so even if the > document would say every IPv6 node MUST implement IPsec, it would mean > basically nothing. > > Where is a Standards Track or BCP document that says IPsec is mandatory? > > If vendors need to make tradeoffs of what they implement or don't > implement, that's their call. They can't call that product to be > "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or > claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC > number which mandates IPsec). That's all. > > The product also might not get IPv6 ready logo certifications and > such, but that's not IETF's business anyway. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 07:58:18 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A545E28C456; Tue, 26 Feb 2008 07:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rPJ+QUSFTBu; Tue, 26 Feb 2008 07:58:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A658B3A6BA0; Tue, 26 Feb 2008 07:58:17 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA0328C15C for ; Tue, 26 Feb 2008 07:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPoBSsnOCalA for ; Tue, 26 Feb 2008 07:58:15 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 05D123A6B96 for ; Tue, 26 Feb 2008 07:58:14 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 25so1478222wfa.31 for ; Tue, 26 Feb 2008 07:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sW61XR3gFLmuXPuVsosWf4J3haH4+EP2gmua8L7TKuk=; b=NR3wzVVKw4JaKqQQuiU8nrPXL87LEEyiBDgNH5uDcSj/JP++hJXajqBc+x62WklGxCof/yogGWAXnlAUqSGpJKNinkBGZYG5ZKuJQq8DvgBzietFMIaFSAHank3z4y1OGEL1/99U4e4bC4/NYNM16GI1iYzeDVQQQNbPeVPfiZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H3+LQPjOZ5daZh3zBbhOxvnXVBvtkS++qjEJceKSp7xBmZwseEf5jx53QAO8SK8lIB5WDvhczDwivdToRbPVOlm97OW7BY5b51U3RtPvPkcW/b7B9BQA+w/lRbaTjaeMq01JILuajT0dn65QgQzzwSwqmPTftjRynJZYoaFQt2o= Received: by 10.142.221.19 with SMTP id t19mr3885059wfg.62.1204041488947; Tue, 26 Feb 2008 07:58:08 -0800 (PST) Received: by 10.143.164.14 with HTTP; Tue, 26 Feb 2008 07:58:08 -0800 (PST) Message-ID: <77ead0ec0802260758s1ed7e4aey2e4fff98ab6fa420@mail.gmail.com> Date: Tue, 26 Feb 2008 07:58:08 -0800 From: "Vishwas Manral" To: "Manfredi, Albert E" Subject: Re: Updates to Node Requirements-bis (UNCLASSIFIED) In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> <19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> Cc: ipv6@ietf.org, Pekka Savola X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Albert, Instead of mandating every protocol, would it be helpful to further break the functionality into two subclasses and have seperate requirements in such cases. I do not like the idea of having to impose a superset of the requirements for all such nodes. In my view such functionality should kept to the minimum. Thanks, Vishwas On Tue, Feb 26, 2008 at 7:43 AM, Manfredi, Albert E wrote: > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > NIST's goal was probably, "some implementations on the field just > > support static and maybe RIPng. We want to mandate something more > > scalable, and OSPFv3 is as good an option as any". > > I completely agree. And, if the NIST Profile were directed at commodity > router vendors, e.g. for enterprise networks of Govt agencies, there > would be some logic in that. However, all IPv6 networks owned and > operated by the Government are not that sort of network. This is similar > to Alain Durand's point about cable modems, where you want the smallest > possible memory footprint when supplying the needed services. > > Bert > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 08:13:13 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9D628C55C; Tue, 26 Feb 2008 08:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFbCIOdhm54h; Tue, 26 Feb 2008 08:13:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08B528C3E5; Tue, 26 Feb 2008 08:12:57 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616B628C3A1 for ; Tue, 26 Feb 2008 08:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neGlrZnphs43 for ; Tue, 26 Feb 2008 08:12:54 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 12FB33A6D4D for ; Tue, 26 Feb 2008 08:12:39 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m1QGCIv8018443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Feb 2008 08:12:27 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m1QGCIIB019083; Tue, 26 Feb 2008 08:12:18 -0800 (PST) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m1QGCH0u019059; Tue, 26 Feb 2008 08:12:18 -0800 (PST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 11:12:17 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Updates to Node Requirements-bis (UNCLASSIFIED) Date: Tue, 26 Feb 2008 11:12:16 -0500 Message-ID: In-Reply-To: <77ead0ec0802260758s1ed7e4aey2e4fff98ab6fa420@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to Node Requirements-bis (UNCLASSIFIED) Thread-Index: Ach4kGOShBUNPzrETRmO3+cunjQX2QAACVHg References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com> <19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> <77ead0ec0802260758s1ed7e4aey2e4fff98ab6fa420@mail.gmail.com> From: "Manfredi, Albert E" To: "Vishwas Manral" X-OriginalArrivalTime: 26 Feb 2008 16:12:17.0575 (UTC) FILETIME=[5B804370:01C87892] Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, February 26, 2008 10:58 AM > To: Manfredi, Albert E > Cc: Pekka Savola; ipv6@ietf.org > Subject: Re: Updates to Node Requirements-bis (UNCLASSIFIED) > > Hi Albert, > > Instead of mandating every protocol, would it be helpful to further > break the functionality into two subclasses and have seperate > requirements in such cases. I do not like the idea of having to impose > a superset of the requirements for all such nodes. > > In my view such functionality should kept to the minimum. Something along those lines would help. Or just qualifying some of these MUSTs, much like I-D 4294-bis does. In my case, it's not IPsec per se at issue, although even there, the security model has to make sense. For example, it doesn't make much sense to specify a vault door as the front door to your home, and at the same time provide no walls on either side of this door. If you are going to secure a network, sending plaintext to routers which are located in non-secure spaces, and expecting these routers to make the network secure, is clearly not going to fly. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 08:18:50 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E143A6D62; Tue, 26 Feb 2008 08:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaCtmd8gGO-M; Tue, 26 Feb 2008 08:18:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892A03A6D4D; Tue, 26 Feb 2008 08:18:49 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FDD3A68F3 for ; Tue, 26 Feb 2008 08:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCOMmtzrswjE for ; Tue, 26 Feb 2008 08:18:43 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 847073A6D16 for ; Tue, 26 Feb 2008 08:18:43 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1QGIakE016685 for ; Tue, 26 Feb 2008 11:18:36 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1QGIatV104520 for ; Tue, 26 Feb 2008 11:18:36 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1QGIa9B014382 for ; Tue, 26 Feb 2008 11:18:36 -0500 Received: from cichlid.raleigh.ibm.com (wecm-9-67-196-237.wecm.ibm.com [9.67.196.237]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1QGIZ5E014370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 11:18:35 -0500 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m1QGIXqt016372; Tue, 26 Feb 2008 11:18:34 -0500 Message-Id: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> To: Nobuo OKABE Subject: Re: Making IPsec *not* mandatory in Node Requirement In-reply-to: <20080226.165331.14652621.nov@tahi.org> References: <4B11770E-DE43-46AD-97F2-CB91C2299EB0@cisco.com> <20080226.165331.14652621.nov@tahi.org> Comments: In-reply-to Nobuo OKABE message dated "Tue, 26 Feb 2008 16:53:31 +0900." Date: Tue, 26 Feb 2008 11:18:33 -0500 From: Thomas Narten Cc: john.loughney@nokia.com, ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org IMO, we need to get over the idea that IPsec is mandatory in IPv6. Really. Or that mandating IPsec is actually useful in practice. It is the case that mandating IPsec as part of IPv6 has contributed to the hype about how great IPv6 is and how one will get better security with IPv6. Unfortunately, that myth has also harmed the overall IPv6 deployment effort, as people look more closely and come to understand that deploying IPv6 doesn't automatically/easily yield improved security. We all know the reality of security is very different and much more complicated/nuanced then just saying "use IPsec". Consider: IPsec by itself (with no key management) is close to useless. The average person cannot configure static keys, so the result is (in effect) a useless mandate (as a broad mandate for ALL nodes). What applications actually make use of IPsec for security? A lot fewer than one might think. For many IPv6 devices/nodes, if one actually looks at the applications that will be used on them, they do not use IPsec today for security. And, there are strong/compelling arguments for why IPsec is not the best security solution for many applications. Thus, requiring IPsec is pointless. To be truly useful, we (of course) need key management. If we want to mandate key management, the stakes go way up. IKEv1/v2 is not a small implementation effort. And, we are now in the funny situation where IKEv1 has been implemented, but due to shortcomings, IKEv2 has already been developed. IKEv2 has been out for over 2 years, but implementations are not widespread yet. So, would we mandate IKEv1 (which is obsoleted and has documented issues), or do we mandate IKEv2, even though it is clear it is not widely available yet? IMO, we should drop the MUST language surrounding IPsec. The technical justification for making it MUST are simply not compelling. It seems to me that the MUST is there primarily for historical/marketing reasons. Note that dropping the MUST will not mean people stop implementing IPsec, where there is compelling benefit. Indeed, note that the USG has already moved away from IKEv1 and has strongly signalled that it will require IKEv2 going forward. So I am confident that IPsec (and IKE) will get implemented going forward. But there is no reason why IPsec should be mandated in devices where it is clear (based on the function/purpose of the device) that IPsec will in fact not actually be used. As a general "node requirement", SHOULD is the right level, not MUST. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 08:29:24 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C680828C5AC; Tue, 26 Feb 2008 08:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qVQcTF8wHU3; Tue, 26 Feb 2008 08:29:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E53C3A6D1A; Tue, 26 Feb 2008 08:29:22 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72F7F3A6D1A for ; Tue, 26 Feb 2008 08:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiC6wEZ+6cQ6 for ; Tue, 26 Feb 2008 08:29:20 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 6540A3A6CF2 for ; Tue, 26 Feb 2008 08:29:20 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1QGTDeZ013798 for ; Tue, 26 Feb 2008 11:29:13 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1QGTC3k140498 for ; Tue, 26 Feb 2008 09:29:12 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1QGTCkx022211 for ; Tue, 26 Feb 2008 09:29:12 -0700 Received: from cichlid.raleigh.ibm.com (wecm-9-67-196-237.wecm.ibm.com [9.67.196.237]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1QGTAdG022127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 09:29:12 -0700 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m1QGT913021002; Tue, 26 Feb 2008 11:29:09 -0500 Message-Id: <200802261629.m1QGT913021002@cichlid.raleigh.ibm.com> To: Pekka Savola Subject: Re: the role of the node "requirements" document In-reply-to: References: Comments: In-reply-to Pekka Savola message dated "Tue, 26 Feb 2008 12:05:07 +0200." Date: Tue, 26 Feb 2008 11:29:09 -0500 From: Thomas Narten Cc: john.loughney@nokia.com, ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Pekka Savola writes: > The node requirements document, despite its misleading title, is > INFORMATIONAL. It does not represent IETF consensus, so even if the > document would say every IPv6 node MUST implement IPsec, it would mean > basically nothing. You may be correct in a narrow, legalistic sense. In practice, however, saying that the document carries no weight is simply not true. The facts speak otherwise. When people look around for guidance on what to implement, they do in fact refer to the IPv6 Node Requirements RFC. Even though it is only informational and (supposedly) carries "no weight", people do in fact defer to it when they are unsure of what to do. Consider the USG IPv6 profiles. DoD (via JITC) has issued profiles. (See http://jitc.fhu.disa.mil/apl/ipv6.html). NIST is also close to finalizing profiles (see http://www.antd.nist.gov/usgv6/). These will be mandatory (in a MUST sense) for products sold to USG. Both profiles relied heavily on the recommendations of RFC 4294. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 08:37:34 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD69E28C5BC; Tue, 26 Feb 2008 08:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.407 X-Spam-Level: X-Spam-Status: No, score=0.407 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdei9yZuBDhI; Tue, 26 Feb 2008 08:37:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE58C3A6D15; Tue, 26 Feb 2008 08:37:32 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FFF53A6D51 for ; Tue, 26 Feb 2008 08:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fds08LXXdbHS for ; Tue, 26 Feb 2008 08:37:30 -0800 (PST) Received: from mailgate-internal2.sri.com (mailgate-internal2.SRI.COM [128.18.84.104]) by core3.amsl.com (Postfix) with SMTP id E011E3A6CC0 for ; Tue, 26 Feb 2008 08:36:57 -0800 (PST) Received: from localhost (HELO mailgate-internal2.SRI.COM) (127.0.0.1) by mailgate-internal2.sri.com with SMTP; 26 Feb 2008 16:36:51 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal2.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2008022608365129058 for ; Tue, 26 Feb 2008 08:36:51 -0800 Received: from [192.168.2.105] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JWU009DQU5EV8D6@mail.sri.com> for ipv6@ietf.org; Tue, 26 Feb 2008 08:36:51 -0800 (PST) Date: Tue, 26 Feb 2008 11:36:52 -0500 From: Ed Jankiewicz Subject: Re: the role of the node "requirements" document In-reply-to: To: ipv6@ietf.org Message-id: <47C44024.6050005@sri.com> MIME-version: 1.0 References: <47C421C3.7070806@innovationslab.net> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Cc: Brian Haberman X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org (full disclosure - I am one of the editors of the DoD IPv6 Profiles document - but comments are my own as an individual) 1. Can we discuss the normative level of the revised Node Requirements document? My preference would be that it is a standards track or BCP ultimately, to give firm definition of what an IPv6 node MUST do. Another INFORMATIONAL document like RFC4294 is merely a helpful annotated bibliography, but that may be all we can accomplish in a reasonable timeframe, all in all it doesn't make a big difference. 2. I don't expect (nor believe it appropriate) that this revision will satisfy all the needs of either NIST or DoD for defining "IPv6 Capable" for our client organizations. That being said, several folks are already reviewing the three drafts side by side, to help ensure that the Node Requirements accurately defines the requirements that apply to ALL IPv6 nodes for ALL deployments. The editors of the DoD and NIST documents should concentrate on the delta from that baseline for specific US Government and DoD requirements and deployments. 3. Specifically with respect to IPsec and IKEv2, regardless of the "settlement" of that debate years ago, there are still valid questions about which requirements apply to ALL IPv6 nodes. I hope this revision of the Node Requirements can reiterate the commitment to IPsec, but if it does not, DoD (and NIST) can certainly state stronger and more specific requirements in our documents. DoD in particular answers to a higher authority on security and cryptographic requirements, and will probably require things that a small office or home user would never need. A prior message in this thread (from Jeremy Duncan) included pointers to the NIST and DoD profiles drafts, feel free to send any questions/comments to the editors off-list. Some of the differences are worth discussing on this list to see if there is consensus for changes to the Node Requirements draft. Additional work will need to be done by the editors of both the DoD and NIST drafts to address the specific needs of our clients that don't apply to everyone. Hemant Singh (shemant) wrote: > Brian, > > Indeed, I know that RFC4294 is INFORMATIONAL. I got confused because I > see the new node-req-bis draft URL snipped below to be on Standards > Track. > > http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt > > Sorry, if I am missing some IETF process. I was expecting the bis draft > above to be INFORMATIONAL as well. > > Thanks. > > Best Regards. > > Hemant > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian Haberman > Sent: Tuesday, February 26, 2008 9:27 AM > To: ipv6@ietf.org > Subject: Re: the role of the node "requirements" document > > Hemant, > Take a look at the category for RFC 4294 at > http://tools.ietf.org/html/rfc4294. It is Informational and no > discussion has occurred to change that classification for this update. > > Regards, > Brian > > > Hemant Singh (shemant) wrote: > >> Pekka, >> >> The node requirement draft as I read it from >> >> http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.tx >> t >> >> is on Standards Track. Did I miss anything because you think this node >> > > >> requirement doc is an INFORMATIONAL draft? >> >> As for IPSec and IPv6, indeed it is true that IPSec is mandatory for >> IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is >> mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security >> Architecture for the Internet Protocol). Snipped from the RFC's is >> section 10 shown below between square brackets. >> >> [10. Conformance Requirements >> >> All IPv4 systems that claim to implement IPsec MUST comply with all >> requirements of the Security Architecture document. All IPv6 >> > systems > >> MUST comply with all requirements of the Security Architecture >> document.] >> >> I totally appreciate Alain's concern for cable modem devices with >> limited memory for IPv6 but the problem is that IPv6 community decided >> > > >> as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. >> Cable IPv6 standards came much later. We will have to see what common >> ground can be met to address Alain's concern. >> >> Hemant >> >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf >> Of Pekka Savola >> Sent: Tuesday, February 26, 2008 5:05 AM >> To: Alain Durand >> Cc: john.loughney@nokia.com; ipv6@ietf.org; Fred Baker (fred) >> Subject: the role of the node "requirements" document >> >> On Tue, 26 Feb 2008, Alain Durand wrote: >> >>> The problem is that some of those devices have really limited memory >>> and they already do (too?) many things, so there is no room left... >>> Some vendors had to go back at their code and spend a lot of time and >>> > > >>> effort to clean things up to make room for the very basic IPv6 code, >>> >> so every kb count. >> >>> The whole idea of asking them to do extra efforts to implement a >>> functionality that is not needed and that will introduce bugs & >>> instability is not very appealing. >>> >>> Again, this last argument applies also to devices that do not have >>> memory >>> problems: if I do not need functionality X, I'd rather like not to >>> have it implemented as it will lower the operational risks. >>> >> I think this discussion somewhat misses the point because some folks >> feel informational roadmap documents have more weight than they >> actually do (according to IETF procedures, or even in practice in >> > vendors' > >> feature planning). (E.g., there was similar discussion about >> RFC4614.) >> >> The node requirements document, despite its misleading title, is >> INFORMATIONAL. It does not represent IETF consensus, so even if the >> document would say every IPv6 node MUST implement IPsec, it would mean >> > > >> basically nothing. >> >> Where is a Standards Track or BCP document that says IPsec is >> > mandatory? > >> If vendors need to make tradeoffs of what they implement or don't >> implement, that's their call. They can't call that product to be >> "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or >> claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC >> number which mandates IPsec). That's all. >> >> The product also might not get IPv6 ready logo certifications and >> such, but that's not IETF's business anyway. >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 09:30:41 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E0B28C6CB; Tue, 26 Feb 2008 09:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywo7eXwHNHJW; Tue, 26 Feb 2008 09:30:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30AAE3A6D51; Tue, 26 Feb 2008 09:30:40 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E50128C4BE for ; Tue, 26 Feb 2008 09:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo11n+vORktx for ; Tue, 26 Feb 2008 09:30:38 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 921BB3A6D51 for ; Tue, 26 Feb 2008 09:30:38 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 25so1538140wfa.31 for ; Tue, 26 Feb 2008 09:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wmxIPVcVgOLqr/h1Ahbg4MxdulzL8/rEc9lKTv67aTs=; b=LtFgfr/UKvGbsQiPmd6KLKbNbhmrg1n0fzIe5MrnZYRhOXWXaJwuhCwSNsN/C0Anmj2krCIbJO7uX/ETs5oeUD9q+QLdq0R9hZG+g547q97FLKeTmnrwqF/DjI6Xdr6Hous7EYE/MqK0FNXRz7M5bcDIXwH6HFNdZN70Fz1gTdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GrVra7Lubg4L18WKAoTtr4z8ZKFkoQT1ysLb72nCwE/vJguFSxP3fr7PB9LFktruE5qRjKEHHWj5XbnUtmjw7LGC5RRvyqcaU9YcenQN2nu2SAPYkVrKD56qzX4Eo6+Q+ggDgiiCf/8CYxXah082PgSLwaRszp5ECYQGrLoSGOo= Received: by 10.142.225.11 with SMTP id x11mr3891377wfg.204.1204047032528; Tue, 26 Feb 2008 09:30:32 -0800 (PST) Received: by 10.143.164.14 with HTTP; Tue, 26 Feb 2008 09:30:32 -0800 (PST) Message-ID: <77ead0ec0802260930y2aaafa53k8b332e629f123ba7@mail.gmail.com> Date: Tue, 26 Feb 2008 09:30:32 -0800 From: "Vishwas Manral" To: "Thomas Narten" Subject: Re: Making IPsec *not* mandatory in Node Requirement In-Reply-To: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Disposition: inline References: <4B11770E-DE43-46AD-97F2-CB91C2299EB0@cisco.com> <20080226.165331.14652621.nov@tahi.org> <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> Cc: john.loughney@nokia.com, ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Thomas, I would again suggest that instead of making it non-mandatory, we could provide a seperate set of requirements - for different device types. OSPFv3 currently uses IPsec because the assumption is that IPv6 mandates IPsec, and that means we do not need any other mechanism for the same. OSPFv2 (normal OSPF) uses its own internal mechanism for authenticating protocol packets. The idea is that if you change such requirements, it may break the assumptions taken by the other protocols regarding the same. Thanks, Vishwas On Tue, Feb 26, 2008 at 8:18 AM, Thomas Narten wrote: > IMO, we need to get over the idea that IPsec is mandatory in > IPv6. Really. Or that mandating IPsec is actually useful in practice. > > It is the case that mandating IPsec as part of IPv6 has contributed to > the hype about how great IPv6 is and how one will get better security > with IPv6. Unfortunately, that myth has also harmed the overall IPv6 > deployment effort, as people look more closely and come to understand > that deploying IPv6 doesn't automatically/easily yield improved > security. > > We all know the reality of security is very different and much more > complicated/nuanced then just saying "use IPsec". > > Consider: > > IPsec by itself (with no key management) is close to useless. The > average person cannot configure static keys, so the result is (in > effect) a useless mandate (as a broad mandate for ALL nodes). > > What applications actually make use of IPsec for security? A lot fewer > than one might think. For many IPv6 devices/nodes, if one actually > looks at the applications that will be used on them, they do not use > IPsec today for security. And, there are strong/compelling arguments > for why IPsec is not the best security solution for many applications. > Thus, requiring IPsec is pointless. > > To be truly useful, we (of course) need key management. If we want to > mandate key management, the stakes go way up. IKEv1/v2 is not a small > implementation effort. And, we are now in the funny situation where > IKEv1 has been implemented, but due to shortcomings, IKEv2 has already > been developed. IKEv2 has been out for over 2 years, but > implementations are not widespread yet. So, would we mandate IKEv1 > (which is obsoleted and has documented issues), or do we mandate > IKEv2, even though it is clear it is not widely available yet? > > IMO, we should drop the MUST language surrounding IPsec. The technical > justification for making it MUST are simply not compelling. It seems > to me that the MUST is there primarily for historical/marketing > reasons. > > Note that dropping the MUST will not mean people stop implementing > IPsec, where there is compelling benefit. Indeed, note that the USG > has already moved away from IKEv1 and has strongly signalled that it > will require IKEv2 going forward. So I am confident that IPsec (and > IKE) will get implemented going forward. > > But there is no reason why IPsec should be mandated in devices where > it is clear (based on the function/purpose of the device) that IPsec > will in fact not actually be used. > > As a general "node requirement", SHOULD is the right level, not MUST. > > Thomas > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 09:59:37 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF6F28C421; Tue, 26 Feb 2008 09:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMenF3aQ2DW1; Tue, 26 Feb 2008 09:59:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2AFA28C726; Tue, 26 Feb 2008 09:58:24 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D0628C3F0 for ; Tue, 26 Feb 2008 09:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcYfXkLXQvHT for ; Tue, 26 Feb 2008 09:58:22 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 04C563A6837 for ; Tue, 26 Feb 2008 09:57:21 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1QHun53029945; Tue, 26 Feb 2008 19:57:10 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 19:57:09 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 11:57:07 -0600 Received: from 10.138.85.208 ([10.138.85.208]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Feb 2008 17:57:07 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 26 Feb 2008 11:58:16 -0600 Subject: Re: Making IPsec *not* mandatory in Node Requirement From: Basavaraj Patil To: Thomas Narten , Nobuo OKABE Message-ID: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4oSlqZ7s2U+SUEdylSAARJNUNiA== In-Reply-To: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> Mime-version: 1.0 X-OriginalArrivalTime: 26 Feb 2008 17:57:07.0089 (UTC) FILETIME=[0057F010:01C878A1] X-Nokia-AV: Clean Cc: John Loughney , ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I agree with Thomas about his views on IPsec being a mandatory and default component of the IPv6 stack. Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec for securing the signaling. This has lead to complexity of the protocol and not really helped either in adoption or implementation. IPsec based security is an overkill for Mobile IPv6 and illustrates the point that you do not have to use it simply because it happens to be an integral part of IPv6. -Basavaraj On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: > IMO, we need to get over the idea that IPsec is mandatory in > IPv6. Really. Or that mandating IPsec is actually useful in practice. > > It is the case that mandating IPsec as part of IPv6 has contributed to > the hype about how great IPv6 is and how one will get better security > with IPv6. Unfortunately, that myth has also harmed the overall IPv6 > deployment effort, as people look more closely and come to understand > that deploying IPv6 doesn't automatically/easily yield improved > security. > > We all know the reality of security is very different and much more > complicated/nuanced then just saying "use IPsec". > > Consider: > > IPsec by itself (with no key management) is close to useless. The > average person cannot configure static keys, so the result is (in > effect) a useless mandate (as a broad mandate for ALL nodes). > > What applications actually make use of IPsec for security? A lot fewer > than one might think. For many IPv6 devices/nodes, if one actually > looks at the applications that will be used on them, they do not use > IPsec today for security. And, there are strong/compelling arguments > for why IPsec is not the best security solution for many applications. > Thus, requiring IPsec is pointless. > > To be truly useful, we (of course) need key management. If we want to > mandate key management, the stakes go way up. IKEv1/v2 is not a small > implementation effort. And, we are now in the funny situation where > IKEv1 has been implemented, but due to shortcomings, IKEv2 has already > been developed. IKEv2 has been out for over 2 years, but > implementations are not widespread yet. So, would we mandate IKEv1 > (which is obsoleted and has documented issues), or do we mandate > IKEv2, even though it is clear it is not widely available yet? > > IMO, we should drop the MUST language surrounding IPsec. The technical > justification for making it MUST are simply not compelling. It seems > to me that the MUST is there primarily for historical/marketing > reasons. > > Note that dropping the MUST will not mean people stop implementing > IPsec, where there is compelling benefit. Indeed, note that the USG > has already moved away from IKEv1 and has strongly signalled that it > will require IKEv2 going forward. So I am confident that IPsec (and > IKE) will get implemented going forward. > > But there is no reason why IPsec should be mandated in devices where > it is clear (based on the function/purpose of the device) that IPsec > will in fact not actually be used. > > As a general "node requirement", SHOULD is the right level, not MUST. > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 10:02:02 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A215928C743; Tue, 26 Feb 2008 10:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM0GMuajzCsR; Tue, 26 Feb 2008 10:02:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032443A6A08; Tue, 26 Feb 2008 10:02:01 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADB03A6A08 for ; Tue, 26 Feb 2008 10:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm3olVCMLFnU for ; Tue, 26 Feb 2008 10:01:58 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 162763A6837 for ; Tue, 26 Feb 2008 10:01:57 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1QI1hva029177; Tue, 26 Feb 2008 20:01:45 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 20:01:29 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 12:01:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 12:00:33 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A010C475A@daebe104.NOE.Nokia.com> In-Reply-To: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4k0W/ZcXSG98WS8OHOTaJ2eTJjgADQ2DA References: <4B11770E-DE43-46AD-97F2-CB91C2299EB0@cisco.com> <20080226.165331.14652621.nov@tahi.org> <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> From: To: , X-OriginalArrivalTime: 26 Feb 2008 18:01:23.0195 (UTC) FILETIME=[98FE9CB0:01C878A1] X-Nokia-AV: Clean Cc: ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thomas, >As a general "node requirement", SHOULD is the right level, not MUST. I veer to being somewhat conservative in this area. I don't think that we should be re-interpreting Standards-track RFCs in the Node Req document. I think that we can only refer to what the base standards track RFCs state, and provide some text to guide the reader. I still tend to think that IPSec is a good enabler to have, on a hw or sw platform, for example. Whether it is activiated or used is another story. Also, understanding the overall security solutions that should be used in different deployments are quite complicated, and can only get worse if certain solutions are not available. At a high-level, creating any IPv6 implementation without any security solutions is a problematic, IMO. If IBM, Nokia or any other company would sell an IPv6 stack as part of a solution that provided no security, I don't think that would be very good or useful. I think some aspects of security needs to be a MUST as part of an overall IPv6 stack, however, there are many choices and parts of a potential solution. I think we should look at what the overall IETF concensus for a minimum requirement would be. My question is, does the IETF have any such consensus? John >-----Original Message----- >From: ext Thomas Narten [mailto:narten@us.ibm.com] >Sent: 26 February, 2008 08:19 >To: Nobuo OKABE >Cc: alain_durand@cable.comcast.com; Loughney John >(Nokia-OCTO/PaloAlto); ipv6@ietf.org; fred@cisco.com >Subject: Re: Making IPsec *not* mandatory in Node Requirement > >IMO, we need to get over the idea that IPsec is mandatory in >IPv6. Really. Or that mandating IPsec is actually useful in practice. > >It is the case that mandating IPsec as part of IPv6 has >contributed to the hype about how great IPv6 is and how one >will get better security with IPv6. Unfortunately, that myth >has also harmed the overall IPv6 deployment effort, as people >look more closely and come to understand that deploying IPv6 >doesn't automatically/easily yield improved security. > >We all know the reality of security is very different and much >more complicated/nuanced then just saying "use IPsec". > >Consider: > >IPsec by itself (with no key management) is close to useless. >The average person cannot configure static keys, so the result is (in >effect) a useless mandate (as a broad mandate for ALL nodes). > >What applications actually make use of IPsec for security? A >lot fewer than one might think. For many IPv6 devices/nodes, >if one actually looks at the applications that will be used on >them, they do not use IPsec today for security. And, there are >strong/compelling arguments for why IPsec is not the best >security solution for many applications. >Thus, requiring IPsec is pointless. > >To be truly useful, we (of course) need key management. If we >want to mandate key management, the stakes go way up. IKEv1/v2 >is not a small implementation effort. And, we are now in the >funny situation where >IKEv1 has been implemented, but due to shortcomings, IKEv2 has >already been developed. IKEv2 has been out for over 2 years, >but implementations are not widespread yet. So, would we >mandate IKEv1 (which is obsoleted and has documented issues), >or do we mandate IKEv2, even though it is clear it is not >widely available yet? > >IMO, we should drop the MUST language surrounding IPsec. The >technical justification for making it MUST are simply not >compelling. It seems to me that the MUST is there primarily >for historical/marketing reasons. > >Note that dropping the MUST will not mean people stop >implementing IPsec, where there is compelling benefit. Indeed, >note that the USG has already moved away from IKEv1 and has >strongly signalled that it will require IKEv2 going forward. >So I am confident that IPsec (and >IKE) will get implemented going forward. > >But there is no reason why IPsec should be mandated in devices >where it is clear (based on the function/purpose of the >device) that IPsec will in fact not actually be used. > >As a general "node requirement", SHOULD is the right level, not MUST. > >Thomas > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 10:13:34 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2358A28C662; Tue, 26 Feb 2008 10:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKyx3SJ9GC4e; Tue, 26 Feb 2008 10:13:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8CE28C367; Tue, 26 Feb 2008 10:13:31 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C5F3A6917 for ; Tue, 26 Feb 2008 10:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fHdUpbs4xC6 for ; Tue, 26 Feb 2008 10:13:28 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by core3.amsl.com (Postfix) with ESMTP id D1B4228C42C for ; Tue, 26 Feb 2008 10:13:10 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so2856758uge.46 for ; Tue, 26 Feb 2008 10:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=t3jnV/sRKRe6hIAgWtm46PZud2jYCNfWaptionrRM7E=; b=NtWyT9NszKkudHqV42GHdELFYjZzM2yl8DGwOthKcptSmCk74oKKn+DZkEu+LEFDlV/aTHDV65LPK0enQQ0HrtxEWDfToDEw1BljJgRxX8DX2zLgIyNuKsBhn927za5enn9cyJGO9dQ3o5XiJEvFgCE7bTMYZ6khX1p+NGpoLME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=k41mbwNHovD03xDZJeBgS6bPwe6P9OPgj+Lsk6XAK2wad8y8o017lHIl2uk0cHjtlgfxf02jlW3ZlLOxZNFN3t/rayNCrSp9dxjnDE+n7YOl47CvUFPQiI06027HO5EHq281WUxTt5m/AMBb6IPAJvNSfe3xSiFfbbEQiD+JvmE= Received: by 10.142.187.2 with SMTP id k2mr4074241wff.25.1204049582444; Tue, 26 Feb 2008 10:13:02 -0800 (PST) Received: by 10.143.164.14 with HTTP; Tue, 26 Feb 2008 10:13:02 -0800 (PST) Message-ID: <77ead0ec0802261013k2d13ba5fr9f436b0c90063ea7@mail.gmail.com> Date: Tue, 26 Feb 2008 10:13:02 -0800 From: "Vishwas Manral" To: "Basavaraj Patil" Subject: Re: Making IPsec *not* mandatory in Node Requirement In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> Cc: Thomas Narten , John Loughney , ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Basavraj, But isn't that something IPsec needs to improve on. We already have efforts like BTNS with "connection latching" in IPsec which may help to ease the load on the end devices, which seems to have been the main issue raised. Thanks, Vishwas On Tue, Feb 26, 2008 at 9:58 AM, Basavaraj Patil wrote: > > I agree with Thomas about his views on IPsec being a mandatory and default > component of the IPv6 stack. > Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec for > securing the signaling. This has lead to complexity of the protocol and not > really helped either in adoption or implementation. > IPsec based security is an overkill for Mobile IPv6 and illustrates the > point that you do not have to use it simply because it happens to be an > integral part of IPv6. > > -Basavaraj > > > > > On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: > > > IMO, we need to get over the idea that IPsec is mandatory in > > IPv6. Really. Or that mandating IPsec is actually useful in practice. > > > > It is the case that mandating IPsec as part of IPv6 has contributed to > > the hype about how great IPv6 is and how one will get better security > > with IPv6. Unfortunately, that myth has also harmed the overall IPv6 > > deployment effort, as people look more closely and come to understand > > that deploying IPv6 doesn't automatically/easily yield improved > > security. > > > > We all know the reality of security is very different and much more > > complicated/nuanced then just saying "use IPsec". > > > > Consider: > > > > IPsec by itself (with no key management) is close to useless. The > > average person cannot configure static keys, so the result is (in > > effect) a useless mandate (as a broad mandate for ALL nodes). > > > > What applications actually make use of IPsec for security? A lot fewer > > than one might think. For many IPv6 devices/nodes, if one actually > > looks at the applications that will be used on them, they do not use > > IPsec today for security. And, there are strong/compelling arguments > > for why IPsec is not the best security solution for many applications. > > Thus, requiring IPsec is pointless. > > > > To be truly useful, we (of course) need key management. If we want to > > mandate key management, the stakes go way up. IKEv1/v2 is not a small > > implementation effort. And, we are now in the funny situation where > > IKEv1 has been implemented, but due to shortcomings, IKEv2 has already > > been developed. IKEv2 has been out for over 2 years, but > > implementations are not widespread yet. So, would we mandate IKEv1 > > (which is obsoleted and has documented issues), or do we mandate > > IKEv2, even though it is clear it is not widely available yet? > > > > IMO, we should drop the MUST language surrounding IPsec. The technical > > justification for making it MUST are simply not compelling. It seems > > to me that the MUST is there primarily for historical/marketing > > reasons. > > > > Note that dropping the MUST will not mean people stop implementing > > IPsec, where there is compelling benefit. Indeed, note that the USG > > has already moved away from IKEv1 and has strongly signalled that it > > will require IKEv2 going forward. So I am confident that IPsec (and > > IKE) will get implemented going forward. > > > > But there is no reason why IPsec should be mandated in devices where > > it is clear (based on the function/purpose of the device) that IPsec > > will in fact not actually be used. > > > > As a general "node requirement", SHOULD is the right level, not MUST. > > > > Thomas > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 10:20:31 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0954E3A6D14; Tue, 26 Feb 2008 10:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a1xNVniY8DK; Tue, 26 Feb 2008 10:20:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81C63A680E; Tue, 26 Feb 2008 10:20:29 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BF43A67F8 for ; Tue, 26 Feb 2008 10:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myCsGROYs1vr for ; Tue, 26 Feb 2008 10:20:25 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 5AA8E3A680E for ; Tue, 26 Feb 2008 10:20:25 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1QILhQo009406; Tue, 26 Feb 2008 12:21:49 -0600 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 20:20:11 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 12:20:09 -0600 Received: from 10.138.85.208 ([10.138.85.208]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Feb 2008 18:20:08 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 26 Feb 2008 12:21:20 -0600 Subject: Re: Making IPsec *not* mandatory in Node Requirement From: Basavaraj Patil To: ext Vishwas Manral Message-ID: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4pGJYoKknwOSXEdylSAARJNUNiA== In-Reply-To: <77ead0ec0802261013k2d13ba5fr9f436b0c90063ea7@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 26 Feb 2008 18:20:09.0259 (UTC) FILETIME=[382E57B0:01C878A4] X-Nokia-AV: Clean Cc: Thomas Narten , John Loughney , ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org It is not the load or processing that is the issue really which I think you are alluding to. It is just the complexity of integrating a protocol like Mobile IPv6 with IPsec and IKE/IKEv2. Mobile IPv6 signaling can be secured via simpler mechanisms. But because of the prevailing thinking that IPsec MUST be used as the security mechanism, we stuck with it and are lets say not too happy about it. -Basavaraj On 2/26/08 12:13 PM, "ext Vishwas Manral" wrote: > Hi Basavraj, > > But isn't that something IPsec needs to improve on. We already have > efforts like BTNS with "connection latching" in IPsec which may help > to ease the load on the end devices, which seems to have been the main > issue raised. > > Thanks, > Vishwas > > On Tue, Feb 26, 2008 at 9:58 AM, Basavaraj Patil > wrote: >> >> I agree with Thomas about his views on IPsec being a mandatory and default >> component of the IPv6 stack. >> Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec for >> securing the signaling. This has lead to complexity of the protocol and not >> really helped either in adoption or implementation. >> IPsec based security is an overkill for Mobile IPv6 and illustrates the >> point that you do not have to use it simply because it happens to be an >> integral part of IPv6. >> >> -Basavaraj >> >> >> >> >> On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: >> >>> IMO, we need to get over the idea that IPsec is mandatory in >>> IPv6. Really. Or that mandating IPsec is actually useful in practice. >>> >>> It is the case that mandating IPsec as part of IPv6 has contributed to >>> the hype about how great IPv6 is and how one will get better security >>> with IPv6. Unfortunately, that myth has also harmed the overall IPv6 >>> deployment effort, as people look more closely and come to understand >>> that deploying IPv6 doesn't automatically/easily yield improved >>> security. >>> >>> We all know the reality of security is very different and much more >>> complicated/nuanced then just saying "use IPsec". >>> >>> Consider: >>> >>> IPsec by itself (with no key management) is close to useless. The >>> average person cannot configure static keys, so the result is (in >>> effect) a useless mandate (as a broad mandate for ALL nodes). >>> >>> What applications actually make use of IPsec for security? A lot fewer >>> than one might think. For many IPv6 devices/nodes, if one actually >>> looks at the applications that will be used on them, they do not use >>> IPsec today for security. And, there are strong/compelling arguments >>> for why IPsec is not the best security solution for many applications. >>> Thus, requiring IPsec is pointless. >>> >>> To be truly useful, we (of course) need key management. If we want to >>> mandate key management, the stakes go way up. IKEv1/v2 is not a small >>> implementation effort. And, we are now in the funny situation where >>> IKEv1 has been implemented, but due to shortcomings, IKEv2 has already >>> been developed. IKEv2 has been out for over 2 years, but >>> implementations are not widespread yet. So, would we mandate IKEv1 >>> (which is obsoleted and has documented issues), or do we mandate >>> IKEv2, even though it is clear it is not widely available yet? >>> >>> IMO, we should drop the MUST language surrounding IPsec. The technical >>> justification for making it MUST are simply not compelling. It seems >>> to me that the MUST is there primarily for historical/marketing >>> reasons. >>> >>> Note that dropping the MUST will not mean people stop implementing >>> IPsec, where there is compelling benefit. Indeed, note that the USG >>> has already moved away from IKEv1 and has strongly signalled that it >>> will require IKEv2 going forward. So I am confident that IPsec (and >>> IKE) will get implemented going forward. >>> >>> But there is no reason why IPsec should be mandated in devices where >>> it is clear (based on the function/purpose of the device) that IPsec >>> will in fact not actually be used. >>> >>> As a general "node requirement", SHOULD is the right level, not MUST. >>> >>> Thomas >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 10:31:15 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92AB28C4A1; Tue, 26 Feb 2008 10:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.018 X-Spam-Level: X-Spam-Status: No, score=-102.018 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UydkxBt-XIhk; Tue, 26 Feb 2008 10:31:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8DD28C349; Tue, 26 Feb 2008 10:31:12 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7A128C349 for ; Tue, 26 Feb 2008 10:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdlRJHV5YTYK for ; Tue, 26 Feb 2008 10:31:10 -0800 (PST) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by core3.amsl.com (Postfix) with ESMTP id 0D5CC28C0FA for ; Tue, 26 Feb 2008 10:31:10 -0800 (PST) Received: from g5t0009.atlanta.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 91E1A30A7E; Tue, 26 Feb 2008 18:31:03 +0000 (UTC) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0009.atlanta.hp.com (Postfix) with ESMTP id 714AF30A81; Tue, 26 Feb 2008 18:31:03 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.1.251.1; Tue, 26 Feb 2008 18:30:11 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Tue, 26 Feb 2008 18:30:11 +0000 From: "Bound, Jim" To: "Dunn, Jeffrey H." , "Manfredi, Albert E" , Brian E Carpenter Date: Tue, 26 Feb 2008 18:30:11 +0000 Subject: RE: Updates to Node Requirements-bis Thread-Topic: Updates to Node Requirements-bis Thread-Index: Ach4DW2HKh0ui8lPSg+r5UITz4iNnAABIRyQAAXdnWAAHVVM8A== Message-ID: <831FE02B5345194BA8147EDEF5F133882966CD30@G3W0070.americas.hpqcorp.net> References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> <47C35B55.7040709@gmail.com> <0AC4B700F00DBB4C94F95727E0991414D83E88@IMCSRV7.MITRE.ORG> In-Reply-To: <0AC4B700F00DBB4C94F95727E0991414D83E88@IMCSRV7.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I concur with Jeffrey regarding the email objective to the IETF below. The IETF develops specifications and guidelines (being loose here with the term). Our role is to "not" standardize deployment practices. The market uses this SDO work here to define their deployment scenarios for their business. GM, Boeing, USG and DOD, Wal-Mart, British Telecom, SKT, Toyota, etc. are all businesses and they will adopt what is mandatory or not-mandatory to support their missions and goals. What the market does depend on from us in the IETF is interoperability across the specifications, though I would expand that to the capabilties of connectivity, interoperability, discovery, security, and end-to-end. However, if we can learn from the market for the case being node requirements, within this discussion, that is a prudent and useful exercise to pursue as an input data point to us, and John's position to us I think reflects this quite well. Regarding IPsec: IPv6 can restore the capability of end-to-end between two nodes without NAT methods being used, through globally routable addresses, which is required by several technology trends in the market (not enough address space with IPv4). Using IPsec encryption (the market will determine the PKI is my view) a user can encrypt/decrypt end-to-end their data below the IP header in the case where there is zero trust for any middle node within the end-to-end network path, and any edge distributed firewalls (my view of where they are headed at the secure edge) simply passes IPsec traffic through as a policy and trusts the IPsec connection. At Danvers, I think 1995, I was against IPsec being mandatory for IPv6 and the primary reason (not the only one I also liked SKIP and other issues :--)) was it was to much of a MUST to put on IPv6 development in the market at that time as an implementor at that time. I and others lost that debate in the IETF. Today it is different the "network stack s" to support IPv6 for the most part have all been developed within any commercial product (clearly more work is requiired above the network stack) I am aware of at this time. If IPsec is a MUST my view is that today most of it has been developed by most commercial products, and it does state from this SDO IPsec is required for proper secure operations at the IP Layer. Today I think it should be a MUST and for node requirements from the IETF view. For the market it will become a MUST product requirement or commercial products simply will loose to their competitors who do support IPsec, and that is how the free market economy should work, and the IETF should not try to influence that aspect of the market. My view is all enterprises should mandate IPsec and if they do there is nothing we can do about that in the IETF. But, we should make sure IPsec supports the IETF requirements we deem necessary for any protocol specification. /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Dunn, Jeffrey H. > Sent: Monday, February 25, 2008 11:28 PM > To: Manfredi, Albert E; Brian E Carpenter > Cc: ipv6@ietf.org > Subject: RE: Updates to Node Requirements-bis > > Colleagues, > > Although I do not speak for either DISA or NIST, I believe > that the spirit of Jeremy's request was that the > specifications (RFCs) required by the DISA and NIST documents > be considered for inclusion in the updated node requirements > document. I am working on he deltas between the NIST draft 1 > and 2, and the DISR. > > Best Regards, > > Jeffrey Dunn > Info Systems Eng., Lead > MITRE Corporation. > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Manfredi, Albert E > Sent: Monday, February 25, 2008 8:30 PM > To: Brian E Carpenter > Cc: ipv6@ietf.org > Subject: RE: Updates to Node Requirements-bis > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > To: Manfredi, Albert E > > > > I would agree that someone should reconcile, or at least > identify, > > > all the differences, although I don't know that it should be the > > > IETF. > > > The IETF's job is to make the Internet work better (RFC 3935) so we > > obviously have to give that priority. It would certainly be > useful to > > understand why the DISA and NIST profiles differ from the IETF's > > profile, but aligning with DISA and NIST shouldn't be a goal in > itself > > as far as I can see. > > Typically, the NIST requirements seem more stringent. My only > point is that if any explanation for differences is deemed > desirable, I would expect that DISA or NIST be the ones who > explain why these differences were introduced. I think we > agree. The IETF can only guess at reasons. > > > > Same applies to IKEv2. The IETF does not mandate its use, while > NIST > > > does. > > > > See RFC 4301 section 3.2 *last* paragraph. The problem is that the > > real world is slow to move to IKEv2. It's important to > describe what's > > real, I think. The NIST requirement is "interesting" given > the state > > of products. > > I-D 4294-bis says in Section 9.4: > > An implementation MUST support the manual configuration of the > security key and SPI. The SPI configuration is needed in order to > delineate between multiple keys. > > Key management SHOULD be supported. Examples of key management > systems include IKEv2 [RFC4306] and Kerberos; S/MIME and > TLS include > key management functions. > > Where key refresh, anti-replay features of AH and ESP, or on-demand > creation of Security Associations (SAs) is required, > automated keying > MUST be supported. > > So automatic key exchange is not considered mandatory by the > IETF in all cases, but it is mandatory in the NIST Profile. > At least, that's how I read that. > > > > My assumption is that this rationale, protection of routing > > > protocols, is why now NIST is mandating that routers support ESP, > > > now that AH has been demoted to a MAY. A brief > clarification would > > > be welcome. > > > > Would you want to ship a router that couldn't protect the network > > layer? > > Depends what you mean. A router located in a non-secure space > can be expected to protect the way it populates its routing > tables. That's about it, though. AH seemed a good way to do > that, but ESP, for the purpose of protecting RIPng or OSPFv3 > messages, should be fine too, I think. > > Expecting more than that seems like wishful thinking, IF the > routers are in non-secure spaces. Encypting spoofed messages > coming from non-secure hosts does not make these any more > secure. What would make these more secure is ESP > host-to-host, or ESP tunneled between security gateways. > > > > Another mandate in the NIST IPv6 Profile is that both > tunneling and > > > dual stack mechanisms be supported in Government networks. > > > That's an operational issue, not a node requirement. Would > you want to > > ship a stack that could support a dual stack but not use it > to tunnel? > > Yes. If I provide a special-purpose network that provides > dual-stack, why should I have the added burden of supporting > tunneling that I will never use? My preferred approach is to > not require features that won't be used, but allow them to be > added if necessary, in the future. This saves development > time and testing efforts. > > Bert > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 10:51:10 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148D228C738; Tue, 26 Feb 2008 10:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJifClZoOw79; Tue, 26 Feb 2008 10:51:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5900528C2BA; Tue, 26 Feb 2008 10:51:04 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED2928C2E1 for ; Tue, 26 Feb 2008 10:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKQA0CFKK-Jm for ; Tue, 26 Feb 2008 10:51:02 -0800 (PST) Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by core3.amsl.com (Postfix) with ESMTP id 2094128C1A2 for ; Tue, 26 Feb 2008 10:51:01 -0800 (PST) Received: from g4t0016.houston.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id AF1AF149F9; Tue, 26 Feb 2008 18:50:55 +0000 (UTC) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTP id 6693614C3D; Tue, 26 Feb 2008 18:50:55 +0000 (UTC) Received: from G3W0058.americas.hpqcorp.net (16.232.1.3) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.1.251.1; Tue, 26 Feb 2008 18:50:05 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0058.americas.hpqcorp.net ([16.232.1.3]) with mapi; Tue, 26 Feb 2008 18:50:04 +0000 From: "Bound, Jim" To: Basavaraj Patil , Thomas Narten , Nobuo OKABE Date: Tue, 26 Feb 2008 18:50:04 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4oSlqZ7s2U+SUEdylSAARJNUNiAABxsSA Message-ID: <831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: John Loughney , "ipv6@ietf.org" , "fred@cisco.com" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org For defense in depth scenarios I disagree in the case for the MN to verify with the HA. But I see your point. /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Basavaraj Patil > Sent: Tuesday, February 26, 2008 12:58 PM > To: Thomas Narten; Nobuo OKABE > Cc: John Loughney; ipv6@ietf.org; fred@cisco.com > Subject: Re: Making IPsec *not* mandatory in Node Requirement > > > I agree with Thomas about his views on IPsec being a > mandatory and default component of the IPv6 stack. > Because of this belief, Mobile IPv6 (RFC3775) design relied > on IPsec for securing the signaling. This has lead to > complexity of the protocol and not really helped either in > adoption or implementation. > IPsec based security is an overkill for Mobile IPv6 and > illustrates the point that you do not have to use it simply > because it happens to be an integral part of IPv6. > > -Basavaraj > > > On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: > > > IMO, we need to get over the idea that IPsec is mandatory in IPv6. > > Really. Or that mandating IPsec is actually useful in practice. > > > > It is the case that mandating IPsec as part of IPv6 has > contributed to > > the hype about how great IPv6 is and how one will get > better security > > with IPv6. Unfortunately, that myth has also harmed the > overall IPv6 > > deployment effort, as people look more closely and come to > understand > > that deploying IPv6 doesn't automatically/easily yield improved > > security. > > > > We all know the reality of security is very different and much more > > complicated/nuanced then just saying "use IPsec". > > > > Consider: > > > > IPsec by itself (with no key management) is close to useless. The > > average person cannot configure static keys, so the result is (in > > effect) a useless mandate (as a broad mandate for ALL nodes). > > > > What applications actually make use of IPsec for security? > A lot fewer > > than one might think. For many IPv6 devices/nodes, if one actually > > looks at the applications that will be used on them, they > do not use > > IPsec today for security. And, there are strong/compelling > arguments > > for why IPsec is not the best security solution for many > applications. > > Thus, requiring IPsec is pointless. > > > > To be truly useful, we (of course) need key management. If > we want to > > mandate key management, the stakes go way up. IKEv1/v2 is > not a small > > implementation effort. And, we are now in the funny situation where > > IKEv1 has been implemented, but due to shortcomings, IKEv2 > has already > > been developed. IKEv2 has been out for over 2 years, but > > implementations are not widespread yet. So, would we mandate IKEv1 > > (which is obsoleted and has documented issues), or do we mandate > > IKEv2, even though it is clear it is not widely available yet? > > > > IMO, we should drop the MUST language surrounding IPsec. > The technical > > justification for making it MUST are simply not compelling. > It seems > > to me that the MUST is there primarily for historical/marketing > > reasons. > > > > Note that dropping the MUST will not mean people stop implementing > > IPsec, where there is compelling benefit. Indeed, note that the USG > > has already moved away from IKEv1 and has strongly > signalled that it > > will require IKEv2 going forward. So I am confident that IPsec (and > > IKE) will get implemented going forward. > > > > But there is no reason why IPsec should be mandated in > devices where > > it is clear (based on the function/purpose of the device) > that IPsec > > will in fact not actually be used. > > > > As a general "node requirement", SHOULD is the right level, > not MUST. > > > > Thomas > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 10:58:08 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF0528C77E; Tue, 26 Feb 2008 10:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq3gXhDw5Kzi; Tue, 26 Feb 2008 10:58:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72F93A6CC8; Tue, 26 Feb 2008 10:58:01 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B343A67CC for ; Tue, 26 Feb 2008 10:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7FWb5opn0Iq for ; Tue, 26 Feb 2008 10:57:59 -0800 (PST) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id E1E6C28C203 for ; Tue, 26 Feb 2008 10:57:23 -0800 (PST) Received: from g4t0014.houston.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id B281A240D8; Tue, 26 Feb 2008 18:57:17 +0000 (UTC) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTP id A8FE824BAE; Tue, 26 Feb 2008 18:57:17 +0000 (UTC) Received: from G3W0629.americas.hpqcorp.net (16.233.58.78) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.1.251.1; Tue, 26 Feb 2008 18:56:22 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0629.americas.hpqcorp.net ([16.233.58.78]) with mapi; Tue, 26 Feb 2008 18:56:22 +0000 From: "Bound, Jim" To: Basavaraj Patil , ext Vishwas Manral Date: Tue, 26 Feb 2008 18:56:22 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4pGJYoKknwOSXEdylSAARJNUNiAABEBTA Message-ID: <831FE02B5345194BA8147EDEF5F133882966CDC0@G3W0070.americas.hpqcorp.net> References: <77ead0ec0802261013k2d13ba5fr9f436b0c90063ea7@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Thomas Narten , John Loughney , "ipv6@ietf.org" , "fred@cisco.com" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I don't see the implementation complexity as supporting rationale but would be open to hearing the issues of signaling maybe? MIPv6, IPsec, and IKEv2 (I also think it was the market mandate IKEv2 right now) do need to be cohesive wihin an implementation but clearly different discrete components with a network stack software design The approach or at least the way I believe it should be engineered in a network stack I think the integration is not a problem. I don't think we should not require a function in the IETF because it is percieved that "integrating a protocol like Mobile IPv6 with IPsec and IKE/IKEv2" is to complex because I would disagree with that assumption. /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Basavaraj Patil > Sent: Tuesday, February 26, 2008 1:21 PM > To: ext Vishwas Manral > Cc: Thomas Narten; John Loughney; ipv6@ietf.org; fred@cisco.com > Subject: Re: Making IPsec *not* mandatory in Node Requirement > > > It is not the load or processing that is the issue really > which I think you are alluding to. It is just the complexity > of . > Mobile IPv6 signaling can be secured via simpler mechanisms. > But because of the prevailing thinking that IPsec MUST be > used as the security mechanism, we stuck with it and are lets > say not too happy about it. > > -Basavaraj > > > On 2/26/08 12:13 PM, "ext Vishwas Manral" > wrote: > > > Hi Basavraj, > > > > But isn't that something IPsec needs to improve on. We already have > > efforts like BTNS with "connection latching" in IPsec which > may help > > to ease the load on the end devices, which seems to have > been the main > > issue raised. > > > > Thanks, > > Vishwas > > > > On Tue, Feb 26, 2008 at 9:58 AM, Basavaraj Patil > > wrote: > >> > >> I agree with Thomas about his views on IPsec being a > mandatory and > >> default component of the IPv6 stack. > >> Because of this belief, Mobile IPv6 (RFC3775) design > relied on IPsec > >> for securing the signaling. This has lead to complexity of the > >> protocol and not really helped either in adoption or > implementation. > >> IPsec based security is an overkill for Mobile IPv6 and > illustrates > >> the point that you do not have to use it simply because > it happens > >> to be an integral part of IPv6. > >> > >> -Basavaraj > >> > >> > >> > >> > >> On 2/26/08 10:18 AM, "ext Thomas Narten" > wrote: > >> > >>> IMO, we need to get over the idea that IPsec is mandatory > in IPv6. > >>> Really. Or that mandating IPsec is actually useful in practice. > >>> > >>> It is the case that mandating IPsec as part of IPv6 has > contributed > >>> to the hype about how great IPv6 is and how one will get better > >>> security with IPv6. Unfortunately, that myth has also harmed the > >>> overall IPv6 deployment effort, as people look more > closely and come > >>> to understand that deploying IPv6 doesn't > automatically/easily yield > >>> improved security. > >>> > >>> We all know the reality of security is very different and > much more > >>> complicated/nuanced then just saying "use IPsec". > >>> > >>> Consider: > >>> > >>> IPsec by itself (with no key management) is close to useless. The > >>> average person cannot configure static keys, so the result is (in > >>> effect) a useless mandate (as a broad mandate for ALL nodes). > >>> > >>> What applications actually make use of IPsec for security? A lot > >>> fewer than one might think. For many IPv6 devices/nodes, if one > >>> actually looks at the applications that will be used on > them, they > >>> do not use IPsec today for security. And, there are > >>> strong/compelling arguments for why IPsec is not the best > security solution for many applications. > >>> Thus, requiring IPsec is pointless. > >>> > >>> To be truly useful, we (of course) need key management. > If we want > >>> to mandate key management, the stakes go way up. IKEv1/v2 > is not a > >>> small implementation effort. And, we are now in the funny > situation > >>> where > >>> IKEv1 has been implemented, but due to shortcomings, IKEv2 has > >>> already been developed. IKEv2 has been out for over 2 years, but > >>> implementations are not widespread yet. So, would we > mandate IKEv1 > >>> (which is obsoleted and has documented issues), or do we mandate > >>> IKEv2, even though it is clear it is not widely available yet? > >>> > >>> IMO, we should drop the MUST language surrounding IPsec. The > >>> technical justification for making it MUST are simply not > >>> compelling. It seems to me that the MUST is there primarily for > >>> historical/marketing reasons. > >>> > >>> Note that dropping the MUST will not mean people stop > implementing > >>> IPsec, where there is compelling benefit. Indeed, note > that the USG > >>> has already moved away from IKEv1 and has strongly > signalled that it > >>> will require IKEv2 going forward. So I am confident that > IPsec (and > >>> IKE) will get implemented going forward. > >>> > >>> But there is no reason why IPsec should be mandated in > devices where > >>> it is clear (based on the function/purpose of the device) > that IPsec > >>> will in fact not actually be used. > >>> > >>> As a general "node requirement", SHOULD is the right > level, not MUST. > >>> > >>> Thomas > >>> > -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>> Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >>> > -------------------------------------------------------------------- > >> > >> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list ipv6@ietf.org > Administrative > >> Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 11:10:22 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBBD28C751; Tue, 26 Feb 2008 11:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ana353XzU+KR; Tue, 26 Feb 2008 11:10:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A259E28C27F; Tue, 26 Feb 2008 11:10:18 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CB428C20F for ; Tue, 26 Feb 2008 11:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W54P4z0GXP1 for ; Tue, 26 Feb 2008 11:10:16 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C766B28C27F for ; Tue, 26 Feb 2008 11:10:15 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2008 20:10:09 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1QJA6wN007008; Tue, 26 Feb 2008 20:10:06 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1QJA3XL024356; Tue, 26 Feb 2008 19:10:03 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 20:10:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 20:11:42 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> In-Reply-To: <831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4oSlqZ7s2U+SUEdylSAARJNUNiAABxsSAAABSjHA= References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> <831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> From: "Julien Abeille (jabeille)" To: "Bound, Jim" , "Basavaraj Patil" , "Thomas Narten" , "Nobuo OKABE" X-OriginalArrivalTime: 26 Feb 2008 19:10:03.0627 (UTC) FILETIME=[30F6A3B0:01C878AB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6460; t=1204053006; x=1204917006; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20Making=20IPsec=20*not*=20mandatory=20in =20Node=20Requirement |Sender:=20; bh=00Fj1bOl44I9C9YAXLRuzH4KFdF/oAU7Y9gLoddWmT8=; b=S0x8fN5ckSdTZwuUXxNG41SiPf81OzIT3r9/l0ppRXjAEXde4YU6Cm+m4k +L1pDZ6EI3qTI/E5rvupGhFctlz/GLrUpGMwWf2j6bVfY8gXjN2PMEsVgXa3 hVxgd5gsad; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: John Loughney , ipv6@ietf.org, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, To come back to constrained device, as I already mentionned on the list wit= hin 6lowpan, we are working on a draft which documents the cost of each fea= ture mandated by RFC4294, from an implementation perspective (target platfo= rm is 8bit microcontroller, few 10K ROM, few K RAM). I guess as soon as we = have results, this might help the discussion. To give a bit of insight on sensor industry, the market is highly fragmente= d in terms of technology. Most vendors have proprietary L3, sometimes propr= ietary L2, and there are a bunch of standards coming, like ZigBee, Z-Wave, = ISA, HART... One reason for people not to go for IPv6 is "Oh this is too big for a senso= r", also because they are not always familiar with IP. What I want to say is that this kind of question (do we mandate IPSec) is c= ritical for a domain which promises billions of device. Cheers, Julien = = Julien Abeill=E9 Software Engineer Technology Center jabeille@cisco.com Fax:+41 21 822 1604 Cisco Systems International S=E0rl Av. des Uttins 5 1180 Rolle Switzerland (FR) www.cisco.com This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient. Any review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by repl= y e-mail and delete all copies of this message. = -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bou= nd, Jim Sent: mardi 26 f=E9vrier 2008 19:50 To: Basavaraj Patil; Thomas Narten; Nobuo OKABE Cc: John Loughney; ipv6@ietf.org; Fred Baker (fred) Subject: RE: Making IPsec *not* mandatory in Node Requirement For defense in depth scenarios I disagree in the case for the MN to verify = with the HA. But I see your point. /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = > Of Basavaraj Patil > Sent: Tuesday, February 26, 2008 12:58 PM > To: Thomas Narten; Nobuo OKABE > Cc: John Loughney; ipv6@ietf.org; fred@cisco.com > Subject: Re: Making IPsec *not* mandatory in Node Requirement > > > I agree with Thomas about his views on IPsec being a mandatory and = > default component of the IPv6 stack. > Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec = > for securing the signaling. This has lead to complexity of the = > protocol and not really helped either in adoption or implementation. > IPsec based security is an overkill for Mobile IPv6 and illustrates = > the point that you do not have to use it simply because it happens to = > be an integral part of IPv6. > > -Basavaraj > > > On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: > > > IMO, we need to get over the idea that IPsec is mandatory in IPv6. > > Really. Or that mandating IPsec is actually useful in practice. > > > > It is the case that mandating IPsec as part of IPv6 has > contributed to > > the hype about how great IPv6 is and how one will get > better security > > with IPv6. Unfortunately, that myth has also harmed the > overall IPv6 > > deployment effort, as people look more closely and come to > understand > > that deploying IPv6 doesn't automatically/easily yield improved = > > security. > > > > We all know the reality of security is very different and much more = > > complicated/nuanced then just saying "use IPsec". > > > > Consider: > > > > IPsec by itself (with no key management) is close to useless. The = > > average person cannot configure static keys, so the result is (in > > effect) a useless mandate (as a broad mandate for ALL nodes). > > > > What applications actually make use of IPsec for security? > A lot fewer > > than one might think. For many IPv6 devices/nodes, if one actually = > > looks at the applications that will be used on them, they > do not use > > IPsec today for security. And, there are strong/compelling > arguments > > for why IPsec is not the best security solution for many > applications. > > Thus, requiring IPsec is pointless. > > > > To be truly useful, we (of course) need key management. If > we want to > > mandate key management, the stakes go way up. IKEv1/v2 is > not a small > > implementation effort. And, we are now in the funny situation where > > IKEv1 has been implemented, but due to shortcomings, IKEv2 > has already > > been developed. IKEv2 has been out for over 2 years, but = > > implementations are not widespread yet. So, would we mandate IKEv1 = > > (which is obsoleted and has documented issues), or do we mandate = > > IKEv2, even though it is clear it is not widely available yet? > > > > IMO, we should drop the MUST language surrounding IPsec. > The technical > > justification for making it MUST are simply not compelling. > It seems > > to me that the MUST is there primarily for historical/marketing = > > reasons. > > > > Note that dropping the MUST will not mean people stop implementing = > > IPsec, where there is compelling benefit. Indeed, note that the USG = > > has already moved away from IKEv1 and has strongly > signalled that it > > will require IKEv2 going forward. So I am confident that IPsec (and > > IKE) will get implemented going forward. > > > > But there is no reason why IPsec should be mandated in > devices where > > it is clear (based on the function/purpose of the device) > that IPsec > > will in fact not actually be used. > > > > As a general "node requirement", SHOULD is the right level, > not MUST. > > > > Thomas > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative = > > Requests: http://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 11:14:03 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7CA28C40F; Tue, 26 Feb 2008 11:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1yES60M+gLX; Tue, 26 Feb 2008 11:14:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7625B3A6A21; Tue, 26 Feb 2008 11:14:01 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6E828C1D4 for ; Tue, 26 Feb 2008 11:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APNqkhTdCM-b for ; Tue, 26 Feb 2008 11:13:59 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D6AD73A6878 for ; Tue, 26 Feb 2008 11:13:58 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1QJDh4N032702; Tue, 26 Feb 2008 21:13:46 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 21:13:44 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 13:13:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 13:12:57 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4oSlqZ7s2U+SUEdylSAARJNUNiAABxsSAAABSjHAAAHQjwA== References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> From: To: , , , , X-OriginalArrivalTime: 26 Feb 2008 19:13:43.0608 (UTC) FILETIME=[B4151380:01C878AB] X-Nokia-AV: Clean Cc: ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Julien and Alain, My high-level question to you both is, for sensors and set-top boxes - do you feel that you do not need security for any reason? Is this a long-term issue or a short-term issue. I can't really think of a reason why security would not be an issue, but I could be wrong. John >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = >Behalf Of ext Julien Abeille (jabeille) >Sent: 26 February, 2008 11:12 >To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas = >Narten; Nobuo OKABE >Cc: Loughney John (Nokia-OCTO/PaloAlto); ipv6@ietf.org; Fred = >Baker (fred) >Subject: RE: Making IPsec *not* mandatory in Node Requirement > >Hi all, > >To come back to constrained device, as I already mentionned on = >the list within 6lowpan, we are working on a draft which = >documents the cost of each feature mandated by RFC4294, from = >an implementation perspective (target platform is 8bit = >microcontroller, few 10K ROM, few K RAM). I guess as soon as = >we have results, this might help the discussion. > >To give a bit of insight on sensor industry, the market is = >highly fragmented in terms of technology. Most vendors have = >proprietary L3, sometimes proprietary L2, and there are a = >bunch of standards coming, like ZigBee, Z-Wave, ISA, HART... >One reason for people not to go for IPv6 is "Oh this is too = >big for a sensor", also because they are not always familiar with IP. > >What I want to say is that this kind of question (do we = >mandate IPSec) is critical for a domain which promises = >billions of device. > >Cheers, >Julien > > > = > = >Julien Abeill=E9 >Software Engineer >Technology Center >jabeille@cisco.com >Fax:+41 21 822 1604 >Cisco Systems International S=E0rl >Av. des Uttins 5 >1180 Rolle >Switzerland (FR) >www.cisco.com > > >This e-mail may contain confidential and privileged material = >for the sole use of the intended recipient. Any review, use, = >distribution or disclosure by others is strictly prohibited. = >If you are not the intended recipient (or authorized to = >receive for the recipient), please contact the sender by reply = >e-mail and delete all copies of this message. > = > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = >Behalf Of Bound, Jim >Sent: mardi 26 f=E9vrier 2008 19:50 >To: Basavaraj Patil; Thomas Narten; Nobuo OKABE >Cc: John Loughney; ipv6@ietf.org; Fred Baker (fred) >Subject: RE: Making IPsec *not* mandatory in Node Requirement > >For defense in depth scenarios I disagree in the case for the = >MN to verify with the HA. But I see your point. >/jim > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = >> Of Basavaraj Patil >> Sent: Tuesday, February 26, 2008 12:58 PM >> To: Thomas Narten; Nobuo OKABE >> Cc: John Loughney; ipv6@ietf.org; fred@cisco.com >> Subject: Re: Making IPsec *not* mandatory in Node Requirement >> >> >> I agree with Thomas about his views on IPsec being a mandatory and = >> default component of the IPv6 stack. >> Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec = >> for securing the signaling. This has lead to complexity of the = >> protocol and not really helped either in adoption or implementation. >> IPsec based security is an overkill for Mobile IPv6 and illustrates = >> the point that you do not have to use it simply because it = >happens to = >> be an integral part of IPv6. >> >> -Basavaraj >> >> >> On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: >> >> > IMO, we need to get over the idea that IPsec is mandatory in IPv6. >> > Really. Or that mandating IPsec is actually useful in practice. >> > >> > It is the case that mandating IPsec as part of IPv6 has >> contributed to >> > the hype about how great IPv6 is and how one will get >> better security >> > with IPv6. Unfortunately, that myth has also harmed the >> overall IPv6 >> > deployment effort, as people look more closely and come to >> understand >> > that deploying IPv6 doesn't automatically/easily yield improved = >> > security. >> > >> > We all know the reality of security is very different and = >much more = >> > complicated/nuanced then just saying "use IPsec". >> > >> > Consider: >> > >> > IPsec by itself (with no key management) is close to useless. The = >> > average person cannot configure static keys, so the result is (in >> > effect) a useless mandate (as a broad mandate for ALL nodes). >> > >> > What applications actually make use of IPsec for security? >> A lot fewer >> > than one might think. For many IPv6 devices/nodes, if one actually = >> > looks at the applications that will be used on them, they >> do not use >> > IPsec today for security. And, there are strong/compelling >> arguments >> > for why IPsec is not the best security solution for many >> applications. >> > Thus, requiring IPsec is pointless. >> > >> > To be truly useful, we (of course) need key management. If >> we want to >> > mandate key management, the stakes go way up. IKEv1/v2 is >> not a small >> > implementation effort. And, we are now in the funny situation where >> > IKEv1 has been implemented, but due to shortcomings, IKEv2 >> has already >> > been developed. IKEv2 has been out for over 2 years, but = >> > implementations are not widespread yet. So, would we mandate IKEv1 = >> > (which is obsoleted and has documented issues), or do we mandate = >> > IKEv2, even though it is clear it is not widely available yet? >> > >> > IMO, we should drop the MUST language surrounding IPsec. >> The technical >> > justification for making it MUST are simply not compelling. >> It seems >> > to me that the MUST is there primarily for historical/marketing = >> > reasons. >> > >> > Note that dropping the MUST will not mean people stop implementing = >> > IPsec, where there is compelling benefit. Indeed, note = >that the USG = >> > has already moved away from IKEv1 and has strongly >> signalled that it >> > will require IKEv2 going forward. So I am confident that IPsec (and >> > IKE) will get implemented going forward. >> > >> > But there is no reason why IPsec should be mandated in >> devices where >> > it is clear (based on the function/purpose of the device) >> that IPsec >> > will in fact not actually be used. >> > >> > As a general "node requirement", SHOULD is the right level, >> not MUST. >> > >> > Thomas >> > = >-------------------------------------------------------------------- >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> > Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> > = >-------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 11:26:45 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2630E28C4A3; Tue, 26 Feb 2008 11:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfx0k-C3+IwV; Tue, 26 Feb 2008 11:26:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912093A6C16; Tue, 26 Feb 2008 11:26:43 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C3028C32C for ; Tue, 26 Feb 2008 11:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNBEKk-T6Avn for ; Tue, 26 Feb 2008 11:26:41 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 486E33A6B1A for ; Tue, 26 Feb 2008 11:26:40 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2008 20:26:33 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1QJQXlM005510; Tue, 26 Feb 2008 20:26:33 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1QJQXXL028905; Tue, 26 Feb 2008 19:26:33 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 20:26:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 20:28:12 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4oSlqZ7s2U+SUEdylSAARJNUNiAABxsSAAABSjHAAAHQjwAAAVViw References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> From: "Julien Abeille (jabeille)" To: , , , , X-OriginalArrivalTime: 26 Feb 2008 19:26:33.0191 (UTC) FILETIME=[7ECA1F70:01C878AD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9295; t=1204053993; x=1204917993; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20Making=20IPsec=20*not*=20mandatory=20in =20Node=20Requirement |Sender:=20; bh=dJGM1CQJoc+4Pfhrbp5st7PQ3P09pRl5BZo2IYPsnmY=; b=PLeXOuXAz9jckAZAc/YXa5f6BbgI6KWcSvYWZLxZiCxrciJ5bCsXBUa8H5 59+bTTjDB305HKzk8OzKNiH/D2w2PlAQa5U8kqrUXLRN1qfiPsTNz+ARJVeJ 0hu6yv/E7I; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipv6@ietf.org, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi John, Regarding sensors, - some applications (e.g. sensors for process control in factories) require= strong security, but dedicated security mechanism are used (in ISA standar= d for industrial automation as an example), the main difference with IPSec = being the importance of the "lightweigt" requirement. A security mechanism = and associated algorithms for such sensors might use much less processing p= ower, memory... than standard IP mechanisms - some applications might not require any security, e.g. a light sensor in = your flat might not need it and not implement it, also due to the very low = cost of the sensor. Cheers, John = = Julien Abeill=E9 Software Engineer Technology Center jabeille@cisco.com Fax:+41 21 822 1604 Cisco Systems International S=E0rl Av. des Uttins 5 1180 Rolle Switzerland (FR) www.cisco.com This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient. Any review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by repl= y e-mail and delete all copies of this message. = -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] = Sent: mardi 26 f=E9vrier 2008 20:13 To: Julien Abeille (jabeille); Jim.Bound@hp.com; basavaraj.patil@nsn.com; n= arten@us.ibm.com; nov@tahi.org Cc: ipv6@ietf.org; Fred Baker (fred) Subject: RE: Making IPsec *not* mandatory in Node Requirement Julien and Alain, My high-level question to you both is, for sensors and set-top boxes - do y= ou feel that you do not need security for any reason? Is this a long-term = issue or a short-term issue. I can't really think of a reason why security would not be an issue, but I = could be wrong. John >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = >ext Julien Abeille (jabeille) >Sent: 26 February, 2008 11:12 >To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas Narten; Nobuo = >OKABE >Cc: Loughney John (Nokia-OCTO/PaloAlto); ipv6@ietf.org; Fred Baker = >(fred) >Subject: RE: Making IPsec *not* mandatory in Node Requirement > >Hi all, > >To come back to constrained device, as I already mentionned on the list = >within 6lowpan, we are working on a draft which documents the cost of = >each feature mandated by RFC4294, from an implementation perspective = >(target platform is 8bit microcontroller, few 10K ROM, few K RAM). I = >guess as soon as we have results, this might help the discussion. > >To give a bit of insight on sensor industry, the market is highly = >fragmented in terms of technology. Most vendors have proprietary L3, = >sometimes proprietary L2, and there are a bunch of standards coming, = >like ZigBee, Z-Wave, ISA, HART... >One reason for people not to go for IPv6 is "Oh this is too big for a = >sensor", also because they are not always familiar with IP. > >What I want to say is that this kind of question (do we mandate IPSec) = >is critical for a domain which promises billions of device. > >Cheers, >Julien > > > = > = >Julien Abeill=E9 >Software Engineer >Technology Center >jabeille@cisco.com >Fax:+41 21 822 1604 >Cisco Systems International S=E0rl >Av. des Uttins 5 >1180 Rolle >Switzerland (FR) >www.cisco.com > > >This e-mail may contain confidential and privileged material for the = >sole use of the intended recipient. Any review, use, distribution or = >disclosure by others is strictly prohibited. >If you are not the intended recipient (or authorized to receive for the = >recipient), please contact the sender by reply e-mail and delete all = >copies of this message. > = > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = >Bound, Jim >Sent: mardi 26 f=E9vrier 2008 19:50 >To: Basavaraj Patil; Thomas Narten; Nobuo OKABE >Cc: John Loughney; ipv6@ietf.org; Fred Baker (fred) >Subject: RE: Making IPsec *not* mandatory in Node Requirement > >For defense in depth scenarios I disagree in the case for the MN to = >verify with the HA. But I see your point. >/jim > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = >> Of Basavaraj Patil >> Sent: Tuesday, February 26, 2008 12:58 PM >> To: Thomas Narten; Nobuo OKABE >> Cc: John Loughney; ipv6@ietf.org; fred@cisco.com >> Subject: Re: Making IPsec *not* mandatory in Node Requirement >> >> >> I agree with Thomas about his views on IPsec being a mandatory and = >> default component of the IPv6 stack. >> Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec = >> for securing the signaling. This has lead to complexity of the = >> protocol and not really helped either in adoption or implementation. >> IPsec based security is an overkill for Mobile IPv6 and illustrates = >> the point that you do not have to use it simply because it >happens to >> be an integral part of IPv6. >> >> -Basavaraj >> >> >> On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: >> >> > IMO, we need to get over the idea that IPsec is mandatory in IPv6. >> > Really. Or that mandating IPsec is actually useful in practice. >> > >> > It is the case that mandating IPsec as part of IPv6 has >> contributed to >> > the hype about how great IPv6 is and how one will get >> better security >> > with IPv6. Unfortunately, that myth has also harmed the >> overall IPv6 >> > deployment effort, as people look more closely and come to >> understand >> > that deploying IPv6 doesn't automatically/easily yield improved = >> > security. >> > >> > We all know the reality of security is very different and >much more >> > complicated/nuanced then just saying "use IPsec". >> > >> > Consider: >> > >> > IPsec by itself (with no key management) is close to useless. The = >> > average person cannot configure static keys, so the result is (in >> > effect) a useless mandate (as a broad mandate for ALL nodes). >> > >> > What applications actually make use of IPsec for security? >> A lot fewer >> > than one might think. For many IPv6 devices/nodes, if one actually = >> > looks at the applications that will be used on them, they >> do not use >> > IPsec today for security. And, there are strong/compelling >> arguments >> > for why IPsec is not the best security solution for many >> applications. >> > Thus, requiring IPsec is pointless. >> > >> > To be truly useful, we (of course) need key management. If >> we want to >> > mandate key management, the stakes go way up. IKEv1/v2 is >> not a small >> > implementation effort. And, we are now in the funny situation where >> > IKEv1 has been implemented, but due to shortcomings, IKEv2 >> has already >> > been developed. IKEv2 has been out for over 2 years, but = >> > implementations are not widespread yet. So, would we mandate IKEv1 = >> > (which is obsoleted and has documented issues), or do we mandate = >> > IKEv2, even though it is clear it is not widely available yet? >> > >> > IMO, we should drop the MUST language surrounding IPsec. >> The technical >> > justification for making it MUST are simply not compelling. >> It seems >> > to me that the MUST is there primarily for historical/marketing = >> > reasons. >> > >> > Note that dropping the MUST will not mean people stop implementing = >> > IPsec, where there is compelling benefit. Indeed, note >that the USG >> > has already moved away from IKEv1 and has strongly >> signalled that it >> > will require IKEv2 going forward. So I am confident that IPsec (and >> > IKE) will get implemented going forward. >> > >> > But there is no reason why IPsec should be mandated in >> devices where >> > it is clear (based on the function/purpose of the device) >> that IPsec >> > will in fact not actually be used. >> > >> > As a general "node requirement", SHOULD is the right level, >> not MUST. >> > >> > Thomas >> > = >-------------------------------------------------------------------- >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> > Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> > = >-------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 11:58:15 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74A728C752; Tue, 26 Feb 2008 11:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ERzkyCjjX18; Tue, 26 Feb 2008 11:58:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD97628C27F; Tue, 26 Feb 2008 11:58:11 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF2E28C450 for ; Tue, 26 Feb 2008 11:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpf5C1gnD7kx for ; Tue, 26 Feb 2008 11:58:09 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B59E528C5FA for ; Tue, 26 Feb 2008 11:57:27 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2008 20:57:21 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1QJvLt7016247 for ; Tue, 26 Feb 2008 20:57:21 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1QJvJXL006879 for ; Tue, 26 Feb 2008 19:57:21 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 20:57:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 20:58:56 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A86010DA2A3@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sFHb4FfeEixsSTqazyE+hnx43wAAIu6AAABDC6A= From: "Julien Abeille (jabeille)" To: X-OriginalArrivalTime: 26 Feb 2008 19:57:16.0945 (UTC) FILETIME=[C9C0A810:01C878B1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10175; t=1204055841; x=1204919841; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20FW=3A=20Making=20IPsec=20*not*=20mandatory=20in =20Node=20Requirement |Sender:=20; bh=Kq1yuku6UlkMmd3Em4P3MwD4wyAtxFF6WOvnrAOkHEA=; b=DXN+RdIK1v9rsoHIq60C51JkRnUMd4mkwobg6VL2lZ776O80Kz+JkUb71n mQ/Lnt1Bii6r6n1D4lj5cKTZMFkgidq2xM2gTHWeLAN0aR/17ZUEgGyyUia8 RG6/23xZI9; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Vishwas, I am not a security expert, I can just say that the lightweight point is ju= st one among other conseqences of the platform capabilities (limited proces= sing power, memory, storage, heavy duty cycle) and expected life time (usua= lly 5 years running on batteries) of the device. My interest is the following: If our work on the cost of IPv6 features shows that some of them are too he= avy, the ideal would be that necessary RFC updates (such as what 6lowpan st= arted) occur, and ultimately RFC4294 can fit on a sensor, or that several "= profiles" (like the DOD or NIST ones) are defined within 6man Cheers, Julien = = -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: mardi 26 f=E9vrier 2008 11:47 To: Julien Abeille (jabeille) Subject: Re: Making IPsec *not* mandatory in Node Requirement Hi Julien, As you stress on "lightweight", I would like to stress the work in the BTNS= working group. I would want to hear more form you and how we can change IP= sec to meet your needs. Thanks, Vishwas On Tue, Feb 26, 2008 at 11:28 AM, Julien Abeille (jabeille) wrote: > Hi John, > > Regarding sensors, > - some applications (e.g. sensors for process control in factories) = > require strong security, but dedicated security mechanism are used (in = > ISA standard for industrial automation as an example), the main = > difference with IPSec being the importance of the "lightweigt" > requirement. A security mechanism and associated algorithms for such = > sensors might use much less processing power, memory... than standard = > IP mechanisms > - some applications might not require any security, e.g. a light sensor = in your flat might not need it and not implement it, also due to the very l= ow cost of the sensor. > > Cheers, > John > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: mardi 26 f=E9vrier 2008 20:13 > To: Julien Abeille (jabeille); Jim.Bound@hp.com; = > basavaraj.patil@nsn.com; narten@us.ibm.com; nov@tahi.org > Cc: ipv6@ietf.org; Fred Baker (fred) > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > Julien and Alain, > > My high-level question to you both is, for sensors and set-top boxes - d= o you feel that you do not need security for any reason? Is this a long-te= rm issue or a short-term issue. > > I can't really think of a reason why security would not be an issue, but= I could be wrong. > > John > > >-----Original Message----- > >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = > Of >ext Julien Abeille (jabeille) > >Sent: 26 February, 2008 11:12 > >To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas Narten; = > Nobuo >OKABE > >Cc: Loughney John (Nokia-OCTO/PaloAlto); ipv6@ietf.org; Fred Baker > >(fred) > >Subject: RE: Making IPsec *not* mandatory in Node Requirement > > >Hi all, > >To come back to constrained device, as I already > mentionned on the list >within 6lowpan, we are working on a draft = > which documents the cost of >each feature mandated by RFC4294, from = > an implementation perspective >(target platform is 8bit = > microcontroller, few 10K ROM, few K RAM). I >guess as soon as we have = > results, this might help the discussion. > > > >To give a bit of insight on sensor industry, the market is highly > >fragmented in terms of technology. Most vendors have proprietary L3, = > >sometimes proprietary L2, and there are a bunch of standards coming, = > >like ZigBee, Z-Wave, ISA, HART... > >One reason for people not to go for IPv6 is "Oh this is too big for = > a >sensor", also because they are not always familiar with IP. > > > >What I want to say is that this kind of question (do we mandate > IPSec) >is critical for a domain which promises billions of device. > > > >Cheers, > >Julien > > > > > > > > > > > >-----Original Message----- > >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = > Of >Bound, Jim > >Sent: mardi 26 f=E9vrier 2008 19:50 > >To: Basavaraj Patil; Thomas Narten; Nobuo OKABE > >Cc: John Loughney; ipv6@ietf.org; Fred Baker (fred) > >Subject: RE: Making IPsec *not* mandatory in Node Requirement > > >For defense in depth scenarios I disagree in the case for the MN to = > >verify with the HA. But I see your point. > >/jim > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = > Behalf >> Of Basavaraj Patil >> Sent: Tuesday, February 26, 2008 > 12:58 PM >> To: Thomas Narten; Nobuo OKABE >> Cc: John Loughney; = > ipv6@ietf.org; fred@cisco.com >> Subject: Re: Making IPsec *not* = > mandatory in Node Requirement >> >> >> I agree with Thomas about = > his views on IPsec being a mandatory and >> default component of the > IPv6 stack. > >> Because of this belief, Mobile IPv6 (RFC3775) design relied on = > IPsec >> for securing the signaling. This has lead to complexity of = > the >> protocol and not really helped either in adoption or implementati= on. > >> IPsec based security is an overkill for Mobile IPv6 and = > illustrates >> the point that you do not have to use it simply = > because it >happens to >> be an integral part of IPv6. > >> > >> -Basavaraj > >> > >> > >> On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: > >> > >> > IMO, we need to get over the idea that IPsec is mandatory in IPv6. > >> > Really. Or that mandating IPsec is actually useful in practice. > >> > > >> > It is the case that mandating IPsec as part of IPv6 has >> = > contributed to >> > the hype about how great IPv6 is and how one will = > get >> better security >> > with IPv6. Unfortunately, that myth has = > also harmed the >> overall IPv6 >> > deployment effort, as people = > look more closely and come to >> understand >> > that deploying IPv6 = > doesn't automatically/easily yield improved >> > security. > >> > > >> > We all know the reality of security is very different and >much = > more >> > complicated/nuanced then just saying "use IPsec". > >> > > >> > Consider: > >> > > >> > IPsec by itself (with no key management) is close to useless. = > The >> > average person cannot configure static keys, so the result = > is (in >> > effect) a useless mandate (as a broad mandate for ALL nodes). > >> > > >> > What applications actually make use of IPsec for security? > >> A lot fewer > >> > than one might think. For many IPv6 devices/nodes, if one = > actually >> > looks at the applications that will be used on them, = > they >> do not use >> > IPsec today for security. And, there are = > strong/compelling >> arguments >> > for why IPsec is not the best = > security solution for many >> applications. > >> > Thus, requiring IPsec is pointless. > >> > > >> > To be truly useful, we (of course) need key management. If >> = > we want to >> > mandate key management, the stakes go way up. > IKEv1/v2 is >> not a small >> > implementation effort. And, we are = > now in the funny situation where >> > IKEv1 has been implemented, but = > due to shortcomings, IKEv2 >> has already >> > been developed. IKEv2 = > has been out for over 2 years, but >> > implementations are not = > widespread yet. So, would we mandate IKEv1 >> > (which is obsoleted = > and has documented issues), or do we mandate >> > IKEv2, even though = > it is clear it is not widely available yet? > >> > > >> > IMO, we should drop the MUST language surrounding IPsec. > >> The technical > >> > justification for making it MUST are simply not compelling. > >> It seems > >> > to me that the MUST is there primarily for historical/marketing > >> > reasons. > >> > > >> > Note that dropping the MUST will not mean people stop = > implementing >> > IPsec, where there is compelling benefit. Indeed, = > note >that the USG >> > has already moved away from IKEv1 and has = > strongly >> signalled that it >> > will require IKEv2 going forward. > So I am confident that IPsec (and >> > IKE) will get implemented = > going forward. > >> > > >> > But there is no reason why IPsec should be mandated in >> = > devices where >> > it is clear (based on the function/purpose of the > device) >> that IPsec >> > will in fact not actually be used. > >> > > >> > As a general "node requirement", SHOULD is the right level, >> = > not MUST. > >> > > >> > Thomas > >> > > >-------------------------------------------------------------------- > >> > IETF IPv6 working group mailing list ipv6@ietf.org = > Administrative >> > Requests: > http://www.ietf.org/mailman/listinfo/ipv6 > >> > > >-------------------------------------------------------------------- > >> > >> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> = > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > >> > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list >ipv6@ietf.org > >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list >ipv6@ietf.org > >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 11:59:57 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF92428C711; Tue, 26 Feb 2008 11:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD7pMlfbbL7w; Tue, 26 Feb 2008 11:59:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D943928C5DA; Tue, 26 Feb 2008 11:59:56 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8981928C436 for ; Tue, 26 Feb 2008 11:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeochEm-WnWj for ; Tue, 26 Feb 2008 11:59:51 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id A523628C3B0 for ; Tue, 26 Feb 2008 11:59:51 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1QJxihD016482 for ; Tue, 26 Feb 2008 14:59:44 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1QJxiIJ299490 for ; Tue, 26 Feb 2008 14:59:44 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1QJxhvq031723 for ; Tue, 26 Feb 2008 14:59:44 -0500 Received: from cichlid.raleigh.ibm.com (wecm-9-67-196-237.wecm.ibm.com [9.67.196.237]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1QJxgrY031629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 14:59:43 -0500 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m1QJxcpZ008513; Tue, 26 Feb 2008 14:59:38 -0500 Message-Id: <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> To: "Julien Abeille (jabeille)" Subject: Re: Making IPsec *not* mandatory in Node Requirement In-reply-to: <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> Comments: In-reply-to "Julien Abeille (jabeille)" message dated "Tue, 26 Feb 2008 20:28:12 +0100." Date: Tue, 26 Feb 2008 14:59:38 -0500 From: Thomas Narten Cc: john.loughney@nokia.com, ipv6@ietf.org, Jim.Bound@hp.com, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > - some applications might not require any security, e.g. a light sensor = > in your flat might not need it and not implement it, also due to the = > very low cost of the sensor. I agree. There is absolutely no need to prevent my neighbor (or a bad guy outside my window) from being able to control/influence light sensors in my house. What possible harm could they do? Who needs security anyway! :-) Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 12:15:42 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F32A28C49B; Tue, 26 Feb 2008 12:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52AO9z-k3HmR; Tue, 26 Feb 2008 12:15:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1EC93A6869; Tue, 26 Feb 2008 12:15:40 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542DA3A68B5 for ; Tue, 26 Feb 2008 12:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNP3iXl2BO7r for ; Tue, 26 Feb 2008 12:15:38 -0800 (PST) Received: from mail.polartel.com (mail.polartel.com [66.231.96.142]) by core3.amsl.com (Postfix) with ESMTP id 5F8323A6784 for ; Tue, 26 Feb 2008 12:15:38 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 14:15:31 -0600 Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F3D2@mail> In-Reply-To: <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sjjU7m9GxyZ5S528x8iG+6QxtgAABI7g References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net><38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com><19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com><38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> From: "Kevin Kargel" To: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org While I agree that by and large security is a good priority, there are cases for lightweight protocols to conserve cost. One example would be remote reporting thermometers that I actually use on IPv4 now. They are non-configurable, they have no settings other than network config. You plug them in, give them an address, and they have a lightweight web server and read-only snmp that will display sensor temperature when queried. I like to have these sensors scatterred throughout my enterprise. There is nothing to hack, they posess virtually no memory, and if they get hacked my world will not end, I will double check the temperature manually, unpower the device, plug it back in, and it will reload from it's read-only boot rom. I would really prefer that these devices cost $40 instead of $200 . We could put all sorts of security on these devices, making them more expensive than they are worth, or we can plug them in, enjoy their benefits, and accept the risk. I have customers that run computers from live-CD's, who want the network to perform, and are not worried about security. They are only connected while the user is at the keyboard, if they suspect a compromise they reboot and are back where they started. They like the fact that they can have internet cheaply and easily. These customers do not want a secure configuration with pass phrases and keys and whatnot, they want a four click config that gets then online. Whether these use cases are good or bad doesn't really matter, what matters is that they do exist and the customer should have decision making authority for their network. JMHO Kevin > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Thomas Narten > Sent: Tuesday, February 26, 2008 2:00 PM > To: Julien Abeille (jabeille) > Cc: john.loughney@nokia.com; ipv6@ietf.org; Jim.Bound@hp.com; > Fred Baker (fred) > Subject: Re: Making IPsec *not* mandatory in Node Requirement > > > - some applications might not require any security, e.g. a light > > sensor = in your flat might not need it and not implement > it, also due > > to the = very low cost of the sensor. > > I agree. There is absolutely no need to prevent my neighbor > (or a bad guy outside my window) from being able to > control/influence light sensors in my house. What possible > harm could they do? > > Who needs security anyway! > > :-) > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 12:16:24 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFC128C72B; Tue, 26 Feb 2008 12:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ4oVAYgAOwS; Tue, 26 Feb 2008 12:16:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB84428C61F; Tue, 26 Feb 2008 12:16:21 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CECE28C4F9 for ; Tue, 26 Feb 2008 12:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncWlrGt3fVkM for ; Tue, 26 Feb 2008 12:16:20 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2A1E128C5FF for ; Tue, 26 Feb 2008 12:16:20 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2008 21:16:13 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1QKGDKD015290; Tue, 26 Feb 2008 21:16:13 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1QKGAXL012408; Tue, 26 Feb 2008 20:16:10 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 21:16:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 21:17:50 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com> In-Reply-To: <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sjA8MhAgWE4CRH+KEUv1fVZkRwAAiBIQ References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> From: "Julien Abeille (jabeille)" To: "Thomas Narten" X-OriginalArrivalTime: 26 Feb 2008 20:16:10.0969 (UTC) FILETIME=[6DAEFC90:01C878B4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=863; t=1204056973; x=1204920973; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20Making=20IPsec=20*not*=20mandatory=20in =20Node=20Requirement |Sender:=20; bh=ayjvAMV+4BTAP+hgLknY+slYecaVBn2SkGEBi6B3CFk=; b=uUi2SVA9GYeF0E+F0T1iDEzWggpLYKdAdXiRAY7KCK8CF5GjM4T4Lf7QY/ ToOZgpn5ONjAD/GZ2O/ETLXXwjuw6KXG5XvM4ZKet8PqN26GvxVAqLyNph5j 4GS7878zKF; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: john.loughney@nokia.com, ipv6@ietf.org, Jim.Bound@hp.com, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org A sensor can only sense..., you are talking about a light actuator. Julien -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] = Sent: mardi 26 f=E9vrier 2008 12:00 To: Julien Abeille (jabeille) Cc: john.loughney@nokia.com; Jim.Bound@hp.com; basavaraj.patil@nsn.com; nov= @tahi.org; ipv6@ietf.org; Fred Baker (fred) Subject: Re: Making IPsec *not* mandatory in Node Requirement > - some applications might not require any security, e.g. a light = > sensor =3D in your flat might not need it and not implement it, also due = > to the =3D very low cost of the sensor. I agree. There is absolutely no need to prevent my neighbor (or a bad guy o= utside my window) from being able to control/influence light sensors in my = house. What possible harm could they do? Who needs security anyway! :-) Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 12:24:07 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3230A28C8C9; Tue, 26 Feb 2008 12:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=-1.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpUcLbtRl9JG; Tue, 26 Feb 2008 12:24:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4700128C87A; Tue, 26 Feb 2008 12:22:11 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F28E28C3C5 for ; Tue, 26 Feb 2008 12:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JSefJz6LEJq for ; Tue, 26 Feb 2008 12:22:04 -0800 (PST) Received: from mx4.ca.afilias.info (vgateway.libertyrms.info [207.219.45.62]) by core3.amsl.com (Postfix) with ESMTP id 29F8528C8A6 for ; Tue, 26 Feb 2008 12:20:12 -0800 (PST) Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1JU6Gu-0005sH-Sv; Tue, 26 Feb 2008 15:19:28 -0500 Message-ID: <47C47446.2050407@ca.afilias.info> Date: Tue, 26 Feb 2008 15:19:18 -0500 From: Brian Dickson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: Making IPsec *not* mandatory in Node Requirement References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Cc: narten@us.ibm.com, ipv6@ietf.org, Jim.Bound@hp.com, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org john.loughney@nokia.com wrote: > Julien and Alain, > > My high-level question to you both is, for sensors and set-top > boxes - do you feel that you do not need security for any > reason? Is this a long-term issue or a short-term issue. > > = Let me answer on everyone's behalf: IPsec is an end-to-end security protocol. For many environments, such as set-top boxes and the like, the box has = its own ability to secure itself (or make itself unusable), and the L0/L1/L2 portion of = the network is under the provider's physical control. So, for a substantial portion of deployed equipment (cable/dsl boxes, = embedded systems), with no user-serviceable parts, *how* security is handled, is orthogonal = to the issue of whether it needs security. Suggesting that in-band, network-wide, heavy-weight security (IPsec) is = the *only* solution to the requirement, doesn't fly. Any of a bunch of other kinds of security can do the job, from TLS to = SSH to use of out-of-band channels. And *this* is why I think that IPsec ought to be downgraded to SHOULD = for IPv6 node requirements. Brian Dickson > I can't really think of a reason why security would not be an > issue, but I could be wrong. > > John > > = >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = >> Behalf Of ext Julien Abeille (jabeille) >> Sent: 26 February, 2008 11:12 >> To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas = >> Narten; Nobuo OKABE >> Cc: Loughney John (Nokia-OCTO/PaloAlto); ipv6@ietf.org; Fred = >> Baker (fred) >> Subject: RE: Making IPsec *not* mandatory in Node Requirement >> >> Hi all, >> >> To come back to constrained device, as I already mentionned on = >> the list within 6lowpan, we are working on a draft which = >> documents the cost of each feature mandated by RFC4294, from = >> an implementation perspective (target platform is 8bit = >> microcontroller, few 10K ROM, few K RAM). I guess as soon as = >> we have results, this might help the discussion. >> >> To give a bit of insight on sensor industry, the market is = >> highly fragmented in terms of technology. Most vendors have = >> proprietary L3, sometimes proprietary L2, and there are a = >> bunch of standards coming, like ZigBee, Z-Wave, ISA, HART... >> One reason for people not to go for IPv6 is "Oh this is too = >> big for a sensor", also because they are not always familiar with IP. >> >> What I want to say is that this kind of question (do we = >> mandate IPSec) is critical for a domain which promises = >> billions of device. >> >> Cheers, >> Julien >> >> >> >> >> Julien Abeill=E9 >> Software Engineer >> Technology Center >> jabeille@cisco.com >> Fax:+41 21 822 1604 >> Cisco Systems International S=E0rl >> Av. des Uttins 5 >> 1180 Rolle >> Switzerland (FR) >> www.cisco.com >> >> >> This e-mail may contain confidential and privileged material = >> for the sole use of the intended recipient. Any review, use, = >> distribution or disclosure by others is strictly prohibited. = >> If you are not the intended recipient (or authorized to = >> receive for the recipient), please contact the sender by reply = >> e-mail and delete all copies of this message. >> >> >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = >> Behalf Of Bound, Jim >> Sent: mardi 26 f=E9vrier 2008 19:50 >> To: Basavaraj Patil; Thomas Narten; Nobuo OKABE >> Cc: John Loughney; ipv6@ietf.org; Fred Baker (fred) >> Subject: RE: Making IPsec *not* mandatory in Node Requirement >> >> For defense in depth scenarios I disagree in the case for the = >> MN to verify with the HA. But I see your point. >> /jim >> >> = >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = >>> Of Basavaraj Patil >>> Sent: Tuesday, February 26, 2008 12:58 PM >>> To: Thomas Narten; Nobuo OKABE >>> Cc: John Loughney; ipv6@ietf.org; fred@cisco.com >>> Subject: Re: Making IPsec *not* mandatory in Node Requirement >>> >>> >>> I agree with Thomas about his views on IPsec being a mandatory and = >>> default component of the IPv6 stack. >>> Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec = >>> for securing the signaling. This has lead to complexity of the = >>> protocol and not really helped either in adoption or implementation. >>> IPsec based security is an overkill for Mobile IPv6 and illustrates = >>> the point that you do not have to use it simply because it = >>> = >> happens to = >> = >>> be an integral part of IPv6. >>> >>> -Basavaraj >>> >>> >>> On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: >>> >>> = >>>> IMO, we need to get over the idea that IPsec is mandatory in IPv6. >>>> Really. Or that mandating IPsec is actually useful in practice. >>>> >>>> It is the case that mandating IPsec as part of IPv6 has >>>> = >>> contributed to >>> = >>>> the hype about how great IPv6 is and how one will get >>>> = >>> better security >>> = >>>> with IPv6. Unfortunately, that myth has also harmed the >>>> = >>> overall IPv6 >>> = >>>> deployment effort, as people look more closely and come to >>>> = >>> understand >>> = >>>> that deploying IPv6 doesn't automatically/easily yield improved = >>>> security. >>>> >>>> We all know the reality of security is very different and = >>>> = >> much more = >> = >>>> complicated/nuanced then just saying "use IPsec". >>>> >>>> Consider: >>>> >>>> IPsec by itself (with no key management) is close to useless. The = >>>> average person cannot configure static keys, so the result is (in >>>> effect) a useless mandate (as a broad mandate for ALL nodes). >>>> >>>> What applications actually make use of IPsec for security? >>>> = >>> A lot fewer >>> = >>>> than one might think. For many IPv6 devices/nodes, if one actually = >>>> looks at the applications that will be used on them, they >>>> = >>> do not use >>> = >>>> IPsec today for security. And, there are strong/compelling >>>> = >>> arguments >>> = >>>> for why IPsec is not the best security solution for many >>>> = >>> applications. >>> = >>>> Thus, requiring IPsec is pointless. >>>> >>>> To be truly useful, we (of course) need key management. If >>>> = >>> we want to >>> = >>>> mandate key management, the stakes go way up. IKEv1/v2 is >>>> = >>> not a small >>> = >>>> implementation effort. And, we are now in the funny situation where >>>> IKEv1 has been implemented, but due to shortcomings, IKEv2 >>>> = >>> has already >>> = >>>> been developed. IKEv2 has been out for over 2 years, but = >>>> implementations are not widespread yet. So, would we mandate IKEv1 = >>>> (which is obsoleted and has documented issues), or do we mandate = >>>> IKEv2, even though it is clear it is not widely available yet? >>>> >>>> IMO, we should drop the MUST language surrounding IPsec. >>>> = >>> The technical >>> = >>>> justification for making it MUST are simply not compelling. >>>> = >>> It seems >>> = >>>> to me that the MUST is there primarily for historical/marketing = >>>> reasons. >>>> >>>> Note that dropping the MUST will not mean people stop implementing = >>>> IPsec, where there is compelling benefit. Indeed, note = >>>> = >> that the USG = >> = >>>> has already moved away from IKEv1 and has strongly >>>> = >>> signalled that it >>> = >>>> will require IKEv2 going forward. So I am confident that IPsec (and >>>> IKE) will get implemented going forward. >>>> >>>> But there is no reason why IPsec should be mandated in >>>> = >>> devices where >>> = >>>> it is clear (based on the function/purpose of the device) >>>> = >>> that IPsec >>> = >>>> will in fact not actually be used. >>>> >>>> As a general "node requirement", SHOULD is the right level, >>>> = >>> not MUST. >>> = >>>> Thomas >>>> >>>> = >> -------------------------------------------------------------------- >> = >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>>> >>>> = >> -------------------------------------------------------------------- >> = >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> = >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> = > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 12:31:24 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502D33A6CDF; Tue, 26 Feb 2008 12:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrWqKgkEYUrK; Tue, 26 Feb 2008 12:31:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4024028C0F4; Tue, 26 Feb 2008 12:31:23 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E2E3A6CCB for ; Tue, 26 Feb 2008 12:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QuJrmxUn5rU for ; Tue, 26 Feb 2008 12:31:21 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.179]) by core3.amsl.com (Postfix) with ESMTP id 0FCB43A6CDF for ; Tue, 26 Feb 2008 12:31:20 -0800 (PST) Received: by el-out-1112.google.com with SMTP id j27so3121301elf.25 for ; Tue, 26 Feb 2008 12:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=Nt4drVmTvf0NUaBLT7rY839lIogiL0Ndq/K/l5/iQzg=; b=t1NAyh/6LRfGzmnkiorCagcChbgvOl4weZC9Z0Tx1BfIXMji/lZnbC9rIc4XRer8hxhO80WJtd1OTi3uoaouVzeSdg2L3pyQ28D+gt4Ns+YtBlwoOPGfvqnJGzbfwFnzKgaTnwGzhVbfdYvdgKiRkWq4DVvJXG/aPOGHpidb9z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Ur089V31koAq3ayFDx+bzj1PpODeksLwdkshbCAMZVeEtd7sO48+z3ao3S7hKl7su6L01ujeeorNWSKJI7ijW7rjpozWWlTs9IWxUnxL1yHyO5xuoLbBVtQQ2qORK8CTuli4GlGakvFGroofXhIj28o9QSkM2zIN66V6MntvtTE= Received: by 10.114.181.1 with SMTP id d1mr6120721waf.10.1204057873381; Tue, 26 Feb 2008 12:31:13 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id n38sm12665251wag.2.2008.02.26.12.31.12 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Feb 2008 12:31:13 -0800 (PST) Message-ID: <47C4770D.9000702@gmail.com> Date: Wed, 27 Feb 2008 09:31:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola Subject: IGPs [Re: Updates to Node Requirements-bis] References: <19EBBEC503C3B5469070E0A6674A533A0109A4E2@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A0109A84C@daebe104.NOE.Nokia.com> In-Reply-To: Cc: john.loughney@nokia.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2008-02-26 19:00, Pekka Savola wrote: > On Mon, 25 Feb 2008, Manfredi, Albert E wrote: >> One MUST that the NIST IPv6 Profile introduced was mandating of OSPFv3 >> as the routing protocol. Is this because RIPng is not beiong adopted in >> practice? Small networks should do well with RIPng, I would think, >> unless RIPng is never used in practice. And in principle, there could be >> a case made for static routing tables in special cases. I'm not sure why >> the routing protocol mandate for all Government nets. > > IS-IS is currently probably more widely used for IPv6 routing than > OSPFv3. > > Given that there are multiple good options that any reasonable > network could deploy, I don't see why the IETF should make a > recommendation in this space. Yes, it's hard to see a "MUST implement" interoperability requirement in this space. However, there is value to a reader in listing the IGPs that are standardised and should be considered for implementation. > > NIST's goal was probably, "some implementations on the field just > support static and maybe RIPng. We want to mandate something more > scalable, and OSPFv3 is as good an option as any". And this illustrates the difference in purpose between the NIST/DISA profiles, which are operational and RFP requirements, and the IETF profile, which is presumably aimed at a minimal implementation rqeuirement. The IETF can (as Fred has said) profitably learn from the NIST/DISA reasoning, but our concerns are broader. Brian > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 12:46:01 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4225828C27F; Tue, 26 Feb 2008 12:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w78acxq7OLgI; Tue, 26 Feb 2008 12:45:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D401928C306; Tue, 26 Feb 2008 12:45:56 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298E53A6808 for ; Tue, 26 Feb 2008 12:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZfVbjCF7ssS for ; Tue, 26 Feb 2008 12:45:54 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by core3.amsl.com (Postfix) with ESMTP id 9A1D53A68B5 for ; Tue, 26 Feb 2008 12:45:54 -0800 (PST) Received: by el-out-1112.google.com with SMTP id j27so3130507elf.25 for ; Tue, 26 Feb 2008 12:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=sLPN4g/XaqPPNSQDZNyVbCZfkKUJdIkEThAvXkh84Dw=; b=Iwjr1sR3B60VB9t/MSQFUgfq4rDX8WVKL6tbPct6c+p42axhbfQd+zHVbY7tKasp9xb+jCtKknehKXDPP1iUphD+larrfqHGC7KaWNgRrQLeqmNewMZ67/3N+lyPdQTXG0403LDf1mXiDWTcxwLjP1qrJFQVcpJLyorZV0UcMH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=g47bXYRcl+JH9zb98jUdQ46kn8CO1cBQ7NzRr4t+go2KPYotT/ntGNSygrvYeXdDnV/yg9VML/CMGqqaFBHwudBTQA/l72Db8j3GOlWEcClMMftwcTyuaAI3D2AMUipyIJjb52mI3uOgfE9hrX/YPsS05qGaUSq2ZO/sQaJ5AsE= Received: by 10.115.15.1 with SMTP id s1mr6141694wai.0.1204058747178; Tue, 26 Feb 2008 12:45:47 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m24sm12710531waf.57.2008.02.26.12.45.45 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Feb 2008 12:45:46 -0800 (PST) Message-ID: <47C47A76.8040901@gmail.com> Date: Wed, 27 Feb 2008 09:45:42 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ed Jankiewicz Subject: Re: the role of the node "requirements" document References: <47C421C3.7070806@innovationslab.net> <47C44024.6050005@sri.com> In-Reply-To: <47C44024.6050005@sri.com> Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2008-02-27 05:36, Ed Jankiewicz wrote: > (full disclosure - I am one of the editors of the DoD IPv6 Profiles > document - but comments are my own as an individual) > > 1. Can we discuss the normative level of the revised Node Requirements > document? My preference would be that it is a standards track or BCP > ultimately, to give firm definition of what an IPv6 node MUST do. > Another INFORMATIONAL document like RFC4294 is merely a helpful > annotated bibliography, but that may be all we can accomplish in a > reasonable timeframe, all in all it doesn't make a big difference. I think we have a lot of experience of failure in this area in the IETF (and OSI profiles also failed), so I predict that if we try to reach consensus on this as a standards-track or BCP document, we will fail again. As we often say, in the end it's the market that decides, and each implementor chooses what to do for their particular part of the market. I think our job is to publish clear and consistent specifications. In the present case, they may well say things like If you choose to implement IPsec, here are the RFCs that you MUST/SHOULD/MAY implement. If you choose to implement an IGP, here are the RFCs that you MAY implement. and so on, for things that are not part of the bare minimum. > > 2. I don't expect (nor believe it appropriate) that this revision will > satisfy all the needs of either NIST or DoD for defining "IPv6 Capable" > for our client organizations. Of course not. A requirement spec for an RFP is not the same thing as a generic implementation requirement spec. > That being said, several folks are > already reviewing the three drafts side by side, to help ensure that the > Node Requirements accurately defines the requirements that apply to ALL > IPv6 nodes for ALL deployments. It may need to define a bare minimum but in addition it certainly needs to list a whole bunch of options. > The editors of the DoD and NIST > documents should concentrate on the delta from that baseline for > specific US Government and DoD requirements and deployments. As should anyone else in the RFP business. > > 3. Specifically with respect to IPsec and IKEv2, regardless of the > "settlement" of that debate years ago, there are still valid questions > about which requirements apply to ALL IPv6 nodes. I hope this revision > of the Node Requirements can reiterate the commitment to IPsec, but if > it does not, DoD (and NIST) can certainly state stronger and more > specific requirements in our documents. DoD in particular answers to a > higher authority on security and cryptographic requirements, and will > probably require things that a small office or home user would never need. Exactly right, IMHO. Brian C > > A prior message in this thread (from Jeremy Duncan) included pointers to > the NIST and DoD profiles drafts, feel free to send any > questions/comments to the editors off-list. Some of the differences are > worth discussing on this list to see if there is consensus for changes > to the Node Requirements draft. Additional work will need to be done by > the editors of both the DoD and NIST drafts to address the specific > needs of our clients that don't apply to everyone. > > Hemant Singh (shemant) wrote: >> Brian, >> >> Indeed, I know that RFC4294 is INFORMATIONAL. I got confused because I >> see the new node-req-bis draft URL snipped below to be on Standards >> Track. >> >> http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt >> >> Sorry, if I am missing some IETF process. I was expecting the bis draft >> above to be INFORMATIONAL as well. >> >> Thanks. >> >> Best Regards. >> >> Hemant >> >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Brian Haberman >> Sent: Tuesday, February 26, 2008 9:27 AM >> To: ipv6@ietf.org >> Subject: Re: the role of the node "requirements" document >> >> Hemant, >> Take a look at the category for RFC 4294 at >> http://tools.ietf.org/html/rfc4294. It is Informational and no >> discussion has occurred to change that classification for this update. >> >> Regards, >> Brian >> >> >> Hemant Singh (shemant) wrote: >> >>> Pekka, >>> >>> The node requirement draft as I read it from >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.tx >>> t >>> >>> is on Standards Track. Did I miss anything because you think this node >>> >> >>> requirement doc is an INFORMATIONAL draft? >>> >>> As for IPSec and IPv6, indeed it is true that IPSec is mandatory for >>> IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is >>> mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security >>> Architecture for the Internet Protocol). Snipped from the RFC's is >>> section 10 shown below between square brackets. >>> >>> [10. Conformance Requirements >>> >>> All IPv4 systems that claim to implement IPsec MUST comply with all >>> requirements of the Security Architecture document. All IPv6 >>> >> systems >> >>> MUST comply with all requirements of the Security Architecture >>> document.] >>> >>> I totally appreciate Alain's concern for cable modem devices with >>> limited memory for IPv6 but the problem is that IPv6 community decided >>> >> >>> as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. >>> Cable IPv6 standards came much later. We will have to see what common >>> ground can be met to address Alain's concern. >>> >>> Hemant >>> >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf >>> Of Pekka Savola >>> Sent: Tuesday, February 26, 2008 5:05 AM >>> To: Alain Durand >>> Cc: john.loughney@nokia.com; ipv6@ietf.org; Fred Baker (fred) >>> Subject: the role of the node "requirements" document >>> >>> On Tue, 26 Feb 2008, Alain Durand wrote: >>> >>>> The problem is that some of those devices have really limited memory >>>> and they already do (too?) many things, so there is no room left... >>>> Some vendors had to go back at their code and spend a lot of time and >>>> >> >>>> effort to clean things up to make room for the very basic IPv6 code, >>>> >>> so every kb count. >>> >>>> The whole idea of asking them to do extra efforts to implement a >>>> functionality that is not needed and that will introduce bugs & >>>> instability is not very appealing. >>>> >>>> Again, this last argument applies also to devices that do not have >>>> memory >>>> problems: if I do not need functionality X, I'd rather like not to >>>> have it implemented as it will lower the operational risks. >>>> >>> I think this discussion somewhat misses the point because some folks >>> feel informational roadmap documents have more weight than they >>> actually do (according to IETF procedures, or even in practice in >>> >> vendors' >> >>> feature planning). (E.g., there was similar discussion about >>> RFC4614.) >>> >>> The node requirements document, despite its misleading title, is >>> INFORMATIONAL. It does not represent IETF consensus, so even if the >>> document would say every IPv6 node MUST implement IPsec, it would mean >>> >> >>> basically nothing. >>> >>> Where is a Standards Track or BCP document that says IPsec is >>> >> mandatory? >> >>> If vendors need to make tradeoffs of what they implement or don't >>> implement, that's their call. They can't call that product to be >>> "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or >>> claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC >>> number which mandates IPsec). That's all. >>> >>> The product also might not get IPv6 ready logo certifications and >>> such, but that's not IETF's business anyway. >>> >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 12:54:08 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A17228C79B; Tue, 26 Feb 2008 12:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnD1hxq2O8ty; Tue, 26 Feb 2008 12:54:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE6E28C405; Tue, 26 Feb 2008 12:53:58 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3138E3A6825 for ; Tue, 26 Feb 2008 12:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iioutGjdTQ-1 for ; Tue, 26 Feb 2008 12:53:55 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.245]) by core3.amsl.com (Postfix) with ESMTP id E81D528C413 for ; Tue, 26 Feb 2008 12:52:38 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 33so6256423agc.1 for ; Tue, 26 Feb 2008 12:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=B5m3hYE7xESBhjoedVhGs9PzIt1Gt+R47C/zXC5d9B8=; b=Kc841TNrs/ty27aQf1CQFO1w5RpXrmPWtY0yrfiUgpWeqHwBVH7v7XE+VZIEAZH7KaYCLfLs9JB9sNEmfHHzx+SwZ2KoXDFC37ZHqfhYI6AWp+fyp3fF6TeJ9kp2F7fjgJ3bD8CuppDZUVdzq9Oi3m8yyuX6OBJJH/5/SNYQwUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BqJGXFSS0A5HpUVwlBpskA5mur5PCjJUmN0v4r1zgz1H3Y9kQyUDGkc602yI/NQ70HmAgaWfcRQvXW0cDVi9vV2DDXkjvYA9QrRv+oPkqQruaZdTeI99hrXplpRWX25Omx5e+jMwv2VOxJLlQvmE3bq4HE5m9FHn5kmfNKJ/DIk= Received: by 10.142.47.6 with SMTP id u6mr4270091wfu.159.1204059151539; Tue, 26 Feb 2008 12:52:31 -0800 (PST) Received: by 10.143.164.14 with HTTP; Tue, 26 Feb 2008 12:52:31 -0800 (PST) Message-ID: <77ead0ec0802261252m3a674a9enaa70b529de3af50c@mail.gmail.com> Date: Tue, 26 Feb 2008 12:52:31 -0800 From: "Vishwas Manral" To: "Brian Dickson" Subject: Re: Making IPsec *not* mandatory in Node Requirement In-Reply-To: <47C47446.2050407@ca.afilias.info> MIME-Version: 1.0 Content-Disposition: inline References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> <831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <47C47446.2050407@ca.afilias.info> Cc: john.loughney@nokia.com, narten@us.ibm.com, ipv6@ietf.org, fred@cisco.com, Jim.Bound@hp.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Brian, BTNS extensions to IPsec provide out-of-band security authentication (its not always in-band like you state). We can replicate the behavior of TLS/ SSL using IPsec. Have a look at: http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and-applic-06.txt Thanks, Vishwas On Tue, Feb 26, 2008 at 12:19 PM, Brian Dickson wr= ote: > john.loughney@nokia.com wrote: > > Julien and Alain, > > > > My high-level question to you both is, for sensors and set-top > > boxes - do you feel that you do not need security for any > > reason? Is this a long-term issue or a short-term issue. > > > > > Let me answer on everyone's behalf: > > IPsec is an end-to-end security protocol. > > For many environments, such as set-top boxes and the like, the box has > its own ability > to secure itself (or make itself unusable), and the L0/L1/L2 portion of > the network > is under the provider's physical control. > > So, for a substantial portion of deployed equipment (cable/dsl boxes, > embedded systems), > with no user-serviceable parts, *how* security is handled, is orthogonal > to the issue > of whether it needs security. > > Suggesting that in-band, network-wide, heavy-weight security (IPsec) is > the *only* > solution to the requirement, doesn't fly. > > Any of a bunch of other kinds of security can do the job, from TLS to > SSH to use of > out-of-band channels. > > And *this* is why I think that IPsec ought to be downgraded to SHOULD > for IPv6 node > requirements. > > Brian Dickson > > > > I can't really think of a reason why security would not be an > > issue, but I could be wrong. > > > > John > > > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > >> Behalf Of ext Julien Abeille (jabeille) > >> Sent: 26 February, 2008 11:12 > >> To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas > >> Narten; Nobuo OKABE > >> Cc: Loughney John (Nokia-OCTO/PaloAlto); ipv6@ietf.org; Fred > >> Baker (fred) > >> Subject: RE: Making IPsec *not* mandatory in Node Requirement > >> > >> Hi all, > >> > >> To come back to constrained device, as I already mentionned on > >> the list within 6lowpan, we are working on a draft which > >> documents the cost of each feature mandated by RFC4294, from > >> an implementation perspective (target platform is 8bit > >> microcontroller, few 10K ROM, few K RAM). I guess as soon as > >> we have results, this might help the discussion. > >> > >> To give a bit of insight on sensor industry, the market is > >> highly fragmented in terms of technology. Most vendors have > >> proprietary L3, sometimes proprietary L2, and there are a > >> bunch of standards coming, like ZigBee, Z-Wave, ISA, HART... > >> One reason for people not to go for IPv6 is "Oh this is too > >> big for a sensor", also because they are not always familiar with IP. > >> > >> What I want to say is that this kind of question (do we > >> mandate IPSec) is critical for a domain which promises > >> billions of device. > >> > >> Cheers, > >> Julien > >> > >> > >> > >> > >> Julien Abeill=E9 > >> Software Engineer > >> Technology Center > >> jabeille@cisco.com > >> Fax:+41 21 822 1604 > >> Cisco Systems International S=E0rl > >> Av. des Uttins 5 > >> 1180 Rolle > >> Switzerland (FR) > >> www.cisco.com > >> > >> > >> This e-mail may contain confidential and privileged material > >> for the sole use of the intended recipient. Any review, use, > >> distribution or disclosure by others is strictly prohibited. > >> If you are not the intended recipient (or authorized to > >> receive for the recipient), please contact the sender by reply > >> e-mail and delete all copies of this message. > >> > >> > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > >> Behalf Of Bound, Jim > >> Sent: mardi 26 f=E9vrier 2008 19:50 > >> To: Basavaraj Patil; Thomas Narten; Nobuo OKABE > >> Cc: John Loughney; ipv6@ietf.org; Fred Baker (fred) > >> Subject: RE: Making IPsec *not* mandatory in Node Requirement > >> > >> For defense in depth scenarios I disagree in the case for the > >> MN to verify with the HA. But I see your point. > >> /jim > >> > >> > >>> -----Original Message----- > >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > >>> Of Basavaraj Patil > >>> Sent: Tuesday, February 26, 2008 12:58 PM > >>> To: Thomas Narten; Nobuo OKABE > >>> Cc: John Loughney; ipv6@ietf.org; fred@cisco.com > >>> Subject: Re: Making IPsec *not* mandatory in Node Requirement > >>> > >>> > >>> I agree with Thomas about his views on IPsec being a mandatory and > >>> default component of the IPv6 stack. > >>> Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec > >>> for securing the signaling. This has lead to complexity of the > >>> protocol and not really helped either in adoption or implementation. > >>> IPsec based security is an overkill for Mobile IPv6 and illustrates > >>> the point that you do not have to use it simply because it > >>> > >> happens to > >> > >>> be an integral part of IPv6. > >>> > >>> -Basavaraj > >>> > >>> > >>> On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: > >>> > >>> > >>>> IMO, we need to get over the idea that IPsec is mandatory in IPv6. > >>>> Really. Or that mandating IPsec is actually useful in practice. > >>>> > >>>> It is the case that mandating IPsec as part of IPv6 has > >>>> > >>> contributed to > >>> > >>>> the hype about how great IPv6 is and how one will get > >>>> > >>> better security > >>> > >>>> with IPv6. Unfortunately, that myth has also harmed the > >>>> > >>> overall IPv6 > >>> > >>>> deployment effort, as people look more closely and come to > >>>> > >>> understand > >>> > >>>> that deploying IPv6 doesn't automatically/easily yield improved > >>>> security. > >>>> > >>>> We all know the reality of security is very different and > >>>> > >> much more > >> > >>>> complicated/nuanced then just saying "use IPsec". > >>>> > >>>> Consider: > >>>> > >>>> IPsec by itself (with no key management) is close to useless. The > >>>> average person cannot configure static keys, so the result is (in > >>>> effect) a useless mandate (as a broad mandate for ALL nodes). > >>>> > >>>> What applications actually make use of IPsec for security? > >>>> > >>> A lot fewer > >>> > >>>> than one might think. For many IPv6 devices/nodes, if one actually > >>>> looks at the applications that will be used on them, they > >>>> > >>> do not use > >>> > >>>> IPsec today for security. And, there are strong/compelling > >>>> > >>> arguments > >>> > >>>> for why IPsec is not the best security solution for many > >>>> > >>> applications. > >>> > >>>> Thus, requiring IPsec is pointless. > >>>> > >>>> To be truly useful, we (of course) need key management. If > >>>> > >>> we want to > >>> > >>>> mandate key management, the stakes go way up. IKEv1/v2 is > >>>> > >>> not a small > >>> > >>>> implementation effort. And, we are now in the funny situation where > >>>> IKEv1 has been implemented, but due to shortcomings, IKEv2 > >>>> > >>> has already > >>> > >>>> been developed. IKEv2 has been out for over 2 years, but > >>>> implementations are not widespread yet. So, would we mandate IKEv1 > >>>> (which is obsoleted and has documented issues), or do we mandate > >>>> IKEv2, even though it is clear it is not widely available yet? > >>>> > >>>> IMO, we should drop the MUST language surrounding IPsec. > >>>> > >>> The technical > >>> > >>>> justification for making it MUST are simply not compelling. > >>>> > >>> It seems > >>> > >>>> to me that the MUST is there primarily for historical/marketing > >>>> reasons. > >>>> > >>>> Note that dropping the MUST will not mean people stop implementing > >>>> IPsec, where there is compelling benefit. Indeed, note > >>>> > >> that the USG > >> > >>>> has already moved away from IKEv1 and has strongly > >>>> > >>> signalled that it > >>> > >>>> will require IKEv2 going forward. So I am confident that IPsec (and > >>>> IKE) will get implemented going forward. > >>>> > >>>> But there is no reason why IPsec should be mandated in > >>>> > >>> devices where > >>> > >>>> it is clear (based on the function/purpose of the device) > >>>> > >>> that IPsec > >>> > >>>> will in fact not actually be used. > >>>> > >>>> As a general "node requirement", SHOULD is the right level, > >>>> > >>> not MUST. > >>> > >>>> Thomas > >>>> > >>>> > >> -------------------------------------------------------------------- > >> > >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>> Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >>>> > >>>> > >> -------------------------------------------------------------------- > >> > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> > >>> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > >> > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 13:04:31 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349F928C766; Tue, 26 Feb 2008 13:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfCIQ4PoyO0C; Tue, 26 Feb 2008 13:04:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0BB3A6C4A; Tue, 26 Feb 2008 13:04:29 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36233A6CDC for ; Tue, 26 Feb 2008 13:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYYAZ80XdaRx for ; Tue, 26 Feb 2008 13:04:27 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8BCA828C503 for ; Tue, 26 Feb 2008 13:04:26 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2008 22:04:20 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1QL4K9O023069; Tue, 26 Feb 2008 22:04:20 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1QL41XN023242; Tue, 26 Feb 2008 21:04:12 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 22:04:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Tue, 26 Feb 2008 22:05:41 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A86010DA2C4@xmb-ams-33d.emea.cisco.com> In-Reply-To: <47C47A76.8040901@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach4uKA1bLaTOMeWRV+VkKGdkOiYPgAAqL2w References: <47C421C3.7070806@innovationslab.net> <47C44024.6050005@sri.com> <47C47A76.8040901@gmail.com> From: "Julien Abeille (jabeille)" To: "Brian E Carpenter" , "Ed Jankiewicz" X-OriginalArrivalTime: 26 Feb 2008 21:04:02.0862 (UTC) FILETIME=[1D7714E0:01C878BB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9594; t=1204059860; x=1204923860; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20the=20role=20of=20the=20node=20=22requi rements=22=20document |Sender:=20; bh=vOMm6czB3m3Jm68rQIPQs79t0pRZS0QCAL6gjlus/Cc=; b=mjDGkZPtNwOq31W63Rbj1NMQ1Q1LPASIgaR/DCSq+RLlSLRhKHUfxrrBew Py5+jyP9rU1RSzQSjRNJFM3NdT7AGnyZA0AhklXd5mH9kwGCmNElNE4obOVv f3gLmCjKG6; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Brian, Please see inline. Cheers, Julien = -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bri= an E Carpenter Sent: mardi 26 f=E9vrier 2008 12:46 To: Ed Jankiewicz Cc: Brian Haberman; ipv6@ietf.org Subject: Re: the role of the node "requirements" document On 2008-02-27 05:36, Ed Jankiewicz wrote: > (full disclosure - I am one of the editors of the DoD IPv6 Profiles = > document - but comments are my own as an individual) > = > 1. Can we discuss the normative level of the revised Node = > Requirements document? My preference would be that it is a standards = > track or BCP ultimately, to give firm definition of what an IPv6 node MUS= T do. > Another INFORMATIONAL document like RFC4294 is merely a helpful = > annotated bibliography, but that may be all we can accomplish in a = > reasonable timeframe, all in all it doesn't make a big difference. I think we have a lot of experience of failure in this area in the IETF (an= d OSI profiles also failed), so I predict that if we try to reach consensus= on this as a standards-track or BCP document, we will fail again. As we of= ten say, in the end it's the market that decides, and each implementor choo= ses what to do for their particular part of the market. I think our job is = to publish clear and consistent specifications. In the present case, they m= ay well say things like If you choose to implement IPsec, here are the RFCs that you MUST/SHOULD/MAY implement. If you choose to implement an IGP, here are the RFCs that you MAY implement. and so on, for things that are not part of the bare minimum. [JA]I like a lot this approach. It allows more solution specific SDOs to sa= y what they take, and fits very fine with our 6lowpan effort to identify th= e "bare minimum". = > = > 2. I don't expect (nor believe it appropriate) that this revision = > will satisfy all the needs of either NIST or DoD for defining "IPv6 Capab= le" > for our client organizations. = Of course not. A requirement spec for an RFP is not the same thing as a gen= eric implementation requirement spec. > That being said, several folks are > already reviewing the three drafts side by side, to help ensure that = > the Node Requirements accurately defines the requirements that apply = > to ALL > IPv6 nodes for ALL deployments. = It may need to define a bare minimum but in addition it certainly needs to = list a whole bunch of options. > The editors of the DoD and NIST > documents should concentrate on the delta from that baseline for = > specific US Government and DoD requirements and deployments. As should anyone else in the RFP business. > = > 3. Specifically with respect to IPsec and IKEv2, regardless of the = > "settlement" of that debate years ago, there are still valid questions = > about which requirements apply to ALL IPv6 nodes. I hope this = > revision of the Node Requirements can reiterate the commitment to = > IPsec, but if it does not, DoD (and NIST) can certainly state stronger = > and more specific requirements in our documents. DoD in particular = > answers to a higher authority on security and cryptographic = > requirements, and will probably require things that a small office or hom= e user would never need. Exactly right, IMHO. Brian C > = > A prior message in this thread (from Jeremy Duncan) included pointers = > to the NIST and DoD profiles drafts, feel free to send any = > questions/comments to the editors off-list. Some of the differences = > are worth discussing on this list to see if there is consensus for = > changes to the Node Requirements draft. Additional work will need to = > be done by the editors of both the DoD and NIST drafts to address the = > specific needs of our clients that don't apply to everyone. > = > Hemant Singh (shemant) wrote: >> Brian, >> >> Indeed, I know that RFC4294 is INFORMATIONAL. I got confused because = >> I see the new node-req-bis draft URL snipped below to be on Standards = >> Track. >> >> http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.t >> xt >> >> Sorry, if I am missing some IETF process. I was expecting the bis = >> draft above to be INFORMATIONAL as well. >> >> Thanks. >> >> Best Regards. >> >> Hemant >> >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = >> Of Brian Haberman >> Sent: Tuesday, February 26, 2008 9:27 AM >> To: ipv6@ietf.org >> Subject: Re: the role of the node "requirements" document >> >> Hemant, >> Take a look at the category for RFC 4294 at = >> http://tools.ietf.org/html/rfc4294. It is Informational and no = >> discussion has occurred to change that classification for this update. >> >> Regards, >> Brian >> >> >> Hemant Singh (shemant) wrote: >> = >>> Pekka, >>> >>> The node requirement draft as I read it from >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01. >>> tx >>> t >>> >>> is on Standards Track. Did I miss anything because you think this = >>> node >>> = >> = >>> requirement doc is an INFORMATIONAL draft? >>> >>> As for IPSec and IPv6, indeed it is true that IPSec is mandatory for = >>> IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is = >>> mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security = >>> Architecture for the Internet Protocol). Snipped from the RFC's is = >>> section 10 shown below between square brackets. >>> >>> [10. Conformance Requirements >>> >>> All IPv4 systems that claim to implement IPsec MUST comply with all >>> requirements of the Security Architecture document. All IPv6 >>> = >> systems >> = >>> MUST comply with all requirements of the Security Architecture >>> document.] >>> >>> I totally appreciate Alain's concern for cable modem devices with = >>> limited memory for IPv6 but the problem is that IPv6 community = >>> decided >>> = >> = >>> as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. >>> Cable IPv6 standards came much later. We will have to see what = >>> common ground can be met to address Alain's concern. >>> >>> Hemant >>> = >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = >>> Of Pekka Savola >>> Sent: Tuesday, February 26, 2008 5:05 AM >>> To: Alain Durand >>> Cc: john.loughney@nokia.com; ipv6@ietf.org; Fred Baker (fred) >>> Subject: the role of the node "requirements" document >>> >>> On Tue, 26 Feb 2008, Alain Durand wrote: >>> = >>>> The problem is that some of those devices have really limited = >>>> memory and they already do (too?) many things, so there is no room lef= t... >>>> Some vendors had to go back at their code and spend a lot of time = >>>> and >>>> = >> = >>>> effort to clean things up to make room for the very basic IPv6 = >>>> code, >>>> = >>> so every kb count. >>> = >>>> The whole idea of asking them to do extra efforts to implement a = >>>> functionality that is not needed and that will introduce bugs & = >>>> instability is not very appealing. >>>> >>>> Again, this last argument applies also to devices that do not have = >>>> memory >>>> problems: if I do not need functionality X, I'd rather like not to = >>>> have it implemented as it will lower the operational risks. >>>> = >>> I think this discussion somewhat misses the point because some folks = >>> feel informational roadmap documents have more weight than they = >>> actually do (according to IETF procedures, or even in practice in >>> = >> vendors' >> = >>> feature planning). (E.g., there was similar discussion about >>> RFC4614.) >>> >>> The node requirements document, despite its misleading title, is = >>> INFORMATIONAL. It does not represent IETF consensus, so even if the = >>> document would say every IPv6 node MUST implement IPsec, it would = >>> mean >>> = >> = >>> basically nothing. >>> >>> Where is a Standards Track or BCP document that says IPsec is >>> = >> mandatory? >> = >>> If vendors need to make tradeoffs of what they implement or don't = >>> implement, that's their call. They can't call that product to be >>> "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, = >>> or claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC = >>> number which mandates IPsec). That's all. >>> >>> The product also might not get IPv6 ready logo certifications and = >>> such, but that's not IETF's business anyway. >>> >>> = >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> = > = -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 13:08:18 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7235328C56D; Tue, 26 Feb 2008 13:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.738 X-Spam-Level: X-Spam-Status: No, score=-100.738 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik5oOCj48i2n; Tue, 26 Feb 2008 13:08:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5EA28C2C6; Tue, 26 Feb 2008 13:08:14 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC55028C306 for ; Tue, 26 Feb 2008 13:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql6gEbUn+ZI3 for ; Tue, 26 Feb 2008 13:08:11 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by core3.amsl.com (Postfix) with ESMTP id 21C753A6CE0 for ; Tue, 26 Feb 2008 13:08:05 -0800 (PST) Received: from g4t0015.houston.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id D33E68090; Tue, 26 Feb 2008 21:07:58 +0000 (UTC) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTP id 3B76D810F; Tue, 26 Feb 2008 21:07:44 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.1.251.1; Tue, 26 Feb 2008 21:06:50 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Tue, 26 Feb 2008 21:06:49 +0000 From: "Bound, Jim" To: "Julien Abeille (jabeille)" , "john.loughney@nokia.com" , "basavaraj.patil@nsn.com" , "narten@us.ibm.com" , "nov@tahi.org" Date: Tue, 26 Feb 2008 21:06:46 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4oSlqZ7s2U+SUEdylSAARJNUNiAABxsSAAABSjHAAAHQjwAAAVViwAAOhkoA= Message-ID: <831FE02B5345194BA8147EDEF5F133882966D087@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Regarding sensors that needs scope there are sensor deployments being plann= ed that will not even use TCP/IP but only layer 1 and 2 except for the gate= way sensor. So can we speak of sensors, sensor nets, sensor instrumentatio= n that is using the TCP/IP protocol to be clear. /jim > -----Original Message----- > From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > Sent: Tuesday, February 26, 2008 2:28 PM > To: john.loughney@nokia.com; Bound, Jim; > basavaraj.patil@nsn.com; narten@us.ibm.com; nov@tahi.org > Cc: ipv6@ietf.org; Fred Baker (fred) > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > Hi John, > > Regarding sensors, > - some applications (e.g. sensors for process control in > factories) require strong security, but dedicated security > mechanism are used (in ISA standard for industrial automation > as an example), the main difference with IPSec being the > importance of the "lightweigt" requirement. A security > mechanism and associated algorithms for such sensors might > use much less processing power, memory... than standard IP mechanisms > - some applications might not require any security, e.g. a > light sensor in your flat might not need it and not implement > it, also due to the very low cost of the sensor. > > Cheers, > John > > > > Julien Abeill=E9 > Software Engineer > Technology Center > jabeille@cisco.com > Fax:+41 21 822 1604 > Cisco Systems International S=E0rl > Av. des Uttins 5 > 1180 Rolle > Switzerland (FR) > www.cisco.com > > > This e-mail may contain confidential and privileged material > for the sole use of the intended recipient. Any review, use, > distribution or disclosure by others is strictly prohibited. > If you are not the intended recipient (or authorized to > receive for the recipient), please contact the sender by > reply e-mail and delete all copies of this message. > > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: mardi 26 f=E9vrier 2008 20:13 > To: Julien Abeille (jabeille); Jim.Bound@hp.com; > basavaraj.patil@nsn.com; narten@us.ibm.com; nov@tahi.org > Cc: ipv6@ietf.org; Fred Baker (fred) > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > Julien and Alain, > > My high-level question to you both is, for sensors and > set-top boxes - do you feel that you do not need security for > any reason? Is this a long-term issue or a short-term issue. > > I can't really think of a reason why security would not be an > issue, but I could be wrong. > > John > > >-----Original Message----- > >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > On Behalf Of > >ext Julien Abeille (jabeille) > >Sent: 26 February, 2008 11:12 > >To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas > Narten; Nobuo > >OKABE > >Cc: Loughney John (Nokia-OCTO/PaloAlto); ipv6@ietf.org; Fred Baker > >(fred) > >Subject: RE: Making IPsec *not* mandatory in Node Requirement > > > >Hi all, > > > >To come back to constrained device, as I already mentionned > on the list > >within 6lowpan, we are working on a draft which documents > the cost of > >each feature mandated by RFC4294, from an implementation perspective > >(target platform is 8bit microcontroller, few 10K ROM, few K RAM). I > >guess as soon as we have results, this might help the discussion. > > > >To give a bit of insight on sensor industry, the market is highly > >fragmented in terms of technology. Most vendors have proprietary L3, > >sometimes proprietary L2, and there are a bunch of standards coming, > >like ZigBee, Z-Wave, ISA, HART... > >One reason for people not to go for IPv6 is "Oh this is too > big for a > >sensor", also because they are not always familiar with IP. > > > >What I want to say is that this kind of question (do we > mandate IPSec) > >is critical for a domain which promises billions of device. > > > >Cheers, > >Julien > > > > > > > > > >Julien Abeill=E9 > >Software Engineer > >Technology Center > >jabeille@cisco.com > >Fax:+41 21 822 1604 > >Cisco Systems International S=E0rl > >Av. des Uttins 5 > >1180 Rolle > >Switzerland (FR) > >www.cisco.com > > > > > >This e-mail may contain confidential and privileged material for the > >sole use of the intended recipient. Any review, use, distribution or > >disclosure by others is strictly prohibited. > >If you are not the intended recipient (or authorized to > receive for the > >recipient), please contact the sender by reply e-mail and delete all > >copies of this message. > > > > > >-----Original Message----- > >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > On Behalf Of > >Bound, Jim > >Sent: mardi 26 f=E9vrier 2008 19:50 > >To: Basavaraj Patil; Thomas Narten; Nobuo OKABE > >Cc: John Loughney; ipv6@ietf.org; Fred Baker (fred) > >Subject: RE: Making IPsec *not* mandatory in Node Requirement > > > >For defense in depth scenarios I disagree in the case for the MN to > >verify with the HA. But I see your point. > >/jim > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > On Behalf > >> Of Basavaraj Patil > >> Sent: Tuesday, February 26, 2008 12:58 PM > >> To: Thomas Narten; Nobuo OKABE > >> Cc: John Loughney; ipv6@ietf.org; fred@cisco.com > >> Subject: Re: Making IPsec *not* mandatory in Node Requirement > >> > >> > >> I agree with Thomas about his views on IPsec being a mandatory and > >> default component of the IPv6 stack. > >> Because of this belief, Mobile IPv6 (RFC3775) design > relied on IPsec > >> for securing the signaling. This has lead to complexity of the > >> protocol and not really helped either in adoption or > implementation. > >> IPsec based security is an overkill for Mobile IPv6 and > illustrates > >> the point that you do not have to use it simply because it > >happens to > >> be an integral part of IPv6. > >> > >> -Basavaraj > >> > >> > >> On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: > >> > >> > IMO, we need to get over the idea that IPsec is > mandatory in IPv6. > >> > Really. Or that mandating IPsec is actually useful in practice. > >> > > >> > It is the case that mandating IPsec as part of IPv6 has > >> contributed to > >> > the hype about how great IPv6 is and how one will get > >> better security > >> > with IPv6. Unfortunately, that myth has also harmed the > >> overall IPv6 > >> > deployment effort, as people look more closely and come to > >> understand > >> > that deploying IPv6 doesn't automatically/easily yield improved > >> > security. > >> > > >> > We all know the reality of security is very different and > >much more > >> > complicated/nuanced then just saying "use IPsec". > >> > > >> > Consider: > >> > > >> > IPsec by itself (with no key management) is close to > useless. The > >> > average person cannot configure static keys, so the result is (in > >> > effect) a useless mandate (as a broad mandate for ALL nodes). > >> > > >> > What applications actually make use of IPsec for security? > >> A lot fewer > >> > than one might think. For many IPv6 devices/nodes, if > one actually > >> > looks at the applications that will be used on them, they > >> do not use > >> > IPsec today for security. And, there are strong/compelling > >> arguments > >> > for why IPsec is not the best security solution for many > >> applications. > >> > Thus, requiring IPsec is pointless. > >> > > >> > To be truly useful, we (of course) need key management. If > >> we want to > >> > mandate key management, the stakes go way up. IKEv1/v2 is > >> not a small > >> > implementation effort. And, we are now in the funny > situation where > >> > IKEv1 has been implemented, but due to shortcomings, IKEv2 > >> has already > >> > been developed. IKEv2 has been out for over 2 years, but > >> > implementations are not widespread yet. So, would we > mandate IKEv1 > >> > (which is obsoleted and has documented issues), or do we mandate > >> > IKEv2, even though it is clear it is not widely available yet? > >> > > >> > IMO, we should drop the MUST language surrounding IPsec. > >> The technical > >> > justification for making it MUST are simply not compelling. > >> It seems > >> > to me that the MUST is there primarily for historical/marketing > >> > reasons. > >> > > >> > Note that dropping the MUST will not mean people stop > implementing > >> > IPsec, where there is compelling benefit. Indeed, note > >that the USG > >> > has already moved away from IKEv1 and has strongly > >> signalled that it > >> > will require IKEv2 going forward. So I am confident that > IPsec (and > >> > IKE) will get implemented going forward. > >> > > >> > But there is no reason why IPsec should be mandated in > >> devices where > >> > it is clear (based on the function/purpose of the device) > >> that IPsec > >> > will in fact not actually be used. > >> > > >> > As a general "node requirement", SHOULD is the right level, > >> not MUST. > >> > > >> > Thomas > >> > > >-------------------------------------------------------------------- > >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >> > Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> > > >-------------------------------------------------------------------- > >> > >> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > >> > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 13:14:07 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F02228C4E2; Tue, 26 Feb 2008 13:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.766 X-Spam-Level: X-Spam-Status: No, score=-100.766 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BObrSRH5gi4w; Tue, 26 Feb 2008 13:14:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1FB28C7A3; Tue, 26 Feb 2008 13:14:01 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305D228C130 for ; Tue, 26 Feb 2008 13:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1dKNHi4hUAY for ; Tue, 26 Feb 2008 13:13:59 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id 8467728C783 for ; Tue, 26 Feb 2008 13:13:58 -0800 (PST) Received: from g1t0029.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id E46F7380A9; Tue, 26 Feb 2008 21:13:51 +0000 (UTC) Received: from G3W0630.americas.hpqcorp.net (g3w0630.americas.hpqcorp.net [16.233.58.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTP id D0A7D380D5; Tue, 26 Feb 2008 21:13:51 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft SMTP Server (TLS) id 8.1.251.1; Tue, 26 Feb 2008 21:13:03 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Tue, 26 Feb 2008 21:13:03 +0000 From: "Bound, Jim" To: Thomas Narten , "Julien Abeille (jabeille)" Date: Tue, 26 Feb 2008 21:13:00 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4siZVGk354qSlT++rhSVGcCebtAACYGkw Message-ID: <831FE02B5345194BA8147EDEF5F133882966D0AB@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> In-Reply-To: <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "john.loughney@nokia.com" , "ipv6@ietf.org" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Example. Bad guy psychopath (medical definition) is able to shut off ones lights or security lighting system comes outside of the through window one did not expect gets in and is 6'8" tall 260 lbs and solid muscle (no fat) and not a nice person :--). Clearly extreme but some want security for the extreme case and do we not want to design for the extreme case too and does the extreme point to a significant or common case? I think if we ask this question what comes back is quite useful. /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Tuesday, February 26, 2008 3:00 PM > To: Julien Abeille (jabeille) > Cc: john.loughney@nokia.com; Bound, Jim; > basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred > Baker (fred) > Subject: Re: Making IPsec *not* mandatory in Node Requirement > > > - some applications might not require any security, e.g. a light > > sensor = in your flat might not need it and not implement > it, also due > > to the = very low cost of the sensor. > > I agree. There is absolutely no need to prevent my neighbor > (or a bad guy outside my window) from being able to > control/influence light sensors in my house. What possible > harm could they do? > > Who needs security anyway! > > :-) > > Thomas > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 13:25:18 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F2928C7CB; Tue, 26 Feb 2008 13:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.753 X-Spam-Level: X-Spam-Status: No, score=-100.753 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFlseDn8KWbE; Tue, 26 Feb 2008 13:25:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F733A6C53; Tue, 26 Feb 2008 13:25:13 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B223A6A59 for ; Tue, 26 Feb 2008 13:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv00I4OeZciO for ; Tue, 26 Feb 2008 13:25:11 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id 0B1523A6C53 for ; Tue, 26 Feb 2008 13:25:10 -0800 (PST) Received: from g1t0029.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id C25563805D; Tue, 26 Feb 2008 21:25:04 +0000 (UTC) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTP id B16C63813A; Tue, 26 Feb 2008 21:25:04 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.1.251.1; Tue, 26 Feb 2008 21:24:14 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Tue, 26 Feb 2008 21:24:14 +0000 From: "Bound, Jim" To: "Julien Abeille (jabeille)" , Thomas Narten Date: Tue, 26 Feb 2008 21:24:12 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sjA8MhAgWE4CRH+KEUv1fVZkRwAAiBIQAAIHCxA= Message-ID: <831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> <38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "john.loughney@nokia.com" , "ipv6@ietf.org" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On the contrary some of the laser sensing capabilities now could be conside= red light so I guess it is what we mean by "light" technically or from a ph= ysics/scientific view I took it to be light controlled by sensors. /jim > -----Original Message----- > From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > Sent: Tuesday, February 26, 2008 3:18 PM > To: Thomas Narten > Cc: john.loughney@nokia.com; Bound, Jim; > basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred > Baker (fred) > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > A sensor can only sense..., you are talking about a light actuator. > > Julien > > > > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: mardi 26 f=E9vrier 2008 12:00 > To: Julien Abeille (jabeille) > Cc: john.loughney@nokia.com; Jim.Bound@hp.com; > basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred > Baker (fred) > Subject: Re: Making IPsec *not* mandatory in Node Requirement > > > - some applications might not require any security, e.g. a light > > sensor =3D in your flat might not need it and not implement > it, also due > > to the =3D very low cost of the sensor. > > I agree. There is absolutely no need to prevent my neighbor > (or a bad guy outside my window) from being able to > control/influence light sensors in my house. What possible > harm could they do? > > Who needs security anyway! > > :-) > > Thomas > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 14:19:26 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452DD3A6CD6; Tue, 26 Feb 2008 14:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MypT1TH8S6Ik; Tue, 26 Feb 2008 14:19:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BA43A68BE; Tue, 26 Feb 2008 14:19:25 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8023A67E7 for ; Tue, 26 Feb 2008 14:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnLjSnt1+s8V for ; Tue, 26 Feb 2008 14:19:20 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BE2013A6BBF for ; Tue, 26 Feb 2008 14:19:19 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2008 23:19:13 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1QMJDGh009586; Tue, 26 Feb 2008 23:19:13 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1QMJ8XL012038; Tue, 26 Feb 2008 22:19:08 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 23:19:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 23:20:46 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> In-Reply-To: <831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sjA8MhAgWE4CRH+KEUv1fVZkRwAAiBIQAAIHCxAAAjUM4A== References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> <38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com> <831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> From: "Julien Abeille (jabeille)" To: "Bound, Jim" , "Thomas Narten" X-OriginalArrivalTime: 26 Feb 2008 22:19:08.0318 (UTC) FILETIME=[9AED1BE0:01C878C5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2041; t=1204064353; x=1204928353; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20Making=20IPsec=20*not*=20mandatory=20in =20Node=20Requirement |Sender:=20; bh=hUfeiCMUsLDEoM7IcAPtBa+fjg9xHklWj9RKWbZxCPw=; b=WsdVbON8GPcCtMS9PGA3tboeEmv59bUAPuM+2qZDsop+FkwEV4K/RVyAOq q0sAy2WdjiKS6rsdSaWSxIDfBoV/pB3wBR+6mtL4L6kgaFyYWDPty1g6GtLj BEBjq0JcA2; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: john.loughney@nokia.com, ipv6@ietf.org, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Fine with this The important point as Kevin Kargel mentions is that there ARE use cases wh= ere security is not required and/or end-to-end security is not required and= /or IPSec is not required. Julien -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] = Sent: mardi 26 f=E9vrier 2008 13:24 To: Julien Abeille (jabeille); Thomas Narten Cc: john.loughney@nokia.com; basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ie= tf.org; Fred Baker (fred) Subject: RE: Making IPsec *not* mandatory in Node Requirement On the contrary some of the laser sensing capabilities now could be conside= red light so I guess it is what we mean by "light" technically or from a ph= ysics/scientific view I took it to be light controlled by sensors. /jim > -----Original Message----- > From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > Sent: Tuesday, February 26, 2008 3:18 PM > To: Thomas Narten > Cc: john.loughney@nokia.com; Bound, Jim; basavaraj.patil@nsn.com; = > nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > A sensor can only sense..., you are talking about a light actuator. > > Julien > > > > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: mardi 26 f=E9vrier 2008 12:00 > To: Julien Abeille (jabeille) > Cc: john.loughney@nokia.com; Jim.Bound@hp.com; = > basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred Baker = > (fred) > Subject: Re: Making IPsec *not* mandatory in Node Requirement > > > - some applications might not require any security, e.g. a light = > > sensor =3D in your flat might not need it and not implement > it, also due > > to the =3D very low cost of the sensor. > > I agree. There is absolutely no need to prevent my neighbor (or a bad = > guy outside my window) from being able to control/influence light = > sensors in my house. What possible harm could they do? > > Who needs security anyway! > > :-) > > Thomas > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 14:36:07 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FE228C4E7; Tue, 26 Feb 2008 14:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4bgXR4-pd2X; Tue, 26 Feb 2008 14:36:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3488F3A67D9; Tue, 26 Feb 2008 14:36:06 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD85528C2FB for ; Tue, 26 Feb 2008 14:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtPIn6ov-QpM for ; Tue, 26 Feb 2008 14:35:58 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 75C533A6ACD for ; Tue, 26 Feb 2008 14:35:58 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1QMZkJD002303; Wed, 27 Feb 2008 00:35:47 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 00:35:45 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 16:35:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 16:35:04 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sjA8MhAgWE4CRH+KEUv1fVZkRwAAiBIQAAIHCxAAAjUM4AAAk03A References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net><38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com><19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com><38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com><200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com><38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com><831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> From: To: X-OriginalArrivalTime: 26 Feb 2008 22:35:16.0625 (UTC) FILETIME=[DC150810:01C878C7] X-Nokia-AV: Clean Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Julien, I guess the point is that some cases and deployment, secuirty is not requir= ed to be used. However, if you are making a product and you do not include security as par= t of the solution, than IPSec then you have a problem. John >Fine with this > >The important point as Kevin Kargel mentions is that there ARE = >use cases where security is not required and/or end-to-end = >security is not required and/or IPSec is not required. > >Julien > >-----Original Message----- >From: Bound, Jim [mailto:Jim.Bound@hp.com] >Sent: mardi 26 f=E9vrier 2008 13:24 >To: Julien Abeille (jabeille); Thomas Narten >Cc: john.loughney@nokia.com; basavaraj.patil@nsn.com; = >nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) >Subject: RE: Making IPsec *not* mandatory in Node Requirement > >On the contrary some of the laser sensing capabilities now = >could be considered light so I guess it is what we mean by = >"light" technically or from a physics/scientific view I took = >it to be light controlled by sensors. > >/jim > >> -----Original Message----- >> From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] >> Sent: Tuesday, February 26, 2008 3:18 PM >> To: Thomas Narten >> Cc: john.loughney@nokia.com; Bound, Jim; basavaraj.patil@nsn.com; = >> nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) >> Subject: RE: Making IPsec *not* mandatory in Node Requirement >> >> A sensor can only sense..., you are talking about a light actuator. >> >> Julien >> >> >> >> -----Original Message----- >> From: Thomas Narten [mailto:narten@us.ibm.com] >> Sent: mardi 26 f=E9vrier 2008 12:00 >> To: Julien Abeille (jabeille) >> Cc: john.loughney@nokia.com; Jim.Bound@hp.com; = >> basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred Baker >> (fred) >> Subject: Re: Making IPsec *not* mandatory in Node Requirement >> >> > - some applications might not require any security, e.g. a light = >> > sensor =3D in your flat might not need it and not implement >> it, also due >> > to the =3D very low cost of the sensor. >> >> I agree. There is absolutely no need to prevent my neighbor = >(or a bad = >> guy outside my window) from being able to control/influence light = >> sensors in my house. What possible harm could they do? >> >> Who needs security anyway! >> >> :-) >> >> Thomas >> >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 15:04:02 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0ED28C45E; Tue, 26 Feb 2008 15:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUFhHaZSTzIt; Tue, 26 Feb 2008 15:04:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4D228C130; Tue, 26 Feb 2008 15:04:01 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145F03A68BD for ; Tue, 26 Feb 2008 15:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2uFQhGfETfr for ; Tue, 26 Feb 2008 15:03:59 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B07DA3A6B55 for ; Tue, 26 Feb 2008 15:03:58 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Feb 2008 00:03:52 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1QN3q8g011243; Wed, 27 Feb 2008 00:03:52 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1QN3lXN021191; Tue, 26 Feb 2008 23:03:52 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 00:03:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Wed, 27 Feb 2008 00:05:27 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A86010DA2E0@xmb-ams-33d.emea.cisco.com> In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sjA8MhAgWE4CRH+KEUv1fVZkRwAAiBIQAAIHCxAAAjUM4AAAk03AAACvlzA= References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net><38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com><19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com><38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com><200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com><38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com><831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> From: "Julien Abeille (jabeille)" To: X-OriginalArrivalTime: 26 Feb 2008 23:03:48.0591 (UTC) FILETIME=[D87E4FF0:01C878CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3322; t=1204067032; x=1204931032; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20Making=20IPsec=20*not*=20mandatory=20in =20Node=20Requirement |Sender:=20; bh=LImxkjv2rdaOqIUGLrJ66G8Si8s59ZGIszk5kjM+m20=; b=j5wnenyRpgw6C0KYurRFNc45VYnu/9xrlQS1b1NLKvdWrXJN+Rl4A19LGw ybAgaSRxp8ORiX52BL1OtJKWy9BW8DvQSpj4rjlw13OpPxc/bgty7p4qDQMR QtsXPGHaBT; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ok, I get it, but I would think this is to be left to the choice of the ven= dor if/how he provides security. = I am in favor of the approach where node requirements rfc defines the bare = minimum for two nodes to be able to talk to each other, then phrase the oth= er sections like setion 6.1, 6.2, i.e. if a node wants to implement securit= y at IP layer, it must use RFCxyz... This might be my 6lowpan view however. Julien = = -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] = Sent: mardi 26 f=E9vrier 2008 14:35 To: Julien Abeille (jabeille) Cc: ipv6@ietf.org Subject: RE: Making IPsec *not* mandatory in Node Requirement Julien, I guess the point is that some cases and deployment, secuirty is not requir= ed to be used. However, if you are making a product and you do not include security as par= t of the solution, than IPSec then you have a problem. John >Fine with this > >The important point as Kevin Kargel mentions is that there ARE use = >cases where security is not required and/or end-to-end security is not = >required and/or IPSec is not required. > >Julien > >-----Original Message----- >From: Bound, Jim [mailto:Jim.Bound@hp.com] >Sent: mardi 26 f=E9vrier 2008 13:24 >To: Julien Abeille (jabeille); Thomas Narten >Cc: john.loughney@nokia.com; basavaraj.patil@nsn.com; nov@tahi.org; = >ipv6@ietf.org; Fred Baker (fred) >Subject: RE: Making IPsec *not* mandatory in Node Requirement > >On the contrary some of the laser sensing capabilities now could be = >considered light so I guess it is what we mean by "light" technically = >or from a physics/scientific view I took it to be light controlled by = >sensors. > >/jim > >> -----Original Message----- >> From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] >> Sent: Tuesday, February 26, 2008 3:18 PM >> To: Thomas Narten >> Cc: john.loughney@nokia.com; Bound, Jim; basavaraj.patil@nsn.com; = >> nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) >> Subject: RE: Making IPsec *not* mandatory in Node Requirement >> >> A sensor can only sense..., you are talking about a light actuator. >> >> Julien >> >> >> >> -----Original Message----- >> From: Thomas Narten [mailto:narten@us.ibm.com] >> Sent: mardi 26 f=E9vrier 2008 12:00 >> To: Julien Abeille (jabeille) >> Cc: john.loughney@nokia.com; Jim.Bound@hp.com; = >> basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred Baker >> (fred) >> Subject: Re: Making IPsec *not* mandatory in Node Requirement >> >> > - some applications might not require any security, e.g. a light = >> > sensor =3D in your flat might not need it and not implement >> it, also due >> > to the =3D very low cost of the sensor. >> >> I agree. There is absolutely no need to prevent my neighbor >(or a bad >> guy outside my window) from being able to control/influence light = >> sensors in my house. What possible harm could they do? >> >> Who needs security anyway! >> >> :-) >> >> Thomas >> >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 15:08:22 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4892128C82D; Tue, 26 Feb 2008 15:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTZlAHXV6vaN; Tue, 26 Feb 2008 15:08:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146623A697B; Tue, 26 Feb 2008 15:08:20 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C813A67D9 for ; Tue, 26 Feb 2008 15:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwmEjG94MF2K for ; Tue, 26 Feb 2008 15:08:17 -0800 (PST) Received: from mailgate-internal2.sri.com (mailgate-internal2.SRI.COM [128.18.84.104]) by core3.amsl.com (Postfix) with SMTP id ED1863A6C4A for ; Tue, 26 Feb 2008 15:07:47 -0800 (PST) Received: from localhost (HELO mailgate-internal2.SRI.COM) (127.0.0.1) by mailgate-internal2.sri.com with SMTP; 26 Feb 2008 23:07:41 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal2.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2008022615074019762 for ; Tue, 26 Feb 2008 15:07:40 -0800 Received: from [192.168.2.105] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JWV0094TC8SVAPZ@mail.sri.com> for ipv6@ietf.org; Tue, 26 Feb 2008 15:07:41 -0800 (PST) Date: Tue, 26 Feb 2008 18:07:41 -0500 From: Ed Jankiewicz Subject: Re: Making IPsec *not* mandatory in Node Requirement In-reply-to: <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> To: ipv6@ietf.org Message-id: <47C49BBD.7060008@sri.com> MIME-version: 1.0 References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> <831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> <38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com> <831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Cc: john.loughney@nokia.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org That is a good point, does IPsec depend on unanimous support? We = struggled with this in the DoD Profiles. Our rationale for making IPsec = mandatory (except at the moment for some simple appliances) was that for = IPsec to be a feasible solution it needs to be available throughout the = network. We want it to be universally available so that it CAN be used = when required. With end-to-end, any two hosts could use IPsec as a = solution even if no one else supported it, assuming that nothing in the = network blocks its use. However, given recent news items about ISPs and = governments wanting to block or throttle certain content, it seems they = might also want to block something that could hide that content from = their prying eyes. = Even if the revision were to relax the requirement for IPsec (and I = don't suggest it should) I believe there should be a strong statement = about non-interference in the Node Requirements so that consenting hosts = can count on the delivery of packets with IPsec options. As Thomas said a while back, de-mandating IPsec would not make it go = away, nor would it remove market incentive for vendors to implement it, = so existing and new implementations would still be available. DoD would = likely still require it in products, so if a vendor wanted to sell to = DoD it would be in their interest to include IPsec. As always, just my = personal opinion, not to be construed as policy... Ed J. john.loughney@nokia.com wrote: > Julien, > > I guess the point is that some cases and deployment, secuirty is not requ= ired to be used. > However, if you are making a product and you do not include security as p= art of the solution, > than IPSec then you have a problem. > > John > > = >> Fine with this >> >> The important point as Kevin Kargel mentions is that there ARE = >> use cases where security is not required and/or end-to-end = >> security is not required and/or IPSec is not required. >> >> Julien >> >> -----Original Message----- >> From: Bound, Jim [mailto:Jim.Bound@hp.com] >> Sent: mardi 26 f=E9vrier 2008 13:24 >> To: Julien Abeille (jabeille); Thomas Narten >> Cc: john.loughney@nokia.com; basavaraj.patil@nsn.com; = >> nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) >> Subject: RE: Making IPsec *not* mandatory in Node Requirement >> >> On the contrary some of the laser sensing capabilities now = >> could be considered light so I guess it is what we mean by = >> "light" technically or from a physics/scientific view I took = >> it to be light controlled by sensors. >> >> /jim >> >> = >>> -----Original Message----- >>> From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] >>> Sent: Tuesday, February 26, 2008 3:18 PM >>> To: Thomas Narten >>> Cc: john.loughney@nokia.com; Bound, Jim; basavaraj.patil@nsn.com; = >>> nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) >>> Subject: RE: Making IPsec *not* mandatory in Node Requirement >>> >>> A sensor can only sense..., you are talking about a light actuator. >>> >>> Julien >>> >>> >>> >>> -----Original Message----- >>> From: Thomas Narten [mailto:narten@us.ibm.com] >>> Sent: mardi 26 f=E9vrier 2008 12:00 >>> To: Julien Abeille (jabeille) >>> Cc: john.loughney@nokia.com; Jim.Bound@hp.com; = >>> basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred Baker >>> (fred) >>> Subject: Re: Making IPsec *not* mandatory in Node Requirement >>> >>> = >>>> - some applications might not require any security, e.g. a light = >>>> sensor =3D in your flat might not need it and not implement >>>> = >>> it, also due >>> = >>>> to the =3D very low cost of the sensor. >>>> = >>> I agree. There is absolutely no need to prevent my neighbor = >>> = >> (or a bad = >> = >>> guy outside my window) from being able to control/influence light = >>> sensors in my house. What possible harm could they do? >>> >>> Who needs security anyway! >>> >>> :-) >>> >>> Thomas >>> >>> = >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> = > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > = -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 15:08:27 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A0528C85C; Tue, 26 Feb 2008 15:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTq1mw9mFSeE; Tue, 26 Feb 2008 15:08:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4DC28C734; Tue, 26 Feb 2008 15:08:21 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98203A6C3D for ; Tue, 26 Feb 2008 15:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAThK1HQDIhq for ; Tue, 26 Feb 2008 15:08:18 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AE3823A6C86 for ; Tue, 26 Feb 2008 15:08:10 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1QN8pwp001364; Tue, 26 Feb 2008 17:09:36 -0600 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 01:07:50 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 17:07:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 17:07:27 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A010C4A96@daebe104.NOE.Nokia.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86010DA2E0@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sjA8MhAgWE4CRH+KEUv1fVZkRwAAiBIQAAIHCxAAAjUM4AAAk03AAACvlzAAAG8t4A== References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net><38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com><19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com><38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com><200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com><38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com><831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA2E0@xmb-ams-33d.emea.cisco.com> From: To: X-OriginalArrivalTime: 26 Feb 2008 23:07:47.0955 (UTC) FILETIME=[672A5C30:01C878CC] X-Nokia-AV: Clean Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Julien, >Ok, I get it, but I would think this is to be left to the >choice of the vendor if/how he provides security. > >I am in favor of the approach where node requirements rfc >defines the bare minimum for two nodes to be able to talk to >each other, then phrase the other sections like setion 6.1, >6.2, i.e. if a node wants to implement security at IP layer, >it must use RFCxyz... >This might be my 6lowpan view however. I think that it is always good to have some common mechanism, if we are talking about interoperability. If you are making a sensor that implements one kind of security, while I make a server that implements another kind of security, the end result is that our two implementations cannot talk to each other securely, even though we are both 'complient' to the Node Req. RFC. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 15:32:50 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7E53A6B68; Tue, 26 Feb 2008 15:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9Z-nbq67V-K; Tue, 26 Feb 2008 15:32:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157903A6878; Tue, 26 Feb 2008 15:32:49 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9027B3A67A1 for ; Tue, 26 Feb 2008 15:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu3oXcl-2ztt for ; Tue, 26 Feb 2008 15:32:46 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id EBEA13A6B68 for ; Tue, 26 Feb 2008 15:32:43 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m1QNWM3M002530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Feb 2008 15:32:28 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m1QNWMte005837; Tue, 26 Feb 2008 15:32:22 -0800 (PST) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m1QNWMP6005815; Tue, 26 Feb 2008 15:32:22 -0800 (PST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 18:32:21 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 18:32:21 -0500 Message-ID: In-Reply-To: <47C49BBD.7060008@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4zJY8U9r/9LUtR8aoWvjKPBF1vAAAVPRQ References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net><38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com><19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com><38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com><200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com><38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com><831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net><38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com><19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> <47C49BBD.7060008@sri.com> From: "Manfredi, Albert E" To: "Ed Jankiewicz" , X-OriginalArrivalTime: 26 Feb 2008 23:32:21.0400 (UTC) FILETIME=[D5683980:01C878CF] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Ed Jankiewicz [mailto:edward.jankiewicz@sri.com] > That is a good point, does IPsec depend on unanimous support? We > struggled with this in the DoD Profiles. Our rationale for > making IPsec > mandatory (except at the moment for some simple appliances) > was that for > IPsec to be a feasible solution it needs to be available > throughout the > network. We want it to be universally available so that it > CAN be used > when required. Take the case of network routers in non-secure spaces. This should be a VERY common situation. Let's assume that I use some form of hardware encryption for everything traveling between routers, mainly to protect the routing protocol, but also apply this encryption to any traffic. This could be more than adequate for such a network, and it avoids the need for IKEv2 in the routers. Or forget hardware encryption. I can also use means other than IKEv2 to identify the crypto algorithm used between my routers, if I have control of router configuration but these routers may be in non-secure spaces. Even manual configuration, if the network is not huge. Or SNMP. > With end-to-end, any two hosts could use IPsec as a > solution even if no one else supported it, assuming that > nothing in the > network blocks its use. And this solution doesn't prevent end-to-end IPsec in any way. And yet, the NIST Profile does not allow the above possibilities. My fundamental position is that for real, meaningful security, you either need IPsec between hosts, or at very least you need IPsec between "security gateways" that are themselves located in secure spaces, *along with* the hosts. In short, when routers are in non-secure speaces, there's no way you'll get "security" if you allow only plaintext to these routers. The onus of IP security goes mostly to hosts or the security gateways. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 15:58:08 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B7D28C38C; Tue, 26 Feb 2008 15:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNt0M6x8300l; Tue, 26 Feb 2008 15:58:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53003A6CB4; Tue, 26 Feb 2008 15:58:02 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915D73A697B for ; Tue, 26 Feb 2008 15:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CVGVtRSyqKK for ; Tue, 26 Feb 2008 15:58:00 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id CE42E3A6CC4 for ; Tue, 26 Feb 2008 15:57:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BDDB4A9165 for ; Tue, 26 Feb 2008 15:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+mSRPXnwwbv for ; Tue, 26 Feb 2008 15:57:06 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 00255A9322 for ; Tue, 26 Feb 2008 15:57:05 -0800 (PST) Message-ID: <47C4A74E.4000807@archrock.com> Date: Tue, 26 Feb 2008 15:57:02 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ipv6@ietf.org Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory in Node Requirement) References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net><38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com><19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com><38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com><200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com><38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com><831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I won't argue against the fact that security is an important part of a complete solution. The question for me is whether IPsec is the most appropriate solution for highly constrained embedded devices (constrained in energy, memory, compute, and link capabilities). From the few implementation numbers thrown around this thread, it sounds like IPsec is not an option for low-power wireless nodes with 8K RAM, 48K ROM, 128B link MTU, and not to mention that any implementation should leave enough space for an interesting application and should operate for multiple years on modest batteries. One nice thing is that, given some application scenarios, there are other ways to incorporate sufficient security without the need for IPsec. For example, link-layer security may be sufficient for private networks. Link-layer security may also be sufficient if border routers/gateways attach to other traditional IP networks via encrypted tunnels. I'm not a security expert, nor do I know the complete workings of IPsec. But I'd be curious if people strongly believe or have ideas on ways to squeeze IPsec into devices that I'm interested in. If not, is it at all possible to consider developing an alternative end-to-end security mechanism that is lightweight. I'm not arguing that this should be used between two traditional IP hosts, but that it can be used between a traditional IP host communicating with a low-power, wireless device or two low-power wireless devices communicating directly. Gordon Bell observed that we've seen a new class of computing form about every decade. IP has so far been able to follow these trends, including hand held devices. Now we are at the beginning of yet another class with low-power wireless devices based on IEEE 802.15.4, and the 6lowpan effort within the IETF has set out to bring IPv6 to this new class. I'd be disappointed if we couldn't come to an agreement on how we can appropriately bring this new class into the IP framework. -- Jonathan Hui -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 18:01:27 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CA028C2B6; Tue, 26 Feb 2008 18:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.629 X-Spam-Level: * X-Spam-Status: No, score=1.629 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5yc2aAfgiaI; Tue, 26 Feb 2008 18:01:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97F63A6CAB; Tue, 26 Feb 2008 18:01:25 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1043F3A6CAB for ; Tue, 26 Feb 2008 18:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtmy0IJ6x7KU for ; Tue, 26 Feb 2008 18:01:23 -0800 (PST) Received: from pacdcimo02.cable.comcast.com (PacdcIMO02.cable.comcast.com [24.40.8.146]) by core3.amsl.com (Postfix) with ESMTP id 9E14F3A695D for ; Tue, 26 Feb 2008 18:01:23 -0800 (PST) Received: from ([24.40.15.118]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.17247979; Tue, 26 Feb 2008 21:01:04 -0500 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 21:01:04 -0500 Received: from 169.223.13.205 ([169.223.13.205]) by PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Feb 2008 02:01:03 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Wed, 27 Feb 2008 10:01:00 +0800 Subject: Re: Making IPsec *not* mandatory in Node Requirement From: Alain Durand To: , , , , , Message-ID: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4oSlqZ7s2U+SUEdylSAARJNUNiAABxsSAAABSjHAAAHQjwAAOToY0 In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> Mime-version: 1.0 X-OriginalArrivalTime: 27 Feb 2008 02:01:04.0586 (UTC) FILETIME=[9C0A5AA0:01C878E4] Cc: ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org John, Clarification: I am not talking about set top box, but cable modems. Very different beast. - Alain. On 2/27/08 3:12 AM, "john.loughney@nokia.com" wrote: > Julien and Alain, > = > My high-level question to you both is, for sensors and set-top > boxes - do you feel that you do not need security for any > reason? Is this a long-term issue or a short-term issue. > = > I can't really think of a reason why security would not be an > issue, but I could be wrong. > = > John > = >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >> Behalf Of ext Julien Abeille (jabeille) >> Sent: 26 February, 2008 11:12 >> To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas >> Narten; Nobuo OKABE >> Cc: Loughney John (Nokia-OCTO/PaloAlto); ipv6@ietf.org; Fred >> Baker (fred) >> Subject: RE: Making IPsec *not* mandatory in Node Requirement >> = >> Hi all, >> = >> To come back to constrained device, as I already mentionned on >> the list within 6lowpan, we are working on a draft which >> documents the cost of each feature mandated by RFC4294, from >> an implementation perspective (target platform is 8bit >> microcontroller, few 10K ROM, few K RAM). I guess as soon as >> we have results, this might help the discussion. >> = >> To give a bit of insight on sensor industry, the market is >> highly fragmented in terms of technology. Most vendors have >> proprietary L3, sometimes proprietary L2, and there are a >> bunch of standards coming, like ZigBee, Z-Wave, ISA, HART... >> One reason for people not to go for IPv6 is "Oh this is too >> big for a sensor", also because they are not always familiar with IP. >> = >> What I want to say is that this kind of question (do we >> mandate IPSec) is critical for a domain which promises >> billions of device. >> = >> Cheers, >> Julien >> = >> = >> = >> = >> Julien Abeill=E9 >> Software Engineer >> Technology Center >> jabeille@cisco.com >> Fax:+41 21 822 1604 >> Cisco Systems International S=E0rl >> Av. des Uttins 5 >> 1180 Rolle >> Switzerland (FR) >> www.cisco.com >> = >> = >> This e-mail may contain confidential and privileged material >> for the sole use of the intended recipient. Any review, use, >> distribution or disclosure by others is strictly prohibited. >> If you are not the intended recipient (or authorized to >> receive for the recipient), please contact the sender by reply >> e-mail and delete all copies of this message. >> = >> = >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >> Behalf Of Bound, Jim >> Sent: mardi 26 f=E9vrier 2008 19:50 >> To: Basavaraj Patil; Thomas Narten; Nobuo OKABE >> Cc: John Loughney; ipv6@ietf.org; Fred Baker (fred) >> Subject: RE: Making IPsec *not* mandatory in Node Requirement >> = >> For defense in depth scenarios I disagree in the case for the >> MN to verify with the HA. But I see your point. >> /jim >> = >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf >>> Of Basavaraj Patil >>> Sent: Tuesday, February 26, 2008 12:58 PM >>> To: Thomas Narten; Nobuo OKABE >>> Cc: John Loughney; ipv6@ietf.org; fred@cisco.com >>> Subject: Re: Making IPsec *not* mandatory in Node Requirement >>> = >>> = >>> I agree with Thomas about his views on IPsec being a mandatory and >>> default component of the IPv6 stack. >>> Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec >>> for securing the signaling. This has lead to complexity of the >>> protocol and not really helped either in adoption or implementation. >>> IPsec based security is an overkill for Mobile IPv6 and illustrates >>> the point that you do not have to use it simply because it >> happens to >>> be an integral part of IPv6. >>> = >>> -Basavaraj >>> = >>> = >>> On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: >>> = >>>> IMO, we need to get over the idea that IPsec is mandatory in IPv6. >>>> Really. Or that mandating IPsec is actually useful in practice. >>>> = >>>> It is the case that mandating IPsec as part of IPv6 has >>> contributed to >>>> the hype about how great IPv6 is and how one will get >>> better security >>>> with IPv6. Unfortunately, that myth has also harmed the >>> overall IPv6 >>>> deployment effort, as people look more closely and come to >>> understand >>>> that deploying IPv6 doesn't automatically/easily yield improved >>>> security. >>>> = >>>> We all know the reality of security is very different and >> much more >>>> complicated/nuanced then just saying "use IPsec". >>>> = >>>> Consider: >>>> = >>>> IPsec by itself (with no key management) is close to useless. The >>>> average person cannot configure static keys, so the result is (in >>>> effect) a useless mandate (as a broad mandate for ALL nodes). >>>> = >>>> What applications actually make use of IPsec for security? >>> A lot fewer >>>> than one might think. For many IPv6 devices/nodes, if one actually >>>> looks at the applications that will be used on them, they >>> do not use >>>> IPsec today for security. And, there are strong/compelling >>> arguments >>>> for why IPsec is not the best security solution for many >>> applications. >>>> Thus, requiring IPsec is pointless. >>>> = >>>> To be truly useful, we (of course) need key management. If >>> we want to >>>> mandate key management, the stakes go way up. IKEv1/v2 is >>> not a small >>>> implementation effort. And, we are now in the funny situation where >>>> IKEv1 has been implemented, but due to shortcomings, IKEv2 >>> has already >>>> been developed. IKEv2 has been out for over 2 years, but >>>> implementations are not widespread yet. So, would we mandate IKEv1 >>>> (which is obsoleted and has documented issues), or do we mandate >>>> IKEv2, even though it is clear it is not widely available yet? >>>> = >>>> IMO, we should drop the MUST language surrounding IPsec. >>> The technical >>>> justification for making it MUST are simply not compelling. >>> It seems >>>> to me that the MUST is there primarily for historical/marketing >>>> reasons. >>>> = >>>> Note that dropping the MUST will not mean people stop implementing >>>> IPsec, where there is compelling benefit. Indeed, note >> that the USG >>>> has already moved away from IKEv1 and has strongly >>> signalled that it >>>> will require IKEv2 going forward. So I am confident that IPsec (and >>>> IKE) will get implemented going forward. >>>> = >>>> But there is no reason why IPsec should be mandated in >>> devices where >>>> it is clear (based on the function/purpose of the device) >>> that IPsec >>>> will in fact not actually be used. >>>> = >>>> As a general "node requirement", SHOULD is the right level, >>> not MUST. >>>> = >>>> Thomas >>>> = >> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>>> = >> -------------------------------------------------------------------- >>> = >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> = >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> = > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 20:23:16 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BD228C3A1; Tue, 26 Feb 2008 20:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.772 X-Spam-Level: X-Spam-Status: No, score=-100.772 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLm4q-lhW8fF; Tue, 26 Feb 2008 20:23:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9313A6D3C; Tue, 26 Feb 2008 20:23:14 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682943A6D83 for ; Tue, 26 Feb 2008 20:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwbNkZtiFapa for ; Tue, 26 Feb 2008 20:23:11 -0800 (PST) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by core3.amsl.com (Postfix) with ESMTP id 1B8BE3A6981 for ; Tue, 26 Feb 2008 20:22:31 -0800 (PST) Received: from g1t0028.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 298881C487; Wed, 27 Feb 2008 04:22:25 +0000 (UTC) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTP id 097AF1C3D8; Wed, 27 Feb 2008 04:22:15 +0000 (UTC) Received: from G3W0058.americas.hpqcorp.net (16.232.1.3) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.1.251.1; Wed, 27 Feb 2008 04:21:10 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0058.americas.hpqcorp.net ([16.232.1.3]) with mapi; Wed, 27 Feb 2008 04:21:10 +0000 From: "Bound, Jim" To: "Julien Abeille (jabeille)" , Thomas Narten Date: Wed, 27 Feb 2008 04:21:08 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sjA8MhAgWE4CRH+KEUv1fVZkRwAAiBIQAAIHCxAAAjUM4AAMujHg Message-ID: <831FE02B5345194BA8147EDEF5F133882966D4CD@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> <38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com> <831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "john.loughney@nokia.com" , "ipv6@ietf.org" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Agreed. /jim > -----Original Message----- > From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > Sent: Tuesday, February 26, 2008 5:21 PM > To: Bound, Jim; Thomas Narten > Cc: john.loughney@nokia.com; basavaraj.patil@nsn.com; > nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > Fine with this > > The important point as Kevin Kargel mentions is that there > ARE use cases where security is not required and/or > end-to-end security is not required and/or IPSec is not required. > > Julien > > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: mardi 26 f=E9vrier 2008 13:24 > To: Julien Abeille (jabeille); Thomas Narten > Cc: john.loughney@nokia.com; basavaraj.patil@nsn.com; > nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > On the contrary some of the laser sensing capabilities now > could be considered light so I guess it is what we mean by > "light" technically or from a physics/scientific view I took > it to be light controlled by sensors. > > /jim > > > -----Original Message----- > > From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > > Sent: Tuesday, February 26, 2008 3:18 PM > > To: Thomas Narten > > Cc: john.loughney@nokia.com; Bound, Jim; basavaraj.patil@nsn.com; > > nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) > > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > > > A sensor can only sense..., you are talking about a light actuator. > > > > Julien > > > > > > > > -----Original Message----- > > From: Thomas Narten [mailto:narten@us.ibm.com] > > Sent: mardi 26 f=E9vrier 2008 12:00 > > To: Julien Abeille (jabeille) > > Cc: john.loughney@nokia.com; Jim.Bound@hp.com; > > basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred Baker > > (fred) > > Subject: Re: Making IPsec *not* mandatory in Node Requirement > > > > > - some applications might not require any security, e.g. a light > > > sensor =3D in your flat might not need it and not implement > > it, also due > > > to the =3D very low cost of the sensor. > > > > I agree. There is absolutely no need to prevent my neighbor > (or a bad > > guy outside my window) from being able to control/influence light > > sensors in my house. What possible harm could they do? > > > > Who needs security anyway! > > > > :-) > > > > Thomas > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 20:26:55 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD44B3A6A38; Tue, 26 Feb 2008 20:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.731 X-Spam-Level: X-Spam-Status: No, score=-100.731 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GatBfX1E6JDZ; Tue, 26 Feb 2008 20:26:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9E73A6A49; Tue, 26 Feb 2008 20:26:53 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB90D3A6A49 for ; Tue, 26 Feb 2008 20:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDFJQZH3T8L3 for ; Tue, 26 Feb 2008 20:26:51 -0800 (PST) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by core3.amsl.com (Postfix) with ESMTP id E54AC3A6A38 for ; Tue, 26 Feb 2008 20:26:50 -0800 (PST) Received: from g1t0028.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 868411C487; Wed, 27 Feb 2008 04:26:44 +0000 (UTC) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTP id 7FB4A1C3D8; Wed, 27 Feb 2008 04:26:44 +0000 (UTC) Received: from G3W0058.americas.hpqcorp.net (16.232.1.3) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.1.251.1; Wed, 27 Feb 2008 04:25:28 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0058.americas.hpqcorp.net ([16.232.1.3]) with mapi; Wed, 27 Feb 2008 04:25:28 +0000 From: "Bound, Jim" To: "Julien Abeille (jabeille)" , "john.loughney@nokia.com" Date: Wed, 27 Feb 2008 04:25:26 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4sjA8MhAgWE4CRH+KEUv1fVZkRwAAiBIQAAIHCxAAAjUM4AAAk03AAACvlzAAC33+EA== Message-ID: <831FE02B5345194BA8147EDEF5F133882966D4CE@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net><38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com><19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com><38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com><200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com><38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com><831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA2E0@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86010DA2E0@xmb-ams-33d.emea.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is clearly the path of least resistance to achieve consensus too and e= cumenical in this community to achieve a common agreement. In this case le= ss could be better (Mark Twain shorter please) but we need to be sure we do= not have bugs and have to rev biz updates every 6 months if we are to ever= get to a completed work. Or maybe a completed work is not the objective b= ut a living document? I don't think our technical job will be that hard if= we agree on scope and approach with the talent/knowledge on this list. /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Julien Abeille (jabeille) > Sent: Tuesday, February 26, 2008 6:05 PM > To: john.loughney@nokia.com > Cc: ipv6@ietf.org > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > Ok, I get it, but I would think this is to be left to the > choice of the vendor if/how he provides security. > > I am in favor of the approach where node requirements rfc > defines the bare minimum for two nodes to be able to talk to > each other, then phrase the other sections like setion 6.1, > 6.2, i.e. if a node wants to implement security at IP layer, > it must use RFCxyz... > This might be my 6lowpan view however. > > Julien > > > > > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: mardi 26 f=E9vrier 2008 14:35 > To: Julien Abeille (jabeille) > Cc: ipv6@ietf.org > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > Julien, > > I guess the point is that some cases and deployment, secuirty > is not required to be used. > However, if you are making a product and you do not include > security as part of the solution, than IPSec then you have a problem. > > John > > >Fine with this > > > >The important point as Kevin Kargel mentions is that there ARE use > >cases where security is not required and/or end-to-end > security is not > >required and/or IPSec is not required. > > > >Julien > > > >-----Original Message----- > >From: Bound, Jim [mailto:Jim.Bound@hp.com] > >Sent: mardi 26 f=E9vrier 2008 13:24 > >To: Julien Abeille (jabeille); Thomas Narten > >Cc: john.loughney@nokia.com; basavaraj.patil@nsn.com; nov@tahi.org; > >ipv6@ietf.org; Fred Baker (fred) > >Subject: RE: Making IPsec *not* mandatory in Node Requirement > > > >On the contrary some of the laser sensing capabilities now could be > >considered light so I guess it is what we mean by "light" > technically > >or from a physics/scientific view I took it to be light > controlled by > >sensors. > > > >/jim > > > >> -----Original Message----- > >> From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > >> Sent: Tuesday, February 26, 2008 3:18 PM > >> To: Thomas Narten > >> Cc: john.loughney@nokia.com; Bound, Jim; basavaraj.patil@nsn.com; > >> nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) > >> Subject: RE: Making IPsec *not* mandatory in Node Requirement > >> > >> A sensor can only sense..., you are talking about a light actuator. > >> > >> Julien > >> > >> > >> > >> -----Original Message----- > >> From: Thomas Narten [mailto:narten@us.ibm.com] > >> Sent: mardi 26 f=E9vrier 2008 12:00 > >> To: Julien Abeille (jabeille) > >> Cc: john.loughney@nokia.com; Jim.Bound@hp.com; > >> basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred Baker > >> (fred) > >> Subject: Re: Making IPsec *not* mandatory in Node Requirement > >> > >> > - some applications might not require any security, e.g. a light > >> > sensor =3D in your flat might not need it and not implement > >> it, also due > >> > to the =3D very low cost of the sensor. > >> > >> I agree. There is absolutely no need to prevent my neighbor > >(or a bad > >> guy outside my window) from being able to control/influence light > >> sensors in my house. What possible harm could they do? > >> > >> Who needs security anyway! > >> > >> :-) > >> > >> Thomas > >> > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 20:37:01 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630BE3A6D97; Tue, 26 Feb 2008 20:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.733 X-Spam-Level: X-Spam-Status: No, score=-100.733 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJH1dlB3-rnE; Tue, 26 Feb 2008 20:37:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299DD3A6D79; Tue, 26 Feb 2008 20:37:00 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E76A3A6906 for ; Tue, 26 Feb 2008 20:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz0opDUtavSl for ; Tue, 26 Feb 2008 20:36:57 -0800 (PST) Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by core3.amsl.com (Postfix) with ESMTP id CB7ED3A6A04 for ; Tue, 26 Feb 2008 20:36:56 -0800 (PST) Received: from g4t0016.houston.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 4006C147CA; Wed, 27 Feb 2008 04:36:50 +0000 (UTC) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTP id 2AED114A1E; Wed, 27 Feb 2008 04:36:50 +0000 (UTC) Received: from G3W0055.americas.hpqcorp.net (16.232.1.152) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.1.251.1; Wed, 27 Feb 2008 04:35:49 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0055.americas.hpqcorp.net ([16.232.1.152]) with mapi; Wed, 27 Feb 2008 04:35:49 +0000 From: "Bound, Jim" To: Ed Jankiewicz , "ipv6@ietf.org" Date: Wed, 27 Feb 2008 04:35:47 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4zIlyxeO8CrvrQMiCAHRNieDDtgALG3JQ Message-ID: <831FE02B5345194BA8147EDEF5F133882966D4D1@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> <831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com> <200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com> <38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com> <831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> <47C49BBD.7060008@sri.com> In-Reply-To: <47C49BBD.7060008@sri.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "john.loughney@nokia.com" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I don't think unanimous support is needed just the support within the domai= n of use and that could be a private or public network with collaboration w= ith the firewall rules at the edge or the node directly in the case of p2p.= On the issue of e2e encrypt/decrypt except the header there are those for= many reasons will not want to permit this for the reasons you state is my = experience. But do we take social and law enforcement issues into considera= tion as IETF individuals? We had this debate some time ago and I believe th= e answer with consensus today might be different. Once while presenting at = some form of NGN conference in London on e2e a person who identified them a= s Law Enforcement asked me if this e2e security existed would that permit b= ad persons to also be able to do this too (this was after 911) and had to s= ay yes with the caveat I am identifying the technology capability not the s= ocial consequences, which is a discussion typically left to the market and = those who enforce laws. But yes the same technology we define for good rea= sons always can be used for bad reasons. But I don't think not doing e2e i= s going to stop bad intentioned criminals. /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Ed Jankiewicz > Sent: Tuesday, February 26, 2008 6:08 PM > To: ipv6@ietf.org > Cc: john.loughney@nokia.com > Subject: Re: Making IPsec *not* mandatory in Node Requirement > > That is a good point, does IPsec depend on unanimous support? > We struggled with this in the DoD Profiles. Our rationale > for making IPsec mandatory (except at the moment for some > simple appliances) was that for IPsec to be a feasible > solution it needs to be available throughout the network. We > want it to be universally available so that it CAN be used > when required. With end-to-end, any two hosts could use > IPsec as a solution even if no one else supported it, > assuming that nothing in the network blocks its use. > However, given recent news items about ISPs and governments > wanting to block or throttle certain content, it seems they > might also want to block something that could hide that > content from their prying eyes. > > Even if the revision were to relax the requirement for IPsec > (and I don't suggest it should) I believe there should be a > strong statement about non-interference in the Node > Requirements so that consenting hosts can count on the > delivery of packets with IPsec options. > > As Thomas said a while back, de-mandating IPsec would not > make it go away, nor would it remove market incentive for > vendors to implement it, so existing and new implementations > would still be available. DoD would likely still require it > in products, so if a vendor wanted to sell to DoD it would be > in their interest to include IPsec. As always, just my > personal opinion, not to be construed as policy... > > Ed J. > > john.loughney@nokia.com wrote: > > Julien, > > > > I guess the point is that some cases and deployment, > secuirty is not required to be used. > > However, if you are making a product and you do not include > security > > as part of the solution, than IPSec then you have a problem. > > > > John > > > > > >> Fine with this > >> > >> The important point as Kevin Kargel mentions is that there ARE use > >> cases where security is not required and/or end-to-end security is > >> not required and/or IPSec is not required. > >> > >> Julien > >> > >> -----Original Message----- > >> From: Bound, Jim [mailto:Jim.Bound@hp.com] > >> Sent: mardi 26 f=E9vrier 2008 13:24 > >> To: Julien Abeille (jabeille); Thomas Narten > >> Cc: john.loughney@nokia.com; basavaraj.patil@nsn.com; > nov@tahi.org; > >> ipv6@ietf.org; Fred Baker (fred) > >> Subject: RE: Making IPsec *not* mandatory in Node Requirement > >> > >> On the contrary some of the laser sensing capabilities now > could be > >> considered light so I guess it is what we mean by "light" > technically > >> or from a physics/scientific view I took it to be light > controlled by > >> sensors. > >> > >> /jim > >> > >> > >>> -----Original Message----- > >>> From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > >>> Sent: Tuesday, February 26, 2008 3:18 PM > >>> To: Thomas Narten > >>> Cc: john.loughney@nokia.com; Bound, Jim; basavaraj.patil@nsn.com; > >>> nov@tahi.org; ipv6@ietf.org; Fred Baker (fred) > >>> Subject: RE: Making IPsec *not* mandatory in Node Requirement > >>> > >>> A sensor can only sense..., you are talking about a light > actuator. > >>> > >>> Julien > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Thomas Narten [mailto:narten@us.ibm.com] > >>> Sent: mardi 26 f=E9vrier 2008 12:00 > >>> To: Julien Abeille (jabeille) > >>> Cc: john.loughney@nokia.com; Jim.Bound@hp.com; > >>> basavaraj.patil@nsn.com; nov@tahi.org; ipv6@ietf.org; Fred Baker > >>> (fred) > >>> Subject: Re: Making IPsec *not* mandatory in Node Requirement > >>> > >>> > >>>> - some applications might not require any security, e.g. a light > >>>> sensor =3D in your flat might not need it and not implement > >>>> > >>> it, also due > >>> > >>>> to the =3D very low cost of the sensor. > >>>> > >>> I agree. There is absolutely no need to prevent my neighbor > >>> > >> (or a bad > >> > >>> guy outside my window) from being able to control/influence light > >>> sensors in my house. What possible harm could they do? > >>> > >>> Who needs security anyway! > >>> > >>> :-) > >>> > >>> Thomas > >>> > >>> > >> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > >> > >> > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 20:47:49 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB2C28C339; Tue, 26 Feb 2008 20:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.735 X-Spam-Level: X-Spam-Status: No, score=-100.735 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8JBjiwzbX7s; Tue, 26 Feb 2008 20:47:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83583A693A; Tue, 26 Feb 2008 20:47:48 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE673A68EC for ; Tue, 26 Feb 2008 20:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfINXH0qJOkj for ; Tue, 26 Feb 2008 20:47:46 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id 7348E3A693A for ; Tue, 26 Feb 2008 20:47:19 -0800 (PST) Received: from g1t0029.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id CE616387F5; Wed, 27 Feb 2008 04:47:12 +0000 (UTC) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTP id BE05F38B73; Wed, 27 Feb 2008 04:47:08 +0000 (UTC) Received: from G3W0058.americas.hpqcorp.net (16.232.1.3) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.1.251.1; Wed, 27 Feb 2008 04:45:46 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0058.americas.hpqcorp.net ([16.232.1.3]) with mapi; Wed, 27 Feb 2008 04:45:46 +0000 From: "Bound, Jim" To: Jonathan Hui , "ipv6@ietf.org" Date: Wed, 27 Feb 2008 04:45:45 +0000 Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory in Node Requirement) Thread-Topic: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory in Node Requirement) Thread-Index: Ach404SsKTgKO8EUS72vyyWnKidrAwAJx69Q Message-ID: <831FE02B5345194BA8147EDEF5F133882966D4D9@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net><38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com><19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com><38F26F36EAA981478A49D1F37F474A86010DA291@xmb-ams-33d.emea.cisco.com><200802261959.m1QJxcpZ008513@cichlid.raleigh.ibm.com><38F26F36EAA981478A49D1F37F474A86010DA2B1@xmb-ams-33d.emea.cisco.com><831FE02B5345194BA8147EDEF5F133882966D0EB@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA2D7@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4A59@daebe104.NOE.Nokia.com> <47C4A74E.4000807@archrock.com> In-Reply-To: <47C4A74E.4000807@archrock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Good point and Gordon Bell has almost always been right for me so I know I listen to him. The key is do these low power and restricted sensor components require security at the IP layer? If IEEE xxx is secure can we conclude the IP layer is not relevant for sensors, but I would suggest they are for any sensor gateway nodes. Or can we develop in industry a micro-kernel IPsec implementation in hardware that can be cost effectively added to a sensor or set of sensor unions for a network? Clearly we are seeing this type of hardware development on microprocessors with the exponential appearance of deep packet inspection providers into the market that are not router/switch vendors. But is IPsec the right answer is the right question for lowpan for engineering cost reasons as opposed to is it possible? /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Jonathan Hui > Sent: Tuesday, February 26, 2008 6:57 PM > To: ipv6@ietf.org > Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* > mandatory in Node Requirement) > > > I won't argue against the fact that security is an important > part of a complete solution. The question for me is whether > IPsec is the most appropriate solution for highly constrained > embedded devices (constrained in energy, memory, compute, and > link capabilities). From the few implementation numbers > thrown around this thread, it sounds like IPsec is not an > option for low-power wireless nodes with 8K RAM, 48K ROM, > 128B link MTU, and not to mention that any implementation > should leave enough space for an interesting application and > should operate for multiple years on modest batteries. > > One nice thing is that, given some application scenarios, > there are other ways to incorporate sufficient security > without the need for IPsec. For example, link-layer security > may be sufficient for private networks. Link-layer security > may also be sufficient if border routers/gateways attach to > other traditional IP networks via encrypted tunnels. > > I'm not a security expert, nor do I know the complete > workings of IPsec. > But I'd be curious if people strongly believe or have ideas > on ways to squeeze IPsec into devices that I'm interested in. > If not, is it at all possible to consider developing an > alternative end-to-end security mechanism that is > lightweight. I'm not arguing that this should be used between > two traditional IP hosts, but that it can be used between a > traditional IP host communicating with a low-power, wireless > device or two low-power wireless devices communicating directly. > > Gordon Bell observed that we've seen a new class of computing > form about every decade. IP has so far been able to follow > these trends, including hand held devices. Now we are at the > beginning of yet another class with low-power wireless > devices based on IEEE 802.15.4, and the 6lowpan effort within > the IETF has set out to bring IPv6 to this new class. I'd be > disappointed if we couldn't come to an agreement on how we > can appropriately bring this new class into the IP framework. > > -- > Jonathan Hui > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 23:14:41 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB4B28C4E5; Tue, 26 Feb 2008 23:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEkm8Quhlavt; Tue, 26 Feb 2008 23:14:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479B13A698F; Tue, 26 Feb 2008 23:14:39 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CFFC3A68D5 for ; Tue, 26 Feb 2008 23:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYAsQaxrCvFQ for ; Tue, 26 Feb 2008 23:14:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BEE273A6D9A for ; Tue, 26 Feb 2008 23:14:31 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Feb 2008 08:14:23 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1R7ENFa017613; Wed, 27 Feb 2008 08:14:23 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1R7EMME029044; Wed, 27 Feb 2008 07:14:22 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 08:14:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement) Date: Wed, 27 Feb 2008 08:13:53 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05424329@xmb-ams-337.emea.cisco.com> In-Reply-To: <831FE02B5345194BA8147EDEF5F133882966D4D9@G3W0070.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement) thread-index: Ach404SsKTgKO8EUS72vyyWnKidrAwAJx69QAATX3IA= From: "Pascal Thubert (pthubert)" To: "Bound, Jim" , "Jonathan Hui" , X-OriginalArrivalTime: 27 Feb 2008 07:14:22.0921 (UTC) FILETIME=[60B8A390:01C87910] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5805; t=1204096463; x=1204960463; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20IPsec=20and=206LoWPAN=20(was=3A=20Re=3A =20Making=20IPsec=20*not*=20mandatory=20inNode=09Requirement ) |Sender:=20; bh=z05OQvqac5RK8zb2BfXWToSYMFOlaeOhPPTPs+zq0HE=; b=UDnK6uTLdNl1C+V5DkIoynSGFhM8bNZ9m/FMB5886WIKxx/L+M2dnbHc2P olwxkBhYgHG+GV66xUTfmR2RBIEBbNTQ0w/NOjEofiG7twjBbU4goD+b1Ctg QSaNAiP4D8; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Jim: All I can say is that at least one Wireless Sensor Network standard under d= evelopment will not use IPSec. ISA100.11a (http://www.isa.org/MSTemplate.cf= m?MicrositeID=3D1134&CommitteeID=3D6891) has decided to endorse - and exten= d when necessary - the work done at 802.15.4 and 6LoWPAN, which means that = we will have IPv6-based sensors in the industrial WSN space. I say it's gre= at news and we-IETF should continue in our effort to support the ISA there. ISA100.11a is defining a simple transport level security above UDP that is = based on the AES encryption engine in the CCM mode (in reality CCM* as defi= ned by 802.15.4, annex B, which refers to CCM as defined by ANSI X9.63-2001= as well as NIST Pub 800-38C and RFC 3610, that's a quote for the purists). = The ISA100.11a Transport level security replicates end to end what is done = at the Data Link Layer in order to benefit from the chipset built-in featur= es. No IKE, No IPSec at least for the current spec. A side effect of that d= esign is that we'll be able to elide the UDP checksum in the 6LoWPAN compre= ssion by including the IPv6 pseudo header and the UDP ports in the Message = Integrity Check computation, pushing the whole computation up a sublayer. I've come to expect that the encryption will be done end to end at the tran= sport level whereas the integrity and authentication will be played hop by = hop over the DLL mesh, but that's a deployment decision. Pascal = >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = >Behalf Of Bound, Jim >Sent: mercredi 27 f=E9vrier 2008 05:46 >To: Jonathan Hui; ipv6@ietf.org >Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* = >mandatory inNode Requirement) > >Good point and Gordon Bell has almost always been right for me = >so I know I listen to him. The key is do these low power and = >restricted sensor components require security at the IP layer? = > If IEEE xxx is secure can we conclude the IP layer is not = >relevant for sensors, but I would suggest they are for any = >sensor gateway nodes. Or can we develop in industry a = >micro-kernel IPsec implementation in hardware that can be cost = >effectively added to a sensor or set of sensor unions for a = >network? Clearly we are seeing this type of hardware = >development on microprocessors with the exponential appearance = >of deep packet inspection providers into the market that are = >not router/switch vendors. But is IPsec the right answer is = >the right question for lowpan for engineering cost reasons as = >opposed to is it possible? > >/jim > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = >> Of Jonathan Hui >> Sent: Tuesday, February 26, 2008 6:57 PM >> To: ipv6@ietf.org >> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory in = >> Node Requirement) >> >> >> I won't argue against the fact that security is an important = >part of a = >> complete solution. The question for me is whether IPsec is the most = >> appropriate solution for highly constrained embedded devices = >> (constrained in energy, memory, compute, and link = >capabilities). From = >> the few implementation numbers thrown around this thread, it sounds = >> like IPsec is not an option for low-power wireless nodes = >with 8K RAM, = >> 48K ROM, 128B link MTU, and not to mention that any implementation = >> should leave enough space for an interesting application and should = >> operate for multiple years on modest batteries. >> >> One nice thing is that, given some application scenarios, there are = >> other ways to incorporate sufficient security without the need for = >> IPsec. For example, link-layer security may be sufficient = >for private = >> networks. Link-layer security may also be sufficient if border = >> routers/gateways attach to other traditional IP networks via = >encrypted = >> tunnels. >> >> I'm not a security expert, nor do I know the complete workings of = >> IPsec. >> But I'd be curious if people strongly believe or have ideas = >on ways to = >> squeeze IPsec into devices that I'm interested in. >> If not, is it at all possible to consider developing an alternative = >> end-to-end security mechanism that is lightweight. I'm not arguing = >> that this should be used between two traditional IP hosts, = >but that it = >> can be used between a traditional IP host communicating with a = >> low-power, wireless device or two low-power wireless devices = >> communicating directly. >> >> Gordon Bell observed that we've seen a new class of computing form = >> about every decade. IP has so far been able to follow these trends, = >> including hand held devices. Now we are at the beginning of yet = >> another class with low-power wireless devices based on IEEE = >802.15.4, = >> and the 6lowpan effort within the IETF has set out to bring IPv6 to = >> this new class. I'd be disappointed if we couldn't come to an = >> agreement on how we can appropriately bring this new class = >into the IP = >> framework. >> >> -- >> Jonathan Hui >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Feb 26 23:26:54 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E5E3A6D9E; Tue, 26 Feb 2008 23:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxX-y9TRDkC1; Tue, 26 Feb 2008 23:26:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDB23A6CB6; Tue, 26 Feb 2008 23:26:48 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2183E3A6CB6 for ; Tue, 26 Feb 2008 23:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYJbcHywZRJF for ; Tue, 26 Feb 2008 23:26:46 -0800 (PST) Received: from tomato.taca.jp (tomato.taca.jp [202.214.123.64]) by core3.amsl.com (Postfix) with ESMTP id 32E7A3A696E for ; Tue, 26 Feb 2008 23:26:46 -0800 (PST) Received: from localhost (unknown [202.214.123.64]) by tomato.taca.jp (Postfix) with ESMTP id 9113B33C43; Wed, 27 Feb 2008 16:26:39 +0900 (JST) Date: Wed, 27 Feb 2008 16:26:26 +0900 (JST) Message-Id: <20080227.162626.264908883.nov@tahi.org> To: narten@us.ibm.com Subject: Re: Making IPsec *not* mandatory in Node Requirement From: Nobuo OKABE In-Reply-To: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> References: <20080226.165331.14652621.nov@tahi.org> <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> X-Mailer: Mew version 5.2.51 on Emacs 22.1.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: john.loughney@nokia.com, ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, # I'm surprised that opinion in the ML has changed from 2002. I agree that IPsec is not a universal security tool as many people had pointed out. I also would like to say that IPsec is still one of the useful tools. So, SHOULD$B!!(Bseems good to me. Thanks, From: Thomas Narten Subject: Re: Making IPsec *not* mandatory in Node Requirement Date: Tue, 26 Feb 2008 11:18:33 -0500 > IMO, we need to get over the idea that IPsec is mandatory in > IPv6. Really. Or that mandating IPsec is actually useful in practice. > > It is the case that mandating IPsec as part of IPv6 has contributed to > the hype about how great IPv6 is and how one will get better security > with IPv6. Unfortunately, that myth has also harmed the overall IPv6 > deployment effort, as people look more closely and come to understand > that deploying IPv6 doesn't automatically/easily yield improved > security. > > We all know the reality of security is very different and much more > complicated/nuanced then just saying "use IPsec". > > Consider: > > IPsec by itself (with no key management) is close to useless. The > average person cannot configure static keys, so the result is (in > effect) a useless mandate (as a broad mandate for ALL nodes). > > What applications actually make use of IPsec for security? A lot fewer > than one might think. For many IPv6 devices/nodes, if one actually > looks at the applications that will be used on them, they do not use > IPsec today for security. And, there are strong/compelling arguments > for why IPsec is not the best security solution for many applications. > Thus, requiring IPsec is pointless. > > To be truly useful, we (of course) need key management. If we want to > mandate key management, the stakes go way up. IKEv1/v2 is not a small > implementation effort. And, we are now in the funny situation where > IKEv1 has been implemented, but due to shortcomings, IKEv2 has already > been developed. IKEv2 has been out for over 2 years, but > implementations are not widespread yet. So, would we mandate IKEv1 > (which is obsoleted and has documented issues), or do we mandate > IKEv2, even though it is clear it is not widely available yet? > > IMO, we should drop the MUST language surrounding IPsec. The technical > justification for making it MUST are simply not compelling. It seems > to me that the MUST is there primarily for historical/marketing > reasons. > > Note that dropping the MUST will not mean people stop implementing > IPsec, where there is compelling benefit. Indeed, note that the USG > has already moved away from IKEv1 and has strongly signalled that it > will require IKEv2 going forward. So I am confident that IPsec (and > IKE) will get implemented going forward. > > But there is no reason why IPsec should be mandated in devices where > it is clear (based on the function/purpose of the device) that IPsec > will in fact not actually be used. > > As a general "node requirement", SHOULD is the right level, not MUST. > > Thomas > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 00:04:40 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D1F28C4E5; Wed, 27 Feb 2008 00:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2i2PJYWpNJA; Wed, 27 Feb 2008 00:04:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7114228C376; Wed, 27 Feb 2008 00:04:39 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E303A6922 for ; Wed, 27 Feb 2008 00:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zblEEPhK+Mei for ; Wed, 27 Feb 2008 00:04:36 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id C4FF73A67F9 for ; Wed, 27 Feb 2008 00:04:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 77F8CA92E7; Wed, 27 Feb 2008 00:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifSmjcBXlwsf; Wed, 27 Feb 2008 00:04:23 -0800 (PST) Received: from [192.168.1.104] (adsl-71-142-85-145.dsl.pltn13.pacbell.net [71.142.85.145]) by mail.sf.archrock.com (Postfix) with ESMTP id 50212A92E6; Wed, 27 Feb 2008 00:04:23 -0800 (PST) Message-ID: <47C51981.4060003@archrock.com> Date: Wed, 27 Feb 2008 00:04:17 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement) References: <7892795E1A87F04CADFCCF41FADD00FC05424329@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05424329@xmb-ams-337.emea.cisco.com> Cc: ipv6@ietf.org, "Bound, Jim" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org To answer Jim's question following on Pascal's point, I don't believe = that only link-layer security is enough because it lacks any end-to-end = properties. It wasn't clear in my previous email, but multihop = topologies are the norm in low-power wireless with IEEE 802.15.4. The ISA100.11a approach which sits above UDP or a lightweight version of = IPsec which sits a bit lower in the layering are both much more = attractive approaches to me than requiring IPsec, as we know it today, = on sensor nodes. Of course, we won't get all of the features of a = full-blown IPsec implementation, but we've got to trade something to = live in this constrained world. I'm willing to live with that and I'm = wondering what others on this list think about that. Specifically, is = there a place for the IETF to specify a lightweight end-to-end security = scheme in place of IPsec? The question of IPsec vs. engineering cost is in some sense true, but it = doesn't capture the entire story. IPsec has significant header = requirements, compared to the link MTU of IEEE 802.15.4. This translates = directly to extra buffering requirements, channel utilization, and = energy cost. You could argue to use bigger batteries, but some = environments with physical and environmental constraints can't afford to = do so. -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jim: > = > All I can say is that at least one Wireless Sensor Network standard under= development will not use IPSec. ISA100.11a (http://www.isa.org/MSTemplate.= cfm?MicrositeID=3D1134&CommitteeID=3D6891) has decided to endorse - and ext= end when necessary - the work done at 802.15.4 and 6LoWPAN, which means tha= t we will have IPv6-based sensors in the industrial WSN space. I say it's g= reat news and we-IETF should continue in our effort to support the ISA ther= e. > = > ISA100.11a is defining a simple transport level security above UDP that i= s based on the AES encryption engine in the CCM mode (in reality CCM* as de= fined by 802.15.4, annex B, which refers to CCM as defined by ANSI X9.63-20= 01 as well as NIST Pub 800-38C and RFC 3610, that's a quote for the purists= ). = > = > The ISA100.11a Transport level security replicates end to end what is don= e at the Data Link Layer in order to benefit from the chipset built-in feat= ures. No IKE, No IPSec at least for the current spec. A side effect of that= design is that we'll be able to elide the UDP checksum in the 6LoWPAN comp= ression by including the IPv6 pseudo header and the UDP ports in the Messag= e Integrity Check computation, pushing the whole computation up a sublayer. > = > I've come to expect that the encryption will be done end to end at the tr= ansport level whereas the integrity and authentication will be played hop b= y hop over the DLL mesh, but that's a deployment decision. > = > Pascal > = > = >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = >> Behalf Of Bound, Jim >> Sent: mercredi 27 f=E9vrier 2008 05:46 >> To: Jonathan Hui; ipv6@ietf.org >> Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* = >> mandatory inNode Requirement) >> >> Good point and Gordon Bell has almost always been right for me = >> so I know I listen to him. The key is do these low power and = >> restricted sensor components require security at the IP layer? = >> If IEEE xxx is secure can we conclude the IP layer is not = >> relevant for sensors, but I would suggest they are for any = >> sensor gateway nodes. Or can we develop in industry a = >> micro-kernel IPsec implementation in hardware that can be cost = >> effectively added to a sensor or set of sensor unions for a = >> network? Clearly we are seeing this type of hardware = >> development on microprocessors with the exponential appearance = >> of deep packet inspection providers into the market that are = >> not router/switch vendors. But is IPsec the right answer is = >> the right question for lowpan for engineering cost reasons as = >> opposed to is it possible? >> >> /jim >> >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = >>> Of Jonathan Hui >>> Sent: Tuesday, February 26, 2008 6:57 PM >>> To: ipv6@ietf.org >>> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory in = >>> Node Requirement) >>> >>> >>> I won't argue against the fact that security is an important = >> part of a = >>> complete solution. The question for me is whether IPsec is the most = >>> appropriate solution for highly constrained embedded devices = >>> (constrained in energy, memory, compute, and link = >> capabilities). From = >>> the few implementation numbers thrown around this thread, it sounds = >>> like IPsec is not an option for low-power wireless nodes = >> with 8K RAM, = >>> 48K ROM, 128B link MTU, and not to mention that any implementation = >>> should leave enough space for an interesting application and should = >>> operate for multiple years on modest batteries. >>> >>> One nice thing is that, given some application scenarios, there are = >>> other ways to incorporate sufficient security without the need for = >>> IPsec. For example, link-layer security may be sufficient = >> for private = >>> networks. Link-layer security may also be sufficient if border = >>> routers/gateways attach to other traditional IP networks via = >> encrypted = >>> tunnels. >>> >>> I'm not a security expert, nor do I know the complete workings of = >>> IPsec. >>> But I'd be curious if people strongly believe or have ideas = >> on ways to = >>> squeeze IPsec into devices that I'm interested in. >>> If not, is it at all possible to consider developing an alternative = >>> end-to-end security mechanism that is lightweight. I'm not arguing = >>> that this should be used between two traditional IP hosts, = >> but that it = >>> can be used between a traditional IP host communicating with a = >>> low-power, wireless device or two low-power wireless devices = >>> communicating directly. >>> >>> Gordon Bell observed that we've seen a new class of computing form = >>> about every decade. IP has so far been able to follow these trends, = >>> including hand held devices. Now we are at the beginning of yet = >>> another class with low-power wireless devices based on IEEE = >> 802.15.4, = >>> and the 6lowpan effort within the IETF has set out to bring IPv6 to = >>> this new class. I'd be disappointed if we couldn't come to an = >>> agreement on how we can appropriately bring this new class = >> into the IP = >>> framework. >>> >>> -- >>> Jonathan Hui >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 01:36:37 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274ED28C478; Wed, 27 Feb 2008 01:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9vxcQ39vdBw; Wed, 27 Feb 2008 01:36:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBEEB3A6DCA; Wed, 27 Feb 2008 01:36:32 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944703A6DAE for ; Wed, 27 Feb 2008 01:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am1nkANKUsUy for ; Wed, 27 Feb 2008 01:36:27 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by core3.amsl.com (Postfix) with ESMTP id 0D1363A6781 for ; Wed, 27 Feb 2008 01:36:26 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d21so1623835nfb.39 for ; Wed, 27 Feb 2008 01:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=vvSuHs9DrK4nXYTalZ4Hg+NSCUSgTaGDVWJSti9unE8=; b=EEvtiOEK8nc6Elqs6+y8zlaqRf94ErJbbqXzDnTUKBuTHr/Nxbu05dz+DaBbE9EBfOfQa0OZBkvpsOSQ6A4kG3DlzGeZOYBzqyCHpWqjj+Dvt/e6nwiUpPPg9FcidwUSy/W5/pZ4OdrWIZZBVrdNmqgS0+Yjlv2qk/UaIe3Pgps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wneS5X8LMGcGuzkkSSM7G/mfQPdeGSy3dR7I682vE+ckr8X8UFSg58pJpXkELE1HlvZbNTk9li6qNQNL3qojgGqggLL6CGzmeWWhDZVgnwm0ecNVeArE91tB72KbWWBpLieAUEknXrwv7+7f/ZSbZOaj02aCshL4fZfbtTivSg8= Received: by 10.86.97.7 with SMTP id u7mr5786334fgb.39.1204104979316; Wed, 27 Feb 2008 01:36:19 -0800 (PST) Received: by 10.86.35.18 with HTTP; Wed, 27 Feb 2008 01:36:19 -0800 (PST) Message-ID: <729b68be0802270136x37b72533ue3dfc2ea72b897e9@mail.gmail.com> Date: Wed, 27 Feb 2008 10:36:19 +0100 From: "Jean-Michel Combes" To: "Basavaraj Patil" Subject: Re: Making IPsec *not* mandatory in Node Requirement In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0802261013k2d13ba5fr9f436b0c90063ea7@mail.gmail.com> Cc: Thomas Narten , ipv6@ietf.org, fred@cisco.com, John Loughney X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, 2008/2/26, Basavaraj Patil : > > It is not the load or processing that is the issue really which I think you > are alluding to. It is just the complexity of integrating a protocol like > Mobile IPv6 with IPsec and IKE/IKEv2. > Mobile IPv6 signaling can be secured via simpler mechanisms. More you have different mechanisms to secure service, more you will have complexity and more you will have a security hole somewhere ... > But because of > the prevailing thinking that IPsec MUST be used as the security mechanism, > we stuck with it and are lets say not too happy about it. Sorry, but who are "we"? Best regards. JMC. > > > -Basavaraj > > > > On 2/26/08 12:13 PM, "ext Vishwas Manral" wrote: > > > Hi Basavraj, > > > > But isn't that something IPsec needs to improve on. We already have > > efforts like BTNS with "connection latching" in IPsec which may help > > to ease the load on the end devices, which seems to have been the main > > issue raised. > > > > Thanks, > > Vishwas > > > > On Tue, Feb 26, 2008 at 9:58 AM, Basavaraj Patil > > wrote: > >> > >> I agree with Thomas about his views on IPsec being a mandatory and default > >> component of the IPv6 stack. > >> Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec for > >> securing the signaling. This has lead to complexity of the protocol and not > >> really helped either in adoption or implementation. > >> IPsec based security is an overkill for Mobile IPv6 and illustrates the > >> point that you do not have to use it simply because it happens to be an > >> integral part of IPv6. > >> > >> -Basavaraj > >> > >> > >> > >> > >> On 2/26/08 10:18 AM, "ext Thomas Narten" wrote: > >> > >>> IMO, we need to get over the idea that IPsec is mandatory in > >>> IPv6. Really. Or that mandating IPsec is actually useful in practice. > >>> > >>> It is the case that mandating IPsec as part of IPv6 has contributed to > >>> the hype about how great IPv6 is and how one will get better security > >>> with IPv6. Unfortunately, that myth has also harmed the overall IPv6 > >>> deployment effort, as people look more closely and come to understand > >>> that deploying IPv6 doesn't automatically/easily yield improved > >>> security. > >>> > >>> We all know the reality of security is very different and much more > >>> complicated/nuanced then just saying "use IPsec". > >>> > >>> Consider: > >>> > >>> IPsec by itself (with no key management) is close to useless. The > >>> average person cannot configure static keys, so the result is (in > >>> effect) a useless mandate (as a broad mandate for ALL nodes). > >>> > >>> What applications actually make use of IPsec for security? A lot fewer > >>> than one might think. For many IPv6 devices/nodes, if one actually > >>> looks at the applications that will be used on them, they do not use > >>> IPsec today for security. And, there are strong/compelling arguments > >>> for why IPsec is not the best security solution for many applications. > >>> Thus, requiring IPsec is pointless. > >>> > >>> To be truly useful, we (of course) need key management. If we want to > >>> mandate key management, the stakes go way up. IKEv1/v2 is not a small > >>> implementation effort. And, we are now in the funny situation where > >>> IKEv1 has been implemented, but due to shortcomings, IKEv2 has already > >>> been developed. IKEv2 has been out for over 2 years, but > >>> implementations are not widespread yet. So, would we mandate IKEv1 > >>> (which is obsoleted and has documented issues), or do we mandate > >>> IKEv2, even though it is clear it is not widely available yet? > >>> > >>> IMO, we should drop the MUST language surrounding IPsec. The technical > >>> justification for making it MUST are simply not compelling. It seems > >>> to me that the MUST is there primarily for historical/marketing > >>> reasons. > >>> > >>> Note that dropping the MUST will not mean people stop implementing > >>> IPsec, where there is compelling benefit. Indeed, note that the USG > >>> has already moved away from IKEv1 and has strongly signalled that it > >>> will require IKEv2 going forward. So I am confident that IPsec (and > >>> IKE) will get implemented going forward. > >>> > >>> But there is no reason why IPsec should be mandated in devices where > >>> it is clear (based on the function/purpose of the device) that IPsec > >>> will in fact not actually be used. > >>> > >>> As a general "node requirement", SHOULD is the right level, not MUST. > >>> > >>> Thomas > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 02:16:53 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2729D3A6A13; Wed, 27 Feb 2008 02:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWzAc5JLwJ8Y; Wed, 27 Feb 2008 02:16:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D823A6887; Wed, 27 Feb 2008 02:16:47 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4647E3A6887 for ; Wed, 27 Feb 2008 02:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdQwURwDTzGD for ; Wed, 27 Feb 2008 02:16:40 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id DB44B3A6828 for ; Wed, 27 Feb 2008 02:16:38 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so557312uge.46 for ; Wed, 27 Feb 2008 02:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OMr9aCQDXpE9K0jVy2j7Xufn5iHuEzkEs379ahHgvxc=; b=EEeyWBJxBiu8+Wc3sRGUYdkMaGMKtt4Q9KA6VelnFeilPhJUNHYS4kG8Zwovsgfiusd0bG6/5AiSkQHFB3Bmvo12p9VZZIOIbrFbbDD4jtSdWnwVppi2iDCrzinrlzMjDwXvmAIwTf93haRG/NvKdOnhgCws3JoaigDfUNUFrLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nImvcthglf7X7M084wJ9d/N06lZiQzNAsnFW3Ql6r3lrheuSonDupW3DvYVn/SXhC8wBERmAPnAWuglHqnf7kLS/we8K6qsWnPGK4QzKMco+wta0hgJ0dE8hQW+8BJxu3MR6ZwRbBXNygFVo2VSTvlRnmDRgiU+jrZPZRFCQpSY= Received: by 10.67.92.4 with SMTP id u4mr792728ugl.85.1204107391795; Wed, 27 Feb 2008 02:16:31 -0800 (PST) Received: by 10.86.35.18 with HTTP; Wed, 27 Feb 2008 02:16:31 -0800 (PST) Message-ID: <729b68be0802270216s2cfdef89q4051553a16d5af32@mail.gmail.com> Date: Wed, 27 Feb 2008 11:16:31 +0100 From: "Jean-Michel Combes" To: "Alain Durand" Subject: Re: Making IPsec *not* mandatory in Node Requirement ( was Re: Updates to Node Requirements-bis (UNCLASSIFIED)) In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <4B11770E-DE43-46AD-97F2-CB91C2299EB0@cisco.com> Cc: john.loughney@nokia.com, ipv6@ietf.org, Fred Baker X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Alain, you raise the existential question about the security (except for dedicated security services like VPN): why to pay for something that might be never used? :) This is exactly the same problem I have today with airbags in the cars: I pay them when I buy a car (i.e. cost), I cannot anymore put my legs on the dashboard when I am passenger because I am afraid to active them (i.e. complexity) and I will, maybe (I hope :)), never use them (i.e. useless). So, why, today, all the cars have such airbags (BTW, which are standardized I assume)? More seriously, I was not involved in the IETF when it was decided that IPsec would be mandatory in IPv6 but IHMO: - it is always good to have a common security protocol at the IP layer (i.e. interoperability) that can be used easily when you will need it. - many protocols have been specified and secured based on the assumption that IPsec was mandatory - if today some technologies cannot support IPsec, the next generation of the same technologies should support them Now I agree that there is a cost and too much security kills the security. But do you prefer to pay a "small" cost and have a "spare wheel" or to pay a "large" later cost because you will have security issues (and so you will have to stop services until to secure them correctly)? Best regards. JMC. 2008/2/26, Alain Durand : > The latest draft: draft-ietf-6man-node-req-bis-00.txt > still lists IPsec as mandatory to implement. > > As I mentioned last IETF meeting, this is creating a problem for certain > kind of devices, like cable modems, who have a very limited memory > footprint. Those devices operate in an environment where IPsec is not used > and mandating its implementation has a serious cost: it means that legacy > devices cannot be upgraded to IPv6... > > In DOCSIS 3.0, the decision was to NOT require IPsec implementation on those > devices. I'm sure other environment have made or will make similar choices. > > Moreover, to make the point more general, we are specifying/buying many > other types of devices where we know that IPsec will never be used. Why > should the vendor of those devices have to implement it? Because one day I > might decide to deploy it? IMHO, this is not a good think, because in the > meantime, I will have to run extra code which means extra bugs, more memory > and more risks of miss-configuration. > > I would like to suggest that the node requirements remove any mention of > IPsec being mandatory to implement and instead includes text in the line of: > "if you are going to implement IPsec, here is what you should/must do". > > - Alain. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 02:20:53 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA00228C59F; Wed, 27 Feb 2008 02:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okj5VW9G4jo8; Wed, 27 Feb 2008 02:20:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4203A69F1; Wed, 27 Feb 2008 02:20:49 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F19E3A69F1 for ; Wed, 27 Feb 2008 02:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR79chtukp-j for ; Wed, 27 Feb 2008 02:20:43 -0800 (PST) Received: from tndh.net (static-66-15-163-216.bdsl.verizon.net [66.15.163.216]) by core3.amsl.com (Postfix) with ESMTP id B25293A6887 for ; Wed, 27 Feb 2008 02:20:43 -0800 (PST) Received: from eagle (192.168.123.10:3200) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 27 Feb 2008 02:20:27 -0800 From: "Tony Hain" To: References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <47C47446.2050407@ca.afilias.info> In-Reply-To: <47C47446.2050407@ca.afilias.info> Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Wed, 27 Feb 2008 18:20:25 +0800 Message-ID: <1cc401c8792a$5fa6bf90$1ef43eb0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach4tcuU2Px0vBfqTMmRNmlVBU4dyQAcq+Eg content-language: en-us X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian Dickson wrote: > ... > Any of a bunch of other kinds of security can do the job, from TLS to > SSH to use of > out-of-band channels. For those that have forgotten, the entire reason for mandating IPsec is to get away from the 47 flavors of security that are never really configured correctly or completely understood. Yes for any given situation someone can design an optimized protocol, but as soon as the situation changes the optimization no longer applies, and may expose unexpected holes. This was in fact happening at the time the mandate was put in. > > And *this* is why I think that IPsec ought to be downgraded to SHOULD > for IPv6 node > requirements. As I recall we had a lengthy argument about this, and really don't need to reopen it now. If there is not a single mandatory-to-implement protocol, there is no way to assure that two random products will have a common means of secure communication. Again, for a specific deployment or application, they can do whatever they want, but that does not remove the need for a common security protocol when it is not known which other device might need to talk to it 6 months down the road. Alain's original post is completely bogus. If his devices don't need IPsec, he is free to tell his vendors not to load it in the image. That is not a reason to change node-requirements. He is in a closed environment and knows that a random device will not appear that doesn't speak the security protocol for that closed environment. The IETF is defining requirements for IPv6 nodes that will appear in arbitrary environments, where there is no means to know the availability of a common security protocol, unless it was specified up front. Making it a SHOULD only ensures that vendors will never implement it, and force the 47 flavors of not-quite-security. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 03:48:00 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295E43A6DBF; Wed, 27 Feb 2008 03:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddrK64nb7Qt7; Wed, 27 Feb 2008 03:47:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4789B3A6849; Wed, 27 Feb 2008 03:47:56 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C303A6849 for ; Wed, 27 Feb 2008 03:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvyMERmsF14h for ; Wed, 27 Feb 2008 03:47:50 -0800 (PST) Received: from yotelheathrow.etvinteractive.com (unknown [135.196.150.194]) by core3.amsl.com (Postfix) with SMTP id CA64B3A67E6 for ; Wed, 27 Feb 2008 03:47:48 -0800 (PST) Received: from [10.6.2.57] (helo=PC20005) by yotelheathrow.etvinteractive.com with esmtp (Exim 3.36 #1 (Debian)) id 1JUKj4-0004mU-00; Wed, 27 Feb 2008 11:45:30 +0000 From: "Hesham Soliman" To: "'Thomas Narten'" , "'Nobuo OKABE'" Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Wed, 27 Feb 2008 22:45:16 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ach4k0osG6K8++o4T/CcXbXinrXH0QAiE4FQ In-Reply-To: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: john.loughney@nokia.com, ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > > As a general "node requirement", SHOULD is the right level, not MUST. => +1 Apart from the technical discussion of whether IPsec is actually useful for applications ....etc. The way KEYWORDS are defined, a MUST makes little sense because IPv6 will not break without IPsec. The argument for mandating IKEv1/IKEv2 is not so dependent, IMHO, on their availability; it rather depends on the availability of widley used credentials that would make us think mandating IKEvx will actually result in it being used :) Hesham > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 05:18:38 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D0728C10C; Wed, 27 Feb 2008 05:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.727 X-Spam-Level: X-Spam-Status: No, score=-100.727 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-ouNC6nUIlN; Wed, 27 Feb 2008 05:18:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110BE3A6896; Wed, 27 Feb 2008 05:18:36 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA74E3A6862 for ; Wed, 27 Feb 2008 05:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYOV0o2ZZLbt for ; Wed, 27 Feb 2008 05:18:29 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by core3.amsl.com (Postfix) with ESMTP id D8FD03A6912 for ; Wed, 27 Feb 2008 05:18:28 -0800 (PST) Received: from g4t0015.houston.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 30EF88BF0; Wed, 27 Feb 2008 13:18:22 +0000 (UTC) Received: from G3W0630.americas.hpqcorp.net (g3w0630.americas.hpqcorp.net [16.233.58.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTP id 1DE5A8BF3; Wed, 27 Feb 2008 13:18:22 +0000 (UTC) Received: from G3W0629.americas.hpqcorp.net (16.233.58.78) by G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft SMTP Server (TLS) id 8.1.251.1; Wed, 27 Feb 2008 13:17:45 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0629.americas.hpqcorp.net ([16.233.58.78]) with mapi; Wed, 27 Feb 2008 13:17:45 +0000 From: "Bound, Jim" To: "Pascal Thubert (pthubert)" , Jonathan Hui , "ipv6@ietf.org" Date: Wed, 27 Feb 2008 13:17:44 +0000 Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement) Thread-Topic: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement) Thread-Index: Ach404SsKTgKO8EUS72vyyWnKidrAwAJx69QAATX3IAADRRSkA== Message-ID: <831FE02B5345194BA8147EDEF5F1338829778C0D@G3W0070.americas.hpqcorp.net> References: <831FE02B5345194BA8147EDEF5F133882966D4D9@G3W0070.americas.hpqcorp.net> <7892795E1A87F04CADFCCF41FADD00FC05424329@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05424329@xmb-ams-337.emea.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Pascal, Responses in line. > All I can say is that at least one Wireless Sensor Network > standard under development will not use IPSec. ISA100.11a > (http://www.isa.org/MSTemplate.cfm?MicrositeID=3D1134&CommitteeI > D=3D6891) has decided to endorse - and extend when necessary - > the work done at 802.15.4 and 6LoWPAN, which means that we > will have IPv6-based sensors in the industrial WSN space. I > say it's great news and we-IETF should continue in our effort > to support the ISA there. Agree this is a very good endorsement from ISA. > > ISA100.11a is defining a simple transport level security > above UDP that is based on the AES encryption engine in the > CCM mode (in reality CCM* as defined by 802.15.4, annex B, > which refers to CCM as defined by ANSI X9.63-2001 as well as > NIST Pub 800-38C and RFC 3610, that's a quote for the purists). Uggh. As purist I do not trust UDP in the first place :--). If one can bu= ild a stack supporting UPD and all that is required for AES then hearing th= at IPsec is to heavy for a sensor makes zero sense to me. > > The ISA100.11a Transport level security replicates end to end > what is done at the Data Link Layer in order to benefit from > the chipset built-in features. Can you say more because moving link layer control up to a transport in my = view not only breaks the Internet Protocol Reference Model but the IEEE lay= er 1 and 2 models? Also IEEE does a fairly good job for most media to secu= re the link at that end? > No IKE, No IPSec at least for > the current spec. A side effect of that design is that we'll > be able to elide the UDP checksum in the 6LoWPAN compression > by including the IPv6 pseudo header and the UDP ports in the > Message Integrity Check computation, pushing the whole > computation up a sublayer. Ouch I don't even believe you should see any ports until after a decrypt fr= om my security purist view. > > I've come to expect that the encryption will be done end to > end at the transport level whereas the integrity and > authentication will be played hop by hop over the DLL mesh, > but that's a deployment decision. Well for mission critical nets this is clearly not supportive of defense in= depth at all. But I can see it as we are talking for some deployments tha= t do not need defense in depth. Thanks /jim > > Pascal > > > >-----Original Message----- > >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > On Behalf Of > >Bound, Jim > >Sent: mercredi 27 f=E9vrier 2008 05:46 > >To: Jonathan Hui; ipv6@ietf.org > >Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* > mandatory > >inNode Requirement) > > > >Good point and Gordon Bell has almost always been right for me so I > >know I listen to him. The key is do these low power and restricted > >sensor components require security at the IP layer? > > If IEEE xxx is secure can we conclude the IP layer is not > relevant for > >sensors, but I would suggest they are for any sensor gateway > nodes. Or > >can we develop in industry a micro-kernel IPsec implementation in > >hardware that can be cost effectively added to a sensor or set of > >sensor unions for a network? Clearly we are seeing this type of > >hardware development on microprocessors with the exponential > appearance > >of deep packet inspection providers into the market that are not > >router/switch vendors. But is IPsec the right answer is the right > >question for lowpan for engineering cost reasons as opposed to is it > >possible? > > > >/jim > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > On Behalf > >> Of Jonathan Hui > >> Sent: Tuesday, February 26, 2008 6:57 PM > >> To: ipv6@ietf.org > >> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* > mandatory in > >> Node Requirement) > >> > >> > >> I won't argue against the fact that security is an important > >part of a > >> complete solution. The question for me is whether IPsec is > the most > >> appropriate solution for highly constrained embedded devices > >> (constrained in energy, memory, compute, and link > >capabilities). From > >> the few implementation numbers thrown around this thread, > it sounds > >> like IPsec is not an option for low-power wireless nodes > >with 8K RAM, > >> 48K ROM, 128B link MTU, and not to mention that any implementation > >> should leave enough space for an interesting application > and should > >> operate for multiple years on modest batteries. > >> > >> One nice thing is that, given some application scenarios, > there are > >> other ways to incorporate sufficient security without the need for > >> IPsec. For example, link-layer security may be sufficient > >for private > >> networks. Link-layer security may also be sufficient if border > >> routers/gateways attach to other traditional IP networks via > >encrypted > >> tunnels. > >> > >> I'm not a security expert, nor do I know the complete workings of > >> IPsec. > >> But I'd be curious if people strongly believe or have ideas > >on ways to > >> squeeze IPsec into devices that I'm interested in. > >> If not, is it at all possible to consider developing an > alternative > >> end-to-end security mechanism that is lightweight. I'm not arguing > >> that this should be used between two traditional IP hosts, > >but that it > >> can be used between a traditional IP host communicating with a > >> low-power, wireless device or two low-power wireless devices > >> communicating directly. > >> > >> Gordon Bell observed that we've seen a new class of computing form > >> about every decade. IP has so far been able to follow > these trends, > >> including hand held devices. Now we are at the beginning of yet > >> another class with low-power wireless devices based on IEEE > >802.15.4, > >> and the 6lowpan effort within the IETF has set out to > bring IPv6 to > >> this new class. I'd be disappointed if we couldn't come to an > >> agreement on how we can appropriately bring this new class > >into the IP > >> framework. > >> > >> -- > >> Jonathan Hui > >> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > >> > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 05:21:44 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0C23A6CF1; Wed, 27 Feb 2008 05:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.708 X-Spam-Level: X-Spam-Status: No, score=-100.708 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEjLoNA27kJT; Wed, 27 Feb 2008 05:21:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7964A3A6D24; Wed, 27 Feb 2008 05:21:37 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2409A3A6D24 for ; Wed, 27 Feb 2008 05:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvOgEuPuBQii for ; Wed, 27 Feb 2008 05:21:31 -0800 (PST) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by core3.amsl.com (Postfix) with ESMTP id 86F543A6993 for ; Wed, 27 Feb 2008 05:21:31 -0800 (PST) Received: from g1t0026.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 997CBC04A; Wed, 27 Feb 2008 13:21:24 +0000 (UTC) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTP id 59743C1AD; Wed, 27 Feb 2008 13:21:19 +0000 (UTC) Received: from G3W0055.americas.hpqcorp.net (16.232.1.152) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.1.251.1; Wed, 27 Feb 2008 13:20:18 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0055.americas.hpqcorp.net ([16.232.1.152]) with mapi; Wed, 27 Feb 2008 13:20:18 +0000 From: "Bound, Jim" To: Jonathan Hui , "Pascal Thubert (pthubert)" Date: Wed, 27 Feb 2008 13:20:17 +0000 Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement) Thread-Topic: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement) Thread-Index: Ach5F2akLosdgUDlTMGlqEW8onnIWQAK9ftA Message-ID: <831FE02B5345194BA8147EDEF5F1338829778C1A@G3W0070.americas.hpqcorp.net> References: <7892795E1A87F04CADFCCF41FADD00FC05424329@xmb-ams-337.emea.cisco.com> <47C51981.4060003@archrock.com> In-Reply-To: <47C51981.4060003@archrock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org It all comes down to is IPsec capable for the nodes within the discussion b= elow and I point to Tony Hain's mail that IPsec is far better than 47 secur= ity protocol options from an IETF doing our job here. Batteries are energy= cost impacting other work in the IETF too it is a reality we need to be aw= are of for sure. thanks /jim > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: Wednesday, February 27, 2008 3:04 AM > To: Pascal Thubert (pthubert) > Cc: Bound, Jim; ipv6@ietf.org > Subject: Re: IPsec and 6LoWPAN (was: Re: Making IPsec *not* > mandatory inNode Requirement) > > > To answer Jim's question following on Pascal's point, I don't > believe that only link-layer security is enough because it > lacks any end-to-end properties. It wasn't clear in my > previous email, but multihop topologies are the norm in > low-power wireless with IEEE 802.15.4. > > The ISA100.11a approach which sits above UDP or a lightweight > version of IPsec which sits a bit lower in the layering are > both much more attractive approaches to me than requiring > IPsec, as we know it today, on sensor nodes. Of course, we > won't get all of the features of a full-blown IPsec > implementation, but we've got to trade something to live in > this constrained world. I'm willing to live with that and I'm > wondering what others on this list think about that. > Specifically, is there a place for the IETF to specify a > lightweight end-to-end security scheme in place of IPsec? > > The question of IPsec vs. engineering cost is in some sense > true, but it doesn't capture the entire story. IPsec has > significant header requirements, compared to the link MTU of > IEEE 802.15.4. This translates directly to extra buffering > requirements, channel utilization, and energy cost. You could > argue to use bigger batteries, but some environments with > physical and environmental constraints can't afford to do so. > > -- > Jonathan Hui > > > Pascal Thubert (pthubert) wrote: > > Hi Jim: > > > > All I can say is that at least one Wireless Sensor Network > standard under development will not use IPSec. ISA100.11a > (http://www.isa.org/MSTemplate.cfm?MicrositeID=3D1134&CommitteeI > D=3D6891) has decided to endorse - and extend when necessary - > the work done at 802.15.4 and 6LoWPAN, which means that we > will have IPv6-based sensors in the industrial WSN space. I > say it's great news and we-IETF should continue in our effort > to support the ISA there. > > > > ISA100.11a is defining a simple transport level security > above UDP that is based on the AES encryption engine in the > CCM mode (in reality CCM* as defined by 802.15.4, annex B, > which refers to CCM as defined by ANSI X9.63-2001 as well as > NIST Pub 800-38C and RFC 3610, that's a quote for the purists). > > > > The ISA100.11a Transport level security replicates end to > end what is done at the Data Link Layer in order to benefit > from the chipset built-in features. No IKE, No IPSec at least > for the current spec. A side effect of that design is that > we'll be able to elide the UDP checksum in the 6LoWPAN > compression by including the IPv6 pseudo header and the UDP > ports in the Message Integrity Check computation, pushing the > whole computation up a sublayer. > > > > I've come to expect that the encryption will be done end to > end at the transport level whereas the integrity and > authentication will be played hop by hop over the DLL mesh, > but that's a deployment decision. > > > > Pascal > > > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > On Behalf > >> Of Bound, Jim > >> Sent: mercredi 27 f=E9vrier 2008 05:46 > >> To: Jonathan Hui; ipv6@ietf.org > >> Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec > *not* mandatory > >> inNode Requirement) > >> > >> Good point and Gordon Bell has almost always been right > for me so I > >> know I listen to him. The key is do these low power and > restricted > >> sensor components require security at the IP layer? > >> If IEEE xxx is secure can we conclude the IP layer is not relevant > >> for sensors, but I would suggest they are for any sensor gateway > >> nodes. Or can we develop in industry a micro-kernel IPsec > >> implementation in hardware that can be cost effectively added to a > >> sensor or set of sensor unions for a network? Clearly we > are seeing > >> this type of hardware development on microprocessors with the > >> exponential appearance of deep packet inspection providers > into the > >> market that are not router/switch vendors. But is IPsec the right > >> answer is the right question for lowpan for engineering > cost reasons > >> as opposed to is it possible? > >> > >> /jim > >> > >>> -----Original Message----- > >>> From: ipv6-bounces@ietf.org > [mailto:ipv6-bounces@ietf.org] On Behalf > >>> Of Jonathan Hui > >>> Sent: Tuesday, February 26, 2008 6:57 PM > >>> To: ipv6@ietf.org > >>> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* > mandatory in > >>> Node Requirement) > >>> > >>> > >>> I won't argue against the fact that security is an important > >> part of a > >>> complete solution. The question for me is whether IPsec > is the most > >>> appropriate solution for highly constrained embedded devices > >>> (constrained in energy, memory, compute, and link > >> capabilities). From > >>> the few implementation numbers thrown around this thread, > it sounds > >>> like IPsec is not an option for low-power wireless nodes > >> with 8K RAM, > >>> 48K ROM, 128B link MTU, and not to mention that any > implementation > >>> should leave enough space for an interesting application > and should > >>> operate for multiple years on modest batteries. > >>> > >>> One nice thing is that, given some application scenarios, > there are > >>> other ways to incorporate sufficient security without the > need for > >>> IPsec. For example, link-layer security may be sufficient > >> for private > >>> networks. Link-layer security may also be sufficient if border > >>> routers/gateways attach to other traditional IP networks via > >> encrypted > >>> tunnels. > >>> > >>> I'm not a security expert, nor do I know the complete workings of > >>> IPsec. > >>> But I'd be curious if people strongly believe or have ideas > >> on ways to > >>> squeeze IPsec into devices that I'm interested in. > >>> If not, is it at all possible to consider developing an > alternative > >>> end-to-end security mechanism that is lightweight. I'm > not arguing > >>> that this should be used between two traditional IP hosts, > >> but that it > >>> can be used between a traditional IP host communicating with a > >>> low-power, wireless device or two low-power wireless devices > >>> communicating directly. > >>> > >>> Gordon Bell observed that we've seen a new class of > computing form > >>> about every decade. IP has so far been able to follow > these trends, > >>> including hand held devices. Now we are at the beginning of yet > >>> another class with low-power wireless devices based on IEEE > >> 802.15.4, > >>> and the 6lowpan effort within the IETF has set out to > bring IPv6 to > >>> this new class. I'd be disappointed if we couldn't come to an > >>> agreement on how we can appropriately bring this new class > >> into the IP > >>> framework. > >>> > >>> -- > >>> Jonathan Hui > >>> > -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>> Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >>> > -------------------------------------------------------------------- > >>> > >> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 05:24:23 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B967D28C445; Wed, 27 Feb 2008 05:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.719 X-Spam-Level: X-Spam-Status: No, score=-100.719 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTSU28re9rV3; Wed, 27 Feb 2008 05:24:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873F33A6D24; Wed, 27 Feb 2008 05:24:17 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECE528C427 for ; Wed, 27 Feb 2008 05:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOuvMY+YAyhr for ; Wed, 27 Feb 2008 05:24:10 -0800 (PST) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id 541503A6D24 for ; Wed, 27 Feb 2008 05:22:18 -0800 (PST) Received: from g4t0014.houston.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 74597242C8; Wed, 27 Feb 2008 13:22:11 +0000 (UTC) Received: from G3W0630.americas.hpqcorp.net (g3w0630.americas.hpqcorp.net [16.233.58.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTP id 653472406A; Wed, 27 Feb 2008 13:22:07 +0000 (UTC) Received: from G3W0055.americas.hpqcorp.net (16.232.1.152) by G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft SMTP Server (TLS) id 8.1.251.1; Wed, 27 Feb 2008 13:21:17 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0055.americas.hpqcorp.net ([16.232.1.152]) with mapi; Wed, 27 Feb 2008 13:21:17 +0000 From: "Bound, Jim" To: "alh-ietf@tndh.net" , "ipv6@ietf.org" Date: Wed, 27 Feb 2008 13:21:16 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4tcuU2Px0vBfqTMmRNmlVBU4dyQAcq+EgAAbC3tA= Message-ID: <831FE02B5345194BA8147EDEF5F1338829778C1E@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <47C47446.2050407@ca.afilias.info> <1cc401c8792a$5fa6bf90$1ef43eb0$@net> In-Reply-To: <1cc401c8792a$5fa6bf90$1ef43eb0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Good recap on why Tony it is very important for us to hear this input and quite valid. thanks /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Tony Hain > Sent: Wednesday, February 27, 2008 5:20 AM > To: ipv6@ietf.org > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > Brian Dickson wrote: > > ... > > Any of a bunch of other kinds of security can do the job, > from TLS to > > SSH to use of out-of-band channels. > > For those that have forgotten, the entire reason for > mandating IPsec is to get away from the 47 flavors of > security that are never really configured correctly or > completely understood. Yes for any given situation someone > can design an optimized protocol, but as soon as the > situation changes the optimization no longer applies, and may > expose unexpected holes. This was in fact happening at the > time the mandate was put in. > > > > > And *this* is why I think that IPsec ought to be downgraded > to SHOULD > > for IPv6 node requirements. > > As I recall we had a lengthy argument about this, and really > don't need to reopen it now. If there is not a single > mandatory-to-implement protocol, there is no way to assure > that two random products will have a common means of secure > communication. Again, for a specific deployment or > application, they can do whatever they want, but that does > not remove the need for a common security protocol when it is > not known which other device might need to talk to it 6 > months down the road. > > > Alain's original post is completely bogus. If his devices > don't need IPsec, he is free to tell his vendors not to load > it in the image. That is not a reason to change > node-requirements. He is in a closed environment and knows > that a random device will not appear that doesn't speak the > security protocol for that closed environment. The IETF is > defining requirements for > IPv6 nodes that will appear in arbitrary environments, where > there is no means to know the availability of a common > security protocol, unless it was specified up front. Making > it a SHOULD only ensures that vendors will never implement > it, and force the 47 flavors of not-quite-security. > > > Tony > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 05:30:49 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99893A698C; Wed, 27 Feb 2008 05:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.704 X-Spam-Level: X-Spam-Status: No, score=-100.704 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxGlnuj0lnIt; Wed, 27 Feb 2008 05:30:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF193A6A80; Wed, 27 Feb 2008 05:30:44 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38D93A68BB for ; Wed, 27 Feb 2008 05:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKW6S18NK17Y for ; Wed, 27 Feb 2008 05:30:41 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id AD24F3A698C for ; Wed, 27 Feb 2008 05:30:41 -0800 (PST) Received: from g1t0029.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id E92D7385B8; Wed, 27 Feb 2008 13:30:34 +0000 (UTC) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTP id A014C381AD; Wed, 27 Feb 2008 13:30:34 +0000 (UTC) Received: from G3W0058.americas.hpqcorp.net (16.232.1.3) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.1.251.1; Wed, 27 Feb 2008 13:29:42 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0058.americas.hpqcorp.net ([16.232.1.3]) with mapi; Wed, 27 Feb 2008 13:29:42 +0000 From: "Bound, Jim" To: Hesham Soliman , 'Thomas Narten' , 'Nobuo OKABE' Date: Wed, 27 Feb 2008 13:29:41 +0000 Subject: RE: Making IPsec *not* mandatory in Node Requirement Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4k0osG6K8++o4T/CcXbXinrXH0QAiE4FQAAoE7WA= Message-ID: <831FE02B5345194BA8147EDEF5F1338829778C31@G3W0070.americas.hpqcorp.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "john.loughney@nokia.com" , "ipv6@ietf.org" , "fred@cisco.com" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I see what your saying but for security if we know IKEv2 is superior then we I think must mandate it and this is the case over IKEv1. Fully supportive of being conscious of the reality of pain to the market and vendors for implementation but when it is a network health issue then we have to do the next right thing in the IETF. IKEv2 is clearly better. Regarding management of PKI etc that is a red herring argument orthogonal to the technical work on a function in the IETF like IKEv2. The market will sort out that deployment automatiion issue we need to spec out and define technical criteria for a specification. Adding foot note that without PKI etc. this will not work well is fine. Thus if apples-x grown in region-x cause ones legs to cramp but apples-y grown in region-y do not the social agency reporting on such things has the responsibility to say apples-y do less harm to you than apples-x. In this specific case as a protocol the IETF is the social agency above. But the market is requiring IKEv2 now and most vendors have figured out it is a done deal if they want to maintain competitive parity in the market. /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: Wednesday, February 27, 2008 7:45 AM > To: 'Thomas Narten'; 'Nobuo OKABE' > Cc: john.loughney@nokia.com; ipv6@ietf.org; fred@cisco.com > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > > > > > As a general "node requirement", SHOULD is the right > level, not MUST. > > => +1 > Apart from the technical discussion of whether IPsec is > actually useful for applications ....etc. The way KEYWORDS > are defined, a MUST makes little sense because IPv6 will not > break without IPsec. > > The argument for mandating IKEv1/IKEv2 is not so dependent, > IMHO, on their availability; it rather depends on the > availability of widley used credentials that would make us > think mandating IKEvx will actually result in it being used :) > > Hesham > > > > > Thomas > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 06:38:59 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B501328C4F6; Wed, 27 Feb 2008 06:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=-1.958, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZVDeD0s7clU; Wed, 27 Feb 2008 06:38:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44FB428C465; Wed, 27 Feb 2008 06:38:58 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051CA28C465 for ; Wed, 27 Feb 2008 06:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tawNlp733P+H for ; Wed, 27 Feb 2008 06:38:55 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 105713A691A for ; Wed, 27 Feb 2008 06:38:54 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Feb 2008 15:38:48 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1REcmdb001315; Wed, 27 Feb 2008 15:38:48 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1REcmME019212; Wed, 27 Feb 2008 14:38:48 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 15:38:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNodeRequirement) Date: Wed, 27 Feb 2008 15:38:18 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC054245E7@xmb-ams-337.emea.cisco.com> In-Reply-To: <831FE02B5345194BA8147EDEF5F1338829778C0D@G3W0070.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNodeRequirement) thread-index: Ach404SsKTgKO8EUS72vyyWnKidrAwAJx69QAATX3IAADRRSkAAAlSpA From: "Pascal Thubert (pthubert)" To: "Bound, Jim" , "Jonathan Hui" , X-OriginalArrivalTime: 27 Feb 2008 14:38:48.0147 (UTC) FILETIME=[766F3A30:01C8794E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9487; t=1204123128; x=1204987128; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20IPsec=20and=206LoWPAN=20(was=3A=20Re=3A =20Making=20IPsec=20*not*=20mandatory=20inNodeRequirement) |Sender:=20; bh=8dfpi9ciy5Ejh1xxJr9adTNcdOCnAtbN8FR++SkVpR8=; b=AV3x8Ze/Z9T7NayGQf//Z294JMPO7wV0L6yolHtDvhSQgNZ//MnYMoV9dM +/XuxevXU9O8WQHfE1Vmk4TwrjLDTKqQVqykT+kAUL0xt/YriPDUn/5ctdBk 2ISyTuThfy; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Jim: Please see inline: >> ISA100.11a is defining a simple transport level security above UDP = >> that is based on the AES encryption engine in the CCM mode = >(in reality = >> CCM* as defined by 802.15.4, annex B, which refers to CCM as defined = >> by ANSI X9.63-2001 as well as NIST Pub 800-38C and RFC 3610, = >that's a = >> quote for the purists). > >Uggh. As purist I do not trust UDP in the first place :--). = >If one can build a stack supporting UPD and all that is = >required for AES then hearing that IPsec is to heavy for a = >sensor makes zero sense to me. I was not there when that decision was made and I do not know all the detai= ls. Seems to me that we get a result that is close to D-TLS with a security= sublayer sitting above UDP as opposed to a sitting at the bottom of the ap= p layer. That much does not bother me too much because it is an end point t= hing above standard UDP and the end-to-end principle is respected. I need to dig but my current understanding is that the ISA approach saves b= ytes in the packet, which is *critical* in the sensor space; part of that s= aving comes from using time in the nonce but not passing (all of) it over t= he air because devices are somewhat synchronized. Anyway, once you have a D= -TLS prime and a good L2 security, it's hard to justify you need IPSec as w= ell. I figure that ISA100.11a falls into Tony's "specific deployment or app= lication," because ISA defines both ends of a communication, so this does n= ot bother me too much either. = What I've been trying to do is make sure that the packets across the backbo= ne (that interconnects LoWPANs) are standard IPv6 packets and that basic ru= les such as RFC 3448 are taken into consideration in the end points. None o= f this was a given to start with :) = > >> >> The ISA100.11a Transport level security replicates end to = >end what is = >> done at the Data Link Layer in order to benefit from the chipset = >> built-in features. > >Can you say more because moving link layer control up to a = >transport in my view not only breaks the Internet Protocol = >Reference Model but the IEEE layer 1 and 2 models? Also IEEE = >does a fairly good job for most media to secure the link at that end? ISA has cleanly defined layers which pretty much echo the TCP/IP model, and= has both L2 and upper L4 security, but no L3 security. = What I've been trying to say here is that the crypto operation is the same = at both layers so the crypto engine available for L2 in the chipsets can be= reused by the transport security; thus the use of standard AES with CCM* m= ode. Each layer secures its own data per its own policy; for instance upper= L4 will encrypt the payload and L2 will only authenticate the frame. As a = result, the crypto engine present in the chipset will run twice. Once and L= 2 and once at L4 if you're terminating the connection; once to check and on= ce to sign if you're only forwarding over the L2 mesh. >> No IKE, No IPSec at least for >> the current spec. A side effect of that design is that we'll be able = >> to elide the UDP checksum in the 6LoWPAN compression by = >including the = >> IPv6 pseudo header and the UDP ports in the Message Integrity Check = >> computation, pushing the whole computation up a sublayer. > >Ouch I don't even believe you should see any ports until after = >a decrypt from my security purist view. What we do is a DTLS prime, not an IPSec Prime. So the UDP ports are visibl= e but still we want to prevent tempering with them. In particular for the UDP checksum, what I'm trying to do is get an IP+UDP = pseudo-header included in the MIC computation but not encrypted, to emulate= the UDP checksum so that the UDP checksum can be elided. With CCM, it is p= ossible to encrypt only a part of the message, leaving - typically a header= - in the clear. Obviously, we elide the pseudo-header as well for transmis= sion. With the checksum trick, UDP is in the clear but still protected agai= nst corruption along the path. As a result, the UDP header can be compresse= d down to 1 byte as opposed to 3 bytes with RFC 4944. = I'm planning to document that process to 6LoWPAN see if we can get a consen= sus betweem the 2 organizations that the whole thing is workable. I hope it is clearer now :) Pascal > >> >> I've come to expect that the encryption will be done end to = >end at the = >> transport level whereas the integrity and authentication will be = >> played hop by hop over the DLL mesh, but that's a deployment = >decision. > >Well for mission critical nets this is clearly not supportive = >of defense in depth at all. But I can see it as we are = >talking for some deployments that do not need defense in depth. > >Thanks >/jim > >> >> Pascal >> >> >> >-----Original Message----- >> >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] >> On Behalf Of >> >Bound, Jim >> >Sent: mercredi 27 f=E9vrier 2008 05:46 >> >To: Jonathan Hui; ipv6@ietf.org >> >Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* >> mandatory >> >inNode Requirement) >> > >> >Good point and Gordon Bell has almost always been right for me so I = >> >know I listen to him. The key is do these low power and restricted = >> >sensor components require security at the IP layer? >> > If IEEE xxx is secure can we conclude the IP layer is not >> relevant for >> >sensors, but I would suggest they are for any sensor gateway >> nodes. Or >> >can we develop in industry a micro-kernel IPsec implementation in = >> >hardware that can be cost effectively added to a sensor or set of = >> >sensor unions for a network? Clearly we are seeing this type of = >> >hardware development on microprocessors with the exponential >> appearance >> >of deep packet inspection providers into the market that are not = >> >router/switch vendors. But is IPsec the right answer is the right = >> >question for lowpan for engineering cost reasons as opposed = >to is it = >> >possible? >> > >> >/jim >> > >> >> -----Original Message----- >> >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] >> On Behalf >> >> Of Jonathan Hui >> >> Sent: Tuesday, February 26, 2008 6:57 PM >> >> To: ipv6@ietf.org >> >> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* >> mandatory in >> >> Node Requirement) >> >> >> >> >> >> I won't argue against the fact that security is an important >> >part of a >> >> complete solution. The question for me is whether IPsec is >> the most >> >> appropriate solution for highly constrained embedded devices = >> >> (constrained in energy, memory, compute, and link >> >capabilities). From >> >> the few implementation numbers thrown around this thread, >> it sounds >> >> like IPsec is not an option for low-power wireless nodes >> >with 8K RAM, >> >> 48K ROM, 128B link MTU, and not to mention that any = >implementation = >> >> should leave enough space for an interesting application >> and should >> >> operate for multiple years on modest batteries. >> >> >> >> One nice thing is that, given some application scenarios, >> there are >> >> other ways to incorporate sufficient security without the = >need for = >> >> IPsec. For example, link-layer security may be sufficient >> >for private >> >> networks. Link-layer security may also be sufficient if border = >> >> routers/gateways attach to other traditional IP networks via >> >encrypted >> >> tunnels. >> >> >> >> I'm not a security expert, nor do I know the complete workings of = >> >> IPsec. >> >> But I'd be curious if people strongly believe or have ideas >> >on ways to >> >> squeeze IPsec into devices that I'm interested in. >> >> If not, is it at all possible to consider developing an >> alternative >> >> end-to-end security mechanism that is lightweight. I'm = >not arguing = >> >> that this should be used between two traditional IP hosts, >> >but that it >> >> can be used between a traditional IP host communicating with a = >> >> low-power, wireless device or two low-power wireless devices = >> >> communicating directly. >> >> >> >> Gordon Bell observed that we've seen a new class of = >computing form = >> >> about every decade. IP has so far been able to follow >> these trends, >> >> including hand held devices. Now we are at the beginning of yet = >> >> another class with low-power wireless devices based on IEEE >> >802.15.4, >> >> and the 6lowpan effort within the IETF has set out to >> bring IPv6 to >> >> this new class. I'd be disappointed if we couldn't come to an = >> >> agreement on how we can appropriately bring this new class >> >into the IP >> >> framework. >> >> >> >> -- >> >> Jonathan Hui >> >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative = >> >> Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> >> >> -------------------------------------------------------------------- >> >> >> >-------------------------------------------------------------------- >> >IETF IPv6 working group mailing list >> >ipv6@ietf.org >> >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> >-------------------------------------------------------------------- >> > >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 06:55:59 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F2928C754; Wed, 27 Feb 2008 06:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0Raz3G-JTSo; Wed, 27 Feb 2008 06:55:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6823A6862; Wed, 27 Feb 2008 06:55:55 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA493A6862 for ; Wed, 27 Feb 2008 06:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3BNISsKuSnn for ; Wed, 27 Feb 2008 06:55:53 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 5AF453A6810 for ; Wed, 27 Feb 2008 06:55:53 -0800 (PST) Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.113]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 14:55:43 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Wed, 27 Feb 2008 14:55:14 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach4Xz+YRvQ5QfooQQSWyAZwcdbLpQAFGJIAAAPf6mA= References: From: To: X-OriginalArrivalTime: 27 Feb 2008 14:55:43.0361 (UTC) FILETIME=[D38C9710:01C87950] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > I totally appreciate Alain's concern for cable modem devices > with limited memory for IPv6 but the problem is that IPv6 > community decided as far back as 1998 with RFC 2401 that > IPSec is mandatory for IPv6. The events of 1998 are irrelevant. The fact is that this website clearly does not consider IPsec to be part of the IPv6 core protocols and therefore lots of implementations will not have it. Cable boxes are not much different from general purpose computers running Linux. In fact, they may use Linux for all I know. In any case, they are complex devices and if you looked at an architecture diagram for them they would like rather like a network in a box with many functions on separate chips (or areas of an FPGA) all communicating with various internal protocols and busses. But IPv6 is not just for devices like that. It was also intended to be something that could be implemented on embedded devices that often use 8-bit CPUs with the IP stack written in carefully handcoded assembly language. TINI is an example of such a device but there are hundreds of them out there and manufacturers continue to introduce new 8-bit microcontrollers all the time. If you have any contacts with Yokogawa in Japan, they have a lot of experience in this area and will be able to give a better idea of how common it is to implement IPv6 without IPsec. WIDE people may also know more about this. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 07:14:27 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD8828C59F; Wed, 27 Feb 2008 07:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esN-Wz9h4LaX; Wed, 27 Feb 2008 07:14:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721E93A6A82; Wed, 27 Feb 2008 07:14:21 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4BA3A6A82 for ; Wed, 27 Feb 2008 07:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij4AUspFBK7s for ; Wed, 27 Feb 2008 07:14:19 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 914473A6A14 for ; Wed, 27 Feb 2008 07:14:19 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Feb 2008 10:14:13 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1RFEDb5025662; Wed, 27 Feb 2008 10:14:13 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1RFDtBf021745; Wed, 27 Feb 2008 15:14:12 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 10:14:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Wed, 27 Feb 2008 10:14:12 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach4Xz+YRvQ5QfooQQSWyAZwcdbLpQAFGJIAAAPf6mAAM7cTcA== References: From: "Hemant Singh (shemant)" To: , X-OriginalArrivalTime: 27 Feb 2008 15:14:12.0705 (UTC) FILETIME=[68C50D10:01C87953] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2725; t=1204125253; x=1204989253; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20the=20role=20of=20the=20node=20=22requi rements=22=20document |Sender:=20 |To:=20,=20; bh=MINVtRIequ6cbHi56gLjkOMAyfEPwKEVTtsyLmMtiAM=; b=iUbJj/xUlSFGYiYAdfgs5iFk+eyHlJzvBHmwywKz/idgMBp4n8q4i7dwOo w6zRpiQMPe7lwt1Li8JBXwCS9kWAKhO8B2FZtAR66mCgXESOpFAH+fxXW1zi SQYN6wjfBc; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org It ridiculous that folks wave a document from 1998 away. Further, does anyone even read emails carefully before replying? When I gave a reference to RFC 2401 where is was mandated that IPSec is a MUST for IPv6, I also gave a reference to RFC 4301 that is dated Dec 2005! Both RFC's have the same section 10 mandating IPSec as a MUST for IPv6. Someone else also suggested that maybe we can sub categorize the IPSec requirement based on different devices like big honking router vs. a small consumer device etc. I don't think that is wise because one has no clue what devices will come into being in future where devices support IPv6. Also read Tony Hain's email that discusses cable. This mailer has enough cable experienced folks to give their input. Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of michael.dillon@bt.com Sent: Wednesday, February 27, 2008 9:55 AM To: ipv6@ietf.org Subject: RE: the role of the node "requirements" document > I totally appreciate Alain's concern for cable modem devices with > limited memory for IPv6 but the problem is that IPv6 community decided > as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. The events of 1998 are irrelevant. The fact is that this website clearly does not consider IPsec to be part of the IPv6 core protocols and therefore lots of implementations will not have it. Cable boxes are not much different from general purpose computers running Linux. In fact, they may use Linux for all I know. In any case, they are complex devices and if you looked at an architecture diagram for them they would like rather like a network in a box with many functions on separate chips (or areas of an FPGA) all communicating with various internal protocols and busses. But IPv6 is not just for devices like that. It was also intended to be something that could be implemented on embedded devices that often use 8-bit CPUs with the IP stack written in carefully handcoded assembly language. TINI is an example of such a device but there are hundreds of them out there and manufacturers continue to introduce new 8-bit microcontrollers all the time. If you have any contacts with Yokogawa in Japan, they have a lot of experience in this area and will be able to give a better idea of how common it is to implement IPv6 without IPsec. WIDE people may also know more about this. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 07:26:58 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7310928C6D9; Wed, 27 Feb 2008 07:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWDeMH4zQKZr; Wed, 27 Feb 2008 07:26:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C9B3A6E0D; Wed, 27 Feb 2008 07:26:57 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA103A6A14 for ; Wed, 27 Feb 2008 07:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epa338BRPE59 for ; Wed, 27 Feb 2008 07:26:50 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AE17F3A6983 for ; Wed, 27 Feb 2008 07:26:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,413,1199692800"; d="scan'208";a="14968314" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 27 Feb 2008 07:26:44 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1RFQits015132; Wed, 27 Feb 2008 07:26:44 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m1RFQhqM029253; Wed, 27 Feb 2008 15:26:44 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 10:26:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Wed, 27 Feb 2008 10:26:35 -0500 Message-ID: In-Reply-To: <1cc401c8792a$5fa6bf90$1ef43eb0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4tcuU2Px0vBfqTMmRNmlVBU4dyQAcq+EgAArFAOA= References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com><47C47446.2050407@ca.afilias.info> <1cc401c8792a$5fa6bf90$1ef43eb0$@net> From: "Hemant Singh (shemant)" To: , X-OriginalArrivalTime: 27 Feb 2008 15:26:36.0435 (UTC) FILETIME=[24113E30:01C87955] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3108; t=1204126004; x=1204990004; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Making=20IPsec=20*not*=20mandatory=20in =20Node=20Requirement |Sender:=20; bh=9cydAaktuq33a9S3hmeGC8k6UXbSGcGo4rs8KSNXqbk=; b=th2X/cua7JuckHGLJUS27eeKYEGpqH+oeY7xKbGRckLhdACBU+1GiK+ezb eboiGoAXMZKRCP52Q+nbpXALhDgjM510+JCmkBSMJdwVz0un8JR4ZElTNLiN VBwAwssy/g0It8I+cW2u5y2RkA/CRynDAnahOuMia9HccJKAH8F8E=; Authentication-Results: sj-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Folks, Tony is right that cable is a closed environment. I am a cable CMTS router developer talking here. Also cable has its own security with BPI+ between the cable modem and CMTS (Cable Modem Termination System). See http://www.cablemodem.com/downloads/specs/CM-SP-BPI+_I12-050812.pdf. BPI+ is not IPSec, but the security is fairly similar. Public keys are negotiated between modem and CMTS and data traffic is encrypted between modem and the CMTS once keys are negotiated. When modem traffic reaches the CMTS, if the traffic has to be forwarded out from CMTS the packet is decrypted and sent in the clear. It's a CMTS configuration that mandates if the traffic from CMTS to the Internet core gets further encrypted if any IPSec is used between CMTS and the WAN/core router. Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tony Hain Sent: Wednesday, February 27, 2008 5:20 AM To: ipv6@ietf.org Subject: RE: Making IPsec *not* mandatory in Node Requirement Brian Dickson wrote: > ... > Any of a bunch of other kinds of security can do the job, from TLS to > SSH to use of out-of-band channels. For those that have forgotten, the entire reason for mandating IPsec is to get away from the 47 flavors of security that are never really configured correctly or completely understood. Yes for any given situation someone can design an optimized protocol, but as soon as the situation changes the optimization no longer applies, and may expose unexpected holes. This was in fact happening at the time the mandate was put in. > > And *this* is why I think that IPsec ought to be downgraded to SHOULD > for IPv6 node requirements. As I recall we had a lengthy argument about this, and really don't need to reopen it now. If there is not a single mandatory-to-implement protocol, there is no way to assure that two random products will have a common means of secure communication. Again, for a specific deployment or application, they can do whatever they want, but that does not remove the need for a common security protocol when it is not known which other device might need to talk to it 6 months down the road. Alain's original post is completely bogus. If his devices don't need IPsec, he is free to tell his vendors not to load it in the image. That is not a reason to change node-requirements. He is in a closed environment and knows that a random device will not appear that doesn't speak the security protocol for that closed environment. The IETF is defining requirements for IPv6 nodes that will appear in arbitrary environments, where there is no means to know the availability of a common security protocol, unless it was specified up front. Making it a SHOULD only ensures that vendors will never implement it, and force the 47 flavors of not-quite-security. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 08:19:10 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE90928C84D; Wed, 27 Feb 2008 08:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rcc4xmJCCzg; Wed, 27 Feb 2008 08:19:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A89F3A69EA; Wed, 27 Feb 2008 08:19:05 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924813A68A6 for ; Wed, 27 Feb 2008 08:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDo3FhijSZ7N for ; Wed, 27 Feb 2008 08:18:59 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id BA20728C80B for ; Wed, 27 Feb 2008 08:18:52 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m1RGIT1a019663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Feb 2008 10:18:30 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m1RGITSx029000; Wed, 27 Feb 2008 08:18:29 -0800 (PST) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m1RGIJGF028593; Wed, 27 Feb 2008 08:18:29 -0800 (PST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:18:25 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Making IPsec *not* mandatory in Node Requirement Date: Wed, 27 Feb 2008 11:18:25 -0500 Message-ID: In-Reply-To: <831FE02B5345194BA8147EDEF5F133882966D4D1@G3W0070.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach4zIlyxeO8CrvrQMiCAHRNieDDtgALG3JQABhSeeA= References: <47C49BBD.7060008@sri.com> <831FE02B5345194BA8147EDEF5F133882966D4D1@G3W0070.americas.hpqcorp.net> From: "Manfredi, Albert E" To: "Bound, Jim" , X-OriginalArrivalTime: 27 Feb 2008 16:18:25.0346 (UTC) FILETIME=[611F6A20:01C8795C] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] > On the > issue of e2e encrypt/decrypt except the header there are > those for many reasons will not want to permit this for the > reasons you state is my experience. I may we way off base, but when I read this, all I can conclude is that security is a non-starter. How can a system be considered secure if the data is not encrypted when it travels across non-trusted networks? And, who would consider his comm links secure if he has to trust the ISP? The NIST Profile makes this same point about plaintext through routers, and I concluded the same thing there. Sounds like a non-sequitur. In principle, authentication, in the non-trusted part of the network, is all that should be required. If security experts determined that AH is not so good, then maybe ESP within ISP nets is okay. But this does not remove the need for e2e encryption, IMO. > But do we take social and > law enforcement issues into consideration as IETF > individuals? The only logical answer is that whatever node inspects the packets has to be capable of decrypting them. Which means, it must become a trusted node. > But I don't think not doing e2e is > going to stop bad intentioned criminals. I'd put it more strongly. Not doing e2e IPsec invalidates the whole security model. It then becomes just something to show on a viewgraph, to try to confuse the innocent into believing that the system is secure. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 08:42:59 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2EE28C96B; Wed, 27 Feb 2008 08:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICyhoQkPD-UD; Wed, 27 Feb 2008 08:42:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4462E28C995; Wed, 27 Feb 2008 08:42:07 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F4328C8C8 for ; Wed, 27 Feb 2008 08:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3J7r1zAApgP for ; Wed, 27 Feb 2008 08:42:03 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 439FB28C828 for ; Wed, 27 Feb 2008 08:37:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id EA9BBA92F6; Wed, 27 Feb 2008 08:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGal380g7nNX; Wed, 27 Feb 2008 08:37:41 -0800 (PST) Received: from [192.168.7.81] (69-12-164-132.sfo.archedrock.com [69.12.164.132]) by mail.sf.archrock.com (Postfix) with ESMTP id 79493A92E0; Wed, 27 Feb 2008 08:37:41 -0800 (PST) Message-ID: <47C591D1.1030208@archrock.com> Date: Wed, 27 Feb 2008 08:37:37 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Bound, Jim" Subject: Re: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement) References: <7892795E1A87F04CADFCCF41FADD00FC05424329@xmb-ams-337.emea.cisco.com> <47C51981.4060003@archrock.com> <831FE02B5345194BA8147EDEF5F1338829778C1A@G3W0070.americas.hpqcorp.net> In-Reply-To: <831FE02B5345194BA8147EDEF5F1338829778C1A@G3W0070.americas.hpqcorp.net> Cc: "Pascal Thubert \(pthubert\)" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Right. We've already seen AES + CCM implemented in hardware with = 802.15.4 radios. While some of those implementations are currently 15.4 = specific, the fact that it is not more general could be considered an = 'implementation flaw'. The biggest concern to those of us trying to deal with IEEE 802.15.4 is = really the header overhead. For this reason, the security protocol for = IEEE 802.15.4 allows for variable size IV and ICV, giving the ability to = make the tradeoffs we need. The basic functions of RFC4309 seem = particularly applicable for IPsec over 802.15.4 links, but the header = size is of concern. The IV carried in each packet is required to be 8 = bytes and the ICV is required to be between 8 and 16 bytes. 802.15.4, on = the other hand, allows smaller fields for both the IV and ICV and gives = the flexibility to make tradeoffs. When you're working with nodes that = send very small messages and maximum frame sizes of 128 bytes (including = link headers), every byte counts. I'm also concerned on the requirement for automated key distribution. Is = it possible to claim that you support IPsec without supporting automated = key management like IKEv2 or something similar? I'm interested in working through this more in detail to do the study of = whether IPsec is a viable option and would like to solicit help from = those that have more expertise in this space. If anyone is interested, = let me know. -- Jonathan Hui Bound, Jim wrote: > It all comes down to is IPsec capable for the nodes within the discussion= below and I point to Tony Hain's mail that IPsec is far better than 47 sec= urity protocol options from an IETF doing our job here. Batteries are ener= gy cost impacting other work in the IETF too it is a reality we need to be = aware of for sure. > = > thanks > /jim > = >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: Wednesday, February 27, 2008 3:04 AM >> To: Pascal Thubert (pthubert) >> Cc: Bound, Jim; ipv6@ietf.org >> Subject: Re: IPsec and 6LoWPAN (was: Re: Making IPsec *not* >> mandatory inNode Requirement) >> >> >> To answer Jim's question following on Pascal's point, I don't >> believe that only link-layer security is enough because it >> lacks any end-to-end properties. It wasn't clear in my >> previous email, but multihop topologies are the norm in >> low-power wireless with IEEE 802.15.4. >> >> The ISA100.11a approach which sits above UDP or a lightweight >> version of IPsec which sits a bit lower in the layering are >> both much more attractive approaches to me than requiring >> IPsec, as we know it today, on sensor nodes. Of course, we >> won't get all of the features of a full-blown IPsec >> implementation, but we've got to trade something to live in >> this constrained world. I'm willing to live with that and I'm >> wondering what others on this list think about that. >> Specifically, is there a place for the IETF to specify a >> lightweight end-to-end security scheme in place of IPsec? >> >> The question of IPsec vs. engineering cost is in some sense >> true, but it doesn't capture the entire story. IPsec has >> significant header requirements, compared to the link MTU of >> IEEE 802.15.4. This translates directly to extra buffering >> requirements, channel utilization, and energy cost. You could >> argue to use bigger batteries, but some environments with >> physical and environmental constraints can't afford to do so. >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jim: >>> >>> All I can say is that at least one Wireless Sensor Network >> standard under development will not use IPSec. ISA100.11a >> (http://www.isa.org/MSTemplate.cfm?MicrositeID=3D1134&CommitteeI >> D=3D6891) has decided to endorse - and extend when necessary - >> the work done at 802.15.4 and 6LoWPAN, which means that we >> will have IPv6-based sensors in the industrial WSN space. I >> say it's great news and we-IETF should continue in our effort >> to support the ISA there. >>> ISA100.11a is defining a simple transport level security >> above UDP that is based on the AES encryption engine in the >> CCM mode (in reality CCM* as defined by 802.15.4, annex B, >> which refers to CCM as defined by ANSI X9.63-2001 as well as >> NIST Pub 800-38C and RFC 3610, that's a quote for the purists). >>> The ISA100.11a Transport level security replicates end to >> end what is done at the Data Link Layer in order to benefit >> from the chipset built-in features. No IKE, No IPSec at least >> for the current spec. A side effect of that design is that >> we'll be able to elide the UDP checksum in the 6LoWPAN >> compression by including the IPv6 pseudo header and the UDP >> ports in the Message Integrity Check computation, pushing the >> whole computation up a sublayer. >>> I've come to expect that the encryption will be done end to >> end at the transport level whereas the integrity and >> authentication will be played hop by hop over the DLL mesh, >> but that's a deployment decision. >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] >> On Behalf >>>> Of Bound, Jim >>>> Sent: mercredi 27 f=E9vrier 2008 05:46 >>>> To: Jonathan Hui; ipv6@ietf.org >>>> Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec >> *not* mandatory >>>> inNode Requirement) >>>> >>>> Good point and Gordon Bell has almost always been right >> for me so I >>>> know I listen to him. The key is do these low power and >> restricted >>>> sensor components require security at the IP layer? >>>> If IEEE xxx is secure can we conclude the IP layer is not relevant >>>> for sensors, but I would suggest they are for any sensor gateway >>>> nodes. Or can we develop in industry a micro-kernel IPsec >>>> implementation in hardware that can be cost effectively added to a >>>> sensor or set of sensor unions for a network? Clearly we >> are seeing >>>> this type of hardware development on microprocessors with the >>>> exponential appearance of deep packet inspection providers >> into the >>>> market that are not router/switch vendors. But is IPsec the right >>>> answer is the right question for lowpan for engineering >> cost reasons >>>> as opposed to is it possible? >>>> >>>> /jim >>>> >>>>> -----Original Message----- >>>>> From: ipv6-bounces@ietf.org >> [mailto:ipv6-bounces@ietf.org] On Behalf >>>>> Of Jonathan Hui >>>>> Sent: Tuesday, February 26, 2008 6:57 PM >>>>> To: ipv6@ietf.org >>>>> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* >> mandatory in >>>>> Node Requirement) >>>>> >>>>> >>>>> I won't argue against the fact that security is an important >>>> part of a >>>>> complete solution. The question for me is whether IPsec >> is the most >>>>> appropriate solution for highly constrained embedded devices >>>>> (constrained in energy, memory, compute, and link >>>> capabilities). From >>>>> the few implementation numbers thrown around this thread, >> it sounds >>>>> like IPsec is not an option for low-power wireless nodes >>>> with 8K RAM, >>>>> 48K ROM, 128B link MTU, and not to mention that any >> implementation >>>>> should leave enough space for an interesting application >> and should >>>>> operate for multiple years on modest batteries. >>>>> >>>>> One nice thing is that, given some application scenarios, >> there are >>>>> other ways to incorporate sufficient security without the >> need for >>>>> IPsec. For example, link-layer security may be sufficient >>>> for private >>>>> networks. Link-layer security may also be sufficient if border >>>>> routers/gateways attach to other traditional IP networks via >>>> encrypted >>>>> tunnels. >>>>> >>>>> I'm not a security expert, nor do I know the complete workings of >>>>> IPsec. >>>>> But I'd be curious if people strongly believe or have ideas >>>> on ways to >>>>> squeeze IPsec into devices that I'm interested in. >>>>> If not, is it at all possible to consider developing an >> alternative >>>>> end-to-end security mechanism that is lightweight. I'm >> not arguing >>>>> that this should be used between two traditional IP hosts, >>>> but that it >>>>> can be used between a traditional IP host communicating with a >>>>> low-power, wireless device or two low-power wireless devices >>>>> communicating directly. >>>>> >>>>> Gordon Bell observed that we've seen a new class of >> computing form >>>>> about every decade. IP has so far been able to follow >> these trends, >>>>> including hand held devices. Now we are at the beginning of yet >>>>> another class with low-power wireless devices based on IEEE >>>> 802.15.4, >>>>> and the 6lowpan effort within the IETF has set out to >> bring IPv6 to >>>>> this new class. I'd be disappointed if we couldn't come to an >>>>> agreement on how we can appropriately bring this new class >>>> into the IP >>>>> framework. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>>> Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>>>> >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>>> >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 08:58:42 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D819F28C86E; Wed, 27 Feb 2008 08:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=-2.804, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+RYcmYAeCsg; Wed, 27 Feb 2008 08:58:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93FA28C817; Wed, 27 Feb 2008 08:56:04 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805C73A696E for ; Wed, 27 Feb 2008 08:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZx1yPqm9CH3 for ; Wed, 27 Feb 2008 08:56:02 -0800 (PST) Received: from mailgate-internal2.sri.com (mailgate-internal2.SRI.COM [128.18.84.104]) by core3.amsl.com (Postfix) with SMTP id DB5A128C8AB for ; Wed, 27 Feb 2008 08:54:49 -0800 (PST) Received: from localhost (HELO mailgate-internal2.SRI.COM) (127.0.0.1) by mailgate-internal2.sri.com with SMTP; 27 Feb 2008 16:54:43 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal2.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2008022708544231309 for ; Wed, 27 Feb 2008 08:54:42 -0800 Received: from [192.168.1.101] (nj-76-6-39-209.dhcp.embarqhsd.net [76.6.39.209]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JWW00IY0PN5IFF6@mail.sri.com> for ipv6@ietf.org; Wed, 27 Feb 2008 08:54:42 -0800 (PST) Date: Wed, 27 Feb 2008 11:54:42 -0500 From: Ed Jankiewicz Subject: Re: the role of the node "requirements" document In-reply-to: To: ipv6@ietf.org Message-id: <47C595D2.8030703@sri.com> MIME-version: 1.0 References: User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org touche. IETF documents remain "current" unless obsoleted by another RFC. The corpus is cumulative, so we have to follow the precedent, even from the deep dark early days like 1998, or document there is consensus that a spec no longer applies (e.g. RFC 4966 rendering RFC 2766 NAT-PT historic.) As Jim Bound has stated many times, IETF defines standards not deployment, and the Node Requirements revision should reiterate that the standard for security in IPv6 is IPsec citing RFC 4301 (successor to 2401). OTOH, we at DoD and NIST are certainly addressing deployment issues - and in fact we do draw distinctions between Big Honking devices and smaller devices to "escape" some requirements where they will not be needed. Our deployment plans do not impose anything on the general community. Similarly, application specifics (for low power sensors, mobility, CPE etc.) can be separately documented, and in keeping with the "first do no harm" principle, as long as they don't interfere with anyone else's use of IPsec, it is reasonable for them to make their own exceptions. Let the buyer beware. As far as I know, DoD will probably only buy stuff with IPsec, but if an ISP doesn't think they need it in their CPE, they should be free to save the development cost and memory space. I agree with Hemant (and others' sentiments on this thread) that the Node Requirements doc should summarize the requirements for IPv6 nodes, and leave the exceptions, extensions and caveats to deployment documents like the NIST and DoD profiles and application documents. Hemant Singh (shemant) wrote: > It ridiculous that folks wave a document from 1998 away. Further, does > anyone even read emails carefully before replying? When I gave a > reference to RFC 2401 where is was mandated that IPSec is a MUST for > IPv6, I also gave a reference to RFC 4301 that is dated Dec 2005! Both > RFC's have the same section 10 mandating IPSec as a MUST for IPv6. > > Someone else also suggested that maybe we can sub categorize the IPSec > requirement based on different devices like big honking router vs. a > small consumer device etc. I don't think that is wise because one has no > clue what devices will come into being in future where devices support > IPv6. > > Also read Tony Hain's email that discusses cable. This mailer has enough > cable experienced folks to give their input. > > Hemant > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > michael.dillon@bt.com > Sent: Wednesday, February 27, 2008 9:55 AM > To: ipv6@ietf.org > Subject: RE: the role of the node "requirements" document > > >> I totally appreciate Alain's concern for cable modem devices with >> limited memory for IPv6 but the problem is that IPv6 community decided >> > > >> as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. >> > > The events of 1998 are irrelevant. The fact is that this website > > clearly does not consider IPsec to be part of the IPv6 core protocols > and therefore lots of implementations will not have it. > > Cable boxes are not much different from general purpose computers > running Linux. In fact, they may use Linux for all I know. In any case, > they are complex devices and if you looked at an architecture diagram > for them they would like rather like a network in a box with many > functions on separate chips (or areas of an FPGA) all communicating with > various internal protocols and busses. > > But IPv6 is not just for devices like that. It was also intended to be > something that could be implemented on embedded devices that often use > 8-bit CPUs with the IP stack written in carefully handcoded assembly > language. TINI is an example of such a device but there are hundreds of > them out there and manufacturers continue to introduce new 8-bit > microcontrollers all the time. > > If you have any contacts with Yokogawa in Japan, they have a lot of > experience in this area and will be able to give a better idea of how > common it is to implement IPv6 without IPsec. WIDE people may also know > more about this. > > --Michael Dillon > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 09:03:05 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55C228C9CE; Wed, 27 Feb 2008 09:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3uSqKjymySg; Wed, 27 Feb 2008 09:03:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7898628C958; Wed, 27 Feb 2008 09:00:50 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839AB28C742 for ; Wed, 27 Feb 2008 09:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfqxZVOBQRXD for ; Wed, 27 Feb 2008 09:00:44 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 2AA1728C96A for ; Wed, 27 Feb 2008 08:59:17 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1RGwjD5005538 for ; Wed, 27 Feb 2008 11:58:45 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1RGwjGI242662 for ; Wed, 27 Feb 2008 11:58:45 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1RGwjO1007572 for ; Wed, 27 Feb 2008 11:58:45 -0500 Received: from cichlid.raleigh.ibm.com (wecm-9-67-140-227.wecm.ibm.com [9.67.140.227]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1RGwi49007506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 11:58:44 -0500 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m1RGwgOM011514; Wed, 27 Feb 2008 11:58:42 -0500 Message-Id: <200802271658.m1RGwgOM011514@cichlid.raleigh.ibm.com> To: Basavaraj Patil Subject: Re: Making IPsec *not* mandatory in Node Requirement In-reply-to: References: Comments: In-reply-to Basavaraj Patil message dated "Tue, 26 Feb 2008 11:58:16 -0600." Date: Wed, 27 Feb 2008 11:58:42 -0500 From: Thomas Narten Cc: John Loughney , ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Basavaraj Patil writes: > I agree with Thomas about his views on IPsec being a mandatory and > default component of the IPv6 stack. Because of this belief, Mobile > IPv6 (RFC3775) design relied on IPsec for securing the > signaling. This has lead to complexity of the protocol and not > really helped either in adoption or implementation. To be clear, this is a simplistic explanation. Had IPsec (and IKE) not been used for MIPv6, they would have had to invent a whole new security protocol for securing things. As we know, coming up with yet another security mechanism is hugely problematic for the IETF. It is far from clear that the MIPv6 WG had the necessary competence to do this, and it is far from clear that the security community would have found the problem space interesting enough to help the WG get it right. > IPsec based security is an overkill for Mobile IPv6 and illustrates > the point that you do not have to use it simply because it happens > to be an integral part of IPv6. THe reason for choosing IPsec was not just because it was "part of IPv6". It was also chosen because there wasn't really another obvious alternative to use. And inventing a new one would have been duanting. (And please don't point to RFC 4285 as the solution. The IESG note that goes with that document is not to be dismissed lightly.) Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 09:17:08 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FFF3A6BDD; Wed, 27 Feb 2008 09:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDsPZQJfR50z; Wed, 27 Feb 2008 09:17:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5865028C8FE; Wed, 27 Feb 2008 09:16:30 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596783A6E4A for ; Wed, 27 Feb 2008 09:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpmODILake6b for ; Wed, 27 Feb 2008 09:16:27 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 14FBE28C93D for ; Wed, 27 Feb 2008 09:14:44 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1RHEF6e027601 for ; Wed, 27 Feb 2008 12:14:15 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1RHEFPQ388264 for ; Wed, 27 Feb 2008 12:14:15 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1RHEF5E030896 for ; Wed, 27 Feb 2008 12:14:15 -0500 Received: from cichlid.raleigh.ibm.com (wecm-9-67-140-227.wecm.ibm.com [9.67.140.227]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1RHEEK1030821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 12:14:14 -0500 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m1RHED68018076; Wed, 27 Feb 2008 12:14:13 -0500 Message-Id: <200802271714.m1RHED68018076@cichlid.raleigh.ibm.com> To: alh-ietf@tndh.net Subject: Re: Making IPsec *not* mandatory in Node Requirement In-reply-to: <1cc401c8792a$5fa6bf90$1ef43eb0$@net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com><831FE02B5345194BA8147EDEF5F133882966CD9E@G3W0070.americas.hpqcorp.net> <38F26F36EAA981478A49D1F37F474A86010DA283@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010C4839@daebe104.NOE.Nokia.com> <47C47446.2050407@ca.afilias.info> <1cc401c8792a$5fa6bf90$1ef43eb0$@net> Comments: In-reply-to "Tony Hain" message dated "Wed, 27 Feb 2008 18:20:25 +0800." Date: Wed, 27 Feb 2008 12:14:13 -0500 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Tony, > For those that have forgotten, the entire reason for mandating IPsec is to > get away from the 47 flavors of security that are never really configured > correctly or completely understood. Yes for any given situation someone can > design an optimized protocol, but as soon as the situation changes the > optimization no longer applies, and may expose unexpected holes. This was in > fact happening at the time the mandate was put in. Right. Having one way to do things is far better than having 47. But if we look at the reality of things, IPsec (and we have to include IKE in evaluating this), IPsec just isn't the ideal one-size-fits-all technology we'd like it to be. For example, one big problem is the lack of a proper API for applications to communicate with IPsec to select services and verify that a certain level of security is present. Second, good security says "don't trust anyone but yourself". So, do you trust the OS you are running on? Do you trust the IPsec embedded in the system that was implemented by a third party? Smart applications implement their own security (e.g., TLS) to ease deployment. We'll never get them to rely on IPsec, at least not until its much more widely available/useable. There are other examples. To channel Randy Bush: > o the net should have mandatory crypto period > > o ipsec sucks This is the dilemma we are in. Personally, I think we are exhibiting a bit of head-in-the-sand mentality to continue saying IPsec is a MUST, when we don't even bother include IKE! IPsec without key management is useless except in very narrow deployment scenarios. > As I recall we had a lengthy argument about this, and really don't need to > reopen it now. If there is not a single mandatory-to-implement protocol, > there is no way to assure that two random products will have a common means > of secure communication. Sure. But I can also see lots of devices that (because of the mix of applications/functionality of the device) simply won't use IPsec becuase it doesn't make sense. Why MUST they implement IPsec when it won't actually get used? If you look at reality, IPsec is not the universal crypto suite. I suspect the market has spoken. > Alain's original post is completely bogus. If his devices don't need IPsec, > he is free to tell his vendors not to load it in the image. That is not a > reason to change node-requirements. He is in a closed environment and knows > that a random device will not appear that doesn't speak the security > protocol for that closed environment. I agree with this as well. In the case of cable modems, Alain shouldn't care about what node requirements says. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 09:27:01 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D68B28C832; Wed, 27 Feb 2008 09:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.056 X-Spam-Level: X-Spam-Status: No, score=-1.056 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w669fxLau2t; Wed, 27 Feb 2008 09:27:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F72C28C3D7; Wed, 27 Feb 2008 09:22:47 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE9428C323 for ; Wed, 27 Feb 2008 09:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wmnis7cWF8sC for ; Wed, 27 Feb 2008 09:22:44 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A198728C414 for ; Wed, 27 Feb 2008 09:20:43 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1RHK5qn015896; Wed, 27 Feb 2008 19:20:31 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 19:20:31 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:20:28 -0600 Received: from 10.138.85.184 ([10.138.85.184]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Feb 2008 17:20:28 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 27 Feb 2008 11:21:40 -0600 Subject: Re: Making IPsec *not* mandatory in Node Requirement From: Basavaraj Patil To: Thomas Narten Message-ID: Thread-Topic: Making IPsec *not* mandatory in Node Requirement Thread-Index: Ach5ZTbpdS7kYuVYEdylSAARJNUNiA== In-Reply-To: <200802271658.m1RGwgOM011514@cichlid.raleigh.ibm.com> Mime-version: 1.0 X-OriginalArrivalTime: 27 Feb 2008 17:20:28.0327 (UTC) FILETIME=[0C313B70:01C87965] X-Nokia-AV: Clean Cc: John Loughney , ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thomas, Why do you believe MIP6 did not simply adopt the same security model as MIP4 and instead choose IPsec? It was because of the view that IPsec support in IPv6 by default exists and hence should be used. And the IESG statement in RFC4285 needs to be revisited and deprecated because the arguments that were the basis for it to be inserted do not apply in many deployments (especially in networks which do not care about the route-optimization feature). -Raj On 2/27/08 10:58 AM, "ext Thomas Narten" wrote: > Basavaraj Patil writes: > >> I agree with Thomas about his views on IPsec being a mandatory and >> default component of the IPv6 stack. Because of this belief, Mobile >> IPv6 (RFC3775) design relied on IPsec for securing the >> signaling. This has lead to complexity of the protocol and not >> really helped either in adoption or implementation. > > To be clear, this is a simplistic explanation. Had IPsec (and IKE) not > been used for MIPv6, they would have had to invent a whole new > security protocol for securing things. As we know, coming up with yet > another security mechanism is hugely problematic for the IETF. It is > far from clear that the MIPv6 WG had the necessary competence to do > this, and it is far from clear that the security community would have > found the problem space interesting enough to help the WG get it > right. > >> IPsec based security is an overkill for Mobile IPv6 and illustrates >> the point that you do not have to use it simply because it happens >> to be an integral part of IPv6. > > THe reason for choosing IPsec was not just because it was "part of > IPv6". It was also chosen because there wasn't really another obvious > alternative to use. And inventing a new one would have been > duanting. (And please don't point to RFC 4285 as the solution. The > IESG note that goes with that document is not to be dismissed > lightly.) > > Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 09:36:44 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571BC28C8F2; Wed, 27 Feb 2008 09:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICtPN00nNwh5; Wed, 27 Feb 2008 09:36:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4923A6E8D; Wed, 27 Feb 2008 09:32:38 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B79C3A6EA6 for ; Wed, 27 Feb 2008 09:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru7YU6Vn30wS for ; Wed, 27 Feb 2008 09:32:32 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 37E7E3A6E84 for ; Wed, 27 Feb 2008 09:32:00 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1RHVrOq028930 for ; Wed, 27 Feb 2008 17:31:53 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m1RHVrHl062177 for ; Wed, 27 Feb 2008 12:31:53 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1RHKZlM022601; Wed, 27 Feb 2008 12:20:35 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1RHKRkI022598; Wed, 27 Feb 2008 12:20:27 -0500 (EST) MIME-Version: 1.0 Message-ID: <18373.39899.246979.270406@gargle.gargle.HOWL> Date: Wed, 27 Feb 2008 12:20:27 -0500 From: James Carlson To: Ed Jankiewicz Subject: Re: the role of the node "requirements" document In-Reply-To: <47C595D2.8030703@sri.com> References: <47C595D2.8030703@sri.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ed Jankiewicz writes: > As Jim Bound has stated many times, IETF defines standards not > deployment, and the Node Requirements revision should reiterate that the > standard for security in IPv6 is IPsec citing RFC 4301 (successor to > 2401). OTOH, we at DoD and NIST are certainly addressing deployment That's an argument for: "if you claim to implement security at all with IPv6, you must at least implement IPsec as described in {insert references}." It's not a good argument for "everyone must implement security in all cases in order to be considered a good IPv6 citizen, even if they have no plans to use those security protocols, so there." > I agree with Hemant (and others' sentiments on this thread) that the > Node Requirements doc should summarize the requirements for IPv6 nodes, > and leave the exceptions, extensions and caveats to deployment documents > like the NIST and DoD profiles and application documents. If you do that, then the likely outcome is that systems that are designed to be used in those special, constrained environments where IPv6 is useful, but IPsec is not, will end up lacking the "IPv6 Ready" logo and other acceptability marks. It makes hash of those other profiles by requiring what isn't necessarily required. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 09:44:28 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF5A3A6B25; Wed, 27 Feb 2008 09:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2+nFXP9CTtI; Wed, 27 Feb 2008 09:44:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0333528C2C7; Wed, 27 Feb 2008 09:44:27 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE563A6B25 for ; Wed, 27 Feb 2008 09:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1MXYS0HC8Fg for ; Wed, 27 Feb 2008 09:44:24 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4DF613A6AC0 for ; Wed, 27 Feb 2008 09:44:24 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1RHhgKU006522; Wed, 27 Feb 2008 19:44:14 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 19:43:34 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:43:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Wed, 27 Feb 2008 11:43:26 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A010EAB19@daebe104.NOE.Nokia.com> In-Reply-To: <18373.39899.246979.270406@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5Z44TBmXEfL+wQ7qjMb8CNgea4gAABtQw References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> From: To: , X-OriginalArrivalTime: 27 Feb 2008 17:43:25.0982 (UTC) FILETIME=[4156B3E0:01C87968] X-Nokia-AV: Clean Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org James, >Ed Jankiewicz writes: >> As Jim Bound has stated many times, IETF defines standards not >> deployment, and the Node Requirements revision should reiterate that >> the standard for security in IPv6 is IPsec citing RFC 4301 >(successor >> to 2401). OTOH, we at DoD and NIST are certainly addressing >> deployment > >That's an argument for: "if you claim to implement security at >all with IPv6, you must at least implement IPsec as described >in {insert references}." > >It's not a good argument for "everyone must implement security >in all cases in order to be considered a good IPv6 citizen, >even if they have no plans to use those security protocols, so there." Well, I would say that we (HW, SW, Platform providers) cannot expect to understand all of the ways that their products will be deployed, so it is extremely hard to state "security is not needed." I am sure we can find a few corner cases, but I find it hard to believe that we can accept this as a general truism. The Security Area has clearly stated that security is important; having mechanisms to secure protocols is manditory; multiple non-madatory solutions decrease security. I interpret this to mean that if you have IPv6, you need a common mechanism to secure it. There is L2 security, and there are things like DTLS and TLS, but there needs to be security to be available at the IP layer. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 10:00:29 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410F628C771; Wed, 27 Feb 2008 10:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDbLXuSTyJeF; Wed, 27 Feb 2008 10:00:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9883A6C52; Wed, 27 Feb 2008 10:00:14 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6AE28C6D9 for ; Wed, 27 Feb 2008 10:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ-dKVGuRItf for ; Wed, 27 Feb 2008 10:00:12 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 1F58D28C6CA for ; Wed, 27 Feb 2008 10:00:12 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1RI04M1024585 for ; Wed, 27 Feb 2008 13:00:04 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1RHxul5153102 for ; Wed, 27 Feb 2008 10:59:59 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1RHxuEH026912 for ; Wed, 27 Feb 2008 10:59:56 -0700 Received: from cichlid.raleigh.ibm.com (wecm-9-67-140-227.wecm.ibm.com [9.67.140.227]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1RHxsbg026810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 10:59:55 -0700 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m1RHxrFL011955; Wed, 27 Feb 2008 12:59:53 -0500 Message-Id: <200802271759.m1RHxrFL011955@cichlid.raleigh.ibm.com> To: john.loughney@nokia.com Subject: Re: the role of the node "requirements" document In-reply-to: <19EBBEC503C3B5469070E0A6674A533A010EAB19@daebe104.NOE.Nokia.com> References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <19EBBEC503C3B5469070E0A6674A533A010EAB19@daebe104.NOE.Nokia.com> Comments: In-reply-to message dated "Wed, 27 Feb 2008 11:43:26 -0600." Date: Wed, 27 Feb 2008 12:59:53 -0500 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org John, > Well, I would say that we (HW, SW, Platform providers) cannot expect > to understand all of the ways that their products will be deployed, > so it is extremely hard to state "security is not needed." That is not what I (and I suspect others) are saying. What I am saying is that security (in practice) turns out to be much harder than "just use IPsec". Really. The corollary to this is that mandating IPsec (at the node level) doesn't actually get you usuable security in IPv6. TO get real security, you have to consider the actual application that needs securing as well as the operational environment where the deployment will take place. There are plenty of applications that already have security that do not use IPsec. Should we/can we force them to use IPsec? No. And if an IPv6 node has limited functionality/purpose, and none of that functionality appears likely to use IPsec (because it has other means for providing security), what is the point of requiring IPsec? I think the big message that people are missing is that IPsec has not become the unbiquitous base-line security that we had once hoped for. And even today, IPv6 only mandates IPsec (with manual keys). No key managment. And if there is one thing we have learned from practical deployments, it's all about key mangement/distribution. That is the hard stuff that makes or breaks usability. Mandating IPsec with just static keying just isn't useful in practice. Thus, continuing to mandate IPsec (while continuing to punt on key management) just looks silly. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 10:12:56 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF0228C1DA; Wed, 27 Feb 2008 10:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5XSsTAXAjM9; Wed, 27 Feb 2008 10:12:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D055D28C274; Wed, 27 Feb 2008 10:12:54 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9433A6973 for ; Wed, 27 Feb 2008 10:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adjNlre7Ctfw for ; Wed, 27 Feb 2008 10:12:53 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 9CF5D3A6AA8 for ; Wed, 27 Feb 2008 10:12:46 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1RICdYe023879 for ; Wed, 27 Feb 2008 18:12:40 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m1RICdaJ034141 for ; Wed, 27 Feb 2008 13:12:39 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1RI1Oxw022812; Wed, 27 Feb 2008 13:01:25 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1RI1KG2022807; Wed, 27 Feb 2008 13:01:20 -0500 (EST) MIME-Version: 1.0 Message-ID: <18373.42352.804585.757980@gargle.gargle.HOWL> Date: Wed, 27 Feb 2008 13:01:20 -0500 From: James Carlson To: john.loughney@nokia.com Subject: RE: the role of the node "requirements" document In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A010EAB19@daebe104.NOE.Nokia.com> References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <19EBBEC503C3B5469070E0A6674A533A010EAB19@daebe104.NOE.Nokia.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org john.loughney@nokia.com writes: > James, > > >Ed Jankiewicz writes: > >> As Jim Bound has stated many times, IETF defines standards not > >> deployment, and the Node Requirements revision should reiterate that > >> the standard for security in IPv6 is IPsec citing RFC 4301 > >(successor > >> to 2401). OTOH, we at DoD and NIST are certainly addressing > >> deployment > > > >That's an argument for: "if you claim to implement security at > >all with IPv6, you must at least implement IPsec as described > >in {insert references}." > > > >It's not a good argument for "everyone must implement security > >in all cases in order to be considered a good IPv6 citizen, > >even if they have no plans to use those security protocols, so there." > > Well, I would say that we (HW, SW, Platform providers) cannot expect to > understand > all of the ways that their products will be deployed, so it is extremely Some platform vendors _do_ sell into markets where deployments are well understood. Others, as you rightly note, do not. I don't see a reason to saddle vendors who don't need a particular feature with an empty requirement to provide it anyway. > hard > to state "security is not needed." I am sure we can find a few corner > cases, > but I find it hard to believe that we can accept this as a general > truism. If we can't assert that it's true in all cases, then why use "MUST"? > The Security Area has clearly stated that security is important; having > mechanisms to secure protocols is manditory; multiple non-madatory > solutions decrease security. I agree with the first and last of those, but not necessarily the second. That's why I believe that the text should say: SHOULD implement IPsec and perhaps even: if any security protocols are implemented, then MUST implement at least IPsec That leaves room for vendors who have no need of IPsec to comply with the requirements. It seems to me that what might be missing here is the definition of "SHOULD." It's not a whimsical requirement. That word has special meaning in this context: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. In other words, vendors who don't know what they're doing, and don't understand the full implications of it, are required to follow the recommendation. Those who don't follow it need to know exactly what they're doing and why the choice is right -- which matches up exactly with your "few corner cases" comment above. > I interpret this to mean that if you have IPv6, you need a common > mechanism > to secure it. No ... it means that if you have any common security mechanism, then you need to provide a single common one. Providing more than one is not as good, but, clearly, providing zero is reasonable provided that you _know_ nobody will use it anyway. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 10:13:47 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63EF3A6AC0; Wed, 27 Feb 2008 10:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0wUwJz6JeWM; Wed, 27 Feb 2008 10:13:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E971B3A6B69; Wed, 27 Feb 2008 10:13:42 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA45E3A6920 for ; Wed, 27 Feb 2008 10:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW-izIuOPHVj for ; Wed, 27 Feb 2008 10:13:36 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 5EA4F3A6B69 for ; Wed, 27 Feb 2008 10:13:34 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1RIDPAw002368 for ; Wed, 27 Feb 2008 18:13:25 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m1RIDPP0034390 for ; Wed, 27 Feb 2008 13:13:25 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1RI2BUV022820; Wed, 27 Feb 2008 13:02:11 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1RI2AGR022817; Wed, 27 Feb 2008 13:02:10 -0500 (EST) MIME-Version: 1.0 Message-ID: <18373.42402.715455.350811@gargle.gargle.HOWL> Date: Wed, 27 Feb 2008 13:02:10 -0500 From: James Carlson To: Thomas Narten Subject: Re: the role of the node "requirements" document In-Reply-To: <200802271759.m1RHxrFL011955@cichlid.raleigh.ibm.com> References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <19EBBEC503C3B5469070E0A6674A533A010EAB19@daebe104.NOE.Nokia.com> <200802271759.m1RHxrFL011955@cichlid.raleigh.ibm.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: john.loughney@nokia.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thomas Narten writes: > Thus, continuing to mandate IPsec (while continuing to punt on key > management) just looks silly. Indeed. It's a solution out looking for a problem. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 10:23:29 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229073A6E23; Wed, 27 Feb 2008 10:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.581 X-Spam-Level: X-Spam-Status: No, score=-0.581 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0N3rtZhtoYX; Wed, 27 Feb 2008 10:23:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7937E28C10C; Wed, 27 Feb 2008 10:23:23 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9313A6AA8 for ; Wed, 27 Feb 2008 10:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq-juCpc1mTC for ; Wed, 27 Feb 2008 10:23:17 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by core3.amsl.com (Postfix) with ESMTP id DAF8328C34F for ; Wed, 27 Feb 2008 10:22:53 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so970927uge.46 for ; Wed, 27 Feb 2008 10:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=yChlp7fv1GSTpIM7bDJ3F9tNc0BOTsCHApkYaIDgXLE=; b=wUxXAS1W6u3xO92WgShPeLGZii4CFlr+4en6ioZcPncJx73WrGrXySQc+hYIimZP/6kuDEt46m6K+KPskjOzFCARq6DkdfkXPlfOzwue9TLXlBCoWPfZ+GqmxWZbfotFaMFDbfOmec7Akq4L3xQWlfiQjwIA5x3kQxCanseFMaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lVXTC5Y9EV4FuCVUBiKghXgdXocSQMkBeU/IkXYQBWgAv3eKboQ1x7Mx7MD2pIwyIleMw3tCinITAk4guuJmxZXRxvR3BF9sQ4DrgJUlfo7U9PEjglvlBLzNo5e7RNgmShF09OeX9deL3zDyaR4RXbPVoaWUn5g2ukeny9tncZI= Received: by 10.66.240.12 with SMTP id n12mr1514221ugh.9.1204136566156; Wed, 27 Feb 2008 10:22:46 -0800 (PST) Received: by 10.86.35.18 with HTTP; Wed, 27 Feb 2008 10:22:46 -0800 (PST) Message-ID: <729b68be0802271022u59211594k8805af1946ac4166@mail.gmail.com> Date: Wed, 27 Feb 2008 19:22:46 +0100 From: "Jean-Michel Combes" To: "Thomas Narten" Subject: Re: the role of the node "requirements" document In-Reply-To: <200802271759.m1RHxrFL011955@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Disposition: inline References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <19EBBEC503C3B5469070E0A6674A533A010EAB19@daebe104.NOE.Nokia.com> <200802271759.m1RHxrFL011955@cichlid.raleigh.ibm.com> Cc: john.loughney@nokia.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Thomas, 2008/2/27, Thomas Narten : > John, > [snip] > > And even today, IPv6 only mandates IPsec (with manual keys). No key > managment. And if there is one thing we have learned from practical > deployments, it's all about key mangement/distribution. That is the > hard stuff that makes or breaks usability. > > Mandating IPsec with just static keying just isn't useful in practice. > > Thus, continuing to mandate IPsec (while continuing to punt on key > management) just looks silly. IMHO, mandating IPsec allows a "Better-Than-Nothing" security (c) :-) Just a quick example: Assume that one day, someone finds a security hole in a protocol used for a specific service and having its own security mechanism. With IPsec, even with manual configuration, you will be able to continue to provide this service until a review of the protocol because you know that the peers have a IPsec implementation. That should limit a service disruption due to a security issue. Best regards. JMC. > > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 10:46:32 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E2928C742; Wed, 27 Feb 2008 10:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCga7FT4RzYG; Wed, 27 Feb 2008 10:46:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55DE3A6C52; Wed, 27 Feb 2008 10:46:24 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187983A684C for ; Wed, 27 Feb 2008 10:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVtCHOXl+VqF for ; Wed, 27 Feb 2008 10:46:18 -0800 (PST) Received: from mailgate-internal1.sri.com (mailgate-internal1.SRI.COM [128.18.84.103]) by core3.amsl.com (Postfix) with SMTP id 65E453A6A81 for ; Wed, 27 Feb 2008 10:46:18 -0800 (PST) Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 27 Feb 2008 18:46:06 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal1.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2008022710460629641 for ; Wed, 27 Feb 2008 10:46:06 -0800 Received: from [192.168.1.101] (nj-76-6-39-209.dhcp.embarqhsd.net [76.6.39.209]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JWW00IZ4USSISK6@mail.sri.com> for ipv6@ietf.org; Wed, 27 Feb 2008 10:46:06 -0800 (PST) Date: Wed, 27 Feb 2008 13:46:03 -0500 From: Ed Jankiewicz Subject: Re: the role of the node "requirements" document In-reply-to: <18373.39899.246979.270406@gargle.gargle.HOWL> To: James Carlson Message-id: <47C5AFEB.3080303@sri.com> MIME-version: 1.0 References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org James: James Carlson wrote: > Ed Jankiewicz writes: > >> As Jim Bound has stated many times, IETF defines standards not >> deployment, and the Node Requirements revision should reiterate that the >> standard for security in IPv6 is IPsec citing RFC 4301 (successor to >> 2401). OTOH, we at DoD and NIST are certainly addressing deployment >> > > That's an argument for: "if you claim to implement security at all > with IPv6, you must at least implement IPsec as described in {insert > references}." > > It's not a good argument for "everyone must implement security in all > cases in order to be considered a good IPv6 citizen, even if they have > no plans to use those security protocols, so there." > > I'll concede that point. We need to say one or the other (unconditional or conditional MUST) and it seems this is the best forum to hash that out. I am not religious about it being an unconditional MUST in the Node Requirements. I am suggesting a "non-interference" statement, that to be a good IPv6 citizen you MUST NOT inhibit the use of IPsec. >> I agree with Hemant (and others' sentiments on this thread) that the >> Node Requirements doc should summarize the requirements for IPv6 nodes, >> and leave the exceptions, extensions and caveats to deployment documents >> like the NIST and DoD profiles and application documents. >> > > If you do that, then the likely outcome is that systems that are > designed to be used in those special, constrained environments where > IPv6 is useful, but IPsec is not, will end up lacking the "IPv6 Ready" > logo and other acceptability marks. > > I still believe in choice - customers can extend requirements to add special features, and can make choices regarding products without IPsec where they are adequate. IETF can publish another 5000 RFCs that mandate IPsec, but vendors and customers are free to build and buy products that don't have it. IETF should state what is necessary for interoperability, including statements about non-interference in some cases. As long as I can use IPsec when I want it, why should I care if my neighbor has a host without it? Or if my ISP blindly passes it without having any IPsec implementation? I would care if my ISP blocked it because it prevented their "deep packet inspection." > It makes hash of those other profiles by requiring what isn't > necessarily required. > > also a good point - exceptions are messier than extensions - but as long as exceptions are non-interfering, let the buyer beware. Ed J. -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 11:28:33 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE773A6E4D; Wed, 27 Feb 2008 11:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00s2DmX9Y8pl; Wed, 27 Feb 2008 11:28:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AEC28C5F0; Wed, 27 Feb 2008 11:28:23 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B523A6C6B for ; Wed, 27 Feb 2008 11:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt0hZPP6D0nj for ; Wed, 27 Feb 2008 11:28:21 -0800 (PST) Received: from smtp138.iad.emailsrvr.com (smtp138.iad.emailsrvr.com [207.97.245.138]) by core3.amsl.com (Postfix) with ESMTP id 4412C28C7FE for ; Wed, 27 Feb 2008 11:28:15 -0800 (PST) Received: from relay3.r3.iad.emailsrvr.com (localhost [127.0.0.1]) by relay3.r3.iad.emailsrvr.com (SMTP Server) with ESMTP id D536444C1C1; Wed, 27 Feb 2008 14:28:07 -0500 (EST) Received: by relay3.r3.iad.emailsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTP id 379E244C275; Wed, 27 Feb 2008 14:28:07 -0500 (EST) In-Reply-To: <18373.39899.246979.270406@gargle.gargle.HOWL> References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> From: Dow Street Subject: Re: the role of the node "requirements" document Date: Wed, 27 Feb 2008 11:27:52 -0800 To: James Carlson X-Mailer: Apple Mail (2.752.3) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Feb 27, 2008, at 9:20 AM, James Carlson wrote: > It's not a good argument for "everyone must implement security in all > cases in order to be considered a good IPv6 citizen, even if they have > no plans to use those security protocols, so there." As I understand it, the current architecture of the Internet explicitly allows for local optimization everywhere but IP itself - IP is the one place where global functionality and interoperability trumps local optimization. In defining the requirements for IP nodes, we are (I think) essentially defining the properties of the Internet itself. In this case, I tend to think that there should be a mandatory security mechanism at the IP layer, at least for any IPv6 node that is connected to the global Internet (or might be connected in the future). It is less clear to me that IPsec is the best mechanism to provide this functionality, but changing to a new mechanism now may be worse than just sticking with IPsec. quick poll - for those opposed to a MUST requirement for IPsec, what is your driving objection? 1. the Internet *does not* need a mandatory security mechanism at the IP layer 2. the Internet *does* need a mandatory security mechanism at the IP layer, but IPsec is not the right one because it is too heavyweight 3. the Internet *does* need a mandatory security mechanism at the IP layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc) 4. I don't care about the architecture of the Internet, because I intend to develop devices that are never connected to the global Internet (and therefore play no role in defining the Internet architecture or adhering to Internet best practices). R, Dow -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 12:19:06 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B19728C673; Wed, 27 Feb 2008 12:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HBzVC5nS0pW; Wed, 27 Feb 2008 12:18:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968B128C376; Wed, 27 Feb 2008 12:18:48 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA8B3A6C5A for ; Wed, 27 Feb 2008 12:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmC0WL64II8Y for ; Wed, 27 Feb 2008 12:18:42 -0800 (PST) Received: from mail.polartel.com (mail.polartel.com [66.231.96.142]) by core3.amsl.com (Postfix) with ESMTP id 53D2828C4AA for ; Wed, 27 Feb 2008 12:18:09 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: the role of the node "requirements" document Date: Wed, 27 Feb 2008 14:18:01 -0600 Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail> In-Reply-To: <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5dxJAmcvzTKDCQpq9fEK6iUEQOwABjqEQ References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> From: "Kevin Kargel" To: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > quick poll - for those opposed to a MUST requirement for > IPsec, what is your driving objection? > My feeling is that we should not introduce mandatory cost factors for end devices. There are many sensor-ish devices that do not require strict security. If it is possible, could we say that IPSEC is MUST for routing hardware and SHOULD for end user devices? That way the end-to-end availablity is still serviced, but low risk devices can stay simple and cheap. Kevin :$s/worry/happy/g -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 12:45:36 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7186C28C4BC; Wed, 27 Feb 2008 12:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IQ9PocBdO50; Wed, 27 Feb 2008 12:45:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A9F28C279; Wed, 27 Feb 2008 12:45:30 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80F128C2B7 for ; Wed, 27 Feb 2008 12:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2JV9C52pAwM for ; Wed, 27 Feb 2008 12:45:28 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id B898728C140 for ; Wed, 27 Feb 2008 12:45:28 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1RKjLfB015481 for ; Wed, 27 Feb 2008 20:45:22 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m1RKjLnC061200 for ; Wed, 27 Feb 2008 15:45:21 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1RKY731023741; Wed, 27 Feb 2008 15:34:07 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1RKY16n023736; Wed, 27 Feb 2008 15:34:01 -0500 (EST) MIME-Version: 1.0 Message-ID: <18373.51513.398270.398946@gargle.gargle.HOWL> Date: Wed, 27 Feb 2008 15:34:01 -0500 From: James Carlson To: Dow Street Subject: Re: the role of the node "requirements" document In-Reply-To: <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Dow Street writes: > 1. the Internet *does not* need a mandatory security mechanism at > the IP layer > 2. the Internet *does* need a mandatory security mechanism at the IP > layer, but IPsec is not the right one because it is too heavyweight > 3. the Internet *does* need a mandatory security mechanism at the IP > layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc) > 4. I don't care about the architecture of the Internet, because I > intend to develop devices that are never connected to the global > Internet (and therefore play no role in defining the Internet > architecture or adhering to Internet best practices). I suppose I'm closest to (1) in your list, but I'd still phrase it differently. 5. IP itself works properly without IPsec -- and demonstrably so. It's not a _requirement_; it's not something that without which IP simply fails to operate. It's desirable, and likely highly desirable, but it's not a fundamental issue. It's fine to say that implementations darn well ought to have security mechanisms unless they've got some really compelling reasons not to. It's also fine to say that choosing a common one is far, far better than having several. However, that's not what "MUST" means. MUST means that you have no options for any other possible environment -- do it, or just ignore the RFC. "SHOULD" carries with it a great deal of force. You have some real explaining to do if you choose to ignore the recommendation. You can't just do it on a whim. I'd go so far as to say that if you choose otherwise, and the result of your choice is that you fail to fulfill other obligations that you have, then you've chosen incorrectly and you're not complying with the letter of the RFC -- you SHOULD have implemented it. I suspect that the people who are arguing in favor of "MUST" have a fear that "SHOULD" is just too weak. I don't see how that's the case at all, as it does indeed force nearly all implementors (those who wish to become or remain compliant with the requirements of the RFC) to implement IPsec -- which is exactly what the "MUST" contingent wants. (And, really, the lack of mandated key management does make even the "SHOULD" language a bit of a farce, as Thomas Narten has correctly observed. You're not really getting any security goodness by implementing a fraction of the bits needed for a real solution.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 13:01:57 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF3F28C466; Wed, 27 Feb 2008 13:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.438 X-Spam-Level: X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv2J-nRJ5m32; Wed, 27 Feb 2008 13:01:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96DEA3A6A15; Wed, 27 Feb 2008 13:01:51 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EC93A698E for ; Wed, 27 Feb 2008 13:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hCLqxySJ2F0 for ; Wed, 27 Feb 2008 13:01:45 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3986E3A6920 for ; Wed, 27 Feb 2008 13:01:45 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2008 13:01:38 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1RL1cDE020607; Wed, 27 Feb 2008 16:01:38 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1RL15Bt006455; Wed, 27 Feb 2008 21:01:37 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 16:01:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Use longest-matching prefix to the next hop Date: Wed, 27 Feb 2008 16:01:27 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use longest-matching prefix to the next hop Thread-Index: Ach4H7vy7KDK6+ZjQWCXFFgwvp0ZvQBYJtkQ References: From: "Hemant Singh (shemant)" To: "FUJIKAWA Kenji" , X-OriginalArrivalTime: 27 Feb 2008 21:01:28.0651 (UTC) FILETIME=[EBF619B0:01C87983] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5438; t=1204146098; x=1205010098; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Use=20longest-matching=20prefix=20to=20 the=20next=20hop |Sender:=20 |To:=20=22FUJIKAWA=20Kenji=22=20,=20< ipv6@ietf.org>; bh=Z8kYeOrNrQAb99PaufTeM8cLpMbN67d8DSEOCRKjsoU=; b=w0PSQWaPd6MgKdH42dlK8whO2pHzE43kvSxAeZcpWTNoeMwH8VeaiKFSyZ 71+8FoJ+TdhiEmH3Xa7XsfglSgHOQs34OK9zeAlnDNdP9VnENQkl0zM8qrJT LdR23mC1kQ; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The draft should not be considered for 6man as a WG item just yet because it needs some more work before the draft is even acceptable to review. Here is some things to look at after I read portions of the draft at the URL below. 1. Section 1 of the draft says 2001:db8:3001:1:EN is selected as the source address of a packet directed from CN to EN. Huh? CN has only an address of 2001:db8:2001::CN, so how can a src of 2001:db8:3001:1:EN be picked? 2. Section 1 says: [Here, in the above IPv6 address notation, CN, R1, R2, and EN indicates 64bit Interface ID's.] There is no router R2 in the picture of Fig. 1. How can one review this document with such basic mistakes/typos in the picture? 3. In section 3 you say: [Before Rule 8 (Use longest matching prefix) in section 5. (Source Address Selection) in RFC3484, the rule using longest-matching prefix to the next hop is to be added.] Did I get is right that you are changing src-addr based on next hop? Basic IP data forwarding and routing ships packets between consecutive hops using L2 addresses. For packet flow from src to dest with multiple hops in between, the L3 src and dest addresses do not change! Src and dest L3 addresses can only be changed by some proxy node in the path. I hope you are not suggesting changing L3 src-addr from hop to hop! I suggest you forget about the solution. First define your src-addr selection problem and let the mailer first agree you have a problem. Then we'll see what is the solution. You have a lot of sections in the draft with problems/issues, viz., 1. A Problem of at Source Address Selection Rule 8. in RFC3484 2.1 Management Issue 2.2 Implementation Issue It confuses the reader as to what is the one single problem you are trying to solve. Or if you are solving multiple problems, list them at the beginning of the draft. Sorry, if I have missed such problem definitions in the mailer earlier than one year from now. I suggest the same to the authors of draft-ietf-6man-addr-select-sol-00.txt. Could you please first describe what is the problem with SAS as specified in RFC 3484. Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of FUJIKAWA Kenji Sent: Monday, February 25, 2008 9:31 PM To: ipv6@ietf.org Subject: Use longest-matching prefix to the next hop Hi all, I am submitting an ID, http://www.ietf.org/proceedings/staging/draft-fujikawa-ipv6-src-addr-sel ection-02.txt and suggesting in the draft that, Before Rule 8 (Use longest matching prefix) in section 5. (Source Address Selection) in RFC3484, the rule using longest-matching prefix to the next hop is to be added. The following is an example, where the Rule 8 selects the roundabout path via ISP3, while the method of using longest-matching prefix to the next hop selects the shortest and best path, when EN sends a packet to CN. # In the previous IETF meeting I only showed a single router case. # but this method is adaptable and useful to the multiple router case. I would like to ask if 6man people is interested in this topic, and this can become working group item. +---+ |CN | +-+-+ | 2001:db8:2001::CN | +---+---+2001:db8:2000:/36 | | +---------+ ISP2 | | | | | +-------+ | +---+---+2001:db8:1000:/36 +-------+2001:db8:3000::/36 | | | | | ISP1 +-------------------+ ISP3 | | | | | +---+---+ +---+---+ | | | | +----------+ +--------+ 2001:db8:1000:R1| |2001:db8:3000:R3 +-+-+ +-+-+ 2001:db8:1001::/48|R1 | |R3 |2001:db8:3001::/48 +-+-+ +-+-+ 2001:db8:1001:1:R1| |2001:db8:3001:1:R3 | | --+---+---+-- 2001:db8:1001:1:EN | 2001:db8:3001:1:EN +-+-+ |EN | +---+ Routing Tables: R1: Destination Next Hop 2001:db8:1000::/36 address_of_ISP1's_router 2001:db8:2000::/36 address_of_ISP1's_router R3: 2001:db8:3000::/36 address_of_ISP3's_router EN: Destination Next Hop 2001:db8:1000::/36 2001:db8:1001:1:R1 2001:db8:2000::/36 2001:db8:1001:1:R1 2001:db8:3000::/36 2001:db8:3001:1:R3 Any questions and comments are welcome. Regards, ------------------------------------------------------------------ FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan Mail: fujikawa@root-hq.com, hudikaha@gmail.com WWW: http://www23.atwiki.jp/hudikaha/ Skype: fujikawakenji -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 13:08:11 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF763A6B76; Wed, 27 Feb 2008 13:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3+iqXBjdtCF; Wed, 27 Feb 2008 13:08:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866073A6A2C; Wed, 27 Feb 2008 13:08:10 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63713A6819 for ; Wed, 27 Feb 2008 13:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ELm+eZe-Ggl for ; Wed, 27 Feb 2008 13:08:08 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 47D823A6A2A for ; Wed, 27 Feb 2008 13:08:05 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k40so4610593wah.25 for ; Wed, 27 Feb 2008 13:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=AGK+Uq3F1VtfkDUgPoqPx5cXnNPDCO1XW1YgSd/mgqY=; b=RdSHhpF4prY3UwY1M3k4pNqoIWi63qytd1NkVB8N/ufIyUyxJRiBfRZloHiS9j25eFsd8hNVGVemYE8vsN5jOJkgVRFj+DsKWfGsY1sVPH/RYoye8oRhe6qE0AmuFiBVVvMtnKQPjVoJksH4J01lcCjYZRIJ5bwq7fGP1Xj2psE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KyFcHi6V1f6Nj4AAqzy0mds9sUIx47i8VhIENV22UknEcEZDvvB8kw1oe+J1Y3BAXtVy87tWG9goUHf5h+3zfxxOpEaRQf1PE+ihnEcdVbeY/T+RsGoeilcSbffG0k3/RHzJHu4P5gIbriyv6DSCJdZBHdklVaK7d7PFInUT4ko= Received: by 10.114.67.2 with SMTP id p2mr8100538waa.1.1204146478814; Wed, 27 Feb 2008 13:07:58 -0800 (PST) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id a8sm14027651poa.2.2008.02.27.13.07.57 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Feb 2008 13:07:58 -0800 (PST) Message-ID: <47C5D12B.8000708@gmail.com> Date: Thu, 28 Feb 2008 10:07:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: James Carlson Subject: Re: the role of the node "requirements" document References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> <18373.51513.398270.398946@gargle.gargle.HOWL> In-Reply-To: <18373.51513.398270.398946@gargle.gargle.HOWL> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2008-02-28 09:34, James Carlson wrote: > Dow Street writes: >> 1. the Internet *does not* need a mandatory security mechanism at >> the IP layer >> 2. the Internet *does* need a mandatory security mechanism at the IP >> layer, but IPsec is not the right one because it is too heavyweight >> 3. the Internet *does* need a mandatory security mechanism at the IP >> layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc) >> 4. I don't care about the architecture of the Internet, because I >> intend to develop devices that are never connected to the global >> Internet (and therefore play no role in defining the Internet >> architecture or adhering to Internet best practices). > > I suppose I'm closest to (1) in your list, but I'd still phrase it > differently. > > 5. IP itself works properly without IPsec -- and demonstrably so. > It's not a _requirement_; it's not something that without which IP > simply fails to operate. It's desirable, and likely highly > desirable, but it's not a fundamental issue. I'm close to this position too, but even closer to 6. As long as the IETF specifies a way of securing the IP layer, it's an implementation, procurement and operational issue whether it gets used. Words in an RFC have no control over that. And don't forget what Thomas said about keying. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 13:28:28 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B1A3A6E44; Wed, 27 Feb 2008 13:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55EPMJ5U-kVc; Wed, 27 Feb 2008 13:28:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3193A6911; Wed, 27 Feb 2008 13:28:22 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9573A679C for ; Wed, 27 Feb 2008 13:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhNqhK3itBgD for ; Wed, 27 Feb 2008 13:28:21 -0800 (PST) Received: from mailgate-internal1.sri.com (mailgate-internal1.SRI.COM [128.18.84.103]) by core3.amsl.com (Postfix) with SMTP id 57AD83A6B8D for ; Wed, 27 Feb 2008 13:27:36 -0800 (PST) Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 27 Feb 2008 21:27:29 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal1.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2008022713272906461 for ; Wed, 27 Feb 2008 13:27:29 -0800 Received: from [192.168.1.101] (nj-76-6-39-209.dhcp.embarqhsd.net [76.6.39.209]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JWX00I9R29SIFT6@mail.sri.com> for ipv6@ietf.org; Wed, 27 Feb 2008 13:27:29 -0800 (PST) Date: Wed, 27 Feb 2008 16:27:26 -0500 From: Ed Jankiewicz Subject: Re: the role of the node "requirements" document In-reply-to: <47C5D12B.8000708@gmail.com> To: ipv6@ietf.org Message-id: <47C5D5BE.9050906@sri.com> MIME-version: 1.0 References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> <18373.51513.398270.398946@gargle.gargle.HOWL> <47C5D12B.8000708@gmail.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Cc: Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I lean towards (3) because IPsec without IKE or something is unmanageable. I could support MUST or SHOULD, or a conditional statement, and would prefer linking to IKEv2 as part of the package. Thomas hinted at the "chicken and egg" problem with IKEv2 - we'd like to mandate it to encourage implementation, but hesitate to mandate something that hardly exists in the near future... But I would go along with Brian's sentiment about IETF not dictating use; that has been said a few times in various ways during this discussion. Reality is even if 4294 is not updated, it makes no difference to the actual implementation and use of IPsec; if revision says nothing about IPsec, it makes no difference. If the revision says SHOULD or MUST, probably makes no difference. Implementors will make their own choices as will buyers of products. Brian E Carpenter wrote: > On 2008-02-28 09:34, James Carlson wrote: > >> Dow Street writes: >> >>> 1. the Internet *does not* need a mandatory security mechanism at >>> the IP layer >>> 2. the Internet *does* need a mandatory security mechanism at the IP >>> layer, but IPsec is not the right one because it is too heavyweight >>> 3. the Internet *does* need a mandatory security mechanism at the IP >>> layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc) >>> 4. I don't care about the architecture of the Internet, because I >>> intend to develop devices that are never connected to the global >>> Internet (and therefore play no role in defining the Internet >>> architecture or adhering to Internet best practices). >>> >> I suppose I'm closest to (1) in your list, but I'd still phrase it >> differently. >> >> 5. IP itself works properly without IPsec -- and demonstrably so. >> It's not a _requirement_; it's not something that without which IP >> simply fails to operate. It's desirable, and likely highly >> desirable, but it's not a fundamental issue. >> > > I'm close to this position too, but even closer to > > 6. As long as the IETF specifies a way of securing the IP layer, > it's an implementation, procurement and operational issue > whether it gets used. Words in an RFC have no control over that. > > And don't forget what Thomas said about keying. > > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 14:42:09 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6752228C38F; Wed, 27 Feb 2008 14:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwlanSem6gvA; Wed, 27 Feb 2008 14:42:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8253A6CFB; Wed, 27 Feb 2008 14:42:08 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC38028C34F for ; Wed, 27 Feb 2008 14:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge0MQONB2LIf for ; Wed, 27 Feb 2008 14:42:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0CBD03A6824 for ; Wed, 27 Feb 2008 14:42:05 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Feb 2008 23:41:59 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1RMfwLZ018387; Wed, 27 Feb 2008 23:41:58 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1RMfwME011740; Wed, 27 Feb 2008 22:41:58 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 23:41:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Wed, 27 Feb 2008 23:43:37 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A8601119D4A@xmb-ams-33d.emea.cisco.com> In-Reply-To: <47C5D5BE.9050906@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5h89P2pBVTg1OSqa3vIfd99ymRgACfVnQ References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL><02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com><18373.51513.398270.398946@gargle.gargle.HOWL><47C5D12B.8000708@gmail.com> <47C5D5BE.9050906@sri.com> From: "Julien Abeille (jabeille)" To: "Ed Jankiewicz" , X-OriginalArrivalTime: 27 Feb 2008 22:41:58.0336 (UTC) FILETIME=[F5EF0400:01C87991] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3662; t=1204152119; x=1205016119; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20the=20role=20of=20the=20node=20=22requi rements=22=20document |Sender:=20; bh=0gbB96P7nPSBI6W5Mo7O05OJYu/fgXakIQixQ5aNmyM=; b=PiDbvF2OR3ximZwI41yh6iMgcNGFBUX5ulQ074E/STV12Jg9vovDD1XghQ Hcn8BSDpNRbCh04ZsCn0BfzJlOYiYckx+4BzzcYXexUaF/NNpFzMCCpqBO3J Sm3gZw1PJi; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, My fear is that if implementations on e.g. sensors show that IPSec is not a= ffordable for this kind of device, and we put an unconditional MUST, in a f= ew years from now we will have billions of device which do not respect RFC4= 294. With a SHOULD it is the same kind of issue, billions of device will be= the exception. Julien -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ed = Jankiewicz Sent: mercredi 27 f=E9vrier 2008 13:27 To: ipv6@ietf.org Cc: Brian E Carpenter Subject: Re: the role of the node "requirements" document I lean towards (3) because IPsec without IKE or something is unmanageable. = I could support MUST or SHOULD, or a conditional statement, and would pref= er linking to IKEv2 as part of the package. = Thomas hinted at the "chicken and egg" problem with IKEv2 - we'd like to ma= ndate it to encourage implementation, but hesitate to mandate something tha= t hardly exists in the near future... But I would go along with Brian's sentiment about IETF not dictating use; t= hat has been said a few times in various ways during this discussion. Real= ity is even if 4294 is not updated, it makes no difference to the actual im= plementation and use of IPsec; if revision says nothing about IPsec, it mak= es no difference. If the revision says SHOULD or MUST, probably makes no d= ifference. Implementors will make their own choices as will buyers of prod= ucts. Brian E Carpenter wrote: > On 2008-02-28 09:34, James Carlson wrote: > = >> Dow Street writes: >> = >>> 1. the Internet *does not* need a mandatory security mechanism at = >>> the IP layer 2. the Internet *does* need a mandatory security = >>> mechanism at the IP layer, but IPsec is not the right one because it = >>> is too heavyweight 3. the Internet *does* need a mandatory security = >>> mechanism at the IP layer, but IPsec *alone* is insufficient = >>> (without IKE, key mgmt, etc) 4. I don't care about the architecture = >>> of the Internet, because I intend to develop devices that are never = >>> connected to the global Internet (and therefore play no role in = >>> defining the Internet architecture or adhering to Internet best = >>> practices). >>> = >> I suppose I'm closest to (1) in your list, but I'd still phrase it = >> differently. >> >> 5. IP itself works properly without IPsec -- and demonstrably so. >> It's not a _requirement_; it's not something that without which IP >> simply fails to operate. It's desirable, and likely highly >> desirable, but it's not a fundamental issue. >> = > > I'm close to this position too, but even closer to > > 6. As long as the IETF specifies a way of securing the IP layer, it's = > an implementation, procurement and operational issue whether it gets = > used. Words in an RFC have no control over that. > > And don't forget what Thomas said about keying. > > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > = -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engin= eering Branch 732-389-1003 or ed.jankiewicz@sri.com = -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 14:44:39 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBB528C219; Wed, 27 Feb 2008 14:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.689 X-Spam-Level: X-Spam-Status: No, score=-0.689 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkGcmlNidbns; Wed, 27 Feb 2008 14:44:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992AA28C395; Wed, 27 Feb 2008 14:44:33 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D863A6831 for ; Wed, 27 Feb 2008 14:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2emhDd9L7Va6 for ; Wed, 27 Feb 2008 14:44:26 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CBBA728C493 for ; Wed, 27 Feb 2008 14:43:57 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1RMjIJ7012815; Wed, 27 Feb 2008 16:45:19 -0600 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 00:43:40 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 16:43:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Wed, 27 Feb 2008 16:43:37 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A010EAE4C@daebe104.NOE.Nokia.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A8601119D4A@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5h89P2pBVTg1OSqa3vIfd99ymRgACfVnQAAAVU5A= References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL><02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com><18373.51513.398270.398946@gargle.gargle.HOWL><47C5D12B.8000708@gmail.com><47C5D5BE.9050906@sri.com> <38F26F36EAA981478A49D1F37F474A8601119D4A@xmb-ams-33d.emea.cisco.com> From: To: , , X-OriginalArrivalTime: 27 Feb 2008 22:43:38.0323 (UTC) FILETIME=[3187D230:01C87992] X-Nokia-AV: Clean Cc: brian.e.carpenter@gmail.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >My fear is that if implementations on e.g. sensors show that >IPSec is not affordable for this kind of device, and we put an >unconditional MUST, in a few years from now we will have >billions of device which do not respect RFC4294. With a SHOULD >it is the same kind of issue, billions of device will be the exception. What is the harm if 1 million sensors are not respecting RFC 4294? John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 14:52:50 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8185D3A6DE1; Wed, 27 Feb 2008 14:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFKSQVRMEfHM; Wed, 27 Feb 2008 14:52:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985E83A6A9E; Wed, 27 Feb 2008 14:52:49 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72DB63A6A9E for ; Wed, 27 Feb 2008 14:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mriRw5JrYUd0 for ; Wed, 27 Feb 2008 14:52:46 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3022A3A6862 for ; Wed, 27 Feb 2008 14:52:22 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Feb 2008 23:52:15 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1RMqDEp026024; Wed, 27 Feb 2008 23:52:13 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1RMqDME013874; Wed, 27 Feb 2008 22:52:13 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 23:52:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Wed, 27 Feb 2008 23:53:52 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A8601119D57@xmb-ams-33d.emea.cisco.com> In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A010EAE4C@daebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5h89P2pBVTg1OSqa3vIfd99ymRgACfVnQAAAVU5AAAEm5MA== References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL><02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com><18373.51513.398270.398946@gargle.gargle.HOWL><47C5D12B.8000708@gmail.com><47C5D5BE.9050906@sri.com> <38F26F36EAA981478A49D1F37F474A8601119D4A@xmb-ams-33d.emea.cisco.com> <19EBBEC503C3B5469070E0A6674A533A010EAE4C@daebe104.NOE.Nokia.com> From: "Julien Abeille (jabeille)" To: , , X-OriginalArrivalTime: 27 Feb 2008 22:52:13.0414 (UTC) FILETIME=[648C7860:01C87993] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=863; t=1204152733; x=1205016733; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20the=20role=20of=20the=20node=20=22requi rements=22=20document |Sender:=20; bh=l4hjfibqZnB3ihQAdrqyJcVtHage+MeO3gDaYzZRJXo=; b=d1GxasoEdOPeOwkAVX0d44wUSHuC+hgwdplVySRzEZBh+FUtS2dBJAw0to BJtT9nWb3YwggYnZkxvcbZsbr3qOUFLDAZu3OahM2Zj6sUGKb29tIKp3ZpLz AC4ilBWlBT; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: brian.e.carpenter@gmail.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi John, To clarify: - I was talking of sensors immplementing "some" IPv6 - It means companies would not care about this RFC Julien -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] = Sent: mercredi 27 f=E9vrier 2008 14:44 To: Julien Abeille (jabeille); edward.jankiewicz@sri.com; ipv6@ietf.org Cc: brian.e.carpenter@gmail.com Subject: RE: the role of the node "requirements" document >My fear is that if implementations on e.g. sensors show that IPSec is = >not affordable for this kind of device, and we put an unconditional = >MUST, in a few years from now we will have billions of device which do = >not respect RFC4294. With a SHOULD it is the same kind of issue, = >billions of device will be the exception. What is the harm if 1 million sensors are not respecting RFC 4294? John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 16:09:37 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A304E28C477; Wed, 27 Feb 2008 16:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=-2.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4w70e9gvK8w; Wed, 27 Feb 2008 16:09:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B821F3A6DE1; Wed, 27 Feb 2008 16:09:36 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A523A6DA3 for ; Wed, 27 Feb 2008 16:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtFekl8nrd9Z for ; Wed, 27 Feb 2008 16:09:29 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id CE64F3A6D6D for ; Wed, 27 Feb 2008 16:09:29 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 47788238D930 for ; Wed, 27 Feb 2008 16:09:23 -0800 (PST) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 272D128091 for ; Wed, 27 Feb 2008 16:09:23 -0800 (PST) X-AuditID: 11807130-aa2b6bb00000575e-95-47c5fbb267e6 Received: from il0602f-dhcp142.apple.com (il0602f-dhcp142.apple.com [17.206.50.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 114C628081 for ; Wed, 27 Feb 2008 16:09:22 -0800 (PST) Message-Id: From: james woodyatt To: IETF IPv6 Mailing List In-Reply-To: <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: the role of the node "requirements" document Date: Wed, 27 Feb 2008 16:09:21 -0800 References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> X-Mailer: Apple Mail (2.919.2) X-Brightmail-Tracker: AAAAAA== X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Feb 27, 2008, at 11:27, Dow Street wrote: > > 3. the Internet *does* need a mandatory security mechanism at the > IP layer, but IPsec *alone* is insufficient (without IKE, key mgmt, > etc) This is what I'd prefer with *one* qualification. I would merely *recommend* it for devices that are capable of IPv6 communication only with peers at link-local scope addresses over links that implement their own link-layer security. I say this from the experience of watching IEEE 802.11 progress from "security is optional" to "we messed up security really bad, sorry about that" to "security is strongly recommended, no really, everybody uses it now," and soon to "security is absolutely mandatory, we will kidnap your family and disappear you to jail if you don't secure your network." I'll be sad if I have to go through that again with IPv6. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 16:46:37 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC7D28C82E; Wed, 27 Feb 2008 16:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkh3ESRYwg7Q; Wed, 27 Feb 2008 16:46:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169B23A6E3A; Wed, 27 Feb 2008 16:46:36 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4B028C7CC for ; Wed, 27 Feb 2008 16:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwUZCMQ7Bk2b for ; Wed, 27 Feb 2008 16:46:29 -0800 (PST) Received: from blnkms22.securesites.net (blnkms22.securesites.net [198.170.88.17]) by core3.amsl.com (Postfix) with ESMTP id 5C5D23A6E3A for ; Wed, 27 Feb 2008 16:46:29 -0800 (PST) Received: from [172.16.1.35] (adsl-67-119-110-158.dsl.snfc21.pacbell.net [67.119.110.158]) (authenticated bits=0) by blnkms22.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id m1S0kKGY073695; Thu, 28 Feb 2008 00:46:21 GMT Message-ID: <47C6046D.20207@blunkmicro.com> Date: Wed, 27 Feb 2008 16:46:37 -0800 From: Sean Lawless Organization: Blunk Microsystems User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Kevin Kargel Subject: Re: the role of the node "requirements" document References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail> In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Greetings all, I've been reading this group for some time and appreciate everyones work. For the most part I have followed the discussions of the past but would now like to throw in my 2 cents. Kevin and many others against mandating (MUST) for IPSec have a valid point. Many sensors and other potential IPv6 nodes do not have the hardware resources to support IPSec, or those resources are better spent at other tasks. This may fall under #4 in Dow Street's driving objection to RFC 4294 wording of MUST, but not necessarily. With the simplicity of securing IP at the edge router with an IPSec tunnel, the point of mandating IPSec for nodes appears unwarranted. I agree with Kevin that IPSec be SHOULD for hosts (but remain a MUST for routers). My argument is similar to #5 made by James Carlson. There are many situations were IPv6 will be deployed without IPSec. There is no need to label these devices as non-IPv6 compliant within this hosts requirements document. My gut feeling is that if IPSec MUST be supported then why is using it optional? A MUST that is optional wouldn't be the first in IETF history but let it be known that some objected. Some years ago I thought static keyed IPSec to be better than no security. In reality IPSec can be compromised with enough traffic analysis, especially if portions of the clear text can be discerned (ICMPv6, etc). Operational security depends on key changing and thus key management. Over time, static keyed IPSec is either masochistic to manage or provides only the illusion of security. Thus I also agree with Thomas, Ed and others that mandating static IPSec without key management will result in it's non use and now we're back to a MUST that is optional to deploy. In conclusion I believe RFC 4294 be changed to SHOULD for IPSec because of #3, #4 and #5 of the poll. BR, **Sean Lawless** * | * /*Senior Software Engineer*/ * | * *Blunk Microsystems LLC* * | 408.XXX.XXXX* Kevin Kargel wrote: > > > >> quick poll - for those opposed to a MUST requirement for >> IPsec, what is your driving objection? >> >> > My feeling is that we should not introduce mandatory cost factors for > end devices. There are many sensor-ish devices that do not require > strict security. > > If it is possible, could we say that IPSEC is MUST for routing hardware > and SHOULD for end user devices? That way the end-to-end availablity is > still serviced, but low risk devices can stay simple and cheap. > > Kevin > > :$s/worry/happy/g > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 20:41:07 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6DC28C880; Wed, 27 Feb 2008 20:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LVEZexdRPfn; Wed, 27 Feb 2008 20:41:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0713A68C8; Wed, 27 Feb 2008 20:41:01 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063863A68C8 for ; Wed, 27 Feb 2008 20:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmF9w47BgpWs for ; Wed, 27 Feb 2008 20:40:53 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id BFE5E3A684B for ; Wed, 27 Feb 2008 20:40:53 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k40so4875458wah.25 for ; Wed, 27 Feb 2008 20:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=aWxCTrOdFYz8C6JpWziFqoJ7jv11GF8RJSak8Sf4AcM=; b=XalpCrG/xzy8fePibOxJLRS9VNreidX1pLNFgRIRMqLkcokdcyE6vKj7pXpRSBkJXtOSYzzSn7TM2wiF4OJ/UxrZn4sTP6fr41NuZ7+PN/IONIZM1/thl+2ZfFQwG6bWDlOT7gr/pVhVGlKgx8HdvlRleg6xKYmdHrD+0ubBDlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UVMPpeleW0ECLgYUBO25aYsiQp0FH76wc9NOrl8sNXuhCRIRIbKV6MOEBQP5REOh6OrylFAMKQjjgFS/EdPjcNgdLU6ap7Wm7vF8Pq+4RrVVagq2urWGnC4C4QHSUSpoCn8bFmFY8ytbEWHAEytpeLp9DlQc9FECf+ZRFQmrLV4= Received: by 10.115.94.1 with SMTP id w1mr74945wal.85.1204173646701; Wed, 27 Feb 2008 20:40:46 -0800 (PST) Received: by 10.115.108.10 with HTTP; Wed, 27 Feb 2008 20:40:46 -0800 (PST) Message-ID: <77f1dba80802272040m72b0dd07n549184714fd55b46@mail.gmail.com> Date: Thu, 28 Feb 2008 13:40:46 +0900 From: "Eunsook \"Eunah\" Kim" To: "Jonathan Hui" Subject: Re: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement) In-Reply-To: <47C591D1.1030208@archrock.com> MIME-Version: 1.0 Content-Disposition: inline References: <7892795E1A87F04CADFCCF41FADD00FC05424329@xmb-ams-337.emea.cisco.com> <47C51981.4060003@archrock.com> <831FE02B5345194BA8147EDEF5F1338829778C1A@G3W0070.americas.hpqcorp.net> <47C591D1.1030208@archrock.com> Cc: "Pascal Thubert \(pthubert\)" , "ipv6@ietf.org" , "Bound, Jim" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, I'm not a security expert, so I'm not eligible to make detail technical discussion on it. But I have the same concern with Pascal and Jonathan. As Jonathan and Pascal already explained the concerns on IPsec in sensor nodes' view, I won't repeat it. I just want to ask the experts on this area to consider the reality that many 6LoWPAN implementors feel hard to squeeze IPsec into the small sensor nodes. I hope that this discussion trigger either the study of IPSec if it can be enough lightweight to be applicable on 6LoWPAN nodes, or practical solutions on sensor network security. Thanks, -eunah (PS) ISA's choice sounds very interesting for me, although I need to check the details. Thanks Pascal for the information. On 2/28/08, Jonathan Hui wrote: > > Right. We've already seen AES + CCM implemented in hardware with > 802.15.4 radios. While some of those implementations are currently 15.4 > specific, the fact that it is not more general could be considered an > 'implementation flaw'. > > The biggest concern to those of us trying to deal with IEEE 802.15.4 is > really the header overhead. For this reason, the security protocol for > IEEE 802.15.4 allows for variable size IV and ICV, giving the ability to > make the tradeoffs we need. The basic functions of RFC4309 seem > particularly applicable for IPsec over 802.15.4 links, but the header > size is of concern. The IV carried in each packet is required to be 8 > bytes and the ICV is required to be between 8 and 16 bytes. 802.15.4, on > the other hand, allows smaller fields for both the IV and ICV and gives > the flexibility to make tradeoffs. When you're working with nodes that > send very small messages and maximum frame sizes of 128 bytes (including > link headers), every byte counts. > > I'm also concerned on the requirement for automated key distribution. Is > it possible to claim that you support IPsec without supporting automated > key management like IKEv2 or something similar? > > I'm interested in working through this more in detail to do the study of > whether IPsec is a viable option and would like to solicit help from > those that have more expertise in this space. If anyone is interested, > let me know. > > -- > Jonathan Hui > > > Bound, Jim wrote: > > It all comes down to is IPsec capable for the nodes within the discussi= on below and I point to Tony Hain's mail that IPsec is far better than 47 s= ecurity protocol options from an IETF doing our job here. Batteries are en= ergy cost impacting other work in the IETF too it is a reality we need to b= e aware of for sure. > > > > thanks > > /jim > > > >> -----Original Message----- > >> From: Jonathan Hui [mailto:jhui@archrock.com] > >> Sent: Wednesday, February 27, 2008 3:04 AM > >> To: Pascal Thubert (pthubert) > >> Cc: Bound, Jim; ipv6@ietf.org > >> Subject: Re: IPsec and 6LoWPAN (was: Re: Making IPsec *not* > >> mandatory inNode Requirement) > >> > >> > >> To answer Jim's question following on Pascal's point, I don't > >> believe that only link-layer security is enough because it > >> lacks any end-to-end properties. It wasn't clear in my > >> previous email, but multihop topologies are the norm in > >> low-power wireless with IEEE 802.15.4. > >> > >> The ISA100.11a approach which sits above UDP or a lightweight > >> version of IPsec which sits a bit lower in the layering are > >> both much more attractive approaches to me than requiring > >> IPsec, as we know it today, on sensor nodes. Of course, we > >> won't get all of the features of a full-blown IPsec > >> implementation, but we've got to trade something to live in > >> this constrained world. I'm willing to live with that and I'm > >> wondering what others on this list think about that. > >> Specifically, is there a place for the IETF to specify a > >> lightweight end-to-end security scheme in place of IPsec? > >> > >> The question of IPsec vs. engineering cost is in some sense > >> true, but it doesn't capture the entire story. IPsec has > >> significant header requirements, compared to the link MTU of > >> IEEE 802.15.4. This translates directly to extra buffering > >> requirements, channel utilization, and energy cost. You could > >> argue to use bigger batteries, but some environments with > >> physical and environmental constraints can't afford to do so. > >> > >> -- > >> Jonathan Hui > >> > >> > >> Pascal Thubert (pthubert) wrote: > >>> Hi Jim: > >>> > >>> All I can say is that at least one Wireless Sensor Network > >> standard under development will not use IPSec. ISA100.11a > >> (http://www.isa.org/MSTemplate.cfm?MicrositeID=3D1134&CommitteeI > >> D=3D6891) has decided to endorse - and extend when necessary - > >> the work done at 802.15.4 and 6LoWPAN, which means that we > >> will have IPv6-based sensors in the industrial WSN space. I > >> say it's great news and we-IETF should continue in our effort > >> to support the ISA there. > >>> ISA100.11a is defining a simple transport level security > >> above UDP that is based on the AES encryption engine in the > >> CCM mode (in reality CCM* as defined by 802.15.4, annex B, > >> which refers to CCM as defined by ANSI X9.63-2001 as well as > >> NIST Pub 800-38C and RFC 3610, that's a quote for the purists). > >>> The ISA100.11a Transport level security replicates end to > >> end what is done at the Data Link Layer in order to benefit > >> from the chipset built-in features. No IKE, No IPSec at least > >> for the current spec. A side effect of that design is that > >> we'll be able to elide the UDP checksum in the 6LoWPAN > >> compression by including the IPv6 pseudo header and the UDP > >> ports in the Message Integrity Check computation, pushing the > >> whole computation up a sublayer. > >>> I've come to expect that the encryption will be done end to > >> end at the transport level whereas the integrity and > >> authentication will be played hop by hop over the DLL mesh, > >> but that's a deployment decision. > >>> Pascal > >>> > >>> > >>>> -----Original Message----- > >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > >> On Behalf > >>>> Of Bound, Jim > >>>> Sent: mercredi 27 f=E9vrier 2008 05:46 > >>>> To: Jonathan Hui; ipv6@ietf.org > >>>> Subject: RE: IPsec and 6LoWPAN (was: Re: Making IPsec > >> *not* mandatory > >>>> inNode Requirement) > >>>> > >>>> Good point and Gordon Bell has almost always been right > >> for me so I > >>>> know I listen to him. The key is do these low power and > >> restricted > >>>> sensor components require security at the IP layer? > >>>> If IEEE xxx is secure can we conclude the IP layer is not relevant > >>>> for sensors, but I would suggest they are for any sensor gateway > >>>> nodes. Or can we develop in industry a micro-kernel IPsec > >>>> implementation in hardware that can be cost effectively added to a > >>>> sensor or set of sensor unions for a network? Clearly we > >> are seeing > >>>> this type of hardware development on microprocessors with the > >>>> exponential appearance of deep packet inspection providers > >> into the > >>>> market that are not router/switch vendors. But is IPsec the right > >>>> answer is the right question for lowpan for engineering > >> cost reasons > >>>> as opposed to is it possible? > >>>> > >>>> /jim > >>>> > >>>>> -----Original Message----- > >>>>> From: ipv6-bounces@ietf.org > >> [mailto:ipv6-bounces@ietf.org] On Behalf > >>>>> Of Jonathan Hui > >>>>> Sent: Tuesday, February 26, 2008 6:57 PM > >>>>> To: ipv6@ietf.org > >>>>> Subject: IPsec and 6LoWPAN (was: Re: Making IPsec *not* > >> mandatory in > >>>>> Node Requirement) > >>>>> > >>>>> > >>>>> I won't argue against the fact that security is an important > >>>> part of a > >>>>> complete solution. The question for me is whether IPsec > >> is the most > >>>>> appropriate solution for highly constrained embedded devices > >>>>> (constrained in energy, memory, compute, and link > >>>> capabilities). From > >>>>> the few implementation numbers thrown around this thread, > >> it sounds > >>>>> like IPsec is not an option for low-power wireless nodes > >>>> with 8K RAM, > >>>>> 48K ROM, 128B link MTU, and not to mention that any > >> implementation > >>>>> should leave enough space for an interesting application > >> and should > >>>>> operate for multiple years on modest batteries. > >>>>> > >>>>> One nice thing is that, given some application scenarios, > >> there are > >>>>> other ways to incorporate sufficient security without the > >> need for > >>>>> IPsec. For example, link-layer security may be sufficient > >>>> for private > >>>>> networks. Link-layer security may also be sufficient if border > >>>>> routers/gateways attach to other traditional IP networks via > >>>> encrypted > >>>>> tunnels. > >>>>> > >>>>> I'm not a security expert, nor do I know the complete workings of > >>>>> IPsec. > >>>>> But I'd be curious if people strongly believe or have ideas > >>>> on ways to > >>>>> squeeze IPsec into devices that I'm interested in. > >>>>> If not, is it at all possible to consider developing an > >> alternative > >>>>> end-to-end security mechanism that is lightweight. I'm > >> not arguing > >>>>> that this should be used between two traditional IP hosts, > >>>> but that it > >>>>> can be used between a traditional IP host communicating with a > >>>>> low-power, wireless device or two low-power wireless devices > >>>>> communicating directly. > >>>>> > >>>>> Gordon Bell observed that we've seen a new class of > >> computing form > >>>>> about every decade. IP has so far been able to follow > >> these trends, > >>>>> including hand held devices. Now we are at the beginning of yet > >>>>> another class with low-power wireless devices based on IEEE > >>>> 802.15.4, > >>>>> and the 6lowpan effort within the IETF has set out to > >> bring IPv6 to > >>>>> this new class. I'd be disappointed if we couldn't come to an > >>>>> agreement on how we can appropriately bring this new class > >>>> into the IP > >>>>> framework. > >>>>> > >>>>> -- > >>>>> Jonathan Hui > >>>>> > >> -------------------------------------------------------------------- > >>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>>> Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >>>>> > >> -------------------------------------------------------------------- > >> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list > >>>> ipv6@ietf.org > >>>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > >>>> > >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 20:54:44 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADA73A6E79; Wed, 27 Feb 2008 20:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGHr+WGE8BSN; Wed, 27 Feb 2008 20:54:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CF83A69BF; Wed, 27 Feb 2008 20:54:42 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D723A69BF for ; Wed, 27 Feb 2008 20:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4ojlomLopBb for ; Wed, 27 Feb 2008 20:54:40 -0800 (PST) Received: from tomato.taca.jp (tomato.taca.jp [202.214.123.64]) by core3.amsl.com (Postfix) with ESMTP id E13713A6903 for ; Wed, 27 Feb 2008 20:54:39 -0800 (PST) Received: from localhost (unknown [202.214.123.64]) by tomato.taca.jp (Postfix) with ESMTP id AA88033CBC; Thu, 28 Feb 2008 13:54:32 +0900 (JST) Date: Thu, 28 Feb 2008 13:54:20 +0900 (JST) Message-Id: <20080228.135420.05882516.nov@tahi.org> To: edward.jankiewicz@sri.com Subject: Re: the role of the node "requirements" document From: Nobuo OKABE In-Reply-To: <47C5D5BE.9050906@sri.com> References: <18373.51513.398270.398946@gargle.gargle.HOWL> <47C5D12B.8000708@gmail.com> <47C5D5BE.9050906@sri.com> X-Mailer: Mew version 5.2.51 on Emacs 22.1.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: ipv6@ietf.org, brian.e.carpenter@gmail.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, Please don't stick with IKEv2 because IETF also standardized other key exchange protocol, i.e KINK (kerberos based ipsec key exchange protocol). Or could you please list those exchange protocols in the RFC if describing name of specific exchange protocol in the RFC? To show a list of choises for implementors. Here are our experiences: - As I told in this ML, one of the problem of IKE/IKEv2 is PK (public key cryptography) when applying IPsec to resource limited devices. - PK impacts against those devices' sensitive factors: footprint/gatesize/throuput/power consumption. - Then, if using IKE* w/ PSK (Pre-Shared Key) instead of PK, the number of PSK is O(N^2) due to its e2e bases. It means scalability issue. - So, 3rd trusted party model (= Key Distribution Center model) is one of reasonable choices if you use PSK instead of PK. Because the number of PSK is O(N). # Kerberos is one of KDC models. # As FYI, if my understanding is correct, # key management of SP100 is also a kind of KDC model. # And, centralized management like KDC is fit for # the management style of "small-but-many-devices" system. - KINK (RFC4430) was designed for that. - I guess that many people worry that it is nightmare to speak multiple key exchange protocols. But, system is not so much complicated because resource limited devices usually relay on some servers. ex. Cheap devices speak cheap key exchange protocol (=KINK) only. Just several servers should be multilingual (IKE*/KINK). - We have opened reference code of multiple IPsec key exchange protocols (IKE/IKEv2/KINK) daemon called Racoon2. It can handles those protocols in the same node. So, it can be helpful hint for your multilingual servers. Those is why I think IPsec is still useful security tools. Again, I understand that above approach is not universal. # and there is no universal approach of security, after all :-) However, it can solve a part of issues discussed here which can not be solved with IKE*. (ex. some applications of sensor/actuator or resource limited devices). Thanks, From: Ed Jankiewicz Subject: Re: the role of the node "requirements" document Date: Wed, 27 Feb 2008 16:27:26 -0500 > I lean towards (3) because IPsec without IKE or something is > unmanageable. I could support MUST or SHOULD, or a conditional > statement, and would prefer linking to IKEv2 as part of the package. > Thomas hinted at the "chicken and egg" problem with IKEv2 - we'd like to > mandate it to encourage implementation, but hesitate to mandate > something that hardly exists in the near future... > > But I would go along with Brian's sentiment about IETF not dictating > use; that has been said a few times in various ways during this > discussion. Reality is even if 4294 is not updated, it makes no > difference to the actual implementation and use of IPsec; if revision > says nothing about IPsec, it makes no difference. If the revision says > SHOULD or MUST, probably makes no difference. Implementors will make > their own choices as will buyers of products. > > > Brian E Carpenter wrote: > > On 2008-02-28 09:34, James Carlson wrote: > > > >> Dow Street writes: > >> > >>> 1. the Internet *does not* need a mandatory security mechanism at > >>> the IP layer > >>> 2. the Internet *does* need a mandatory security mechanism at the IP > >>> layer, but IPsec is not the right one because it is too heavyweight > >>> 3. the Internet *does* need a mandatory security mechanism at the IP > >>> layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc) > >>> 4. I don't care about the architecture of the Internet, because I > >>> intend to develop devices that are never connected to the global > >>> Internet (and therefore play no role in defining the Internet > >>> architecture or adhering to Internet best practices). > >>> > >> I suppose I'm closest to (1) in your list, but I'd still phrase it > >> differently. > >> > >> 5. IP itself works properly without IPsec -- and demonstrably so. > >> It's not a _requirement_; it's not something that without which IP > >> simply fails to operate. It's desirable, and likely highly > >> desirable, but it's not a fundamental issue. > >> > > > > I'm close to this position too, but even closer to > > > > 6. As long as the IETF specifies a way of securing the IP layer, > > it's an implementation, procurement and operational issue > > whether it gets used. Words in an RFC have no control over that. > > > > And don't forget what Thomas said about keying. > > > > Brian > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > > -- > Ed Jankiewicz - SRI International > Fort Monmouth Branch Office - IPv6 Research > Supporting DISA Standards Engineering Branch > 732-389-1003 or ed.jankiewicz@sri.com > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Feb 27 20:55:37 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC1B28C586; Wed, 27 Feb 2008 20:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkJOXA8u9X71; Wed, 27 Feb 2008 20:55:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5DC3A6AE2; Wed, 27 Feb 2008 20:55:36 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E188F3A6A7E for ; Wed, 27 Feb 2008 20:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBajI0PAwcDe for ; Wed, 27 Feb 2008 20:55:29 -0800 (PST) Received: from 122x218x96x122.ap122.ftth.ucom.ne.jp (unknown [IPv6:2002:7ada:607a:0:8102:7ada:607a:0]) by core3.amsl.com (Postfix) with ESMTP id 1E36928C2D8 for ; Wed, 27 Feb 2008 20:55:27 -0800 (PST) Received: from coin (localhost [127.0.0.1]) by 122x218x96x122.ap122.ftth.ucom.ne.jp (Postfix) with ESMTP id B307A6C087 for ; Thu, 28 Feb 2008 13:55:18 +0900 (JST) Received: from coin.bbtec.net (localhost [127.0.0.1]) by coin (Postfix) with ESMTP id 2E50E6B4FF for ; Thu, 28 Feb 2008 13:33:58 +0900 (JST) Date: Thu, 28 Feb 2008 13:33:58 +0900 Message-ID: From: FUJIKAWA Kenji To: ipv6@ietf.org Subject: Re: Use longest-matching prefix to the next hop In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.7 Emacs/22.1 (i386--netbsdelf) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hemant Singh; Thank you for your comments. At Wed, 27 Feb 2008 16:01:27 -0500, Hemant Singh (shemant) wrote: > > The draft should not be considered for 6man as a WG item just yet > because it needs some more work before the draft is even acceptable to > review. Here is some things to look at after I read portions of the > draft at the URL below. > > 1. Section 1 of the draft says 2001:db8:3001:1:EN is selected as the > source address of a packet directed from CN to EN. Huh? CN has only an > address of 2001:db8:2001::CN, so how can a src of 2001:db8:3001:1:EN be > picked? > Because 2001:db8:3001:1:EN longer-matches to 2001:db8:2001::CN than 2001:db8:1001:1:EN. # Note that 1 = 01, 2 = 10, and 3 = 11 in binary form. > 2. Section 1 says: > > [Here, in the above IPv6 address notation, CN, R1, R2, and EN indicates > 64bit Interface ID's.] > > There is no router R2 in the picture of Fig. 1. > This is typo. > How can one review this document with such basic mistakes/typos in the > picture? > > 3. In section 3 you say: > > [Before Rule 8 (Use longest matching prefix) in section 5. (Source > Address Selection) in RFC3484, the rule using longest-matching prefix > to the next hop is to be added.] > > Did I get is right that you are changing src-addr based on next hop? > Basic IP data forwarding and routing ships packets between consecutive > hops using L2 addresses. For packet flow from src to dest with multiple > hops in between, the L3 src and dest addresses do not change! Src and > dest L3 addresses can only be changed by some proxy node in the path. I > hope you are not suggesting changing L3 src-addr from hop to hop! > No, I am not suggesting changing L3 src-addr from hop to hop. > I suggest you forget about the solution. First define your src-addr > selection problem and let the mailer first agree you have a problem. > Then we'll see what is the solution. You have a lot of sections in the > draft with problems/issues, viz., > > 1. A Problem of at Source Address Selection Rule 8. in RFC3484 > 2.1 Management Issue > 2.2 Implementation Issue > > It confuses the reader as to what is the one single problem you are > trying to solve. Or if you are solving multiple problems, list them at > the beginning of the draft. Sorry, if I have missed such problem > definitions in the mailer earlier than one year from now. > I see. Thank you for your advice. 2.1 and 2.2 should be "Management Approach" and "Implementation Approach" or something. > I suggest the same to the authors of > draft-ietf-6man-addr-select-sol-00.txt. Could you please first describe > what is the problem with SAS as specified in RFC 3484. > > Hemant > ------------------------------------------------------------------ FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan Mail: fujikawa@root-hq.com, hudikaha@gmail.com WWW: http://www23.atwiki.jp/hudikaha/ Skype: fujikawakenji > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > FUJIKAWA Kenji > Sent: Monday, February 25, 2008 9:31 PM > To: ipv6@ietf.org > Subject: Use longest-matching prefix to the next hop > > Hi all, > > I am submitting an ID, > > http://www.ietf.org/proceedings/staging/draft-fujikawa-ipv6-src-addr-sel > ection-02.txt > and suggesting in the draft that, > > Before Rule 8 (Use longest matching prefix) in section 5. (Source > Address Selection) in RFC3484, the rule using longest-matching prefix > to the next hop is to be added. > > The following is an example, > where the Rule 8 selects the roundabout path via ISP3, while the method > of using longest-matching prefix to the next hop selects the shortest > and best path, when EN sends a packet to CN. > > # In the previous IETF meeting I only showed a single router case. > # but this method is adaptable and useful to the multiple router case. > > I would like to ask if 6man people is interested in this topic, and this > can become working group item. > > +---+ > |CN | > +-+-+ > | 2001:db8:2001::CN > | > +---+---+2001:db8:2000:/36 > | | > +---------+ ISP2 | > | | | > | +-------+ > | > +---+---+2001:db8:1000:/36 +-------+2001:db8:3000::/36 > | | | | > | ISP1 +-------------------+ ISP3 | > | | | | > +---+---+ +---+---+ > | | > | | > +----------+ +--------+ > 2001:db8:1000:R1| |2001:db8:3000:R3 > +-+-+ +-+-+ > 2001:db8:1001::/48|R1 | |R3 |2001:db8:3001::/48 > +-+-+ +-+-+ > 2001:db8:1001:1:R1| |2001:db8:3001:1:R3 > | | > --+---+---+-- > 2001:db8:1001:1:EN | 2001:db8:3001:1:EN > +-+-+ > |EN | > +---+ > > Routing Tables: > R1: > Destination Next Hop > 2001:db8:1000::/36 address_of_ISP1's_router > 2001:db8:2000::/36 address_of_ISP1's_router > R3: > 2001:db8:3000::/36 address_of_ISP3's_router > EN: > Destination Next Hop > 2001:db8:1000::/36 2001:db8:1001:1:R1 > 2001:db8:2000::/36 2001:db8:1001:1:R1 > 2001:db8:3000::/36 2001:db8:3001:1:R3 > > Any questions and comments are welcome. > > Regards, > ------------------------------------------------------------------ > FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias > Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan > Mail: fujikawa@root-hq.com, hudikaha@gmail.com > WWW: http://www23.atwiki.jp/hudikaha/ > Skype: fujikawakenji > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 01:04:47 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01DEF28C584; Thu, 28 Feb 2008 01:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEJIx-7VRu8D; Thu, 28 Feb 2008 01:04:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525E128C47F; Thu, 28 Feb 2008 01:04:41 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA8A28C545 for ; Thu, 28 Feb 2008 01:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15fs1koIXMlW for ; Thu, 28 Feb 2008 01:04:34 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id 8116628C754 for ; Thu, 28 Feb 2008 01:04:04 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id i7so3888643tid.25 for ; Thu, 28 Feb 2008 01:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=mRLQHrakM+RIu0Ffc5pdkYgZ++D2zA0tVtXCVIxfs/0=; b=YHhhtb5Vph85Hg6s/7fFUVX+jJCRc52a2+n8JBfDnxQ7hC6VGyHxvloCFeNJFEAsYZoPYwAtf2kmkclvyymYdT5E/HRk1IYavS7gBf6J/ZQtaYzorXoXj4Q6hQQjwiczTPWqttOE++7hMvP6upACQT2B0Um+fODk22DhUPh0iD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=iYzgznscYOx+VZldwjC4DeGaW6hPdnxvnrGMzv0GGcTYKfgc99e0RTvpLQHaBTJiH7JdrmkfBx1WFOVEVnXY28q0uWlRgNwdqnVF2V1t1TiLY9VIvJDCs3VYnd0O2yss5gwSm6oq+WFAnp1YlqvX2Ou4Sy9sApFQQvnL2dm+c5U= Received: by 10.151.144.4 with SMTP id w4mr2615742ybn.199.1204189433521; Thu, 28 Feb 2008 01:03:53 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f6sm4617639nfh.21.2008.02.28.01.03.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Feb 2008 01:03:51 -0800 (PST) From: Julien Laganier To: ipv6@ietf.org Subject: Re: Making IPsec *not* mandatory in Node Requirement Date: Thu, 28 Feb 2008 10:04:32 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> <1cc401c8792a$5fa6bf90$1ef43eb0$@net> <200802271714.m1RHED68018076@cichlid.raleigh.ibm.com> In-Reply-To: <200802271714.m1RHED68018076@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802281004.34603.julien.IETF@laposte.net> Cc: Thomas Narten X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thomas, all, On Wednesday 27 February 2008, Thomas Narten wrote: > Tony, > > > For those that have forgotten, the entire reason for mandating > > IPsec is to get away from the 47 flavors of security that are never > > really configured correctly or completely understood. Yes for any > > given situation someone can design an optimized protocol, but as > > soon as the situation changes the optimization no longer applies, > > and may expose unexpected holes. This was in fact happening at the > > time the mandate was put in. > > Right. =A0Having one way to do things is far better than having 47. > > But if we look at the reality of things, IPsec (and we have to > include IKE in evaluating this), IPsec just isn't the ideal > one-size-fits-all technology we'd like it to be. > > For example, one big problem is the lack of a proper API for > applications to communicate with IPsec to select services and verify > that a certain level of security is present. = Would that be the major showstopper in using IPsec for other things than = VPNs, the IETF has chartered the BTNS WG to work on APIs to communicate = with IPsec. The WG currently has two documents that need reviews: http://tools.ietf.org/wg/btns/draft-ietf-btns-abstract-api/ http://tools.ietf.org/wg/btns/draft-ietf-btns-c-api/ > Second, good security says "don't trust anyone but yourself". So, do > you trust the OS you are running on? = If someone cares about security but doesn't trust the OS he's running = on, I think the best thing he can do is to not use the OS in question. > Do you trust the IPsec embedded in the system that was implemented by > a third party? = Keeping IPsec mandatory would be one facilitator of the move from IPsec = implementation from third party to native IPsec implementation shipped = with the OS that has to be trusted. > Smart applications implement their own security (e.g., TLS) to ease > deployment. = How many applications really implement their *own* security? Many = applications I'm using daily relies on libraries shipped with the OS = that has to be trusted, e.g. gnutls and openssl. > We'll never get them to rely on IPsec, at least not until its much > more widely available/useable. = Agree. But I think the availability part can be helped by keeping IPsec = mandatory (so that it gets in more and more OS's), while the usability = part can be helped by getting the BTNS WG to deliver its APIs (so that = applications can finally start using IPsec). --julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 03:42:14 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E23A28C806; Thu, 28 Feb 2008 03:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bcPRcS72gcl; Thu, 28 Feb 2008 03:42:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84B028C49D; Thu, 28 Feb 2008 03:41:08 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D543A6847 for ; Thu, 28 Feb 2008 03:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfwaxvzSt111 for ; Thu, 28 Feb 2008 03:41:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2C4BE28C69C for ; Thu, 28 Feb 2008 03:37:56 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Feb 2008 12:37:49 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1SBbndH018255; Thu, 28 Feb 2008 12:37:49 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1SBbiME001334; Thu, 28 Feb 2008 11:37:49 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 12:37:44 +0100 Received: from pgrosset-wxp02.cisco.com ([10.61.66.20]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 12:37:44 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Feb 2008 12:37:42 +0100 To: "Kevin Kargel" From: Patrick Grossetete Subject: RE: the role of the node "requirements" document In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail> References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 28 Feb 2008 11:37:44.0252 (UTC) FILETIME=[557627C0:01C879FE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6415; t=1204198669; x=1205062669; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pgrosset@cisco.com; z=From:=20Patrick=20Grossetete=20 |Subject:=20RE=3A=20the=20role=20of=20the=20node=20=22requi rements=22=20document |Sender:=20; bh=MrpX8Y1+19wCY5Z1cRN2Zsd61ofnffM4gdf7ncvSazk=; b=JAAGOmQHNL7AsHfOo/01dY2dEOx3uAGi2TPdDURpY+cPWrB5g2zdnvQak8 JFy+bnOPf0ffrU35N+ALIjwEUX3ehmC4F1Hi6QBMoHlolQlq4y4Ls3lXCXET /4KE90ZJqw; Authentication-Results: ams-dkim-2; header.From=pgrosset@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1794936475==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1794936475== Content-Type: multipart/alternative; boundary="=====================_55177781==.ALT" --=====================_55177781==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Having been through the whole thread, I have to react to this last proposal in regards of operational deployments. I already raised several times the fact that IPsec on routers in NOT a generic requirement. If the "requirements" are generic enough to consider the following realities then I have no more issue - "Router" definition - it ranges from Core to Edge routers to L3 switches to low cost CPE devices to "a Node that interconnects sub-networks by packet forwarding." - all those HW having different capabilities, cost and performances. so, let's review the use of IPsec on "Routers". - IPsec can be used by control plane features, such as OSPFv3 Authentication (RFC 4552) or MIPv6 in case the router act as MIPv6 Home Agent. It is purely a software feature with no real impact on hardware. But why should I support IPsec if none of those features are implemented, let's say on a low cost CPE router? - IPsec as management feature. As indicated by Fred, it looks to me that the preferred solution is currently SSH/SSL. Is everybody agreeing about a potential market shift to IPsec? - IPsec used by Data plane features, such as router-to-router IPsec tunnel where encryption could be hardware assisted. However, if the IPsec tunnel is not terminated on a router, packets will get forwarded as raw traffic. But why should I support this on a core router or Layer 3 switches which will never be configured as tunnel end-point? - IPsec as end-to-end feature. No question it is used in well controlled domains but if it is a generic requirement to not interact with traffic protected by IPsec, could we indicate that all features such as packet filtering, QoS marking or re-marking, instrumentation are lost? which may not be an issue for some people but will certainly be one for others. And yes, if AH is a "MAY" we need to find a better way to do authentication using ESP... a real IETF task. Best Regards Patrick At 09:18 PM 2/27/2008, Kevin Kargel wrote: > > > > quick poll - for those opposed to a MUST requirement for > > IPsec, what is your driving objection? > > >My feeling is that we should not introduce mandatory cost factors for >end devices. There are many sensor-ish devices that do not require >strict security. > >If it is possible, could we say that IPSEC is MUST for routing hardware >and SHOULD for end user devices? That way the end-to-end availablity is >still serviced, but low risk devices can stay simple and cheap. > >Kevin > >:$s/worry/happy/g > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- --=====================_55177781==.ALT Content-Type: text/html; charset="us-ascii"         Hi,

        Having been through the whole thread, I have to react to this last proposal in regards of
operational deployments. I already raised several times the fact that IPsec on routers in NOT a generic requirement.

If the "requirements" are generic enough to consider the following realities then  I have no more issue

- "Router" definition - it ranges from Core to Edge routers to L3 switches to low cost CPE devices to "a Node that
interconnects sub-networks by packet forwarding." - all those HW having different capabilities, cost and performances.
so, let's review the use of IPsec on "Routers".

- IPsec can be used by control plane features, such as OSPFv3 Authentication (RFC 4552) or MIPv6 in case the router
act as MIPv6 Home Agent. It is purely a software feature with no real impact on hardware. But why should I support
IPsec if none of those features are implemented, let's say on a low cost CPE router?

- IPsec as management feature. As indicated by Fred, it looks to me that the preferred solution is currently SSH/SSL.
Is everybody agreeing about a potential market shift to IPsec?

- IPsec used by Data plane features, such as router-to-router IPsec tunnel where encryption could be hardware assisted.
However, if the IPsec tunnel is not terminated on a router, packets will get forwarded as raw traffic. But why should I
support this on a core router or Layer 3 switches which will never be configured as tunnel end-point?

- IPsec as end-to-end feature. No question it is used in well controlled domains but if it is a generic requirement to
not interact with traffic protected by IPsec, could we indicate that all features such as packet filtering, QoS marking
or re-marking, instrumentation are lost? which may not be an issue for some people but will certainly be one for others.
And yes, if AH is a "MAY" we need to find a better way to do authentication using ESP... a real IETF task.

Best Regards
Patrick

At 09:18 PM 2/27/2008, Kevin Kargel wrote:
 

> quick poll - for those opposed to a MUST requirement for
> IPsec, what is your driving objection?
>
My feeling is that we should not introduce mandatory cost factors for
end devices.  There are many sensor-ish devices that do not require
strict security.

If it is possible, could we say that IPSEC is MUST for routing hardware
and SHOULD for end user devices?  That way the end-to-end availablity is
still serviced, but low risk devices can stay simple and cheap.

Kevin

:$s/worry/happy/g

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--=====================_55177781==.ALT-- --===============1794936475== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1794936475==-- From ipv6-bounces@ietf.org Thu Feb 28 05:45:06 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649563A6B4C; Thu, 28 Feb 2008 05:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W11UfzE7zghW; Thu, 28 Feb 2008 05:44:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20C13A6E75; Thu, 28 Feb 2008 05:44:57 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD703A6961 for ; Thu, 28 Feb 2008 05:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddatprwLQZt9 for ; Thu, 28 Feb 2008 05:44:51 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id A2E363A6A40 for ; Thu, 28 Feb 2008 05:44:47 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1SDieVP013491 for ; Thu, 28 Feb 2008 13:44:40 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m1SDie7w059326 for ; Thu, 28 Feb 2008 08:44:40 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1SDiVbq026053; Thu, 28 Feb 2008 08:44:31 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1SDiUIL026050; Thu, 28 Feb 2008 08:44:30 -0500 (EST) MIME-Version: 1.0 Message-ID: <18374.47806.354120.554370@gargle.gargle.HOWL> Date: Thu, 28 Feb 2008 08:44:30 -0500 From: James Carlson To: Julien Laganier Subject: Re: Making IPsec *not* mandatory in Node Requirement In-Reply-To: <200802281004.34603.julien.IETF@laposte.net> References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> <1cc401c8792a$5fa6bf90$1ef43eb0$@net> <200802271714.m1RHED68018076@cichlid.raleigh.ibm.com> <200802281004.34603.julien.IETF@laposte.net> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: Thomas Narten , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Julien Laganier writes: > On Wednesday 27 February 2008, Thomas Narten wrote: > > We'll never get them to rely on IPsec, at least not until its much > > more widely available/useable. > > Agree. But I think the availability part can be helped by keeping IPsec > mandatory (so that it gets in more and more OS's), while the usability > part can be helped by getting the BTNS WG to deliver its APIs (so that > applications can finally start using IPsec). You get exactly that same level of goodness with a BCP 14 "SHOULD." The only difference is that "MUST" causes implementors with differing fundamental marketing considerations to toss the whole requirements RFC out on its ear -- because it mandates something that (in their view) ought not be done or perhaps simply _cannot_ be done with available resources. MUST doesn't actually cause any more implementations to appear in comparison to SHOULD. I think your argument would work, though, if we were discussing SHOULD versus MAY. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 06:11:42 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22FD63A6EA1; Thu, 28 Feb 2008 06:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a9hRYkRkjBh; Thu, 28 Feb 2008 06:11:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A6E3A69F0; Thu, 28 Feb 2008 06:11:38 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10E23A6A80 for ; Thu, 28 Feb 2008 06:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3zYtr0+mVg1 for ; Thu, 28 Feb 2008 06:11:31 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by core3.amsl.com (Postfix) with ESMTP id 2325D3A69F0 for ; Thu, 28 Feb 2008 06:11:30 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so584406uge.46 for ; Thu, 28 Feb 2008 06:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=ZDEO+rI88b7gZAvBKJfB5hbEKNy+ZmrSPaG7dh7pMxE=; b=AJzBiM8ULZZcnZFBl8swKM/9V3h9C6vfDkCwujxcgzj/KWlHRAFzJ4xuC/sZXBIGWAxlyIko/QGy93oj4bCcutBJljFoIaK/qzaj/Oc3DpfNk4OGVH1QAG+L3Z+A0mvQ+8kGVi8STPTZRYfW+xvBgNu4ivhrbvU2QU1UFV0Sj4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=NX8+vVCT1UFO3R6/LTAV7wDKQ0GC6uFz/Vb0UPsXcCHbRs6FVIkeowEyfwEOZVhNR+2jWebi+66n56oWIVYygZBR/nxnw/kY0h0LeP7/O57jcDjDZSd0dKd5Wi4eMDCOessq772skKXI+s006M2UebfMCw1/fhEOh54Now26hS0= Received: by 10.67.40.15 with SMTP id s15mr3409273ugj.46.1204207882322; Thu, 28 Feb 2008 06:11:22 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k28sm1260352ugd.77.2008.02.28.06.11.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Feb 2008 06:11:21 -0800 (PST) From: Julien Laganier To: James Carlson Subject: Re: Making IPsec *not* mandatory in Node Requirement Date: Thu, 28 Feb 2008 15:12:10 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> <200802281004.34603.julien.IETF@laposte.net> <18374.47806.354120.554370@gargle.gargle.HOWL> In-Reply-To: <18374.47806.354120.554370@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802281512.11737.julien.IETF@laposte.net> Cc: Thomas Narten , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org James, On Thursday 28 February 2008, James Carlson wrote: > Julien Laganier writes: > > On Wednesday 27 February 2008, Thomas Narten wrote: > > > We'll never get them to rely on IPsec, at least not until its > > > much more widely available/useable. > > > > Agree. But I think the availability part can be helped by keeping > > IPsec mandatory (so that it gets in more and more OS's), while the > > usability part can be helped by getting the BTNS WG to deliver its > > APIs (so that applications can finally start using IPsec). > > You get exactly that same level of goodness with a BCP 14 "SHOULD." > The only difference is that "MUST" causes implementors with differing > fundamental marketing considerations to toss the whole requirements > RFC out on its ear -- because it mandates something that (in their > view) ought not be done or perhaps simply _cannot_ be done with > available resources. > > MUST doesn't actually cause any more implementations to appear in > comparison to SHOULD. I think your argument would work, though, if > we were discussing SHOULD versus MAY. You are right. SHOULD should be fine. --julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 06:56:35 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B31B28C661; Thu, 28 Feb 2008 06:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO+EFMgdBy6P; Thu, 28 Feb 2008 06:56:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635213A6A0E; Thu, 28 Feb 2008 06:56:34 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2183328C64E for ; Thu, 28 Feb 2008 06:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm5DhCIU0cTs for ; Thu, 28 Feb 2008 06:56:32 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 3A32D28C62B for ; Thu, 28 Feb 2008 06:56:32 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m1SEuCDV028302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Feb 2008 08:56:16 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m1SEuBfA014399; Thu, 28 Feb 2008 06:56:11 -0800 (PST) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m1SEuBxE014381; Thu, 28 Feb 2008 06:56:11 -0800 (PST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 09:56:10 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Thu, 28 Feb 2008 09:56:09 -0500 Message-ID: In-Reply-To: <47C6046D.20207@blunkmicro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5o8qI19pDDPUYTGmK/VXAuRFWlQAdL0Qg References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com><70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail> <47C6046D.20207@blunkmicro.com> From: "Manfredi, Albert E" To: "Sean Lawless" X-OriginalArrivalTime: 28 Feb 2008 14:56:10.0921 (UTC) FILETIME=[0E63A990:01C87A1A] Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Sean Lawless [mailto:sean@blunkmicro.com] > Kevin and many others against mandating (MUST) for IPSec have a valid > point. Many sensors and other potential IPv6 nodes do not have the > hardware resources to support IPSec, or those resources are > better spent > at other tasks. This may fall under #4 in Dow Street's driving > objection to RFC 4294 wording of MUST, but not necessarily. With the > simplicity of securing IP at the edge router with an IPSec > tunnel, the > point of mandating IPSec for nodes appears unwarranted. I agree with > Kevin that IPSec be SHOULD for hosts (but remain a MUST for > routers). I strongly disagree. If IPsec is not mandatory for hosts, then it MUST (if anything) be mandatory for security gateways, NOT routers, with the exception perhaps of securing the routing protocols. Reason being, you cannot achieve security unless cybertext only goes through non-secure networks. What you call "edge routers" I call security gateways. These are likely routers, but they must not be confused with just any ole ISP router, or router in any other core network that is not "secure" as far as the client is concerned. I think it's important not to give anyone the illusion of security. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 09:04:39 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9E328C938; Thu, 28 Feb 2008 09:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VliAhVMvBJAe; Thu, 28 Feb 2008 09:04:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A92D28C0D8; Thu, 28 Feb 2008 09:04:34 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43DF03A6A0E for ; Thu, 28 Feb 2008 09:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnUk001RC-Ai for ; Thu, 28 Feb 2008 09:04:27 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id ACDC73A67B4 for ; Thu, 28 Feb 2008 09:04:27 -0800 (PST) Received: from g1t0029.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 63CBD3803F; Thu, 28 Feb 2008 17:04:20 +0000 (UTC) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTP id 57BD638216; Thu, 28 Feb 2008 17:04:20 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.1.251.1; Thu, 28 Feb 2008 17:03:39 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Thu, 28 Feb 2008 17:03:39 +0000 From: "Bound, Jim" To: Thomas Narten , "john.loughney@nokia.com" Date: Thu, 28 Feb 2008 17:03:39 +0000 Subject: RE: the role of the node "requirements" document Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5azghCOU0orbJSOirrBo7h27vFAAwBBMg Message-ID: <831FE02B5345194BA8147EDEF5F13388297D18A0@G3W0070.americas.hpqcorp.net> References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <19EBBEC503C3B5469070E0A6674A533A010EAB19@daebe104.NOE.Nokia.com> <200802271759.m1RHxrFL011955@cichlid.raleigh.ibm.com> In-Reply-To: <200802271759.m1RHxrFL011955@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thomas, I am coming from 180 degrees where you are but I respect your input. IPsec is required by any market (this includes VPNs and LAN only IPsec use) the IETF has been successful so I respectfully disagree with your market data. In addition the infrastructure to support IPsec is not our concern in the IETF IPsec secures layer 3 on networks and that is highly valuable to the market. Each market segment will deal with PKI and user space API and Management issues on their own terms/conditions and methods. I still think we have debate to move to a SHOULD but even a SHOULD says do this or have a good reason to not do it. Moving it to MAY is unacceptable to me in the IETF as a note. /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Thomas Narten > Sent: Wednesday, February 27, 2008 1:00 PM > To: john.loughney@nokia.com > Cc: ipv6@ietf.org > Subject: Re: the role of the node "requirements" document > > John, > > > Well, I would say that we (HW, SW, Platform providers) > cannot expect > > to understand all of the ways that their products will be > deployed, so > > it is extremely hard to state "security is not needed." > > That is not what I (and I suspect others) are saying. > > What I am saying is that security (in practice) turns out to > be much harder than "just use IPsec". Really. The corollary > to this is that mandating IPsec (at the node level) doesn't > actually get you usuable security in IPv6. > > TO get real security, you have to consider the actual > application that needs securing as well as the operational > environment where the deployment will take place. There are > plenty of applications that already have security that do not > use IPsec. Should we/can we force them to use IPsec? No. > > And if an IPv6 node has limited functionality/purpose, and > none of that functionality appears likely to use IPsec > (because it has other means for providing security), what is > the point of requiring IPsec? > > I think the big message that people are missing is that IPsec > has not become the unbiquitous base-line security that we had > once hoped for. > > And even today, IPv6 only mandates IPsec (with manual keys). > No key managment. And if there is one thing we have learned > from practical deployments, it's all about key > mangement/distribution. That is the hard stuff that makes or > breaks usability. > > Mandating IPsec with just static keying just isn't useful in practice. > > Thus, continuing to mandate IPsec (while continuing to punt on key > management) just looks silly. > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 09:11:40 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E276328C93C; Thu, 28 Feb 2008 09:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbFmsxIxjp2e; Thu, 28 Feb 2008 09:11:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6931D28C8BB; Thu, 28 Feb 2008 09:11:39 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB94428C6FE for ; Thu, 28 Feb 2008 09:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhsyMJRTom1j for ; Thu, 28 Feb 2008 09:11:32 -0800 (PST) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by core3.amsl.com (Postfix) with ESMTP id E456128C661 for ; Thu, 28 Feb 2008 09:11:31 -0800 (PST) Received: from g1t0026.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id D6787C0C9; Thu, 28 Feb 2008 17:11:24 +0000 (UTC) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTP id B40C7C342; Thu, 28 Feb 2008 17:11:19 +0000 (UTC) Received: from G3W0055.americas.hpqcorp.net (16.232.1.152) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.1.251.1; Thu, 28 Feb 2008 17:10:48 +0000 Received: from G3W0070.americas.hpqcorp.net ([16.232.1.146]) by G3W0055.americas.hpqcorp.net ([16.232.1.152]) with mapi; Thu, 28 Feb 2008 17:10:48 +0000 From: "Bound, Jim" To: Ed Jankiewicz , "ipv6@ietf.org" Date: Thu, 28 Feb 2008 17:10:48 +0000 Subject: RE: the role of the node "requirements" document Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5h+Sco3YQYuyESV+0SFui0DmlcgApGe9Q Message-ID: <831FE02B5345194BA8147EDEF5F13388297D18D5@G3W0070.americas.hpqcorp.net> References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> <18373.51513.398270.398946@gargle.gargle.HOWL> <47C5D12B.8000708@gmail.com> <47C5D5BE.9050906@sri.com> In-Reply-To: <47C5D5BE.9050906@sri.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I believe all IPv6 nodes SHOULD support IPsec. I don't care about the PKI or other managed parts but if they are referenced to IPsec they should have no known protocol interoperability problems, the market will decide and select on that one is my view. This should clearly not mandate USE as others have stated. I also would support a MUST as I agree with Dow and others who can see the value of a MUST but I will not fight to hard if majority wants to move to SHOULD. If it is 50/50 for consensus I will continue to provide data why MUST has to remain. And I want to reiterate and note the important mail from Tony Hain for this polling to others as input to our collective thoughts. Thanks Dow /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Ed Jankiewicz > Sent: Wednesday, February 27, 2008 4:27 PM > To: ipv6@ietf.org > Cc: Brian E Carpenter > Subject: Re: the role of the node "requirements" document > > I lean towards (3) because IPsec without IKE or something is > unmanageable. I could support MUST or SHOULD, or a > conditional statement, and would prefer linking to IKEv2 as > part of the package. > Thomas hinted at the "chicken and egg" problem with IKEv2 - > we'd like to mandate it to encourage implementation, but > hesitate to mandate something that hardly exists in the near future... > > But I would go along with Brian's sentiment about IETF not > dictating use; that has been said a few times in various ways > during this discussion. Reality is even if 4294 is not > updated, it makes no difference to the actual implementation > and use of IPsec; if revision says nothing about IPsec, it > makes no difference. If the revision says SHOULD or MUST, > probably makes no difference. Implementors will make their > own choices as will buyers of products. > > > Brian E Carpenter wrote: > > On 2008-02-28 09:34, James Carlson wrote: > > > >> Dow Street writes: > >> > >>> 1. the Internet *does not* need a mandatory security > mechanism at > >>> the IP layer 2. the Internet *does* need a mandatory security > >>> mechanism at the IP layer, but IPsec is not the right one > because it > >>> is too heavyweight 3. the Internet *does* need a > mandatory security > >>> mechanism at the IP layer, but IPsec *alone* is insufficient > >>> (without IKE, key mgmt, etc) 4. I don't care about the > architecture > >>> of the Internet, because I intend to develop devices that > are never > >>> connected to the global Internet (and therefore play no role in > >>> defining the Internet architecture or adhering to Internet best > >>> practices). > >>> > >> I suppose I'm closest to (1) in your list, but I'd still phrase it > >> differently. > >> > >> 5. IP itself works properly without IPsec -- and demonstrably so. > >> It's not a _requirement_; it's not something that > without which IP > >> simply fails to operate. It's desirable, and likely highly > >> desirable, but it's not a fundamental issue. > >> > > > > I'm close to this position too, but even closer to > > > > 6. As long as the IETF specifies a way of securing the IP > layer, it's > > an implementation, procurement and operational issue > whether it gets > > used. Words in an RFC have no control over that. > > > > And don't forget what Thomas said about keying. > > > > Brian > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > > -- > Ed Jankiewicz - SRI International > Fort Monmouth Branch Office - IPv6 Research Supporting DISA > Standards Engineering Branch > 732-389-1003 or ed.jankiewicz@sri.com > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 09:58:52 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE093A6E60; Thu, 28 Feb 2008 09:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w215-BVgk0O1; Thu, 28 Feb 2008 09:58:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA3228C89E; Thu, 28 Feb 2008 09:58:46 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD09928C853 for ; Thu, 28 Feb 2008 09:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdjRubOZbaWK for ; Thu, 28 Feb 2008 09:58:38 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AEAC428C937 for ; Thu, 28 Feb 2008 09:58:14 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2008 09:58:07 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1SHw72I000534; Thu, 28 Feb 2008 09:58:07 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1SHvuBP018571; Thu, 28 Feb 2008 17:58:07 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 12:57:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Use longest-matching prefix to the next hop Date: Thu, 28 Feb 2008 12:57:45 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use longest-matching prefix to the next hop Thread-Index: Ach5xi6z9hynzvtRSGmnM3cAGBeztgAaZWwQ References: From: "Hemant Singh (shemant)" To: "FUJIKAWA Kenji" , X-OriginalArrivalTime: 28 Feb 2008 17:57:46.0261 (UTC) FILETIME=[6C849C50:01C87A33] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7911; t=1204221487; x=1205085487; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Use=20longest-matching=20prefix=20to=20 the=20next=20hop |Sender:=20; bh=cxBYXeIZK8dAJLHLTpd0U+//4pu7sLDyJCJ8AnMTkUY=; b=eLBkxsQEIGIeWFF0P65L5AX9NAjqcrhZETO2r96vfOPhi38IF+KwL+qubM TrwbvMeJrN27aPD4Njz2McLfNcLOElTPoxXH0l2tXmK8bdwQmQKqu4YDeECL uelOVburfT; Authentication-Results: sj-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Sorry, you missed my point about your -02 draft with another typo where the text says [is selected as the source address of a packet directed from CN to EN] - this is text towards the end of section 1. The text should say [packet directed from EN to CN] or I don't understand what are you trying in this SAS example. Further RFC 3484 considers a multi-homed example in section 10.5 and clearly says [This predicament demonstrates the limitations of the longest-matching-prefix heuristic in multi-homed situations.] There are more than one set of means to figure out an optimized routing for multi-homed sites. I think the WG should decide if we want to propose a formal solution to the multi-homed scenario. Thanks. Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of FUJIKAWA Kenji Sent: Wednesday, February 27, 2008 11:34 PM To: ipv6@ietf.org Subject: Re: Use longest-matching prefix to the next hop Hemant Singh; Thank you for your comments. At Wed, 27 Feb 2008 16:01:27 -0500, Hemant Singh (shemant) wrote: > > The draft should not be considered for 6man as a WG item just yet > because it needs some more work before the draft is even acceptable to > review. Here is some things to look at after I read portions of the > draft at the URL below. > > 1. Section 1 of the draft says 2001:db8:3001:1:EN is selected as the > source address of a packet directed from CN to EN. Huh? CN has only an > address of 2001:db8:2001::CN, so how can a src of 2001:db8:3001:1:EN > be picked? > Because 2001:db8:3001:1:EN longer-matches to 2001:db8:2001::CN than 2001:db8:1001:1:EN. # Note that 1 = 01, 2 = 10, and 3 = 11 in binary form. > 2. Section 1 says: > > [Here, in the above IPv6 address notation, CN, R1, R2, and EN > indicates 64bit Interface ID's.] > > There is no router R2 in the picture of Fig. 1. > This is typo. > How can one review this document with such basic mistakes/typos in the > picture? > > 3. In section 3 you say: > > [Before Rule 8 (Use longest matching prefix) in section 5. (Source > Address Selection) in RFC3484, the rule using longest-matching prefix > to the next hop is to be added.] > > Did I get is right that you are changing src-addr based on next hop? > Basic IP data forwarding and routing ships packets between consecutive > hops using L2 addresses. For packet flow from src to dest with > multiple hops in between, the L3 src and dest addresses do not change! > Src and dest L3 addresses can only be changed by some proxy node in > the path. I hope you are not suggesting changing L3 src-addr from hop to hop! > No, I am not suggesting changing L3 src-addr from hop to hop. > I suggest you forget about the solution. First define your src-addr > selection problem and let the mailer first agree you have a problem. > Then we'll see what is the solution. You have a lot of sections in the > draft with problems/issues, viz., > > 1. A Problem of at Source Address Selection Rule 8. in RFC3484 > 2.1 Management Issue > 2.2 Implementation Issue > > It confuses the reader as to what is the one single problem you are > trying to solve. Or if you are solving multiple problems, list them at > the beginning of the draft. Sorry, if I have missed such problem > definitions in the mailer earlier than one year from now. > I see. Thank you for your advice. 2.1 and 2.2 should be "Management Approach" and "Implementation Approach" or something. > I suggest the same to the authors of > draft-ietf-6man-addr-select-sol-00.txt. Could you please first > describe what is the problem with SAS as specified in RFC 3484. > > Hemant > ------------------------------------------------------------------ FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan Mail: fujikawa@root-hq.com, hudikaha@gmail.com WWW: http://www23.atwiki.jp/hudikaha/ Skype: fujikawakenji > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of FUJIKAWA Kenji > Sent: Monday, February 25, 2008 9:31 PM > To: ipv6@ietf.org > Subject: Use longest-matching prefix to the next hop > > Hi all, > > I am submitting an ID, > > http://www.ietf.org/proceedings/staging/draft-fujikawa-ipv6-src-addr-s > el > ection-02.txt > and suggesting in the draft that, > > Before Rule 8 (Use longest matching prefix) in section 5. (Source > Address Selection) in RFC3484, the rule using longest-matching prefix > to the next hop is to be added. > > The following is an example, > where the Rule 8 selects the roundabout path via ISP3, while the > method of using longest-matching prefix to the next hop selects the > shortest and best path, when EN sends a packet to CN. > > # In the previous IETF meeting I only showed a single router case. > # but this method is adaptable and useful to the multiple router case. > > I would like to ask if 6man people is interested in this topic, and > this can become working group item. > > +---+ > |CN | > +-+-+ > | 2001:db8:2001::CN > | > +---+---+2001:db8:2000:/36 > | | > +---------+ ISP2 | > | | | > | +-------+ > | > +---+---+2001:db8:1000:/36 +-------+2001:db8:3000::/36 > | | | | > | ISP1 +-------------------+ ISP3 | > | | | | > +---+---+ +---+---+ > | | > | | > +----------+ +--------+ > 2001:db8:1000:R1| |2001:db8:3000:R3 > +-+-+ +-+-+ > 2001:db8:1001::/48|R1 | |R3 |2001:db8:3001::/48 > +-+-+ +-+-+ > 2001:db8:1001:1:R1| |2001:db8:3001:1:R3 > | | > --+---+---+-- > 2001:db8:1001:1:EN | 2001:db8:3001:1:EN > +-+-+ > |EN | > +---+ > > Routing Tables: > R1: > Destination Next Hop > 2001:db8:1000::/36 address_of_ISP1's_router > 2001:db8:2000::/36 address_of_ISP1's_router > R3: > 2001:db8:3000::/36 address_of_ISP3's_router > EN: > Destination Next Hop > 2001:db8:1000::/36 2001:db8:1001:1:R1 > 2001:db8:2000::/36 2001:db8:1001:1:R1 > 2001:db8:3000::/36 2001:db8:3001:1:R3 > > Any questions and comments are welcome. > > Regards, > ------------------------------------------------------------------ > FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias > Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan > Mail: fujikawa@root-hq.com, hudikaha@gmail.com > WWW: http://www23.atwiki.jp/hudikaha/ > Skype: fujikawakenji > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 11:14:50 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDF73A6F3B; Thu, 28 Feb 2008 11:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5rXE8W1d9kt; Thu, 28 Feb 2008 11:14:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF823A6F03; Thu, 28 Feb 2008 11:14:44 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4523A6C2B for ; Thu, 28 Feb 2008 11:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0K2oEWcG5ME for ; Thu, 28 Feb 2008 11:14:37 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DA22A3A6EDF for ; Thu, 28 Feb 2008 11:14:36 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Feb 2008 14:14:26 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1SJERjx008761; Thu, 28 Feb 2008 14:14:27 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1SJE4Bd024738; Thu, 28 Feb 2008 19:14:27 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 14:14:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Use longest-matching prefix to the next hop Date: Thu, 28 Feb 2008 14:14:11 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use longest-matching prefix to the next hop Thread-Index: Ach5xi6z9hynzvtRSGmnM3cAGBeztgAdWwZA References: From: "Hemant Singh (shemant)" To: "FUJIKAWA Kenji" , X-OriginalArrivalTime: 28 Feb 2008 19:14:11.0967 (UTC) FILETIME=[19CFD0F0:01C87A3E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8972; t=1204226067; x=1205090067; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Use=20longest-matching=20prefix=20to=20 the=20next=20hop |Sender:=20 |To:=20=22FUJIKAWA=20Kenji=22=20,=20< ipv6@ietf.org>; bh=hd7eR/xAxLRMAt+VNQe/gDnlyWOyvqjltjJgszEh6uM=; b=zwBpopBr8Jjg3LqpXWslzS7A+1aozrT9SMfz8250DJScTl44tyIMSq3ICJ 4rc7v44PtUgtPq2DuWehCj1ZElE3kBGxrpJhPUqn4nFC38kw/dXcNrsFsIZT YBhRcyaiYV; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Fujikawa san, I leave it to the WG to decide what to do with this draft. What you are suggesting for a solution is already mentioned in RFC 3484. So I don't know understand why we need your draft? Maybe it can be an Information draft. I don't see a category of Standards Track or Informational in your draft. What you are suggesting for solution is already motioned in RFC 3484. Here is that information. Section 5, Rule 8 says [Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance.] "best" communication performance can mean best routing path. Further section 7 of the same RFC explains how does SAS interface with routing. Snipped below is a text that says [Implementations may also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and the other router is advertising global prefix B. Then when sending via the first router, the host may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B.] The text above is your solution described in section 2.2 of your draft. You look up the routing entry for the destination first (like how section 7 of RFC 3484 also says), and then on seeing that the routing entry shows path thru router R1 (in your example), then EN will use the 2001:db8:1001:1:EN for src-addr (this is what the sentence in section 7 of RFC 3484 also says). Is your solution any different from what is already described in RFC 3284? What am I missing? Thanks. Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of FUJIKAWA Kenji Sent: Wednesday, February 27, 2008 11:34 PM To: ipv6@ietf.org Subject: Re: Use longest-matching prefix to the next hop Hemant Singh; Thank you for your comments. At Wed, 27 Feb 2008 16:01:27 -0500, Hemant Singh (shemant) wrote: > > The draft should not be considered for 6man as a WG item just yet > because it needs some more work before the draft is even acceptable to > review. Here is some things to look at after I read portions of the > draft at the URL below. > > 1. Section 1 of the draft says 2001:db8:3001:1:EN is selected as the > source address of a packet directed from CN to EN. Huh? CN has only an > address of 2001:db8:2001::CN, so how can a src of 2001:db8:3001:1:EN > be picked? > Because 2001:db8:3001:1:EN longer-matches to 2001:db8:2001::CN than 2001:db8:1001:1:EN. # Note that 1 = 01, 2 = 10, and 3 = 11 in binary form. > 2. Section 1 says: > > [Here, in the above IPv6 address notation, CN, R1, R2, and EN > indicates 64bit Interface ID's.] > > There is no router R2 in the picture of Fig. 1. > This is typo. > How can one review this document with such basic mistakes/typos in the > picture? > > 3. In section 3 you say: > > [Before Rule 8 (Use longest matching prefix) in section 5. (Source > Address Selection) in RFC3484, the rule using longest-matching prefix > to the next hop is to be added.] > > Did I get is right that you are changing src-addr based on next hop? > Basic IP data forwarding and routing ships packets between consecutive > hops using L2 addresses. For packet flow from src to dest with > multiple hops in between, the L3 src and dest addresses do not change! > Src and dest L3 addresses can only be changed by some proxy node in > the path. I hope you are not suggesting changing L3 src-addr from hop to hop! > No, I am not suggesting changing L3 src-addr from hop to hop. > I suggest you forget about the solution. First define your src-addr > selection problem and let the mailer first agree you have a problem. > Then we'll see what is the solution. You have a lot of sections in the > draft with problems/issues, viz., > > 1. A Problem of at Source Address Selection Rule 8. in RFC3484 > 2.1 Management Issue > 2.2 Implementation Issue > > It confuses the reader as to what is the one single problem you are > trying to solve. Or if you are solving multiple problems, list them at > the beginning of the draft. Sorry, if I have missed such problem > definitions in the mailer earlier than one year from now. > I see. Thank you for your advice. 2.1 and 2.2 should be "Management Approach" and "Implementation Approach" or something. > I suggest the same to the authors of > draft-ietf-6man-addr-select-sol-00.txt. Could you please first > describe what is the problem with SAS as specified in RFC 3484. > > Hemant > ------------------------------------------------------------------ FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan Mail: fujikawa@root-hq.com, hudikaha@gmail.com WWW: http://www23.atwiki.jp/hudikaha/ Skype: fujikawakenji > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of FUJIKAWA Kenji > Sent: Monday, February 25, 2008 9:31 PM > To: ipv6@ietf.org > Subject: Use longest-matching prefix to the next hop > > Hi all, > > I am submitting an ID, > > http://www.ietf.org/proceedings/staging/draft-fujikawa-ipv6-src-addr-s > el > ection-02.txt > and suggesting in the draft that, > > Before Rule 8 (Use longest matching prefix) in section 5. (Source > Address Selection) in RFC3484, the rule using longest-matching prefix > to the next hop is to be added. > > The following is an example, > where the Rule 8 selects the roundabout path via ISP3, while the > method of using longest-matching prefix to the next hop selects the > shortest and best path, when EN sends a packet to CN. > > # In the previous IETF meeting I only showed a single router case. > # but this method is adaptable and useful to the multiple router case. > > I would like to ask if 6man people is interested in this topic, and > this can become working group item. > > +---+ > |CN | > +-+-+ > | 2001:db8:2001::CN > | > +---+---+2001:db8:2000:/36 > | | > +---------+ ISP2 | > | | | > | +-------+ > | > +---+---+2001:db8:1000:/36 +-------+2001:db8:3000::/36 > | | | | > | ISP1 +-------------------+ ISP3 | > | | | | > +---+---+ +---+---+ > | | > | | > +----------+ +--------+ > 2001:db8:1000:R1| |2001:db8:3000:R3 > +-+-+ +-+-+ > 2001:db8:1001::/48|R1 | |R3 |2001:db8:3001::/48 > +-+-+ +-+-+ > 2001:db8:1001:1:R1| |2001:db8:3001:1:R3 > | | > --+---+---+-- > 2001:db8:1001:1:EN | 2001:db8:3001:1:EN > +-+-+ > |EN | > +---+ > > Routing Tables: > R1: > Destination Next Hop > 2001:db8:1000::/36 address_of_ISP1's_router > 2001:db8:2000::/36 address_of_ISP1's_router > R3: > 2001:db8:3000::/36 address_of_ISP3's_router > EN: > Destination Next Hop > 2001:db8:1000::/36 2001:db8:1001:1:R1 > 2001:db8:2000::/36 2001:db8:1001:1:R1 > 2001:db8:3000::/36 2001:db8:3001:1:R3 > > Any questions and comments are welcome. > > Regards, > ------------------------------------------------------------------ > FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias > Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan > Mail: fujikawa@root-hq.com, hudikaha@gmail.com > WWW: http://www23.atwiki.jp/hudikaha/ > Skype: fujikawakenji > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 14:48:00 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22333A6C75; Thu, 28 Feb 2008 14:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEbN8nw+LgIB; Thu, 28 Feb 2008 14:48:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D049A3A6DD2; Thu, 28 Feb 2008 14:47:20 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBC93A69A2 for ; Thu, 28 Feb 2008 14:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUTRBvkE4FPk for ; Thu, 28 Feb 2008 14:47:14 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 44AD73A67B3 for ; Thu, 28 Feb 2008 14:47:13 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1SMl5RJ003071 for ; Thu, 28 Feb 2008 17:47:06 -0500 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1SMl5sK003062; Thu, 28 Feb 2008 17:47:05 -0500 Received: from IMCSRV7.MITRE.ORG ([129.83.20.57]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 17:47:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Thu, 28 Feb 2008 17:45:27 -0500 Message-ID: <0AC4B700F00DBB4C94F95727E0991414D84605@IMCSRV7.MITRE.ORG> In-Reply-To: <831FE02B5345194BA8147EDEF5F13388297D18D5@G3W0070.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document thread-index: Ach5h+Sco3YQYuyESV+0SFui0DmlcgApGe9QAAufbSA= References: <47C595D2.8030703@sri.com> <18373.39899.246979.270406@gargle.gargle.HOWL><02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com><18373.51513.398270.398946@gargle.gargle.HOWL> <47C5D12B.8000708@gmail.com><47C5D5BE.9050906@sri.com> <831FE02B5345194BA8147EDEF5F13388297D18D5@G3W0070.americas.hpqcorp.net> From: "Dunn, Jeffrey H." To: "Bound, Jim" , "Ed Jankiewicz" , X-OriginalArrivalTime: 28 Feb 2008 22:47:04.0908 (UTC) FILETIME=[D713F0C0:01C87A5B] Cc: Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Colleagues, While I agree with Jim in principal, I should add that the entire premise of a "one size fits all" IPv6 node description will probably suffer from being the too low lowest common denominator. To wit, by the definition in 4294, a host runs the gamut of complex servers to UDP speakers attached to simple sensors, e.g., a thermometer. As a result, I am not sure how much impact 4294 will have with industry or government, as the definition is so broad it is almost meaningless. Just my $0.02. Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bound, Jim Sent: Thursday, February 28, 2008 12:11 PM To: Ed Jankiewicz; ipv6@ietf.org Cc: Brian E Carpenter Subject: RE: the role of the node "requirements" document I believe all IPv6 nodes SHOULD support IPsec. I don't care about the PKI or other managed parts but if they are referenced to IPsec they should have no known protocol interoperability problems, the market will decide and select on that one is my view. This should clearly not mandate USE as others have stated. I also would support a MUST as I agree with Dow and others who can see the value of a MUST but I will not fight to hard if majority wants to move to SHOULD. If it is 50/50 for consensus I will continue to provide data why MUST has to remain. And I want to reiterate and note the important mail from Tony Hain for this polling to others as input to our collective thoughts. Thanks Dow /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Ed Jankiewicz > Sent: Wednesday, February 27, 2008 4:27 PM > To: ipv6@ietf.org > Cc: Brian E Carpenter > Subject: Re: the role of the node "requirements" document > > I lean towards (3) because IPsec without IKE or something is > unmanageable. I could support MUST or SHOULD, or a > conditional statement, and would prefer linking to IKEv2 as > part of the package. > Thomas hinted at the "chicken and egg" problem with IKEv2 - > we'd like to mandate it to encourage implementation, but > hesitate to mandate something that hardly exists in the near future... > > But I would go along with Brian's sentiment about IETF not > dictating use; that has been said a few times in various ways > during this discussion. Reality is even if 4294 is not > updated, it makes no difference to the actual implementation > and use of IPsec; if revision says nothing about IPsec, it > makes no difference. If the revision says SHOULD or MUST, > probably makes no difference. Implementors will make their > own choices as will buyers of products. > > > Brian E Carpenter wrote: > > On 2008-02-28 09:34, James Carlson wrote: > > > >> Dow Street writes: > >> > >>> 1. the Internet *does not* need a mandatory security > mechanism at > >>> the IP layer 2. the Internet *does* need a mandatory security > >>> mechanism at the IP layer, but IPsec is not the right one > because it > >>> is too heavyweight 3. the Internet *does* need a > mandatory security > >>> mechanism at the IP layer, but IPsec *alone* is insufficient > >>> (without IKE, key mgmt, etc) 4. I don't care about the > architecture > >>> of the Internet, because I intend to develop devices that > are never > >>> connected to the global Internet (and therefore play no role in > >>> defining the Internet architecture or adhering to Internet best > >>> practices). > >>> > >> I suppose I'm closest to (1) in your list, but I'd still phrase it > >> differently. > >> > >> 5. IP itself works properly without IPsec -- and demonstrably so. > >> It's not a _requirement_; it's not something that > without which IP > >> simply fails to operate. It's desirable, and likely highly > >> desirable, but it's not a fundamental issue. > >> > > > > I'm close to this position too, but even closer to > > > > 6. As long as the IETF specifies a way of securing the IP > layer, it's > > an implementation, procurement and operational issue > whether it gets > > used. Words in an RFC have no control over that. > > > > And don't forget what Thomas said about keying. > > > > Brian > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > > -- > Ed Jankiewicz - SRI International > Fort Monmouth Branch Office - IPv6 Research Supporting DISA > Standards Engineering Branch > 732-389-1003 or ed.jankiewicz@sri.com > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Feb 28 17:31:38 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11A328C892; Thu, 28 Feb 2008 17:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.009 X-Spam-Level: X-Spam-Status: No, score=0.009 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5GhjxPwEsID; Thu, 28 Feb 2008 17:31:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62FE93A6B84; Thu, 28 Feb 2008 17:31:36 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8217F28C1FE for ; Thu, 28 Feb 2008 17:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em8cCvPWu0x7 for ; Thu, 28 Feb 2008 17:31:29 -0800 (PST) Received: from 122x218x96x122.ap122.ftth.ucom.ne.jp (unknown [IPv6:2002:7ada:607a:0:8102:7ada:607a:0]) by core3.amsl.com (Postfix) with ESMTP id 5A19E3A6A37 for ; Thu, 28 Feb 2008 17:31:27 -0800 (PST) Received: from coin (localhost [127.0.0.1]) by 122x218x96x122.ap122.ftth.ucom.ne.jp (Postfix) with ESMTP id 5FDC56BF89 for ; Fri, 29 Feb 2008 10:31:19 +0900 (JST) Received: from coin.bbtec.net (localhost [127.0.0.1]) by coin (Postfix) with ESMTP id CAB8E6C7DB for ; Fri, 29 Feb 2008 10:31:18 +0900 (JST) Date: Fri, 29 Feb 2008 10:31:18 +0900 Message-ID: From: FUJIKAWA Kenji To: ipv6@ietf.org Subject: Re: Use longest-matching prefix to the next hop In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.7 Emacs/22.1 (i386--netbsdelf) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Hemant Singh, At Thu, 28 Feb 2008 12:57:45 -0500, Hemant Singh (shemant) wrote: > > Sorry, you missed my point about your -02 draft with another typo where > the text says [is selected as the source address of a packet directed > from CN to EN] - this is text towards the end of section 1. The text > should say [packet directed from EN to CN] or I don't understand what > are you trying in this SAS example. > It's my mistake as you indicated. Sorry. At Thu, 28 Feb 2008 14:14:11 -0500, Hemant Singh (shemant) wrote: > > I leave it to the WG to decide what to do with this draft. What you are > suggesting for a solution is already mentioned in RFC 3484. So I don't > know understand why we need your draft? Maybe it can be an Information > draft. > I don't see a category of Standards Track or Informational in > your draft. > > What you are suggesting for solution is already motioned in RFC 3484. > Here is that information. > > Section 5, Rule 8 says > > [Rule 8 may be superseded if the implementation has other means of > choosing among source addresses. For example, if the implementation > somehow knows which source address will result in the "best" > communications performance.] > > "best" communication performance can mean best routing path. > > Further section 7 of the same RFC explains how does SAS interface with > routing. Snipped below is a text that says > Yes, my draft is one of means of choosing the best source address. As a standard track, adding my method before Rule 8. is RFC3484 is the best, I think, but being published as an Informational is also further useful for source address selection in multihomed sites. This is what I would like to ask to 6man people. > [Implementations may also use the choice of router to influence the > choice of source address. For example, suppose a host is on a link > with two routers. One router is advertising a global prefix A and > the other router is advertising global prefix B. Then when sending via > the first router, the host may prefer source addresses with > prefix A and when sending via the second router, prefer source > addresses with prefix B.] > > The text above is your solution described in section 2.2 of your draft. > You look up the routing entry for the destination first (like how > section 7 of RFC 3484 also says), and then on seeing that the routing > entry shows path thru router R1 (in your example), then EN will use the > 2001:db8:1001:1:EN for src-addr (this is what the sentence in section 7 > of RFC 3484 also says). > > Is your solution any different from what is already described in RFC > 3284? What am I missing? > First, my draft clarifies one implementationable algorithm of the method in RFC3484 you mentioned. Then, it requires the interfaces of the routers should be assigned global IP addresses. In addition, the draft shows the algorithm is applicable to a single router case. Thank you for your comments, I will re-write my draft so that it clarifies the relationship between RFC3484 you indicated. Regards ------------------------------------------------------------------ FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan Mail: fujikawa@root-hq.com, hudikaha@gmail.com WWW: http://www23.atwiki.jp/hudikaha/ Skype: fujikawakenji Tel: +66 8-4773-3252 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > FUJIKAWA Kenji > Sent: Wednesday, February 27, 2008 11:34 PM > To: ipv6@ietf.org > Subject: Re: Use longest-matching prefix to the next hop > > Hemant Singh; > > Thank you for your comments. > > At Wed, 27 Feb 2008 16:01:27 -0500, > Hemant Singh (shemant) wrote: > > > > The draft should not be considered for 6man as a WG item just yet > > because it needs some more work before the draft is even acceptable to > > > review. Here is some things to look at after I read portions of the > > draft at the URL below. > > > > 1. Section 1 of the draft says 2001:db8:3001:1:EN is selected as the > > source address of a packet directed from CN to EN. Huh? CN has only an > > > address of 2001:db8:2001::CN, so how can a src of 2001:db8:3001:1:EN > > be picked? > > > > Because 2001:db8:3001:1:EN longer-matches to 2001:db8:2001::CN than > 2001:db8:1001:1:EN. > > # Note that 1 = 01, 2 = 10, and 3 = 11 in binary form. > > > 2. Section 1 says: > > > > [Here, in the above IPv6 address notation, CN, R1, R2, and EN > > indicates 64bit Interface ID's.] > > > > There is no router R2 in the picture of Fig. 1. > > > > This is typo. > > > How can one review this document with such basic mistakes/typos in the > > > picture? > > > > 3. In section 3 you say: > > > > [Before Rule 8 (Use longest matching prefix) in section 5. (Source > > Address Selection) in RFC3484, the rule using longest-matching prefix > > > to the next hop is to be added.] > > > > Did I get is right that you are changing src-addr based on next hop? > > Basic IP data forwarding and routing ships packets between consecutive > > > hops using L2 addresses. For packet flow from src to dest with > > multiple hops in between, the L3 src and dest addresses do not change! > > > Src and dest L3 addresses can only be changed by some proxy node in > > the path. I hope you are not suggesting changing L3 src-addr from hop > to hop! > > > > No, I am not suggesting changing L3 src-addr from hop to hop. > > > I suggest you forget about the solution. First define your src-addr > > selection problem and let the mailer first agree you have a problem. > > Then we'll see what is the solution. You have a lot of sections in the > > > draft with problems/issues, viz., > > > > 1. A Problem of at Source Address Selection Rule 8. in RFC3484 > > 2.1 Management Issue > > 2.2 Implementation Issue > > > > It confuses the reader as to what is the one single problem you are > > trying to solve. Or if you are solving multiple problems, list them at > > > the beginning of the draft. Sorry, if I have missed such problem > > definitions in the mailer earlier than one year from now. > > > > I see. Thank you for your advice. > 2.1 and 2.2 should be "Management Approach" and "Implementation > Approach" > or something. > > > I suggest the same to the authors of > > draft-ietf-6man-addr-select-sol-00.txt. Could you please first > > describe what is the problem with SAS as specified in RFC 3484. > > > > Hemant > > > ------------------------------------------------------------------ > FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias > Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan > Mail: fujikawa@root-hq.com, hudikaha@gmail.com > WWW: http://www23.atwiki.jp/hudikaha/ > Skype: fujikawakenji > > > > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > Of FUJIKAWA Kenji > > Sent: Monday, February 25, 2008 9:31 PM > > To: ipv6@ietf.org > > Subject: Use longest-matching prefix to the next hop > > > > Hi all, > > > > I am submitting an ID, > > > > http://www.ietf.org/proceedings/staging/draft-fujikawa-ipv6-src-addr-s > > el > > ection-02.txt > > and suggesting in the draft that, > > > > Before Rule 8 (Use longest matching prefix) in section 5. (Source > > Address Selection) in RFC3484, the rule using longest-matching > prefix > > to the next hop is to be added. > > > > The following is an example, > > where the Rule 8 selects the roundabout path via ISP3, while the > > method of using longest-matching prefix to the next hop selects the > > shortest and best path, when EN sends a packet to CN. > > > > # In the previous IETF meeting I only showed a single router case. > > # but this method is adaptable and useful to the multiple router case. > > > > I would like to ask if 6man people is interested in this topic, and > > this can become working group item. > > > > +---+ > > |CN | > > +-+-+ > > | 2001:db8:2001::CN > > | > > +---+---+2001:db8:2000:/36 > > | | > > +---------+ ISP2 | > > | | | > > | +-------+ > > | > > +---+---+2001:db8:1000:/36 +-------+2001:db8:3000::/36 > > | | | | > > | ISP1 +-------------------+ ISP3 | > > | | | | > > +---+---+ +---+---+ > > | | > > | | > > +----------+ +--------+ > > 2001:db8:1000:R1| |2001:db8:3000:R3 > > +-+-+ +-+-+ > > 2001:db8:1001::/48|R1 | |R3 |2001:db8:3001::/48 > > +-+-+ +-+-+ > > 2001:db8:1001:1:R1| |2001:db8:3001:1:R3 > > | | > > --+---+---+-- > > 2001:db8:1001:1:EN | 2001:db8:3001:1:EN > > +-+-+ > > |EN | > > +---+ > > > > Routing Tables: > > R1: > > Destination Next Hop > > 2001:db8:1000::/36 address_of_ISP1's_router > > 2001:db8:2000::/36 address_of_ISP1's_router > > R3: > > 2001:db8:3000::/36 address_of_ISP3's_router > > EN: > > Destination Next Hop > > 2001:db8:1000::/36 2001:db8:1001:1:R1 > > 2001:db8:2000::/36 2001:db8:1001:1:R1 > > 2001:db8:3000::/36 2001:db8:3001:1:R3 > > > > Any questions and comments are welcome. > > > > Regards, > > ------------------------------------------------------------------ > > FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias > > > Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan > > Mail: fujikawa@root-hq.com, hudikaha@gmail.com > > WWW: http://www23.atwiki.jp/hudikaha/ > > Skype: fujikawakenji > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 29 07:31:41 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B6E3A6F3A; Fri, 29 Feb 2008 07:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6gwJV4ZoRU5; Fri, 29 Feb 2008 07:31:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70C43A6C0E; Fri, 29 Feb 2008 07:31:40 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944753A693A for ; Fri, 29 Feb 2008 07:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCveUxe6K4Za for ; Fri, 29 Feb 2008 07:31:35 -0800 (PST) Received: from mail.polartel.com (mail.polartel.com [66.231.96.142]) by core3.amsl.com (Postfix) with ESMTP id A8DF428C266 for ; Fri, 29 Feb 2008 07:31:35 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: the role of the node "requirements" document Date: Fri, 29 Feb 2008 09:31:26 -0600 Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F3E2@mail> In-Reply-To: <47C6046D.20207@blunkmicro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5pmlhyfrIX16KQrWrd2mUZMD3ngBPhtfw References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail> <47C6046D.20207@blunkmicro.com> From: "Kevin Kargel" To: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org To make a furthur rediculous analogy, SMTP is a wonderfully functional spec, and it makes perfect sense to mandate that any devices utilizing SMTP MUST be compliant to the ESMTP spec RFC2821, but it would be rather silly to mandate that ALL IPv6 connected devices be RFC2821 compliant regardless of whether they have a requirement for SMTP. If the operating system of the nifty internet accessible doohickey that you wish to patent and sell has no need to exchange email, then building in ESMTP compliance would be an unecessary expense that would reduce the profitiability of your venture and would cost consumers (who ultimately pay for everything) more money. It may be a piddling amount, and a trivial implementation, but we must bear in mind the straw/camel parable. Many little things can aggregate to be a large burden. > Kevin and many others against mandating (MUST) for IPSec have > a valid point. Many sensors and other potential IPv6 nodes > do not have the hardware resources to support IPSec, or those > resources are better spent at other tasks. ..... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 29 07:49:54 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D2E28C5B1; Fri, 29 Feb 2008 07:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq2rR-GhIxSd; Fri, 29 Feb 2008 07:49:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26753A69BD; Fri, 29 Feb 2008 07:49:48 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B3628C258 for ; Fri, 29 Feb 2008 07:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHTnIImP9i-p for ; Fri, 29 Feb 2008 07:49:41 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3615E3A6A8B for ; Fri, 29 Feb 2008 07:49:41 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1TFnBrS027592; Fri, 29 Feb 2008 17:49:31 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 17:47:48 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 09:47:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: the role of the node "requirements" document Date: Fri, 29 Feb 2008 09:47:41 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533A010EB850@daebe104.NOE.Nokia.com> In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F3E2@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach5pmlhyfrIX16KQrWrd2mUZMD3ngBPhtfwAAE2FeA= References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com><70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail><47C6046D.20207@blunkmicro.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F3E2@mail> From: To: , X-OriginalArrivalTime: 29 Feb 2008 15:47:46.0848 (UTC) FILETIME=[6E1E6200:01C87AEA] X-Nokia-AV: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Kevin, I would say that is not a logical argument, IMO. The IETF has long considered security to be an essential part of internet protocols. Pease read http://tools.ietf.org/html/rfc4301. SMTP in that sense is optional, and not considered a part of IPv6. The ability to secure the IP layer has been seen as a mandatory requirement from the Security AD. That being said, there seems to be strong feeling that IPsec support is not being considered mandatory, so the WG needs to consider how we are able to secure the IP layer. I do not think l2 security is sufficient, as L2 security will not create a security association between two arbitrary nodes in the interenet. I would also mention that some people are looking at more point solutions or solutions that may be deployed in a managed deployment. IMO, those are not the general case that the Node Req. document is trying to address. I will try to summarize this thread, but I think it might be up to the WG chairs to discuss this with our ADs and the Security ADs to understand what the IESG considers to be the correct level of security requirements. John >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >Behalf Of ext Kevin Kargel >Sent: 29 February, 2008 07:31 >To: ipv6@ietf.org >Subject: RE: the role of the node "requirements" document > > To make a furthur rediculous analogy, SMTP is a >wonderfully functional spec, and it makes perfect sense to >mandate that any devices utilizing SMTP MUST be compliant to >the ESMTP spec RFC2821, but it would be rather silly to >mandate that ALL IPv6 connected devices be RFC2821 compliant >regardless of whether they have a requirement for SMTP. > > If the operating system of the nifty internet >accessible doohickey that you wish to patent and sell has no >need to exchange email, then building in ESMTP compliance >would be an unecessary expense that would reduce the >profitiability of your venture and would cost consumers (who >ultimately pay for everything) more money. > > It may be a piddling amount, and a trivial >implementation, but we must bear in mind the straw/camel >parable. Many little things can aggregate to be a large burden. > > >> Kevin and many others against mandating (MUST) for IPSec >have a valid >> point. Many sensors and other potential IPv6 nodes do not have the >> hardware resources to support IPSec, or those resources are better >> spent at other tasks. >..... >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 29 08:01:45 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2AE28C52B; Fri, 29 Feb 2008 08:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNglqyszMiBl; Fri, 29 Feb 2008 08:01:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86163A6910; Fri, 29 Feb 2008 08:01:39 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D483A67D0 for ; Fri, 29 Feb 2008 08:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUf6nyNwiWhY for ; Fri, 29 Feb 2008 08:01:37 -0800 (PST) Received: from smtp138.iad.emailsrvr.com (smtp138.iad.emailsrvr.com [207.97.245.138]) by core3.amsl.com (Postfix) with ESMTP id CCFF228C3DA for ; Fri, 29 Feb 2008 08:01:37 -0800 (PST) Received: from relay3.r3.iad.emailsrvr.com (localhost [127.0.0.1]) by relay3.r3.iad.emailsrvr.com (SMTP Server) with ESMTP id DAA0044C1AB; Fri, 29 Feb 2008 11:01:29 -0500 (EST) Received: by relay3.r3.iad.emailsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTP id 8AA9344C13A; Fri, 29 Feb 2008 11:01:29 -0500 (EST) In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F3E2@mail> References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail> <47C6046D.20207@blunkmicro.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F3E2@mail> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8CF7F3B5-6514-4E76-B939-6950CD0B89D1@linquest.com> From: Dow Street Subject: Re: the role of the node "requirements" document Date: Fri, 29 Feb 2008 08:01:13 -0800 To: Kevin Kargel X-Mailer: Apple Mail (2.752.3) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Feb 29, 2008, at 7:31 AM, Kevin Kargel wrote: > To make a furthur rediculous analogy, SMTP is a wonderfully > functional spec, and it makes perfect sense to mandate that any > devices > utilizing SMTP MUST be compliant to the ESMTP spec RFC2821, but it > would > be rather silly to mandate that ALL IPv6 connected devices be RFC2821 > compliant regardless of whether they have a requirement for SMTP. I'm not an SMTP expert, but if I understand your comments correctly I think your analogy actually supports a MUST for IPsec for all IPv6 nodes. 1. "Node running SMTP MUST support ESMTP, and enhanced profile of SMTP with additional functionality" is similar to... 2. "Node running IPv6 MUST support IPsec, an enhanced profile of IPv6 with additional functionality" Besides, analogies to mechanisms above or below IP are only partly useful, if you indeed believe that IP is a special part of the stack (the waist, the consensus, the common convergence layer, etc.) R, Dow -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 29 08:36:01 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0420028C630; Fri, 29 Feb 2008 08:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-1.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtQfCqR9nWbP; Fri, 29 Feb 2008 08:35:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419F428C42C; Fri, 29 Feb 2008 08:35:55 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA5E3A6A0A for ; Fri, 29 Feb 2008 08:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQs0eMsbW9ng for ; Fri, 29 Feb 2008 08:35:48 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 232403A67D0 for ; Fri, 29 Feb 2008 08:35:47 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m1TGZdKW026044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Feb 2008 08:35:40 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m1TGZdSb013783 for ; Fri, 29 Feb 2008 08:35:39 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m1TGZceD013761 for ; Fri, 29 Feb 2008 08:35:39 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 08:35:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: [Int-area] FW: [RRG] Subnetwork Encapsulation and Adaptation Layer(SEAL) Date: Fri, 29 Feb 2008 08:35:36 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDEBA@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] FW: [RRG] Subnetwork Encapsulation and Adaptation Layer(SEAL) thread-index: AchtBlQLjkHj432HT5+LfAhaAW/K4gAAUw0QADUyxPAAJLuXEAJZ8GVQAJRmgUAAMQTcMA== From: "Templin, Fred L" To: X-OriginalArrivalTime: 29 Feb 2008 16:35:36.0769 (UTC) FILETIME=[1CB99310:01C87AF1] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Forwarding this from other lists. This document addresses known limitations for use cases such as tunneling IPv6 over IPv4. Fred fred.l.templin@boeing.com -----Original Message----- From: Templin, Fred L Sent: Thursday, February 28, 2008 9:12 AM To: v6ops@ops.ietf.org Subject: FW: [Int-area] FW: [RRG] Subnetwork Encapsulation and Adaptation Layer(SEAL) Forwarding from the int-area list, a new document with v6ops implications is available and titled: "Subnetwork Encapsulation and Adaptation Layer (SEAL)" http://www.ietf.org/internet-drafts/draft-templin-seal-03.txt This specification considers the use case for router-to-router tunneling of IPv6 over IPv4 in enterprise networks, MANETs, and the global Internet routing core. It also addresses many of the tunnel MTU and fragmentation issues raised in RFC4459. Additional background on the proposed approach is given in the forwarded message (below). Please review along with the document itself and send comments. Fred fred.l.templin@boeing.com -----Original Message----- From: Templin, Fred L Sent: Monday, February 25, 2008 9:58 AM To: Internet Area Subject: [Int-area] FW: [RRG] Subnetwork Encapsulation and Adaptation Layer(SEAL) This message is forwared from the Routing Research Group mailing list. A new document with int-area implications is available and titled: "Subnetwork Encapsulation and Adaptation Layer (SEAL)" http://www.ietf.org/internet-drafts/draft-templin-seal-03.txt SEAL in part specifies an MTU determination scheme based on the Report Fragmentation (RF) concept that was first proposed by Charles Lynn on the tcp-ip mailing list in 1987 and re-introduced by Steve Deering on the Path MTU working group mailing list in 1989. Digests from those lists are found at: http://ipvlx.com/tcp_ip.txt http://gatekeeper.dec.com/pub/DEC/WRL/mogul/mtudwg-log Based on the list discussions, the Report Fragmentation (RF) method seemed to be the most attractive approach under consideration for IPv4 path MTU discovery, but was abandoned in favor of the (Don't Fragment/Fragmentation Needed) method that eventually became RFC1191. The RF method seems to have been abandoned due in part to difficulty in procuring an "RF" bit in the IPv4 header, difficulty in defining an ICMP Fragmentation Report message and the concern that not all hosts at that time correctly implemented IP reassembly. The SEAL proposal addresses all of these points (as well as others) and shows that a Report Fragmentation-based path MTU discovery capability for router-to-router tunneling in the Internet is still possible and could correct the operational difficulties associated with traditional path MTU discovery approaches. Moreover, the SEAL approach supports true diversity, especially for subnetworks that contain heterogeneous link types with diverse MTUs and/or L2 address formats. Please review and comment, Fred fred.l.templin@boeing.com _______________________________________________ Int-area mailing list Int-area@ietf.org http://www.ietf.org/mailman/listinfo/int-area -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 29 09:32:53 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1400528C5D9; Fri, 29 Feb 2008 09:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3QmxkmQdlMr; Fri, 29 Feb 2008 09:32:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7B528C1A9; Fri, 29 Feb 2008 09:32:20 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A740A28C498 for ; Fri, 29 Feb 2008 09:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-HL7dRmvAeM for ; Fri, 29 Feb 2008 09:32:14 -0800 (PST) Received: from mail.polartel.com (mail.polartel.com [66.231.96.142]) by core3.amsl.com (Postfix) with ESMTP id 2C99C3A6C09 for ; Fri, 29 Feb 2008 09:32:14 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: the role of the node "requirements" document Date: Fri, 29 Feb 2008 11:32:05 -0600 Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F3E9@mail> In-Reply-To: <8CF7F3B5-6514-4E76-B939-6950CD0B89D1@linquest.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the role of the node "requirements" document Thread-Index: Ach67tBZ/ZdDuuivREqeVHqOoqvaSgACdkIg References: <47C595D2.8030703@sri.com><18373.39899.246979.270406@gargle.gargle.HOWL> <02297828-D4AA-43D7-8329-6B597AA6E634@linquest.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F3DB@mail> <47C6046D.20207@blunkmicro.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F3E2@mail> <8CF7F3B5-6514-4E76-B939-6950CD0B89D1@linquest.com> From: "Kevin Kargel" To: "Dow Street" Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Not quite.. it would be more accurate if you said " 2. "Node running secure protocols MUST support IPsec, an enhanced profile of IPv6 with additional functionality" > 1. "Node running SMTP MUST support ESMTP, and enhanced > profile of SMTP with additional functionality" > > is similar to... > > 2. "Node running IPv6 MUST support IPsec, an enhanced profile > of IPv6 with additional functionality" > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 29 10:09:24 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB8728C74F; Fri, 29 Feb 2008 10:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.428 X-Spam-Level: X-Spam-Status: No, score=0.428 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzgcc2Twcjw1; Fri, 29 Feb 2008 10:09:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8836628C664; Fri, 29 Feb 2008 10:09:18 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457B128C1AA for ; Wed, 27 Feb 2008 14:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K38zqw56XXRY for ; Wed, 27 Feb 2008 14:36:50 -0800 (PST) Received: from web82306.mail.mud.yahoo.com (web82306.mail.mud.yahoo.com [209.191.85.226]) by core3.amsl.com (Postfix) with SMTP id 5892D3A6CD4 for ; Wed, 27 Feb 2008 14:36:50 -0800 (PST) Received: (qmail 51750 invoked by uid 60001); 27 Feb 2008 22:36:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=ZwISOgPt0M20po8adyMfyimG17PBoVmOLyWtvbwhatfMD8QlB7UPzt8Da++rnIQ/NqOWSUX3hyb0uqJ95JVKUMKbMReXat9vpMTs6CjiuBe3vO8dMM1zetRr6zT9gGYc49MonyQhDumz6SYJ8q/AnBUMP/2KqTxuBBQIVzXx8i0=; X-YMail-OSG: T5sJk.wVM1kFzwU8ZJMxYE1a4xUGglhurSF4zmcRuxWOdC3QP._MF0Gk9_aRIHsip8yeEK7vy0TuIy9jaKHM8wETObLzHzapF_e6HlWNAwO8rKF_oEE- Received: from [69.235.150.105] by web82306.mail.mud.yahoo.com via HTTP; Wed, 27 Feb 2008 14:36:43 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Wed, 27 Feb 2008 14:36:43 -0800 (PST) From: Mike Taylor Subject: RE: ipv6 Digest, Vol 46, Issue 33 To: ipv6@ietf.org MIME-Version: 1.0 Message-ID: <468454.44678.qm@web82306.mail.mud.yahoo.com> X-Mailman-Approved-At: Fri, 29 Feb 2008 10:09:17 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0150473688==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0150473688== Content-Type: multipart/alternative; boundary="0-1135514868-1204151803=:44678" --0-1135514868-1204151803=:44678 Content-Type: text/plain; charset=us-ascii > quick poll - for those opposed to a MUST requirement for IPsec, what > is your driving objection? > > 1. the Internet *does not* need a mandatory security mechanism at > the IP layer True. My personal feeling is that security at the IP layer is probably wrong for the majority of systems. It's great for setting up VPNs between security gateways with fixed globally routable addresses but otherwise it just doesn't seem to make a lot of sense. At least not if that IP-layer security, like IPsec, has to depend on configuring packet filters based on IP addresses, protocol numbers, and ports which as we know are far from permanent entities. It seems to me that the fundamental notion behind IPsec is that there is something sacred about IP addresses and port numbers, i.e., that they provide some form of permanent, trustable identification of a node. But of course that just isn't true. So what's the point, in general, of coupling a security mechanism to IP addresses and ports? I just personally don't get it, save for the one obvious application already notd above for VPN gateways. > 2. the Internet *does* need a mandatory security mechanism at the IP > layer, but IPsec is not the right one because it is too heavyweight > 3. the Internet *does* need a mandatory security mechanism at the IP > layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc) > 4. I don't care about the architecture of the Internet, because I > intend to develop devices that are never connected to the global > Internet (and therefore play no role in defining the Internet > architecture or adhering to Internet best practices). > And that too. Many of our customers are developing systems for closed private networks. We're not sure why they'd want to use IPv6 for that purpose but hey, the customer is always right. Certainly they should be able to develop lightweight devices for use on their private network and if those devices need to access the global internet they should be able to use a security gateway to accomplish that. But they wouldn't want to burden those devices with IPsec, even if IP-layer security made sense. And while it isn't a surmountable problem 5. We are being forced to treat all of our IPv6 enabled protocols such as FTP as encryption items by the U.S. export authorities because the U.S. government thinks they must be since IPv6 "includes security". It's just plain silly since our IPv6 is no different than our IPv4 - both get all their security from our IPsec which is sold separately. But we can't convince them otherwise because it has been mandated that all IPv6 nodes shall support IPsec. We can sell our IPv6 code without any trace of IPsec save for a few lines of interface code that are #ifdef'd out when IPsec isn't present and yet our IPv6 stack and worse yet, all of the socket-layer apps that support IPv6, are viewed as encryption items. Good grief. Regards, Mike Taylor > R, > Dow > > > ------------------------------ > > _______________________________________________ > ipv6 mailing list > ipv6@ietf.org > https://www.ietf.org/mailman/listinfo/ipv6 > > > End of ipv6 Digest, Vol 46, Issue 33 > ************************************ --0-1135514868-1204151803=:44678 Content-Type: text/html; charset=us-ascii

> quick poll - for those opposed to a MUST requirement for IPsec, what

> is your driving objection?

>

> 1.  the Internet *does not* need a mandatory security mechanism at

> the IP layer

 

True.  My personal feeling is that security at the IP layer is probably

wrong for the majority of systems.  It's great for setting up VPNs

between security gateways with fixed globally routable addresses but

otherwise it just doesn't seem to make a lot of sense.  At least not

if that IP-layer security, like IPsec, has to depend on configuring

packet filters based on IP addresses, protocol numbers, and ports

which as we know are far from permanent entities.

 

It seems to me that the fundamental notion behind IPsec is that

there is something sacred about IP addresses and port numbers, i.e.,

that they provide some form of permanent, trustable identification

of a node.  But of course that just isn't true.  So what's the point,

in general, of coupling a security mechanism to IP addresses and ports? 

I just personally don't get it, save for the one obvious application

already notd above for VPN gateways.

 

> 2.  the Internet *does* need a mandatory security mechanism at the IP

> layer, but IPsec is not the right one because it is too heavyweight

> 3.  the Internet *does* need a mandatory security mechanism at the IP

> layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc)

 

> 4.  I don't care about the architecture of the Internet, because I

> intend to develop devices that are never connected to the global

> Internet (and therefore play no role in defining the Internet

> architecture or adhering to Internet best practices).

>

 

And that too.  Many of our customers are developing systems for

closed private networks.  We're not sure why they'd want to use IPv6

for that purpose but hey, the customer is always right.  Certainly

they should be able to develop lightweight devices for use on their

private network and if those devices need to access the global internet

they should be able to use a security gateway to accomplish that.

But they wouldn't want to burden those devices with IPsec, even

if IP-layer security made sense.

 

And while it isn't a surmountable problem

 

5. We are being forced to treat all of our IPv6 enabled protocols such

   as FTP as encryption items by the U.S. export authorities because

   the U.S. government thinks they must be since IPv6 "includes

   security".  It's just plain silly since our IPv6 is no different

   than our IPv4 - both get all their security from our IPsec which

   is sold separately.  But we can't convince them otherwise because it

   has been mandated that all IPv6 nodes shall support IPsec.

   We can sell our IPv6 code without any trace of IPsec save for a few

   lines of interface code that are #ifdef'd out when IPsec isn't present

   and yet our IPv6 stack and worse yet, all of the socket-layer apps

   that support IPv6, are viewed as encryption items.  Good grief.

 

Regards,

 

Mike Taylor

 

> R,

> Dow

>

>

> ------------------------------

>

> _______________________________________________

> ipv6 mailing list

> ipv6@ietf.org

> https://www.ietf.org/mailman/listinfo/ipv6

>

>

> End of ipv6 Digest, Vol 46, Issue 33

> ************************************

--0-1135514868-1204151803=:44678-- --===============0150473688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0150473688==-- From ipv6-bounces@ietf.org Fri Feb 29 10:23:31 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B64F3A6E2E; Fri, 29 Feb 2008 10:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p8NnuKw2fPK; Fri, 29 Feb 2008 10:23:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077703A6DAB; Fri, 29 Feb 2008 10:23:24 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FAD3A6D53 for ; Fri, 29 Feb 2008 10:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWe8shJNueyQ for ; Fri, 29 Feb 2008 10:23:21 -0800 (PST) Received: from mailgate-internal1.sri.com (mailgate-internal1.SRI.COM [128.18.84.103]) by core3.amsl.com (Postfix) with SMTP id 3492D3A6F09 for ; Fri, 29 Feb 2008 10:23:00 -0800 (PST) Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 29 Feb 2008 18:22:49 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal1.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2008022910224826054 for ; Fri, 29 Feb 2008 10:22:48 -0800 Received: from [192.168.2.105] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JX000IDNJ1ZJLRW@mail.sri.com> for ipv6@ietf.org; Fri, 29 Feb 2008 10:22:48 -0800 (PST) Date: Fri, 29 Feb 2008 13:22:47 -0500 From: Ed Jankiewicz Subject: Re: ipv6 Digest, Vol 46, Issue 33 In-reply-to: <468454.44678.qm@web82306.mail.mud.yahoo.com> To: Mike Taylor Message-id: <47C84D77.8080101@sri.com> MIME-version: 1.0 References: <468454.44678.qm@web82306.mail.mud.yahoo.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Can you provide a citation to some authority for export restrictions on IPv6? I have not heard that before and find it surprising (though not impossible). That would be troubling, because IPsec in and of itself (and by association IPv6) does not necessarily contain any cryptographic code, although an implementation might. Also, not all algorithms would be subject to export control. Nothing in IPv6 or IPsec compels an implementor to include any restricted cryptographic code. I am definitely not a cryptography expert, nor am I an authority on US export regulations. However, in my day job I deal with IPv6 standards for US DoD and interact with a lot of vendors. I don't recall this coming up with any vendors, but if there is a chance this will be an issue, I need to do some homework. In particular, for DoD use we may require more advanced algorithms (see RFC 4869 and http://www.nsa.gov/ia/industry/crypto_suite_b.cfm) and I don't know what the restrictions on export of that code would be. Ed J. Mike Taylor wrote: > > And while it isn't a surmountable problem > > > > 5. We are being forced to treat all of our IPv6 enabled protocols such > > as FTP as encryption items by the U.S. export authorities because > > the U.S. government thinks they must be since IPv6 "includes > > security". It's just plain silly since our IPv6 is no different > > than our IPv4 - both get all their security from our IPsec which > > is sold separately. But we can't convince them otherwise because it > > has been mandated that all IPv6 nodes shall support IPsec. > > We can sell our IPv6 code without any trace of IPsec save for a few > > lines of interface code that are #ifdef'd out when IPsec isn't present > > and yet our IPv6 stack and worse yet, all of the socket-layer apps > > that support IPv6, are viewed as encryption items. Good grief. > > > > Regards, > > > > Mike Taylor > > > > > R, > > > Dow > > > > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > ipv6 mailing list > > > ipv6@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > > > End of ipv6 Digest, Vol 46, Issue 33 > > > ************************************ > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 29 12:17:15 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FE13A6F7A; Fri, 29 Feb 2008 12:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55hZ+1N9jThP; Fri, 29 Feb 2008 12:17:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9123A6F24; Fri, 29 Feb 2008 12:17:09 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853E53A6E78 for ; Fri, 29 Feb 2008 12:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+2PUQfL-LlA for ; Fri, 29 Feb 2008 12:17:03 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id DCC513A6DAD for ; Fri, 29 Feb 2008 12:17:02 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1TKGq1B031779 for ; Fri, 29 Feb 2008 15:16:52 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1TKGp0t215966 for ; Fri, 29 Feb 2008 15:16:51 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1TKGpIE018756 for ; Fri, 29 Feb 2008 15:16:51 -0500 Received: from cichlid.raleigh.ibm.com (wecm-9-67-164-220.wecm.ibm.com [9.67.164.220]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1TKGo11018666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 15:16:51 -0500 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m1TKGo5w014256; Fri, 29 Feb 2008 15:16:50 -0500 Message-Id: <200802292016.m1TKGo5w014256@cichlid.raleigh.ibm.com> To: Mike Taylor Subject: IPv6 as an export issue In-reply-to: <468454.44678.qm@web82306.mail.mud.yahoo.com> References: <468454.44678.qm@web82306.mail.mud.yahoo.com> Comments: In-reply-to Mike Taylor message dated "Wed, 27 Feb 2008 14:36:43 -0800." Date: Fri, 29 Feb 2008 15:16:49 -0500 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Mike Taylor writes: > And while it isn't a surmountable problem > > 5. We are being forced to treat all of our IPv6 enabled protocols such > as FTP as encryption items by the U.S. export authorities because > the U.S. government thinks they must be since IPv6 "includes > security". It's just plain silly since our IPv6 is no different > than our IPv4 - both get all their security from our IPsec which > is sold separately. But we can't convince them otherwise because it > has been mandated that all IPv6 nodes shall support IPsec. > We can sell our IPv6 code without any trace of IPsec save for a few > lines of interface code that are #ifdef'd out when IPsec isn't present > and yet our IPv6 stack and worse yet, all of the socket-layer apps > that support IPv6, are viewed as encryption items. Good grief. This sounds completely bogus to me. I've never heard of this problem before. Who else has this problem? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Feb 29 12:48:29 2008 Return-Path: X-Original-To: ietfarch-ipngwg-archive@core3.amsl.com Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368E328C754; Fri, 29 Feb 2008 12:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31y0Bvhp119n; Fri, 29 Feb 2008 12:48:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731B728C6BB; Fri, 29 Feb 2008 12:48:27 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF49128C372 for ; Fri, 29 Feb 2008 12:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGBynn2EXfY2 for ; Fri, 29 Feb 2008 12:48:19 -0800 (PST) Received: from mailgate-internal2.sri.com (mailgate-internal2.SRI.COM [128.18.84.104]) by core3.amsl.com (Postfix) with SMTP id C65D128C72D for ; Fri, 29 Feb 2008 12:47:34 -0800 (PST) Received: from localhost (HELO mailgate-internal2.SRI.COM) (127.0.0.1) by mailgate-internal2.sri.com with SMTP; 29 Feb 2008 20:47:26 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal2.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2008022912472512615 for ; Fri, 29 Feb 2008 12:47:25 -0800 Received: from [192.168.2.105] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JX000IGGPR1ISQ9@mail.sri.com> for ipv6@ietf.org; Fri, 29 Feb 2008 12:47:26 -0800 (PST) Date: Fri, 29 Feb 2008 15:47:25 -0500 From: Ed Jankiewicz Subject: Re: ipv6 as an export issue In-reply-to: <85494.80185.qm@web82308.mail.mud.yahoo.com> To: mtaylor.design@yahoo.com Message-id: <47C86F5D.70401@sri.com> MIME-version: 1.0 References: <85494.80185.qm@web82308.mail.mud.yahoo.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Cc: Thomas Narten , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org wow. I've never heard of the Bureau of Industry and Security. I'll do = a little digging, hopefully can get an opinion from someone at NSA. It = seems like an overly simplistic assumption that all IPv6 products are = encryption items. I'll post anything I discover that is "approved for = public release" to the list. mtaylor.design@yahoo.com wrote: > Hello Ed, > = > We have been fighting this battle directly with government personal > at the Bureau of Industry and Security = > (http://www.bis.doc.gov/about/index.htm) > both by email and by phone. It has been going on for months. We finally > had a phone conversation with a higher level manager at BIS just the > other day and as I expected by then we were told basically that if IPv6 > is mentioned anywhere in our product's documentation (even for socket > layer protocols like FTP or Telnet that happen to be able to run over > IPv6 sockets) that we MUST submit these products as encryption items > and fill out Supplement No. 6 to Part 742=97Guidelines for Submitting = > Review Requests > for Encryption Items and that they will have to go to the NSA and = > others for review. = > The mistake we made before is that we tried to submit these items as = > if they did > not include any encryption capabilities, which of course they do not, = > but this manager > informed us that in that case the review is done by lower level people = > who absolutely are > trained that if it says IPv6 then it is an encryption item because, as = > this manager told us > repeatedly, IPv6 by definition includes security so any products that = > support IPv6 are > by definition encryption items and must be reviewed by BIS as such. = > And this > review is done by different people than the ones who review non-encryption > items. We tried to explain again to him that technically it simply = > wasn't true that > IPv6 really has built-in security but as I expected it wasn't any use. = > = > He assured us that so long as we explained in supplement 6 that in so = > many words > the products were "passive" with regard to security, i.e, had no means = > of influencing > whether or not any security was applied to the application data, then = > it would not > be a lengthy process and we should get them through pretty easily. = > But he also > explained that the goverment doesn't care where the actual security = > operations > get carried out in the code. That is, the fact that it is all done by = > a separate > IPsec module and that we can sell our IPv6 code without IPsec is = > irrelevant. > The issue as best we can tell seems to be whether the product provides = > an API > by which a user of the product could influence/configure the use of = > security. Of > course none of our socket-layer products have such an API, and in fact = > our IPv6 > stack doesn't even have such an API. Only the IPsec product itself = > has such > an API. = > = > So once we explained this to him he acknowledged that probably we will = > in the > end be able to export the IPv6 products, without IPsec, under a lesser = > export > license (I forget the number) than an actual encryption item such as = > IPsec itself. > However, the products MUST still go to the correct people for review = > and thus > MUST be submitted with Supplement 6 as potential encryption items or they > will never get through. The laughable part is that every single part = > of Supplement > 6 will end up being filled out as N/A since this form asks you to = > supply the > details, like supported maximum encryption key lengths, for the supposed > encryption item. It's like some episode of MASH. > = > So it really aggravates us that because this misguided notion has been = > propagated > that IPv6 somehow has "built-in" security we must now go through this = > lengthier and > more involved process than we otherwise would have. Especially since, = > as we all know, > IPv6 has does not have built-in security any more than does IPv4 and = > yet apparently > because of the IPv6 node requirements document mandating that IPv6 = > nodes must > support IPsec the goverment has been lead to believe that IPv6 by = > definition has > built-in security. = > = > Regards, > = > Mike Taylor > > = > ----- Original Message ---- > From: Ed Jankiewicz > To: Mike Taylor > Cc: ipv6@ietf.org > Sent: Friday, February 29, 2008 10:22:47 AM > Subject: Re: ipv6 Digest, Vol 46, Issue 33 > > Can you provide a citation to some authority for export restrictions on > IPv6? I have not heard that before and find it surprising (though not > impossible). That would be troubling, because IPsec in and of itself > (and by association IPv6) does not necessarily contain any cryptographic > code, although an implementation might. Also, not all algorithms would > be subject to export control. Nothing in IPv6 or IPsec compels an > implementor to include any restricted cryptographic code. > > I am definitely not a cryptography expert, nor am I an authority on US > export regulations. However, in my day job I deal with IPv6 standards > for US DoD and interact with a lot of vendors. I don't recall this > coming up with any vendors, but if there is a chance this will be an > issue, I need to do some homework. In particular, for DoD use we may > require more advanced algorithms (see RFC 4869 and > http://www.nsa.gov/ia/industry/crypto_suite_b.cfm) and I don't know what > the restrictions on export of that code would be. > > Ed J. > > Mike Taylor wrote: > > > > And while it isn't a surmountable problem > > > > = > > > > 5. We are being forced to treat all of our IPv6 enabled protocols such > > > > as FTP as encryption items by the U.S. export authorities because > > > > the U.S. government thinks they must be since IPv6 "includes > > > > security". It's just plain silly since our IPv6 is no different > > > > than our IPv4 - both get all their security from our IPsec which > > > > is sold separately. But we can't convince them otherwise because it > > > > has been mandated that all IPv6 nodes shall support IPsec. > > > > We can sell our IPv6 code without any trace of IPsec save for a few > > > > lines of interface code that are #ifdef'd out when IPsec isn't = > present > > > > and yet our IPv6 stack and worse yet, all of the socket-layer apps > > > > that support IPv6, are viewed as encryption items. Good grief. > > > > = > > > > Regards, > > > > = > > > > Mike Taylor > > > > = > > > > > R, > > > > > Dow > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > > > _______________________________________________ > > > > > ipv6 mailing list > > > > > ipv6@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > > > > > > > > > End of ipv6 Digest, Vol 46, Issue 33 > > > > > ************************************ > > > > ------------------------------------------------------------------------ > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > = > > -- = Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research = Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com = -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------