From owner-v6ops@ops.ietf.org Sat Aug 1 00:57:12 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECB03A6A6D for ; Sat, 1 Aug 2009 00:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, 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 9Q8us0HQ3pS9 for ; Sat, 1 Aug 2009 00:57:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60A163A6A71 for ; Sat, 1 Aug 2009 00:57:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX9NL-000L58-Kp for v6ops-data0@psg.com; Sat, 01 Aug 2009 07:51:31 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MX9NG-000L40-MU for v6ops@ops.ietf.org; Sat, 01 Aug 2009 07:51:28 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id E934FA0; Sat, 1 Aug 2009 09:51:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E6C7F9F; Sat, 1 Aug 2009 09:51:23 +0200 (CEST) Date: Sat, 1 Aug 2009 09:51:23 +0200 (CEST) From: Mikael Abrahamsson To: "Wes Beebee (wbeebee)" cc: v6ops@ops.ietf.org Subject: RE: in-addr.arpa. in DHCPv6-PD scenario In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 31 Jul 2009, Wes Beebee (wbeebee) wrote: > Are you concerned about reverse-dns for items in the home or in the > internet? I would like for people in the homes to be able to set reverse-dns for their prefix, handle dynamic DNS updates etc. This could be done by the home CPE router, it could also be done elsewhere. The natural point would be the home CPE router somehow being involved since it's involved in the DHCPv6-PD process. > For the home, I would imagine that if the IPv6 CPE router supported a > local DNS server, then that server would also handle PTR queries. Absolutely, but then again, I've had bad experiences with the quality of DNS recursive resolver software in home CPE routers, so perhaps we should try to come up with a more generic approach? Would a "well known address" in the PD delegated prefix work here? PREFIX::53 for instance. This would of course have the problem that if the home CPE didn't support this (didn't allocate this address to itself) then you get in-addr lookup timesouts when hosts on the Internet tries to do this. Should perhaps the DHCPv6-PD request from the client include an option where the client can ask for reverse DNS delegation of the space being PD requested, if it actually supports this? Then a WKA could be used, or the actual IPv6 address of the server wanting to be used could be provided to the DHCPv6 server and the ISP would then have to provide hook into the DNS server to set this CPE router provided IPv6 address (it would also have to be able to set an absolute address and a relative address I guess, since it at the time of the request does not know what prefix it's getting, or perhaps it should be done by a separate PD request after the PD-prefix is already known to the CPE router). I tride to find a mention of how to provide a in-addr.arpa.-server involved in the DHCPv6-PD process but could find none, does this mean that there needs to be an addition to DHCPv6-PD to enable this behaviour? Do people think it's a good idea? I personally like reverse-DNS historically, but when IPv6 hosts can take and leave IPs via SLAAC all the time, does it even make sense to have reverse-DNS? I still think it does. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Mon Aug 3 06:37:42 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF373A6DCF for ; Mon, 3 Aug 2009 06:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.281 X-Spam-Level: X-Spam-Status: No, score=-4.281 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 VPZWKu5WAGeE for ; Mon, 3 Aug 2009 06:37:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F145E3A698E for ; Mon, 3 Aug 2009 06:37:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXxcG-0006PL-IM for v6ops-data0@psg.com; Mon, 03 Aug 2009 13:30:16 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXxcB-0006O0-LD for v6ops@ops.ietf.org; Mon, 03 Aug 2009 13:30:14 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALmDdkqrR7PE/2dsb2JhbAC6C4gpji8FhBiBTw X-IronPort-AV: E=Sophos;i="4.43,314,1246838400"; d="scan'208";a="181040368" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2009 13:30:10 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n73DUAFk005151; Mon, 3 Aug 2009 06:30:10 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n73DU7ir022865; Mon, 3 Aug 2009 13:30:10 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:30:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: in-addr.arpa. in DHCPv6-PD scenario Date: Mon, 3 Aug 2009 09:30:03 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: in-addr.arpa. in DHCPv6-PD scenario Thread-Index: AcoSfOET1hGZsO7TSfCvPap03AQoGwBwNnvg References: From: "Wes Beebee (wbeebee)" To: "Mikael Abrahamsson" Cc: , "Hemant Singh (shemant)" X-OriginalArrivalTime: 03 Aug 2009 13:30:04.0664 (UTC) FILETIME=[82B0E780:01CA143E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=691; t=1249306210; x=1250170210; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20in-addr.arpa.=20in=20DHCPv6-PD=20scenar io |Sender:=20; bh=m6faPwDaiPL+d3eOxFLy3pJEY3nVegaotYWWJLH3BLo=; b=ri4yQNeGtoy7ymaMsD+XysgGpdaFNOdqyMDl12D0oleGaq4MgDEuywgaIy D8JxEj3m7+fo6le0JTX4VhzQroIwezgXqfd6yatErpUDy8V/l32It0oXlUPL iuOGgEqIT9; Authentication-Results: sj-dkim-4; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > Do people think it's a good idea? I personally like reverse-DNS historically, but when IPv6 hosts can take and > leave IPs via SLAAC all the time, does it even make sense to have reverse-DNS? I still think it does. For DHCPv6 clients in the home, you could have the DHCPv6 server in the CPE Router also populate the reverse-DNS tree. For SLAAC clients in the home (the more usual case), you could snoop the NS(DAD) and consult a MAC table of allowed clients and names and then populate the reverse DNS tree. The question for the working group is, is this behavior worthwhile to standardize or should we just expect that vendors will do something reasonable here? - Wes From owner-v6ops@ops.ietf.org Mon Aug 3 07:45:38 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D703C28C1D5 for ; Mon, 3 Aug 2009 07:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 vvBn8FGVooQz for ; Mon, 3 Aug 2009 07:45:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E724328C1D2 for ; Mon, 3 Aug 2009 07:45:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXyjG-000IWQ-Dk for v6ops-data0@psg.com; Mon, 03 Aug 2009 14:41:34 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXyiq-000ISP-Gg for v6ops@ops.ietf.org; Mon, 03 Aug 2009 14:41:16 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsAANuTdkqQ/uCLe2dsb2JhbACaIwEBFiQGoFKIKY42BYQYgU8 X-IronPort-AV: E=Sophos;i="4.43,314,1246838400"; d="scan'208";a="46351279" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2009 14:41:06 +0000 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 n73Ef5ZA003694; Mon, 3 Aug 2009 16:41:05 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n73Ef6CH005807; Mon, 3 Aug 2009 14:41:06 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 16:41:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: in-addr.arpa. in DHCPv6-PD scenario Date: Mon, 3 Aug 2009 16:41:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: in-addr.arpa. in DHCPv6-PD scenario Thread-Index: AcoSfcW69F0e+6SpRJqdKd4nr5hbAABymxbg References: From: "Eric Vyncke (evyncke)" To: "Mikael Abrahamsson" , "Wes Beebee (wbeebee)" Cc: X-OriginalArrivalTime: 03 Aug 2009 14:41:06.0536 (UTC) FILETIME=[6EF6F680:01CA1448] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1016; t=1249310465; x=1250174465; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evyncke@cisco.com; z=From:=20=22Eric=20Vyncke=20(evyncke)=22=20 |Subject:=20RE=3A=20in-addr.arpa.=20in=20DHCPv6-PD=20scenar io |Sender:=20; bh=adMLCuDxq74mKB7++xzHXJGC1zcpSvqfe8+HUcamTJs=; b=HzPzdBkz99p3CJim+09GZMHkuohtP1oKqeWDi03caY0/ep0QLOUyjFHinn xVPDIALiBuNFBp1iLDZ5m7FSz09VSfPbAVTt1ywCcYYeNBIbOyhnAqGzj6ZE MNAF2BZF8E; Authentication-Results: ams-dkim-2; header.From=evyncke@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > On Fri, 31 Jul 2009, Wes Beebee (wbeebee) wrote: >=20 > > Are you concerned about reverse-dns for items in the home or in the=20 > > internet? >=20 > I would like for people in the homes to be able to set=20 > reverse-dns for their prefix, handle dynamic DNS updates etc.=20 > This could be done by the home CPE router, it could also be=20 > done elsewhere. The natural point would be the home CPE=20 > router somehow being involved since it's involved in the=20 > DHCPv6-PD process. A complication is that some ISP (at least in Europe) want to change the = delegated prefix every day (like they change now the IPv4 address every = day). This would then also mean to clean/purge DNS information... ...%<.....%<.......... >=20 > Do people think it's a good idea? I personally like=20 > reverse-DNS historically, but when IPv6 hosts can take and=20 > leave IPs via SLAAC all the time, does it even make sense to=20 > have reverse-DNS? I still think it does. Same feeling here -=E9ric From owner-v6ops@ops.ietf.org Mon Aug 3 08:50:04 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060C03A6A80 for ; Mon, 3 Aug 2009 08:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 23skocJUXMNu for ; Mon, 3 Aug 2009 08:50:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E41CF3A68F9 for ; Mon, 3 Aug 2009 08:50:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXzji-0001pE-Eh for v6ops-data0@psg.com; Mon, 03 Aug 2009 15:46:06 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXzja-0001oT-TL for v6ops@ops.ietf.org; Mon, 03 Aug 2009 15:46:04 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=FI6g9gqqgN1h+cftOZkLfLu1anQYUjy/Y6taETbkWvBHWlvN38ez8HNhO+GhS4M2Ri1lw6XeuZ4ZEQebbimLYad5MRxb63HrqcwtCvEAl7Z/+WKPkgYs0Lc+fn1o1XNM; Received: from [199.212.90.19] (helo=dh19.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXziH-0005z7-Gf; Mon, 03 Aug 2009 15:44:38 +0000 Cc: "Mikael Abrahamsson" , "Wes Beebee (wbeebee)" , Message-Id: <18DC67CB-6EF4-4613-894C-90955B6297C5@hopcount.ca> From: Joe Abley To: "Eric Vyncke (evyncke)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: in-addr.arpa. in DHCPv6-PD scenario Date: Mon, 3 Aug 2009 11:44:37 -0400 References: X-Mailer: Apple Mail (2.935.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3-Aug-2009, at 10:41, Eric Vyncke (evyncke) wrote: > A complication is that some ISP (at least in Europe) want to change > the delegated prefix every day (like they change now the IPv4 > address every day). Why? From owner-v6ops@ops.ietf.org Mon Aug 3 08:52:40 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DCE3A6B2F for ; Mon, 3 Aug 2009 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=-1.979, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 Cjlem8KrEodb for ; Mon, 3 Aug 2009 08:52:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB0873A6AA0 for ; Mon, 3 Aug 2009 08:52:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXzpR-0002pd-Vr for v6ops-data0@psg.com; Mon, 03 Aug 2009 15:52:02 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXzpM-0002p6-HX for v6ops@ops.ietf.org; Mon, 03 Aug 2009 15:51:58 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALukdkqrR7PE/2dsb2JhbAC8KYgpjj8FgjiBYIFP X-IronPort-AV: E=Sophos;i="4.43,315,1246838400"; d="scan'208";a="359364681" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2009 15:51:56 +0000 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 n73Fpt7J016221; Mon, 3 Aug 2009 08:51:55 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n73FpNIq010950; Mon, 3 Aug 2009 15:51:55 GMT Received: from xmb-ams-331.cisco.com ([144.254.231.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 17:51:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: in-addr.arpa. in DHCPv6-PD scenario Date: Mon, 3 Aug 2009 17:51:52 +0200 Message-ID: In-Reply-To: <18DC67CB-6EF4-4613-894C-90955B6297C5@hopcount.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: in-addr.arpa. in DHCPv6-PD scenario Thread-Index: AcoUUiz/s4fZabjhT6yseOHvFmkO2wAAA3/g References: <18DC67CB-6EF4-4613-894C-90955B6297C5@hopcount.ca> From: "Gunter Van de Velde (gvandeve)" To: "Joe Abley" , "Eric Vyncke (evyncke)" Cc: "Mikael Abrahamsson" , "Wes Beebee (wbeebee)" , X-OriginalArrivalTime: 03 Aug 2009 15:51:54.0840 (UTC) FILETIME=[5326B580:01CA1452] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=654; t=1249314715; x=1250178715; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=20=22Gunter=20Van=20de=20Velde=20(gvandeve)=22=20 |Subject:=20RE=3A=20in-addr.arpa.=20in=20DHCPv6-PD=20scenar io |Sender:=20; bh=d+6A0BaCRViOe09ZPUwQNu1GSJMpI5SG62ObWzAcsgA=; b=kJP3eIAXwxgb6w0kuLAH+jMLkEQmY1MteiBGshBx3KtZDsa3pAEOqxu44t 8z4GzuNjDy+/DTVvXObaNyQF1stL8q/YOOp7kq4OoaIHtSaUUs32g5YLw7Tp qHMb7AERfK; Authentication-Results: sj-dkim-4; header.From=gvandeve@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Services differentiation. They ask more money for a fixed address and they want to reuse that business model G/ -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Joe Abley Sent: maandag 3 augustus 2009 17:45 To: Eric Vyncke (evyncke) Cc: Mikael Abrahamsson; Wes Beebee (wbeebee); v6ops@ops.ietf.org Subject: Re: in-addr.arpa. in DHCPv6-PD scenario On 3-Aug-2009, at 10:41, Eric Vyncke (evyncke) wrote: > A complication is that some ISP (at least in Europe) want to change =20 > the delegated prefix every day (like they change now the IPv4 =20 > address every day). Why? From owner-v6ops@ops.ietf.org Mon Aug 3 08:57:23 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4953A6D74 for ; Mon, 3 Aug 2009 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 h+W3rybWMBZY for ; Mon, 3 Aug 2009 08:57:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B17693A69F7 for ; Mon, 3 Aug 2009 08:57:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXztf-0003UA-Qe for v6ops-data0@psg.com; Mon, 03 Aug 2009 15:56:23 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXztW-0003T9-VA for v6ops@ops.ietf.org; Mon, 03 Aug 2009 15:56:21 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=tHbPxhN5ZthptLK7grsTnh0Y5Ql7TeOrqBjLQvSvQmyDoJFDjjbWGNpPl8nVD+2BwcBS09fmbDOMFCE8PYqq7dOspKyiS6uWhrNZfcNf7yKaaObqzXirvqNinpj/T7aj; Received: from [199.212.90.19] (helo=dh19.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MXztU-00062o-0D; Mon, 03 Aug 2009 15:56:12 +0000 Cc: "Eric Vyncke (evyncke)" , "Mikael Abrahamsson" , "Wes Beebee (wbeebee)" , Message-Id: <337DD27B-6A03-4091-964F-55AD36B98FE5@hopcount.ca> From: Joe Abley To: Gunter Van de Velde (gvandeve) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: in-addr.arpa. in DHCPv6-PD scenario Date: Mon, 3 Aug 2009 11:56:11 -0400 References: <18DC67CB-6EF4-4613-894C-90955B6297C5@hopcount.ca> X-Mailer: Apple Mail (2.935.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3-Aug-2009, at 11:51, Gunter Van de Velde (gvandeve) wrote: > Services differentiation. > They ask more money for a fixed address and they want to reuse that > business model I think they should be prepared to find out that it's cheaper and easier for them to change their business model. From jbdfinger@amtelecom.net Mon Aug 3 11:52:44 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF7D28C25F for ; Mon, 3 Aug 2009 11:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.23 X-Spam-Level: X-Spam-Status: No, score=-29.23 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvLcPuEQKbkP for ; Mon, 3 Aug 2009 11:52:38 -0700 (PDT) Received: from aacps.org (unknown [201.250.178.153]) by core3.amsl.com (Postfix) with SMTP id 5EF3C28C242 for ; Mon, 3 Aug 2009 11:52:36 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090803185237.5EF3C28C242@core3.amsl.com> Date: Mon, 3 Aug 2009 11:52:36 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Mon Aug 3 15:26:32 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3833A6EBF for ; Mon, 3 Aug 2009 15:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_BAYES_5x7=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 VhQAV+6zoLjO for ; Mon, 3 Aug 2009 15:26:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2DB33A6D6E for ; Mon, 3 Aug 2009 15:26:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY5uA-000ABv-2Y for v6ops-data0@psg.com; Mon, 03 Aug 2009 22:21:18 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY5u5-000ABT-LK for v6ops@ops.ietf.org; Mon, 03 Aug 2009 22:21:16 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG//dkqrR7MV/2dsb2JhbAC7bIgpjwkFhBiBTw X-IronPort-AV: E=Sophos;i="4.43,316,1246838400"; d="scan'208";a="222852514" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2009 22:21:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n73MLCmc015822; Mon, 3 Aug 2009 15:21:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n73MLCt6016485; Mon, 3 Aug 2009 22:21:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 15:21:12 -0700 Received: from sjc-mbaugher-8713.cisco.com ([10.19.93.36]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 15:21:12 -0700 Cc: IPv6 Operations Message-Id: <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> From: Mark Baugher To: james woodyatt In-Reply-To: <57D79623-D8A1-41E9-9FB8-B5FEBEE91729@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Date: Mon, 3 Aug 2009 15:19:56 -0700 References: <20090727184501.933F83A6CE4@core3.amsl.com> <029CBD08-5A79-44C2-8490-E63AF783E3B7@muada.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com> <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A-453D6A64641B@apple.com> <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com> <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> <440B7E43-76B7-4C18-A93E-DF052280DC41@apple.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-EUMSG-01.mgdnok.nokia.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8-B5FEBEE91729@apple.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Aug 2009 22:21:12.0587 (UTC) FILETIME=[B5740DB0:01CA1488] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=441; t=1249338073; x=1250202073; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20R41=20in=20draft-ietf-v6ops-cpe-simple- security-07 |Sender:=20; bh=jvy9bwjXmdp6khxDK4KiHx02RjB1HA4umZq3KFuG/F8=; b=FCRmZBStc+IsPlk2vFPlFd3ognrPeBcQLrPEA3LBxqKf0qp25JP66wrefx LE37MkU99cTykrw5nId3KK2wfFEBujC/2UR4EdgD+/Axux/DikkUz1i6LszG dbnl2vPu3St26wfpw/s3JfG/XeINWX2uxoGJE15IE8srOooBdtvBQ=; Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 31, 2009, at 4:56 AM, james woodyatt wrote: > I think it should suffice to delete the second sentence from R41 > entirely. It would then read as follows: > > R41: Gateways SHOULD implement a protocol to permit applications to > solicit inbound traffic without advance knowledge of the addresses > of > exterior nodes with which they expect to communicate. Why do we recommend this function for IPv6? Mark From owner-v6ops@ops.ietf.org Mon Aug 3 16:51:07 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B6B3A698F for ; Mon, 3 Aug 2009 16:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_BAYES_5x7=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 PTSux2u-xdT3 for ; Mon, 3 Aug 2009 16:51:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE4D828C156 for ; Mon, 3 Aug 2009 16:51:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY7F3-000KRO-6y for v6ops-data0@psg.com; Mon, 03 Aug 2009 23:46:57 +0000 Received: from [209.85.146.177] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY7Ey-000KQJ-Qo for v6ops@ops.ietf.org; Mon, 03 Aug 2009 23:46:54 +0000 Received: by wa-out-1112.google.com with SMTP id j37so611763waf.9 for ; Mon, 03 Aug 2009 16:46:52 -0700 (PDT) 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=EX87+sTFxIu8UzjqSNvBX7VjIz2cutFOl13YAGDFZUo=; b=ornSqyOyyCh0NAxT3bJBfPuHOy25N5FgiLzIWjAwDfT3w9G8JKTLUoFtp/LGLGeFGY 8iq5yIZtZLcSgYoHpx5hlw1nywi6DKLtmuiMOb68oGkxu4r3M9bLWGvdlMsPJbKERd8q ckZzYviSkRFvn+6ADmKVig3EbrndUY71Wp6Sc= 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=IfmrPd6V/9Uz+k87nBcSTWwKlIxGeSvHjXcRGapextO8wYRAx+otRC48z57jYcxK8O TZMDhd5eYqTQDlSOKl2ebB5T40HQxxEwHrwSaQn7pKirvzKqcJqWgg7DSpr8F7A5Tn+w KEnay5sXvrHv0wiugO+uhLegkzeARFkI4rtBM= Received: by 10.114.81.12 with SMTP id e12mr10163470wab.6.1249343211718; Mon, 03 Aug 2009 16:46:51 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id l28sm11799822waf.19.2009.08.03.16.46.49 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Aug 2009 16:46:51 -0700 (PDT) Message-ID: <4A7776E8.4060706@gmail.com> Date: Tue, 04 Aug 2009 11:46:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Baugher CC: james woodyatt , IPv6 Operations Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 References: <20090727184501.933F83A6CE4@core3.amsl.com> <029CBD08-5A79-44C2-8490-E63AF783E3B7@muada.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com> <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A-453D6A64641B@apple.com> <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com> <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> <440B7E43-76B7-4C18-A93E-DF052280DC41@apple.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-EUMSG-01.mgdnok.nokia.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8-B5FEBEE91729@apple.com> <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> In-Reply-To: <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2009-08-04 10:19, Mark Baugher wrote: > > On Jul 31, 2009, at 4:56 AM, james woodyatt wrote: > >> I think it should suffice to delete the second sentence from R41 >> entirely. It would then read as follows: >> >> R41: Gateways SHOULD implement a protocol to permit applications to >> solicit inbound traffic without advance knowledge of the addresses of >> exterior nodes with which they expect to communicate. > > Why do we recommend this function for IPv6? How else would you deal with a CPE firewall that has default deny for incoming packets? Manual config? Brian From owner-v6ops@ops.ietf.org Mon Aug 3 18:20:17 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67CA28C297 for ; Mon, 3 Aug 2009 18:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.439 X-Spam-Level: X-Spam-Status: No, score=-104.439 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_BAYES_5x7=0.6, 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 Y18gpjwZsz69 for ; Mon, 3 Aug 2009 18:20:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77E1F28C2A9 for ; Mon, 3 Aug 2009 18:20:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY8dM-0005hX-8d for v6ops-data0@psg.com; Tue, 04 Aug 2009 01:16:08 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MY8dH-0005h0-Iz for v6ops@ops.ietf.org; Tue, 04 Aug 2009 01:16:05 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id B16B07016CC0 for ; Mon, 3 Aug 2009 18:16:02 -0700 (PDT) X-AuditID: 11807130-b7bdfae000004bc9-2b-4a778bd2871f Received: from il0602a-dhcp96.apple.com (il0602a-dhcp96.apple.com [17.206.23.224]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 39.0C.19401.2DB877A4; Mon, 3 Aug 2009 18:16:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1074) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 From: james woodyatt In-Reply-To: <4A7776E8.4060706@gmail.com> Date: Mon, 3 Aug 2009 18:16:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0AD2A405-17FE-4EB6-A012-97C18A5D4460@apple.com> References: <20090727184501.933F83A6CE4@core3.amsl.com> <029CBD08-5A79-44C2-8490-E63AF783E3B7@muada.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com> <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A-453D6A64641B@apple.com> <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com> <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> <440B7E43-76B7-4C18-A93E-DF052280DC41@apple.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-EUMSG-01.mgdnok.nokia.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8-B5FEBEE91729@apple.com> <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> <4A7776E8.4060706@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1074) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 3, 2009, at 16:46, Brian E Carpenter wrote: > On 2009-08-04 10:19, Mark Baugher wrote: >> >> On Jul 31, 2009, at 4:56 AM, james woodyatt wrote: >>> >>> I think it should suffice to delete the second sentence from R41 >>> entirely. It would then read as follows: >>> >>> R41: Gateways SHOULD implement a protocol to permit applications to >>> solicit inbound traffic without advance knowledge of the >>> addresses of >>> exterior nodes with which they expect to communicate. >> >> Why do we recommend this function for IPv6? > > How else would you deal with a CPE firewall that has default deny > for incoming packets? Manual config? That may be precisely the point of Mr. Baugher's question. At the IETF 75 social event, I got to talking with Paul Hoffman [VPN Consortium] about this topic. It seemed to me that he was quite seriously suggesting services like are all anyone on the Internet really needs for this purpose. As an individual contributor, such suggestions fill me with a nihilistic despair. As the editor of this draft, however, I take them as seriously as they seem to be offered. Given that we don't have a standards-track protocol we feel comfortable recommending, I'm not sure R41 as currently worded is really any better than making no recommendation at all and telling Internet application developers that they should just wait for portforward.com to get around to supporting IPv6 routers in its PFConfig application. The best argument I have for what I original wrote for R41 is that I think and its PFConfig application are Lovecraftian horrors whose very existence is proof of IETF's deep and abiding hatred of common people. I think we will all go to our graves in shame and dishonor if we don't try to prevent the mass psychic abuse inherent in what exists to facilitate from happening again with IPv6 CPE like it does now for IPv4/NAT CPE. But, that's my personal opinion. I recognize my argument is not very persuasive to a significant fraction of the working group participants. This was why I polled the working group about the option of simply deleting R41 from this draft. Sadly, no consensus seemed to emerge. So, again, I'd like to invite further discussion from all those people who chose to hum for one of the alternatives I presented to the option of removing R41 from the draft. What is it you really want? -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Mon Aug 3 21:08:01 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47963A6F02 for ; Mon, 3 Aug 2009 21:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.395 X-Spam-Level: X-Spam-Status: No, score=-4.395 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 um70Da2Pv6SZ for ; Mon, 3 Aug 2009 21:08:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71C2B3A6405 for ; Mon, 3 Aug 2009 21:08:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYBEk-0005b6-TA for v6ops-data0@psg.com; Tue, 04 Aug 2009 04:02:54 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYBEc-0005Yx-3u for v6ops@ops.ietf.org; Tue, 04 Aug 2009 04:02:50 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAFtPd0qrR7O6/2dsb2JhbACCJi+5TIgpjxkFhBiBTw X-IronPort-AV: E=Sophos;i="4.43,318,1246838400"; d="scan'208,217";a="192194686" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 04 Aug 2009 04:02:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7442iUQ013258; Mon, 3 Aug 2009 21:02:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7442i6e000236; Tue, 4 Aug 2009 04:02:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 21:02:44 -0700 Received: from sjc-mbaugher-8711.cisco.com ([10.19.93.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 21:02:43 -0700 Cc: james woodyatt , IPv6 Operations Message-Id: <3BF326F1-3AF5-4577-8409-6BE2D0D6D320@cisco.com> From: Mark Baugher To: Brian E Carpenter In-Reply-To: <4A7776E8.4060706@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-37-468423593 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Date: Mon, 3 Aug 2009 21:02:43 -0700 References: <20090727184501.933F83A6CE4@core3.amsl.com> <029CBD08-5A79-44C2-8490-E63AF783E3B7@muada.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com> <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A-453D6A64641B@apple.com> <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com> <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> <440B7E43-76B7-4C18-A93E-DF052280DC41@apple.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-EUMSG-01.mgdnok.nokia.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8-B5FEBEE91729@apple.com> <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> <4A7776E8.4060706@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Aug 2009 04:02:43.0935 (UTC) FILETIME=[6B3F9EF0:01CA14B8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3468; t=1249358564; x=1250222564; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20R41=20in=20draft-ietf-v6ops-cpe-simple- security-07 |Sender:=20; bh=sBrZUWEjUC1MhI4yivVxrrzo/Jb0CT9HWqfmT5RyuUk=; b=V6Igmx9I1Pm9D1K0HFSe3Ci89eBQ0fESpDelfahlgTY40vhUeCfn3mdz04 n3LeXao6JFKOIXL2ZthWnoSYrF7+Y7OyV3tKh2f3pBFlL17ftSjObKzzhBxH f4aW1pWCq1; Authentication-Results: sj-dkim-2; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-37-468423593 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 3/08/2009, at 4:46 PM, Brian E Carpenter wrote: > > How else would you deal with a CPE firewall that has default deny > for incoming packets? Manual config? > Manual config can at least be authenticated. Conficker reportedly uses UPnP NAT traversal on IPv4 home networks and could have just as easily used NAT-PMP. So we're recreating this issue in IPv6 unless we authenticate such requests. How much worse off are we with no firewall than with one where practically any piece of malware can open it. Besides that, I understand R15 and R27 to say that these shoulds would allow unsolicited inbound packets directed to an internal address, so long as the packets use TCP or UDP - if I'm reading them correctly. Finally, it's not clear to me who the intended audience is for R41. We don't want every vendor of a CPE to invent their own firewall control solution. It's something that the various standards developing organizations need to consider doing. I'm looking at James' draft as recommendations for CPE vendors, OSS developers, and skilled users. Mark --Apple-Mail-37-468423593 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On 3/08/2009, at = 4:46 PM, Brian E Carpenter wrote:


How else would you deal with a = CPE firewall that has default deny
for incoming packets? Manual = config?


Manual config can at = least be authenticated.  Conficker reportedly uses UPnP NAT = traversal on IPv4 home networks and could have just as easily used = NAT-PMP.  So we're recreating this issue in IPv6 unless we = authenticate such requests.  How much worse off are we with no = firewall than with one where practically any piece of malware can open = it.

Besides that, I understand R15 and R27 to = say that these shoulds would allow unsolicited inbound packets directed = to an internal address, so long as the packets use TCP or UDP - if I'm = reading them correctly.

Finally, it's not clear = to me who the intended audience is for R41.  We don't want every = vendor of a CPE to invent their own firewall control solution. =  It's something that the various standards developing organizations = need to consider doing.  I'm looking at James' draft as = recommendations for CPE vendors, OSS developers, and skilled = users.

Mark

= --Apple-Mail-37-468423593-- From owner-v6ops@ops.ietf.org Tue Aug 4 00:01:15 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6018B3A6F23 for ; Tue, 4 Aug 2009 00:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, 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 HNJr3kHc+AY6 for ; Tue, 4 Aug 2009 00:01:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 953933A677D for ; Tue, 4 Aug 2009 00:01:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYDxD-0003el-9v for v6ops-data0@psg.com; Tue, 04 Aug 2009 06:56:59 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYDx9-0003eP-Do for v6ops@ops.ietf.org; Tue, 04 Aug 2009 06:56:57 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 502DD659; Tue, 4 Aug 2009 08:56:54 +0200 (CEST) To: Mark Baugher Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 MIME-Version: 1.0 Date: Tue, 04 Aug 2009 08:56:54 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: Brian E Carpenter , james woodyatt , IPv6 Operations Organization: Remlab.net In-Reply-To: <3BF326F1-3AF5-4577-8409-6BE2D0D6D320@cisco.com> References: <20090727184501.933F83A6CE4@core3.amsl.com> <029CBD08-5A79-44C2-8490-E63AF783E3B7@muada.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com> <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A-453D6A64641B@apple.com> <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com> <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> <440B7E43-76B7-4C18-A93E-DF052280DC41@apple.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-EUMSG-01.mgdnok.nokia.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8-B5FEBEE91729@apple.com> <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> <4A7776E8.4060706@gmail.com> <3BF326F1-3AF5-4577-8409-6BE2D0D6D320@cisco.com> Message-ID: X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 3 Aug 2009 21:02:43 -0700, Mark Baugher wrote: > Manual config can at least be authenticated. Conficker reportedly > uses UPnP NAT traversal on IPv4 home networks and could have just as > easily used NAT-PMP. So we're recreating this issue in IPv6 unless we > authenticate such requests. How much worse off are we with no > firewall than with one where practically any piece of malware can open > it. That's just NOT TRUE. Typically the trust between your CPE and your computer comes ENTIRELY from the fact that the computer is behind the CPE. If you computer is already infected, then you are already screwed. Certainly the CPE should protect itself from the computer, but it cannot protect the rest of the internal network, especially not the already infected computer. As for UPnP-IGD and NAT-PMP... if Conficker is already behind the CPE, it can use UDP or make outbound connections anyway. The hole punching protocol just makes it more slightly more convenient for the worm. -- Rémi Denis-Courmont From owner-v6ops@ops.ietf.org Tue Aug 4 04:00:12 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329C83A7005 for ; Tue, 4 Aug 2009 04:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, MIME_8BIT_HEADER=0.3, 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 Yt91lmAOlN0v for ; Tue, 4 Aug 2009 04:00:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4AE493A689E for ; Tue, 4 Aug 2009 04:00:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYHeA-0008rX-Cj for v6ops-data0@psg.com; Tue, 04 Aug 2009 10:53:34 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYHe4-0008qp-CH for v6ops@ops.ietf.org; Tue, 04 Aug 2009 10:53:30 +0000 Received: from 202-6-145-242.static.adam.com.au ([202.6.145.242] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1MYHdq-0004gU-Oy; Tue, 04 Aug 2009 20:23:14 +0930 Received: from opy.nosense.org (localhost.localdomain [127.0.0.1]) by opy.nosense.org (Postfix) with SMTP id 3FFBB49298; Tue, 4 Aug 2009 20:23:13 +0930 (CST) Date: Tue, 4 Aug 2009 20:23:13 +0930 From: Mark Smith To: =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont Cc: Mark Baugher , Brian E Carpenter , james woodyatt , IPv6 Operations Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Message-Id: <20090804202313.642d2942.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <20090727184501.933F83A6CE4@core3.amsl.com> <029CBD08-5A79-44C2-8490-E63AF783E3B7@muada.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com> <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A-453D6A64641B@apple.com> <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com> <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> <440B7E43-76B7-4C18-A93E-DF052280DC41@apple.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-EUMSG-01.mgdnok.nokia.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8-B5FEBEE91729@apple.com> <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> <4A7776E8.4060706@gmail.com> <3BF326F1-3AF5-4577-8409-6BE2D0D6D320@cisco.com> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 04 Aug 2009 08:56:54 +0200 R=E9mi Denis-Courmont wrote: >=20 > On Mon, 3 Aug 2009 21:02:43 -0700, Mark Baugher wrot= e: >=20 > > Manual config can at least be authenticated. Conficker reportedly >=20 > > uses UPnP NAT traversal on IPv4 home networks and could have just as >=20 > > easily used NAT-PMP. So we're recreating this issue in IPv6 unless we >=20 > > authenticate such requests. How much worse off are we with no >=20 > > firewall than with one where practically any piece of malware can open >=20 > > it. >=20 >=20 >=20 > That's just NOT TRUE. Typically the trust between your CPE and your >=20 > computer comes ENTIRELY from the fact that the computer is behind the CPE. >=20 > If you computer is already infected, then you are already screwed. >=20 > Certainly the CPE should protect itself from the computer, but it cannot >=20 > protect the rest of the internal network, especially not the already >=20 > infected computer. >=20 >=20 >=20 > As for UPnP-IGD and NAT-PMP... if Conficker is already behind the CPE, it >=20 > can use UDP or make outbound connections anyway. The hole punching protoc= ol >=20 > just makes it more slightly more convenient for the worm. >=20 >=20 Completely agree. Looking at netbooks with wired, wifi, bluetooth, and 3G or Wimax connectivity, or Smartphones with wifi, 3G or Wimax connectivity, the only safe thing to do is to have each host protect itself, because at any time there could be multiple candidate access methods for Internet access (and IEEE 802.21 (described in the recent Internet Protocol Journal) is trying to make which one is currently being used transparent). Even better is to have the applications protect themselves, like ssh does ("If you want something done properly, you need to do it yourself"). From lominack@alphatrust.com Tue Aug 4 08:13:21 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B31428C3C1 for ; Tue, 4 Aug 2009 08:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.224 X-Spam-Level: X-Spam-Status: No, score=-16.224 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqEnLKgePR88 for ; Tue, 4 Aug 2009 08:13:15 -0700 (PDT) Received: from ajaxfire.nl (unknown [189.100.119.119]) by core3.amsl.com (Postfix) with SMTP id 525B328C3DD for ; Tue, 4 Aug 2009 08:13:13 -0700 (PDT) To: Subject: no-reply From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090804151314.525B328C3DD@core3.amsl.com> Date: Tue, 4 Aug 2009 08:13:13 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Tue Aug 4 14:46:03 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899823A709D for ; Tue, 4 Aug 2009 14:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 lYrnRmIPrb+z for ; Tue, 4 Aug 2009 14:46:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 562DC3A70C2 for ; Tue, 4 Aug 2009 14:46:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYRjD-000CIw-75 for v6ops-data0@psg.com; Tue, 04 Aug 2009 21:39:27 +0000 Received: from [194.29.32.54] (helo=dlpdemo.checkpoint.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYRj8-000CIS-R8 for v6ops@ops.ietf.org; Tue, 04 Aug 2009 21:39:25 +0000 Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E5A0C29C002; Wed, 5 Aug 2009 00:39:38 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9EC6F200409; Wed, 5 Aug 2009 00:39:38 +0300 (IDT) X-CheckPoint: {4A78A8D6-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n74LdI3d011563; Wed, 5 Aug 2009 00:39:19 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 5 Aug 2009 00:39:18 +0300 From: Yaron Sheffer To: Mark Smith , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= CC: Mark Baugher , Brian E Carpenter , james woodyatt , IPv6 Operations Date: Wed, 5 Aug 2009 00:39:16 +0300 Subject: RE: R41 in draft-ietf-v6ops-cpe-simple-security-07 Thread-Topic: R41 in draft-ietf-v6ops-cpe-simple-security-07 Thread-Index: AcoU+RUEib3jS7PGSRiw5X8IFUprEQAUg0ag Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D28F@il-ex01.ad.checkpoint.com> References: <20090727184501.933F83A6CE4@core3.amsl.com> <029CBD08-5A79-44C2-8490-E63AF783E3B7@muada.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com> <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A-453D6A64641B@apple.com> <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com> <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> <440B7E43-76B7-4C18-A93E-DF052280DC41@apple.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-EUMSG-01.mgdnok.nokia.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8-B5FEBEE91729@apple.com> <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> <4A7776E8.4060706@gmail.com> <3BF326F1-3AF5-4577-8409-6BE2D0D6D320@cisco.com> <20090804202313.642d2942.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20090804202313.642d2942.ipng@69706e6720323030352d30312d31340a.nosense.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F9_01CA1565.297082C0" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_00F9_01CA1565.297082C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the risk of repeating a banality, "the only safe thing" is defense in depth. We need to both have applications secure themselves, and, where possible, require the CPE to provide additional protection. And I'll second Remi's opinion, a firewall that can be manipulated by malware is better than no firewall at all. Microsoft's native firewall = adds security to the host even though applications can punch holes through = it. Thanks, Yaron > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf > Of Mark Smith > Sent: Tuesday, August 04, 2009 13:53 > To: R=E9mi Denis-Courmont > Cc: Mark Baugher; Brian E Carpenter; james woodyatt; IPv6 Operations > Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 >=20 > On Tue, 04 Aug 2009 08:56:54 +0200 > R=E9mi Denis-Courmont wrote: >=20 > > > > On Mon, 3 Aug 2009 21:02:43 -0700, Mark Baugher > wrote: > > > > > Manual config can at least be authenticated. Conficker reportedly > > > > > uses UPnP NAT traversal on IPv4 home networks and could have just = as > > > > > easily used NAT-PMP. So we're recreating this issue in IPv6 = unless we > > > > > authenticate such requests. How much worse off are we with no > > > > > firewall than with one where practically any piece of malware can = open > > > > > it. > > > > > > > > That's just NOT TRUE. Typically the trust between your CPE and your > > > > computer comes ENTIRELY from the fact that the computer is behind = the > CPE. > > > > If you computer is already infected, then you are already screwed. > > > > Certainly the CPE should protect itself from the computer, but it = cannot > > > > protect the rest of the internal network, especially not the already > > > > infected computer. > > > > > > > > As for UPnP-IGD and NAT-PMP... if Conficker is already behind the = CPE, > it > > > > can use UDP or make outbound connections anyway. The hole punching > protocol > > > > just makes it more slightly more convenient for the worm. > > > > >=20 > Completely agree. >=20 > Looking at netbooks with wired, wifi, bluetooth, and 3G or Wimax > connectivity, or Smartphones with wifi, 3G or Wimax connectivity, the > only safe thing to do is to have each host protect itself, because at > any time there could be multiple candidate access methods for > Internet access (and IEEE 802.21 (described in the recent Internet > Protocol Journal) is trying to make which one is currently being used > transparent). Even better is to have the applications protect > themselves, like ssh does ("If you want something done properly, you > need to do it yourself"). >=20 >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00F9_01CA1565.297082C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNDIxMzkxNlowIwYJKoZIhvcNAQkEMRYEFESYNtu0Xol0 Zy5zxUCNK0M0rhtcMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA EsHd9rZgiMbvoYCoiH9b2r3vOMn5AVLQbp1miyHjSyeCC8G1Kgc1R3xP8vodeaxrJYheynTypqKM gLdRpLrsfSeV/FNlWh6J86sTWyChyGtVTYO79Pf0rs+0U2bGbUG+iCZE5EW0t9Lj/WiDNiGUJ1Uo 8BdDIi8k9KoTn8cwLjba7jwPrwNLIXUjRj5s4m67UfF/Zxf7YPdE+oh0Ju2LYXSgyIZeZbUu954h dYhFu3FmxX47DDCNOYx8qdY2Ho0tTPuBa5WZSaLVJMppHmDYVWvASaGHMz4gGL203fpJ7wwvrE5B 9+j6RKqwyP+rT6dxVEViMEk8CPL3DC6FQZXEmQAAAAAAAA== ------=_NextPart_000_00F9_01CA1565.297082C0-- From owner-v6ops@ops.ietf.org Tue Aug 4 14:59:58 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED4728C43E for ; Tue, 4 Aug 2009 14:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.42 X-Spam-Level: X-Spam-Status: No, score=-4.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 tQxUolMt2gLS for ; Tue, 4 Aug 2009 14:59:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B9FF028C46C for ; Tue, 4 Aug 2009 14:59:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYRzn-000F1b-R7 for v6ops-data0@psg.com; Tue, 04 Aug 2009 21:56:35 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYRzf-000Ezh-8O for v6ops@ops.ietf.org; Tue, 04 Aug 2009 21:56:31 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANFLeEqrR7MV/2dsb2JhbAC8XogpkCAFhBiBUQ X-IronPort-AV: E=Sophos;i="4.43,323,1246838400"; d="scan'208";a="360429684" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2009 21:56:25 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n74LuPnp011827; Tue, 4 Aug 2009 14:56:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n74LuP1g011489; Tue, 4 Aug 2009 21:56:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 14:56:25 -0700 Received: from sjc-mbaugher-8713.cisco.com ([10.19.93.36]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 14:56:24 -0700 Cc: Mark Smith , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , Brian E Carpenter , james woodyatt , IPv6 Operations Message-Id: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> From: Mark Baugher To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D28F@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Date: Tue, 4 Aug 2009 14:55:08 -0700 X-OriginalArrivalTime: 04 Aug 2009 21:56:25.0306 (UTC) FILETIME=[6960BBA0:01CA154E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1968; t=1249422985; x=1250286985; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20R41=20in=20draft-ietf-v6ops-cpe-simple- security-07 |Sender:=20; bh=RYXzrgLtDr4A7P/3R04J6aEk8MK0wvEa2U3fZ/FO9HI=; b=FeaFMe0JFQwjvznwU1yNMSxvNL1DwE6a3uPjypXnLyCQ3suTiAbJDVDcD3 qu6nMqypirJz7u7omqJEnwu4bLxGrSNuTnp9BFAjUFHtROAisP9cUjp9U7fJ OgOOWe4+Ozb4lT+qtiREqYfyNaFiFtYPqKxkNUZXDY4Sr15qJma6s=; Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: References: <20090727184501.933F83A6CE4@core3.amsl.com> <029CBD08-5A79-44C2-8490-E63AF783E3B7@muada.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com> <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A-453D6A64641B@apple.com> <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com> <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> <440B7E43-76B7-4C18-A93E-DF052280DC41@apple.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-EUMSG-01.mgdnok.nokia.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8-B5FEBEE91729@apple.com> <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> <4A7776E8.4060706@gmail.com> <3BF326F1-3AF5-4577-8409-6BE2D0D6D320@cisco.com> <20090804202313.642d2942.ipng@69706e6720323030352d30312d31340a.nosense.org> <7F9A6D26EB51614FBF9F81C0DA4CFE C80133E557D28F@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.935.3) Return-Path: mbaugher@cisco.com X-OriginalArrivalTime: 04 Aug 2009 21:56:24.0954 (UTC) FILETIME=[692B05A0:01CA154E] On Aug 4, 2009, at 2:39 PM, Yaron Sheffer wrote: > And I'll second Remi's opinion, a firewall that can be manipulated by > malware is better than no firewall at all. If we're going to design firewall control for IPv6, whether it be something new like ALD or an obvious extension to what's done for IPv4, I think it should default to authenticated firewall control. In other words, I would not start with standardizing an unauthenticated firewall control mechanisms and assume that others will figure out how to add access controls. Letting malware use UPnP NAT traversal or NAT- PMP as done today is a pretty low standard for a CPE interface that IMHO we should not accept going forward. We'd like the CPE to refuse commands from malware. Mark From owner-v6ops@ops.ietf.org Tue Aug 4 15:05:43 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A686C3A6918 for ; Tue, 4 Aug 2009 15:05:43 -0700 (PDT) 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.576, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 O1fQ4ZZ1tGye for ; Tue, 4 Aug 2009 15:05:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA9AB3A7047 for ; Tue, 4 Aug 2009 15:05:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYS74-000Fwh-6j for v6ops-data0@psg.com; Tue, 04 Aug 2009 22:04:06 +0000 Received: from [194.29.32.54] (helo=dlpdemo.checkpoint.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYS6y-000Fw6-7K for v6ops@ops.ietf.org; Tue, 04 Aug 2009 22:04:03 +0000 Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2B2DE200E09; Wed, 5 Aug 2009 01:04:18 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id CD4EB200409; Wed, 5 Aug 2009 01:04:17 +0300 (IDT) X-CheckPoint: {4A78AE9D-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n74M3w3d016892; Wed, 5 Aug 2009 01:03:58 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 5 Aug 2009 01:03:58 +0300 From: Yaron Sheffer To: Mark Baugher CC: Mark Smith , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , Brian E Carpenter , james woodyatt , IPv6 Operations Date: Wed, 5 Aug 2009 01:03:55 +0300 Subject: RE: R41 in draft-ietf-v6ops-cpe-simple-security-07 Thread-Topic: R41 in draft-ietf-v6ops-cpe-simple-security-07 Thread-Index: AcoVTmtVi/p2VxLRR7+hVRj0nhnTGwAADsAg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D292@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D28F@il-ex01.ad.checkpoint.com> <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> In-Reply-To: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0105_01CA1568.9B01F7E0" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0105_01CA1568.9B01F7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark, My security reflexes tell me that authenticated is better than un-, and = I agree that the protocol MUST support such a mode. But in practice, this protocol will be used by applications, which most likely will store the = auth credentials somewhere. Malware can subvert the applications and/or get directly at the credentials. At which point I'm not sure this is so = secure any more. Thanks, Yaron > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: Wednesday, August 05, 2009 0:55 > To: Yaron Sheffer > Cc: Mark Smith; R=E9mi Denis-Courmont; Brian E Carpenter; james = woodyatt; > IPv6 Operations > Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 >=20 > References: <20090727184501.933F83A6CE4@core3.amsl.com> = <029CBD08-5A79- > 44C2-8490-E63AF783E3B7@muada.com> > = <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com> > <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A- > 453D6A64641B@apple.com> = <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com> > <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> = CC6B5E3A29D1@mbaugher.com> <440B7E43-76B7-4C18-A93E- > DF052280DC41@apple.com> = <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK- > EUMSG-01.mgdnok.nokia.com> F4E89542CEFE@apple.com> = <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK- > EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8- > B5FEBEE91729@apple.com> = <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com> > <4A7776E8.4060706@gmail.com> <3BF326F1-3AF5-4577-8409- > 6BE2D0D6D320@cisco.com> > = <20090804202313.642d2942.ipng@69706e6720323030352d30312d31340a.nosense.or= g > > <7F9A6D26EB51614FBF9F81C0DA4CF! > EC80133E557D28F@il-ex01.ad.checkpoint.com> > X-Mailer: Apple Mail (2.935.3) > Return-Path: mbaugher@cisco.com > X-OriginalArrivalTime: 04 Aug 2009 21:56:24.0954 (UTC) > FILETIME=3D[692B05A0:01CA154E] >=20 >=20 > On Aug 4, 2009, at 2:39 PM, Yaron Sheffer wrote: >=20 > > And I'll second Remi's opinion, a firewall that can be manipulated = by > > malware is better than no firewall at all. >=20 > If we're going to design firewall control for IPv6, whether it be > something new like ALD or an obvious extension to what's done for > IPv4, I think it should default to authenticated firewall control. In > other words, I would not start with standardizing an unauthenticated > firewall control mechanisms and assume that others will figure out how > to add access controls. Letting malware use UPnP NAT traversal or = NAT- > PMP as done today is a pretty low standard for a CPE interface that > IMHO we should not accept going forward. We'd like the CPE to refuse > commands from malware. >=20 > Mark >=20 >=20 > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0105_01CA1568.9B01F7E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNDIyMDM1NVowIwYJKoZIhvcNAQkEMRYEFBT22U3e/PH4 ewjQfmdA2NRQ76ozMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA k8jKsC1BpXmQTBZWzYpqejhELtqrt28BxeqU77/nz+9cGwpe7nwempEERJA27+wXv9DecoFRh6Ji Hl2ZVygZmcGDIE+WUjRlIkQT9yu2dFpI4zJbS0vaclyvuWjzIHX0DS9bIUKdpV47yCMhCVTjaEG0 n7iDg3ymsXkRswLF5gIFSWWjjIwT8LwQtWoX/CRVpfrimsOMOsDLX11JhAWIVTgZgGfkv1d9lzTj /mu/m/A4dTew4YTRuiormIW7F8AYbYz3UZ42RCzmDrck27dpudlVDUWcU/a+qUqwLMTWf9Wni5VN zGSxj2vAE2dS/FlxtXNR7zL5uFtWccYm/DkD/QAAAAAAAA== ------=_NextPart_000_0105_01CA1568.9B01F7E0-- From owner-v6ops@ops.ietf.org Tue Aug 4 15:18:25 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF0D28C3F8 for ; Tue, 4 Aug 2009 15:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08-WhgMBg9ki for ; Tue, 4 Aug 2009 15:18:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AF953A6BBF for ; Tue, 4 Aug 2009 15:18:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYSJB-000HZM-PX for v6ops-data0@psg.com; Tue, 04 Aug 2009 22:16:37 +0000 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYSJ3-000HXY-K0 for v6ops@ops.ietf.org; Tue, 04 Aug 2009 22:16:32 +0000 Received: from [209.97.124.250] ([209.97.124.250]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n74MFcnm039614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Aug 2009 22:15:47 GMT (envelope-from joelja@bogus.com) Message-ID: <4A78B304.6090305@bogus.com> Date: Tue, 04 Aug 2009 15:15:32 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.22 (X11/20090710) MIME-Version: 1.0 To: Mark Baugher CC: Yaron Sheffer , Mark Smith , =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= , Brian E Carpenter , james woodyatt , IPv6 Operations Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 References: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> In-Reply-To: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 04 Aug 2009 22:15:48 +0000 (UTC) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mark Baugher : > Letting malware use UPnP NAT traversal or NAT-PMP as > done today is a pretty low standard for a CPE interface that IMHO we > should not accept going forward. We'd like the CPE to refuse commands > from malware. What's the difference between a user and malware? > Mark > > From owner-v6ops@ops.ietf.org Tue Aug 4 16:00:54 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C331028C14C for ; Tue, 4 Aug 2009 16:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.557 X-Spam-Level: X-Spam-Status: No, score=-104.557 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 GDCGHggHRMxT for ; Tue, 4 Aug 2009 16:00:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DAF903A7078 for ; Tue, 4 Aug 2009 16:00:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYSwt-000NZo-SF for v6ops-data0@psg.com; Tue, 04 Aug 2009 22:57:39 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYSwq-000NYb-6e for v6ops@ops.ietf.org; Tue, 04 Aug 2009 22:57:37 +0000 Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 0AA3E703E137; Tue, 4 Aug 2009 15:57:35 -0700 (PDT) X-AuditID: 11807136-b7b3cae0000059ab-4d-4a78bcde4945 Received: from il0602a-dhcp96.apple.com (il0602a-dhcp96.apple.com [17.206.23.224]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id A2.CD.22955.EDCB87A4; Tue, 4 Aug 2009 15:57:35 -0700 (PDT) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Mime-Version: 1.0 (Apple Message framework v1074) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: james woodyatt In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D292@il-ex01.ad.checkpoint.com> Date: Tue, 4 Aug 2009 15:57:34 -0700 Cc: Mark Baugher , Mark Smith , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , Brian E Carpenter , IPv6 Operations Content-Transfer-Encoding: 7bit Message-Id: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D28F@il-ex01.ad.checkpoint.com> <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D292@il-ex01.ad.checkpoint.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1074) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 4, 2009, at 15:03, Yaron Sheffer wrote: > From: Mark Baugher [mailto:mbaugher@cisco.com] (Sent: Wednesday, > August 05, 2009 0:55) >> On Aug 4, 2009, at 2:39 PM, Yaron Sheffer wrote: >>> >>> And I'll second Remi's opinion, a firewall that can be manipulated >>> by malware is better than no firewall at all. >> >> If we're going to design firewall control for IPv6, whether it be >> something new like ALD or an obvious extension to what's done for >> IPv4, I think it should default to authenticated firewall control. >> [...] > > My security reflexes tell me that authenticated is better than un-, > and I > agree that the protocol MUST support such a mode. But in practice, > this > protocol will be used by applications, which most likely will store > the auth > credentials somewhere. [...] No. The most like scenario is applications soliciting any-source inbound traffic will use techniques like RFC 5389 modulo NAT, and because there is no standard for choosing an exterior filtering regime, applications will then perform filter-state behavior tests and use rendezvous services when the exterior filtering regime isn't endpoint-independent. This will end up costing battery and network resources that would otherwise not be spent if there was a protocol like R41 recommends, but it will work, it will be simple and it won't require any authentication credentials that users may or may not possess, much less remember where they wrote them down. The point of allowing passive listeners to solicit any-source incoming flows with something like ALD has *always* been to make more wasteful techniques like RFC 5389 modulo NAT completely unnecessary. Does this need to be spelled out more clearly in the draft? -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Tue Aug 4 16:47:23 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08C03A7110 for ; Tue, 4 Aug 2009 16:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 BoZJtc3AC3Qc for ; Tue, 4 Aug 2009 16:47:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96CFC3A6920 for ; Tue, 4 Aug 2009 16:47:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYTg9-0003lA-NR for v6ops-data0@psg.com; Tue, 04 Aug 2009 23:44:25 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYTg0-0003jh-5W for v6ops@ops.ietf.org; Tue, 04 Aug 2009 23:44:22 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGNkeEqrR7PD/2dsb2JhbAC8FIgpkBoFhBiBUQ X-IronPort-AV: E=Sophos;i="4.43,324,1246838400"; d="scan'208";a="360491248" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2009 23:44:16 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n74NiFuM026371; Tue, 4 Aug 2009 16:44:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n74NiFCa009946; Tue, 4 Aug 2009 23:44:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 16:44:15 -0700 Received: from sjc-mbaugher-8711.cisco.com ([10.19.93.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 16:44:14 -0700 Cc: Mark Smith , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , Brian E Carpenter , james woodyatt , IPv6 Operations Message-Id: From: Mark Baugher To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D292@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Date: Tue, 4 Aug 2009 16:44:13 -0700 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D28F@il-ex01.ad.checkpoint.com> <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D292@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Aug 2009 23:44:14.0758 (UTC) FILETIME=[7978C460:01CA155D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4188; t=1249429455; x=1250293455; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20R41=20in=20draft-ietf-v6ops-cpe-simple- security-07 |Sender:=20; bh=8QXUzvj74fW/0H7CXBkOBH/9M/fwZbqnoIbI47IW8WQ=; b=br7IcSR9woph5ezaXFaIon2BPD0T/345oLmetfahmQ+tLE2uCgIiDryKVV n5X7qDz98M+aHwnLLMuX1t2gIb4hagdFLlfTDDZx7PZe62Hm/BoQKIJQeYik LRXR0a/Sy4; Authentication-Results: sj-dkim-3; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: hi Yaron On 4/08/2009, at 3:03 PM, Yaron Sheffer wrote: > Hi Mark, > > My security reflexes tell me that authenticated is better than un-, =20= > and I > agree that the protocol MUST support such a mode. But in practice, =20 > this > protocol will be used by applications, which most likely will store =20= > the auth > credentials somewhere. Right. And the application can be running on a platform that has no =20 malware problem, a small potential for malware problems, or very big malware =20 problems. > Malware can subvert the applications and/or get > directly at the credentials. At which point I'm not sure this is so =20= > secure > any more. On a platform that has very big malware problems, like we have today, =20= the use of access controls raises the bar: For the malware to manipulate =20= the firewall, it must get installed on a device that has a credential, and =20= it must be a device from which it can obtain the credential and use it. In other words, just getting installed on a device is not enough; the =20 malware needs to get installed on a device authorized to do firewall control. Furthermore, I would not rule out advances in the state of the art, such as devices that are not prone to malware or new authentication =20 techniques that defeat malware. CAPTCHA is one such technique that is widely =20 reputed to be broken. But I would not rule out novel uses of old methods like CAPTCHA, which might be harder to defeat when run from the network gateway device. Mark > > > Thanks, > Yaron > >> -----Original Message----- >> From: Mark Baugher [mailto:mbaugher@cisco.com] >> Sent: Wednesday, August 05, 2009 0:55 >> To: Yaron Sheffer >> Cc: Mark Smith; R=E9mi Denis-Courmont; Brian E Carpenter; james =20 >> woodyatt; >> IPv6 Operations >> Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 >> >> References: <20090727184501.933F83A6CE4@core3.amsl.com> =20 >> <029CBD08-5A79- >> 44C2-8490-E63AF783E3B7@muada.com> >> = <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C9BA@il-ex01.ad.checkpoint.com=20= >> > >> <200907282136.55466.remi@remlab.net> <35FFC80F-07B3-4CE3-BF7A- >> 453D6A64641B@apple.com> = <114203F8-FFC7-474C-8764-4F87447AB810@cisco.com=20 >> > >> <2C8F9109-C96D-422E-9EEB-6EF22D79EF62@apple.com> > C0F5-4C84-845C- >> CC6B5E3A29D1@mbaugher.com> <440B7E43-76B7-4C18-A93E- >> DF052280DC41@apple.com> =20 >> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK- >> EUMSG-01.mgdnok.nokia.com> > F4E89542CEFE@apple.com> =20 >> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK- >> EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8- >> B5FEBEE91729@apple.com> = <190A532E-35DF-4E97-99D2-9167B9183316@cisco.com=20 >> > >> <4A7776E8.4060706@gmail.com> <3BF326F1-3AF5-4577-8409- >> 6BE2D0D6D320@cisco.com> >> = <20090804202313.642d2942.ipng@69706e6720323030352d30312d31340a.nosense.org= >>> <7F9A6D26EB51614FBF9F81C0DA4CF! >> EC80133E557D28F@il-ex01.ad.checkpoint.com> >> X-Mailer: Apple Mail (2.935.3) >> Return-Path: mbaugher@cisco.com >> X-OriginalArrivalTime: 04 Aug 2009 21:56:24.0954 (UTC) >> FILETIME=3D[692B05A0:01CA154E] >> >> >> On Aug 4, 2009, at 2:39 PM, Yaron Sheffer wrote: >> >>> And I'll second Remi's opinion, a firewall that can be manipulated =20= >>> by >>> malware is better than no firewall at all. >> >> If we're going to design firewall control for IPv6, whether it be >> something new like ALD or an obvious extension to what's done for >> IPv4, I think it should default to authenticated firewall control. =20= >> In >> other words, I would not start with standardizing an unauthenticated >> firewall control mechanisms and assume that others will figure out =20= >> how >> to add access controls. Letting malware use UPnP NAT traversal or =20= >> NAT- >> PMP as done today is a pretty low standard for a CPE interface that >> IMHO we should not accept going forward. We'd like the CPE to refuse >> commands from malware. >> >> Mark >> >> >> Scanned by Check Point Total Security Gateway. From owner-v6ops@ops.ietf.org Tue Aug 4 16:47:29 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E623A7114 for ; Tue, 4 Aug 2009 16:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 PJQJoHu6MdSU for ; Tue, 4 Aug 2009 16:47:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 805953A7110 for ; Tue, 4 Aug 2009 16:47:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYThK-0003yy-Be for v6ops-data0@psg.com; Tue, 04 Aug 2009 23:45:38 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYThG-0003xB-IS for v6ops@ops.ietf.org; Tue, 04 Aug 2009 23:45:36 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI9leEqrR7PD/2dsb2JhbAC8G4gpkBsFhBg X-IronPort-AV: E=Sophos;i="4.43,324,1246838400"; d="scan'208";a="360491980" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2009 23:45:34 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n74NjYb0028014; Tue, 4 Aug 2009 16:45:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n74NjYKV015341; Tue, 4 Aug 2009 23:45:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 16:45:33 -0700 Received: from sjc-mbaugher-8711.cisco.com ([10.19.93.34]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 16:45:33 -0700 Cc: Yaron Sheffer , Mark Smith , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , Brian E Carpenter , james woodyatt , IPv6 Operations Message-Id: <82DF295C-DED2-49E7-85F1-6EED97911EA7@cisco.com> From: Mark Baugher To: Joel Jaeggli In-Reply-To: <4A78B304.6090305@bogus.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Date: Tue, 4 Aug 2009 16:45:32 -0700 References: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> <4A78B304.6090305@bogus.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Aug 2009 23:45:33.0545 (UTC) FILETIME=[A86EB590:01CA155D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=462; t=1249429534; x=1250293534; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20R41=20in=20draft-ietf-v6ops-cpe-simple- security-07 |Sender:=20; bh=HlmwCvyUEXv24UltX4gH5za828LeOkux9uyrOxhAF+g=; b=iztgB97j+mVe5PRFNTeyeXPK1soM4wVkIkNig/ke6nYoAfd5ZAc3KW+Dou mTmh64zor7IRFbw4S7g60cQpDzkFfs9I1mRZ0IYhKRQNO2J7u5JjMWu5Temq Lk8snhYEOb; Authentication-Results: sj-dkim-3; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 4/08/2009, at 3:15 PM, Joel Jaeggli wrote: > Mark Baugher : >> Letting malware use UPnP NAT traversal or NAT-PMP as >> done today is a pretty low standard for a CPE interface that IMHO we >> should not accept going forward. We'd like the CPE to refuse >> commands >> from malware. > > What's the difference between a user and malware? I just posted replied to another note regarding this. Mark > > >> Mark >> >> From jxforces@alexmann.com Tue Aug 4 21:08:18 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E253A69D8 for ; Tue, 4 Aug 2009 21:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.306 X-Spam-Level: X-Spam-Status: No, score=-18.306 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_EQ_MX=0.535, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqXSDNmjc3yn for ; Tue, 4 Aug 2009 21:08:12 -0700 (PDT) Received: from aeromar.com.mx (unknown [121.209.250.156]) by core3.amsl.com (Postfix) with SMTP id 0FFFD3A69BA for ; Tue, 4 Aug 2009 21:08:10 -0700 (PDT) To: Subject: Return mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090805040811.0FFFD3A69BA@core3.amsl.com> Date: Tue, 4 Aug 2009 21:08:10 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Tue Aug 4 23:46:07 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7CBE3A70ED for ; Tue, 4 Aug 2009 23:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, 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 X-E460+WBhWO for ; Tue, 4 Aug 2009 23:46:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBE213A6AF2 for ; Tue, 4 Aug 2009 23:46:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYaCB-000BMA-B2 for v6ops-data0@psg.com; Wed, 05 Aug 2009 06:41:55 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYaC6-000BLO-Vg for v6ops@ops.ietf.org; Wed, 05 Aug 2009 06:41:53 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 09DF8627; Wed, 5 Aug 2009 08:41:50 +0200 (CEST) To: Yaron Sheffer Subject: RE: R41 in draft-ietf-v6ops-cpe-simple-security-07 MIME-Version: 1.0 Date: Wed, 05 Aug 2009 08:41:50 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: Mark Baugher , Mark Smith , Brian E Carpenter , james woodyatt , IPv6 Operations Organization: Remlab.net In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D292@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D28F@il-ex01.ad.checkpoint.com> <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D292@il-ex01.ad.checkpoint.com> Message-ID: X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 5 Aug 2009 01:03:55 +0300, Yaron Sheffer wrote: > Hi Mark, > > My security reflexes tell me that authenticated is better than un-, and I > agree that the protocol MUST support such a mode. But in practice, this > protocol will be used by applications, which most likely will store the > auth > credentials somewhere. Malware can subvert the applications and/or get > directly at the credentials. At which point I'm not sure this is so secure > any more. Supporting authenticated mode, sure. But by definition, this won't work in an unmanaged network... As for more controlled networks, it is questionable whether hosts should be allowed to modify the firewall configuration at all, anyway. -- Rémi Denis-Courmont From owner-v6ops@ops.ietf.org Tue Aug 4 23:46:14 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E1D3A711B for ; Tue, 4 Aug 2009 23:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, 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 rs3RE1tLiEi3 for ; Tue, 4 Aug 2009 23:46:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C6723A6AF2 for ; Tue, 4 Aug 2009 23:46:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYaAa-000B4l-IG for v6ops-data0@psg.com; Wed, 05 Aug 2009 06:40:16 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYaAW-000B42-8N for v6ops@ops.ietf.org; Wed, 05 Aug 2009 06:40:14 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 093B561D; Wed, 5 Aug 2009 08:40:09 +0200 (CEST) To: Mark Baugher Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 MIME-Version: 1.0 Date: Wed, 05 Aug 2009 08:40:09 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: Yaron Sheffer , Mark Smith , Brian E Carpenter , james woodyatt , IPv6 Operations Organization: Remlab.net In-Reply-To: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> References: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> Message-ID: X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 4 Aug 2009 14:55:08 -0700, Mark Baugher wrote: >> And I'll second Remi's opinion, a firewall that can be manipulated by >> malware is better than no firewall at all. > > If we're going to design firewall control for IPv6, whether it be > something new like ALD or an obvious extension to what's done for > IPv4, I think it should default to authenticated firewall control. We must live in different planet. Because on my planet, most people wouldn't know how to authenticate to their firewall. IPv6 is supposed to be at least as easy to configure as IPv4... -- Rémi Denis-Courmont From owner-v6ops@ops.ietf.org Tue Aug 4 23:46:20 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0AE23A711B for ; Tue, 4 Aug 2009 23:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, 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 0NnzTz6muza9 for ; Tue, 4 Aug 2009 23:46:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 01F643A6AF2 for ; Tue, 4 Aug 2009 23:46:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYaEo-000BeQ-FD for v6ops-data0@psg.com; Wed, 05 Aug 2009 06:44:38 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYaEj-000BcY-8V for v6ops@ops.ietf.org; Wed, 05 Aug 2009 06:44:35 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 6AA5162A; Wed, 5 Aug 2009 08:44:32 +0200 (CEST) To: james woodyatt Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 MIME-Version: 1.0 Date: Wed, 05 Aug 2009 08:44:32 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: Yaron Sheffer , Mark Baugher , Mark Smith , Brian E Carpenter , IPv6 Operations Organization: Remlab.net In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D28F@il-ex01.ad.checkpoint.com> <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D292@il-ex01.ad.checkpoint.com> Message-ID: X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 4 Aug 2009 15:57:34 -0700, james woodyatt wrote: > The most like scenario is applications soliciting any-source > inbound traffic will use techniques like RFC 5389 modulo NAT, and > because there is no standard for choosing an exterior filtering > regime, applications will then perform filter-state behavior tests and > use rendezvous services when the exterior filtering regime isn't > endpoint-independent. This will end up costing battery and network > resources that would otherwise not be spent if there was a protocol > like R41 recommends, but it will work, it will be simple and it won't > require any authentication credentials that users may or may not > possess, much less remember where they wrote them down. > > The point of allowing passive listeners to solicit any-source incoming > flows with something like ALD has *always* been to make more wasteful > techniques like RFC 5389 modulo NAT completely unnecessary. Does this > need to be spelled out more clearly in the draft? >From this discussion, I guess so. You might mention that RFC5389 only works for UDP while at it. -- Rémi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Aug 5 06:38:04 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5855B3A6F3D for ; Wed, 5 Aug 2009 06:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.146 X-Spam-Level: X-Spam-Status: No, score=-101.146 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, IP_NOT_FRIENDLY=0.334, 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 Cm2z6zCO95Z7 for ; Wed, 5 Aug 2009 06:38:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D2803A6A9C for ; Wed, 5 Aug 2009 06:38:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYgbc-000GsW-Cv for v6ops-data0@psg.com; Wed, 05 Aug 2009 13:32:36 +0000 Received: from [2001:5a8:4:2290::101] (helo=thrike.conjury.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYgbY-000GqW-4S for v6ops@ops.ietf.org; Wed, 05 Aug 2009 13:32:34 +0000 Received: from localhost (localhost [127.0.0.1]) by thrike.conjury.org (Postfix) with ESMTP id 8814D1A59DC for ; Wed, 5 Aug 2009 06:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at conjury.org Received: from thrike.conjury.org ([127.0.0.1]) by localhost (thrike.conjury.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOkpokPaYVYp for ; Wed, 5 Aug 2009 06:32:31 -0700 (PDT) Received: from [172.16.1.11] (quasit.conjury.org [69.12.155.89]) by thrike.conjury.org (Postfix) with ESMTP id 303A31A59D5 for ; Wed, 5 Aug 2009 06:32:31 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1074) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 From: james woodyatt In-Reply-To: Date: Wed, 5 Aug 2009 06:32:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D28F@il-ex01.ad.checkpoint.com> <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557D292@il-ex01.ad.checkpoint.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1074) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 4, 2009, at 23:44, R=E9mi Denis-Courmont wrote: > On Tue, 4 Aug 2009 15:57:34 -0700, james woodyatt =20 > wrote: >> >> [...] The point of allowing passive listeners to solicit any-source =20= >> incoming flows with something like ALD has *always* been to make =20 >> more wasteful techniques like RFC 5389 modulo NAT completely =20 >> unnecessary. Does this need to be spelled out more clearly in the =20= >> draft? > > =46rom this discussion, I guess so. Sigh. Okay, I'll whip something up. > You might mention that RFC5389 only works for UDP while at it. Section 2 [page 4] seems to disagree. >> The on-the-wire protocol described here is changed only slightly =20 >> from classic STUN. The protocol now runs over TCP in addition to =20 >> UDP. -- james woodyatt member of technical staff, communications engineering From mo.kallioniemi@advanced-connect.net Wed Aug 5 07:46:55 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A02E28C242 for ; Wed, 5 Aug 2009 07:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, 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_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToS5ffKrslGc for ; Wed, 5 Aug 2009 07:46:55 -0700 (PDT) Received: from adsl-155-34-192-81.adsl.iam.net.ma (adsl-155-34-192-81.adsl.iam.net.ma [81.192.34.155]) by core3.amsl.com (Postfix) with SMTP id BDF8028C0E9 for ; Wed, 5 Aug 2009 07:46:50 -0700 (PDT) To: Subject: new mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090805144651.BDF8028C0E9@core3.amsl.com> Date: Wed, 5 Aug 2009 07:46:50 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Wed Aug 5 10:06:51 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4E828C5E8 for ; Wed, 5 Aug 2009 10:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 i306n444xola for ; Wed, 5 Aug 2009 10:06:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05D7D28C5BF for ; Wed, 5 Aug 2009 10:06:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYjrx-0002rJ-RA for v6ops-data0@psg.com; Wed, 05 Aug 2009 17:01:41 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYjrt-0002qG-2a for v6ops@ops.ietf.org; Wed, 05 Aug 2009 17:01:39 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcEADNXeUqrR7O6/2dsb2JhbACCJTC6RIgpkG8FgjeBYYFR X-IronPort-AV: E=Sophos;i="4.43,329,1246838400"; d="scan'208,217";a="181606330" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 05 Aug 2009 17:01:36 +0000 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 n75H1aos029395; Wed, 5 Aug 2009 10:01:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n75H1aEM012227; Wed, 5 Aug 2009 17:01:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 10:01:35 -0700 Received: from sjc-mbaugher-8711.cisco.com ([10.19.93.34]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 10:01:35 -0700 Cc: Yaron Sheffer , Mark Smith , Brian E Carpenter , james woodyatt , IPv6 Operations Message-Id: <907C81FE-998E-4BE1-A9A0-C0410B450CE3@cisco.com> From: Mark Baugher To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-41-601554238 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Date: Wed, 5 Aug 2009 10:01:33 -0700 References: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 05 Aug 2009 17:01:35.0516 (UTC) FILETIME=[63DABDC0:01CA15EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4833; t=1249491696; x=1250355696; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20R41=20in=20draft-ietf-v6ops-cpe-simple- security-07 |Sender:=20; bh=13VrheQ6qMkJST+14PSHrDzLuyHl8NZO7K8h+XwgkPI=; b=l52ulG1g9t261nuVRKudWP22kJfDBSlxS/6rRCa2LSfqAB4tl5XQH/DCuS u66qQBkqCnvVH0wdKSBFiWOCtNSB0nzeqB5LIR/a6IMs49j85+oAEpiW/ecT pWsOC9BksO; Authentication-Results: sj-dkim-2; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-41-601554238 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 4/08/2009, at 11:40 PM, R=E9mi Denis-Courmont wrote: > We must live in different planet. Because on my planet, most people > > wouldn't know how to authenticate to their firewall. IPv6 is =20 > supposed to be > > at least as easy to configure as IPv4... A half dozen years ago, most home network wireless LANs in the US were =20= open. Market surveys that I saw from that time indicated that a lot =20 of people would prefer that their networks be private. Today, home wi-=20= fi networks are mostly private, at least in the US. AFAICT, the vast =20= majority of people who are running their wi-fi networks without =20 privacy do so because that's the way they want to run it. Last week, =20= I heard that a major US service provider is going to ship a wi-fi CPE =20= with wi-fi privacy turned on by default. That's progress as most =20 gateway/router vendors don't do that today because it could result in =20= a lot of service calls given that people can be running WEP, WPA or =20 WPA2 on client devices. I expect to see more providers and vendors =20 ship their wi-fi products with privacy turn on by default, and who =20 therefore expect their customers to authenticate to a wi-fi/router as =20= part of the process. So I think your statement above is shortsighted =20= for at least this reason. There is innovation taking place in home network access controls - WPS =20= is one attempt by vendors to provide usable security in an unmanaged =20 environment. I know of a few other organizations that are designing =20 security into their home networking services and not interpreting =20 "unmanaged" as meaning "insecure". It would be shortsighted to design =20= a firewall control protocol that does not at least have access control =20= as an option. Mark --Apple-Mail-41-601554238 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 4/08/2009, at = 11:40 PM, R=E9mi Denis-Courmont wrote:

We must live in different planet. = Because on my planet, most people

wouldn't know how to = authenticate to their firewall. IPv6 is supposed to be

at least = as easy to configure as IPv4...

A half = dozen years ago, most home network wireless LANs in the US were open. =  Market surveys that I saw from that time indicated that a lot of = people would prefer that their networks be private.  Today, home = wi-fi networks are mostly private, at least in the US.  AFAICT, the = vast majority of people who are running their wi-fi networks without = privacy do so because that's the way they want to run it.  Last = week, I heard that a major US service provider is going to ship a wi-fi = CPE with wi-fi privacy turned on by default.  That's progress as = most gateway/router vendors don't do that today because it could result = in a lot of service calls given that people can be running WEP, WPA or = WPA2 on client devices.  I expect to see more providers and vendors = ship their wi-fi products with privacy turn on by default, and who = therefore expect their customers to authenticate to a wi-fi/router as = part of the process.  So I think your statement above is = shortsighted for at least this reason.

There is = innovation taking place in home network access controls - WPS is one = attempt by vendors to provide usable security in an unmanaged = environment.  I know of a few other organizations that are = designing security into their home networking services and not = interpreting "unmanaged" as meaning "insecure".  It would be = shortsighted to design a firewall control protocol that does not at = least have access control as an = option. 

Mark

= --Apple-Mail-41-601554238-- From owner-v6ops@ops.ietf.org Wed Aug 5 11:10:11 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DEB28C61E for ; Wed, 5 Aug 2009 11:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 QW51cJ2WbNsZ for ; Wed, 5 Aug 2009 11:10:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B53B928C616 for ; Wed, 5 Aug 2009 11:09:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYkr3-000Dm1-Ci for v6ops-data0@psg.com; Wed, 05 Aug 2009 18:04:49 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYkqx-000DlZ-IF for v6ops@ops.ietf.org; Wed, 05 Aug 2009 18:04:47 +0000 Received: from basile.remlab.net (cs27060099.pp.htv.fi [89.27.60.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id 57665EB; Wed, 5 Aug 2009 20:04:42 +0200 (CEST) From: "=?iso-8859-15?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: Mark Baugher Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Date: Wed, 5 Aug 2009 21:04:39 +0300 User-Agent: KMail/1.11.4 (Linux/2.6.30.4; KDE/4.2.4; i686; ; ) Cc: Yaron Sheffer , Mark Smith , Brian E Carpenter , james woodyatt , IPv6 Operations References: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> <907C81FE-998E-4BE1-A9A0-C0410B450CE3@cisco.com> In-Reply-To: <907C81FE-998E-4BE1-A9A0-C0410B450CE3@cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908052104.40762.remi@remlab.net> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le mercredi 5 ao=FBt 2009 20:01:33 Mark Baugher, vous avez =E9crit : > I expect to see more providers and vendors > ship their wi-fi products with privacy turn on by default, and who > therefore expect their customers to authenticate to a wi-fi/router as > part of the process. So I think your statement above is shortsighted > for at least this reason. If the host operating system is authenticated to the CPE at layer-2, why th= e=20 heck should it re-authenticate at layer-3? To me the big problem=20 _specifically_ with UPnP is that any random application can use it and=20 complete non-sense stuff with it like redirect any port to any IP and port. As a counter-example, if I recall correctly, ALD can only redirect ports to= =20 the host that request it, and requires system privileges on the host (as it= =20 runson ICMPv6). > There is innovation taking place in home network access controls - WPS > is one attempt by vendors to provide usable security in an unmanaged > environment. I know of a few other organizations that are designing > security into their home networking services and not interpreting > "unmanaged" as meaning "insecure". It would be shortsighted to design > a firewall control protocol that does not at least have access control > as an option. I already said I am all for having authentication as an option. But=20 reallistically, I doubt it can nor should be enabled by *default* on=20 *unmanaged* networks. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Wed Aug 5 12:16:55 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884B628C63A for ; Wed, 5 Aug 2009 12:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 7R3AFsQIETqp for ; Wed, 5 Aug 2009 12:16:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2345E28C639 for ; Wed, 5 Aug 2009 12:16:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYluo-000ORF-Ms for v6ops-data0@psg.com; Wed, 05 Aug 2009 19:12:46 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MYlui-000OPY-KZ for v6ops@ops.ietf.org; Wed, 05 Aug 2009 19:12:43 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJx2eUqrR7MV/2dsb2JhbAC9EIgpkGwFgjeBYYFR X-IronPort-AV: E=Sophos;i="4.43,330,1246838400"; d="scan'208";a="361172336" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Aug 2009 19:12:40 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n75JCepE024993; Wed, 5 Aug 2009 12:12:40 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n75JCd4D019894; Wed, 5 Aug 2009 19:12:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 12:12:39 -0700 Received: from dhcp-64-101-33-187.cisco.com ([64.101.33.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 12:12:39 -0700 Cc: Yaron Sheffer , Mark Smith , Brian E Carpenter , james woodyatt , IPv6 Operations Message-Id: <66D0F368-8ECE-460D-95C1-63F991C88468@cisco.com> From: Mark Baugher To: =?ISO-8859-1?Q?=22R=E9mi_Denis-Courmont=22?= In-Reply-To: <200908052104.40762.remi@remlab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07 Date: Wed, 5 Aug 2009 12:11:21 -0700 References: <3C35AAD7-D7F7-4E6D-A7E0-C6DA2CF95946@cisco.com> <907C81FE-998E-4BE1-A9A0-C0410B450CE3@cisco.com> <200908052104.40762.remi@remlab.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 05 Aug 2009 19:12:39.0183 (UTC) FILETIME=[B2F719F0:01CA1600] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2047; t=1249499560; x=1250363560; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20R41=20in=20draft-ietf-v6ops-cpe-simple- security-07 |Sender:=20; bh=n0pubF+HkKA0YKXljL/LTICEYehoDac39OVCSx9jrO0=; b=GCujvN3RbPSzr6tsbjsgWWPb60y27AeiweUFnoYkxTYGEM2XJVEawbu5nL xvvydODN61tLISJCf/CDFpVXTTaaBi1fPk0USfyZOfL6wB7kwOVNzP4txmz9 fgJit8xFbySV9K4xIeY8y8t5WvtCa3B1jE0mqW/A2mVIvW7PA6ZgY=; Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I did not say anything about layer 2 or 3 or UPnP. I'm not interested =20= in holding a beauty contest for the various ways to do firewall control. The =20 point I'm trying to make applies to all of them. That being said, we seem to be in agreement for having authentication =20= as an option for any firewall control. I would add that to R41. Mark On Aug 5, 2009, at 11:04 AM, R=E9mi Denis-Courmont wrote: > Le mercredi 5 ao=FBt 2009 20:01:33 Mark Baugher, vous avez =E9crit : >> I expect to see more providers and vendors >> ship their wi-fi products with privacy turn on by default, and who >> therefore expect their customers to authenticate to a wi-fi/router as >> part of the process. So I think your statement above is shortsighted >> for at least this reason. > > If the host operating system is authenticated to the CPE at layer-2, =20= > why the > heck should it re-authenticate at layer-3? To me the big problem > _specifically_ with UPnP is that any random application can use it and > complete non-sense stuff with it like redirect any port to any IP =20 > and port. > > As a counter-example, if I recall correctly, ALD can only redirect =20 > ports to > the host that request it, and requires system privileges on the host =20= > (as it > runson ICMPv6). > >> There is innovation taking place in home network access controls - =20= >> WPS >> is one attempt by vendors to provide usable security in an unmanaged >> environment. I know of a few other organizations that are designing >> security into their home networking services and not interpreting >> "unmanaged" as meaning "insecure". It would be shortsighted to =20 >> design >> a firewall control protocol that does not at least have access =20 >> control >> as an option. > > I already said I am all for having authentication as an option. But > reallistically, I doubt it can nor should be enabled by *default* on > *unmanaged* networks. > > > --=20 > R=E9mi Denis-Courmont > http://www.remlab.net/ > From womanizem0@iristel.net Wed Aug 5 13:50:06 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D83428C61A; Wed, 5 Aug 2009 13:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.488 X-Spam-Level: X-Spam-Status: No, score=-9.488 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPzT9Tr-5wux; Wed, 5 Aug 2009 13:50:05 -0700 (PDT) Received: from cpe-65-189-140-247.columbus.res.rr.com (cpe-65-189-140-247.columbus.res.rr.com [65.189.140.247]) by core3.amsl.com (Postfix) with ESMTP id E5EB93A6BDF; Wed, 5 Aug 2009 13:48:36 -0700 (PDT) Received: from 65.189.140.247 by mail.iristel.com; Wed, 5 Aug 2009 16:48:23 -0500 Message-ID: <000d01ca160e$13164420$6400a8c0@womanizem0> From: v6ops-archive@ietf.org To: Subject: Lose fat painlessly Date: Wed, 5 Aug 2009 16:48:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA160E.13164420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA160E.13164420 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Lose Weight Fast , YOUR Trial offer IS WAITING Try Acai Berry. Acai diet will deliver results and rid you of your unwated weight.   our store =20 =20 Thank You!=20 best regards Veda=20 Purvis ------=_NextPart_000_0007_01CA160E.13164420 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Lose Weight Fast , YOUR Trial offer IS WAITING Try Acai Berry.
Acai diet will deliver results and rid you of your unwated = weight.
 
our= store
Thank You!
best regards Veda=20 Purvis
------=_NextPart_000_0007_01CA160E.13164420-- From vpim-bounces@ietf.org Wed Aug 5 13:50:09 2009 Return-Path: X-Original-To: v6ops-archive@ietf.org Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3AF3A7249 for ; Wed, 5 Aug 2009 13:50:09 -0700 (PDT) Subject: The results of your email commands From: vpim-bounces@ietf.org To: v6ops-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1691315067==" Message-ID: Date: Wed, 05 Aug 2009 13:50:07 -0700 Precedence: bulk X-BeenThere: vpim@ietf.org X-Mailman-Version: 2.1.9 List-Id: Voice Profile for Internet Mail Discussion Archive X-List-Administrivia: yes Sender: vpim-bounces@ietf.org Errors-To: vpim-bounces@ietf.org --===============1691315067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: Acai diet will deliver results and rid you of your unwated weight.   our store =20 =20 Thank You!=20 best regards Veda=20 Purvis - Done. --===============1691315067== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: vpim-request@core3.amsl.com Delivered-To: vpim-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D83428C61A; Wed, 5 Aug 2009 13:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.488 X-Spam-Level: X-Spam-Status: No, score=-9.488 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPzT9Tr-5wux; Wed, 5 Aug 2009 13:50:05 -0700 (PDT) Received: from cpe-65-189-140-247.columbus.res.rr.com (cpe-65-189-140-247.columbus.res.rr.com [65.189.140.247]) by core3.amsl.com (Postfix) with ESMTP id E5EB93A6BDF; Wed, 5 Aug 2009 13:48:36 -0700 (PDT) Received: from 65.189.140.247 by mail.iristel.com; Wed, 5 Aug 2009 16:48:23 -0500 Message-ID: <000d01ca160e$13164420$6400a8c0@womanizem0> From: v6ops-archive@ietf.org To: Subject: Lose fat painlessly Date: Wed, 5 Aug 2009 16:48:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA160E.13164420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA160E.13164420 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Lose Weight Fast , YOUR Trial offer IS WAITING Try Acai Berry. Acai diet will deliver results and rid you of your unwated weight.   our store =20 =20 Thank You!=20 best regards Veda=20 Purvis ------=_NextPart_000_0007_01CA160E.13164420 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Lose Weight Fast , YOUR Trial offer IS WAITING Try Acai Berry.
Acai diet will deliver results and rid you of your unwated = weight.
 
our= store
Thank You!
best regards Veda=20 Purvis
------=_NextPart_000_0007_01CA160E.13164420-- --===============1691315067==-- From epithete34@isp-will.net Fri Aug 7 07:23:31 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F3C3A6D64; Fri, 7 Aug 2009 07:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.714 X-Spam-Level: X-Spam-Status: No, score=-31.714 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hsgu4IHkWWUu; Fri, 7 Aug 2009 07:23:31 -0700 (PDT) Received: from ip-95-222-213-118.unitymediagroup.de (ip-95-222-213-118.unitymediagroup.de [95.222.213.118]) by core3.amsl.com (Postfix) with ESMTP id 9AD283A6E8D; Fri, 7 Aug 2009 07:23:30 -0700 (PDT) Received: from 95.222.213.118 by www.isp-will.net; Fri, 7 Aug 2009 16:23:05 +0100 Date: Fri, 7 Aug 2009 16:23:05 +0100 Message-Id: <9B5H7446987.UBWRAZGKMACR1146@95.222.213.118.isp-will.net> From: v6ops-archive@lists.ietf.org To: v6ops-archive@lists.ietf.org Subject: Fast, easy and SLIM Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Acai Berry will help you lose fat safely and effeciently.
 
Get your trial of Acai Slim Today.
best regards Marsha Salgado
From snagged@it-evangelist.com Fri Aug 7 07:25:37 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6859C3A6CC7 for ; Fri, 7 Aug 2009 07:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.049 X-Spam-Level: X-Spam-Status: No, score=-29.049 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJGa7NSEB3mw for ; Fri, 7 Aug 2009 07:25:36 -0700 (PDT) Received: from dial09.mundivox.com (unknown [189.45.143.105]) by core3.amsl.com (Postfix) with ESMTP id 8EB643A6C29 for ; Fri, 7 Aug 2009 07:25:36 -0700 (PDT) Received: from 189.45.143.105 by aspmx.l.google.com; Fri, 7 Aug 2009 11:24:51 -0300 Date: Fri, 7 Aug 2009 11:24:51 -0300 Message-Id: <8R59OG676361.ZB27SF28TUUE9942@189.45.143.105.it-evangelist.com> From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: Order 1 bottle from home now Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
My new ambition is to help others try what is making me feel great click
 
Acai dissolves unwanted fats
best regards Darby Webb
From owner-v6ops@ops.ietf.org Fri Aug 7 11:31:28 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50AA13A67A1 for ; Fri, 7 Aug 2009 11:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 PZV9Jncl4Ew8 for ; Fri, 7 Aug 2009 11:31:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 376093A6884 for ; Fri, 7 Aug 2009 11:31:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZU7W-0005vs-HN for v6ops-data0@psg.com; Fri, 07 Aug 2009 18:24:50 +0000 Received: from [66.235.125.216] (helo=mail.pronto.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZU7S-0005vW-LI for v6ops@ops.ietf.org; Fri, 07 Aug 2009 18:24:48 +0000 Received: from [192.168.2.177] (boulder.pronto.com [71.33.226.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pronto.com (Postfix) with ESMTP id 5ADE61B90157 for ; Fri, 7 Aug 2009 12:24:45 -0600 (MDT) Subject: IPv6 terminology question From: Daniel Stickney To: IPv6 Operations Content-Type: text/plain Date: Fri, 07 Aug 2009 12:24:43 -0600 Message-Id: <1249669484.19584.28.camel@dstickney2> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.3) Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello all, I am searching for an authoritative answer to my question on IPv6 terminology. I hope this is an appropriate list to ask on, and if it is not I sincerely apologize. So far in my searching I have mostly been finding inconsistency, confusion and guessing. I would like to know if there is an official term for the colon separated 16-bit groups in an IPv6 address. I'm asking here because I believe an answer from members of the IETF is as official as it gets. Personally I've been calling them "words"; as in "an IPv6 address is made up of 8 colon separated words." I see the term "word" used in some other whitepapers and documents published about IPv6 (The TCP/IP Guide, ISBN-13: 9781593270476, p. 379, and also http://documents.iss.net/whitepapers/IPv6.pdf). I also see the term "octet" used, but I believe incorrectly since only an IPv4 address is four 8-bit groups, or octets. I've seen "quartet", "pieces" and "quad" used, and heard guesses at "hexadecitet", "double-octet" and many others. I'm starting to discuss IPv6 in a professional environment with other network engineers and I want to make sure I'm using proper terminology during discussions and for documentation. Plus all the people who I've seen asking this same question can reference this thread for an answer themselves. Thanks in advance for your time, -- Daniel Stickney Operations Manager - Systems and Network Engineer From owner-v6ops@ops.ietf.org Fri Aug 7 12:36:57 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A413A6971 for ; Fri, 7 Aug 2009 12:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 Hx+cABeqvNgk for ; Fri, 7 Aug 2009 12:36:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E79B23A67E7 for ; Fri, 7 Aug 2009 12:36:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZVBS-000GN7-QM for v6ops-data0@psg.com; Fri, 07 Aug 2009 19:32:58 +0000 Received: from [66.235.125.216] (helo=mail.pronto.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZVBO-000GLs-MA for v6ops@ops.ietf.org; Fri, 07 Aug 2009 19:32:57 +0000 Received: from [192.168.2.177] (boulder.pronto.com [71.33.226.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pronto.com (Postfix) with ESMTP id A5A591B901CE for ; Fri, 7 Aug 2009 13:32:53 -0600 (MDT) Subject: RE: IPv6 terminology question From: Daniel Stickney To: IPv6 Operations In-Reply-To: References: <1249669484.19584.28.camel@dstickney2> Content-Type: text/plain Date: Fri, 07 Aug 2009 13:32:52 -0600 Message-Id: <1249673572.19584.44.camel@dstickney2> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.3) Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > Daniel, > > This is defined in RFC4291 "IPv6 Addressing Architecture" Section 2.2 "Text Representation of Addresses". It says: > > 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to > four hexadecimal digits of the eight 16-bit pieces of the address. > Examples: > > ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 > > 2001:DB8:0:0:8:800:200C:417A > > Note that it is not necessary to write the leading zeros in an > individual field, but there must be at least one numeral in every > field (except for the case described in 2.). > > The closest thing to a definition would be to call them "field"s. For example, "an IPv6 address is made up of 8 colon separated fields". > > Bob > > p.s. Suggest in the future, try reading the actual specifications. > I appreciate your input Bob. What term do you all normally use in your discussions with other engineers? I'm fine with "field", just haven't heard or seen anyone else use it yet. Thanks, -- Daniel Stickney Operations Manager - Systems and Network Engineer p.s. I did read that spec, and several others. In my first message when I said 'I've seen "quartet", "pieces" ....', that term "pieces" comes from the 2nd line of the section you quoted. I just thought "pieces" and "field" were generic enough to not be official terms. From lihb@19.cn Fri Aug 7 12:55:57 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFFD3A6403 for ; Fri, 7 Aug 2009 12:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.68 X-Spam-Level: X-Spam-Status: No, score=-19.68 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhG5INpbPKQf for ; Fri, 7 Aug 2009 12:55:51 -0700 (PDT) Received: from amada.co.jp (unknown [189.105.240.72]) by core3.amsl.com (Postfix) with SMTP id E3CE03A6949 for ; Fri, 7 Aug 2009 12:55:48 -0700 (PDT) To: Subject: Return Mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090807195549.E3CE03A6949@core3.amsl.com> Date: Fri, 7 Aug 2009 12:55:48 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Fri Aug 7 13:35:10 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BDE28C101 for ; Fri, 7 Aug 2009 13:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmP+ws3kq2hk for ; Fri, 7 Aug 2009 13:35:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D11CA28C1D7 for ; Fri, 7 Aug 2009 13:34:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZW6S-0001DV-Rc for v6ops-data0@psg.com; Fri, 07 Aug 2009 20:31:52 +0000 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZW6P-0001Cs-7Y for v6ops@ops.ietf.org; Fri, 07 Aug 2009 20:31:50 +0000 Received: from [209.97.124.250] ([209.97.124.250]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n77KVlc6062203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Aug 2009 20:31:48 GMT (envelope-from joelja@bogus.com) Message-ID: <4A7C8F2E.6030606@bogus.com> Date: Fri, 07 Aug 2009 13:31:42 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.22 (X11/20090804) MIME-Version: 1.0 To: Daniel Stickney CC: IPv6 Operations Subject: Re: IPv6 terminology question References: <1249669484.19584.28.camel@dstickney2> <1249673572.19584.44.camel@dstickney2> In-Reply-To: <1249673572.19584.44.camel@dstickney2> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Fri, 07 Aug 2009 20:31:49 +0000 (UTC) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Daniel Stickney wrote: >> Daniel, >> >> This is defined in RFC4291 "IPv6 Addressing Architecture" Section 2.2 "Text Representation of Addresses". It says: >> >> 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to >> four hexadecimal digits of the eight 16-bit pieces of the address. >> Examples: >> >> ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 >> >> 2001:DB8:0:0:8:800:200C:417A >> >> Note that it is not necessary to write the leading zeros in an >> individual field, but there must be at least one numeral in every >> field (except for the case described in 2.). >> >> The closest thing to a definition would be to call them "field"s. For example, "an IPv6 address is made up of 8 colon separated fields". >> >> Bob >> >> p.s. Suggest in the future, try reading the actual specifications. >> > > I appreciate your input Bob. > > What term do you all normally use in your discussions with other > engineers? I'm fine with "field", just haven't heard or seen anyone else > use it yet. A book that I performed a review on covering this subject states: "IPv6 addresses are written in 8 groups of 16 bits each, or 8 groups of 4 hexadecimal numbers separated by colons." - Goralski, "The Illustrated Network" 2009 I'm comfortable with that being sufficiently unambiguous, modula you have to skip to the next paragraph to get abbreviation. > Thanks, > From owner-v6ops@ops.ietf.org Fri Aug 7 15:33:16 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1618B3A6978 for ; Fri, 7 Aug 2009 15:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, 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 3SHG2UXf+FiS for ; Fri, 7 Aug 2009 15:33:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4E3D3A691D for ; Fri, 7 Aug 2009 15:33:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZXuq-000Hex-J5 for v6ops-data0@psg.com; Fri, 07 Aug 2009 22:28:00 +0000 Received: from [129.83.20.191] (helo=smtp-bedford.mitre.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZXum-000HeP-J7; Fri, 07 Aug 2009 22:27:58 +0000 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 n77MRskW018855; Fri, 7 Aug 2009 18:27:54 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n77MRs3t018852; Fri, 7 Aug 2009 18:27:54 -0400 Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 7 Aug 2009 18:27:54 -0400 From: "Dunn, Jeffrey H." To: Joel Jaeggli , Daniel Stickney CC: IPv6 Operations , "Dunn, Jeffrey H." Date: Fri, 7 Aug 2009 18:27:52 -0400 Subject: RE: IPv6 terminology question Thread-Topic: IPv6 terminology question Thread-Index: AcoXoUkLj2CgHqNkSGa0pf6VB+i77gACzDIw Message-ID: <3C6F21684E7C954193E6C7C4573B7627035FC05D1C@IMCMBX1.MITRE.ORG> References: <1249669484.19584.28.camel@dstickney2> <1249673572.19584.44.camel@dstickney2> <4A7C8F2E.6030606@bogus.com> In-Reply-To: <4A7C8F2E.6030606@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Q29sbGVhZ3VlcywNCg0KRnJvbSBhbiBhcHBsaWNhdGlvbnMgcHJvZ3JhbW1pbmcgdmlld3BvaW50 LCB0aGUgMiBvY3RldHMgYmV0d2VlbiB0aGUgY29sb25zIGFyZSBjYWxsZWQgYW4gdW5zaWduZWQg c2hvcnQsIGFzIGluIHRoZSAxNi1iaXQgQyBsYW5ndWFnZSBkYXRhIHN0cnVjdHVyZS4gUkZDIDM0 OTMgc3BlY2lmaWVzIHRoZSBJUHY2IGFkZHJlc3Mgc3RydWN0dXJlIGFzIDE2IHVuc2lnbmVkIDgt Yml0IGludGVnZXJzOyBob3dldmVyLCB0aGlzIGlzIGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50IHRv IDggdW5zaWduZWQgMTYtYml0IGludGVnZXJzLiBBcyBhIHJlc3VsdCwgdGhlIHgncyBpbiB0aGUg bWVzc2FnZSBiZWxvdyBhcmUgdW5zaWduZWQgc2hvcnRzLg0KDQpCZXN0IFJlZ2FyZHMsIA0KwqAg DQpKZWZmcmV5IER1bm4gDQpJbmZvIFN5c3RlbXMgRW5nLiwgTGVhZCANCk1JVFJFIENvcnBvcmF0 aW9uLg0KKDMwMSkgNDQ4LTY5NjUgKG1vYmlsZSkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogb3duZXItdjZvcHNAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItdjZvcHNA b3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBKYWVnZ2xpDQpTZW50OiBGcmlkYXksIEF1 Z3VzdCAwNywgMjAwOSA0OjMyIFBNDQpUbzogRGFuaWVsIFN0aWNrbmV5DQpDYzogSVB2NiBPcGVy YXRpb25zDQpTdWJqZWN0OiBSZTogSVB2NiB0ZXJtaW5vbG9neSBxdWVzdGlvbg0KDQoNCg0KRGFu aWVsIFN0aWNrbmV5IHdyb3RlOg0KPj4gRGFuaWVsLA0KPj4NCj4+IFRoaXMgaXMgZGVmaW5lZCBp biBSRkM0MjkxICJJUHY2IEFkZHJlc3NpbmcgQXJjaGl0ZWN0dXJlIiBTZWN0aW9uIDIuMiAiVGV4 dCBSZXByZXNlbnRhdGlvbiBvZiBBZGRyZXNzZXMiLiAgSXQgc2F5czoNCj4+DQo+PiAgICAxLiBU aGUgcHJlZmVycmVkIGZvcm0gaXMgeDp4Ong6eDp4Ong6eDp4LCB3aGVyZSB0aGUgJ3gncyBhcmUg b25lIHRvDQo+PiAgICAgICBmb3VyIGhleGFkZWNpbWFsIGRpZ2l0cyBvZiB0aGUgZWlnaHQgMTYt Yml0IHBpZWNlcyBvZiB0aGUgYWRkcmVzcy4NCj4+ICAgICAgIEV4YW1wbGVzOg0KPj4NCj4+ICAg ICAgICAgIEFCQ0Q6RUYwMToyMzQ1OjY3ODk6QUJDRDpFRjAxOjIzNDU6Njc4OQ0KPj4NCj4+ICAg ICAgICAgIDIwMDE6REI4OjA6MDo4OjgwMDoyMDBDOjQxN0ENCj4+DQo+PiAgICAgICBOb3RlIHRo YXQgaXQgaXMgbm90IG5lY2Vzc2FyeSB0byB3cml0ZSB0aGUgbGVhZGluZyB6ZXJvcyBpbiBhbg0K Pj4gICAgICAgaW5kaXZpZHVhbCBmaWVsZCwgYnV0IHRoZXJlIG11c3QgYmUgYXQgbGVhc3Qgb25l IG51bWVyYWwgaW4gZXZlcnkNCj4+ICAgICAgIGZpZWxkIChleGNlcHQgZm9yIHRoZSBjYXNlIGRl c2NyaWJlZCBpbiAyLikuDQo+Pg0KPj4gVGhlIGNsb3Nlc3QgdGhpbmcgdG8gYSBkZWZpbml0aW9u IHdvdWxkIGJlIHRvIGNhbGwgdGhlbSAiZmllbGQicy4gIEZvciBleGFtcGxlLCAiYW4gSVB2NiBh ZGRyZXNzIGlzIG1hZGUgdXAgb2YgOCBjb2xvbiBzZXBhcmF0ZWQgZmllbGRzIi4NCj4+DQo+PiBC b2INCj4+DQo+PiBwLnMuIFN1Z2dlc3QgaW4gdGhlIGZ1dHVyZSwgdHJ5IHJlYWRpbmcgdGhlIGFj dHVhbCBzcGVjaWZpY2F0aW9ucy4gIA0KPj4NCj4gDQo+IEkgYXBwcmVjaWF0ZSB5b3VyIGlucHV0 IEJvYi4NCj4gDQo+IFdoYXQgdGVybSBkbyB5b3UgYWxsIG5vcm1hbGx5IHVzZSBpbiB5b3VyIGRp c2N1c3Npb25zIHdpdGggb3RoZXINCj4gZW5naW5lZXJzPyBJJ20gZmluZSB3aXRoICJmaWVsZCIs IGp1c3QgaGF2ZW4ndCBoZWFyZCBvciBzZWVuIGFueW9uZSBlbHNlDQo+IHVzZSBpdCB5ZXQuDQoN CkEgYm9vayB0aGF0IEkgcGVyZm9ybWVkIGEgcmV2aWV3IG9uIGNvdmVyaW5nIHRoaXMgc3ViamVj dCBzdGF0ZXM6DQoNCiJJUHY2IGFkZHJlc3NlcyBhcmUgd3JpdHRlbiBpbiA4IGdyb3VwcyBvZiAx NiBiaXRzIGVhY2gsIG9yIDggZ3JvdXBzIG9mDQo0IGhleGFkZWNpbWFsIG51bWJlcnMgc2VwYXJh dGVkIGJ5IGNvbG9ucy4iIC0gR29yYWxza2ksICJUaGUgSWxsdXN0cmF0ZWQNCk5ldHdvcmsiIDIw MDkNCg0KSSdtIGNvbWZvcnRhYmxlIHdpdGggdGhhdCBiZWluZyBzdWZmaWNpZW50bHkgdW5hbWJp Z3VvdXMsIG1vZHVsYSB5b3UNCmhhdmUgdG8gc2tpcCB0byB0aGUgbmV4dCBwYXJhZ3JhcGggdG8g Z2V0IGFiYnJldmlhdGlvbi4NCg0KPiBUaGFua3MsDQo+IA0KDQo= From owner-v6ops@ops.ietf.org Fri Aug 7 18:25:03 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29A13A69FE for ; Fri, 7 Aug 2009 18:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 BlfcyhTSpSPx for ; Fri, 7 Aug 2009 18:25:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC1683A6B12 for ; Fri, 7 Aug 2009 18:24:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZabR-000F1x-54 for v6ops-data0@psg.com; Sat, 08 Aug 2009 01:20:09 +0000 Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZabM-000F1I-Bl for v6ops@ops.ietf.org; Sat, 08 Aug 2009 01:20:06 +0000 Received: by pzk38 with SMTP id 38so2123030pzk.33 for ; Fri, 07 Aug 2009 18:20:03 -0700 (PDT) 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=HmtqptNdqaS/N3dgnAvJ279TaHoTHG0Jswm2dUcMLmE=; b=CUJDHWEw4ES9NjoA6PoZSwZ0VqvqMCNAJGhO7JjVUmqRKkeQigWQyIzISZvHAjtvum OnY0KEtCNy+iCRL9z7dP0ODuz/fNhODhTyQ4mOdrif0sePoSBs1MWMbY7OlzucjFtsw9 3px5NhZM3/pWnTF3tva3HVedmTcpgMPlSkDZo= 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=wp7Sjsj07cZyTz8UsTOw15ACvvL0+Y/tnmtFW6BP98CkjX955lgGh8m1TPm1X9jSO1 0SQFBUoWZzZ7lAqpqKnlCmB7auCl0jipPnhOM0HHxhdxCDzx+yunYtpSu9Jbzr2e0wYk vhHxmd4KBsC2rtMdO2eUoHB2pNHBgfalpvSNg= Received: by 10.114.173.11 with SMTP id v11mr2432427wae.48.1249694403035; Fri, 07 Aug 2009 18:20:03 -0700 (PDT) Received: from ?10.1.1.4? (118-92-210-226.dsl.dyn.ihug.co.nz [118.92.210.226]) by mx.google.com with ESMTPS id j15sm2704564waf.51.2009.08.07.18.19.59 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Aug 2009 18:20:02 -0700 (PDT) Message-ID: <4A7CD2B6.6050703@gmail.com> Date: Sat, 08 Aug 2009 13:19:50 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Dunn, Jeffrey H." CC: Joel Jaeggli , Daniel Stickney , IPv6 Operations Subject: Re: IPv6 terminology question References: <1249669484.19584.28.camel@dstickney2> <1249673572.19584.44.camel@dstickney2> <4A7C8F2E.6030606@bogus.com> <3C6F21684E7C954193E6C7C4573B7627035FC05D1C@IMCMBX1.MITRE.ORG> In-Reply-To: <3C6F21684E7C954193E6C7C4573B7627035FC05D1C@IMCMBX1.MITRE.ORG> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I don't see why C terminology wins, especially in a reference back to traditional mini-computer architectures. For example, in the most accurate ABNF we have for the presentation format, they're called "hex4" (draft-ietf-sip-ipv6-abnf-fix). As Bob said, they're generically called "fields" in the defining RFC, which seems fine to me. Brian On 2009-08-08 10:27, Dunn, Jeffrey H. wrote: > Colleagues, > > From an applications programming viewpoint, the 2 octets between the colons are called an unsigned short, as in the 16-bit C language data structure. RFC 3493 specifies the IPv6 address structure as 16 unsigned 8-bit integers; however, this is functionally equivalent to 8 unsigned 16-bit integers. As a result, the x's in the message below are unsigned shorts. > > Best Regards, > > Jeffrey Dunn > Info Systems Eng., Lead > MITRE Corporation. > (301) 448-6965 (mobile) > > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Joel Jaeggli > Sent: Friday, August 07, 2009 4:32 PM > To: Daniel Stickney > Cc: IPv6 Operations > Subject: Re: IPv6 terminology question > > > > Daniel Stickney wrote: >>> Daniel, >>> >>> This is defined in RFC4291 "IPv6 Addressing Architecture" Section 2.2 "Text Representation of Addresses". It says: >>> >>> 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to >>> four hexadecimal digits of the eight 16-bit pieces of the address. >>> Examples: >>> >>> ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 >>> >>> 2001:DB8:0:0:8:800:200C:417A >>> >>> Note that it is not necessary to write the leading zeros in an >>> individual field, but there must be at least one numeral in every >>> field (except for the case described in 2.). >>> >>> The closest thing to a definition would be to call them "field"s. For example, "an IPv6 address is made up of 8 colon separated fields". >>> >>> Bob >>> >>> p.s. Suggest in the future, try reading the actual specifications. >>> >> I appreciate your input Bob. >> >> What term do you all normally use in your discussions with other >> engineers? I'm fine with "field", just haven't heard or seen anyone else >> use it yet. > > A book that I performed a review on covering this subject states: > > "IPv6 addresses are written in 8 groups of 16 bits each, or 8 groups of > 4 hexadecimal numbers separated by colons." - Goralski, "The Illustrated > Network" 2009 > > I'm comfortable with that being sufficiently unambiguous, modula you > have to skip to the next paragraph to get abbreviation. > >> Thanks, >> > From trustiestzj047@koln-4db4445d.pool.einsundeins.de Sat Aug 8 18:32:49 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2193A697D; Sat, 8 Aug 2009 18:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.784 X-Spam-Level: X-Spam-Status: No, score=-10.784 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DE=0.35, 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, UNPARSEABLE_RELAY=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCYKC6zSJ+O7; Sat, 8 Aug 2009 18:32:49 -0700 (PDT) Received: from koln-4db4445d.pool.einsundeins.de (koln-4db4445d.pool.einsundeins.de [77.180.68.93]) by core3.amsl.com (Postfix) with ESMTP id 2E5393A6B8B; Sat, 8 Aug 2009 18:32:48 -0700 (PDT) Received: from 77.180.68.93 by ; Sun, 9 Aug 2009 02:32:52 +0100 Date: Sun, 9 Aug 2009 02:32:52 +0100 From: "Rich Gordillo" X-Mailer: The Bat! (v2.00.6) Business Reply-To: doggerelm0@koln-4db4445d.pool.einsundeins.de X-Priority: 3 (Normal) Message-ID: <068692916.12132683191671@koln-4db4445d.pool.einsundeins.de> To: trade-archive@lists.ietf.org Subject: Look Sexy for the Summer MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit You can still have fun and enjoy everyday with acai berry system Next week, I should be on one month into this, give it a try http://maxbewildered.com/ From keith.jenner@alcoa.com.au Sun Aug 9 01:48:21 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA19F3A6999 for ; Sun, 9 Aug 2009 01:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.894 X-Spam-Level: X-Spam-Status: No, score=-16.894 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj4+sIf0RTml for ; Sun, 9 Aug 2009 01:48:21 -0700 (PDT) Received: from ags.gov.au (unknown [122.168.254.109]) by core3.amsl.com (Postfix) with SMTP id 80A523A6824 for ; Sun, 9 Aug 2009 01:48:15 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090809084818.80A523A6824@core3.amsl.com> Date: Sun, 9 Aug 2009 01:48:15 -0700 (PDT) Having trouble viewing this email? Click here to view as a webpage. From jbaeza@alum.mit.edu Sun Aug 9 01:57:08 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C9F3A698C for ; Sun, 9 Aug 2009 01:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.387 X-Spam-Level: X-Spam-Status: No, score=-34.387 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, 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 jfXqq8hzaZAl for ; Sun, 9 Aug 2009 01:57:06 -0700 (PDT) Received: from amscan-uk.co.uk (unknown [41.196.171.184]) by core3.amsl.com (Postfix) with SMTP id 78BE53A67EE for ; Sun, 9 Aug 2009 01:57:04 -0700 (PDT) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090809085705.78BE53A67EE@core3.amsl.com> Date: Sun, 9 Aug 2009 01:57:04 -0700 (PDT) Having trouble viewing this email? Click here to view as a webpage. From owner-v6ops@ops.ietf.org Mon Aug 10 12:20:18 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB123A69B3 for ; Mon, 10 Aug 2009 12:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 j0zt6+gOohBG for ; Mon, 10 Aug 2009 12:20:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF30B3A69F6 for ; Mon, 10 Aug 2009 12:20:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaaJF-0004h1-Aw for v6ops-data0@psg.com; Mon, 10 Aug 2009 19:13:29 +0000 Received: from [209.85.210.185] (helo=mail-yx0-f185.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaaIw-0004eA-Gw for v6ops@ops.ietf.org; Mon, 10 Aug 2009 19:13:16 +0000 Received: by yxe15 with SMTP id 15so4223410yxe.5 for ; Mon, 10 Aug 2009 12:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=DqKotLBbyspdPfSA4Cjd1QsbUejbmeWRIjzMJ/dB144=; b=Aac25mEtlhmzKZ1kcoyW0SQACrIwVXjWpYhwFJ84a8Z70qHeT0L2IwNtvOoZy5I0Z1 T4rxNPgsKnNcLT0zqoryJ5T+EuFN7+kmBO9+j5xTmGp8UV6R1EKYY/CL1vMyYW+/OmXR FAlrzDNQWkrT/1CynZ47Xbd6Y2TyO21hA1WAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=R909WJNkXUiJ0YnlltI+RYMgGmr3gP7naNQzqBlfOwjOm7Y53ZRIGQNzg2rqu2R7dc UddglxL9G+XJEZLVhHsBVBPpBebolGGpDZIcyCSJE2xOH+lm0DsRI9bDYpIRhE8vrJqS IBuC3kRRfjFsBY9UwCnSkC0xvc8l2AFdkoe4o= MIME-Version: 1.0 Reply-To: matt@mattanderson.net Received: by 10.150.192.19 with SMTP id p19mr7214895ybf.294.1249931589633; Mon, 10 Aug 2009 12:13:09 -0700 (PDT) In-Reply-To: <4A7CD2B6.6050703@gmail.com> References: <1249669484.19584.28.camel@dstickney2> <1249673572.19584.44.camel@dstickney2> <4A7C8F2E.6030606@bogus.com> <3C6F21684E7C954193E6C7C4573B7627035FC05D1C@IMCMBX1.MITRE.ORG> <4A7CD2B6.6050703@gmail.com> Date: Mon, 10 Aug 2009 15:13:09 -0400 X-Google-Sender-Auth: 7a670c39619625ef Message-ID: Subject: Re: IPv6 terminology question From: Matt Anderson To: Brian E Carpenter Cc: "Dunn, Jeffrey H." , Joel Jaeggli , Daniel Stickney , IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I find the word "field" too generic, just like "parts" and "sections." In IPv4, we call them "octets," because each is 8 bits wide. In IPv6, I've always thought of them as "hextets," because each is 16 bits wide. "Hextet" may also remind novices that they are working in hexadecimal, not base-10 like they're used to with IPv4. A quick Google search will reveal a number of places where the word "hextet" is used ("hextet ipv6" has 800+ results). I think that most people familiar with IPv6 would understand what "hextet" means, in this context, even if they hadn't heard the word before. On Fri, Aug 7, 2009 at 9:19 PM, Brian E Carpenter wrote: > I don't see why C terminology wins, especially in a reference back to > traditional mini-computer architectures. For example, in the most accurat= e > ABNF we have for the presentation format, they're called "hex4" > (draft-ietf-sip-ipv6-abnf-fix). > > As Bob said, they're generically called "fields" in the defining > RFC, which seems fine to me. > > =A0 =A0Brian > > On 2009-08-08 10:27, Dunn, Jeffrey H. wrote: >> Colleagues, >> >> From an applications programming viewpoint, the 2 octets between the col= ons are called an unsigned short, as in the 16-bit C language data structur= e. RFC 3493 specifies the IPv6 address structure as 16 unsigned 8-bit integ= ers; however, this is functionally equivalent to 8 unsigned 16-bit integers= . As a result, the x's in the message below are unsigned shorts. >> >> Best Regards, >> >> Jeffrey Dunn >> Info Systems Eng., Lead >> MITRE Corporation. >> (301) 448-6965 (mobile) >> >> >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Beha= lf Of Joel Jaeggli >> Sent: Friday, August 07, 2009 4:32 PM >> To: Daniel Stickney >> Cc: IPv6 Operations >> Subject: Re: IPv6 terminology question >> >> >> >> Daniel Stickney wrote: >>>> Daniel, >>>> >>>> This is defined in RFC4291 "IPv6 Addressing Architecture" Section 2.2 = "Text Representation of Addresses". =A0It says: >>>> >>>> =A0 =A01. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are on= e to >>>> =A0 =A0 =A0 four hexadecimal digits of the eight 16-bit pieces of the = address. >>>> =A0 =A0 =A0 Examples: >>>> >>>> =A0 =A0 =A0 =A0 =A0ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 >>>> >>>> =A0 =A0 =A0 =A0 =A02001:DB8:0:0:8:800:200C:417A >>>> >>>> =A0 =A0 =A0 Note that it is not necessary to write the leading zeros i= n an >>>> =A0 =A0 =A0 individual field, but there must be at least one numeral i= n every >>>> =A0 =A0 =A0 field (except for the case described in 2.). >>>> >>>> The closest thing to a definition would be to call them "field"s. =A0F= or example, "an IPv6 address is made up of 8 colon separated fields". >>>> >>>> Bob >>>> >>>> p.s. Suggest in the future, try reading the actual specifications. >>>> >>> I appreciate your input Bob. >>> >>> What term do you all normally use in your discussions with other >>> engineers? I'm fine with "field", just haven't heard or seen anyone els= e >>> use it yet. >> >> A book that I performed a review on covering this subject states: >> >> "IPv6 addresses are written in 8 groups of 16 bits each, or 8 groups of >> 4 hexadecimal numbers separated by colons." - Goralski, "The Illustrated >> Network" 2009 >> >> I'm comfortable with that being sufficiently unambiguous, modula you >> have to skip to the next paragraph to get abbreviation. >> >>> Thanks, >>> >> > > From owner-v6ops@ops.ietf.org Mon Aug 10 12:43:22 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9454428C285 for ; Mon, 10 Aug 2009 12:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 yqBmvpT9JFi8 for ; Mon, 10 Aug 2009 12:43:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DAE1028C262 for ; Mon, 10 Aug 2009 12:43:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaajO-0008N3-CC for v6ops-data0@psg.com; Mon, 10 Aug 2009 19:40:30 +0000 Received: from [2001:41e0:ff00:0:216:3eff:fe00:4] (helo=abaddon.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaajI-0008Lt-VO for v6ops@ops.ietf.org; Mon, 10 Aug 2009 19:40:28 +0000 Received: from [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0] (spaghetti.ch.unfix.org [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 0555E401FEC; Mon, 10 Aug 2009 21:40:22 +0200 (CEST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.2 at abaddon Message-ID: <4A8077A0.4020802@spaghetti.zurich.ibm.com> Date: Mon, 10 Aug 2009 21:40:16 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Daniel Stickney CC: IPv6 Operations , Geoff Huston Subject: Re: IPv6 terminology question References: <1249669484.19584.28.camel@dstickney2> In-Reply-To: <1249669484.19584.28.camel@dstickney2> X-Enigmail-Version: 0.96.0 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig335809488123C6F31CC7C480" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig335809488123C6F31CC7C480 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel Stickney wrote: > Hello all, > =20 > I am searching for an authoritative answer to my question on IPv6 > terminology. I hope this is an appropriate list to ask on, and if it is= > not I sincerely apologize. So far in my searching I have mostly been > finding inconsistency, confusion and guessing. I would like to know if > there is an official term for the colon separated 16-bit groups in an > IPv6 address. I'm asking here because I believe an answer from members > of the IETF is as official as it gets.=20 [..] QUAD That is nothing "official", but that is how I tend to call it. "An IPv6 address contains 8 quads". There are 4 (quad) nibbles (4 bits) making up the 16-bit groups, 8 of which make 128bits. I don't recall where I got that from, but then again over the years I probably have read way too much IPv6 material. Possibly derived from the quad-A (AAAA) record. googling a bit, it seems I am not the only person doing that: http://www.potaroo.net/ispcol/2008-08/ipv6addr.pl Geoff, where did you get this from? :) (As I would not be surprised that I picked it up in one of his many interesting publications ;) Greets, Jeroen --------------enig335809488123C6F31CC7C480 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFKgHegKaooUjM+fCMRAlJbAJ0VZ2Wivby5TpJdgN3rn1yNGiIG0ACeNrEI mOGntJHh92H6k3bpvKpMSAo= =ldth -----END PGP SIGNATURE----- --------------enig335809488123C6F31CC7C480-- From owner-v6ops@ops.ietf.org Mon Aug 10 13:44:43 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043893A6F14 for ; Mon, 10 Aug 2009 13:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ipHr5j+il0pg for ; Mon, 10 Aug 2009 13:44:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0E8328C253 for ; Mon, 10 Aug 2009 13:44:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mabf4-000H1j-AK for v6ops-data0@psg.com; Mon, 10 Aug 2009 20:40:06 +0000 Received: from [2001:dc0:2001:a:4608::60] (helo=asmtp.apnic.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mabex-000H0z-Oc for v6ops@ops.ietf.org; Mon, 10 Aug 2009 20:40:02 +0000 Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 445B811006B; Tue, 11 Aug 2009 06:39:58 +1000 (EST) Cc: Daniel Stickney , IPv6 Operations Message-Id: From: Geoff Huston To: Jeroen Massar In-Reply-To: <4A8077A0.4020802@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: IPv6 terminology question Date: Tue, 11 Aug 2009 06:39:56 +1000 References: <1249669484.19584.28.camel@dstickney2> <4A8077A0.4020802@spaghetti.zurich.ibm.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 11/08/2009, at 5:40 AM, Jeroen Massar wrote: > Daniel Stickney wrote: >> Hello all, >> >> I am searching for an authoritative answer to my question on IPv6 >> terminology. I hope this is an appropriate list to ask on, and if >> it is >> not I sincerely apologize. So far in my searching I have mostly been >> finding inconsistency, confusion and guessing. I would like to know >> if >> there is an official term for the colon separated 16-bit groups in an >> IPv6 address. I'm asking here because I believe an answer from >> members >> of the IETF is as official as it gets. > [..] > > QUAD > > That is nothing "official", but that is how I tend to call it. > "An IPv6 address contains 8 quads". > > There are 4 (quad) nibbles (4 bits) making up the 16-bit groups, 8 of > which make 128bits. > > I don't recall where I got that from, but then again over the years I > probably have read way too much IPv6 material. Possibly derived from > the > quad-A (AAAA) record. googling a bit, it seems I am not the only > person > doing that: http://www.potaroo.net/ispcol/2008-08/ipv6addr.pl > > Geoff, where did you get this from? :) > (As I would not be surprised that I picked it up in one of his many > interesting publications ;) I think I picked it up from the quad-A terminology. I don't recall any other term that has been commonly used to described the IPv6 address notation. Geoff From owner-v6ops@ops.ietf.org Mon Aug 10 19:35:47 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE163A6881 for ; Mon, 10 Aug 2009 19:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 ybEDYsV7zAIJ for ; Mon, 10 Aug 2009 19:35:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5251C3A6BC7 for ; Mon, 10 Aug 2009 19:35:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mah7q-000AkB-3n for v6ops-data0@psg.com; Tue, 11 Aug 2009 02:30:10 +0000 Received: from [202.32.8.193] (helo=tyo201.gate.nec.co.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mah7l-000AiQ-UF for v6ops@ops.ietf.org; Tue, 11 Aug 2009 02:30:07 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n7B2Tv7O003866; Tue, 11 Aug 2009 11:29:57 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id n7B2Tvi29134; Tue, 11 Aug 2009 11:29:57 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id n7B2TvuI004032; Tue, 11 Aug 2009 11:29:57 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n7B2TuQ2032687; Tue, 11 Aug 2009 11:29:56 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n7B2TuQB018867; Tue, 11 Aug 2009 11:29:56 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n7B2TuOB027491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 11:29:56 +0900 Message-ID: <4A80D7A4.4040109@mesh.ad.jp> Date: Tue, 11 Aug 2009 11:29:56 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Brian E Carpenter CC: "Dunn, Jeffrey H." , Joel Jaeggli , Daniel Stickney , IPv6 Operations Subject: Re: IPv6 terminology question References: <1249669484.19584.28.camel@dstickney2> <1249673572.19584.44.camel@dstickney2> <4A7C8F2E.6030606@bogus.com> <3C6F21684E7C954193E6C7C4573B7627035FC05D1C@IMCMBX1.MITRE.ORG> <4A7CD2B6.6050703@gmail.com> In-Reply-To: <4A7CD2B6.6050703@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I think fields is fine. That's what we call it in our ISP. I know some others that do. Quads sound nice too. I just got used to what I saw in RFC4291. Regards, Seiichi Brian E Carpenter wrote: > I don't see why C terminology wins, especially in a reference back to > traditional mini-computer architectures. For example, in the most accurate > ABNF we have for the presentation format, they're called "hex4" > (draft-ietf-sip-ipv6-abnf-fix). > > As Bob said, they're generically called "fields" in the defining > RFC, which seems fine to me. > > Brian > > On 2009-08-08 10:27, Dunn, Jeffrey H. wrote: >> Colleagues, >> >> From an applications programming viewpoint, the 2 octets between the colons are called an unsigned short, as in the 16-bit C language data structure. RFC 3493 specifies the IPv6 address structure as 16 unsigned 8-bit integers; however, this is functionally equivalent to 8 unsigned 16-bit integers. As a result, the x's in the message below are unsigned shorts. >> >> Best Regards, >> >> Jeffrey Dunn >> Info Systems Eng., Lead >> MITRE Corporation. >> (301) 448-6965 (mobile) >> >> >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Joel Jaeggli >> Sent: Friday, August 07, 2009 4:32 PM >> To: Daniel Stickney >> Cc: IPv6 Operations >> Subject: Re: IPv6 terminology question >> >> >> >> Daniel Stickney wrote: >>>> Daniel, >>>> >>>> This is defined in RFC4291 "IPv6 Addressing Architecture" Section 2.2 "Text Representation of Addresses". It says: >>>> >>>> 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to >>>> four hexadecimal digits of the eight 16-bit pieces of the address. >>>> Examples: >>>> >>>> ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 >>>> >>>> 2001:DB8:0:0:8:800:200C:417A >>>> >>>> Note that it is not necessary to write the leading zeros in an >>>> individual field, but there must be at least one numeral in every >>>> field (except for the case described in 2.). >>>> >>>> The closest thing to a definition would be to call them "field"s. For example, "an IPv6 address is made up of 8 colon separated fields". >>>> >>>> Bob >>>> >>>> p.s. Suggest in the future, try reading the actual specifications. >>>> >>> I appreciate your input Bob. >>> >>> What term do you all normally use in your discussions with other >>> engineers? I'm fine with "field", just haven't heard or seen anyone else >>> use it yet. >> A book that I performed a review on covering this subject states: >> >> "IPv6 addresses are written in 8 groups of 16 bits each, or 8 groups of >> 4 hexadecimal numbers separated by colons." - Goralski, "The Illustrated >> Network" 2009 >> >> I'm comfortable with that being sufficiently unambiguous, modula you >> have to skip to the next paragraph to get abbreviation. >> >>> Thanks, >>> > > - -- ================================================ NEC BIGLOBE Ltd. Seiichi Kawamura +81 3 3798 6085 (FAX: +81 3 3798 6029) +81 90 1547 4791 (mobile) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFKgNekcrhTYfxyMkIRAtC6AJ9DVH/DW8NxDt+0FQN7m8e1ozzqCgCgg/E9 CUjYtBtLiLpY5/9Wnem7HRo= =9fOx -----END PGP SIGNATURE----- From Richard.Campbell@BuroHappold.com Mon Aug 10 19:48:20 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317273A68BF; Mon, 10 Aug 2009 19:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulV68YOGKqTq; Mon, 10 Aug 2009 19:48:19 -0700 (PDT) Received: from cluster-d.mailcontroller.altohiway.com (clusterd.mailcontroller.co.uk [213.83.66.161]) by core3.amsl.com (Postfix) with ESMTP id 3292B3A6A1D; Mon, 10 Aug 2009 19:48:18 -0700 (PDT) Received: from rlya6d.mailcontroller.altohiway.com (localhost.localdomain [127.0.0.1]) by rlya6d.mailcontroller.altohiway.com (MailController) with ESMTP id n7B2l9AJ003974; Tue, 11 Aug 2009 03:48:21 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rlya6d.mailcontroller.altohiway.com (MailControl) id n7B2kVVn029675; Tue, 11 Aug 2009 03:46:31 +0100 Received: from ex-fe02.burohappold.com ([77.73.8.93]) by rlya6d-eth0.mailcontroller.altohiway.com (envelope-sender Richard.Campbell@BuroHappold.com) (MIMEDefang) with ESMTP id n7B2kIEw027881; Tue, 11 Aug 2009 03:46:30 +0100 (BST) Received: from ex-be03.burohappold.com ([172.16.254.36]) by ex-fe02.burohappold.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 03:46:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1A2D.E61C9626" Subject: Dear Webmail User!!! Date: Tue, 11 Aug 2009 03:46:16 +0100 Message-ID: <769F37AB357BF741BC9FD2057F2618320AAB8809@ex-be03.burohappold.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dear Webmail User!!! Thread-Index: AcoaLeWbXQ586AGORwCkdSLmmYxrWQ== From: "Richard Campbell" X-OriginalArrivalTime: 11 Aug 2009 02:46:18.0408 (UTC) FILETIME=[E6F3FA80:01CA1A2D] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.195.1.116 To: undisclosed-recipients:; This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1A2D.E61C9626 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Email user, This message is from Administration centre Maintenance Policy verified that= your mailbox exceeds its limit, you will be unable to receive=20 new email, To re-set your SPACE on our database prior to maintain your INBO= X, you must click the link below.=20 =20 Click Here: http://app.formassembly.com/forms/view/108302 =20 =20 (If the link above does not appear clickable or does not open a browser win= dow when you click it, copy it and paste it into=20 your web browser's Location bar.) =20 Thank you for your cooperation. Web Mail Technical Services. This message has been scanned by MailController - www.MailController.altohi= way.com ------_=_NextPart_001_01CA1A2D.E61C9626 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Email user,

This message is from Administration centre Main= tenance Policy verified that your mailbox exceeds its limit, you will be un= able to receive
new email, To re-set your SPACE on our database prior t= o maintain your INBOX, you must click the link below.

 

Click Here: http://app.formassembly.com/forms/view/10830= 2 

 

(If the link above does not appear clickable or= does not open a browser window when you click it, copy it and paste it int= o
your web browser's Location bar.)

 

Thank you for your cooperation.

Web Mail Technical Services.

<= /DIV>

This message has been scanned by MailController.

= ------_=_NextPart_001_01CA1A2D.E61C9626-- From owner-v6ops@ops.ietf.org Tue Aug 11 01:15:45 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A633F3A6FA9 for ; Tue, 11 Aug 2009 01:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.616 X-Spam-Level: * X-Spam-Status: No, score=1.616 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 V0qz0ySkjk0B for ; Tue, 11 Aug 2009 01:15:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A27F13A6FAE for ; Tue, 11 Aug 2009 01:15:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MamRe-0000js-Gv for v6ops-data0@psg.com; Tue, 11 Aug 2009 08:10:58 +0000 Received: from [209.85.220.227] (helo=mail-fx0-f227.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MamRY-0000iw-P1 for v6ops@ops.ietf.org; Tue, 11 Aug 2009 08:10:55 +0000 Received: by fxm27 with SMTP id 27so2821818fxm.11 for ; Tue, 11 Aug 2009 01:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.107.148 with SMTP id b20mr553554fap.62.1249978249770; Tue, 11 Aug 2009 01:10:49 -0700 (PDT) X-Originating-IP: [135.196.66.65] In-Reply-To: References: <1249669484.19584.28.camel@dstickney2> <1249673572.19584.44.camel@dstickney2> <4A7C8F2E.6030606@bogus.com> <3C6F21684E7C954193E6C7C4573B7627035FC05D1C@IMCMBX1.MITRE.ORG> <4A7CD2B6.6050703@gmail.com> Date: Tue, 11 Aug 2009 09:10:49 +0100 X-Google-Sender-Auth: 7e89b524212ba425 Message-ID: Subject: Re: IPv6 terminology question From: Russell Heilling To: matt@mattanderson.net Cc: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: 2009/8/10 Matt Anderson : > I find the word "field" too generic, just like "parts" and "sections." Personally I find 'field' or '16-bit field' to be preferable. > In IPv4, we call them "octets," because each is 8 bits wide. =A0In IPv6, > I've always thought of them as "hextets," because each is 16 bits > wide. =A0"Hextet" may also remind novices that they are working in > hexadecimal, not base-10 like they're used to with IPv4. Actually a 'hextet' would be 6 bits. A 16-bit value would be a 'hexadecatet' which doesn't flow off the tongue quite so well... --=20 IP Network Engineer Tel: +44 (0) 1784 494200 DDI: +44 (0) 1784 713918 Fax: +44 (0) 1784 494201 http://www.viatel.com From lisa.cohen@afs.org Tue Aug 11 02:47:09 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED6F3A7004 for ; Tue, 11 Aug 2009 02:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.287 X-Spam-Level: X-Spam-Status: No, score=-40.287 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhG+cAWeqxhB for ; Tue, 11 Aug 2009 02:47:07 -0700 (PDT) Received: from amig.com (unknown [122.3.187.11]) by core3.amsl.com (Postfix) with SMTP id 7E55B3A6F73 for ; Tue, 11 Aug 2009 02:47:05 -0700 (PDT) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090811094706.7E55B3A6F73@core3.amsl.com> Date: Tue, 11 Aug 2009 02:47:05 -0700 (PDT) Show picture and go to site now! From joanne.thompson@aatkings.com.au Tue Aug 11 03:42:50 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187E83A6C10 for ; Tue, 11 Aug 2009 03:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.296 X-Spam-Level: X-Spam-Status: No, score=-27.296 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, RELAY_IS_221=2.222, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, 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 PF+cdpawZRl4 for ; Tue, 11 Aug 2009 03:42:46 -0700 (PDT) Received: from aacps.org (unknown [221.120.240.7]) by core3.amsl.com (Postfix) with SMTP id 9F8693A6B60 for ; Tue, 11 Aug 2009 03:42:39 -0700 (PDT) To: Subject: Delivery Status Notification 87% 0FF. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090811104242.9F8693A6B60@core3.amsl.com> Date: Tue, 11 Aug 2009 03:42:39 -0700 (PDT) Having trouble viewing this email? Click here to view as a webpage. From owner-v6ops@ops.ietf.org Tue Aug 11 05:30:35 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97443A705A for ; Tue, 11 Aug 2009 05:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 WT1PuXvT2SJ9 for ; Tue, 11 Aug 2009 05:30:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E99AB3A69A2 for ; Tue, 11 Aug 2009 05:30:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaqQV-0007rv-Tu for v6ops-data0@psg.com; Tue, 11 Aug 2009 12:26:03 +0000 Received: from [87.198.142.193] (helo=mail.acquirer.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaqQR-0007r3-6O for v6ops@ops.ietf.org; Tue, 11 Aug 2009 12:26:02 +0000 X-Envelope-To: v6ops@ops.ietf.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n7BCPkgu011631 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 13:25:46 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4A81634A.2010301@inex.ie> Date: Tue, 11 Aug 2009 13:25:46 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Martin Pels CC: Roque Gagliano , v6ops@ops.ietf.org Subject: Re: comments on draft-ietf-v6ops-v6inixp-01.txt References: <4A6EE42A.7020809@inex.ie> <4A702AFD.6040803@inex.ie> <20090730175043.14100900@fizzix> In-Reply-To: <20090730175043.14100900@fizzix> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 30/07/2009 16:50, Martin Pels wrote: > We've had a couple of students research this. Sounds interesting. Are the results of this work publicly available? Nick From dependability5@iq-finder.com Tue Aug 11 12:53:16 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAFC73A7003 for ; Tue, 11 Aug 2009 12:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.157 X-Spam-Level: **** X-Spam-Status: No, score=4.157 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_CHARTER=2.175, 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, FM_SEX_HELODDDD=10.357, FM_SEX_HOSTDDDD=10.357, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, HTML_MESSAGE=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADLTSUB2=1.23, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5bOHjbKG2u8 for ; Tue, 11 Aug 2009 12:53:16 -0700 (PDT) Received: from 66-169-109-143.dhcp.ftwo.tx.charter.com (66-169-109-143.dhcp.ftwo.tx.charter.com [66.169.109.143]) by core3.amsl.com (Postfix) with ESMTP id E0C663A6FFA for ; Tue, 11 Aug 2009 12:53:12 -0700 (PDT) Received: from 66.169.109.143 by mail.iq-finder.com; Tue, 11 Aug 2009 14:51:59 -0600 Message-ID: <000d01ca1abd$307f7140$6400a8c0@dependability5> From: Ramonita Oakes To: Subject: fat to lose and fit tight sexy body to gain, try it free Date: Tue, 11 Aug 2009 14:51:59 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA1ABD.307F7140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA1ABD.307F7140 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If you are unable to see the=20 message below, click here to view. =20 =20 =20 =20 =20 =20 Newsletter =20 =20 =20 =20 =20 Events Lose Weight Fast , YOUR Trial offer IS WAITING Try Acai Berry.   =A0=A0=A0 Move to our site To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web sitePROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.=20 Back to=20 Top =20 =20 Subscribe Unsubscribe Privacy Statement =20 Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these messages from=20 us. Read more about our privacy=20 statement. =20 Copyright(c) 2009, QldqgSystems, Inc.=20 All rights reserved. =A0 ------=_NextPart_000_0007_01CA1ABD.307F7140 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
If you are unable to se= e the=20 message below, click here to view.

Events<= /P>

Lose Weight Fast , YOUR Trial offer IS WAITING Try Ac= ai Berry.
&nb= sp;
=A0=A0=A0 Move to our site


To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web site

PROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.
Back = to=20 Top

Subscribe Unsubscribe Privacy Statement
Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these message= s from=20 us. Read more about our privacy=20 statement.
Copyright(c) 2009, QldqgSystems, In= c.=20 All rights reserved.
=A0
------=_NextPart_000_0007_01CA1ABD.307F7140-- From nancy_mabelb@ahni.com Tue Aug 11 19:56:16 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32113A699C for ; Tue, 11 Aug 2009 19:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -52.68 X-Spam-Level: X-Spam-Status: No, score=-52.68 tagged_above=-999 required=5 tests=[AWL=34.701, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz41jJNYmDqB for ; Tue, 11 Aug 2009 19:56:16 -0700 (PDT) Received: from agor.net (unknown [190.174.137.178]) by core3.amsl.com (Postfix) with SMTP id 92AD43A67A3 for ; Tue, 11 Aug 2009 19:56:13 -0700 (PDT) To: Subject: Delivery Status Notification (Failure) 315$-884$ per work day. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090812025614.92AD43A67A3@core3.amsl.com> Date: Tue, 11 Aug 2009 19:56:13 -0700 (PDT) Our company(WA Surveys) is proud to inform you that we now have one secret-shopper position available.
This is a part time position as it doesn't take more then one hour to evaluate a store.
Your commission for each evaluation is $100 and you can receive assignments on daily basis.

If you are interested in working as a secret shopper for our company you can request more information at mossberenicemoonnaa@gmail.com
Thank you,
WA Surveys Inc.
From servingsl162@ipuku.com Tue Aug 11 20:14:54 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B966E3A67A3; Tue, 11 Aug 2009 20:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.419 X-Spam-Level: X-Spam-Status: No, score=-11.419 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_CHELLO_NL=3.595, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqdJoe37+Oly; Tue, 11 Aug 2009 20:14:53 -0700 (PDT) Received: from e223129.upc-e.chello.nl (e223129.upc-e.chello.nl [213.93.223.129]) by core3.amsl.com (Postfix) with ESMTP id 7BF923A685C; Tue, 11 Aug 2009 20:13:52 -0700 (PDT) Received: from 213.93.223.129 by ipuku.com with smtp IFJJ4W3061; Wed, 12 Aug 2009 05:12:36 +0100 Message-ID: <000d01ca1afa$bdaf2a00$6400a8c0@servingsl162> From: Arno Christiansen To: Subject: Make the fat disappear Date: Wed, 12 Aug 2009 05:12:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA1AFA.BDAF2A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA1AFA.BDAF2A00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If you are unable to see the=20 message below, click here to view. =20 =20 =20 =20 =20 =20 Newsletter =20 =20 =20 =20 =20 Events Acai Berry has helped millions in staying fit and healthy   =A0=A0=A0 Take a step to enter To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web sitePROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.=20 Back to=20 Top =20 =20 Subscribe Unsubscribe Privacy Statement =20 Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these messages from=20 us. Read more about our privacy=20 statement. =20 Copyright(c) 2009, QqrxnhkSystems, Inc.=20 All rights reserved. =A0 ------=_NextPart_000_0007_01CA1AFA.BDAF2A00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
If you are unable to se= e the=20 message below, click here to view.

Events<= /P>

Acai Berry has helped millions in staying fit and heal= thy
&nb= sp;
=A0=A0=A0 Take a step to enter


To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web site

PROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.
Back = to=20 Top

Subscribe Unsubscribe Privacy Statement
Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these message= s from=20 us. Read more about our privacy=20 statement.
Copyright(c) 2009, QqrxnhkSystems, = Inc.=20 All rights reserved.
=A0
------=_NextPart_000_0007_01CA1AFA.BDAF2A00-- From vpim-bounces@ietf.org Tue Aug 11 20:14:56 2009 Return-Path: X-Original-To: v6ops-archive@ietf.org Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42113A69ED for ; Tue, 11 Aug 2009 20:14:56 -0700 (PDT) Subject: The results of your email commands From: vpim-bounces@ietf.org To: v6ops-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1774759616==" Message-ID: Date: Tue, 11 Aug 2009 20:14:55 -0700 Precedence: bulk X-BeenThere: vpim@ietf.org X-Mailman-Version: 2.1.9 List-Id: Voice Profile for Internet Mail Discussion Archive X-List-Administrivia: yes Sender: vpim-bounces@ietf.org Errors-To: vpim-bounces@ietf.org --===============1774759616== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: message below, click here to view. =20 =20 =20 =20 =20 =20 Newsletter =20 =20 =20 =20 =20 Events Acai Berry has helped millions in staying fit and healthy   =A0=A0=A0 Take a step to enter To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web sitePROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= - Ignored: ces,=20 please visit our Subscription Center.=20 Back to=20 Top =20 =20 Subscribe Unsubscribe Privacy Statement =20 Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these messages from=20 us. Read more about our privacy=20 statement. =20 Copyright(c) 2009, QqrxnhkSystems, Inc.=20 All rights reserved. =A0 - Done. --===============1774759616== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: vpim-request@core3.amsl.com Delivered-To: vpim-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B966E3A67A3; Tue, 11 Aug 2009 20:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.419 X-Spam-Level: X-Spam-Status: No, score=-11.419 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_CHELLO_NL=3.595, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqdJoe37+Oly; Tue, 11 Aug 2009 20:14:53 -0700 (PDT) Received: from e223129.upc-e.chello.nl (e223129.upc-e.chello.nl [213.93.223.129]) by core3.amsl.com (Postfix) with ESMTP id 7BF923A685C; Tue, 11 Aug 2009 20:13:52 -0700 (PDT) Received: from 213.93.223.129 by ipuku.com with smtp IFJJ4W3061; Wed, 12 Aug 2009 05:12:36 +0100 Message-ID: <000d01ca1afa$bdaf2a00$6400a8c0@servingsl162> From: Arno Christiansen To: Subject: Make the fat disappear Date: Wed, 12 Aug 2009 05:12:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA1AFA.BDAF2A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA1AFA.BDAF2A00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If you are unable to see the=20 message below, click here to view. =20 =20 =20 =20 =20 =20 Newsletter =20 =20 =20 =20 =20 Events Acai Berry has helped millions in staying fit and healthy   =A0=A0=A0 Take a step to enter To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web sitePROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.=20 Back to=20 Top =20 =20 Subscribe Unsubscribe Privacy Statement =20 Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these messages from=20 us. Read more about our privacy=20 statement. =20 Copyright(c) 2009, QqrxnhkSystems, Inc.=20 All rights reserved. =A0 ------=_NextPart_000_0007_01CA1AFA.BDAF2A00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
If you are unable to se= e the=20 message below, click here to view.

Events<= /P>

Acai Berry has helped millions in staying fit and heal= thy
&nb= sp;
=A0=A0=A0 Take a step to enter


To=20 submit feedback about our Professionals Community, complete the= =20 feedback form at: our web site

PROFILE=20 AND SUBSCRIPTIONS To=20 modify your profile, email address, subscriptions, and preferen= ces,=20 please visit our Subscription Center.
Back = to=20 Top

Subscribe Unsubscribe Privacy Statement
Subscribe to recieve emails and=20 newsletters from us. Or modify your profile, subscriptions, and=20 preferences if you're already our customer. To no longer receives these message= s from=20 us. Read more about our privacy=20 statement.
Copyright(c) 2009, QqrxnhkSystems, = Inc.=20 All rights reserved.
=A0
------=_NextPart_000_0007_01CA1AFA.BDAF2A00-- --===============1774759616==-- From lynell.tufferyn@ajpark.com Tue Aug 11 22:52:56 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1743A6AE1 for ; Tue, 11 Aug 2009 22:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.235 X-Spam-Level: X-Spam-Status: No, score=-86.235 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, 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 6aOXBLDXIBJ7 for ; Tue, 11 Aug 2009 22:52:55 -0700 (PDT) Received: from strasszer.szivarvanynet.hu (strasszer.szivarvanynet.hu [212.92.15.193]) by core3.amsl.com (Postfix) with SMTP id 2E5B93A6AB9 for ; Tue, 11 Aug 2009 22:52:52 -0700 (PDT) To: Subject: Dear v6ops-archive, we have position for you 322$-700$/day. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090812055254.2E5B93A6AB9@core3.amsl.com> Date: Tue, 11 Aug 2009 22:52:52 -0700 (PDT) Our company(WA Surveys) is proud to inform you that we now have one secret-shopper position available.
This is a part time position as it doesn't take more then one hour to evaluate a store.
Your commission for each evaluation is $100 and you can receive assignments on daily basis.

If you are interested in working as a secret shopper for our company you can request more information at billingsbriannetastyykn@gmail.com
Thank you,
WA Surveys Inc.
From nlgp@alphasintered.com Fri Aug 14 08:20:19 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99DA43A69CB for ; Fri, 14 Aug 2009 08:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.964 X-Spam-Level: X-Spam-Status: No, score=-18.964 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, 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_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe-OtiCMTMzv for ; Fri, 14 Aug 2009 08:20:13 -0700 (PDT) Received: from alpicom.ch (unknown [122.169.184.99]) by core3.amsl.com (Postfix) with SMTP id A05C228C108 for ; Fri, 14 Aug 2009 08:20:10 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090814152011.A05C228C108@core3.amsl.com> Date: Fri, 14 Aug 2009 08:20:10 -0700 (PDT) Show picture and go to site now! From crescendirj74@navegacion.com.my Sat Aug 15 05:24:25 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E7E28C22E; Sat, 15 Aug 2009 05:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.39 X-Spam-Level: X-Spam-Status: No, score=-16.39 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_CHARTER=2.175, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, 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 ywkuSddbaahS; Sat, 15 Aug 2009 05:24:24 -0700 (PDT) Received: from 24-216-176-92.dhcp.stls.mo.charter.com (24-216-176-92.dhcp.stls.mo.charter.com [24.216.176.92]) by core3.amsl.com (Postfix) with ESMTP id 6DAFD28C1F0; Sat, 15 Aug 2009 05:24:11 -0700 (PDT) Received: from 24.216.176.92 by mail.navegacion.com.my; Sat, 15 Aug 2009 07:24:14 -0600 Message-ID: <000d01ca1da3$4d57e0c0$6400a8c0@crescendirj74> From: Ashlee Buchanan To: Subject: Best Acai Berry Offers For Free Click NOw Date: Sat, 15 Aug 2009 07:24:14 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA1DA3.4D57E0C0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA1DA3.4D57E0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Can't see=20 this email? VIEW IN BROWSER =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Threat Information and=20 Product News for Customers =20 =20 =20 =20 =20 =20 =20 =20 =20 In this Issue: =20   =20 =20 Product=20 NewsEnhance your body ability to burn fat , w= ith Acai Berry. =A0 Ring the bell now =20 =20 =20 =20 =20 We appreciate your interest in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please opt-in to = our mailing=20 list. =20 =20 =A0 =20 Copyright=20 2009 Ozpn, Incorporated. All rights reserved. All other product=20 orcompany names may be trademarks or registered trademarks of their=20 owners. =A0 ------=_NextPart_000_0007_01CA1DA3.4D57E0C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ca= n't see=20 this email? VIEW IN BROWSER
Threat Information an= d=20 Product News for Customers=
In this Issue:<= /TD>
 
Product=20 News

Enhance your body ability to b= urn fat , with Acai Berry.
=A0
Ring the bell now
We appreciate your inter= est in=20 our newsletter. If you would like to receive our pr= oduct=20 announcements and special offers, please opt-in to our mailing=20 list.
=A0
Copyright=20 2009 Ozpn, Incorporated. All rights reserved. All other product=20 or
company names may be trademarks or registered trademarks of the= ir=20 owners.
=A0
------=_NextPart_000_0007_01CA1DA3.4D57E0C0-- From mbpu@3drealms.com Mon Aug 17 03:05:10 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED7E3A6C6D for ; Mon, 17 Aug 2009 03:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.5 X-Spam-Level: X-Spam-Status: No, score=-24.5 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP5qKPdXfTWb for ; Mon, 17 Aug 2009 03:05:09 -0700 (PDT) Received: from adventisthealthcare.com (unknown [92.9.63.38]) by core3.amsl.com (Postfix) with SMTP id EB40A3A6870 for ; Mon, 17 Aug 2009 03:05:06 -0700 (PDT) To: Subject: Open the door into a new world of sensual delights! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090817100507.EB40A3A6870@core3.amsl.com> Date: Mon, 17 Aug 2009 03:05:06 -0700 (PDT) Click here to view as a webpage. From owner-v6ops@ops.ietf.org Mon Aug 17 08:27:34 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F1A3A6E76 for ; Mon, 17 Aug 2009 08:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPhPZFATG8-c for ; Mon, 17 Aug 2009 08:27:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABC303A683C for ; Mon, 17 Aug 2009 08:27:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md41R-000A1t-GZ for v6ops-data0@psg.com; Mon, 17 Aug 2009 15:21:21 +0000 Received: from n55.bullet.mail.sp1.yahoo.com ([98.136.44.188]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md41K-000A12-2e for v6ops@ops.ietf.org; Mon, 17 Aug 2009 15:21:18 +0000 Received: from [216.252.122.217] by n55.bullet.mail.sp1.yahoo.com with NNFMP; 17 Aug 2009 15:21:13 -0000 Received: from [69.147.84.107] by t2.bullet.sp1.yahoo.com with NNFMP; 17 Aug 2009 15:21:13 -0000 Received: from [127.0.0.1] by omp202.mail.sp1.yahoo.com with NNFMP; 17 Aug 2009 15:21:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 21589.19634.bm@omp202.mail.sp1.yahoo.com Received: (qmail 83234 invoked by uid 60001); 17 Aug 2009 15:21:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250522472; bh=aFwhQp/2YAUeE6RiHthyLsD9Qv4v2E0QoYy/7DH9Ib8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=gklmzotnVChiwl3Avgw8BzwkZAi6REZ1273X2UzmCtoma7r9qA9/Iix5BaWWUNQTd5zyEOX1KIENjj122uGMZQUaIK1s7iW5aGwBOXMltGSkrevmvGb6yDcNJI+AdGjwHO6aZwbpDkM1Pj90wJIMswHUEDtn/2YWuxthWAvnSiQ= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=acJr3zedFbpo32lqoBllfc9pYrM2Y33MYC69MS/r4l9zAXuA5XgtZOG2Hhu91gBOsU83E5ak6A4Ik7+ZGUxv62/NGuyCGSMnhMedgl6o7u6lR87MTfmDhXGlty1FVZjmVVNwDBPwuUn3wZ4teSh+mYM9VXSLEosgTn/KlmzRyA8=; Message-ID: <789539.81531.qm@web45502.mail.sp1.yahoo.com> X-YMail-OSG: wbhj3XYVM1nend3JxUs6Y_qC4.6wg5WEdsq8eavbVZlCDQ340jP0xBjqiV94KT4mqH88BsCMCdwa6fJ3oBQlfI4ZM4fh40oun5y847yvqbPiZvfKmcmZ97tjcpSA38DfSSGLTVRsvNMeQlz0Y6ORZ5gu5OFFp9y0cpFJ_LsWuJGMOzYCscUtWl1bMLCfaDmK0.ytUXXf1HW5qD9u09HZ98tkwQ00GqwvztM6Ri9KMRiaOYHKwTiBaMBdKUzfYZM4_EoYZOyVxEIphgwpBIk2ZvB5DT2g8EFmXAikYm0lMu.HtZuh4.fV Received: from [89.138.113.91] by web45502.mail.sp1.yahoo.com via HTTP; Mon, 17 Aug 2009 08:21:12 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 Date: Mon, 17 Aug 2009 08:21:12 -0700 (PDT) From: Gabi Nakibly Subject: Routing loop attacks using IPv6 tunnels To: v6ops Cc: secdir@ietf.org, ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-619404899-1250522472=:81531" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0-619404899-1250522472=:81531 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=0AI would like to draw the attention of the list to=A0some=A0resear= ch=A0results which my colleague and I at the National EW Research=A0& Simul= ation=A0Center have recently published. The research presents a=A0class of = routing loop attacks that abuses 6to4, ISATAP and Teredo. The=A0paper can b= e found at: http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pd= f=0A=0AHere is the abstract:=0AIPv6 is the future network layer protocol fo= r the Internet. Since it is not compatible with its predecessor, some inter= operability mechanisms were designed. An important category of these mechan= isms is automatic tunnels, which enable IPv6 communication over an IPv4 net= work without prior configuration. This category includes ISATAP, 6to4 and T= eredo. We present a novel class of attacks that exploit vulnerabilities in = these tunnels. These attacks take advantage of inconsistencies between a tu= nnel's overlay IPv6 routing state and the native IPv6 routing state. The at= tacks form routing loops which can be abused as a vehicle for traffic ampli= fication to facilitate DoS attacks. We exhibit five attacks of this class. = One of the presented attacks can DoS a Teredo server using a single packet.= The exploited vulnerabilities are embedded in the design of the tunnels; h= ence any implementation of these tunnels may be vulnerable. In particular, = the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and W= indows Server 2008 R2. =0A=0AI think the results of the research warrant so= me corrective action. If this=A0indeed shall be the general sentiment of th= e list, I will be happy write an appropriate I-D. The mitigation measures w= e suggested in the paper are the best we could think of to completely elimi= nate the problem. However they are far from perfect since=A0they would requ= ire=A0tunnel implementations to be updated in case new types of automatic t= unnels are introduced.=0A=0AYour comments are welcome.=0A=0AGabi=0A=0A=0A = --0-619404899-1250522472=:81531 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=0A
I would like to draw the attention of the li= st to some research results which my colleague and I at the = National EW Research & Simulation Center have recently publis= hed. The research presents a class of routing loop attacks that abuses= 6to4, ISATAP and Teredo. The paper can be found at: http://www.usen= ix.org/events/woot09/tech/full_papers/nakibly.pdf
=0A
 =0A
Here is the abstract:
=0A
IPv6 is the future network layer protocol for the Internet.= Since it is not compatible with its predecessor, some interoperability mec= hanisms were designed. An important category of these mechanisms is automat= ic tunnels, which enable IPv6 communication over an IPv4 network without pr= ior configuration. This category includes ISATAP, 6to4 and Teredo. We prese= nt a novel class of attacks that exploit vulnerabilities in these tunnels. = These attacks take advantage of inconsistencies between a tunnel's overlay = IPv6 routing state and the native IPv6 routing state. The attacks form rout= ing loops which can be abused as a vehicle for traffic amplification to fac= ilitate DoS attacks. We exhibit five attacks of this class. One of the pres= ented attacks can DoS a Teredo server using a single packet. The exploited = vulnerabilities are embedded in the design of the tunnels; hence any implem= entation of these tunnels may be vulnerable. In particular, the attacks were tested against the ISATAP, 6to= 4 and Teredo implementations of Windows Vista and Windows Server 2008 R2. <= /FONT>
=0A
 
=0A
I think the results of the research= warrant some corrective action. If this indeed shall be the general s= entiment of the list, I will be happy write an appropriate I-D. The mitigat= ion measures we suggested in the paper are the best we could think of to co= mpletely eliminate the problem. However they are far from perfect since&nbs= p;they would require tunnel implementations to be updated in case new = types of automatic tunnels are introduced.
=0A
 
=0AYour comments are welcome.
=0A
 
=0A
Gabi

=0A=0A --0-619404899-1250522472=:81531-- From owner-v6ops@ops.ietf.org Mon Aug 17 09:57:08 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7FF3A6D5C for ; Mon, 17 Aug 2009 09:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 TcSsei2d5HuW for ; Mon, 17 Aug 2009 09:57:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D3553A6D4A for ; Mon, 17 Aug 2009 09:57:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md5TK-000Mb1-Le for v6ops-data0@psg.com; Mon, 17 Aug 2009 16:54:14 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md5TG-000MYW-1Z for v6ops@ops.ietf.org; Mon, 17 Aug 2009 16:54:12 +0000 Received: from basile.remlab.net (cs27060099.pp.htv.fi [89.27.60.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id 07D462D4; Mon, 17 Aug 2009 18:54:09 +0200 (CEST) From: "=?iso-8859-15?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels Date: Mon, 17 Aug 2009 19:54:06 +0300 User-Agent: KMail/1.12.0 (Linux/2.6.30.4; KDE/4.3.0; i686; ; ) Cc: v6ops , secdir@ietf.org, ipv6@ietf.org References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> In-Reply-To: <789539.81531.qm@web45502.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <200908171954.07106.remi@remlab.net> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le lundi 17 ao=FBt 2009 18:21:12 Gabi Nakibly, vous avez =E9crit : > Hi all, > I would like to draw the attention of the list to some research results > which my colleague and I at the National EW Research & Simulation Center > have recently published. The research presents a class of routing loop > attacks that abuses 6to4, ISATAP and Teredo. The paper can be found at: > http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf Attack E has been known for at least 2 years, though I do not have a Micros= oft=20 implementation to verify: http://www.remlab.net/miredo/mtfl-sa-0603.shtml.en Note that it *does* affect Linux-based in the sense that a non-privileged=20 local user could screw up (an unlikely scenario on a Teredo server, anyway). I'm now trying to verify attack D. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Mon Aug 17 10:38:11 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22AC3A6CCE for ; Mon, 17 Aug 2009 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 Vl0Mi9+6vn52 for ; Mon, 17 Aug 2009 10:38:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 458C53A6EFB for ; Mon, 17 Aug 2009 10:38:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md679-0004VQ-AA for v6ops-data0@psg.com; Mon, 17 Aug 2009 17:35:23 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Md672-0004U6-6G for v6ops@ops.ietf.org; Mon, 17 Aug 2009 17:35:19 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7HHZAt2001095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Aug 2009 10:35:10 -0700 (PDT) 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 n7HHZAB3016048; Mon, 17 Aug 2009 10:35:10 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7HHZ8XE015894; Mon, 17 Aug 2009 10:35:10 -0700 (PDT) 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.3959); Mon, 17 Aug 2009 10:35:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1F61.10FEDC58" Subject: RE: Routing loop attacks using IPv6 tunnels Date: Mon, 17 Aug 2009 10:35:08 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <789539.81531.qm@web45502.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcofTmXEPOk1UYNFRUS+bwV+J7jmOAADteKg References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" Cc: , X-OriginalArrivalTime: 17 Aug 2009 17:35:10.0344 (UTC) FILETIME=[11BE1880:01CA1F61] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1F61.10FEDC58 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Gabi, =20 Thanks for publishing this work. In the document, attacks A, B and C correspond to a configuration that violates section 6.2 of RFC5214: =20 > 6.2. ISATAP Interface Address Configuration >=20 > Each ISATAP interface configures a set of locators consisting of IPv4 > address-to-interface mappings from a single site; i.e., an ISATAP > interface's locator set MUST NOT span multiple sites. =20 In particular, in scenarios A, B and C the IPv4 locator used for ISATAP is seen both within the enterprise as site #1 and within the global Internet itself as site #2. If the ISATAP interface is to be used as an enterprise- interior interface, it should therefore not accept IP-proto-41 packets coming from an IPv4 source outside of the enterprise nor source IP-proto-41 packets that are destined to an IPv4 node outside of the enterprise. This condition should be satisfied by having the site border routers implement IPv4 ingress filtering and ip-protocol-41 filtering as required in Section 10 of RFC5214. =20 It is mentioned that attack C could also occur when the routers reside in the same site, where their addresses may be private. This would correspond to a case in which an attacker within the site attacks the site itself, which can easily be traced - especially when source address spoofing from a node within the site is prevented through proper ingress filtering. =20 Fred fred.l.templin@boeing.com =20 ________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Monday, August 17, 2009 8:21 AM To: v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: Routing loop attacks using IPv6 tunnels =20 Hi all, I would like to draw the attention of the list to some research results which my colleague and I at the National EW Research & Simulation Center have recently published. The research presents a class of routing loop attacks that abuses 6to4, ISATAP and Teredo. The paper can be found at: http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf =20 Here is the abstract: IPv6 is the future network layer protocol for the Internet. Since it is not compatible with its predecessor, some interoperability mechanisms were designed. An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 network without prior configuration. This category includes ISATAP, 6to4 and Teredo. We present a novel class of attacks that exploit vulnerabilities in these tunnels. These attacks take advantage of inconsistencies between a tunnel's overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. We exhibit five attacks of this class. One of the presented attacks can DoS a Teredo server using a single packet. The exploited vulnerabilities are embedded in the design of the tunnels; hence any implementation of these tunnels may be vulnerable. In particular, the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and Windows Server 2008 R2.=20 =20 I think the results of the research warrant some corrective action. If this indeed shall be the general sentiment of the list, I will be happy write an appropriate I-D. The mitigation measures we suggested in the paper are the best we could think of to completely eliminate the problem. However they are far from perfect since they would require tunnel implementations to be updated in case new types of automatic tunnels are introduced. =20 Your comments are welcome. =20 Gabi =20 ------_=_NextPart_001_01CA1F61.10FEDC58 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Gabi,

 

Thanks for publishing this work. In = the document, attacks A, B and C

correspond to a configuration that violates section 6.2 of RFC5214:

 

> 6.2.  ISATAP Interface = Address Configuration

> 

>   Each ISATAP = interface configures a set of locators consisting of IPv4

>   = address-to-interface mappings from a single site; i.e., an ISATAP

>   interface's = locator set MUST NOT span multiple sites.

 

In particular, in scenarios A, B = and C the IPv4 locator used for ISATAP

is seen both within the enterprise = as site #1 and within the global Internet

itself as site #2. If the ISATAP = interface is to be used as an enterprise-

interior interface, it should = therefore not accept IP-proto-41 packets

coming from an IPv4 source outside = of the enterprise nor source

IP-proto-41 packets that are = destined to an IPv4 node outside of the

enterprise. This condition should = be satisfied by having the site border

routers implement IPv4 ingress = filtering and ip-protocol-41 filtering as

required in Section 10 of = RFC5214.

 

It is mentioned that attack C could = also occur when the routers reside

in the same site, where their = addresses may be private. This would

correspond to a case in which an = attacker within the site attacks the

site itself, which can easily be = traced – especially when source address

spoofing from a node within the = site is prevented through proper ingress

filtering.

 

Fred

fred.l.templin@boeing.com

 

From: Gabi = Nakibly [mailto:gnakibly@yahoo.com]
Sent: Monday, August 17, = 2009 8:21 AM
To: v6ops
Cc: ipv6@ietf.org; = secdir@ietf.org
Subject: Routing loop = attacks using IPv6 tunnels

 

Hi all,

I would like to draw the attention of the list to some research results which my colleague and I at the National EW Research & Simulation Center have recently = published. The research presents a class of routing loop attacks that abuses = 6to4, ISATAP and Teredo. The paper can be found at: http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf

 

Here is the abstract:

IPv6 is the future network layer protocol for the = Internet. Since it is not compatible with its predecessor, some interoperability mechanisms were designed. An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 network = without prior configuration. This category includes ISATAP, 6to4 and Teredo. We = present a novel class of attacks that exploit vulnerabilities in these tunnels. = These attacks take advantage of inconsistencies between a tunnel's overlay = IPv6 routing state and the native IPv6 routing state. The attacks form = routing loops which can be abused as a vehicle for traffic amplification to facilitate = DoS attacks. We exhibit five attacks of this class. One of the presented = attacks can DoS a Teredo server using a single packet. The exploited = vulnerabilities are embedded in the design of the tunnels; hence any implementation of = these tunnels may be vulnerable. In particular, the attacks were tested = against the ISATAP, 6to4 and Teredo implementations of Windows Vista and Windows = Server 2008 R2.

 

I think the results of the research warrant some = corrective action. If this indeed shall be the general sentiment of the list, = I will be happy write an appropriate I-D. The mitigation measures we suggested = in the paper are the best we could think of to completely eliminate the = problem. However they are far from perfect since they would = require tunnel implementations to be updated in case new types of automatic tunnels are introduced.

 

Your comments are welcome.

 

Gabi

 

------_=_NextPart_001_01CA1F61.10FEDC58-- From owner-v6ops@ops.ietf.org Tue Aug 18 02:36:14 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E833A6DE3 for ; Tue, 18 Aug 2009 02:36:14 -0700 (PDT) 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.332, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNlbwd7R98n1 for ; Tue, 18 Aug 2009 02:36:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B2273A6975 for ; Tue, 18 Aug 2009 02:36:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdL1A-000MFT-BL for v6ops-data0@psg.com; Tue, 18 Aug 2009 09:30:12 +0000 Received: from n61.bullet.mail.sp1.yahoo.com ([98.136.44.37]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdL0x-000MBt-Cm for v6ops@ops.ietf.org; Tue, 18 Aug 2009 09:30:02 +0000 Received: from [69.147.84.145] by n61.bullet.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 09:29:58 -0000 Received: from [69.147.84.114] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 09:29:58 -0000 Received: from [127.0.0.1] by omp203.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 09:29:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 897451.26734.bm@omp203.mail.sp1.yahoo.com Received: (qmail 63969 invoked by uid 60001); 18 Aug 2009 09:29:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250587798; bh=Xog9xZ5c5UeuLK5xjiGcY3IlKftxHwVbSeOxGNAv/e4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kMCSK5bHviRPpp7J0s2MRCI2a6c8+1+Qr2txf9ORTR4zR+zDWE50Nam/HCsdY3kq5BC2AmtjZXX0GyRvW75oqlcolG29bfb/GZkhmR5y4w8U/7CieXq1+6xrEnEF9V1ihZAFJGwhw5XIlEtPQQS5WUKgLvtwjolSDGz/lhYq3co= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ye8fVTICRwVLgrpcxbItMxp4a9qB+0evHYmayEke/eZFKxCnNM98uLga1qUpxr+YLlps5tj3niEV6NGtcQOjIDMSxnPtommJlqJOfm2ic4PUSPvEX1b0WlFX/UpboPM2yQZSzgZkgN9838baYPsu1Cg7XEh/1cbWcx5aqdStZwA=; Message-ID: <726098.63579.qm@web45508.mail.sp1.yahoo.com> X-YMail-OSG: PuL04akVM1nrwaa8C1Zdq8RfdVDvtbNk50H_YjqX7uR.fHDa7HcfS3XJBZ95VzonvXg_vy8iPV3Dpz4O_HSfC_nPoco58MX1TNmhzqOyEaAQm3sNNvLUWaqYiJ_GxqWNWGodWVxPFpXRCypVj.lSPxApZnrJ5xYZoRlaBXMt0HWb2MKMLLZVbHESuO3VO9cJglkCx1e_XRdte6qSxW_m3BTO2L1W9JY7L2vJNyiDBzXMvBhCDNzdf07mfFferaz4DWu99t53xHeLuPVIiuMGcFqrtUTMOZV47Ub4NZN0ZKG9zkS3GL0- Received: from [89.138.113.91] by web45508.mail.sp1.yahoo.com via HTTP; Tue, 18 Aug 2009 02:29:58 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <200908171954.07106.remi@remlab.net> Date: Tue, 18 Aug 2009 02:29:58 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= Cc: v6ops , secdir@ietf.org, ipv6@ietf.org In-Reply-To: <200908171954.07106.remi@remlab.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1408785047-1250587798=:63579" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0-1408785047-1250587798=:63579 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Indeed, the vulnerability of attack 5 was noted and fixed in Miredo. Howeve= r, I am not aware of any updates=A0to the Teredo specification to mitigate = it. This means that new implementations will=A0always be vulnerable as in t= he case of Windows Server 2008 R2. This vulnerability was reported to Micro= soft a few months ago. They have reproduced it on their end. A fix should b= e released in the next RC.=0AI did not realize that the attack can be succe= ssful also on Linux. Thanks for the correction.=0A=0APlease let me know the= results of your check on attack #4. If you wish, I can send you (off-list)= =A0the details of my setup for this attack. By the way, I encourage other p= eople on the list to verify the attacks in different scenarios.=0A=0AGabi= =0A=0A=A0=0A=0A________________________________=0AFrom: R=E9mi Denis-Courmo= nt =0ATo: Gabi Nakibly =0ACc: v6ops ; secdir@ietf.org; ipv6@ietf.org=0ASent: Monday, August 1= 7, 2009 7:54:06 PM=0ASubject: Re: Routing loop attacks using IPv6 tunnels= =0A=0ALe lundi 17 ao=FBt 2009 18:21:12 Gabi Nakibly, vous avez =E9crit :=0A= > Hi all,=0A> I would like to draw the attention of the list to some resear= ch results=0A> which my colleague and I at the National EW Research & Simul= ation Center=0A> have recently published. The research presents a class of = routing loop=0A> attacks that abuses 6to4, ISATAP and Teredo. The paper can= be found at:=0A> http://www.usenix.org/events/woot09/tech/full_papers/naki= bly.pdf=0A=0AAttack E has been known for at least 2 years, though I do not = have a Microsoft =0Aimplementation to verify: http://www.remlab.net/miredo/= mtfl-sa-0603.shtml.en=0A=0ANote that it *does* affect Linux-based in the se= nse that a non-privileged =0Alocal user could screw up (an unlikely scenari= o on a Teredo server, anyway).=0A=0A=0AI'm now trying to verify attack D.= =0A=0A=0A-- =0AR=E9mi Denis-Courmont=0Ahttp://www.remlab.net/=0A=0A=0A=0A = --0-1408785047-1250587798=:63579 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Indeed, the vulnerability of attack 5 was noted and fixed in Mire= do. However, I am not aware of any updates to the Teredo specification= to mitigate it. This means that new implementations will always be vu= lnerable as in the case of Windows Server 2008 R2. This vulnerability was r= eported to Microsoft a few months ago. They have reproduced it on their end= .. A fix should be released in the next RC.
=0A
I did not realize t= hat the attack can be successful also on Linux. Thanks for the correction.<= /DIV>=0A
 
=0A
Please let me know the results of your che= ck on attack #4. If you wish, I can send you (off-list) the details of= my setup for this attack. By the way, I encourage other people on the list= to verify the attacks in different scenarios.
=0A
 
=0A
Gabi=0A

 
=0A
=0A
=0A<= SPAN style=3D"FONT-WEIGHT: bold">From: R=E9mi Denis-Courmont <= ;remi@remlab.net>
To:= Gabi Nakibly <gnakibly@yahoo.com>
Cc: v6ops <v6ops@ops.ietf.org>; secdir@ietf.org; ipv= 6@ietf.org
Sent: Monday,= August 17, 2009 7:54:06 PM
Subject= : Re: Routing loop attacks using IPv6 tunnels

Le l= undi 17 ao=FBt 2009 18:21:12 Gabi Nakibly, vous avez =E9crit :
> Hi a= ll,
> I would like to draw the attention of the list to some research= results
> which my colleague and I at the National EW Research &= Simulation Center
> have recently published. The research presents a= class of routing loop
> attacks that abuses 6to4, ISATAP and Teredo.= The paper can be found at:
> http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf

At= tack E has been known for at least 2 years, though I do not have a Microsof= t
implementation to verify: http://www.remlab.net/miredo/mtfl-sa-0603.s= html.en

Note that it *does* affect Linux-based in the sense that a n= on-privileged
local user could screw up (an unlikely scenario on a Tere= do server, anyway).


I'm now trying to verify attack D.

--
R=E9mi Denis-Courmont
http://www.remlab.net/
=0A=0A=0A=0A --0-1408785047-1250587798=:63579-- From owner-v6ops@ops.ietf.org Tue Aug 18 03:31:59 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C383A6B58 for ; Tue, 18 Aug 2009 03:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa+rldmCnHdr for ; Tue, 18 Aug 2009 03:31:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C92473A68E6 for ; Tue, 18 Aug 2009 03:31:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdLwg-0004q0-NZ for v6ops-data0@psg.com; Tue, 18 Aug 2009 10:29:38 +0000 Received: from n79.bullet.mail.sp1.yahoo.com ([98.136.44.39]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdLwV-0004or-CN for v6ops@ops.ietf.org; Tue, 18 Aug 2009 10:29:35 +0000 Received: from [216.252.122.217] by n79.bullet.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 10:29:27 -0000 Received: from [69.147.84.123] by t2.bullet.sp1.yahoo.com with NNFMP; 18 Aug 2009 10:29:27 -0000 Received: from [127.0.0.1] by omp209.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 10:29:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 115271.6593.bm@omp209.mail.sp1.yahoo.com Received: (qmail 44992 invoked by uid 60001); 18 Aug 2009 10:29:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250591367; bh=FhrggRYJfMQPyzw933PNcehrE2GcrLL8yvQV75aq6fg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=c2ncJKmi+IvpWWl+/0XblUJqFhD6Kke//EwQzKZArrfAqZywwQJLvsNjpwaQhQdyhCsoFVdm2LgeUwh7mjh+Wam7rMtf7nhvav4QKK3KAoGQ6TRzFBACG9GrBkGzOU6sxThFQhqp/iKfXQqV0xUHAbz0LeLIsKwl9kz9Bk0XY6c= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0yD4r7gEQf6M8btJ0pELKZSFEbB7/rWoTdyfD8evzVfk2ObDgD6/8DiazZEjr5Q8opQbrB7XIRtsQo/Aj3hHt+Qecf9cQ/3mBAMLyq8MFAp48bLMSVNrRvIvDdVtX/EhPcXSHKLBZ4UFsJ4pk5NXZr3prVNah+jtY1QcNa/cpsQ=; Message-ID: <2705.42043.qm@web45502.mail.sp1.yahoo.com> X-YMail-OSG: VBI9GEkVM1llUTTNFOz1BkkiBeoEYErNwFMrfpoXtT.d3KOzB_djLgS3 Received: from [89.138.113.91] by web45502.mail.sp1.yahoo.com via HTTP; Tue, 18 Aug 2009 03:29:26 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> Date: Tue, 18 Aug 2009 03:29:26 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" , v6ops Cc: ipv6@ietf.org, secdir@ietf.org In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1918408619-1250591366=:42043" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0-1918408619-1250591366=:42043 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Indeed the ISATAP interface of the ISATAP router is meant to be an enterpri= se-interior (note that=C2=A0it is still=C2=A0assumed that the associated IP= v4 address is=C2=A0non-private). As=C2=A0we explicitly note in the paper, t= he first three attacks=C2=A0will be mitigated=C2=A0if proper protocol-41 fi= ltering is deployed on the site's border. However, note that RFC5214 does n= ot mandate or require this filtering. It is only mentioned as a possible mi= tigation against incoming spurious protocol-41 packets. In addition, Sectio= n 10 of RFC5214 only mentions=C2=A0ingress not=C2=A0egress filtering.=C2=A0= Hence it=C2=A0will not stop attack #2.=C2=A0=0AIn addition, as mentioned, p= rotocol-41 filtering is not helpful when attack #3 is launched on two route= rs that reside in the same site. Note that=C2=A0it=C2=A0may be=C2=A0possibl= e for=C2=A0the attack packet=C2=A0to be sourced from outside the site unles= s proper filtering of incoming IPv6 packets is deployed. If the attacker re= sides in the site, usually ingress filtering will not be helpful since it i= s deployed in general on the site's border.=0A=0AIn general, I would like t= o point out that indeed as in most other attacks these attacks may also be = mitigated by proper firewall rules. However, I do not believe that this=C2= =A0should be our only answer against these attacks. I believe that since th= ese attacks are made possible due to the inherent characteristics of the tu= nnels they=C2=A0should be stopped intrinsically as much as possible by the = tunnel participants and not relay on outside filtering rules.=0A=0AGabi=0A= =0A=0A________________________________=0AFrom: "Templin, Fred L" =0ATo: Gabi Nakibly ; v6ops =0ACc: ipv6@ietf.org; secdir@ietf.org=0ASent: Monday, August 17, = 2009 8:35:08 PM=0ASubject: RE: Routing loop attacks using IPv6 tunnels=0A= =0A=0AGabi,=0A=C2=A0=0AThanks for publishing this work. In the document, at= tacks A, B and C=0Acorrespond to a configuration that violates section 6.2 = of RFC5214:=0A=C2=A0=0A> 6.2.=C2=A0 ISATAP Interface Address Configuration= =0A>=C2=A0=0A> =C2=A0=C2=A0Each ISATAP interface configures a set of locato= rs consisting of IPv4=0A>=C2=A0=C2=A0 address-to-interface mappings from a = single site; i.e., an ISATAP=0A>=C2=A0=C2=A0 interface's locator set MUST N= OT span multiple sites.=0A=C2=A0=0AIn particular, in scenarios A, B and C t= he IPv4 locator used for ISATAP=0Ais seen both within the enterprise as sit= e #1 and within the global Internet=0Aitself as site #2. If the ISATAP inte= rface is to be used as an enterprise-=0Ainterior interface, it should there= fore not accept IP-proto-41 packets=0Acoming from an IPv4 source outside of= the enterprise nor source=0AIP-proto-41 packets that are destined to an IP= v4 node outside of the=0Aenterprise. This condition should be satisfied by = having the site border=0Arouters implement IPv4 ingress filtering and ip-pr= otocol-41 filtering as=0Arequired in Section 10 of RFC5214.=0A=C2=A0=0AIt i= s mentioned that attack C could also occur when the routers reside=0Ain the= same site, where their addresses may be private. This would=0Acorrespond t= o a case in which an attacker within the site attacks the=0Asite itself, wh= ich can easily be traced =E2=80=93 especially when source address=0Aspoofin= g from a node within the site is prevented through proper ingress=0Afilteri= ng.=0A=C2=A0=0AFred=0Afred.l.templin@boeing.com=0A=C2=A0=0A=0A_____________= ___________________=0A=0AFrom:Gabi Nakibly [mailto:gnakibly@yahoo.com] =0AS= ent: Monday, August 17, 2009 8:21 AM=0ATo: v6ops=0ACc: ipv6@ietf.org; secdi= r@ietf.org=0ASubject: Routing loop attacks using IPv6 tunnels=0A=C2=A0=0AHi= all,=0AI would like to draw the attention of the list to=C2=A0some=C2=A0re= search=C2=A0results which my colleague and I at the National EW Research=C2= =A0& Simulation=C2=A0Center have recently published. The research presents = a=C2=A0class of routing loop attacks that abuses 6to4, ISATAP and Teredo. T= he=C2=A0paper can be found at: http://www.usenix.org/events/woot09/tech/ful= l_papers/nakibly.pdf=0A=C2=A0=0AHere is the abstract:=0AIPv6 is the future = network layer protocol for the Internet. Since it is not compatible with it= s predecessor, some interoperability mechanisms were designed. An important= category of these mechanisms is automatic tunnels, which enable IPv6 commu= nication over an IPv4 network without prior configuration. This category in= cludes ISATAP, 6to4 and Teredo. We present a novel class of attacks that ex= ploit vulnerabilities in these tunnels. These attacks take advantage of inc= onsistencies between a tunnel's overlay IPv6 routing state and the native I= Pv6 routing state. The attacks form routing loops which can be abused as a = vehicle for traffic amplification to facilitate DoS attacks. We exhibit fiv= e attacks of this class. One of the presented attacks can DoS a Teredo serv= er using a single packet. The exploited vulnerabilities are embedded in the= design of the tunnels; hence any implementation of these tunnels may be vu= lnerable. In particular, the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and W= indows Server 2008 R2. =0A=C2=A0=0AI think the results of the research warr= ant some corrective action. If this=C2=A0indeed shall be the general sentim= ent of the list, I will be happy write an appropriate I-D. The mitigation m= easures we suggested in the paper are the best we could think of to complet= ely eliminate the problem. However they are far from perfect since=C2=A0the= y would require=C2=A0tunnel implementations to be updated in case new types= of automatic tunnels are introduced.=0A=C2=A0=0AYour comments are welcome.= =0A=C2=A0=0AGabi=0A=0A=0A --0-1918408619-1250591366=:42043 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Indeed the ISATAP interface of the ISATAP router is meant to be a= n enterprise-interior (note that it is still assumed that the ass= ociated IPv4 address is non-private). As we explicitly note in th= e paper, the first three attacks will be mitigated if proper prot= ocol-41 filtering is deployed on the site's border. However, note that RFC5= 214 does not mandate or require this filtering. It is only mentioned as a p= ossible mitigation against incoming spurious protocol-41 packets. In additi= on, Section 10 of RFC5214 only mentions ingress not egress filter= ing. Hence it will not stop attack #2. 
=0A
In addition= , as mentioned, protocol-41 filtering is not helpful when attack #3 is laun= ched on two routers that reside in the same site. Note that it ma= y be possible for the attack packet to be sourced from outsi= de the site unless proper filtering of incoming IPv6 packets is deployed. I= f the attacker resides in the site, usually ingress filtering will not be h= elpful since it is deployed in general on the site's border.
=0A
 <= /DIV>=0A
In general, I would like to point out that indeed as in most other a= ttacks these attacks may also be mitigated by proper firewall rules. Howeve= r, I do not believe that this should be our only answer against these = attacks. I believe that since these attacks are made possible due to the in= herent characteristics of the tunnels they should be stopped intrinsic= ally as much as possible by the tunnel participants and not relay on outsid= e filtering rules.
=0A
 
=0A
Gabi
=0A
 
=0A
=0A
=0A
=0AFrom: "Templin, Fred L" <Fred.L.Templin@boeing.= com>
To: Gabi Nakibly= <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>
Cc: ipv6@ietf.org; secdir@ietf.orgSent: Monday, August 17, 2= 009 8:35:08 PM
Subject: = RE: Routing loop attacks using IPv6 tunnels

=0A=0A=0A=0A
=0A

Gabi,

=0A

 

=0A

Thanks for publishing this work. In the document, a= ttacks A, B and C

=0A

correspond to a configuration that violates section 6.2 of R= FC5214:

=0A

 

=0A

> 6.2.  ISATAP Interface Address Configuration

=0A

> 

=0A

> &= nbsp; Each ISATAP interface configures a set of locators consisting of= IPv4

=0A

>   address-to-interface mappings from a single site; i.e.,= an ISATAP

=0A

>   interface's locator set MUST NOT span multiple sit= es.

=0A

 

=0A

In particular, in scenarios A, B and C the IPv4 locator used for ISATA= P

=0A

i= s seen both within the enterprise as site #1 and within the global Internet=

=0A

i= tself as site #2. If the ISATAP interface is to be used as an enterprise-

=0A

inte= rior interface, it should therefore not accept IP-proto-41 packets

=0A

<= SPAN style=3D"FONT-FAMILY: Arial; COLOR: navy; FONT-SIZE: 10pt">coming from= an IPv4 source outside of the enterprise nor source

=0AIP-proto-41 packets that = are destined to an IPv4 node outside of the

=0A

enterprise. This condition should = be satisfied by having the site border

=0A

routers implement IPv4 ingress filterin= g and ip-protocol-41 filtering as

=0A

= required in Section 10 of RFC5214.

=0A

 

=0A

It is me= ntioned that attack C could also occur when the routers reside

=0A

in the same sit= e, where their addresses may be private. This would

=0A

correspond to a case in wh= ich an attacker within the site attacks the

=0A

site itself, which can easily be t= raced =E2=80=93 especially when source address

=0A

spoofing from a node within the= site is prevented through proper ingress

=0A

filtering.

=0A

 

=0A<= P class=3DMsoNormal>Fred

= =0A

fred.l.templin@boein= g.com

=0A

 

=0A
=0A
=0A
=0A
=0A
=0A

From:<= /SPAN> Gabi Nakibly [mailto:gnakibly@yahoo.com]
Sent: Monday, August 17, 2009 8:= 21 AM
To: v6ops
Cc: ipv6@ietf.org; secdir@ietf.o= rg
Subject: Routing loop= attacks using IPv6 tunnels

=0A

= &nb= sp;

=0A
=0A
=0A

Hi all,

=0A
=0A

I would like t= o draw the attention of the list to some research results wh= ich my colleague and I at the National EW Research & Simulation&nb= sp;Center have recently published. The research presents a class of ro= uting loop attacks that abuses 6to4, ISATAP and Teredo. The paper can = be found at: http://www.usenix.org/events/woot09/tech/full_papers/nakibly.p= df

=0A
=0A

 

=0A
=0A

Here is the abstract= :

=0A
=0A

IPv6 is the f= uture network layer protocol for the Internet. Since it is not compatible w= ith its predecessor, some interoperability mechanisms were designed. An imp= ortant category of these mechanisms is automatic tunnels, which enable IPv6= communication over an IPv4 network without prior configuration. This categ= ory includes ISATAP, 6to4 and Teredo. We present a novel class of attacks t= hat exploit vulnerabilities in these tunnels. These attacks take advantage = of inconsistencies between a tunnel's overlay IPv6 routing state and the na= tive IPv6 routing state. The attacks form routing loops which can be abused= as a vehicle for traffic amplification to facilitate DoS attacks. We exhib= it five attacks of this class. One of the presented attacks can DoS a Tered= o server using a single packet. The exploited vulnerabilities are embedded = in the design of the tunnels; hence any implementation of these tunnels may be vulnerable. In particular, the = attacks were tested against the ISATAP, 6to4 and Teredo implementations of = Windows Vista and Windows Server 2008 R2.

=0A
= =0A

 

=0A
=0A

I think the results of the research warrant some corre= ctive action. If this indeed shall be the general sentiment of the lis= t, I will be happy write an appropriate I-D. The mitigation measures we sug= gested in the paper are the best we could think of to completely eliminate = the problem. However they are far from perfect since they would requir= e tunnel implementations to be updated in case new types of automatic = tunnels are introduced.

=0A
=0A

 

=0A
=0A

Your comments are welcome.

=0A
=0A

 

=0A
=0A

= Gabi

=0A

 =

=0A

=0A=0A --0-1918408619-1250591366=:42043-- From owner-v6ops@ops.ietf.org Tue Aug 18 04:55:31 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA1E3A680E for ; Tue, 18 Aug 2009 04:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, 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 HTD7BX0kMFBp for ; Tue, 18 Aug 2009 04:55:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 455E33A67A3 for ; Tue, 18 Aug 2009 04:55:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdNDz-000GPM-D4 for v6ops-data0@psg.com; Tue, 18 Aug 2009 11:51:35 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdNDv-000GOf-8R for v6ops@ops.ietf.org; Tue, 18 Aug 2009 11:51:33 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 4C342494; Tue, 18 Aug 2009 13:51:30 +0200 (CEST) To: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels MIME-Version: 1.0 Date: Tue, 18 Aug 2009 13:51:30 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: v6ops , secdir@ietf.org, ipv6@ietf.org Organization: Remlab.net In-Reply-To: <726098.63579.qm@web45508.mail.sp1.yahoo.com> References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <200908171954.07106.remi@remlab.net> <726098.63579.qm@web45508.mail.sp1.yahoo.com> Message-ID: <6c60aa25c21d90342161a94ee190d34f@chewa.net> X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 18 Aug 2009 02:29:58 -0700 (PDT), Gabi Nakibly wrote: > Indeed, the vulnerability of attack 5 was noted and fixed in Miredo. > However, I am not aware of any updates to the Teredo specification to > mitigate it. This means that new implementations will always be vulnerable > as in the case of Windows Server 2008 R2. This vulnerability was reported > to Microsoft a few months ago. They have reproduced it on their end. A fix > should be released in the next RC. > I did not realize that the attack can be successful also on Linux. Thanks > for the correction. Well, it is as simple as not looping packet back to yourself, isn't it? There could be a warning in the spec, but it's really an implementation error, I think. > Please let me know the results of your check on attack #4. If you wish, I > can send you (off-list) the details of my setup for this attack. By the > way, I encourage other people on the list to verify the attacks in > different scenarios. I managed to reproduce it. Single-homed NATs have absolutely no excuse in forwarding a packet with their own IP address as the source. But yeah - there is a problem. -- Rémi Denis-Courmont From owner-v6ops@ops.ietf.org Tue Aug 18 08:55:14 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360563A6E80 for ; Tue, 18 Aug 2009 08:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 V9VflYax-Hyp for ; Tue, 18 Aug 2009 08:55:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FB9C3A6E82 for ; Tue, 18 Aug 2009 08:55:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdQw7-0002vw-Gv for v6ops-data0@psg.com; Tue, 18 Aug 2009 15:49:23 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdQvs-0002qq-Jo for v6ops@ops.ietf.org; Tue, 18 Aug 2009 15:49:12 +0000 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 n7IFmlUr005723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 10:48:48 -0500 (CDT) 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 n7IFmltf008992; Tue, 18 Aug 2009 08:48:47 -0700 (PDT) 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 n7IFmhgn008798; Tue, 18 Aug 2009 08:48:47 -0700 (PDT) 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.3959); Tue, 18 Aug 2009 08:48:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Routing loop attacks using IPv6 tunnels Date: Tue, 18 Aug 2009 08:48:45 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106498101@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <2705.42043.qm@web45502.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: Acof7sREBI8RyOgVTuWZvjFQVikJ0AAJPgow References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> <2705.42043.qm@web45502.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" Cc: , X-OriginalArrivalTime: 18 Aug 2009 15:48:46.0762 (UTC) FILETIME=[5F3E88A0:01CA201B] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gabi, ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Tuesday, August 18, 2009 3:29 AM To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Indeed the ISATAP interface of the ISATAP router is meant > to be an enterprise-interior (note that=A0it is still=A0assumed > that the associated IPv4 address is=A0non-private). As=A0we > explicitly note in the paper, the first three attacks=A0will > be mitigated=A0if proper protocol-41 filtering is deployed on > the site's border. However, note that RFC5214 does not mandate > or require this filtering. The RFC5214 Security Considerations makes clear the consequences of not implementing IPv4 ingress filtering and ip-protocol-41 filtering (i.e., a possible spooing attack in which spurious ip-protocol-41 packets are injected into an ISATAP link from outside). RFC5214 Section 6.2 additionally requires that an ISATAP interface's locator set MUST NOT span multiple sites. This means that the ISATAP interface must not decapsulate nor source ip-proto-41 packets within multiple sites, where the enterprise interior is site #1 and the global Internet is site #2. ip-protocol-41 filtering is the way in which the ISATAP interface is restricted to a single site.=20 > It is only mentioned as a possible mitigation against > incoming spurious protocol-41 packets. In addition, > Section 10 of RFC5214 only mentions=A0ingress not=A0egress > filtering.=A0Hence it=A0will not stop attack #2. We are now talking about ip-proto-41 filtering; not ingress filtering. ip-proto-41 filtering is in both directions. It prevents ip-proto-41 packets from entering the enterprise interior ISATAP site from the Internet and prevents ip-proto-41 packets from entering the Internet ISATAP site from the enterprise interior. Else the ISATAP interface would span multiple sites. Besides, "ingress" filtering is not about packets coming from the Internet into the end site, but rather it is about packets leaving the end site and going out into the Internet. RFC2827 (BCP38) documents ingress filtering. > In addition, > as mentioned, protocol-41 filtering is not helpful when > attack #3 is launched on two routers that reside in the > same site. Note that=A0it=A0may be=A0possible for=A0the attack > packet=A0to be sourced from outside the site unless proper > filtering of incoming IPv6 packets is deployed. If the > attacker resides in the site, usually ingress filtering > will not be helpful since it is deployed in general on > the site's border. Here, we have the ISATAP router in both cases sourcing a packet from a foreign prefix. This attack is mitigated by=20 IPv6 ingress filtering which is an IPv6 security consideration and not an ISATAP nor IPv4 security consideration. BCP recommendations for network ingress filtering are documented in RFC2827 and it is expected that IPv6 routers that configure ISATAP interfaces will implement IPv6 ingress filtering according to the BCP. =A0 > In general, I would like to point out that indeed as in > most other attacks these attacks may also be mitigated by > proper firewall rules. However, I do not believe that this > should be our only answer against these attacks. I believe > that since these attacks are made possible due to the > inherent characteristics of the tunnels they=A0should be > stopped intrinsically as much as possible by the tunnel > participants and not relay on outside filtering rules. In RFC5214, Section 10 we have: "restricting access to the link can be achieved by restricting access to the site". The mitigations do exactly that, and in such a way that ISATAP nodes can operate with only the necessary and sufficient checks. So on this point, I do not share your opinion. Fred fred.l.templin@boeing.com =A0 ________________________________________ From: "Templin, Fred L" To: Gabi Nakibly ; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Sent: Monday, August 17, 2009 8:35:08 PM Subject: RE: Routing loop attacks using IPv6 tunnels Gabi, =A0 Thanks for publishing this work. In the document, attacks A, B and C correspond to a configuration that violates section 6.2 of RFC5214: =A0 > 6.2.=A0 ISATAP Interface Address Configuration >=A0 > =A0=A0Each ISATAP interface configures a set of locators consisting of = IPv4 >=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP >=A0=A0 interface's locator set MUST NOT span multiple sites. =A0 In particular, in scenarios A, B and C the IPv4 locator used for ISATAP is seen both within the enterprise as site #1 and within the global = Internet itself as site #2. If the ISATAP interface is to be used as an = enterprise- interior interface, it should therefore not accept IP-proto-41 packets coming from an IPv4 source outside of the enterprise nor source IP-proto-41 packets that are destined to an IPv4 node outside of the enterprise. This condition should be satisfied by having the site border routers implement IPv4 ingress filtering and ip-protocol-41 filtering as required in Section 10 of RFC5214. =A0 It is mentioned that attack C could also occur when the routers reside in the same site, where their addresses may be private. This would correspond to a case in which an attacker within the site attacks the site itself, which can easily be traced - especially when source address spoofing from a node within the site is prevented through proper ingress filtering. =A0 Fred fred.l.templin@boeing.com =A0 ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Monday, August 17, 2009 8:21 AM To: v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: Routing loop attacks using IPv6 tunnels =A0 Hi all, I would like to draw the attention of the list = to=A0some=A0research=A0results which my colleague and I at the National = EW Research=A0& Simulation=A0Center have recently published. The = research presents a=A0class of routing loop attacks that abuses 6to4, = ISATAP and Teredo. The=A0paper can be found at: = http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf =A0 Here is the abstract: IPv6 is the future network layer protocol for the Internet. Since it is = not compatible with its predecessor, some interoperability mechanisms = were designed. An important category of these mechanisms is automatic = tunnels, which enable IPv6 communication over an IPv4 network without = prior configuration. This category includes ISATAP, 6to4 and Teredo. We = present a novel class of attacks that exploit vulnerabilities in these = tunnels. These attacks take advantage of inconsistencies between a = tunnel's overlay IPv6 routing state and the native IPv6 routing state. = The attacks form routing loops which can be abused as a vehicle for = traffic amplification to facilitate DoS attacks. We exhibit five attacks = of this class. One of the presented attacks can DoS a Teredo server = using a single packet. The exploited vulnerabilities are embedded in the = design of the tunnels; hence any implementation of these tunnels may be = vulnerable. In particular, the attacks were tested against the ISATAP, = 6to4 and Teredo implementations of Windows Vista and Windows Server 2008 = R2.=20 =A0 I think the results of the research warrant some corrective action. If = this=A0indeed shall be the general sentiment of the list, I will be = happy write an appropriate I-D. The mitigation measures we suggested in = the paper are the best we could think of to completely eliminate the = problem. However they are far from perfect since=A0they would = require=A0tunnel implementations to be updated in case new types of = automatic tunnels are introduced. =A0 Your comments are welcome. =A0 Gabi =A0 From owner-v6ops@ops.ietf.org Tue Aug 18 10:04:42 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5FF28C316 for ; Tue, 18 Aug 2009 10:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 hb5l0jbb5J0A for ; Tue, 18 Aug 2009 10:04:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D25A63A6B31 for ; Tue, 18 Aug 2009 10:04:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdS3L-000Cvc-5L for v6ops-data0@psg.com; Tue, 18 Aug 2009 17:00:55 +0000 Received: from [80.12.242.140] (helo=smtp2a.orange.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdS3F-000Cus-Sk for v6ops@ops.ietf.org; Tue, 18 Aug 2009 17:00:53 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a23.orange.fr (SMTP Server) with ESMTP id 321A980003C0; Tue, 18 Aug 2009 19:00:48 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a23.orange.fr (SMTP Server) with ESMTP id 2622680000B9; Tue, 18 Aug 2009 19:00:48 +0200 (CEST) Received: from [193.248.104.104] (Mix-Lille-207-14-104.w193-248.abo.wanadoo.fr [193.248.104.104]) by mwinf2a23.orange.fr (SMTP Server) with ESMTP id 78E3D80003C0; Tue, 18 Aug 2009 19:00:45 +0200 (CEST) X-ME-UUID: 20090818170045495.78E3D80003C0@mwinf2a23.orange.fr In-Reply-To: <789539.81531.qm@web45502.mail.sp1.yahoo.com> References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> Cc: v6ops , 6man 6man , secdir@ietf.org, Mark Townsley Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case Date: Tue, 18 Aug 2009 19:00:42 +0200 To: Gabi Nakibly X-Mailer: Apple Mail (2.753.1) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Gabi, First, thanks to you and your colleagues for this research, and for =20 the clear presentation of its results. In my understanding, your contribution is important for transition =20 solutions to be carefully selected, and where needed improved. This mail is to complement the analysis with what applies to 6rd. For those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is an =20= automatic tunnel mechanism in actual use for IPv6 across IPv4 clouds. With it, service providers can offer native IPv6 to their customers =20 while using for this their existing IPv4 infrastructures. Publication of the RFC that describes it, RFC 5569, has been delayed =20 since May for a reason related to intellectual property rights =20 applicable to independent submissions. But the draft on which 6rd is based is still available, and a new =20 draft to extend its applicability is also available: - tools.ietf.org/html/draft-despres-6rd-03 - tools.ietf.org/html/draft-townsley-ipv6-6rd-01 (1) Case of ISPs that operate 6rd relays and no 6to4 relays (and =20 neither Teredo relays nor ISP-infrastructure NATs) In its sec. 3, draft-despres-6rd-03 says: <<< The IPv4 anycast address of 6rd relays may be chosen =20 independently by each ISP. The only constraint is that routes toward the ISP that =20= are advertised must not include this address. >>> In view of your study and in my understanding, it should be completed =20= with: "Also, the ISP must not forward toward the global IPv4 global =20 Internet packets having this address as source." With this, an ISP that operates 6rd relays but operates neither 6to4 =20 relays nor Teredo relays nor NATs is immune to the routing loop =20 attack because: - An IPv6 packet forwarded to the IPv6 Internet by a 6rd relay cannot =20= come back to an IPv4 interface of a 6rd relay of the same ISP: there =20 is no IPv4 route back to the ISP for its 6rd anycast address. - An IPv6 packet received from the IPv6 Internet by a 6rd relay =20 cannot be sent back to the IPv4 global Internet: the source address =20 of its IPv4 encapsulating packet is the 6rd anycast address, which =20 prevents it from reaching the IPv4 global Internet. Note that, if interfaces of the ISP to the IPv4 global Internet are =20 already subject to ingress filtering (packets received by the global =20 Internet are discarded if there is no reverse path available for =20 them), the added sentence is not necessary. It is just just a double =20 precaution for cases where such ingress filtering doesn't apply. (2) Case of ISPs that operate 6rd relays AND 6to4 relays (but neither =20= Teredo relays nor ISP-infrastructure NATs) In its sec. 5 on security, draft-despres-6rd-03 says: <<< o RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd address that matches the IPv4 source. The IPv6 destination must not start with the ISP 6rd prefix. ... o RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a =20= 6rd address of the ISP. The IPv4 destination must not be multicast, i.e. must not start with 224/3... >>> In view of your study and in my understanding, it MUST be completed =20 with: - after the first quoted paragraph: "Furthermore, if the ISP also operates 6to4 relays that advertise on =20 the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source must =20= be neither the 6to4 anycast address 192.88.99.0 nor any of its =20 equivalent IPv4 unicast addresses." - after the second quoted paragraph: "Furthermore, if the ISP also operates 6to4 relays that advertise on =20 the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 destination =20= derived from the IPv6 destination must be neither the IPv4 anycast =20 address 192.88.99.0 nor any of its equivalent IPv4 unicast addresses." With this, an ISP that operates both 6rd and 6to4 relays is also =20 immune to the routing-loop attack because: - an IPv6 packet forwarded to the global Internet by 6rd relays can =20 come back to the ISP IPv4 network via one of the 6to4 relays of the =20 ISP BUT cannot be accepted again by a 6rd relay: its IPv4 source =20 address is then one of a 6to4 relay, which, with the first added =20 sentence, prevents it from being accepted by the 6rd relay. - an IPv6 packet received from the IPv6 Internet by a 6rd relay =20 cannot be sent back to the IPv4 global Internet via one of the 6to4 =20 relays: the IPv4 address derived from its IPv6 destination would have =20= for this to be one of a 6to4 relays, which, with the second added =20 sentence, prevents it from being forwarded by the 6rd relay. Note: RFC 3068, where the 6to4 anycast address is introduced, says =20 that "each 6to4 relay router that advertise the 6to4 anycast prefix =20 MUST also provide an equivalent IPv4 unicast address". Whether this =20 is really important in practice is IMHO unclear. On the other hand, =20 if this MUST is dispensed with, the above security precaution can be =20 implemented in 6rd relays without a need to handle a variable number =20 of addresses, and to administratively configure them (with the =20 associated risks of human errors). To conclude: - Without needing to modify 6to4 relays, ISATAP relays, and Teredo =20 relays, ISPs that support 6rd and don't support 6to4 appear to be =20 already protected against routing loop attacks if ingress filtering =20 is operational at their interfaces to the IPv4 global Internet. With =20 an additional simple precaution in 6rd relays, they can also be =20 immune in the absence of such filtering. - A necessary additional security precaution against routing-loop =20 attacks is now identified for ISPs that support 6rd and that, having =20 started with 6to4, wish to keep it for backward compatibility. Thanks =20= again for your analysis which made it possible. Best regards, RD Le 17 ao=FBt 09 =E0 17:21, Gabi Nakibly a =E9crit : > Hi all, > I would like to draw the attention of the list to some research =20 > results which my colleague and I at the National EW Research & =20 > Simulation Center have recently published. The research presents a =20 > class of routing loop attacks that abuses 6to4, ISATAP and Teredo. =20 > The paper can be found at: http://www.usenix.org/events/woot09/tech/=20= > full_papers/nakibly.pdf > > Here is the abstract: > IPv6 is the future network layer protocol for the Internet. Since =20 > it is not compatible with its predecessor, some interoperability =20 > mechanisms were designed. An important category of these mechanisms =20= > is automatic tunnels, which enable IPv6 communication over an IPv4 =20 > network without prior configuration. This category includes ISATAP, =20= > 6to4 and Teredo. We present a novel class of attacks that exploit =20 > vulnerabilities in these tunnels. These attacks take advantage of =20 > inconsistencies between a tunnel's overlay IPv6 routing state and =20 > the native IPv6 routing state. The attacks form routing loops which =20= > can be abused as a vehicle for traffic amplification to facilitate =20 > DoS attacks. We exhibit five attacks of this class. One of the =20 > presented attacks can DoS a Teredo server using a single packet. =20 > The exploited vulnerabilities are embedded in the design of the =20 > tunnels; hence any implementation of these tunnels may be =20 > vulnerable. In particular, the attacks were tested against the =20 > ISATAP, 6to4 and Teredo implementations of Windows Vista and =20 > Windows Server 2008 R2. > > I think the results of the research warrant some corrective action. =20= > If this indeed shall be the general sentiment of the list, I will =20 > be happy write an appropriate I-D. The mitigation measures we =20 > suggested in the paper are the best we could think of to completely =20= > eliminate the problem. However they are far from perfect since they =20= > would require tunnel implementations to be updated in case new =20 > types of automatic tunnels are introduced. > > Your comments are welcome. > > Gabi > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Tue Aug 18 13:54:30 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF8C3A6C2E for ; Tue, 18 Aug 2009 13:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.782 X-Spam-Level: X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 a6Z3kqx+o0TG for ; Tue, 18 Aug 2009 13:54:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 434053A6A17 for ; Tue, 18 Aug 2009 13:53:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVcT-000O2a-KB for v6ops-data0@psg.com; Tue, 18 Aug 2009 20:49:25 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdVcL-000O1N-Vj for v6ops@ops.ietf.org; Tue, 18 Aug 2009 20:49:22 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACOwikpAZnmf/2dsb2JhbAC/X4gtLgiQIQWCKgMQCAiBTIFT X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="scan'208";a="54568092" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2009 20:49:16 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7IKnGYa019886; Tue, 18 Aug 2009 16:49:16 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7IKnGC8000764; Tue, 18 Aug 2009 20:49:16 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.3959); Tue, 18 Aug 2009 16:49:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Posted a new copy of CPE Rtr draft Date: Tue, 18 Aug 2009 16:49:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posted a new copy of CPE Rtr draft Thread-Index: AcoJVCY1e15FhBmoSWyBV29pln679gV95gDgAABw1OA= References: From: "Hemant Singh (shemant)" To: "Iljitsch van Beijnum" , "Wes Beebee (wbeebee)" Cc: "Hemant Singh (shemant)" , X-OriginalArrivalTime: 18 Aug 2009 20:49:15.0000 (UTC) FILETIME=[58E95780:01CA2045] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23086; t=1250628556; x=1251492556; 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=20Posted=20a=20new=20copy=20of=20CPE=20Rt r=20draft |Sender:=20 |To:=20=22Iljitsch=20van=20Beijnum=22=20,=0A=20=20=20=20=20=20=20=20=22Wes=20Beebee=20(wbeebee)=22= 20; bh=D2LbOe/NWUThF+F0eABBQwgDI4GmsNiE4fconiHwulE=; b=KBpWmmle02MqyO9ANUZpp/YUFcBkCrLytqSSu0YbyJrzwaYFgulmgXB0kL HU3UkOu5fe9mG92gcI1UzfU4NpzuCw3TvvpCAg/jTV7rpdzF9qCb6F968TpU N5XOPm5PIN; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Iljitsch, Sorry for the delayed reply - as you know I was out on vacation to India for a month and got back to work on August 3, 2009. I am finally catching up with all my emails. Thanks much for the review. I and Wes discussed your questions and have responses ready. Please see our replies in line below. >-----Original Message----- >From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 >Sent: Monday, July 20, 2009 12:07 PM >To: Hemant Singh (shemant) >Cc: IPv6 Operations; Wes Beebee (wbeebee) >Subject: Re: Posted a new copy of CPE Rtr draft >>On 6 mrt 2009, at 23:27, Hemant Singh (shemant) wrote: >> http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-04.txt >>now v6ops-ipv6-cpe-router-00, right? Yes. >Not having read the subsequent discussion yet, here is my feedback: >Most important issue: >"The CPE Router may also support prefix sub-delegation." >We should make this a MUST. I don't want to end up in the situation where I get a crappy DSL IPv6 CPE from my ISP and I can't use my own CPE because there is no subdelegation. I agree with you. If the WG agrees, we'd be happy to change this one to a MUST. >If that's too hard, then we must mandate the ability for ISP-provided CPEs to run in bridge mode. (But then that CPE would probably still need a global address for management.) Preferably the ISP->provided CPE would go in bridge mode automatically when a more capable CPE is present. I guess this could happen if the ISP-CPE receives a PD request. Yes, since the home-CPE behind the ISP-CPE will not send RA upstream, I think so too when the first time the ISP-CPE knows it has a home-CPE rtr behind it is when the home-CPE issues a DHCPv6 SOLICIT with an IA_PD option. I am not sold on the bridged mode yet. We will have to discuss this more later. >In general, information is often repeated. Some repetition is deliberate. We can remove any other when we find any of it. >"A CPE Router is an IPv6 Node" >I would think it's a router... Or do you guys mean that in addition to being a router, it must also fulfill the node requirements? If so, may want to say so explicitly here. We didn't want to be any more specific that our existing text because all we wanted to say was the device for baseline functionality is what is specified in the IPv6 Node requirements (req) because the Node reqs doc also specifies some router behavior. Over the baseline of the IPv6 Node reqs, since the device is comprised of a router, bridge, and a switch, the behavior and requirements get complex and such complexity is what is dealt with in such a CPE Rtr draft.=20 >"The WAN interface is preferred to be Ethernet encapsulated but it may support other encapsulations such as PPP." >What about ATM? (I used native IPv6 over ADSL =3D ATM with a Cisco >826/827 for years.) Sure. We just gave PPP as an example. ATM or Firewire, or what have you, is still totally supported because we say any other encapsulation besides Ethernet may be supported. We can also remove the "preferred Ethernet" case. >"If no LAN interface is present" >Then what is the function of the CPE? > Before the CPE Router is initialized, the device must have IPv6 > enabled. The CPE Router SHOULD support the ability to disable its > IPv6 stack. The CPE Router also has the ability to block or forward > IPv6 traffic to and from the router's LAN interface(s). [RFC2669] > includes a MIB definition to block the IPv4 or IPv6 Ethertype in the > upstream or downstream interface(s) of a device such as the CPE > Router. Some portion of this MIB may need to be modified for use > with the CPE Router. >This kind of detail has the potential to obscure the forrest with largely unnecessary trees. On the other hand it's also not so detailed that it fully specifies what an implementation is supposed to do. >But different vendors are likely to have different opinions on that, anyway. And if v6 can be disabled, why not v4? We only added text discussing blocking of v6 traffic on the CPE Rtr LAN interface(s) since we are putting together an IPv6 CPE Rtr specification and not an IPv4 one. However, since our paragraph above also mentioned RFC2669, note that we say either of v4 or v6 can be blocked as shown how in this RFC. >"The CPE Router MUST support at least one of two WAN interface models," >It takes very long until the other shoe drops, would be better to just say "numbered and unnumbered" and then start a new paragraph for the discussion of the numbered model. We have thrashed a lot on this sentence and after agreement from a lot of folks that such a sentence exists. I think it is fine to keep the sentence as is because let a CPE Rtr vendor decide if they have to implement both or at least one of the two WAN interface models. After all, after this sentence, the ensuing text does discuss the numbered and the unnumbered models. =20 > In the Numbered model, the WAN interface acquires a global unicast > address (GUA) using a combination of SLAAC and stateful DHCPv6 for > IA_PD (no IA_NA) or uses only stateful DHCPv6 for GUA (IA_NA) >So the CPE is required to support address assignment for its WAN interface with both DHCPv6 and stateless autoconfig? I don't like that. What we mean to say is the WAN interface can acquire a GUA using SLAAC and then use stateful DHCPv6 to acquire an IA_PD because neither stateless DHCPv6 nor SLAAC support obtaining IA_PD. Also, if the WAN interface acquires a GUA using stateful DHCPv6, then the WAN can request both IA_NA and IA_PD in one DHCPv6 transaction set. The IA_NA DHCPv6 option is related to obtaining the GUA. >"A Loopback interface" >I would say "assigning a stable global unicast address to a loopback interface" so as to not confuse people who live in a host-based world where loopback interfaces have ::1 as their address. Perfect suggestion. Here is the new text. [Assigning a stable global unicast address to a loopback interface (which can be used as a stable peering point for routing protocols or to respond to the anycast address) is optional.] For reference, the old text was: [A Loopback interface (which can be used as a stable peering point for routing protocols or to respond to the anycast address) is optional.] >"The IA_PD is sub-delegated to the LAN interface(s)" >I would say "/64 subprefixes of the IA_PD provided prefix are assigned to a LAN interface or multiple LAN interfaces. If the IA_PD only provides a /64 (which is NOT recommended) this prefix is assigned >to one LAN interface." We have already mentioned such text in our document. Could you please look in the Cascading Routers section. >"Either the Loopback or the LAN interface can be used to source WAN- facing traffic." >Like what? (I guess NTP or something like that...) Oh, this is any traffic from the LAN in the home that needs to head out the WAN interface to the SP. >"if the O bit is set in the RA, the WAN interface acquires other configuration information." >What if the O bit is not set? Doesn't the CPE always initiate stateful >DHCPv6 in order to obtain a prefix? A delegated prefix or the IA_PD can only be requested using stateful DHCPv6. M and O bits is contentious in the 6man and elsewhere, but if the M bit is set, supposedly the network has a stateful DHCPv6 server that clients can obtain IA_NA or GUA from using stateful DHCPv6. Stateful DHCPv6 acquires the Other information as well such as IPv6 address of the DNS server. If the O bit is not set, and if the WAN interface has obtained GUA using SLAAC, then stateless DHCPv6 is initiated to get Other information since the M-bit is set in the RA. >"Other IPv6 configuration information is obtained using stateless DHCPv6." >I don't think it makes sense to perform both stateful and stateless DHCPv6. Yes, it does. See my responses above. >"The Unnumbered model is incompatible with the strong host model [RFC1122] on the CPE router" >Which is irrelevant, the CPE is a ROUTER, and there are no "strong" =20 >routers, only "strong" hosts. >"where a device that uses the strong host model can operate as a CPE Router." >Such devices must not be allowed. NTT in Japan already has such devices deployed. Please look in v6ops archives for the CPE Rtr document and search for Shin M. who asked for such text to be put in the CPE Rtr. They are using Windows PC with their own hacked up router code. >"The CPE Router may include a stateful DHCPv6 server to assign addresses to home devices connected via the LAN interface(s) of the CPE Router." >That seems rather pointless. And because it's only a MAY there's no need to specifically point this out in the text. If one gets to the CPE Rtr next section related to Cascading of routers, then one can see why a DHCPv6 server is needed and also a MAY. You see, to cascade CPE Rtrs one needs either a DHCPv6 server in the CPE Rtr or a DHCPv6 relay.=20 >But I guess this means that DHCPv6 requests done by hosts on the LAN side are never propagated to the ISP? All DHCPv6 requests between a client and server terminate at the server, so the client DHCPv6 reqs are not expected to propagate to the ISP. >"The home devices can also acquire addresses via SLAAC." >That's not very specific. Needs to be: the CPE MUST send router advertisements with a prefix option once a prefix is available. Not quite. What if the LAN wants to do DHCPv6 and not SLAAC. I think we can make the SLAAC as default and allow a configuration change to change SLAAC to DHCPv6. > If the IA_PD changes, the CPE Router must reconfigure > the LAN interface(s) with new IPv6 addresses derived from the new > IA_PD and then also renumber the IPv6 ND RA configuration on the LAN > interface(s). >Need to explain that the old and the new prefixes must overlap for some time to allow for graceful renumbering. Both RFC 4862 and 4861 mention graceful renumbering. We can add a sentence to our document saying to keep graceful renumbering in mind or maybe not... > This document recommends the RA sent out by LAN Interface(S) to be > configured for SLAAC so that the prefix advertised in the RA is > derived from the IA_PD assigned to the CPE Router by the Service > Provider; >Requires > the O-bit is also set so that the CPE Router can pass > Domain Name Server(s) IPv6 address(es) to home devices. >Only if the CPE implements a stateless DHCPv6 server that redistributes the DHCPv6 info the router itself got from the ISP, or if the router acts as a DHCPv6 relay. Or the CPE Rtr has a stateful DHCPv6 server which can dole out Other parameters. >How are ULAs for configuration supposed to work? Obviously you can't print the address for configuration in the manual (it being randomly generated and all). So at the very least this has to work >through the DNS. The problem is: how do you get rid of the ULA addresses on hosts once global addresses are available? Please see archives of v6ops for the ULA discussion that closed the ULA issue by agreeing with us to keep ULA permanent on the CPE Rtr. So the ULA is not going away if the GUA is acquired. That is why in section 5.5.1 we mention source address selection. As for DNS, since it's a local DNS server in the CPE Rtr the local DNS will return entries for both the GUA and the ULA. =20 >The only time ULAs outperform link locals is in the case of cascaded CPEs where you want to go from host X to CPE A through CPE B. With link locals that wouldn't work. >An alternative for the configuration address would be a well-known address, so users can be told to go to 2001:db8::1. This could work with link locals on the hosts as long as CPEs aren't cascaded. Rather than use any well-known address, we have proposed http://router.local in section 8.4. By definition of Bonjour is limited to the link-local domain. > initiates L2TPv2 tunnel from > the CPE Router to tunnel IPv6 data from the home over an IPv4 > network. The feature is enabled before any IPv6 host in the home is > connected to the CPE Router or the WAN interface of the CPE Router is > operational. >What does this mean? Section section 3.1.1, Figure 1 of the softwires draft referenced in this section. >It is important that delays or failure with the softwire stuff doesn't delay the initiation of native IPv6. Sure. Now that this whole section has moved to our "bis" CPE Rtr document, we have just referenced the DS-Lite draft which is turn discusses softwires etc. Any failures with softwire has to be discussed in the softwire draft. Please note, after the San Francisco IETF in Spring 2009, it was decided in the v6ops WG that our draft be broken up into two drafts. The first document would only discuss tech already in RFC form and/or mature tech so that the document could be expedited in the IETF RFC process. A second document (which I refer to as the bis draft) tracks all the Work In Progress including DS-lite, softwires, etc. We will submit the bis version as an individual submission to the IETF sometime this week; we will also submit a new version of the Phase I draft alongwith it. >Also, "softwires" is the IETF wg, please use the name of the protocol. So far I have not seen the name of the protocol related to softwire. Even DS-lite that mentions it uses the term softwire. I will double check with folks and if a formal name exists, we will replace the term softwire in our document(s). =20 >Why is this under the PPP heading? See Figure 1 in section 3.1.1 in http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2-13#se ction-3.1 Softwire is using PPP for some control. However, now this softwire section is gone to the bis draft and trimmed down for text as well. >5.7. Stateful DHCPv6 Server (CORE) > The CPE Router may support a stateful DHCPv6 server to serve clients > on the CPE Router LAN interface(s) >Core but not a requirement??? The reason is because one may be able to get by with just a DHCPv6 relay.=20 > If the CPE router supports > cascading of routers through automatic prefix sub-delegation, the CPE > router MUST support a DHCPv6 server or DHCPv6 relay agent. >(see above). Having a server or a relay are very different for the ISP, not good to leave both options open because now the ISP has to support both. Valid point. We do want to change the DHCPv6 server to a MUST if the WG has no objection. >Is it mentioned anywhere that if a CPE supports subdelegation, it must also be capable of installing routes towards the router that has a subdelegation? The Cascading routers section has following text: [The CPE Router MAY support RIPng in the home network.] If not RIPng some simple static routes are easy to auto-provision as addresses are doled out to downstream clients. We can add a sentence towards this effect. >"The CPE Router MAY support RIPng in the home network." >For what purpose? RIP is a terrible routing protocol... We have legitimate requirements from the community that the home may support more than one routers connected to more than one ISP domain. For example, one router is connected to a cable modem and the other router is connected to a DSL modem. For these two routers in the home, RIPng is suggested. A future version of this document will include use cases and such a two router case makes sense to add for a use case. > Each of the WAN and LAN interface(s) of the CPE Router must have its > own L2 (e.g. MAC) address. >Why? This may make vendors limit the number of interfaces. Number of interfaces is not limited. Router vendors implement virtual network interfaces via software over the hardware network interfaces. Each of WAN and LAN interface is a hardware port with a hardware address on the CPE Rtr. Over any one hardware address, numerous software network interfaces could be developed. >"The CPE Router supports ND protocol" >the ND protocol > both the WAN interface and LAN interface(s) to advertise itself as a > router to neighbors in the Service Provider and home networks. >You mean it sends RAs on the WAN side? Why??? On the WAN side, the CPE Rtr sends an RS. We will reword this sentence to: [The CPE Router supports ND protocol on both the WAN interface and LAN interface(s) and sends Router Solicitations (RS) on the WAN interface and sends Router Advertisement(s) (RA) on the LAN interface(s).] > If the CPE Router has only one /64 prefix to be used across multiple > LAN interfaces and the CPE Router supports any two LAN interfaces > that cannot bridge data between them because the two interfaces have > disparate MAC layer, then the CPE Router MUST support ND Proxy > [RFC4389]. >No, This will just be used as a reason for ISPs to give users less than a /64. If they do that, simply configure 1 LAN interface, no special case handling. >"Legacy 3GPP networks have the following requirements:" >I think it would serve the document better to keep such unusual cases out of it. Please discuss with Nokia and Teemu who is also working with Qualcomm - they wanted such a section to full their needs from this document. This document is defining a generic IPv6 Rtr that can be used in any deployment, so why not let the legacy 3GPP folks use this document. Just by adding a ND Proxy section to this document fulfills their needs. We have taken special care in this section to clearly say, please use ND Proxy only under this legacy 3GPP deployment. > For these legacy 3GPP networks, the CPE Router MUST support ND Proxy > between the WAN and LAN interface(s). However, if the CPE Router has > multiple prefixes available for use on LAN interfaces(s), then ND > Proxy is not necessary. First a MUST and then "not necessary" is far from ideal specification writing... Does the change of the sentence beginning with "However" above looks better to you: [If a CPE Router will never be deployed in an environment with these characteristics, then ND Proxy is not necessary.]. >About multicast: what happens on wifi, which can't handle non-minimal amounts of multicast traffic? (Also see the multicast discussion on the homegate list.) We have not discussed wifi in the CPE Rtr yet. Yes, I have seen the mcast discussion on the homegate list where folks are talking above converting the traffic to unicast or bcast? We have to see what is mature tech here to add to the CPE Rtr document if the community agrees. > If the CPE Router hardware includes a network bridge between the WAN > interface and the LAN interface(s), then the CPE Router MUST support > MLDv2 snooping as per [RFC4541]. >Can't it just treat multicasts as broadcasts? That's why cheap switches do AFAIK. I would rather not have MLD snooping, because if implemented incorrectly it breaks the network in severe ways. (Like >boxes that didn't pass IPv6 multicasts because of IGMP snooping.) If there are issues/bugs with MLD Snooping, it's a bug. Anyhow, one has to take that up with the IETF mcast groups that discuss MLD Snooping protocols. =20 >"8.1. Path MTU Discovery Support (MEDIUM)" >Why medium? This is absolutely essential to avoid PMTUD black holes, one of the scurges of today's internet in general and the IPv6 internet in particular. The language here MUST be much sharper. The reason for the MEDIUM designation was to indicate that work is ongoing on this subject and the industry has not yet reached consensus on the right way to address this. It's not an indicator that the work is not important - to the contrary, we agree that the work is very important. >"Ethernet Jumbo frames (9000+ bytes)" >Jumboframes is anything bigger than 1500 bytes. Sorry, it's a mistake. Will change to (> 1500 bytes). > The CPE Router may support RIPng routing protocol [RFC2080] so that > RIPng operates between the CPE Router and the Service Provider > network. >Have you talked to ISPs about this? Not only is RIP slow, it's also insecure. I don't think they want this headache. And what if the ISP redistributes 50000 prefixes from other customers to the CPE? We are talking to ISPs and also in this mailer. ISPs do not like using RIPng but we would like to point out that if RIPng is not used then how does the SP network know of delegated prefix routes? IETF has seen a few proposals on this PD route injection but none of the proposals have any traction yet - I have not seen any RFC on this subject. That is why we say in our draft [However, RIPng does provide one solution from the CPE Router to the Service Provider network for prefix route injection] >Besides, "MAY" is useless. If 99 CPE vendors support RIP and 1 doesn't then the ISPs still can't use it. We hear you on the MAY's. However, note, the MAY's are due to some decisions not made in the IETF for how certain things are going to work in the residential broadband network. Some time is needed for things like a route injection to gestate and we cannot treat route injection as a future item - it's a problem that needs to be solved for a delegated prefix network. >"The firewall may" >Again, "may" language is useless. There must be a list of the extension headers that firewalls must support. The extension headers is still Work in Progress. Anyway we have referenced the Woodyatt CPE simple security draft that should deal with any such firewall issues. This section has also moved to our bis draft. >"CPE Router MAY initiate ISATAP" >How would that work?? The CPE Rtr must always try 6rd first and if that fails then the rtr should try 6to4 and once that fails, then I think it makes sense the device can try ISATAP. Either one has the ISATAP PRL manually provisioned on the rtr or ISATAP queries for the PRL with DNS. I am personally not sold on ISATAP at all, but Fred Templin asked for ISATAP to be included in the CPE Rtr. If others in the community do not want ISATAP in the CPE Rtr, then we can remove it. > softwires. Further, any approach which requires the use of a tunnel > MUST take into account the reduced MTU. >Would be useful to include an MTU option in RAs that reflects the usable maximum packet size on the WAN side. RFC4861 already mentions such a fact in section 4.2 with the RA MTU option. >"An AAAA record is relayed to the server." >This sentence doesn't make any sense. >Please refer to the DNS64 document, a CPE either needs to do it right or not do it at all. This section has been reworked for the two new documents. DNS64 bagnulo draft is now mentioned in the bis document. Hemant From owner-v6ops@ops.ietf.org Tue Aug 18 14:16:45 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A62F3A6B7D for ; Tue, 18 Aug 2009 14:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 lZXC7yWrkiTP for ; Tue, 18 Aug 2009 14:16:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39D983A6E67 for ; Tue, 18 Aug 2009 14:16:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdW1S-00022f-Rr for v6ops-data0@psg.com; Tue, 18 Aug 2009 21:15:14 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdW1M-00021P-Vf for v6ops@ops.ietf.org; Tue, 18 Aug 2009 21:15:12 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id BFED328C3A9; Tue, 18 Aug 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090818211501.BFED328C3A9@core3.amsl.com> Date: Tue, 18 Aug 2009 14:15:01 -0700 (PDT) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 CPE Router Recommendations Author(s) : H. Singh, W. Beebee Filename : draft-ietf-v6ops-ipv6-cpe-router-01.txt Pages : 21 Date : 2009-08-18 This document recommends IPv6 behavior for Customer Premises Equipment (CPE) routers in Internet-enabled homes and small offices. The CPE Router may be a standalone device. The CPE Router may also be embedded in a device such as a cable modem, DSL modem, cellular phone, etc. This document describes the router portion of such a device. The purpose behind this document is to provide minimal functionality for interoperability and create consistency in the customer experience and satisfy customer expectations for the device. Further, the document also provide some guidance for implementers to expedite availability of IPv6 CPE router products in the marketplace. It is expected that standards bodies other than the IETF developing standards for specific products in this area (e.g. CableLabs eRouter, Broadband Forum, Home Gateway Initiative, etc.) may reference this work for basic functionality and provide value-added or linktype-specific customizations and enhancements which are beyond the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-v6ops-ipv6-cpe-router-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-18140515.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Tue Aug 18 14:20:15 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75D713A6ADF for ; Tue, 18 Aug 2009 14:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 SKk1HR-YeWYJ for ; Tue, 18 Aug 2009 14:20:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26EFA3A6938 for ; Tue, 18 Aug 2009 14:20:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdW5k-0002ao-Qh for v6ops-data0@psg.com; Tue, 18 Aug 2009 21:19:40 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdW5g-0002ZF-FK for v6ops@ops.ietf.org; Tue, 18 Aug 2009 21:19:38 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFi4ikpAZnmf/2dsb2JhbACZYKVyiC2QYAWEGYFT X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="scan'208";a="54571187" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2009 21:19:22 +0000 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 n7ILJMJ9001613 for ; Tue, 18 Aug 2009 17:19:22 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7ILJMYu029054 for ; Tue, 18 Aug 2009 21:19:22 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.3959); Tue, 18 Aug 2009 17:19:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: FW: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Date: Tue, 18 Aug 2009 17:19:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Thread-Index: AcogR5sPMTp9vGcPRUiqGisolv/kKAAAZUog From: "Hemant Singh (shemant)" To: Cc: "Hemant Singh (shemant)" , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 18 Aug 2009 21:19:22.0188 (UTC) FILETIME=[8E1458C0:01CA2049] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2924; t=1250630362; x=1251494362; 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=20dr aft-ietf-v6ops-ipv6-cpe-router-01=20 |Sender:=20 |To:=20; bh=qiidHKmPztamuWPPMhUlqsNBSAQG9WRaC5q+epVPxwU=; b=lzVa9FpeR4BXkrTFyZ09L7TKA8C2oefswCpl2LwSx8GCk2o+Mxhx7bov1E YqMMAZTWVqViXPUVeSxvefq+ON+FDVhEA0X3GBkiWo+RXMIXA5oNVTc4fAhd 3dFK10Pmln; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Rm9sa3MsDQoNClRoaXMgaXMgdGhlIGxhc3QgdmVyc2lvbiBvZiB0aGUgSVB2NiBDUEUgUm91dGVy IFJlY29tbWVuZGF0aW9ucyB3aXRoIEkgYW5kIFdlcyBhcyBhdXRob3JzLiAgVGhlIG5leHQgcmV2 aXNpb24gd2lsbCBpbmNsdWRlIE9sZSBUcm9hbiBhbmQgQ2hyaXMgRG9ubGV5IGFzIGNvLWF1dGhv cnMuDQpTaW5jZSBTYW4gRnJhbmNpc2NvIElFVEYgaW4gU3ByaW5nIDIwMDksIGEgZGVjaXNpb24g d2FzIG1hZGUgdG8gc3BsaXQgdXAgdGhlIGRvY3VtZW50IGludG8gdHdvLiAgVGhlIHNlY29uZCBk b2N1bWVudCBoYXMgYWxzbyBiZWVuIHBvc3RlZCB0b2RheSBhcyBkcmFmdC13YmVlYmVlLXY2b3Bz LWlwdjYtY3BlLXJvdXRlci1iaXMtMDAudHh0Lg0KDQpIZW1hbnQNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3Vi bWlzc2lvbkBpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTgsIDIwMDkgNTowNSBQ TQ0KVG86IEhlbWFudCBTaW5naCAoc2hlbWFudCkNCkNjOiBXZXMgQmVlYmVlICh3YmVlYmVlKQ0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXY2b3BzLWlw djYtY3BlLXJvdXRlci0wMSANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi12 Nm9wcy1pcHY2LWNwZS1yb3V0ZXItMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWx5IHN1Ym1pdHRl ZCBieSBIZW1hbnQgU2luZ2ggYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpG aWxlbmFtZToJIGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1jcGUtcm91dGVyDQpSZXZpc2lvbjoJIDAx DQpUaXRsZToJCSBJUHY2IENQRSBSb3V0ZXIgUmVjb21tZW5kYXRpb25zDQpDcmVhdGlvbl9kYXRl OgkgMjAwOS0wOC0xOA0KV0cgSUQ6CQkgdjZvcHMNCk51bWJlcl9vZl9wYWdlczogMjENCg0KQWJz dHJhY3Q6DQpUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMgSVB2NiBiZWhhdmlvciBmb3IgQ3VzdG9t ZXIgUHJlbWlzZXMNCkVxdWlwbWVudCAoQ1BFKSByb3V0ZXJzIGluIEludGVybmV0LWVuYWJsZWQg aG9tZXMgYW5kIHNtYWxsIG9mZmljZXMuDQpUaGUgQ1BFIFJvdXRlciBtYXkgYmUgYSBzdGFuZGFs b25lIGRldmljZS4gIFRoZSBDUEUgUm91dGVyIG1heSBhbHNvDQpiZSBlbWJlZGRlZCBpbiBhIGRl dmljZSBzdWNoIGFzIGEgY2FibGUgbW9kZW0sIERTTCBtb2RlbSwgY2VsbHVsYXINCnBob25lLCBl dGMuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgcm91dGVyIHBvcnRpb24gb2Ygc3VjaCBh DQpkZXZpY2UuICBUaGUgcHVycG9zZSBiZWhpbmQgdGhpcyBkb2N1bWVudCBpcyB0byBwcm92aWRl IG1pbmltYWwNCmZ1bmN0aW9uYWxpdHkgZm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIGNyZWF0ZSBj b25zaXN0ZW5jeSBpbiB0aGUNCmN1c3RvbWVyIGV4cGVyaWVuY2UgYW5kIHNhdGlzZnkgY3VzdG9t ZXIgZXhwZWN0YXRpb25zIGZvciB0aGUgZGV2aWNlLg0KRnVydGhlciwgdGhlIGRvY3VtZW50IGFs c28gcHJvdmlkZSBzb21lIGd1aWRhbmNlIGZvciBpbXBsZW1lbnRlcnMgdG8NCmV4cGVkaXRlIGF2 YWlsYWJpbGl0eSBvZiBJUHY2IENQRSByb3V0ZXIgcHJvZHVjdHMgaW4gdGhlIG1hcmtldHBsYWNl Lg0KSXQgaXMgZXhwZWN0ZWQgdGhhdCBzdGFuZGFyZHMgYm9kaWVzIG90aGVyIHRoYW4gdGhlIElF VEYgZGV2ZWxvcGluZw0Kc3RhbmRhcmRzIGZvciBzcGVjaWZpYyBwcm9kdWN0cyBpbiB0aGlzIGFy ZWEgKGUuZy4gIENhYmxlTGFicw0KZVJvdXRlciwgQnJvYWRiYW5kIEZvcnVtLCBIb21lIEdhdGV3 YXkgSW5pdGlhdGl2ZSwgZXRjLikgbWF5DQpyZWZlcmVuY2UgdGhpcyB3b3JrIGZvciBiYXNpYyBm dW5jdGlvbmFsaXR5IGFuZCBwcm92aWRlIHZhbHVlLWFkZGVkDQpvciBsaW5rdHlwZS1zcGVjaWZp YyBjdXN0b21pemF0aW9ucyBhbmQgZW5oYW5jZW1lbnRzIHdoaWNoIGFyZSBiZXlvbmQNCnRoZSBz Y29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg== From owner-v6ops@ops.ietf.org Tue Aug 18 14:22:55 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB1528C208 for ; Tue, 18 Aug 2009 14:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.937 X-Spam-Level: X-Spam-Status: No, score=-3.937 tagged_above=-999 required=5 tests=[AWL=-1.442, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_44=1, J_BACKHAIR_46=1, RCVD_IN_DNSWL_MED=-4, 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 nggw4bfrJILr for ; Tue, 18 Aug 2009 14:22:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF69F3A6B23 for ; Tue, 18 Aug 2009 14:22:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdW87-000331-BC for v6ops-data0@psg.com; Tue, 18 Aug 2009 21:22:07 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdW83-00031X-6R for v6ops@ops.ietf.org; Tue, 18 Aug 2009 21:22:05 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7ILLQtY026939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2009 16:21:26 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7ILLPiH006485; Tue, 18 Aug 2009 16:21:25 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7ILLNDL006389; Tue, 18 Aug 2009 16:21:25 -0500 (CDT) 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.3959); Tue, 18 Aug 2009 14:21:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Posted a new copy of CPE Rtr draft Date: Tue, 18 Aug 2009 14:21:21 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1064DB00C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posted a new copy of CPE Rtr draft Thread-Index: AcoJVCY1e15FhBmoSWyBV29pln679gV95gDgAABw1OAAPrk/sA== References: From: "Templin, Fred L" To: "Hemant Singh (shemant)" , "Iljitsch van Beijnum" , "Wes Beebee (wbeebee)" Cc: X-OriginalArrivalTime: 18 Aug 2009 21:21:24.0296 (UTC) FILETIME=[D6DC8C80:01CA2049] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, > >"CPE Router MAY initiate ISATAP" >=20 > >How would that work?? >=20 > The CPE Rtr must always try 6rd first and if that fails then the rtr > should try 6to4 and once that fails, then I think it makes sense the > device can try ISATAP. Either one has the ISATAP PRL manually > provisioned on the rtr or ISATAP queries for the PRL with DNS. I am > personally not sold on ISATAP at all, but Fred Templin asked for ISATAP > to be included in the CPE Rtr. If others in the community do not want > ISATAP in the CPE Rtr, then we can remove it. I asked for ISATAP to show up in the CPE Rtr document, but I asked for it to show up inside the customer site; not on the provider side. ISATAP is for host<->router or host<->host; it is not for router<->router. So, the time ISATAP would be used in the provider network is when the CPE device is a host and not a router. On the customer side, the CPE router can serve as the ISATAP router and can be discovered by dual-stack hosts within the customer network. But, that arrangement would not be visible within the provider network. Fred fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Tue Aug 18 14:29:46 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0690E3A6C2E for ; Tue, 18 Aug 2009 14:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_44=1, J_BACKHAIR_46=1, RCVD_IN_DNSWL_MED=-4, 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 GZDgbfu0t3GB for ; Tue, 18 Aug 2009 14:29:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E72428C297 for ; Tue, 18 Aug 2009 14:29:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdWE9-00043q-UK for v6ops-data0@psg.com; Tue, 18 Aug 2009 21:28:21 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdWE6-00043O-2S for v6ops@ops.ietf.org; Tue, 18 Aug 2009 21:28:20 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPu5ikqrR7PD/2dsb2JhbAC/U4gtkGAFhBk X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="scan'208";a="369996940" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Aug 2009 21:28:17 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7ILSHsH020361; Tue, 18 Aug 2009 14:28:17 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7ILSHSf001929; Tue, 18 Aug 2009 21:28:17 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.3959); Tue, 18 Aug 2009 17:28:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Posted a new copy of CPE Rtr draft Date: Tue, 18 Aug 2009 17:28:15 -0400 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1064DB00C@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posted a new copy of CPE Rtr draft Thread-Index: AcoJVCY1e15FhBmoSWyBV29pln679gV95gDgAABw1OAAPrk/sAAAjSbA References: <39C363776A4E8C4A94691D2BD9D1C9A1064DB00C@XCH-NW-7V2.nw.nos.boeing.com> From: "Hemant Singh (shemant)" To: "Templin, Fred L" , "Iljitsch van Beijnum" , "Wes Beebee (wbeebee)" Cc: X-OriginalArrivalTime: 18 Aug 2009 21:28:16.0852 (UTC) FILETIME=[CCC39940:01CA204A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1616; t=1250630897; x=1251494897; c=relaxed/simple; s=sjdkim3002; 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=20Posted=20a=20new=20copy=20of=20CPE=20Rt r=20draft |Sender:=20; bh=IhsLZAFzMowhF4TnccxtNuKEGkEuayH1gmtarJ8xy+g=; b=Kl7QlgsG4BhPlG7+tOe5FiKM2H1UZ98w0GU83h+RyflWxrDlRtzuuPcGnl vfEQmVaPTknRIMrLdVfZbZxma+1DME/MhXPej+p1n/oGqFw3pYVhk2LJXU6j D5MdupK4Bh; Authentication-Results: sj-dkim-3; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, Thanks for the clarification. Our next revision will take care of this error in the document if ISATAP is agreed upon by the group to be included for use in the home. Hemant -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Tuesday, August 18, 2009 5:21 PM To: Hemant Singh (shemant); Iljitsch van Beijnum; Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org Subject: RE: Posted a new copy of CPE Rtr draft Hemant, > >"CPE Router MAY initiate ISATAP" >=20 > >How would that work?? >=20 > The CPE Rtr must always try 6rd first and if that fails then the rtr > should try 6to4 and once that fails, then I think it makes sense the > device can try ISATAP. Either one has the ISATAP PRL manually > provisioned on the rtr or ISATAP queries for the PRL with DNS. I am > personally not sold on ISATAP at all, but Fred Templin asked for ISATAP > to be included in the CPE Rtr. If others in the community do not want > ISATAP in the CPE Rtr, then we can remove it. I asked for ISATAP to show up in the CPE Rtr document, but I asked for it to show up inside the customer site; not on the provider side. ISATAP is for host<->router or host<->host; it is not for router<->router. So, the time ISATAP would be used in the provider network is when the CPE device is a host and not a router. On the customer side, the CPE router can serve as the ISATAP router and can be discovered by dual-stack hosts within the customer network. But, that arrangement would not be visible within the provider network. Fred fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Tue Aug 18 15:26:26 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D073A6942 for ; Tue, 18 Aug 2009 15:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_44=1, J_BACKHAIR_46=1, RCVD_IN_DNSWL_MED=-4, 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 QPM3HUvnVBnD for ; Tue, 18 Aug 2009 15:26:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 267D23A67B7 for ; Tue, 18 Aug 2009 15:26:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdX5A-000BSk-27 for v6ops-data0@psg.com; Tue, 18 Aug 2009 22:23:08 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdX56-000BS4-7u for v6ops@ops.ietf.org; Tue, 18 Aug 2009 22:23:06 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7IMMsp3026642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2009 17:22:54 -0500 (CDT) 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 n7IMMrnK028559; Tue, 18 Aug 2009 15:22:54 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7IMMri1028545; Tue, 18 Aug 2009 15:22:53 -0700 (PDT) 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.3959); Tue, 18 Aug 2009 15:22:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Posted a new copy of CPE Rtr draft Date: Tue, 18 Aug 2009 15:22:50 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1064DB09D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posted a new copy of CPE Rtr draft Thread-Index: AcoJVCY1e15FhBmoSWyBV29pln679gV95gDgAABw1OAAPrk/sAAAjSbAAAG6EbA= References: <39C363776A4E8C4A94691D2BD9D1C9A1064DB00C@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Hemant Singh (shemant)" , "Iljitsch van Beijnum" , "Wes Beebee (wbeebee)" Cc: X-OriginalArrivalTime: 18 Aug 2009 22:22:53.0445 (UTC) FILETIME=[6DC40350:01CA2052] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com] > Sent: Tuesday, August 18, 2009 2:28 PM > To: Templin, Fred L; Iljitsch van Beijnum; Wes Beebee (wbeebee) > Cc: v6ops@ops.ietf.org > Subject: RE: Posted a new copy of CPE Rtr draft >=20 > Fred, >=20 > Thanks for the clarification. Our next revision will take care of this > error in the document if ISATAP is agreed upon by the group to be > included for use in the home. OK, but to be complete the assertion is that ISATAP can be used: 1) In the customer network when the CPE acts as an ISATAP router on the customer side, and 2) In the provider network when the CPE acts as an ISATAP host on the provider side. Also missing from the spec is a discussion of VET when the CPE acts as either a VET host or a VET enterprise border router on the provider side, and there is a VET enterprise border gateway in the provider network. It may/may not be useful to characterize VET as "ISATAP version 2 (isatapv2)". Fred fred.l.templin@boeing.com >=20 > Hemant >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Tuesday, August 18, 2009 5:21 PM > To: Hemant Singh (shemant); Iljitsch van Beijnum; Wes Beebee (wbeebee) > Cc: v6ops@ops.ietf.org > Subject: RE: Posted a new copy of CPE Rtr draft >=20 > Hemant, >=20 > > >"CPE Router MAY initiate ISATAP" > > > > >How would that work?? > > > > The CPE Rtr must always try 6rd first and if that fails then the rtr > > should try 6to4 and once that fails, then I think it makes sense the > > device can try ISATAP. Either one has the ISATAP PRL manually > > provisioned on the rtr or ISATAP queries for the PRL with DNS. I am > > personally not sold on ISATAP at all, but Fred Templin asked for > ISATAP > > to be included in the CPE Rtr. If others in the community do not want > > ISATAP in the CPE Rtr, then we can remove it. >=20 > I asked for ISATAP to show up in the CPE Rtr document, but > I asked for it to show up inside the customer site; not on > the provider side. ISATAP is for host<->router or host<->host; > it is not for router<->router. So, the time ISATAP would be > used in the provider network is when the CPE device is a host > and not a router. >=20 > On the customer side, the CPE router can serve as the ISATAP > router and can be discovered by dual-stack hosts within the > customer network. But, that arrangement would not be visible > within the provider network. >=20 > Fred > fred.l.templin@boeing.com From jenneke.lelieveld@akzonobel.com Tue Aug 18 16:54:25 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D533A6C0C for ; Tue, 18 Aug 2009 16:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.437 X-Spam-Level: X-Spam-Status: No, score=-77.437 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 NeJyqSglI+mM for ; Tue, 18 Aug 2009 16:54:25 -0700 (PDT) Received: from 189-178-21-190.adsl.terra.cl (189-178-21-190.adsl.terra.cl [190.21.178.189]) by core3.amsl.com (Postfix) with SMTP id E14783A6C34 for ; Tue, 18 Aug 2009 16:54:16 -0700 (PDT) To: v6ops-archive@ietf.org Subject: Representatives Wanted From: v6ops-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090818235416.E14783A6C34@core3.amsl.com> Date: Tue, 18 Aug 2009 16:54:16 -0700 (PDT) Our company(US Surveys) is proud to inform you that we now have one secret-shopper position available.
This is a part time position as it doesn't take more then one hour to evaluate a store.
Your commission for each evaluation is $100 and you can receive assignments on daily basis.

In order to qualify for the secret-shopper position a candidate must be 21 years of age or older
and own a wellsfargo account (it is recommended to open a fresh account to be used for this position only).

If you are interested in working as a secret shopper for our company you can request more information at jazminebdovefunnyeszka@gmail.com

Thank you,
US Surveys Inc.
From owner-v6ops@ops.ietf.org Tue Aug 18 21:23:12 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D3C28C1D6 for ; Tue, 18 Aug 2009 21:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 szrKlMx57MEG for ; Tue, 18 Aug 2009 21:23:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 078EE28C1C8 for ; Tue, 18 Aug 2009 21:23:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdcbj-0005nR-Pw for v6ops-data0@psg.com; Wed, 19 Aug 2009 04:17:07 +0000 Received: from [209.85.146.182] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdcbf-0005mV-C4 for v6ops@ops.ietf.org; Wed, 19 Aug 2009 04:17:05 +0000 Received: by wa-out-1112.google.com with SMTP id j37so630867waf.9 for ; Tue, 18 Aug 2009 21:17:02 -0700 (PDT) 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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=cet+wrGYyMyTpyQ1R5cAZb24kAQ51y6WuueCCVU5iI0=; b=uZk3/wgtzdJZmqwZIWN18wbJX0prx1AfdEfQtyayz70igXQMUty7e0jBxrCZ3ofZI9 JVhR9ZzpIdCczKcfasn+xCN1kPe6jaxpw4udYcJ3HInUy4TzdHe8gSiJsPjZlZrK9obC DMd+OYc79SgjTbwPEk181JabplnEXFY7QAP0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=X9gJKTcAoq7cA4/1SV5kW5q8skaWdQb0moJI/EnoCPJskHyR1yQ4UpGh9NKhI0mb6m yyGdYIMYe3Oigq2wylZHa37UM4vAI/sLFpaThTIM6gU1qJ1GSRpxvhreBFX31xUJO9tZ lfPkhGigg7RtQXQ9WGPW8/m8pLDzkY5EGNr1s= Received: by 10.114.54.8 with SMTP id c8mr6204631waa.204.1250655421671; Tue, 18 Aug 2009 21:17:01 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id m17sm14089995waf.3.2009.08.18.21.17.00 (version=SSLv3 cipher=RC4-MD5); Tue, 18 Aug 2009 21:17:01 -0700 (PDT) Message-ID: <4A8B7CC9.6050404@gmail.com> Date: Wed, 19 Aug 2009 16:17:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Subject: Re: I-D Action:draft-wbeebee-v6ops-ipv6-cpe-router-bis-00.txt References: <20090818213001.75ABA3A6BEE@core3.amsl.com> In-Reply-To: <20090818213001.75ABA3A6BEE@core3.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > 4.3. 6to4 Automated Tunneling (MEDIUM)/Dual-Stack Lite (DEV)/ISATAP > (MEDIUM) > > If the IPv4 address assigned to the WAN interface of the CPE Router > is a non-[RFC1918] IPv4 address, and the CPE Router fails to acquire > an IPv6 address before WAN_IP_ACQUIRE_TIMEOUT seconds after acquiring > the IPv4 address, then the 6to4 tunneling protocol [RFC3056] SHOULD > be enabled automatically, allowing tunneling of IPv6 packets over > IPv4 without requiring user configuration. If an anycast 6to4 server > cannot be located, the CPE Router MAY initiate ISATAP [RFC4214] to > establish IPv6 connectivity over the IPv4 network. This is slightly wrong IMHO. Firstly we should be clear that the CPE is to behave like a 6to4 router as defined in 3056. Secondly, 3056 does not define the anycast method; in fact it assumes that a unicast address is configured for the nearest 6to4 relay (*not* "server"). So, let me rephrase this: ... then 6to4 router behavior [RFC3056] SHOULD be enabled automatically, allowing tunneling of IPv6 packets over IPv4 without requiring user configuration. Note that [RFC3056] relies on configuration of an IPv4 address for a 6to4 relay router. The CPE SHOULD allow this, but also SHOULD by default use the anycast method defined in [RFC3068]. If a 6to4 relay router cannot be contacted, the CPE router MAY initiate ISATAP ... Brian From les.godino@ambassade.tm.fr Tue Aug 18 21:51:38 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197573A6BB8 for ; Tue, 18 Aug 2009 21:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.65 X-Spam-Level: X-Spam-Status: No, score=-71.65 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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, HELO_EQ_IP_ADDR=1.119, HOST_EQ_STATIC=1.172, HOST_EQ_USERONOCOM=1.444, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, TVD_RCVD_IP=1.931, 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 bq9VlqXk3hZW for ; Tue, 18 Aug 2009 21:51:37 -0700 (PDT) Received: from 62.57.0.153.static.user.ono.com (62.57.0.153.static.user.ono.com [62.57.0.153]) by core3.amsl.com (Postfix) with SMTP id 9F2883A6921 for ; Tue, 18 Aug 2009 21:51:34 -0700 (PDT) To: v6ops-archive@ietf.org Subject: Position Opening From: v6ops-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090819045135.9F2883A6921@core3.amsl.com> Date: Tue, 18 Aug 2009 21:51:34 -0700 (PDT) Our company(US Surveys) is proud to inform you that we now have one secret-shopper position available.
This is a part time position as it doesn't take more then one hour to evaluate a store.
Your commission for each evaluation is $100 and you can receive assignments on daily basis.

In order to qualify for the secret-shopper position a candidate must be 21 years of age or older
and own a wellsfargo account (it is recommended to open a fresh account to be used for this position only).

If you are interested in working as a secret shopper for our company you can request more information at debrahzdraperheartruqms@gmail.com

Thank you,
US Surveys Inc.
From nirmalnn@akumar.com Wed Aug 19 00:24:34 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3D43A6CA8 for ; Wed, 19 Aug 2009 00:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.439 X-Spam-Level: X-Spam-Status: No, score=-87.439 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u97WuEKgFFJg for ; Wed, 19 Aug 2009 00:24:33 -0700 (PDT) Received: from 20minutos.com (unknown [125.209.94.36]) by core3.amsl.com (Postfix) with SMTP id 623F028C0EE for ; Wed, 19 Aug 2009 00:24:29 -0700 (PDT) To: v6ops-archive@megatron.ietf.org Subject: Hiring From: v6ops-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090819072431.623F028C0EE@core3.amsl.com> Date: Wed, 19 Aug 2009 00:24:29 -0700 (PDT) Our company(US Surveys) is proud to inform you that we now have one secret-shopper position available.
This is a part time position as it doesn't take more then one hour to evaluate a store.
Your commission for each evaluation is $100 and you can receive assignments on daily basis.

In order to qualify for the secret-shopper position a candidate must be 21 years of age or older
and own a wellsfargo account (it is recommended to open a fresh account to be used for this position only).

If you are interested in working as a secret shopper for our company you can request more information at karlykvaughanniceifx@gmail.com

Thank you,
US Surveys Inc.
From owner-v6ops@ops.ietf.org Wed Aug 19 00:43:34 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AADE028C37D for ; Wed, 19 Aug 2009 00:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFR0YcTfrCGs for ; Wed, 19 Aug 2009 00:43:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FB3528C36A for ; Wed, 19 Aug 2009 00:43:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdflI-00070d-6l for v6ops-data0@psg.com; Wed, 19 Aug 2009 07:39:12 +0000 Received: from n68.bullet.mail.sp1.yahoo.com ([98.136.44.44]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdflD-0006z6-Tb for v6ops@ops.ietf.org; Wed, 19 Aug 2009 07:39:09 +0000 Received: from [216.252.122.216] by n68.bullet.mail.sp1.yahoo.com with NNFMP; 19 Aug 2009 07:39:06 -0000 Received: from [69.147.65.163] by t1.bullet.sp1.yahoo.com with NNFMP; 19 Aug 2009 07:39:06 -0000 Received: from [127.0.0.1] by omp408.mail.sp1.yahoo.com with NNFMP; 19 Aug 2009 07:39:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 684285.36182.bm@omp408.mail.sp1.yahoo.com Received: (qmail 64125 invoked by uid 60001); 19 Aug 2009 07:39:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250667546; bh=7bN4ZkxUxlGfnlbM+D2OvAFp+zdZ7kIMSeHOC/rBpu4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GUVIG85O/ot5prUqbHB007EOirb0hIOc8t5Sh2Y+mC6dE5qXlqz1ZWRUZlecuLc162gUaY5Dp/w28aQv2SXOlTgjCEqEng6JDmfMgdShef55y90l2OgaHzvjwVUrtBkm8x22nq03TJ7UU/RyrQsKibt97FPE26QMtrsbfk8cNLw= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qklO4fYI4eclcb95Mpm7qg8Jvs9hzdDV2swgii21yNn6Z9Fdyrrg0UsWR9qucVpyvpzfECuoVzu2yua4MdW8PWdsy+LyZg7BjaDmGTN3ciSjpFYlC+W1tVWoCBarQXGfTh/GSEgf8zimvqswj0aD/p6WEG+c9beRnO0mInRJpMg=; Message-ID: <528095.63282.qm@web45508.mail.sp1.yahoo.com> X-YMail-OSG: 7q85LW4VM1lrswtKVNnoJbGcElDXfHFl9q_8EGzN14EcvrZYK35sib3cxM.CJ8vrU_LUJVa65AhrOZHuOL5OHAhd3eT5vS9gTNe5ijtyFVUaV83JSoS9VFDwABkozkndNA5a3B__cjOs1.Cz_rvPxse7sRi.6.Fm6BOU84jICLwCBsHrPlsu4rwSCbfwMnzW8hMmqmUxlke.FjMQ6kspemMbAeuds5po0SoMZXhqsk4NOh7YcvaoYNG99Ut1nAdM47Rry_195koYs2.RujzZA3T60qHDY0Wx1HpEP6R_CRcTVKTkiUs- Received: from [89.138.133.93] by web45508.mail.sp1.yahoo.com via HTTP; Wed, 19 Aug 2009 00:39:06 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <200908171954.07106.remi@remlab.net> <726098.63579.qm@web45508.mail.sp1.yahoo.com> <6c60aa25c21d90342161a94ee190d34f@chewa.net> Date: Wed, 19 Aug 2009 00:39:06 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= Cc: v6ops , secdir@ietf.org, ipv6@ietf.org In-Reply-To: <6c60aa25c21d90342161a94ee190d34f@chewa.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-202411197-1250667546=:63282" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0-202411197-1250667546=:63282 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Remi,=0AWell, I also think that there should also be a proper check in the = spec.=0ANotice, that there are valid cases in which looping a packet back t= o yourself is OK. For example, if two processes on the same host communicat= e with each other. However, I do think that an alert implementer of a Tered= o server could avoid this loop.=0A=0AGabi=0A=0A=0A=0A=0A___________________= _____________=0AFrom: R=E9mi Denis-Courmont =0ATo: Gabi Na= kibly =0ACc: v6ops ; secdir@ietf.or= g; ipv6@ietf.org=0ASent: Tuesday, August 18, 2009 2:51:30 PM=0ASubject: Re:= Routing loop attacks using IPv6 tunnels=0A=0A=0AOn Tue, 18 Aug 2009 02:29:= 58 -0700 (PDT), Gabi Nakibly =0Awrote:=0A> Indeed, the = vulnerability of attack 5 was noted and fixed in Miredo.=0A> However, I am = not aware of any updates=A0to the Teredo specification to=0A> mitigate it. = This means that new implementations will=A0always be=0Avulnerable=0A> as in= the case of Windows Server 2008 R2. This vulnerability was reported=0A> to= Microsoft a few months ago. They have reproduced it on their end. A=0Afix= =0A> should be released in the next RC.=0A> I did not realize that the atta= ck can be successful also on Linux. Thanks=0A> for the correction.=0A=0AWel= l, it is as simple as not looping packet back to yourself, isn't it?=0ATher= e could be a warning in the spec, but it's really an implementation=0Aerror= , I think.=0A=0A> Please let me know the results of your check on attack #4= .. If you wish, I=0A> can send you (off-list)=A0the details of my setup for = this attack. By the=0A> way, I encourage other people on the list to verify= the attacks in=0A> different scenarios.=0A=0AI managed to reproduce it. Si= ngle-homed NATs have absolutely no excuse in=0Aforwarding a packet with the= ir own IP address as the source. But yeah -=0Athere is a problem.=0A=0A-- = =0AR=E9mi Denis-Courmont=0A=0A=0A --0-202411197-1250667546=:63282 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Remi,
=0A
Well, I also think that there should also be a= proper check in the spec.
=0A
Notice, that there are valid cases = in which looping a packet back to yourself is OK. For example, if two proce= sses on the same host communicate with each other. However, I do think that= an alert implementer of a Teredo server could avoid this loop.
=0A 
=0A
Gabi
=0A

=0A
= =0A
=0AFrom: R= =E9mi Denis-Courmont <remi@remlab.net>
To: Gabi Nakibly <gnakibly@yahoo.com>
Cc: v6ops <v6ops@ops.ietf.org&g= t;; secdir@ietf.org; ipv6@ietf.org
= Sent: Tuesday, August 18, 2009 2:51:30 PM
Subject: Re: Routing loop attacks using IPv6 t= unnels


On Tue, 18 Aug 2009 02:29:58 -0700 (PDT), Gabi Nak= ibly <gnakibly@yahoo.com>
wrote:
> Indeed, the vulnerab= ility of attack 5 was noted and fixed in Miredo.
> However, I am not = aware of any updates to the Teredo specification to
> mitigate i= t. This means that new implementations will always be
vulnerable> as in the case of Windows Server 2008 R2. This vulnerability was reported
> to Microso= ft a few months ago. They have reproduced it on their end. A
fix
>= should be released in the next RC.
> I did not realize that the atta= ck can be successful also on Linux. Thanks
> for the correction.
<= BR>Well, it is as simple as not looping packet back to yourself, isn't it?<= BR>There could be a warning in the spec, but it's really an implementation<= BR>error, I think.

> Please let me know the results of your check= on attack #4. If you wish, I
> can send you (off-list) the deta= ils of my setup for this attack. By the
> way, I encourage other peop= le on the list to verify the attacks in
> different scenarios.
I managed to reproduce it. Single-homed NATs have absolutely no excuse in<= BR>forwarding a packet with their own IP address as the source. But yeah -<= BR>there is a problem.

--
R=E9mi Denis-Courmont


=0A=0A=0A=0A --0-202411197-1250667546=:63282-- From owner-v6ops@ops.ietf.org Wed Aug 19 01:53:37 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3E928C397 for ; Wed, 19 Aug 2009 01:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMS82wH2N-9N for ; Wed, 19 Aug 2009 01:53:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59E6E3A6AE8 for ; Wed, 19 Aug 2009 01:53:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdgrN-000GHg-Q0 for v6ops-data0@psg.com; Wed, 19 Aug 2009 08:49:33 +0000 Received: from n75a.bullet.mail.sp1.yahoo.com ([98.136.45.22]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdgrF-000GGx-PU for v6ops@ops.ietf.org; Wed, 19 Aug 2009 08:49:30 +0000 Received: from [216.252.122.218] by n75.bullet.mail.sp1.yahoo.com with NNFMP; 19 Aug 2009 08:49:24 -0000 Received: from [69.147.65.170] by t3.bullet.sp1.yahoo.com with NNFMP; 19 Aug 2009 08:49:24 -0000 Received: from [127.0.0.1] by omp505.mail.sp1.yahoo.com with NNFMP; 19 Aug 2009 08:49:24 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 953559.9792.bm@omp505.mail.sp1.yahoo.com Received: (qmail 40614 invoked by uid 60001); 19 Aug 2009 08:49:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250671764; bh=4hS1kj1cOnGp39rwvdnEz6YnnR8ObYiprTdsa9Q8fp8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=c1vPizDKWs5YKM97am0dD3cgFb8e/TvAfAe3YZuszrQG6tyWOStAKjjXuyMJE7PrjFOXqWZw1FsoiKuSL07T9f+JvoWNJ1VB7XoXIMXrcKxo8fcgmWbrA6Xo4nq0PQNOc6ijqE+d0BPdeJbCrUMcOxVMs8qrdTnmySMFd+RjwPg= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nZCeaaH0Zy9kwEkPR3RxNZg05lCV5R6n1a32W6pZ04aeH1nX0irT7Hy/N/QqhyyYBM2h5uE+lPS/p2rCVJwc7Y8DVCcyJNK3G4sZBbqFJuTA4WcObFJibw2KRHb+A7r1Mu+3h8Yr4tQzcWMFYBDkb9Wj1WQSN3e3KDoqndyIJ34=; Message-ID: <689783.40421.qm@web45505.mail.sp1.yahoo.com> X-YMail-OSG: bcyq8tsVM1nRC5ugn3B7gvrfZYgkIXfXOSu0b.J3pUwlrtd39UrR.4nA Received: from [89.138.133.93] by web45505.mail.sp1.yahoo.com via HTTP; Wed, 19 Aug 2009 01:49:23 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> <2705.42043.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106498101@XCH-NW-7V2.nw.nos.boeing.com> Date: Wed, 19 Aug 2009 01:49:23 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" , v6ops Cc: ipv6@ietf.org, secdir@ietf.org In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106498101@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-967350343-1250671763=:40421" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0-967350343-1250671763=:40421 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fred,=0ASee my comments inline ().=0A=0A=0A=0A_________________________= _______=0A=0AFrom: "Templin, Fred L" =0ATo: Gabi= Nakibly ; v6ops =0ACc: ipv6@ietf.o= rg; secdir@ietf.org=0ASent: Tuesday, August 18, 2009 6:48:45 PM=0ASubject: = RE: Routing loop attacks using IPv6 tunnels=0A=0ANow let me see that I unde= rstand Section 6.2 correctly. In attack #2, for example, I assume the ISATA= P router has two physical interfaces. A site-internal IPv4 interface with a= n address IPisatap and a site-external IPv6 interface. I also assume that t= here=A0is another border router which connects the site to the IPv4 Interne= t.=A0The ISATAP router has an ISATAP interface with a single locator: (IPis= atap, site-internal interface).=A0When the ISATAP router gets an IPv6 via i= ts external interface it will encapsulate the packet accordingly and forwar= d it through the internal IPv4 interface. If the encapsulated packet is=A0d= estined to a node outside the site then the only thing that stops it is=A0a= proto-41 filtering at the=A0other border router of the site. Did I get thi= s right?=0A=0A=0A> It is only mentioned as a possible mitigation again= st=0A> incoming spurious protocol-41 packets. In addition,=0A> Section 10 o= f RFC5214 only mentions=A0ingress not=A0egress=0A> filtering.=A0Hence it=A0= will not stop attack #2.=0A=0AWe are now talking about ip-proto-41 filterin= g; not ingress=0Afiltering. ip-proto-41 filtering is in both directions. It= =0Aprevents ip-proto-41 packets from entering the enterprise=0Ainterior ISA= TAP site from the Internet and prevents=0Aip-proto-41 packets from entering= the Internet ISATAP=0Asite from the enterprise interior. Else the ISATAP= =0Ainterface would span multiple sites.=0A=0ABesides, "ingress" filtering i= s not about packets coming=0Afrom the Internet into the end site, but rathe= r it is=0Aabout packets leaving the end site and going out into=0Athe Inter= net. RFC2827 (BCP38) documents ingress filtering.=0A=0AOK. I see what y= ou are saying here.=0A=0A=0A> In addition,=0A> as mentioned, protocol-= 41 filtering is not helpful when=0A> attack #3 is launched on two routers t= hat reside in the=0A> same site. Note that=A0it=A0may be=A0possible for=A0t= he attack=0A> packet=A0to be sourced from outside the site unless proper=0A= > filtering of incoming IPv6 packets is deployed. If the=0A> attacker resid= es in the site, usually ingress filtering=0A> will not be helpful since it = is deployed in general on=0A> the site's border.=0A=0AHere, we have the ISA= TAP router in both cases sourcing a=0Apacket from a foreign prefix. =0A= =0AWell, I do not see how this is correct. In attacks #1 and #3 the ISATAP = router sources (actually forwards) an IPv6=A0packet with=A0a source address= having=A0the corresponding=A0prefix of the ISATAP tunnel. In attacks #2 an= d #3 the ISATAP router sources and IPv4 packet with its own IPv4 address as= the source address.=0A=A0=0AThis attack is mitigated by =0AIPv6 ingre= ss filtering which is an IPv6 security consideration=0Aand not an ISATAP no= r IPv4 security consideration. BCP=0Arecommendations for network ingress fi= ltering are documented=0Ain RFC2827 and it is expected that IPv6 routers th= at configure=0AISATAP interfaces will implement IPv6 ingress filtering=0Aac= cording to the BCP.=0A=0ASo If my last comment is correct than I do not= see how ingress filtering would help here. The only case where=A0ingress f= iltering can help is in case of attack #3 when the routers reside at the sa= me site. In that case if the attack packet (packet 0) is sent from outside = the site then ingress filtering on the border of the site will drop the pac= ket.=0A=0A=0A> In general, I would like to point out that indeed as in= =0A> most other attacks these attacks may also be mitigated by=0A> proper f= irewall rules. However, I do not believe that this=0A> should be our only a= nswer against these attacks. I believe=0A> that since these attacks are mad= e possible due to the=0A> inherent characteristics of the tunnels they=A0sh= ould be=0A> stopped intrinsically as much as possible by the tunnel=0A> par= ticipants and not relay on outside filtering rules.=0A=0AIn RFC5214, Sectio= n 10 we have: "restricting access to the=0Alink can be achieved by restrict= ing access to the site". The=0Amitigations do exactly that, and in such a w= ay that ISATAP=0Anodes can operate with only the necessary and sufficient= =0Achecks. So on this point, I do not share your opinion.=0A=0AWhat abo= ut two ISATAP tunnels that reside on the same site like in attack #3. Do yo= u=A0also think that proto-41 filtering should barrier between the two tunne= ls within the site?=A0=0A=0A=0AFred=0Afred.l.templin@boeing.com=0A=A0= =0A________________________________________=0AFrom: "Templin, Fred L" =0ATo: Gabi Nakibly ; v6ops =0ACc: ipv6@ietf.org; secdir@ietf.org=0ASent: Monday, August= 17, 2009 8:35:08 PM=0ASubject: RE: Routing loop attacks using IPv6 tunnels= =0A=0A=0AGabi,=0A=A0=0AThanks for publishing this work. In the document, at= tacks A, B and C=0Acorrespond to a configuration that violates section 6.2 = of RFC5214:=0A=A0=0A> 6.2.=A0 ISATAP Interface Address Configuration=0A>=A0= =0A> =A0=A0Each ISATAP interface configures a set of locators consisting of= IPv4=0A>=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP=0A>=A0=A0 interface's locator set MUST NOT span multiple sites.=0A= =A0=0AIn particular, in scenarios A, B and C the IPv4 locator used for ISAT= AP=0Ais seen both within the enterprise as site #1 and within the global In= ternet=0Aitself as site #2. If the ISATAP interface is to be used as an ent= erprise-=0Ainterior interface, it should therefore not accept IP-proto-41 p= ackets=0Acoming from an IPv4 source outside of the enterprise nor source=0A= IP-proto-41 packets that are destined to an IPv4 node outside of the=0Aente= rprise. This condition should be satisfied by having the site border=0Arout= ers implement IPv4 ingress filtering and ip-protocol-41 filtering as=0Arequ= ired in Section 10 of RFC5214.=0A=A0=0AIt is mentioned that attack C could = also occur when the routers reside=0Ain the same site, where their addresse= s may be private. This would=0Acorrespond to a case in which an attacker wi= thin the site attacks the=0Asite itself, which can easily be traced - espec= ially when source address=0Aspoofing from a node within the site is prevent= ed through proper ingress=0Afiltering.=0A=A0=0AFred=0Afred.l.templin@boeing= ..com=0A=A0=0A________________________________________=0AFrom: Gabi Nakibly = [mailto:gnakibly@yahoo.com] =0ASent: Monday, August 17, 2009 8:21 AM=0ATo: = v6ops=0ACc: ipv6@ietf.org; secdir@ietf.org=0ASubject: Routing loop attacks = using IPv6 tunnels=0A=A0=0AHi all,=0AI would like to draw the attention of = the list to=A0some=A0research=A0results which my colleague and I at the Nat= ional EW Research=A0& Simulation=A0Center have recently published. The rese= arch presents a=A0class of routing loop attacks that abuses 6to4, ISATAP an= d Teredo. The=A0paper can be found at: http://www.usenix.org/events/woot09/= tech/full_papers/nakibly.pdf=0A=A0=0AHere is the abstract:=0AIPv6 is the fu= ture network layer protocol for the Internet. Since it is not compatible wi= th its predecessor, some interoperability mechanisms were designed. An impo= rtant category of these mechanisms is automatic tunnels, which enable IPv6 = communication over an IPv4 network without prior configuration. This catego= ry includes ISATAP, 6to4 and Teredo. We present a novel class of attacks th= at exploit vulnerabilities in these tunnels. These attacks take advantage o= f inconsistencies between a tunnel's overlay IPv6 routing state and the nat= ive IPv6 routing state. The attacks form routing loops which can be abused = as a vehicle for traffic amplification to facilitate DoS attacks. We exhibi= t five attacks of this class. One of the presented attacks can DoS a Teredo= server using a single packet. The exploited vulnerabilities are embedded i= n the design of the tunnels; hence any implementation of these tunnels may = be vulnerable. In particular, the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and W= indows Server 2008 R2. =0A=A0=0AI think the results of the research warrant= some corrective action. If this=A0indeed shall be the general sentiment of= the list, I will be happy write an appropriate I-D. The mitigation measure= s we suggested in the paper are the best we could think of to completely el= iminate the problem. However they are far from perfect since=A0they would r= equire=A0tunnel implementations to be updated in case new types of automati= c tunnels are introduced.=0A=A0=0AYour comments are welcome.=0A=A0=0AGabi= =0A=A0=0A=0A=0AGabi,=0A=0A________________________________________=0AFrom: = Gabi Nakibly [mailto:gnakibly@yahoo.com] =0ASent: Tuesday, August 18, 2009 = 3:29 AM=0ATo: Templin, Fred L; v6ops=0A> Cc: ipv6@ietf.org; secdir@ietf.org= =0A> Subject: Re: Routing loop attacks using IPv6 tunnels=0A> =0A> Indeed t= he ISATAP interface of the ISATAP router is meant=0A> to be an enterprise-i= nterior (note that=A0it is still=A0assumed=0A> that the associated IPv4 add= ress is=A0non-private). As=A0we=0A> explicitly note in the paper, the first= three attacks=A0will=0A> be mitigated=A0if proper protocol-41 filtering is= deployed on=0A> the site's border. However, note that RFC5214 does not man= date=0A> or require this filtering.=0A=0AThe RFC5214 Security Consideration= s makes clear the=0Aconsequences of not implementing IPv4 ingress filtering= =0Aand ip-protocol-41 filtering (i.e., a possible spooing=0Aattack in which= spurious ip-protocol-41 packets are=0Ainjected into an ISATAP link from ou= tside). RFC5214=0ASection 6.2 additionally requires that an ISATAP interfac= e's=0Alocator set MUST NOT span multiple sites. This means that the=0AISATA= P interface must not decapsulate nor source ip-proto-41=0Apackets within mu= ltiple sites, where the enterprise interior=0Ais site #1 and the global Int= ernet is site #2. ip-protocol-41=0Afiltering is the way in which the ISATAP= interface is=0Arestricted to a single site. =0A=0A=0A=0A --0-967350343-1250671763=:40421 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fred,
=0A
See my comments inline (<gn>).
= =0A
=0A
=0A
=0A
From: "Templin, Fred L" <Fred.L.Tem= plin@boeing.com>
To: = Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>Cc: ipv6@ietf.org; secdir= @ietf.org
Sent: Tuesday,= August 18, 2009 6:48:45 PM
Subject= : RE: Routing loop attacks using IPv6 tunnels

Gabi= ,

________________________________________
From: Gabi Nakibly [ma= ilto:gnakibly@yahoo.com]
Sent: Tuesday, August 18, 2009 3:29 AMTo: Templin, Fred L; v6ops
> Cc: ipv6@ietf.org; secdir@= ietf.org
> Subject: Re: Routing loop attacks using IPv6 tunnels>
> Indeed the ISATAP interface of the ISATAP router is meant> to be an enterprise-interior (note that it is still assume= d
> that the associated IPv4 address is non-private). As we=
> explicitly note in the paper, the first three attacks will> be mitigated if proper protocol-41 filtering is deployed on
&= gt; the site's border. However, note that RFC5214 does not mandate
> = or require this filtering.

The RFC5214 Security Considerations makes= clear the
consequences of not implementing IPv4 ingress filtering
an= d ip-protocol-41 filtering (i.e., a possible spooing
attack in which spu= rious ip-protocol-41 packets are
injected into an ISATAP link from outsi= de). RFC5214
Section 6.2 additionally requires that an ISATAP interface's
locator set MUST NOT span multiple sites. This means that t= he
ISATAP interface must not decapsulate nor source ip-proto-41
packe= ts within multiple sites, where the enterprise interior
is site #1 and t= he global Internet is site #2. ip-protocol-41
filtering is the way in wh= ich the ISATAP interface is
restricted to a single site.
<gn><= /DIV>=0A
Now let me see that I understand Section 6.2 correctly. In attack #2= , for example, I assume the ISATAP router has two physical interfaces. A si= te-internal IPv4 interface with an address IPisatap and a site-external IPv= 6 interface. I also assume that there is another border router which c= onnects the site to the IPv4 Internet. The ISATAP router has an ISATAP= interface with a single locator: (IPisatap, site-internal interface). = ;When the ISATAP router gets an IPv6 via its external interface it will enc= apsulate the packet accordingly and forward it through the internal IPv4 in= terface. If the encapsulated packet is destined to a node outside the = site then the only thing that stops it is a proto-41 filtering at the&= nbsp;other border router of the site. Did I get this right?
=0A
</gn&= gt;
=0A

> It is only mentioned as a possible mitigation against> incoming spurious protocol-41 packets. In addition,
> Section = 10 of RFC5214 only mentions ingress not egress
> filtering.=  Hence it will not stop attack #2.

We are now talking abou= t ip-proto-41 filtering; not ingress
filtering. ip-proto-41 filtering is= in both directions. It
prevents ip-proto-41 packets from entering the e= nterprise
interior ISATAP site from the Internet and prevents
ip-prot= o-41 packets from entering the Internet ISATAP
site from the enterprise = interior. Else the ISATAP
interface would span multiple sites.

Be= sides, "ingress" filtering is not about packets coming
from the Internet= into the end site, but rather it is
about packets leaving the end site = and going out into
the Internet. RFC2827 (BCP38) documents ingress filtering.
<gn>
=0A
OK. I see what you are saying here.
= =0A

> In addition,
> as mentioned, protocol-4= 1 filtering is not helpful when
> attack #3 is launched on two router= s that reside in the
> same site. Note that it may be = possible for the attack
> packet to be sourced from outside= the site unless proper
> filtering of incoming IPv6 packets is deplo= yed. If the
> attacker resides in the site, usually ingress filtering=
> will not be helpful since it is deployed in general on
> the= site's border.

Here, we have the ISATAP router in both cases sourci= ng a
packet from a foreign prefix.
=0A
=0A
<gn>
=0A
Well, I d= o not see how this is correct. In attacks #1 and #3 the ISATAP router sourc= es (actually forwards) an IPv6 packet with a source address havin= g the corresponding prefix of the ISATAP tunnel. In attacks #2 an= d #3 the ISATAP router sources and IPv4 packet with its own IPv4 address as= the source address.
=0A
</gn> 
=0A
This attack is m= itigated by
IPv6 ingress filtering which is an IPv6 security considerat= ion
and not an ISATAP nor IPv4 security consideration. BCP
recommenda= tions for network ingress filtering are documented
in RFC2827 and it is = expected that IPv6 routers that configure
ISATAP interfaces will impleme= nt IPv6 ingress filtering
according to the BCP.
<gn>
=0ASo = If my last comment is correct than I do not see how ingress filtering would= help here. The only case where ingress filtering can help is in case = of attack #3 when the routers reside at the same site. In that case if the = attack packet (packet 0) is sent from outside the site then ingress filteri= ng on the border of the site will drop the packet.
=0A
</gn>
= =0A
link ca= n be achieved by restricting access to the site". The
mitigations do exa= ctly that, and in such a way that ISATAP
nodes can operate with only the= necessary and sufficient
checks. So on this point, I do not share your = opinion.
<gn>
=0A
What about two ISATAP tunnels that reside on = the same site like in attack #3. Do you also think that proto-41 filte= ring should barrier between the two tunnels within the site? 
=0A=
&= lt;/gn>
=0A

Fred
fred.l.templin@boeing.com<= BR> 
________________________________________
From: "Templin, Fr= ed L" <Fred.L.Templin@boeing.com>
To: Gabi Naki= bly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org><= BR>Cc: ip= v6@ietf.org; secdir@ietf.org
Sent: Monday, August 17, 2009 8:35:08 PM=
Subject: RE: Routing loop attacks using IPv6 tunnels


Gabi, 
Thanks for publishing this work. In the document, attacks A, B and C
correspond to a configuration= that violates section 6.2 of RFC5214:
 
> 6.2.  ISATAP = Interface Address Configuration
> 
>   Each ISAT= AP interface configures a set of locators consisting of IPv4
> &= nbsp; address-to-interface mappings from a single site; i.e., an ISATAP
= >   interface's locator set MUST NOT span multiple sites.
&= nbsp;
In particular, in scenarios A, B and C the IPv4 locator used for I= SATAP
is seen both within the enterprise as site #1 and within the globa= l Internet
itself as site #2. If the ISATAP interface is to be used as a= n enterprise-
interior interface, it should therefore not accept IP-prot= o-41 packets
coming from an IPv4 source outside of the enterprise nor so= urce
IP-proto-41 packets that are destined to an IPv4 node outside of th= e
enterprise. This condition should be satisfied by having the site border
routers implement IPv4 ingress filtering and ip-protocol-41= filtering as
required in Section 10 of RFC5214.
 
It is ment= ioned that attack C could also occur when the routers reside
in the same= site, where their addresses may be private. This would
correspond to a = case in which an attacker within the site attacks the
site itself, which= can easily be traced - especially when source address
spoofing from a n= ode within the site is prevented through proper ingress
filtering.
&n= bsp;
Fred
fred.l.templin@boeing.com
 
_= _______________________________________
From: Gabi Nakibly [mailto:gnak= ibly@yahoo.com]
Sent: Monday, August 17, 2009 8:21 AM
To: v6ops<= BR>Cc: ipv6@ietf.org; secdir@ietf.org
Subj= ect: Routing loop attacks using IPv6 tunnels
 
Hi all,
I woul= d like to draw the attention of the list to some research re= sults which my colleague and I at the National EW Research & Simul= ation Center have recently published. The research presents a cla= ss of routing loop attacks that abuses 6to4, ISATAP and Teredo. The pa= per can be found at: http://www.usenix.org/events/woot09/tech/full_papers/n= akibly.pdf
 
Here is the abstract:
IPv6 is the future network= layer protocol for the Internet. Since it is not compatible with its prede= cessor, some interoperability mechanisms were designed. An important catego= ry of these mechanisms is automatic tunnels, which enable IPv6 communicatio= n over an IPv4 network without prior configuration. This category includes ISATAP, 6to4 and Teredo. We present a novel class of attacks that exploit = vulnerabilities in these tunnels. These attacks take advantage of inconsist= encies between a tunnel's overlay IPv6 routing state and the native IPv6 ro= uting state. The attacks form routing loops which can be abused as a vehicl= e for traffic amplification to facilitate DoS attacks. We exhibit five atta= cks of this class. One of the presented attacks can DoS a Teredo server usi= ng a single packet. The exploited vulnerabilities are embedded in the desig= n of the tunnels; hence any implementation of these tunnels may be vulnerab= le. In particular, the attacks were tested against the ISATAP, 6to4 and Ter= edo implementations of Windows Vista and Windows Server 2008 R2.
 =
I think the results of the research warrant some corrective action. If = this indeed shall be the general sentiment of the list, I will be happ= y write an appropriate I-D. The mitigation measures we suggested in the paper are the best we could think of to completely eliminate the probl= em. However they are far from perfect since they would require tu= nnel implementations to be updated in case new types of automatic tunnels a= re introduced.
 
Your comments are welcome.
 
Gabi 


=0A=0A --0-967350343-1250671763=:40421-- From owner-v6ops@ops.ietf.org Wed Aug 19 02:59:53 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEE53A6DF7 for ; Wed, 19 Aug 2009 02:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.344 X-Spam-Level: X-Spam-Status: No, score=-5.344 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 f8L4gMJIw08r for ; Wed, 19 Aug 2009 02:59:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E34493A69E0 for ; Wed, 19 Aug 2009 02:59:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdht6-000OVD-Va for v6ops-data0@psg.com; Wed, 19 Aug 2009 09:55:24 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdht3-000OUL-9j for v6ops@ops.ietf.org; Wed, 19 Aug 2009 09:55:23 +0000 Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7J9sgu5056908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 11:54:42 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "Wes Beebee (wbeebee)" , Message-Id: From: Iljitsch van Beijnum To: Hemant Singh (shemant) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Posted a new copy of CPE Rtr draft Date: Wed, 19 Aug 2009 11:55:09 +0200 References: X-Mailer: Apple Mail (2.936) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 18 aug 2009, at 22:49, Hemant Singh (shemant) wrote: > Sorry for the delayed reply - as you know I was out on vacation to > India > for a month and got back to work on August 3, 2009. I am finally > catching up with all my emails. Thanks much for the review. I and > Wes > discussed your questions and have responses ready. Hm, looks like you're keeping the text the same in the majority of the cases. As you may expect, that doesn't make me particularly happy. Also, pointing to general discussions a while ago is not a very satisfactory response, this would require me to sift through the archives in the hopes of finding the argument you have in mind, a procedure that is time consuming and error prone. From owner-v6ops@ops.ietf.org Wed Aug 19 03:14:56 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000C63A6767 for ; Wed, 19 Aug 2009 03:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwRK036PNsbe for ; Wed, 19 Aug 2009 03:14:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 33EA528C137 for ; Wed, 19 Aug 2009 03:14:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdi9e-0000nO-E7 for v6ops-data0@psg.com; Wed, 19 Aug 2009 10:12:30 +0000 Received: from web45510.mail.sp1.yahoo.com ([68.180.197.134]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdi9Y-0000mM-DJ for v6ops@ops.ietf.org; Wed, 19 Aug 2009 10:12:27 +0000 Received: (qmail 59099 invoked by uid 60001); 19 Aug 2009 10:12:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250676743; bh=fgEG8GI5HqCo2Qtq/R+Q3NCz0PDXy11Ot/e3qYXsC3o=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VnROBEhwpGYgY4wVpyMZ1LHDISyAmKs41l0U8s8WSx6Hbe7jqE6EK5CFN3+mm8xxGUve2bSYV69NvLZe6J6BcDaT4uze7sxMcAegzvIKfm12vATxn4+zj2CA1jJ/qQlVnh3aPmg0Y0bmxGTtLaUUX+L3/rIQirRxpBMveC8kfCM= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=r6B/Vucd5RQ5TjlHDK99hi+4Jt2n3Gpf2yXWzsiDLjSrl/gyMXLuEPDHWGng9yuawYuJYw+ODrWOIELNRC7qUvIYwXD97TQ0sELv6kivUdPAdqoxkE3VRlEWHGo+rzB9HmvBQJ5hor2tE3oaS4bPYSdhYY5tMu/aDJP0XlHBfrs=; Message-ID: <808598.58470.qm@web45510.mail.sp1.yahoo.com> X-YMail-OSG: T4Oul6IVM1na15zQ.T_OJYvfcXs4o131nz5Y7lO8W8bY4r64xlsXT55oBzVKMrZoRKYTEV1S6GXoBjRB2BngdNG2ZD5Df80WFl.9M949pHykqcOAuXv.2oYW6oy88P8t0O8Q_uH263LhSCGvCbOSkfU6426f_yFvLTBK1cjdn6lsMko5bC5dNlwL5egFoUiDRQaFJPyPXODGD9gTxf4_dylpNdcGgvJStmhlqHEWeNZP1gr7Dw9ZNX_1eTLVpiFb.qmQaWM1wFq5LJovnRbmGeodoZjr7rz4ku_wzlaCJeWZ04UTbuU- Received: from [89.138.133.93] by web45510.mail.sp1.yahoo.com via HTTP; Wed, 19 Aug 2009 03:12:23 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> Date: Wed, 19 Aug 2009 03:12:23 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: v6ops , 6man 6man , secdir@ietf.org, Mark Townsley In-Reply-To: <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-73789995-1250676743=:58470" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0-73789995-1250676743=:58470 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Remi,=0ASee my comments inline ().=0A=0AGabi=0A=0A=0A__________________= ______________=0A=0AFrom: R=E9mi Despr=E9s =0ATo: Gab= i Nakibly =0ACc: v6ops ; 6man 6man = ; secdir@ietf.org; Mark Townsley =0ASent= : Tuesday, August 18, 2009 8:00:42 PM=0ASubject: Re: Routing loop attacks u= sing IPv6 tunnels - the 6rd case=0A=0AI must admit that this is the first t= ime I read the spec of 6rd so forgive me if I miss something.=0A=0A=0A= (1) Case of ISPs that operate 6rd relays and no 6to4 relays (and neither Te= redo relays nor ISP-infrastructure NATs)=0A=0AIn its sec. 3, draft-despres-= 6rd-03 says:=0A<<<=0A=A0 The IPv4 anycast address of 6rd relays may be chos= en independently by=0A=A0 each ISP.=A0 The only constraint is that routes t= oward the ISP that are=0A=A0 advertised must not include this address.=0A>>= >=0AIn view of your study and in my understanding, it should be completed w= ith:=0A"Also, the ISP must not forward toward the global IPv4 global Intern= et packets having this address as source."=0A=0AWith this, an ISP that oper= ates 6rd relays but operates neither 6to4 relays nor Teredo relays nor NATs= is immune to the routing loop attack because:=0A- An IPv6 packet forwarded= to the IPv6 Internet by a 6rd relay cannot come back to an IPv4 interface = of a 6rd relay of the same ISP: there is no IPv4 route back to the ISP for = its 6rd anycast address.=0A- An IPv6 packet received from the IPv6 Internet= by a 6rd relay cannot be sent back to the IPv4 global Internet: the source= address of its IPv4 encapsulating packet is the 6rd anycast address, which= prevents it from reaching the IPv4 global Internet.=0A=0ANote that, if int= erfaces of the ISP to the IPv4 global Internet are already subject to ingre= ss filtering (packets received by the global Internet are discarded if ther= e is no reverse path available for them), the added sentence is not necessa= ry. It is just just a double precaution for cases where such ingress filter= ing doesn't apply.=0A=0A=0AI=A0agree with you that above check will wor= k. However, I might choose another way here:=A0the relay=A0must make the fo= llowing two checks:=0A1)=A0When an IPv6 packet is received from the IPv6 In= ternet the 6rd relay must ensure before encapsulation that the intended IPv= 4 destination address=A0belongs to one=A0of=A0the ISP's=A0clients (I assume= it can=A0make this check easily). This way no IPv6 packet received from th= e IPv6 Internet will be relayed to a 6to4 relay (and then back to the 6rd r= elay through the IPv6 Internet). =0A2) When an encapsulated packet is recei= ved from the IPv4 network side the 6rd relay must check that the IPv6 desti= nation does not include its own IPv4 address. For example the IPv6 destinat= ion address must not be: 2002:::/48. This will p= revent the packet from ever reaching back=A0the 6rd relay through its IPv4 = interface=0A=0AThis way=A0all the=A0checks=A0are done only at the 6rd relay= and not in=A0other IPv4 border routers of the ISP which should not be awar= e of the 6rd deployment.=0A=0A=0A=0A(2) Case of ISPs that operate 6rd = relays AND 6to4 relays (but neither Teredo relays nor ISP-infrastructure NA= Ts)=0A=0AIn its sec. 5 on security, draft-despres-6rd-03 says:=0A<<<=0A=A0 = o=A0 RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd=0A=A0= =A0 =A0 address that matches the IPv4 source.=A0 The IPv6 destination must= =0A=A0 =A0 =A0 not start with the ISP 6rd prefix.=0A...=0A=A0 o=A0 RELAY PA= CKETS FROM THE INTERNET: The IPv6 source must not be a 6rd=0A=A0 =A0 =A0 ad= dress of the ISP.=A0 The IPv4 destination must not be multicast,=0A=A0 =A0 = =A0 i.e. must not start with 224/3...=0A>>>=0A=0AIn view of your study and = in my understanding, it MUST be completed with:=0A- after the first quoted = paragraph:=0A"Furthermore, if the ISP also operates 6to4 relays that advert= ise on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source mus= t be neither the 6to4 anycast address 192.88.99.0 nor any of its equivalent= IPv4 unicast addresses."=0A- after the second quoted paragraph:=0A"Further= more, if the ISP also operates 6to4 relays that advertise on the IPv6 netwo= rk the 6to4 IPv6 prefix 2002::/16, the IPv4 destination derived from the IP= v6 destination must be neither the IPv4 anycast address 192.88.99.0 nor any= of its equivalent IPv4 unicast addresses."=0A=0A=0AActually, I believe= that the precautions I suggested above will work here also instead of thos= e checks. Won't they?=0AIn general, I think that checks performed on the de= stination address (IPv4 or IPv6) should be more robust than checks on a sou= rce address.=0A=0A=0AWith this, an ISP that operates both 6rd and 6to4= relays is also immune to the routing-loop attack because:=0A- an IPv6 pack= et forwarded to the global Internet by 6rd relays can come back to the ISP = IPv4 network via one of the 6to4 relays of the ISP BUT cannot be accepted a= gain by a 6rd relay: its IPv4 source address is then one of a 6to4 relay, w= hich, with the first added sentence, prevents it from being accepted by the= 6rd relay.=0A- an IPv6 packet received from the IPv6 Internet by a 6rd rel= ay cannot be sent back to the IPv4 global Internet via one of the 6to4 rela= ys: the IPv4 address derived from its IPv6 destination would have for this = to be one of a 6to4 relays, which, with the second added sentence, prevents= it from being forwarded by the 6rd relay.=0A=0ANote: RFC 3068, where the 6= to4 anycast address is introduced, says that "each 6to4 relay router that a= dvertise the 6to4 anycast prefix MUST also provide an equivalent IPv4 unica= st address". Whether this is really important in practice is IMHO unclear. = On the other hand, if this MUST is dispensed with, the above security preca= ution can be implemented in 6rd relays without a need to handle a variable = number of addresses, and to administratively configure them (with the assoc= iated risks of human errors).=0A=0A=0AIf you do the check on the destin= ation address you can avoid this administrative configuration altogether.= =0A=0A=0ATo conclude:=0A- Without needing to modify 6to4 relays, ISATA= P relays, and Teredo relays, ISPs that support 6rd and don't support 6to4 a= ppear to be already protected against routing loop attacks if ingress filte= ring is operational at their interfaces to the IPv4 global Internet. With a= n additional simple precaution in 6rd relays, they can also be immune in th= e absence of such filtering.=0A=0AI fully agree.=0A=0A- A necessar= y additional security precaution against routing-loop attacks is now identi= fied for ISPs that support 6rd and that, having started with 6to4, wish to = keep it for backward compatibility. Thanks again for your analysis which ma= de it possible.=0A=0A=0ABest regards,=0ARD=0A=0A=0A=0ALe 17 ao=FBt 09 =E0 1= 7:21, Gabi Nakibly a =E9crit :=0A=0A> Hi all,=0A> I would like to draw the = attention of the list to some research results which my colleague and I at = the National EW Research & Simulation Center have recently published. The r= esearch presents a class of routing loop attacks that abuses 6to4, ISATAP a= nd Teredo. The paper can be found at: http://www.usenix.org/events/woot09/t= ech/full_papers/nakibly.pdf=0A> =0A> Here is the abstract:=0A> IPv6 is the = future network layer protocol for the Internet. Since it is not compatible = with its predecessor, some interoperability mechanisms were designed. An im= portant category of these mechanisms is automatic tunnels, which enable IPv= 6 communication over an IPv4 network without prior configuration. This cate= gory includes ISATAP, 6to4 and Teredo. We present a novel class of attacks = that exploit vulnerabilities in these tunnels. These attacks take advantage= of inconsistencies between a tunnel's overlay IPv6 routing state and the n= ative IPv6 routing state. The attacks form routing loops which can be abuse= d as a vehicle for traffic amplification to facilitate DoS attacks. We exhi= bit five attacks of this class. One of the presented attacks can DoS a Tere= do server using a single packet. The exploited vulnerabilities are embedded= in the design of the tunnels; hence any implementation of these tunnels ma= y be vulnerable. In particular, the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vist= a and Windows Server 2008 R2.=0A> =0A> I think the results of the research = warrant some corrective action. If this indeed shall be the general sentime= nt of the list, I will be happy write an appropriate I-D. The mitigation me= asures we suggested in the paper are the best we could think of to complete= ly eliminate the problem. However they are far from perfect since they woul= d require tunnel implementations to be updated in case new types of automat= ic tunnels are introduced.=0A> =0A> Your comments are welcome.=0A> =0A> Gab= i=0A> =0A> ----------------------------------------------------------------= ----=0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Adminis= trative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> ----------= ----------------------------------------------------------=0A=0A=0A=0A=0AHi= Gabi,=0A=0AFirst, thanks to you and your colleagues for this research, and= for the clear presentation of its results.=0AIn my understanding, your con= tribution is important for transition solutions to be carefully selected, a= nd where needed improved.=0A=0AThis mail is to complement the analysis with= what applies to 6rd.=0A=0AFor those who don't know it, 6rd, like 6to4, ISA= TAP and Teredo, is an automatic tunnel mechanism in actual use for IPv6 acr= oss IPv4 clouds.=0AWith it, service providers can offer native IPv6 to thei= r customers while using for this their existing IPv4 infrastructures.=0APub= lication of the RFC that describes it, RFC 5569, has been delayed since May= for a reason related to intellectual property rights applicable to indepen= dent submissions.=0ABut the draft on which 6rd is based is still available,= and a new draft to extend its applicability is also available:=0A- tools.i= etf.org/html/draft-despres-6rd-03=0A- tools.ietf.org/html/draft-townsley-ip= v6-6rd-01=0A=0A=0A=0A --0-73789995-1250676743=:58470 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Remi,
=0A
See my comments inline (<gn>).
= =0A
Gabi
=0A

=0A
=0A
=0A<= /DIV>=0A
From: R=E9mi Despr= =E9s <remi.despres@free.fr>
T= o: Gabi Nakibly <gnakibly@yahoo.com>
Cc: v6ops <v6ops@ops.ietf.org>; 6man 6m= an <ipv6@ietf.org>; secdir@ietf.org; Mark Townsley <townsley@cisco= .com>
Sent: Tuesday, = August 18, 2009 8:00:42 PM
Subject:= Re: Routing loop attacks using IPv6 tunnels - the 6rd case
<= /FONT>
Hi Gabi,

First, thanks to you and your colleagues for this= research, and for the clear presentation of its results.
In my understa= nding, your contribution is important for transition solutions to be carefu= lly selected, and where needed improved.

This mail is to complement = the analysis with what applies to 6rd.

For those who don't know it, 6rd, like 6to4, I= SATAP and Teredo, is an automatic tunnel mechanism in actual use for IPv6 a= cross IPv4 clouds.
With it, service providers can offer native IPv6 to t= heir customers while using for this their existing IPv4 infrastructures.Publication of the RFC that describes it, RFC 5569, has been delayed since= May for a reason related to intellectual property rights applicable to ind= ependent submissions.
But the draft on which 6rd is based is still avail= able, and a new draft to extend its applicability is also available:
- <= A href=3D"http://tools.ietf.org/html/draft-despres-6rd-03" target=3D_blank>= tools.ietf.org/html/draft-despres-6rd-03
- tools.ietf.org/htm= l/draft-townsley-ipv6-6rd-01
<gn>
=0A
I must admit that thi= s is the first time I read the spec of 6rd so forgive me if I miss somethin= g.
=0A
</gn>

(1) Case of ISPs that operate 6rd relays and n= o 6to4 relays (and neither Teredo relays nor ISP-infrastructure NATs)
In its sec. 3, draft-despres-6rd-03 says:
<<<
  The I= Pv4 anycast address of 6rd relays may be chosen independently by
  = each ISP.  The only constraint is that routes toward the ISP that are<= BR>  advertised must not include this address.
>>>
In v= iew of your study and in my understanding, it should be completed with:
= "Also, the ISP must not forward toward the global IPv4 global Internet pack= ets having this address as source."

With this, an ISP that operates = 6rd relays but operates neither 6to4 relays nor Teredo relays nor NATs is i= mmune to the routing loop attack because:
- An IPv6 packet forwarded to = the IPv6 Internet by a 6rd relay cannot come back to an IPv4 interface of a= 6rd relay of the same ISP: there is no IPv4 route back to the ISP for its 6rd = anycast address.
- An IPv6 packet received from the IPv6 Internet by a 6= rd relay cannot be sent back to the IPv4 global Internet: the source addres= s of its IPv4 encapsulating packet is the 6rd anycast address, which preven= ts it from reaching the IPv4 global Internet.

Note that, if interfac= es of the ISP to the IPv4 global Internet are already subject to ingress fi= ltering (packets received by the global Internet are discarded if there is = no reverse path available for them), the added sentence is not necessary. I= t is just just a double precaution for cases where such ingress filtering d= oesn't apply.
=0A
<gn>
=0A
I agree with you that above= check will work. However, I might choose another way here: the relay&= nbsp;must make the following two checks:
=0A
1) When an IPv6 packet= is received from the IPv6 Internet the 6rd relay must ensure before encaps= ulation that the intended IPv4 destination address belongs to one = ;of the ISP's clients (I assume it can make this check easil= y). This way no IPv6 packet received from the IPv6 Internet will be relayed= to a 6to4 relay (and then back to the 6rd relay through the IPv6 Internet)= .
=0A
2) When an encapsulated packet is received from the IPv4 network = side the 6rd relay must check that the IPv6 destination does not include it= s own IPv4 address. For example the IPv6 destination address must not be: 2= 002:<IPv4 address of 6rd relay>::/48. This will prevent the packet fr= om ever reaching back the 6rd relay through its IPv4 interface
= =0A
This way all the checks are done only at the= 6rd relay and not in other IPv4 border routers of the ISP which shoul= d not be aware of the 6rd deployment.
=0A
</gn>


(2) Cas= e of ISPs that operate 6rd relays AND 6to4 relays (but neither Teredo relay= s nor ISP-infrastructure NATs)

In its sec. 5 on security, draft-desp= res-6rd-03 says:
<<<
  o  RELAY PACKETS TOWARD THE= INTERNET: The IPv6 source must be a 6rd
      address th= at matches the IPv4 source.  The IPv6 destination must
   = ;   not start with the ISP 6rd prefix.
...
  o  RELAY = PACKETS FROM THE INTERNET: The IPv6 source must not be a 6rd
  &nbs= p;   address of the ISP.  The IPv4 destination must not be multic= ast,
      i.e. must not start with 224/3...
>>&= gt;

In view of your study and in my understanding, it MUST be comple= ted with:
- after the first quoted paragraph:
"Furthermore, if the IS= P also operates 6to4 relays that advertise on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 sou= rce must be neither the 6to4 anycast address 192.88.99.0 nor any of its equ= ivalent IPv4 unicast addresses."
- after the second quoted paragraph:"Furthermore, if the ISP also operates 6to4 relays that advertise on the I= Pv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 destination derived fr= om the IPv6 destination must be neither the IPv4 anycast address 192.88.99.= 0 nor any of its equivalent IPv4 unicast addresses."
=0A
<gn><= /DIV>=0A
Actually, I believe that the precautions I suggested above will work= here also instead of those checks. Won't they?
=0A
In general, I think = that checks performed on the destination address (IPv4 or IPv6) should be m= ore robust than checks on a source address.
=0A
</gn>
=0A
W= ith this, an ISP that operates both 6rd and 6to4 relays is also immune to t= he routing-loop attack because:
- an IPv6 packet forwarded to the global= Internet by 6rd relays can come back to the ISP IPv4 network via one of th= e 6to4 relays of the ISP BUT cannot be accepted again by a 6rd relay: its I= Pv4 source address is then one of a 6to4 relay, which, with the first added= sentence, prevents it from being accepted by the 6rd relay.
- an IPv6 p= acket received from the IPv6 Internet by a 6rd relay cannot be sent back to= the IPv4 global Internet via one of the 6to4 relays: the IPv4 address deri= ved from its IPv6 destination would have for this to be one of a 6to4 relay= s, which, with the second added sentence, prevents it from being forwarded = by the 6rd relay.

Note: RFC 3068, where the 6to4 anycast address is = introduced, says that "each 6to4 relay router that advertise the 6to4 anycast prefix MUST also provide an equivalent IPv4 unicast address".= Whether this is really important in practice is IMHO unclear. On the other= hand, if this MUST is dispensed with, the above security precaution can be= implemented in 6rd relays without a need to handle a variable number of ad= dresses, and to administratively configure them (with the associated risks = of human errors).

<gn>
=0A
If you do the check on the desti= nation address you can avoid this administrative configuration altogether.<= /DIV>=0A
</gn>

To conclude:
- Without needing to modify 6to4 = relays, ISATAP relays, and Teredo relays, ISPs that support 6rd and don't s= upport 6to4 appear to be already protected against routing loop attacks if = ingress filtering is operational at their interfaces to the IPv4 global Int= ernet. With an additional simple precaution in 6rd relays, they can also be= immune in the absence of such filtering.
=0A
<gn>
=0A
I fully = agree.
=0A
</gn>
- A necessary additional security precaution a= gainst routing-loop attacks is now identified for ISPs that support 6rd and= that, having started with 6to4, wish to keep it for backward compatibility= . Thanks again for your analysis which made it possible.


Best re= gards,
RD



Le 17 ao=FBt 09 =E0 17:21, Gabi Nakibly a =E9cr= it :

> Hi all,
> I would like to draw the attention of the = list to some research results which my colleague and I at the National EW R= esearch & Simulation Center have recently published. The research prese= nts a class of routing loop attacks that abuses 6to4, ISATAP and Teredo. Th= e paper can be found at: http://www.usenix.org/events/woot09/tech/full_pape= rs/nakibly.pdf
>
> Here is the abstract:
> IPv6 is the f= uture network layer protocol for the Internet. Since it is not compatible w= ith its predecessor, some interoperability mechanisms were designed. An important = category of these mechanisms is automatic tunnels, which enable IPv6 commun= ication over an IPv4 network without prior configuration. This category inc= ludes ISATAP, 6to4 and Teredo. We present a novel class of attacks that exp= loit vulnerabilities in these tunnels. These attacks take advantage of inco= nsistencies between a tunnel's overlay IPv6 routing state and the native IP= v6 routing state. The attacks form routing loops which can be abused as a v= ehicle for traffic amplification to facilitate DoS attacks. We exhibit five= attacks of this class. One of the presented attacks can DoS a Teredo serve= r using a single packet. The exploited vulnerabilities are embedded in the = design of the tunnels; hence any implementation of these tunnels may be vul= nerable. In particular, the attacks were tested against the ISATAP, 6to4 an= d Teredo implementations of Windows Vista and Windows Server 2008 R2.
>
> I think the results of the research warrant some corr= ective action. If this indeed shall be the general sentiment of the list, I= will be happy write an appropriate I-D. The mitigation measures we suggest= ed in the paper are the best we could think of to completely eliminate the = problem. However they are far from perfect since they would require tunnel = implementations to be updated in case new types of automatic tunnels are in= troduced.
>
> Your comments are welcome.
>
> Gabi=
>
> ---------------------------------------------------------= -----------
> IETF IPv6 working group mailing list
> ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= BR>> --------------------------------------------------------------------



=0A=0A --0-73789995-1250676743=:58470-- From mail@aliciazore.com Wed Aug 19 07:11:46 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CF23A6A82 for ; Wed, 19 Aug 2009 07:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.692 X-Spam-Level: X-Spam-Status: No, score=-85.692 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_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 XtPa+cmZMCZb for ; Wed, 19 Aug 2009 07:11:45 -0700 (PDT) Received: from 6mail.at (unknown [81.215.110.77]) by core3.amsl.com (Postfix) with SMTP id 68DF23A67F3 for ; Wed, 19 Aug 2009 07:11:43 -0700 (PDT) To: v6ops-archive@megatron.ietf.org Subject: Open Positions From: v6ops-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090819141144.68DF23A67F3@core3.amsl.com> Date: Wed, 19 Aug 2009 07:11:43 -0700 (PDT) Our company(US Surveys) is proud to inform you that we now have one secret-shopper position available.
This is a part time position as it doesn't take more then one hour to evaluate a store.
Your commission for each evaluation is $100 and you can receive assignments on daily basis.

In order to qualify for the secret-shopper position a candidate must be 21 years of age or older
and own a wellsfargo account (it is recommended to open a fresh account to be used for this position only).

If you are interested in working as a secret shopper for our company you can request more information at marianjflintwildhtkn@gmail.com

Thank you,
US Surveys Inc.
From owner-v6ops@ops.ietf.org Wed Aug 19 07:19:57 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70453A6A51 for ; Wed, 19 Aug 2009 07:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.722 X-Spam-Level: X-Spam-Status: No, score=-3.722 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 VUgvLeOT4IkA for ; Wed, 19 Aug 2009 07:19:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B63453A6B01 for ; Wed, 19 Aug 2009 07:18:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdlv8-00090I-Si for v6ops-data0@psg.com; Wed, 19 Aug 2009 14:13:46 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdlv3-0008zM-GL for v6ops@ops.ietf.org; Wed, 19 Aug 2009 14:13:44 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIeli0pAZnmf/2dsb2JhbAC9KogvkVoFhBo X-IronPort-AV: E=Sophos;i="4.43,408,1246838400"; d="scan'208";a="54627138" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Aug 2009 14:13:39 +0000 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 n7JEDdIB015480; Wed, 19 Aug 2009 10:13:39 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7JEDdp4015120; Wed, 19 Aug 2009 14:13:39 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.3959); Wed, 19 Aug 2009 10:13:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Posted a new copy of CPE Rtr draft Date: Wed, 19 Aug 2009 10:13:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posted a new copy of CPE Rtr draft Thread-Index: Acogsyz2AW3DDHvlStuObkIoogE4EgAIncvQ References: From: "Hemant Singh (shemant)" To: "Iljitsch van Beijnum" Cc: "Wes Beebee (wbeebee)" , X-OriginalArrivalTime: 19 Aug 2009 14:13:39.0107 (UTC) FILETIME=[3FA13F30:01CA20D7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2056; t=1250691219; x=1251555219; 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=20Posted=20a=20new=20copy=20of=20CPE=20Rt r=20draft |Sender:=20 |To:=20=22Iljitsch=20van=20Beijnum=22=20; bh=yXzavQxaj4gNshHsM3jyKnYF0z6zDZcrFcXUb53uCOg=; b=eGOiKu08pRXsHgRo5hAvZIIGsGFeRqRXjtenp2pEYHYuTL8se1KZ6f08ev wFONOa0kWkBSIZPqCs6diZBsAizJfedTk24zXytgiR3/jb0pQFMqxwijPUbd XS1m9TzwJO; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 Sent: Wednesday, August 19, 2009 5:55 AM To: Hemant Singh (shemant) Cc: Wes Beebee (wbeebee); v6ops@ops.ietf.org Subject: Re: Posted a new copy of CPE Rtr draft >Hm, looks like you're keeping the text the same in the majority of the >cases. As you may expect, that doesn't make me particularly happy. Sorry, we forgot to edit the -01 for two places I said we'd make a change. The one place was to remove the "preferred to be Ethernet" and other places was to make a sentence better in the ND Proxy section as follows: [If a CPE Router will never be deployed in an environment with these characteristics, then ND Proxy is not necessary.]. All other agreement for changing any MAY to a MUST was only agreed by us but I said the broader mailer has to agree to such a change and that is why we didn't make any such MAY to MUST changes. >Also, pointing to general discussions a while ago is not a very =20 >satisfactory response, this would require me to sift through the =20 >archives in the hopes of finding the argument you have in mind, a =20 >procedure that is time consuming and error prone. There were two cases in my response that pointed to the v6ops archives. I'd be happy to explain the two cases here. Case (a) the ULA discussion. Here is the reasoning. Brian Carpenter gave the dentist example and we all agreed to keep ULA permanent (if at all the CPE Rtr decides to support ULA) because if the SP network goes down, the GUA in the home is no longer active. In such a case, the ULA is still active and folks in the home can print to their printer or what have you.=20 Case (b) strong host model sentence and Shin M.'s request. NTT (I believe it is NTT West) in Japan has hacked up routing code they provide to their broadband customers to run the code on a Windows PC. So this happens to be a router running under Windows. Now once can see how do strong vs. weak host models get into play. Hemant =20 From mail@agence-metier.com Wed Aug 19 07:23:39 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9513A6ABF for ; Wed, 19 Aug 2009 07:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.16 X-Spam-Level: X-Spam-Status: No, score=-81.16 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8GY29yZwT4W for ; Wed, 19 Aug 2009 07:23:39 -0700 (PDT) Received: from c-98-234-96-81.hsd1.ca.comcast.net (c-98-234-96-81.hsd1.ca.comcast.net [98.234.96.81]) by core3.amsl.com (Postfix) with SMTP id 8EA153A6BC0 for ; Wed, 19 Aug 2009 07:23:37 -0700 (PDT) To: v6ops-archive@ietf.org Subject: Representatives Wanted From: v6ops-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090819142338.8EA153A6BC0@core3.amsl.com> Date: Wed, 19 Aug 2009 07:23:37 -0700 (PDT) Our company(US Surveys) is proud to inform you that we now have one secret-shopper position available.
This is a part time position as it doesn't take more then one hour to evaluate a store.
Your commission for each evaluation is $100 and you can receive assignments on daily basis.

In order to qualify for the secret-shopper position a candidate must be 21 years of age or older
and own a wellsfargo account (it is recommended to open a fresh account to be used for this position only).

If you are interested in working as a secret shopper for our company you can request more information at jesuslhardenanzfasv@gmail.com

Thank you,
US Surveys Inc.
From owner-v6ops@ops.ietf.org Wed Aug 19 07:52:26 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221D428C42D for ; Wed, 19 Aug 2009 07:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 9LEBBJB1clUS for ; Wed, 19 Aug 2009 07:52:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B1C0828C42B for ; Wed, 19 Aug 2009 07:52:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdmU2-000EcQ-Ae for v6ops-data0@psg.com; Wed, 19 Aug 2009 14:49:50 +0000 Received: from [194.29.32.54] (helo=dlpdemo.checkpoint.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdmTw-000Eb6-Os for v6ops@ops.ietf.org; Wed, 19 Aug 2009 14:49:47 +0000 Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B9B4E29C008; Wed, 19 Aug 2009 17:50:04 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6B0E429C004; Wed, 19 Aug 2009 17:50:04 +0300 (IDT) X-CheckPoint: {4A8C1037-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n7JEnf3d026551; Wed, 19 Aug 2009 17:49:41 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 19 Aug 2009 17:49:42 +0300 From: Yaron Sheffer To: "Hemant Singh (shemant)" , "v6ops@ops.ietf.org" CC: "Wes Beebee (wbeebee)" Date: Wed, 19 Aug 2009 17:49:40 +0300 Subject: RE: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Thread-Topic: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Thread-Index: AcogR5sPMTp9vGcPRUiqGisolv/kKAAAZUogACRXw8A= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B238@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0055_01CA20F5.6D16FD60" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0055_01CA20F5.6D16FD60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Hemant, I took a quick look at the BIS document, and it is not self explanatory. = What does "DEV" mean? What does "MEDIUM" mean? A terminology section = would be appreciated. Do we really consider packet filtering (a technology older than IPv6 :-) = to be "under development"? How does this document relate to the "simple = security" draft? Thanks, Yaron > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf > Of Hemant Singh (shemant) > Sent: Wednesday, August 19, 2009 0:19 > To: v6ops@ops.ietf.org > Cc: Hemant Singh (shemant); Wes Beebee (wbeebee) > Subject: FW: New Version Notification for draft-ietf-v6ops-ipv6-cpe- > router-01 >=20 > Folks, >=20 > This is the last version of the IPv6 CPE Router Recommendations with I = and > Wes as authors. The next revision will include Ole Troan and Chris = Donley > as co-authors. > Since San Francisco IETF in Spring 2009, a decision was made to split = up > the document into two. The second document has also been posted today = as > draft-wbeebee-v6ops-ipv6-cpe-router-bis-00.txt. >=20 > Hemant >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, August 18, 2009 5:05 PM > To: Hemant Singh (shemant) > Cc: Wes Beebee (wbeebee) > Subject: New Version Notification for = draft-ietf-v6ops-ipv6-cpe-router-01 >=20 >=20 > A new version of I-D, draft-ietf-v6ops-ipv6-cpe-router-01.txt has been > successfuly submitted by Hemant Singh and posted to the IETF = repository. >=20 > Filename: draft-ietf-v6ops-ipv6-cpe-router > Revision: 01 > Title: IPv6 CPE Router Recommendations > Creation_date: 2009-08-18 > WG ID: v6ops > Number_of_pages: 21 >=20 > Abstract: > This document recommends IPv6 behavior for Customer Premises > Equipment (CPE) routers in Internet-enabled homes and small offices. > The CPE Router may be a standalone device. The CPE Router may also > be embedded in a device such as a cable modem, DSL modem, cellular > phone, etc. This document describes the router portion of such a > device. The purpose behind this document is to provide minimal > functionality for interoperability and create consistency in the > customer experience and satisfy customer expectations for the device. > Further, the document also provide some guidance for implementers to > expedite availability of IPv6 CPE router products in the marketplace. > It is expected that standards bodies other than the IETF developing > standards for specific products in this area (e.g. CableLabs > eRouter, Broadband Forum, Home Gateway Initiative, etc.) may > reference this work for basic functionality and provide value-added > or linktype-specific customizations and enhancements which are beyond > the scope of this document. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > = =04=EF=BF=BDjy=EF=BF=BDu=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD$>=EF=BF=BD=EF= =BF=BD=EF=BF=BD:-jT=EF=BF=BDr=EF=BF=BD=EF=BF=BD!=EF=BF=BD=EF=BF=BD=EF=BF=BD= =1A ------=_NextPart_000_0055_01CA20F5.6D16FD60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxOTE0NDk0MFowIwYJKoZIhvcNAQkEMRYEFG60qLvZP7/V 09DHqu2mO6jz4kHMMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA TRGdKKWMoHIaLZH/K0B44l6Ud7VqDvy/wZi4d3PsCtqm77Ecf++sURG3yygqZsQeDYAL3eaxsqm+ +04rqUG6nSwC/w+M4OEZ19SCBu57SCdk4AyISxZaBtPDushH5MF7KGLOLpo6C0v/p5PAArs/hXER v24uXXvogezj/CWtgt0q20elbNIqRpawJ2fI4smgOfcLkXRoYfhDde0OBOvcXV9DfV05Cutlq47J +m+oUIbcI7TDoBU9qlCbp6+QsfIPX5KQKpZA0Pyno/xqasiYPn8n8HesfMSTZ5J1sfQRWrBkWtpl Q3iLEAgoaBLs2Nt2MrBFHKr/lWGcmO8FRzlQowAAAAAAAA== ------=_NextPart_000_0055_01CA20F5.6D16FD60-- From owner-v6ops@ops.ietf.org Wed Aug 19 08:06:56 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13DE03A6834 for ; Wed, 19 Aug 2009 08:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.746 X-Spam-Level: X-Spam-Status: No, score=-3.746 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 we4GrrsQ7wpc for ; Wed, 19 Aug 2009 08:06:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 872E83A6A36 for ; Wed, 19 Aug 2009 08:06:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdmis-000HIq-4Q for v6ops-data0@psg.com; Wed, 19 Aug 2009 15:05:10 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdmin-000HG3-Bn for v6ops@ops.ietf.org; Wed, 19 Aug 2009 15:05:07 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAP6xi0pAZnmf/2dsb2JhbACZYqNNiC+RUQWEGoFT X-IronPort-AV: E=Sophos;i="4.43,408,1246838400"; d="scan'208";a="54676084" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Aug 2009 15:05:04 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7JF54J0001380; Wed, 19 Aug 2009 11:05:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7JF54rD026387; Wed, 19 Aug 2009 15:05:04 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.3959); Wed, 19 Aug 2009 11:05:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Date: Wed, 19 Aug 2009 11:05:03 -0400 Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B238@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Thread-Index: AcogR5sPMTp9vGcPRUiqGisolv/kKAAAZUogACRXw8AAAJ2YYA== References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B238@il-ex01.ad.checkpoint.com> From: "Hemant Singh (shemant)" To: "Yaron Sheffer" , Cc: "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 19 Aug 2009 15:05:03.0952 (UTC) FILETIME=[6E573D00:01CA20DE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5704; t=1250694304; x=1251558304; 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=20New=20Version=20Notification=20for=20dr aft-ietf-v6ops-ipv6-cpe-router-01=20 |Sender:=20 |To:=20=22Yaron=20Sheffer=22=20,=20< v6ops@ops.ietf.org>; bh=WqBXDE6hqXdJm8zuG7xNrQbSKgQGGcOnCcyq5hhSzA0=; b=keXUInnzNSD3yPyk9Rf5VSe4iJmn0uqawQBvVqHQF9NJQGmKI5hBWZ/sAW L/MTc8lSDmcTZPSUcSPoIhY7BL9rvik8Tvps6ni5u5zCvEWaKoTPVlEpdIxU 55/DgHwQ2o; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: WWFyb24sDQoNClRoaXMgQklTIGRvY3VtZW50IGlzIHBhcnQgMiBvZiB0aGUgSVB2NiBDUEUgUm91 dGVyIFJlY29tbWVuZGF0aW9ucyBkb2N1bWVudC4gIFRoZSBmaXJzdCBkb2N1bWVudCBpcyBhdA0K DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtdjZvcHMtaXB2Ni1jcGUtcm91dGVy LTAxLnR4dA0KDQpQbGVhc2Ugc2VlIGxhc3QgcGFyYWdyYXBoIGluIHNlY3Rpb24gMSBvZiB0aGUg ZHJhZnQgYWJvdmUgZm9yIGV4cGxhbmF0aW9uIG9mIHRoZSBERVYgYW5kIE1FRElVTSB0ZXJtcy4g DQoNClRoaXMgZG9jdW1lbnQgZG9lcyBub3QgdHJ5IHRvIGRlZmluZSBhbnkgbmV3IElQdjYgc2Vj dXJpdHkgYW5kIGluc3RlYWQgcG9pbnRzIHRvIHRoZSBJUHY2IHNpbXBsZSBzZWN1cml0eSBkb2N1 bWVudC4gICBUaGUgb25seSByZWFzb24gcGFja2V0IGZpbHRlcmluZyBoYXMgYmVlbiBkZWZpbmVk IGFzIERFViBpcyBiZWNhdXNlIGl0IGlzIGRlc2NyaWJlZCBpbiBtb3JlIGRldGFpbCBpbiB0aGUg c2ltcGxlIHNlY3VyaXR5IGRvY3VtZW50IGJ1dCB0aGUgc2ltcGxlIHNlY3VyaXR5IGRvY3VtZW50 IGlzIFdvcmsgaW4gUHJvZ3Jlc3MgKG5vdCBhbiBSRkMgeWV0KS4gIEluIGdlbmVyYWwgSSBhZ3Jl ZSB3aXRoIHlvdSB0aGF0IHBhY2tldCBmaWx0ZXJpbmcgaXMgb2xkZXIgdGhhbiBJUHY2LiAgRG8g YXBwcmVjaWF0ZSBvbmUgZmFjdCB0aGF0IGdpdmVuIHR1bm5lbGVkIElQdjYgZGF0YSBhbmQgbmV3 IGRyYWZ0cyBpbiB0aGUgYXJlYSBvZiBjaGFuZ2luZyBJUHY2IHN0YW5kYXJkcyBmb3IgZmlyZXdh bGwgdHJhdmVyc2FsIGhhcyBub3QgYWdyZWVkIHVwb24gaG93IHRvIGZpbHRlciByZWxldmFudCBJ UHY2IGRhdGEuICBUaGF0IGlzIHdoZXJlIHNvbWUgbW9yZSBvZiBERVYgYmVoYXZpb3IgZ2V0cyBp bnRvIHBhY2tldCBmaWx0ZXJpbmcgZm9yIElQdjYuDQoNCkhlbWFudA0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogWWFyb24gU2hlZmZlciBbbWFpbHRvOnlhcm9uZkBjaGVja3Bv aW50LmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxOSwgMjAwOSAxMDo1MCBBTQ0KVG86 IEhlbWFudCBTaW5naCAoc2hlbWFudCk7IHY2b3BzQG9wcy5pZXRmLm9yZw0KQ2M6IFdlcyBCZWVi ZWUgKHdiZWViZWUpDQpTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1pZXRmLXY2b3BzLWlwdjYtY3BlLXJvdXRlci0wMSANCg0KSGkgSGVtYW50LA0KDQpJIHRv b2sgYSBxdWljayBsb29rIGF0IHRoZSBCSVMgZG9jdW1lbnQsIGFuZCBpdCBpcyBub3Qgc2VsZiBl eHBsYW5hdG9yeS4gV2hhdCBkb2VzICJERVYiIG1lYW4/IFdoYXQgZG9lcyAiTUVESVVNIiBtZWFu PyBBIHRlcm1pbm9sb2d5IHNlY3Rpb24gd291bGQgYmUgYXBwcmVjaWF0ZWQuDQoNCkRvIHdlIHJl YWxseSBjb25zaWRlciBwYWNrZXQgZmlsdGVyaW5nIChhIHRlY2hub2xvZ3kgb2xkZXIgdGhhbiBJ UHY2IDotKSB0byBiZSAidW5kZXIgZGV2ZWxvcG1lbnQiPyBIb3cgZG9lcyB0aGlzIGRvY3VtZW50 IHJlbGF0ZSB0byB0aGUgInNpbXBsZSBzZWN1cml0eSIgZHJhZnQ/DQoNClRoYW5rcywNCglZYXJv bg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG93bmVyLXY2b3BzQG9w cy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZ10gT24gQmVoYWxmDQo+ IE9mIEhlbWFudCBTaW5naCAoc2hlbWFudCkNCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTks IDIwMDkgMDoxOQ0KPiBUbzogdjZvcHNAb3BzLmlldGYub3JnDQo+IENjOiBIZW1hbnQgU2luZ2gg KHNoZW1hbnQpOyBXZXMgQmVlYmVlICh3YmVlYmVlKQ0KPiBTdWJqZWN0OiBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXY2b3BzLWlwdjYtY3BlLQ0KPiByb3V0ZXIt MDENCj4gDQo+IEZvbGtzLA0KPiANCj4gVGhpcyBpcyB0aGUgbGFzdCB2ZXJzaW9uIG9mIHRoZSBJ UHY2IENQRSBSb3V0ZXIgUmVjb21tZW5kYXRpb25zIHdpdGggSSBhbmQNCj4gV2VzIGFzIGF1dGhv cnMuICBUaGUgbmV4dCByZXZpc2lvbiB3aWxsIGluY2x1ZGUgT2xlIFRyb2FuIGFuZCBDaHJpcyBE b25sZXkNCj4gYXMgY28tYXV0aG9ycy4NCj4gU2luY2UgU2FuIEZyYW5jaXNjbyBJRVRGIGluIFNw cmluZyAyMDA5LCBhIGRlY2lzaW9uIHdhcyBtYWRlIHRvIHNwbGl0IHVwDQo+IHRoZSBkb2N1bWVu dCBpbnRvIHR3by4gIFRoZSBzZWNvbmQgZG9jdW1lbnQgaGFzIGFsc28gYmVlbiBwb3N0ZWQgdG9k YXkgYXMNCj4gZHJhZnQtd2JlZWJlZS12Nm9wcy1pcHY2LWNwZS1yb3V0ZXItYmlzLTAwLnR4dC4N Cj4gDQo+IEhlbWFudA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog SUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXQ0K PiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTgsIDIwMDkgNTowNSBQTQ0KPiBUbzogSGVtYW50IFNp bmdoIChzaGVtYW50KQ0KPiBDYzogV2VzIEJlZWJlZSAod2JlZWJlZSkNCj4gU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXY2b3BzLWlwdjYtY3BlLXJvdXRl ci0wMQ0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXY2b3BzLWlw djYtY3BlLXJvdXRlci0wMS50eHQgaGFzIGJlZW4NCj4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5 IEhlbWFudCBTaW5naCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBG aWxlbmFtZToJIGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1jcGUtcm91dGVyDQo+IFJldmlzaW9uOgkg MDENCj4gVGl0bGU6CQkgSVB2NiBDUEUgUm91dGVyIFJlY29tbWVuZGF0aW9ucw0KPiBDcmVhdGlv bl9kYXRlOgkgMjAwOS0wOC0xOA0KPiBXRyBJRDoJCSB2Nm9wcw0KPiBOdW1iZXJfb2ZfcGFnZXM6 IDIxDQo+IA0KPiBBYnN0cmFjdDoNCj4gVGhpcyBkb2N1bWVudCByZWNvbW1lbmRzIElQdjYgYmVo YXZpb3IgZm9yIEN1c3RvbWVyIFByZW1pc2VzDQo+IEVxdWlwbWVudCAoQ1BFKSByb3V0ZXJzIGlu IEludGVybmV0LWVuYWJsZWQgaG9tZXMgYW5kIHNtYWxsIG9mZmljZXMuDQo+IFRoZSBDUEUgUm91 dGVyIG1heSBiZSBhIHN0YW5kYWxvbmUgZGV2aWNlLiAgVGhlIENQRSBSb3V0ZXIgbWF5IGFsc28N Cj4gYmUgZW1iZWRkZWQgaW4gYSBkZXZpY2Ugc3VjaCBhcyBhIGNhYmxlIG1vZGVtLCBEU0wgbW9k ZW0sIGNlbGx1bGFyDQo+IHBob25lLCBldGMuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUg cm91dGVyIHBvcnRpb24gb2Ygc3VjaCBhDQo+IGRldmljZS4gIFRoZSBwdXJwb3NlIGJlaGluZCB0 aGlzIGRvY3VtZW50IGlzIHRvIHByb3ZpZGUgbWluaW1hbA0KPiBmdW5jdGlvbmFsaXR5IGZvciBp bnRlcm9wZXJhYmlsaXR5IGFuZCBjcmVhdGUgY29uc2lzdGVuY3kgaW4gdGhlDQo+IGN1c3RvbWVy IGV4cGVyaWVuY2UgYW5kIHNhdGlzZnkgY3VzdG9tZXIgZXhwZWN0YXRpb25zIGZvciB0aGUgZGV2 aWNlLg0KPiBGdXJ0aGVyLCB0aGUgZG9jdW1lbnQgYWxzbyBwcm92aWRlIHNvbWUgZ3VpZGFuY2Ug Zm9yIGltcGxlbWVudGVycyB0bw0KPiBleHBlZGl0ZSBhdmFpbGFiaWxpdHkgb2YgSVB2NiBDUEUg cm91dGVyIHByb2R1Y3RzIGluIHRoZSBtYXJrZXRwbGFjZS4NCj4gSXQgaXMgZXhwZWN0ZWQgdGhh dCBzdGFuZGFyZHMgYm9kaWVzIG90aGVyIHRoYW4gdGhlIElFVEYgZGV2ZWxvcGluZw0KPiBzdGFu ZGFyZHMgZm9yIHNwZWNpZmljIHByb2R1Y3RzIGluIHRoaXMgYXJlYSAoZS5nLiAgQ2FibGVMYWJz DQo+IGVSb3V0ZXIsIEJyb2FkYmFuZCBGb3J1bSwgSG9tZSBHYXRld2F5IEluaXRpYXRpdmUsIGV0 Yy4pIG1heQ0KPiByZWZlcmVuY2UgdGhpcyB3b3JrIGZvciBiYXNpYyBmdW5jdGlvbmFsaXR5IGFu ZCBwcm92aWRlIHZhbHVlLWFkZGVkDQo+IG9yIGxpbmt0eXBlLXNwZWNpZmljIGN1c3RvbWl6YXRp b25zIGFuZCBlbmhhbmNlbWVudHMgd2hpY2ggYXJlIGJleW9uZA0KPiB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC4NCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQuDQo+IA0KPiAN Cj4gBO+/vWp577+9de+/ve+/ve+/ve+/vSQ+77+977+977+9Oi1qVO+/vXLvv73vv70h77+977+9 77+9Gg0K From owner-v6ops@ops.ietf.org Wed Aug 19 08:20:03 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFC728C42B for ; Wed, 19 Aug 2009 08:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 sZHO8cTTt9G8 for ; Wed, 19 Aug 2009 08:20:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0090D28C406 for ; Wed, 19 Aug 2009 08:20:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdmtq-000IpZ-9R for v6ops-data0@psg.com; Wed, 19 Aug 2009 15:16:30 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdmtl-000Ip0-1E for v6ops@ops.ietf.org; Wed, 19 Aug 2009 15:16:27 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7JFGKcd015199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Aug 2009 08:16:21 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7JFGKlO012175; Wed, 19 Aug 2009 10:16:20 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7JFGHbw012098; Wed, 19 Aug 2009 10:16:20 -0500 (CDT) 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.3959); Wed, 19 Aug 2009 08:16:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Routing loop attacks using IPv6 tunnels Date: Wed, 19 Aug 2009 08:16:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1064DB28F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <689783.40421.qm@web45505.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcogqfWX02z6QDvcQleWnEJQ4OsboAAJVPYg References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> <2705.42043.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106498101@XCH-NW-7V2.nw.nos.boeing.com> <689783.40421.qm@web45505.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" Cc: , X-OriginalArrivalTime: 19 Aug 2009 15:16:20.0245 (UTC) FILETIME=[01715C50:01CA20E0] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Gabi, I'm sorry to have to keep turning this into plaintext, but annotation is difficult otherwise. See below for my responses (=3D=3D>): ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Wednesday, August 19, 2009 1:49 AM To: Templin, Fred L; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: Re: Routing loop attacks using IPv6 tunnels Fred, See my comments inline (). ________________________________________ From: "Templin, Fred L" To: Gabi Nakibly ; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Sent: Tuesday, August 18, 2009 6:48:45 PM Subject: RE: Routing loop attacks using IPv6 tunnels Gabi, ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Tuesday, August 18, 2009 3:29 AM To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Indeed the ISATAP interface of the ISATAP router is meant > to be an enterprise-interior (note that=A0it is still=A0assumed > that the associated IPv4 address is=A0non-private). As=A0we > explicitly note in the paper, the first three attacks=A0will > be mitigated=A0if proper protocol-41 filtering is deployed on > the site's border. However, note that RFC5214 does not mandate > or require this filtering. The RFC5214 Security Considerations makes clear the consequences of not implementing IPv4 ingress filtering and ip-protocol-41 filtering (i.e., a possible spooing attack in which spurious ip-protocol-41 packets are injected into an ISATAP link from outside). RFC5214 Section 6.2 additionally requires that an ISATAP interface's locator set MUST NOT span multiple sites. This means that the ISATAP interface must not decapsulate nor source ip-proto-41 packets within multiple sites, where the enterprise interior is site #1 and the global Internet is site #2. ip-protocol-41 filtering is the way in which the ISATAP interface is restricted to a single site.=20 Now let me see that I understand Section 6.2 correctly. In attack #2, for example, I assume the ISATAP router has two physical interfaces. A site-internal IPv4 interface with an address IPisatap and a site-external IPv6 interface. I also assume that there=A0is another border router which connects the site to the IPv4 Internet.=A0The ISATAP router has an ISATAP interface with a single locator: (IPisatap, site-internal interface).=A0When the ISATAP router gets an IPv6 via its external interface it will encapsulate the packet accordingly and forward it through the internal IPv4 interface. If the encapsulated packet is=A0destined to a node outside the site then the only thing that stops it is=A0a proto-41 filtering at the=A0other border router of the site. Did I get this right? =3D=3D> In this case, yes - the ip-proto-41 filtering is at a =3D=3D> border router. I know of at least one major enterprise =3D=3D> network that does this. > It is only mentioned as a possible mitigation against > incoming spurious protocol-41 packets. In addition, > Section 10 of RFC5214 only mentions=A0ingress not=A0egress > filtering.=A0Hence it=A0will not stop attack #2. We are now talking about ip-proto-41 filtering; not ingress filtering. ip-proto-41 filtering is in both directions. It prevents ip-proto-41 packets from entering the enterprise interior ISATAP site from the Internet and prevents ip-proto-41 packets from entering the Internet ISATAP site from the enterprise interior. Else the ISATAP interface would span multiple sites. Besides, "ingress" filtering is not about packets coming from the Internet into the end site, but rather it is about packets leaving the end site and going out into the Internet. RFC2827 (BCP38) documents ingress filtering. OK. I see what you are saying here. =3D=3D> OK. > In addition, > as mentioned, protocol-41 filtering is not helpful when > attack #3 is launched on two routers that reside in the > same site. Note that=A0it=A0may be=A0possible for=A0the attack > packet=A0to be sourced from outside the site unless proper > filtering of incoming IPv6 packets is deployed. If the > attacker resides in the site, usually ingress filtering > will not be helpful since it is deployed in general on > the site's border. Here, we have the ISATAP router in both cases sourcing a packet from a foreign prefix.=20 Well, I do not see how this is correct. In attacks #1 and #3 the ISATAP = router sources (actually forwards) an IPv6=A0packet with=A0a source = address having=A0the corresponding=A0prefix of the ISATAP tunnel. In = attacks #2 and #3 the ISATAP router sources and IPv4 packet with its own = IPv4 address as the source address. =3D=3D> There were a number of errors in what I said in my last =3D=3D> message, so let me see if I can get it right here: =3D=3D> =3D=3D> In attacks #1 and #2 there are two cases to consider. Case =3D=3D> 1 in which a border router separates the 6to4 relay from the =3D=3D> ISATAP router, and case 2 in which no border router separates =3D=3D> the 6to4 relay from the ISATAP router. =3D=3D> =3D=3D> In attack #1, we have an IPv6 packet with a local source =3D=3D> address entering the site from the outside. IPv6 ingress =3D=3D> filtering at the site border router should prevent the =3D=3D> packet from entering the site in the first place. If the =3D=3D> 6to4 relay router is outside the site then ip-proto-41 =3D=3D> filtering at the border router will block the attack in =3D=3D> the first place anyway. If the relay router is *inside* =3D=3D> the site, then the IPv6 ingress filtering is the lone =3D=3D> mitigation. The end result is that the 6to4 relay should =3D=3D> really be positioned outside of the site's border routers; =3D=3D> otherwise, it could be spoofed into thinking that the =3D=3D> ISATAP router is a 6to4 router and not an ISATAP router.=20 =3D=3D> =3D=3D> In attack #2, we have an IPv6 packet with a foreign source =3D=3D> address being forwarded by the ISATAP router to a 6to4 =3D=3D> relay, but I mis-spoke when I said that this would be a =3D=3D> case of the ISATAP router forwarding a packet with a foreign =3D=3D> source address out of the ISATAP link. For all the ISATAP =3D=3D> router knows, the 6to4 relay is just an ordinary host on =3D=3D> the ISATAP link, so the ISATAP router actually believes it =3D=3D> is forwarding the packet *into* the ISATAP link (not out of =3D=3D> it). But as in attack #1, the attack is blocked by ip-proto-41 =3D=3D> filtering at the border router between the ISATAP router and =3D=3D> the 6to4 relay. If there is no border router between the ISATAP =3D=3D> router and the 6to4 relay, then we have an identical instance =3D=3D> to attack #3 which I will discuss below. But, the best =3D=3D> operational practice would again be to have the 6to4 relay =3D=3D> oriented outside of a border router that filters ip-proto-41. =3D=3D> =3D=3D> Short summary is that in attack #1, the 6to4 relay thinks it =3D=3D> is talking to a 6to4 router and not an ISATAP router. In =3D=3D> attack #2, the ISATAP router thinks it is talking to a =3D=3D> simple host on the link and not a 6to4 relay. In both cases, =3D=3D> the attacks are mitigated when there is an ip-proto-41 =3D=3D> filtering border router between the ISATAP router and the =3D=3D> 6to4 relay. Oftentimes, the "border router" will be a two- =3D=3D> interface router that implements 6to4 on a site-external =3D=3D> IPv4 interface and implements ISATAP on a site-internal =3D=3D> IPv4 interface and performs ip-proto-41 filtering on packets =3D=3D> from outside the site with an IPv4 destination corresponding =3D=3D> to the ISATAP interface. I will discuss attack #3 below: =A0 This attack is mitigated by=20 IPv6 ingress filtering which is an IPv6 security consideration and not an ISATAP nor IPv4 security consideration. BCP recommendations for network ingress filtering are documented in RFC2827 and it is expected that IPv6 routers that configure ISATAP interfaces will implement IPv6 ingress filtering according to the BCP. So If my last comment is correct than I do not see how ingress filtering = would help here. The only case where=A0ingress filtering can help is in = case of attack #3 when the routers reside at the same site. In that case = if the attack packet (packet 0) is sent from outside the site then = ingress filtering on the border of the site will drop the packet. =3D=3D> Correct about the IPv6 ingress filtering at the border, =3D=3D> but as with attack #2 my error in the previous message =3D=3D> was in thinking the ISATAP router A was forwarding the =3D=3D> packet *out* of the ISATAP link when in fact from the =3D=3D> ISATAP router's perspective it is forwarding the packet =3D=3D> to a simple host *inside* of the link. =3D=3D> =3D=3D> The problem here is that the ISATAP router is blindly =3D=3D> forwarding a packet to a node that it assumes is a simple =3D=3D> host on the ISATAP link without first verifying that the =3D=3D> node has demonstrated a willingness to participate as a =3D=3D> host on the link. As you have pointed out, this can lead =3D=3D> to strange scenarios when the anonymous node is a tunnel =3D=3D> router of some sort that does not participate in the =3D=3D> ISATAP link. =3D=3D> =3D=3D> It would not generally be possible for the ISATAP router =3D=3D> to check whether the IPv6 destination address is an ISATAP =3D=3D> address that embeds one of its own IPv4 addresses, because =3D=3D> when IPv4 private addresses are used the same IPv4 address =3D=3D> can (and often does) occur in multiple sites. So for example, =3D=3D> if the ISATAP router configures an IPv4 address 10.0.0.1 =3D=3D> and is asked to forward an IPv6 packet with ISATAP =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where the =3D=3D> IPv6 prefix is foreign, the router can't very well drop the =3D=3D> packet as this would block legitimate communications. It =3D=3D> is also not generally possible to check whether a foreign =3D=3D> link is an ISATAP link by looking for the magic token =3D=3D> "0:5EFE" as that token only has significance for ISATAP =3D=3D> links and not other link types. =3D=3D> =3D=3D> Instead, the mitigation I think makes the most sense is =3D=3D> for the ISATAP router to first verify that the node which =3D=3D> it assumes to be a simple ISATAP host has demonstrated a =3D=3D> willingness to participate in the link. That can be done =3D=3D> by having the ISATAP router first check the neighbor cache =3D=3D> when it has a packet to send to verify that there is a =3D=3D> cached entry corresponding to the destination. For nodes =3D=3D> that are willing ISATAP hosts on the link, there would =3D=3D> have been a neighbor cache entry created when the node =3D=3D> sends a Router Solicitation to the ISATAP router for the =3D=3D> purpose of discovering default router lifetimes and on- =3D=3D> link prefixes. So, the simple mitigations is for the ISATAP =3D=3D> router to forward the packet only if there is a pre-existing =3D=3D> neighbor cache entry and drop the packet otherwise. This =3D=3D> implies that the router should keep neighbor cache entires =3D=3D> for the duration of the minimum lifetime of the prefixes =3D=3D> it advertises in its Router Advertisements. =20 > In general, I would like to point out that indeed as in > most other attacks these attacks may also be mitigated by > proper firewall rules. However, I do not believe that this > should be our only answer against these attacks. I believe > that since these attacks are made possible due to the > inherent characteristics of the tunnels they=A0should be > stopped intrinsically as much as possible by the tunnel > participants and not relay on outside filtering rules. In RFC5214, Section 10 we have: "restricting access to the link can be achieved by restricting access to the site". The mitigations do exactly that, and in such a way that ISATAP nodes can operate with only the necessary and sufficient checks. So on this point, I do not share your opinion. What about two ISATAP tunnels that reside on the same site like in = attack #3. Do you=A0also think that proto-41 filtering should barrier = between the two tunnels within the site?=A0 =3D=3D> I think this may be overcome by the discussion above. =3D=3D> Short story is that operational practices must be =3D=3D> employed whereby an ISATAP router is not mistaken for =3D=3D> a 6to4 router. This is through proper arrangement of =3D=3D> 6to4 router/relay interfaces outside of the site border =3D=3D> rather than inside, and ISATAP router interfaces inside =3D=3D> of the site border rather than outside. Also proper =3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at =3D=3D> site borders. =3D=3D> =3D=3D> Also, when there are multiple ISATAP links within the =3D=3D> same local IPv4 routing region, an ISATAP router should =3D=3D> first verify a node's willingness to act as a host on =3D=3D> the ISATAP link before blindly sending a packet to it. =3D=3D> =3D=3D> Fred =3D=3D> fred.l.templin@boeing.com Fred fred.l.templin@boeing.com =A0 ________________________________________ From: "Templin, Fred L" To: Gabi Nakibly ; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Sent: Monday, August 17, 2009 8:35:08 PM Subject: RE: Routing loop attacks using IPv6 tunnels Gabi, =A0 Thanks for publishing this work. In the document, attacks A, B and C correspond to a configuration that violates section 6.2 of RFC5214: =A0 > 6.2.=A0 ISATAP Interface Address Configuration >=A0 > =A0=A0Each ISATAP interface configures a set of locators consisting of = IPv4 >=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP >=A0=A0 interface's locator set MUST NOT span multiple sites. =A0 In particular, in scenarios A, B and C the IPv4 locator used for ISATAP is seen both within the enterprise as site #1 and within the global = Internet itself as site #2. If the ISATAP interface is to be used as an = enterprise- interior interface, it should therefore not accept IP-proto-41 packets coming from an IPv4 source outside of the enterprise nor source IP-proto-41 packets that are destined to an IPv4 node outside of the enterprise. This condition should be satisfied by having the site border routers implement IPv4 ingress filtering and ip-protocol-41 filtering as required in Section 10 of RFC5214. =A0 It is mentioned that attack C could also occur when the routers reside in the same site, where their addresses may be private. This would correspond to a case in which an attacker within the site attacks the site itself, which can easily be traced - especially when source address spoofing from a node within the site is prevented through proper ingress filtering. =A0 Fred fred.l.templin@boeing.com =A0 ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Monday, August 17, 2009 8:21 AM To: v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: Routing loop attacks using IPv6 tunnels =A0 Hi all, I would like to draw the attention of the list = to=A0some=A0research=A0results which my colleague and I at the National = EW Research=A0& Simulation=A0Center have recently published. The = research presents a=A0class of routing loop attacks that abuses 6to4, = ISATAP and Teredo. The=A0paper can be found at: = http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf =A0 Here is the abstract: IPv6 is the future network layer protocol for the Internet. Since it is = not compatible with its predecessor, some interoperability mechanisms = were designed. An important category of these mechanisms is automatic = tunnels, which enable IPv6 communication over an IPv4 network without = prior configuration. This category includes ISATAP, 6to4 and Teredo. We = present a novel class of attacks that exploit vulnerabilities in these = tunnels. These attacks take advantage of inconsistencies between a = tunnel's overlay IPv6 routing state and the native IPv6 routing state. = The attacks form routing loops which can be abused as a vehicle for = traffic amplification to facilitate DoS attacks. We exhibit five attacks = of this class. One of the presented attacks can DoS a Teredo server = using a single packet. The exploited vulnerabilities are embedded in the = design of the tunnels; hence any implementation of these tunnels may be = vulnerable. In particular, the attacks were tested against the ISATAP, = 6to4 and Teredo implementations of Windows Vista and Windows Server 2008 = R2.=20 =A0 I think the results of the research warrant some corrective action. If = this=A0indeed shall be the general sentiment of the list, I will be = happy write an appropriate I-D. The mitigation measures we suggested in = the paper are the best we could think of to completely eliminate the = problem. However they are far from perfect since=A0they would = require=A0tunnel implementations to be updated in case new types of = automatic tunnels are introduced. =A0 Your comments are welcome. =A0 Gabi =A0 From owner-v6ops@ops.ietf.org Wed Aug 19 08:28:05 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87713A6A82 for ; Wed, 19 Aug 2009 08:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 40BPvmr7NWDL for ; Wed, 19 Aug 2009 08:28:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E6CF3A68DF for ; Wed, 19 Aug 2009 08:28:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdn3a-000KFu-2W for v6ops-data0@psg.com; Wed, 19 Aug 2009 15:26:34 +0000 Received: from [194.29.32.54] (helo=dlpdemo.checkpoint.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdn3U-000KEt-D4 for v6ops@ops.ietf.org; Wed, 19 Aug 2009 15:26:31 +0000 Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2BF4529C008; Wed, 19 Aug 2009 18:26:49 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id CFA2629C004; Wed, 19 Aug 2009 18:26:48 +0300 (IDT) X-CheckPoint: {4A8C18D3-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n7JFQP3d008023; Wed, 19 Aug 2009 18:26:26 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 19 Aug 2009 18:26:26 +0300 From: Yaron Sheffer To: "Hemant Singh (shemant)" , "v6ops@ops.ietf.org" CC: "Wes Beebee (wbeebee)" Date: Wed, 19 Aug 2009 18:26:25 +0300 Subject: RE: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Thread-Topic: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Thread-Index: AcogR5sPMTp9vGcPRUiqGisolv/kKAAAZUogACRXw8AAAJ2YYAAA2UCg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B241@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B238@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0090_01CA20FA.8F6145B0" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0090_01CA20FA.8F6145B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, I found that document myself, but the document should clarify its = terminology, or at least have a terminology section pointing to that = other doc. But I'm worried about the practical implications. *Any* IPv4 CPE today = has some form of packet filtering, even if it's all mixed up with NAT. = If we now declare it "advanced" and move it to a separate RFC, we will = be signaling the industry that packet filtering on the CPE is "nice to = have". IMHO that would be a big mistake. Big enough to slow down ISP = adoption of IPv6. Thanks, Yaron > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com] > Sent: Wednesday, August 19, 2009 18:05 > To: Yaron Sheffer; v6ops@ops.ietf.org > Cc: Wes Beebee (wbeebee) > Subject: RE: New Version Notification for draft-ietf-v6ops-ipv6-cpe- > router-01 >=20 > Yaron, >=20 > This BIS document is part 2 of the IPv6 CPE Router Recommendations > document. The first document is at >=20 > http://www.ietf.org/id/draft-ietf-v6ops-ipv6-cpe-router-01.txt >=20 > Please see last paragraph in section 1 of the draft above for = explanation > of the DEV and MEDIUM terms. >=20 > This document does not try to define any new IPv6 security and instead > points to the IPv6 simple security document. The only reason packet > filtering has been defined as DEV is because it is described in more > detail in the simple security document but the simple security = document is > Work in Progress (not an RFC yet). In general I agree with you that > packet filtering is older than IPv6. Do appreciate one fact that = given > tunneled IPv6 data and new drafts in the area of changing IPv6 = standards > for firewall traversal has not agreed upon how to filter relevant IPv6 > data. That is where some more of DEV behavior gets into packet = filtering > for IPv6. >=20 > Hemant >=20 > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@checkpoint.com] > Sent: Wednesday, August 19, 2009 10:50 AM > To: Hemant Singh (shemant); v6ops@ops.ietf.org > Cc: Wes Beebee (wbeebee) > Subject: RE: New Version Notification for draft-ietf-v6ops-ipv6-cpe- > router-01 >=20 > Hi Hemant, >=20 > I took a quick look at the BIS document, and it is not self = explanatory. > What does "DEV" mean? What does "MEDIUM" mean? A terminology section = would > be appreciated. >=20 > Do we really consider packet filtering (a technology older than IPv6 = :-) > to be "under development"? How does this document relate to the = "simple > security" draft? >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf > > Of Hemant Singh (shemant) > > Sent: Wednesday, August 19, 2009 0:19 > > To: v6ops@ops.ietf.org > > Cc: Hemant Singh (shemant); Wes Beebee (wbeebee) > > Subject: FW: New Version Notification for draft-ietf-v6ops-ipv6-cpe- > > router-01 > > > > Folks, > > > > This is the last version of the IPv6 CPE Router Recommendations with = I > and > > Wes as authors. The next revision will include Ole Troan and Chris > Donley > > as co-authors. > > Since San Francisco IETF in Spring 2009, a decision was made to = split up > > the document into two. The second document has also been posted = today > as > > draft-wbeebee-v6ops-ipv6-cpe-router-bis-00.txt. > > > > Hemant > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Tuesday, August 18, 2009 5:05 PM > > To: Hemant Singh (shemant) > > Cc: Wes Beebee (wbeebee) > > Subject: New Version Notification for = draft-ietf-v6ops-ipv6-cpe-router- > 01 > > > > > > A new version of I-D, draft-ietf-v6ops-ipv6-cpe-router-01.txt has = been > > successfuly submitted by Hemant Singh and posted to the IETF = repository. > > > > Filename: draft-ietf-v6ops-ipv6-cpe-router > > Revision: 01 > > Title: IPv6 CPE Router Recommendations > > Creation_date: 2009-08-18 > > WG ID: v6ops > > Number_of_pages: 21 > > > > Abstract: > > This document recommends IPv6 behavior for Customer Premises > > Equipment (CPE) routers in Internet-enabled homes and small offices. > > The CPE Router may be a standalone device. The CPE Router may also > > be embedded in a device such as a cable modem, DSL modem, cellular > > phone, etc. This document describes the router portion of such a > > device. The purpose behind this document is to provide minimal > > functionality for interoperability and create consistency in the > > customer experience and satisfy customer expectations for the = device. > > Further, the document also provide some guidance for implementers to > > expedite availability of IPv6 CPE router products in the = marketplace. > > It is expected that standards bodies other than the IETF developing > > standards for specific products in this area (e.g. CableLabs > > eRouter, Broadband Forum, Home Gateway Initiative, etc.) may > > reference this work for basic functionality and provide value-added > > or linktype-specific customizations and enhancements which are = beyond > > the scope of this document. > > > > > > > > The IETF Secretariat. > > > > > > = =04=EF=BF=BDjy=EF=BF=BDu=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD$>=EF=BF=BD=EF= =BF=BD=EF=BF=BD:-jT=EF=BF=BDr=EF=BF=BD=EF=BF=BD!=EF=BF=BD=EF=BF=BD=EF=BF=BD= =1A > = I=C6=A7=EF=BF=BD=EF=BF=BD[=EF=BF=BD(^rC=EF=BF=BD{S=EF=BF=BD=D6=A5I=EF=BF=BD= .=EF=BF=BD+r=19=EF=BF=BD^=EF=BF=BD=EF=BF=BD ------=_NextPart_000_0090_01CA20FA.8F6145B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxOTE1MjYyNVowIwYJKoZIhvcNAQkEMRYEFOcm9v3QHNNv OC2X4P8vIjQIdJgbMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA JriOjrJbJNY0aoWbeIa9JRbSwg/M0QchTxSx8X8SU4gOoLrBF3yl4q0X9GK00dKJLbPwBhtK94aa 2G7x2Gx84kjURtsvqKK92/klLBlv+bFjKPXeyU/ktmk/Cy8rpGz9xlB7QKw9OlTV+CWxN3HheblF mxKVhrELs36/Fs87I8be0BDD3Y/tuAON9A9QX9BOzqnLiQ8+bPdvneLZydo2Q1xRDkQ1LEsfJE1j etxh0Zm//TJivqR3LXxNCInKNpGa0iSeEEpBA2cWNW6vSG5516XK9jEYMsJWKpL42MGHk5Bmk07e 0tNTOrAh/02f3CMT2+sqWGL/rp3ac7AbOifLpAAAAAAAAA== ------=_NextPart_000_0090_01CA20FA.8F6145B0-- From owner-v6ops@ops.ietf.org Wed Aug 19 09:22:50 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94CB3A6D3F for ; Wed, 19 Aug 2009 09:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 24bJXdWJdj8d for ; Wed, 19 Aug 2009 09:22:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7340E3A6A3C for ; Wed, 19 Aug 2009 09:22:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdnqx-0002KT-Cp for v6ops-data0@psg.com; Wed, 19 Aug 2009 16:17:35 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdnqn-0002JM-Ms for v6ops@ops.ietf.org; Wed, 19 Aug 2009 16:17:29 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANPCi0qrR7PE/2dsb2JhbACZYqQEiC+RVQWEGoFT X-IronPort-AV: E=Sophos;i="4.43,409,1246838400"; d="scan'208";a="90684024" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Aug 2009 16:17:26 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7JGHOLO023436; Wed, 19 Aug 2009 09:17:24 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n7JGHOwH001193; Wed, 19 Aug 2009 16:17:24 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.3959); Wed, 19 Aug 2009 12:17:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Date: Wed, 19 Aug 2009 12:17:23 -0400 Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B241@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Thread-Index: AcogR5sPMTp9vGcPRUiqGisolv/kKAAAZUogACRXw8AAAJ2YYAAA2UCgAAHxsDA= References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B238@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B241@il-ex01.ad.checkpoint.com> From: "Hemant Singh (shemant)" To: "Yaron Sheffer" , Cc: "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 19 Aug 2009 16:17:24.0309 (UTC) FILETIME=[89652850:01CA20E8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7940; t=1250698644; x=1251562644; c=relaxed/simple; s=sjdkim4002; 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=20New=20Version=20Notification=20for=20dr aft-ietf-v6ops-ipv6-cpe-router-01=20 |Sender:=20; bh=ZSTlCm+Ta8x/lQVqw5TQn6AimuLru8gJUB00xtkeUL8=; b=DMRKcpE4kIB5xYyfdiNX44K/Nkl+mIz+UQS4a8XriA1v3onaV9LTf55CIl W4gsitZu54+Lyev4PUo1u+Wb+9m2XMKrNphuUrvh/CFE/EaIEz0SXpFzrCmB wYgV5ebIvq; Authentication-Results: sj-dkim-4; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: WWFyb24sDQoNClN1cmUsIHdlIGNhbiBtYWtlIHRoZSB0ZXJtaW5vbG9neSBhdmFpbGFibGUgaW4g dGhlIGJpcyB2ZXJzaW9uIHRvby4gIFRoZXJlIGlzIG5vIFJGQyBvbiBwYWNrZXQgZmlsdGVyaW5n IG5vciBhbnkgd2lkZWx5IGRlcGxveWVkIElQdjYgQ1BFIFJvdXRlciB0aGF0IHBlcmZvcm1zIHBh Y2tldCBmaWx0ZXJpbmcuICBUaGF0IGlzIHdoeSB0aGlzIHRvcGljIGlzIHVuZGVyIERFVi4NCg0K SGVtYW50DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBZYXJvbiBTaGVmZmVy IFttYWlsdG86eWFyb25mQGNoZWNrcG9pbnQuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0 IDE5LCAyMDA5IDExOjI2IEFNDQpUbzogSGVtYW50IFNpbmdoIChzaGVtYW50KTsgdjZvcHNAb3Bz LmlldGYub3JnDQpDYzogV2VzIEJlZWJlZSAod2JlZWJlZSkNClN1YmplY3Q6IFJFOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1jcGUtcm91dGVyLTAx IA0KDQpZZXMsIEkgZm91bmQgdGhhdCBkb2N1bWVudCBteXNlbGYsIGJ1dCB0aGUgZG9jdW1lbnQg c2hvdWxkIGNsYXJpZnkgaXRzIHRlcm1pbm9sb2d5LCBvciBhdCBsZWFzdCBoYXZlIGEgdGVybWlu b2xvZ3kgc2VjdGlvbiBwb2ludGluZyB0byB0aGF0IG90aGVyIGRvYy4NCg0KQnV0IEknbSB3b3Jy aWVkIGFib3V0IHRoZSBwcmFjdGljYWwgaW1wbGljYXRpb25zLiAqQW55KiBJUHY0IENQRSB0b2Rh eSBoYXMgc29tZSBmb3JtIG9mIHBhY2tldCBmaWx0ZXJpbmcsIGV2ZW4gaWYgaXQncyBhbGwgbWl4 ZWQgdXAgd2l0aCBOQVQuIElmIHdlIG5vdyBkZWNsYXJlIGl0ICJhZHZhbmNlZCIgYW5kIG1vdmUg aXQgdG8gYSBzZXBhcmF0ZSBSRkMsIHdlIHdpbGwgYmUgc2lnbmFsaW5nIHRoZSBpbmR1c3RyeSB0 aGF0IHBhY2tldCBmaWx0ZXJpbmcgb24gdGhlIENQRSBpcyAibmljZSB0byBoYXZlIi4gSU1ITyB0 aGF0IHdvdWxkIGJlIGEgYmlnIG1pc3Rha2UuIEJpZyBlbm91Z2ggdG8gc2xvdyBkb3duIElTUCBh ZG9wdGlvbiBvZiBJUHY2Lg0KDQpUaGFua3MsDQoJWWFyb24NCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpIFttYWlsdG86c2hlbWFu dEBjaXNjby5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE5LCAyMDA5IDE4OjA1DQo+ IFRvOiBZYXJvbiBTaGVmZmVyOyB2Nm9wc0BvcHMuaWV0Zi5vcmcNCj4gQ2M6IFdlcyBCZWViZWUg KHdiZWViZWUpDQo+IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWlldGYtdjZvcHMtaXB2Ni1jcGUtDQo+IHJvdXRlci0wMQ0KPiANCj4gWWFyb24sDQo+IA0K PiBUaGlzIEJJUyBkb2N1bWVudCBpcyBwYXJ0IDIgb2YgdGhlIElQdjYgQ1BFIFJvdXRlciBSZWNv bW1lbmRhdGlvbnMNCj4gZG9jdW1lbnQuICBUaGUgZmlyc3QgZG9jdW1lbnQgaXMgYXQNCj4gDQo+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWNwZS1yb3V0ZXIt MDEudHh0DQo+IA0KPiBQbGVhc2Ugc2VlIGxhc3QgcGFyYWdyYXBoIGluIHNlY3Rpb24gMSBvZiB0 aGUgZHJhZnQgYWJvdmUgZm9yIGV4cGxhbmF0aW9uDQo+IG9mIHRoZSBERVYgYW5kIE1FRElVTSB0 ZXJtcy4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgdHJ5IHRvIGRlZmluZSBhbnkgbmV3 IElQdjYgc2VjdXJpdHkgYW5kIGluc3RlYWQNCj4gcG9pbnRzIHRvIHRoZSBJUHY2IHNpbXBsZSBz ZWN1cml0eSBkb2N1bWVudC4gICBUaGUgb25seSByZWFzb24gcGFja2V0DQo+IGZpbHRlcmluZyBo YXMgYmVlbiBkZWZpbmVkIGFzIERFViBpcyBiZWNhdXNlIGl0IGlzIGRlc2NyaWJlZCBpbiBtb3Jl DQo+IGRldGFpbCBpbiB0aGUgc2ltcGxlIHNlY3VyaXR5IGRvY3VtZW50IGJ1dCB0aGUgc2ltcGxl IHNlY3VyaXR5IGRvY3VtZW50IGlzDQo+IFdvcmsgaW4gUHJvZ3Jlc3MgKG5vdCBhbiBSRkMgeWV0 KS4gIEluIGdlbmVyYWwgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0DQo+IHBhY2tldCBmaWx0ZXJpbmcg aXMgb2xkZXIgdGhhbiBJUHY2LiAgRG8gYXBwcmVjaWF0ZSBvbmUgZmFjdCB0aGF0IGdpdmVuDQo+ IHR1bm5lbGVkIElQdjYgZGF0YSBhbmQgbmV3IGRyYWZ0cyBpbiB0aGUgYXJlYSBvZiBjaGFuZ2lu ZyBJUHY2IHN0YW5kYXJkcw0KPiBmb3IgZmlyZXdhbGwgdHJhdmVyc2FsIGhhcyBub3QgYWdyZWVk IHVwb24gaG93IHRvIGZpbHRlciByZWxldmFudCBJUHY2DQo+IGRhdGEuICBUaGF0IGlzIHdoZXJl IHNvbWUgbW9yZSBvZiBERVYgYmVoYXZpb3IgZ2V0cyBpbnRvIHBhY2tldCBmaWx0ZXJpbmcNCj4g Zm9yIElQdjYuDQo+IA0KPiBIZW1hbnQNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFlhcm9uIFNoZWZmZXIgW21haWx0bzp5YXJvbmZAY2hlY2twb2ludC5jb21dDQo+ IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE5LCAyMDA5IDEwOjUwIEFNDQo+IFRvOiBIZW1hbnQg U2luZ2ggKHNoZW1hbnQpOyB2Nm9wc0BvcHMuaWV0Zi5vcmcNCj4gQ2M6IFdlcyBCZWViZWUgKHdi ZWViZWUpDQo+IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlldGYtdjZvcHMtaXB2Ni1jcGUtDQo+IHJvdXRlci0wMQ0KPiANCj4gSGkgSGVtYW50LA0KPiAN Cj4gSSB0b29rIGEgcXVpY2sgbG9vayBhdCB0aGUgQklTIGRvY3VtZW50LCBhbmQgaXQgaXMgbm90 IHNlbGYgZXhwbGFuYXRvcnkuDQo+IFdoYXQgZG9lcyAiREVWIiBtZWFuPyBXaGF0IGRvZXMgIk1F RElVTSIgbWVhbj8gQSB0ZXJtaW5vbG9neSBzZWN0aW9uIHdvdWxkDQo+IGJlIGFwcHJlY2lhdGVk Lg0KPiANCj4gRG8gd2UgcmVhbGx5IGNvbnNpZGVyIHBhY2tldCBmaWx0ZXJpbmcgKGEgdGVjaG5v bG9neSBvbGRlciB0aGFuIElQdjYgOi0pDQo+IHRvIGJlICJ1bmRlciBkZXZlbG9wbWVudCI/IEhv dyBkb2VzIHRoaXMgZG9jdW1lbnQgcmVsYXRlIHRvIHRoZSAic2ltcGxlDQo+IHNlY3VyaXR5IiBk cmFmdD8NCj4gDQo+IFRoYW5rcywNCj4gCVlhcm9uDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogb3duZXItdjZvcHNAb3BzLmlldGYub3JnIFttYWlsdG86b3du ZXItdjZvcHNAb3BzLmlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPiBPZiBIZW1hbnQgU2luZ2gg KHNoZW1hbnQpDQo+ID4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTksIDIwMDkgMDoxOQ0KPiA+ IFRvOiB2Nm9wc0BvcHMuaWV0Zi5vcmcNCj4gPiBDYzogSGVtYW50IFNpbmdoIChzaGVtYW50KTsg V2VzIEJlZWJlZSAod2JlZWJlZSkNCj4gPiBTdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLXY2b3BzLWlwdjYtY3BlLQ0KPiA+IHJvdXRlci0wMQ0KPiA+ DQo+ID4gRm9sa3MsDQo+ID4NCj4gPiBUaGlzIGlzIHRoZSBsYXN0IHZlcnNpb24gb2YgdGhlIElQ djYgQ1BFIFJvdXRlciBSZWNvbW1lbmRhdGlvbnMgd2l0aCBJDQo+IGFuZA0KPiA+IFdlcyBhcyBh dXRob3JzLiAgVGhlIG5leHQgcmV2aXNpb24gd2lsbCBpbmNsdWRlIE9sZSBUcm9hbiBhbmQgQ2hy aXMNCj4gRG9ubGV5DQo+ID4gYXMgY28tYXV0aG9ycy4NCj4gPiBTaW5jZSBTYW4gRnJhbmNpc2Nv IElFVEYgaW4gU3ByaW5nIDIwMDksIGEgZGVjaXNpb24gd2FzIG1hZGUgdG8gc3BsaXQgdXANCj4g PiB0aGUgZG9jdW1lbnQgaW50byB0d28uICBUaGUgc2Vjb25kIGRvY3VtZW50IGhhcyBhbHNvIGJl ZW4gcG9zdGVkIHRvZGF5DQo+IGFzDQo+ID4gZHJhZnQtd2JlZWJlZS12Nm9wcy1pcHY2LWNwZS1y b3V0ZXItYmlzLTAwLnR4dC4NCj4gPg0KPiA+IEhlbWFudA0KPiA+DQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wgW21haWx0 bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddDQo+ID4gU2VudDogVHVlc2RheSwgQXVndXN0IDE4LCAy MDA5IDU6MDUgUE0NCj4gPiBUbzogSGVtYW50IFNpbmdoIChzaGVtYW50KQ0KPiA+IENjOiBXZXMg QmVlYmVlICh3YmVlYmVlKQ0KPiA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWNwZS1yb3V0ZXItDQo+IDAxDQo+ID4NCj4gPg0KPiA+ IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXY2b3BzLWlwdjYtY3BlLXJvdXRlci0w MS50eHQgaGFzIGJlZW4NCj4gPiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgSGVtYW50IFNpbmdo IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IEZpbGVuYW1lOgkg ZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWNwZS1yb3V0ZXINCj4gPiBSZXZpc2lvbjoJIDAxDQo+ID4g VGl0bGU6CQkgSVB2NiBDUEUgUm91dGVyIFJlY29tbWVuZGF0aW9ucw0KPiA+IENyZWF0aW9uX2Rh dGU6CSAyMDA5LTA4LTE4DQo+ID4gV0cgSUQ6CQkgdjZvcHMNCj4gPiBOdW1iZXJfb2ZfcGFnZXM6 IDIxDQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiBUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMgSVB2 NiBiZWhhdmlvciBmb3IgQ3VzdG9tZXIgUHJlbWlzZXMNCj4gPiBFcXVpcG1lbnQgKENQRSkgcm91 dGVycyBpbiBJbnRlcm5ldC1lbmFibGVkIGhvbWVzIGFuZCBzbWFsbCBvZmZpY2VzLg0KPiA+IFRo ZSBDUEUgUm91dGVyIG1heSBiZSBhIHN0YW5kYWxvbmUgZGV2aWNlLiAgVGhlIENQRSBSb3V0ZXIg bWF5IGFsc28NCj4gPiBiZSBlbWJlZGRlZCBpbiBhIGRldmljZSBzdWNoIGFzIGEgY2FibGUgbW9k ZW0sIERTTCBtb2RlbSwgY2VsbHVsYXINCj4gPiBwaG9uZSwgZXRjLiAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgdGhlIHJvdXRlciBwb3J0aW9uIG9mIHN1Y2ggYQ0KPiA+IGRldmljZS4gIFRoZSBw dXJwb3NlIGJlaGluZCB0aGlzIGRvY3VtZW50IGlzIHRvIHByb3ZpZGUgbWluaW1hbA0KPiA+IGZ1 bmN0aW9uYWxpdHkgZm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIGNyZWF0ZSBjb25zaXN0ZW5jeSBp biB0aGUNCj4gPiBjdXN0b21lciBleHBlcmllbmNlIGFuZCBzYXRpc2Z5IGN1c3RvbWVyIGV4cGVj dGF0aW9ucyBmb3IgdGhlIGRldmljZS4NCj4gPiBGdXJ0aGVyLCB0aGUgZG9jdW1lbnQgYWxzbyBw cm92aWRlIHNvbWUgZ3VpZGFuY2UgZm9yIGltcGxlbWVudGVycyB0bw0KPiA+IGV4cGVkaXRlIGF2 YWlsYWJpbGl0eSBvZiBJUHY2IENQRSByb3V0ZXIgcHJvZHVjdHMgaW4gdGhlIG1hcmtldHBsYWNl Lg0KPiA+IEl0IGlzIGV4cGVjdGVkIHRoYXQgc3RhbmRhcmRzIGJvZGllcyBvdGhlciB0aGFuIHRo ZSBJRVRGIGRldmVsb3BpbmcNCj4gPiBzdGFuZGFyZHMgZm9yIHNwZWNpZmljIHByb2R1Y3RzIGlu IHRoaXMgYXJlYSAoZS5nLiAgQ2FibGVMYWJzDQo+ID4gZVJvdXRlciwgQnJvYWRiYW5kIEZvcnVt LCBIb21lIEdhdGV3YXkgSW5pdGlhdGl2ZSwgZXRjLikgbWF5DQo+ID4gcmVmZXJlbmNlIHRoaXMg d29yayBmb3IgYmFzaWMgZnVuY3Rpb25hbGl0eSBhbmQgcHJvdmlkZSB2YWx1ZS1hZGRlZA0KPiA+ IG9yIGxpbmt0eXBlLXNwZWNpZmljIGN1c3RvbWl6YXRpb25zIGFuZCBlbmhhbmNlbWVudHMgd2hp Y2ggYXJlIGJleW9uZA0KPiA+IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID4N Cj4gPg0KPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KPiA+DQo+ID4NCj4gPiAE77+9annvv711 77+977+977+977+9JD7vv73vv73vv706LWpU77+9cu+/ve+/vSHvv73vv73vv70aDQo+IEnGp++/ ve+/vVvvv70oXnJD77+9e1Pvv73WpUnvv70u77+9K3IZ77+9Xu+/ve+/vQ0K From owner-v6ops@ops.ietf.org Wed Aug 19 10:06:58 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE153A68E8 for ; Wed, 19 Aug 2009 10:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.293 X-Spam-Level: X-Spam-Status: No, score=-4.293 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 g9tNIKeB+PGQ for ; Wed, 19 Aug 2009 10:06:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 590633A68A6 for ; Wed, 19 Aug 2009 10:06:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdoa2-0009Gi-Dr for v6ops-data0@psg.com; Wed, 19 Aug 2009 17:04:10 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdoZy-0009G2-Kt for v6ops@ops.ietf.org; Wed, 19 Aug 2009 17:04:08 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF/Ni0pAZnme/2dsb2JhbAC9V4gvkUkFhBqBUw X-IronPort-AV: E=Sophos;i="4.43,409,1246838400"; d="scan'208";a="54659376" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Aug 2009 17:04:05 +0000 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 n7JH45ci019181; Wed, 19 Aug 2009 13:04:05 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7JH458l013960; Wed, 19 Aug 2009 17:04:05 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 13:04:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D Action:draft-wbeebee-v6ops-ipv6-cpe-router-bis-00.txt Date: Wed, 19 Aug 2009 13:04:04 -0400 Message-ID: In-Reply-To: <4A8B7CC9.6050404@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-wbeebee-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcoghN3rEw7wdPDwSsWlJxYrcXEpwQAafyug References: <20090818213001.75ABA3A6BEE@core3.amsl.com> <4A8B7CC9.6050404@gmail.com> From: "Wes Beebee (wbeebee)" To: "Brian E Carpenter" , "IPv6 Operations" X-OriginalArrivalTime: 19 Aug 2009 17:04:05.0550 (UTC) FILETIME=[0F109CE0:01CA20EF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1838; t=1250701445; x=1251565445; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20I-D=20Action=3Adraft-wbeebee-v6ops-ipv6 -cpe-router-bis-00.txt |Sender:=20 |To:=20=22Brian=20E=20Carpenter=22=20,=0A=20=20=20=20=20=20=20=20=22IPv6=20Operations=22=2 0; bh=VDc72367XMnr8M91bhLAYk9hlrycuE2kOx0l+Lpy/nI=; b=PUVo/vxkkTfkQgMX8/xuDtdJn4gGwiniXGeZkXzwb2J5o/4H0Bw4zpuqCf 5V4MdR9OcmZxNuyOZD4DKTIo03NO1JYM01Xjh0Y0kUzYYAsFA+GGgylJeoA0 BeS7t+RCEh; Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian - We agree with your new text and will include it in the next version. - Hemant & Wes -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, August 19, 2009 12:17 AM To: IPv6 Operations Subject: Re: I-D Action:draft-wbeebee-v6ops-ipv6-cpe-router-bis-00.txt > 4.3. 6to4 Automated Tunneling (MEDIUM)/Dual-Stack Lite (DEV)/ISATAP > (MEDIUM) >=20 > If the IPv4 address assigned to the WAN interface of the CPE Router > is a non-[RFC1918] IPv4 address, and the CPE Router fails to acquire > an IPv6 address before WAN_IP_ACQUIRE_TIMEOUT seconds after acquiring > the IPv4 address, then the 6to4 tunneling protocol [RFC3056] SHOULD > be enabled automatically, allowing tunneling of IPv6 packets over > IPv4 without requiring user configuration. If an anycast 6to4 server > cannot be located, the CPE Router MAY initiate ISATAP [RFC4214] to > establish IPv6 connectivity over the IPv4 network. =20 This is slightly wrong IMHO. Firstly we should be clear that the CPE is to behave like a 6to4 router as defined in 3056. Secondly, 3056 does not define the anycast method; in fact it assumes that a unicast address is configured for the nearest 6to4 relay (*not* "server"). So, let me rephrase this: ... then 6to4 router behavior [RFC3056] SHOULD be enabled automatically, allowing tunneling of IPv6 packets over IPv4 without requiring user configuration. Note that [RFC3056] relies on configuration of an IPv4 address for a 6to4 relay router. The CPE SHOULD allow this, but also SHOULD by default use the anycast method defined in [RFC3068]. If a 6to4 relay router cannot be contacted, the CPE router MAY initiate ISATAP ... Brian From owner-v6ops@ops.ietf.org Wed Aug 19 16:03:12 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0B93A6AA5 for ; Wed, 19 Aug 2009 16:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.542 X-Spam-Level: X-Spam-Status: No, score=-104.542 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 TvKY-qVFuVxH for ; Wed, 19 Aug 2009 16:03:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D1CC28C155 for ; Wed, 19 Aug 2009 16:03:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdu6O-000IrW-CQ for v6ops-data0@psg.com; Wed, 19 Aug 2009 22:57:56 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mdu6K-000Ir3-Tk for v6ops@ops.ietf.org; Wed, 19 Aug 2009 22:57:54 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id CA0DA72BD577; Wed, 19 Aug 2009 15:57:51 -0700 (PDT) X-AuditID: 11807130-b7bdfae000004bc9-7e-4a8c836eba6c Received: from il0602a-dhcp117.apple.com (il0602a-dhcp117.apple.com [17.206.23.245]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 89.60.19401.F638C8A4; Wed, 19 Aug 2009 15:57:51 -0700 (PDT) Subject: Re: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Mime-Version: 1.0 (Apple Message framework v1074) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: james woodyatt In-Reply-To: Date: Wed, 19 Aug 2009 15:57:50 -0700 Cc: Yaron Sheffer , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Content-Transfer-Encoding: 7bit Message-Id: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B238@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B241@il-ex01.ad.checkpoint.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1074) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 19, 2009, at 09:17, Hemant Singh (shemant) wrote: > > ...nor any widely deployed IPv6 CPE Router that performs packet > filtering. I would humbly disagree with this statement. -- james woodyatt member of technical staff, communications engineering From prepaymente7@cpe-66-108-51-116.nyc.res.rr.com Wed Aug 19 19:41:58 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0C63A6C51 for ; Wed, 19 Aug 2009 19:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.684 X-Spam-Level: X-Spam-Status: No, score=-71.684 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 kswwPmxGRE36 for ; Wed, 19 Aug 2009 19:41:57 -0700 (PDT) Received: from cpe-66-108-51-116.nyc.res.rr.com (cpe-66-108-51-116.nyc.res.rr.com [66.108.51.116]) by core3.amsl.com (Postfix) with ESMTP id C32243A6D0E for ; Wed, 19 Aug 2009 19:41:56 -0700 (PDT) Received: from 66.108.51.116 by mail.adhost.com; Wed, 19 Aug 2009 20:42:01 -0600 Date: Wed, 19 Aug 2009 20:42:01 -0600 From: "Caryn V. Troiano" X-Mailer: The Bat! (v2.00.2) Educational Reply-To: prepaymente7@cpe-66-108-51-116.nyc.res.rr.com X-Priority: 3 (Normal) Message-ID: <098863898.12734734605474@cpe-66-108-51-116.nyc.res.rr.com> To: v6ops-archive@megatron.ietf.org Subject: Now get a promotion. MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Now you are getting a 100% verifiable degree in just 4-5 weeks, with the help of your work experience. You can get Bachelors, Masters or Doctorate degree in a few weeks time. Give us a call now. 1 305 460 5721 Drop us your msg, with your full name and contact number so we can call you back. From jabsju02@irismaritime.com Thu Aug 20 02:33:10 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8180728C0EF for ; Thu, 20 Aug 2009 02:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.194 X-Spam-Level: **** X-Spam-Status: No, score=4.194 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeOYqHfiL54j for ; Thu, 20 Aug 2009 02:33:09 -0700 (PDT) Received: from 97-114-122-226.spkn.qwest.net (97-114-122-226.spkn.qwest.net [97.114.122.226]) by core3.amsl.com (Postfix) with ESMTP id 70E5A28C116 for ; Thu, 20 Aug 2009 02:33:07 -0700 (PDT) Received: from 97.114.122.226 by mail.irismaritime.com with smtp N9A4BO291; Thu, 20 Aug 2009 02:30:36 -0800 Message-ID: <000d01ca2178$dfd48740$6400a8c0@jabsju02> From: Virginia Odonnell To: Subject: I feel invincible, give a test run at this asap!! Date: Thu, 20 Aug 2009 02:30:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA2178.DFD48740" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA2178.DFD48740 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Acai berry will allow you to lose your undesired wieght.   http://www.violencizers.biz/?iupvqdrlje =A0 Very famous people are using this to look great, I got on board for free!! =A0 We invite you =A0 =A0 best ragards Odonnell ------=_NextPart_000_0007_01CA2178.DFD48740 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Acai berry will allow you to lose your un= desired wieght.
 
http://www.violencizers.bi= z/?iupvqdrlje
=A0
Very famous people are using this to look= great, I got on board for free!!
=A0
=A0
=A0
best ragards Odonnell
------=_NextPart_000_0007_01CA2178.DFD48740-- From owner-v6ops@ops.ietf.org Thu Aug 20 02:40:17 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01563A6FDF for ; Thu, 20 Aug 2009 02:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 V4Ef8GMOs1UW for ; Thu, 20 Aug 2009 02:40:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A5FA3A6FB4 for ; Thu, 20 Aug 2009 02:40:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me42y-0004cf-Fs for v6ops-data0@psg.com; Thu, 20 Aug 2009 09:35:04 +0000 Received: from [80.12.242.100] (helo=smtp28.orange.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Me42q-0004ag-5F for v6ops@ops.ietf.org; Thu, 20 Aug 2009 09:34:59 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2806.orange.fr (SMTP Server) with ESMTP id 990C57000082; Thu, 20 Aug 2009 11:34:54 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2806.orange.fr (SMTP Server) with ESMTP id 8CAB5700008D; Thu, 20 Aug 2009 11:34:54 +0200 (CEST) Received: from [193.248.114.206] (Mix-Lille-207-3-206.w193-248.abo.wanadoo.fr [193.248.114.206]) by mwinf2806.orange.fr (SMTP Server) with ESMTP id 201507000082; Thu, 20 Aug 2009 11:34:50 +0200 (CEST) X-ME-UUID: 20090820093451131.201507000082@mwinf2806.orange.fr In-Reply-To: <808598.58470.qm@web45510.mail.sp1.yahoo.com> References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> <808598.58470.qm@web45510.mail.sp1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: v6ops , 6man 6man , secdir@ietf.org, Mark Townsley Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case Date: Thu, 20 Aug 2009 11:34:49 +0200 To: Gabi Nakibly X-Mailer: Apple Mail (2.753.1) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: gabi, Thanks for your quick answer. Further remarks in line. Le 19 ao=FBt 09 =E0 12:12, Gabi Nakibly a =E9crit : > Remi, > See my comments inline (). > Gabi > > From: R=E9mi Despr=E9s > To: Gabi Nakibly > Cc: v6ops ; 6man 6man ; =20 > secdir@ietf.org; Mark Townsley > Sent: Tuesday, August 18, 2009 8:00:42 PM > Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case > > Hi Gabi, > > First, thanks to you and your colleagues for this research, and for =20= > the clear presentation of its results. > In my understanding, your contribution is important for transition =20 > solutions to be carefully selected, and where needed improved. > > This mail is to complement the analysis with what applies to 6rd. > > For those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is =20 > an automatic tunnel mechanism in actual use for IPv6 across IPv4 =20 > clouds. > With it, service providers can offer native IPv6 to their customers =20= > while using for this their existing IPv4 infrastructures. > Publication of the RFC that describes it, RFC 5569, has been =20 > delayed since May for a reason related to intellectual property =20 > rights applicable to independent submissions. > But the draft on which 6rd is based is still available, and a new =20 > draft to extend its applicability is also available: > - tools.ietf.org/html/draft-despres-6rd-03 > - tools.ietf.org/html/draft-townsley-ipv6-6rd-01 > > I must admit that this is the first time I read the spec of 6rd so =20 > forgive me if I miss something. > > > (1) Case of ISPs that operate 6rd relays and no 6to4 relays (and =20 > neither Teredo relays nor ISP-infrastructure NATs) > > In its sec. 3, draft-despres-6rd-03 says: > <<< > The IPv4 anycast address of 6rd relays may be chosen =20 > independently by > each ISP. The only constraint is that routes toward the ISP that =20= > are > advertised must not include this address. > >>> > In view of your study and in my understanding, it should be =20 > completed with: > "Also, the ISP must not forward toward the global IPv4 global =20 > Internet packets having this address as source." > > With this, an ISP that operates 6rd relays but operates neither =20 > 6to4 relays nor Teredo relays nor NATs is immune to the routing =20 > loop attack because: > - An IPv6 packet forwarded to the IPv6 Internet by a 6rd relay =20 > cannot come back to an IPv4 interface of a 6rd relay of the same =20 > ISP: there is no IPv4 route back to the ISP for its 6rd anycast =20 > address. > - An IPv6 packet received from the IPv6 Internet by a 6rd relay =20 > cannot be sent back to the IPv4 global Internet: the source address =20= > of its IPv4 encapsulating packet is the 6rd anycast address, which =20 > prevents it from reaching the IPv4 global Internet. > > Note that, if interfaces of the ISP to the IPv4 global Internet are =20= > already subject to ingress filtering (packets received by the =20 > global Internet are discarded if there is no reverse path available =20= > for them), the added sentence is not necessary. It is just just a =20 > double precaution for cases where such ingress filtering doesn't =20 > apply. > > I agree with you that above check will work. However, I might =20 > choose another way here: the relay must make the following two checks: > 1) When an IPv6 packet is received from the IPv6 Internet the 6rd =20 > relay must ensure before encapsulation that the intended IPv4 =20 > destination address belongs to one of the ISP's clients (I assume =20 > it can make this check easily). This way no IPv6 packet received =20 > from the IPv6 Internet will be relayed to a 6to4 relay (and then =20 > back to the 6rd relay through the IPv6 Internet). The problem is that this check is not easy "in general" because ISPs =20 typically have their IPv4 prefixes allocated one by one as they =20 increase the number of their clients. > 2) When an encapsulated packet is received from the IPv4 network =20 > side the 6rd relay must check that the IPv6 destination does not =20 > include its own IPv4 address. For example the IPv6 destination =20 > address must not be: 2002:::/48. This =20 > will prevent the packet from ever reaching back the 6rd relay =20 > through its IPv4 interface The problem is that to be general, and as you noted, this test =20 depends on a knowledge of all formats used to embed IPv4 addresses in =20= IPv6 addresses. When a new format is introduced, a security weakness =20 therefore holds until all relays are upgraded to support it. Besides, and more important, some formats may use _ISP dependent =20 prefixes_ (and 6rd is already in this case!). These formats cannot be =20= recognized by a constant code. This being noted, I agree that, to extend applicability of 6rd relays =20= to cases where ingress filtering doesn't apply, and to deal more =20 simply with the case of 6rd ISPs that also operate 6to4 relays, 6rd =20 relays SHOULD do as you propose: *In 6rd relays, packets received on the IPv4 side should be discarded =20= if their IPv6 destinations are 6to4 addresses containing the ISP 6rd =20 anycast address.* > > This way all the checks are done only at the 6rd relay and not in =20 > other IPv4 border routers of the ISP which should not be aware of =20 > the 6rd deployment. Note that IPv4 border routers of the ISP need not to be aware of the =20 6rd in particular. They only have to make sure that ingress filtering "in general" =20 applies to packets sent toward the global Internet. (If their downstream neighbors do ingress filtering as they should, =20 these border routers have nothing specific to do. In cases where this =20= isn't sure though, they should better prevent source address spoofing =20= by filtering themselves source addresses for which they have no =20 reverse path.) > > > > (2) Case of ISPs that operate 6rd relays AND 6to4 relays (but =20 > neither Teredo relays nor ISP-infrastructure NATs) > > In its sec. 5 on security, draft-despres-6rd-03 says: > <<< > o RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd > address that matches the IPv4 source. The IPv6 destination must > not start with the ISP 6rd prefix. > ... > o RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a =20= > 6rd > address of the ISP. The IPv4 destination must not be multicast, > i.e. must not start with 224/3... > >>> > > In view of your study and in my understanding, it MUST be completed =20= > with: > - after the first quoted paragraph: > "Furthermore, if the ISP also operates 6to4 relays that advertise =20 > on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source =20= > must be neither the 6to4 anycast address 192.88.99.0 nor any of its =20= > equivalent IPv4 unicast addresses." > - after the second quoted paragraph: > "Furthermore, if the ISP also operates 6to4 relays that advertise =20 > on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 =20 > destination derived from the IPv6 destination must be neither the =20 > IPv4 anycast address 192.88.99.0 nor any of its equivalent IPv4 =20 > unicast addresses." > > Actually, I believe that the precautions I suggested above will =20 > work here also instead of those checks. Won't they? As explained above, it would be 100% safe only if all embedded IPv4 =20 addresses were guaranteed to be recognized, which is not the case. > In general, I think that checks performed on the destination =20 > address (IPv4 or IPv6) should be more robust than checks on a =20 > source address. In my understanding, not always. Each scenario has to be studied for what it is. > > > With this, an ISP that operates both 6rd and 6to4 relays is also =20 > immune to the routing-loop attack because: > - an IPv6 packet forwarded to the global Internet by 6rd relays can =20= > come back to the ISP IPv4 network via one of the 6to4 relays of the =20= > ISP BUT cannot be accepted again by a 6rd relay: its IPv4 source =20 > address is then one of a 6to4 relay, which, with the first added =20 > sentence, prevents it from being accepted by the 6rd relay. > - an IPv6 packet received from the IPv6 Internet by a 6rd relay =20 > cannot be sent back to the IPv4 global Internet via one of the 6to4 =20= > relays: the IPv4 address derived from its IPv6 destination would =20 > have for this to be one of a 6to4 relays, which, with the second =20 > added sentence, prevents it from being forwarded by the 6rd relay. > > Note: RFC 3068, where the 6to4 anycast address is introduced, says =20 > that "each 6to4 relay router that advertise the 6to4 anycast prefix =20= > MUST also provide an equivalent IPv4 unicast address". Whether this =20= > is really important in practice is IMHO unclear. On the other hand, =20= > if this MUST is dispensed with, the above security precaution can =20 > be implemented in 6rd relays without a need to handle a variable =20 > number of addresses, and to administratively configure them (with =20 > the associated risks of human errors). > > > If you do the check on the destination address you can avoid this =20 > administrative configuration altogether. Agreed for packets forwarded to the IPv6 side (see above). Now, for packets from the IPv6 Internet, rather than checking that =20 the embedded IPv4 destination has one of the ISP allocated prefixes, =20 there is a better check I hadn't seen before sending the previous e-=20 mail: *In 6rd relays, packets received on the IPv6 side should be discarded =20= if their source addresses are 6to4 addresses containing the ISP 6rd =20 anycast address.* The above administrative configuration is thus unnecessary, and the =20 6rd relay cannot participate in a routing loop attack even if its ISP =20= also operates 6to4 relays. NOTE: As a matter of fact, a source address check can also be used to =20= improve the Mitigation Measures you proposed for 6to4, ISATAP and =20 Teredo relays: *In your three forwarding conditions, it would be sufficient to add =20 "or source" after each occurrence of "destination".* Thus, each of these relays becomes protected against rooting loop =20 attacks via any other 6to4, ISATAP, and Teredo relay, even if this =20 relay doesn't make the new check on destination addresses. > > > To conclude: > - Without needing to modify 6to4 relays, ISATAP relays, and Teredo =20 > relays, ISPs that support 6rd and don't support 6to4 appear to be =20 > already protected against routing loop attacks if ingress filtering =20= > is operational at their interfaces to the IPv4 global Internet. =20 > With an additional simple precaution in 6rd relays, they can also =20 > be immune in the absence of such filtering. > > I fully agree. Thanks. Thoughts on the proposal to improve your mitigation measures? Regards, RD > > - A necessary additional security precaution against routing-loop =20 > attacks is now identified for ISPs that support 6rd and that, =20 > having started with 6to4, wish to keep it for backward =20 > compatibility. Thanks again for your analysis which made it possible. > > > Best regards, > RD > > > > Le 17 ao=FBt 09 =E0 17:21, Gabi Nakibly a =E9crit : > > > Hi all, > > I would like to draw the attention of the list to some research =20 > results which my colleague and I at the National EW Research & =20 > Simulation Center have recently published. The research presents a =20 > class of routing loop attacks that abuses 6to4, ISATAP and Teredo. =20 > The paper can be found at: http://www.usenix.org/events/woot09/tech/=20= > full_papers/nakibly.pdf > > > > Here is the abstract: > > IPv6 is the future network layer protocol for the Internet. Since =20= > it is not compatible with its predecessor, some interoperability =20 > mechanisms were designed. An important category of these mechanisms =20= > is automatic tunnels, which enable IPv6 communication over an IPv4 =20 > network without prior configuration. This category includes ISATAP, =20= > 6to4 and Teredo. We present a novel class of attacks that exploit =20 > vulnerabilities in these tunnels. These attacks take advantage of =20 > inconsistencies between a tunnel's overlay IPv6 routing state and =20 > the native IPv6 routing state. The attacks form routing loops which =20= > can be abused as a vehicle for traffic amplification to facilitate =20 > DoS attacks. We exhibit five attacks of this class. One of the =20 > presented attacks can DoS a Teredo server using a single packet. =20 > The exploited vulnerabilities are embedded in the design of the =20 > tunnels; hence any implementation of these tunnels may be =20 > vulnerable. In particular, the attacks were tested against the =20 > ISATAP, 6to4 and Teredo implementations of Windows Vista and =20 > Windows Server 2008 R2. > > > > I think the results of the research warrant some corrective =20 > action. If this indeed shall be the general sentiment of the list, =20 > I will be happy write an appropriate I-D. The mitigation measures =20 > we suggested in the paper are the best we could think of to =20 > completely eliminate the problem. However they are far from perfect =20= > since they would require tunnel implementations to be updated in =20 > case new types of automatic tunnels are introduced. > > > > Your comments are welcome. > > > > Gabi > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > From nette.gron@a-lehdet.fi Thu Aug 20 18:37:18 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2873A6ACF for ; Thu, 20 Aug 2009 18:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.816 X-Spam-Level: X-Spam-Status: No, score=-28.816 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FICiAKaVukDB for ; Thu, 20 Aug 2009 18:37:16 -0700 (PDT) Received: from af7.mopera.ne.jp (unknown [125.163.208.31]) by core3.amsl.com (Postfix) with SMTP id 716E33A6935 for ; Thu, 20 Aug 2009 18:37:14 -0700 (PDT) To: Subject: 2 v6ops-archive@ietf.org From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090821013715.716E33A6935@core3.amsl.com> Date: Thu, 20 Aug 2009 18:37:14 -0700 (PDT) Click here to view as a webpage. From upliftrbl@54032218.catv.pool.telekom.hu Thu Aug 20 18:55:15 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C533A6B43 for ; Thu, 20 Aug 2009 18:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.025 X-Spam-Level: X-Spam-Status: No, score=-75.025 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FM_SCHOOLING=5.657, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_20C99=0.571] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U29Hm-kuTp1d for ; Thu, 20 Aug 2009 18:55:14 -0700 (PDT) Received: from 54032218.catv.pool.telekom.hu (54032218.catv.pool.telekom.hu [84.3.34.24]) by core3.amsl.com (Postfix) with ESMTP id 083763A6885 for ; Thu, 20 Aug 2009 18:55:13 -0700 (PDT) Received: from 84.3.34.24 by mail.routesmart.com; Fri, 21 Aug 2009 02:55:19 +0100 Message-ID: <01ca220a$d1720b90$18220354@upliftrbl> From: "Clora C. Cottrell" To: Subject: More paid, less work Date: Fri, 21 Aug 2009 02:55:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3338.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3338.1 Now you can get real degree just in 4-5 weeks with the help of your professional career We are here serving you with these programs.:- Masters, Bachelors and PhD Ring right now [1.305-460-5721] Drop us your msg, with your full name and contact number so we can call you back. From office@alvi.ch Fri Aug 21 05:07:26 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13443A67F2 for ; Fri, 21 Aug 2009 05:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_80=2, DNS_FROM_RFC_BOGUSMX=1.482, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY-VBdQsjcvF for ; Fri, 21 Aug 2009 05:07:25 -0700 (PDT) Received: from 41.pool85-60-46.dynamic.orange.es (179.pool85-60-10.dynamic.orange.es [85.60.10.179]) by core3.amsl.com (Postfix) with SMTP id BFE413A6880 for ; Fri, 21 Aug 2009 05:07:16 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090821120723.BFE413A6880@core3.amsl.com> Date: Fri, 21 Aug 2009 05:07:16 -0700 (PDT) Show picture and go to site now! From marketing@agtal.com.br Fri Aug 21 10:45:00 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5616D28C1D5 for ; Fri, 21 Aug 2009 10:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.311 X-Spam-Level: X-Spam-Status: No, score=-8.311 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mREGuqotxrEU for ; Fri, 21 Aug 2009 10:44:58 -0700 (PDT) Received: from abacusint.co.uk (unknown [189.71.159.22]) by core3.amsl.com (Postfix) with SMTP id 211B03A6B5A for ; Fri, 21 Aug 2009 10:44:51 -0700 (PDT) To: Subject: new mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090821174452.211B03A6B5A@core3.amsl.com> Date: Fri, 21 Aug 2009 10:44:51 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Fri Aug 21 13:52:01 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA543A6A85 for ; Fri, 21 Aug 2009 13:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Jcwhu-Y840L0 for ; Fri, 21 Aug 2009 13:52:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DEDF63A69EE for ; Fri, 21 Aug 2009 13:52:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Meazd-000FV5-EM for v6ops-data0@psg.com; Fri, 21 Aug 2009 20:45:49 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b8c] (helo=outgoing02.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeazY-000FUJ-Qv for v6ops@ops.ietf.org; Fri, 21 Aug 2009 20:45:46 +0000 Received: from [2001:1888::a:214:51ff:fe29:1e4e] (unknown [IPv6:2001:1888:0:a:214:51ff:fe29:1e4e]) by outgoing02.lava.net (Postfix) with ESMTPS id ABBEF1718B2; Fri, 21 Aug 2009 10:45:42 -1000 (HST) Date: Fri, 21 Aug 2009 10:45:42 -1000 (HST) From: Antonio Querubin To: james woodyatt cc: Hemant Singh , Yaron Sheffer , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 In-Reply-To: Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B238@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B241@il-ex01.ad.checkpoint.com> User-Agent: Alpine 1.00 (OSX 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 19 Aug 2009, james woodyatt wrote: > On Aug 19, 2009, at 09:17, Hemant Singh (shemant) wrote: >> >> ...nor any widely deployed IPv6 CPE Router that performs packet filtering. > > I would humbly disagree with this statement. I concur. The Airport's IPv6 behaviour is becoming well-known to some in our tech support department, particularly when it sits several routers deep into a customer's NAT'ed, IPv4-only network :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net From owner-v6ops@ops.ietf.org Fri Aug 21 14:28:53 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811043A683E for ; Fri, 21 Aug 2009 14:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.232 X-Spam-Level: X-Spam-Status: No, score=-104.232 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 bILei84q1F8k for ; Fri, 21 Aug 2009 14:28:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 882833A6831 for ; Fri, 21 Aug 2009 14:28:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MebdB-000PLz-OA for v6ops-data0@psg.com; Fri, 21 Aug 2009 21:26:41 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mebd7-000PLL-Kk for v6ops@ops.ietf.org; Fri, 21 Aug 2009 21:26:39 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 534CA7319131 for ; Fri, 21 Aug 2009 14:26:36 -0700 (PDT) X-AuditID: 11807137-b7befae000005eb4-9f-4a8f110c053e Received: from il0602a-dhcp117.apple.com (il0602a-dhcp117.apple.com [17.206.23.245]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 42.23.24244.C011F8A4; Fri, 21 Aug 2009 14:26:36 -0700 (PDT) From: james woodyatt Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows Date: Fri, 21 Aug 2009 14:26:35 -0700 Message-Id: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: everyone-- We are not yet ready to proceed to another round of Working Group Last Call for this draft. At IETF 75 in Stockholm, several participants objected to the language in the current revision that recommends allowing unsolicited inbound IPv6-in-IPv6, GREv1-in-IPv6 and IPv4-in- IPv6 tunnel flow initiations to proceed without applying any stateful filtering regime to the encapsulated flows. Following this, I took the online discussion with some of those participants aside to the V6CPE Security design team email list and we've been talking about various alternatives to resolve the issue. This message is to report to the working group our current status. p1. At least one speaker at the microphone [I didn't get the name] offered to write sample language for appropriate recommendations, but I've not yet received anything. I'm not confident I could compose an adequate set of recommendations myself, so I'm stalled on that line of effort. p2. I have proposed an alternative way of addressing what seems to be to be the underlying root concern of the remaining objections, i.e. that encapsulated flows might be used to exploit undisclosed vulnerabilities in CPE hosts and thereby obtain a route to attack other hosts in the residential network. The design team seems not to have any major issues with it, so I'm going to propose it here to the working group before I go to write it into the -08 revision. To review, here is what section 3.2.7 currently says: > 3.2.7. Other Virtual Private Network Protocols > > Residential IPv6 gateways are not expected to prohibit the use of > virtual private networks in residential usage scenarios. > > R24: In their DEFAULT operating mode, IPv6 gateways MUST NOT > prohibit the forwarding, to and from legitimate node addresses, with > upper layer protocol of type IP version 6, and SHOULD NOT prohibit > the forwarding of other tunneled networking protocols commonly used > for virtual private networking, e.g. IP version 4, Generic Routing > Encapsulation, etcetera. I propose changing this to read as follows: > 3.2.7. Other Encapsulation Protocols > > While residential IPv6 gateways are not expected to prohibit virtual > private networks from operating with tunnel endpoints located at > interior nodes, it is important to protect interior networks from > being reachable through routes created remotely by exploiting > vulnerable interior hosts. Therefore, residential IPv6 gateways are > expected to require tunnel encapsulations to be protected by a > cryptographic protocol. > > R24: In their DEFAULT operating mode, IPv6 gateways MUST prohibit > the forwarding of packets to and from interior node addresses with > upper layer protocol of type IP version 6 and without Encapsulated > Security Payload (ESP) or Authenticated Header (AH) extension > headers. A configuration option MUST be provided for lifting this > prohibition. > > R25: In their DEFAULT operating mode, IPv6 gateways MUST prohibit > the forwarding of packets to and from interior node addresses with > upper layer protocol of type IP version 4 and Generic Routing > Encapsulation [RFC 2784]. [I would add the missing reference to RFC 2784 and adjust the recommendation numbers accordingly.] I'm now asking the working group if *this* change would be objectionable. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Fri Aug 21 15:07:39 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1337F28C16E for ; Fri, 21 Aug 2009 15:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.079 X-Spam-Level: X-Spam-Status: No, score=-4.079 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 xFSJysXNX6Kj for ; Fri, 21 Aug 2009 15:07:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1D733A6C12 for ; Fri, 21 Aug 2009 15:07:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MecDO-0007kx-LU for v6ops-data0@psg.com; Fri, 21 Aug 2009 22:04:06 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MecDJ-0007j1-Oq for v6ops@ops.ietf.org; Fri, 21 Aug 2009 22:04:04 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADa2jkpAZnmf/2dsb2JhbAC9Pog3kFMFhBqBVA X-IronPort-AV: E=Sophos;i="4.44,252,1249257600"; d="scan'208";a="55082717" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2009 22:04:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7LM40l8007684; Fri, 21 Aug 2009 18:04:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7LM405x018509; Fri, 21 Aug 2009 22:04:00 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.3959); Fri, 21 Aug 2009 18:04:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Date: Fri, 21 Aug 2009 18:03:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 Thread-Index: AcoioFzmng1Q7cnWQrCBFu+qyo0rXwACpiLg References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B238@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B241@il-ex01.ad.checkpoint.com> From: "Hemant Singh (shemant)" To: "Antonio Querubin" , "james woodyatt" Cc: "Yaron Sheffer" , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Aug 2009 22:04:00.0097 (UTC) FILETIME=[497A1510:01CA22AB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=754; t=1250892240; x=1251756240; 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=20New=20Version=20Notification=20for=20dr aft-ietf-v6ops-ipv6-cpe-router-01 |Sender:=20 |To:=20=22Antonio=20Querubin=22=20,=20=22jam es=20woodyatt=22=20; bh=/26H8GyBHTccQ1dhAQsdIQdEVkJMAEtaQouzNnEQtrs=; b=Ob/I4BluAs4YkRnj+Eh3+l/0jobe2dKbzWHUKgYAkKFOjVQKhKNc2BDD98 XvjclONVIGv1Uf7evkvYqVJmJq5jLVBjFdXrd8Rwrb4+BVX8gXPWQwXBTLXZ JIlfvRNAm9; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Friday, August 21, 2009 4:46 PM To: james woodyatt Cc: Hemant Singh (shemant); Yaron Sheffer; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New Version Notification for draft-ietf-v6ops-ipv6-cpe-router-01 >I concur. The Airport's IPv6 behaviour is becoming well-known to some in=20 >our tech support department, particularly when it sits several routers=20 >deep into a customer's NAT'ed, IPv4-only network :) Fine, Antonio and James. Wes and I were thinking once the cpe simple security draft becomes an RFC, we'd be happy to move the packet filtering from DEV to MEDIUM. In the meantime, we are still humbly open to any input. Hemant From owner-v6ops@ops.ietf.org Fri Aug 21 15:27:05 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1C13A69EA for ; Fri, 21 Aug 2009 15:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.476 X-Spam-Level: X-Spam-Status: No, score=-104.476 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 ah1cKk-J5IPn for ; Fri, 21 Aug 2009 15:27:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A26D93A6359 for ; Fri, 21 Aug 2009 15:27:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MecY0-000Brt-8S for v6ops-data0@psg.com; Fri, 21 Aug 2009 22:25:24 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MecXw-000BrT-HR for v6ops@ops.ietf.org; Fri, 21 Aug 2009 22:25:22 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 4A487731B5CC for ; Fri, 21 Aug 2009 15:25:20 -0700 (PDT) X-AuditID: 11807130-b7bdfae000004bc9-7b-4a8f1ed024b2 Received: from il0602a-dhcp117.apple.com (il0602a-dhcp117.apple.com [17.206.23.245]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id B4.EA.19401.0DE1F8A4; Fri, 21 Aug 2009 15:25:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1075.2) Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows From: james woodyatt In-Reply-To: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> Date: Fri, 21 Aug 2009 15:25:19 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 21, 2009, at 14:26, james woodyatt wrote: > [I wrote:] >> >> R24: In their DEFAULT operating mode, IPv6 gateways MUST prohibit >> the forwarding of packets to and from interior node addresses with >> upper layer protocol of type IP version 6 and without Encapsulated >> Security Payload (ESP) or Authenticated Header (AH) extension >> headers. A configuration option MUST be provided for lifting this >> prohibition. Ugh. This needs wordsmithing. How about this instead: > R24: In their DEFAULT operating mode, IPv6 gateways MUST prohibit > the forwarding of packets to and from interior node addresses with > upper layer protocol of type IP version 6 unless the encapsulated > packets have Encapsulated Security Payload (ESP) or Authenticated > Header (AH) extension headers. A configuration option MUST be > provided for lifting this prohibition. I think that more clearly defines the regime I'm proposing. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Sat Aug 22 04:07:36 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C706B3A6986 for ; Sat, 22 Aug 2009 04:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 LXiCMHwv4+G1 for ; Sat, 22 Aug 2009 04:07:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E3F93A686D for ; Sat, 22 Aug 2009 04:07:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeoLd-000MFw-Lx for v6ops-data0@psg.com; Sat, 22 Aug 2009 11:01:25 +0000 Received: from [194.29.32.54] (helo=dlpdemo.checkpoint.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeoLY-000ME3-V7 for v6ops@ops.ietf.org; Sat, 22 Aug 2009 11:01:23 +0000 Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C6D8A29C002; Sat, 22 Aug 2009 14:01:40 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 55F24200456; Sat, 22 Aug 2009 14:01:40 +0300 (IDT) X-CheckPoint: {4A8FCEFB-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n7MB1G3d018893; Sat, 22 Aug 2009 14:01:16 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sat, 22 Aug 2009 14:01:16 +0300 From: Yaron Sheffer To: james woodyatt , IPv6 Operations Date: Sat, 22 Aug 2009 14:01:14 +0300 Subject: RE: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows Thread-Topic: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows Thread-Index: AcoiskfYA/bccz++RjC9Ah05v1nptQAYyvvA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> In-Reply-To: <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0037_01CA2331.02D4A360" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0037_01CA2331.02D4A360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi James, I support your intention, which is to allow tunneled traffic only if it is cryptographically protected. But I don't understand the new text. It just doesn't clarify that we're talking of tunneled traffic. How about: R24: In their DEFAULT operating mode, IPv6 gateways MUST prohibit the forwarding of tunneled networking protocols, e.g. IPv4-in-IPv6, Generic Routing Encapsulation etc., unless such protocols are protected by applying ESP or AH extension headers to the encapsulating IPv6 packet. A configuration option MUST be provided for lifting this prohibition. In other words, the CPE is only required to verify that the *outer* packet is protected; if it is not protected, the standard internal-initiator policy applies, plus the gateway should drop suspicious GRE and IP-IP tunnels. Thanks, Yaron > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of james woodyatt > Sent: Saturday, August 22, 2009 1:25 > To: IPv6 Operations > Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated > flows > > On Aug 21, 2009, at 14:26, james woodyatt wrote: > > [I wrote:] > >> > >> R24: In their DEFAULT operating mode, IPv6 gateways MUST prohibit the > >> forwarding of packets to and from interior node addresses with upper > >> layer protocol of type IP version 6 and without Encapsulated Security > >> Payload (ESP) or Authenticated Header (AH) extension headers. A > >> configuration option MUST be provided for lifting this prohibition. > > Ugh. This needs wordsmithing. > > How about this instead: > > > R24: In their DEFAULT operating mode, IPv6 gateways MUST prohibit the > > forwarding of packets to and from interior node addresses with upper > > layer protocol of type IP version 6 unless the encapsulated packets > > have Encapsulated Security Payload (ESP) or Authenticated Header (AH) > > extension headers. A configuration option MUST be provided for > > lifting this prohibition. > > I think that more clearly defines the regime I'm proposing. > > > -- > james woodyatt > member of technical staff, communications engineering > > > > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0037_01CA2331.02D4A360 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyMjExMDExNFowIwYJKoZIhvcNAQkEMRYEFKscgrut0yYA SoL8FTnP6PJdYsPkMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA RQVSVHH3PpRuGgdALvGr3VAcbusbZAFSPf+U78IFAYiV7NQfDRQP3HNRJKYdp/acuCaeotW+6PHn KocCt8/gIPJvLKZutN+4w98cWFb5nwnEcFLB3/8PCRJtv53ZQmtyBqIZwN3Wqzr4IeFTAWCBIbAN 6VkKNoxWYj6j17lD534XGP17lRDfe50wP73kMreLCJ3jZACuHvU9jwXzCIp5VtgYbpV2vl7354eH nhOro1iZF5yCgdaqU6eb/Wsw8z3arMD4ExH0gptOpEIIYHNottKdMGwn2W4XCO+td1p6vzMkPd2P IVdaWq59Ss0MyNwvm5bmCw8AXGVeCoi9EDj8AQAAAAAAAA== ------=_NextPart_000_0037_01CA2331.02D4A360-- From owner-v6ops@ops.ietf.org Sat Aug 22 12:09:25 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831703A68F6 for ; Sat, 22 Aug 2009 12:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.63 X-Spam-Level: X-Spam-Status: No, score=-104.63 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 Ku-NpLJHf7RM for ; Sat, 22 Aug 2009 12:09:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DB763A6834 for ; Sat, 22 Aug 2009 12:09:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MevsL-000FD7-DS for v6ops-data0@psg.com; Sat, 22 Aug 2009 19:03:41 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MevsH-000FCR-9j for v6ops@ops.ietf.org; Sat, 22 Aug 2009 19:03:38 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 07F9C6F0460C for ; Sat, 22 Aug 2009 12:03:37 -0700 (PDT) X-AuditID: 11807130-b7bdfae000004bc9-92-4a904108fe25 Received: from [17.151.80.241] (Unknown_Domain [17.151.80.241]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id EE.8F.19401.801409A4; Sat, 22 Aug 2009 12:03:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1075.2) Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows From: james woodyatt In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> Date: Sat, 22 Aug 2009 12:03:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2009, at 04:01, Yaron Sheffer wrote: > > In other words, the CPE is only required to verify that the *outer* > packet > is protected; if it is not protected, the standard internal- > initiator policy > applies, plus the gateway should drop suspicious GRE and IP-IP > tunnels. Ah, I think I see where the confusion is arising. The recommendation to allow IPsec AH and ESP transport mode in both directions suffice to police the outer packet header chain. R20 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Authenticated Header (AH)" [RFC4302] in their outer IP extension header chain. R21 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with an upper layer protocol of type "Encapsulating Security Payload (ESP)" [RFC4303] in their outer IP extension header chain. What you would prefer to see is that section 3.2.7 be deleted in its entirety, which is precisely what I proposed at IETF 75 in Stockholm, and which failed to achieve consensus. Perhaps, after further discussion, this option will seem sensible to a larger fraction of participants? However, I should note that allowing outbound tunnel initiations still doesn't address the concern I described in my previous message. [My proposed text for section 3.2.7 to address this concern.] >> >> While residential IPv6 gateways are not expected to prohibit >> virtual private networks from operating with tunnel endpoints >> located at interior nodes, it is important to protect interior >> networks from being reachable through routes created remotely by >> exploiting vulnerable interior hosts. Therefore, residential IPv6 >> gateways are expected to require tunnel encapsulations to be >> protected by a cryptographic protocol. If the perception is that flows encapsulated in tunnels must be subject to a stateful filtering regime to protect the interior network against exploits against vulnerable tunnel endpoint hosts, and if requiring such encapsulated flows to be encrypted with IPsec-in-IPv6- in-IPv6 is regarded as an acceptable way to meet the perceived need to protect all encapsulated flows with a cryptographic protocol, then simply treating outbound tunnel initiations as any other unrecognized protocol would be insufficient to address the objections in the working group to taking this draft to Last Call. How should we proceed? -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Sat Aug 22 22:04:31 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7E13A6A66 for ; Sat, 22 Aug 2009 22:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 GqCNV1S7FD36 for ; Sat, 22 Aug 2009 22:04:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FD683A67D1 for ; Sat, 22 Aug 2009 22:04:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf5AI-000FqV-U6 for v6ops-data0@psg.com; Sun, 23 Aug 2009 04:58:50 +0000 Received: from [2001:470:8859:cafe:20c:29ff:fec5:e30a] (helo=research.suspicious.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf5AD-000FpZ-9W for v6ops@ops.ietf.org; Sun, 23 Aug 2009 04:58:48 +0000 Received: from [IPv6:2001::53aa:64c:0:e0bf:9f0d:6265] (unknown [IPv6:2001:0:53aa:64c:0:e0bf:9f0d:6265]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by research.suspicious.org (Postfix) with ESMTPSA id D46DA7FE0; Sun, 23 Aug 2009 00:58:42 -0400 (EDT) Cc: IPv6 Operations Message-Id: <390865C6-3343-4C31-9767-6E0FCA4481DD@suspicious.org> From: Truman Boyes To: james woodyatt In-Reply-To: <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> Content-Type: multipart/alternative; boundary=Apple-Mail-17--34100891 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows Date: Sun, 23 Aug 2009 00:58:42 -0400 References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-17--34100891 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Greetings, This is quite confusing from an implementation perspective; security is not explicitly increased by prohibiting non-encrypted tunnels but allowing encrypted (ESP or AH) traffic flows. Wouldn't this simply serve as a driver to make all tunnel encapsulations use ESP/AH? Kind regards, Truman Boyes On 22/08/2009, at 3:03 PM, james woodyatt wrote: > On Aug 22, 2009, at 04:01, Yaron Sheffer wrote: >> >> In other words, the CPE is only required to verify that the *outer* >> packet >> is protected; if it is not protected, the standard internal- >> initiator policy >> applies, plus the gateway should drop suspicious GRE and IP-IP >> tunnels. > > Ah, I think I see where the confusion is arising. The > recommendation to allow IPsec AH and ESP transport mode in both > directions suffice to police the outer packet header chain. > > R20 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit > the forwarding of packets, to and from legitimate node addresses, > with destination extension headers of type "Authenticated Header > (AH)" [RFC4302] in their outer IP extension header chain. > > R21 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit > the forwarding of packets, to and from legitimate node addresses, > with an upper layer protocol of type "Encapsulating Security > Payload (ESP)" [RFC4303] in their outer IP extension header > chain. > > What you would prefer to see is that section 3.2.7 be deleted in its > entirety, which is precisely what I proposed at IETF 75 in > Stockholm, and which failed to achieve consensus. Perhaps, after > further discussion, this option will seem sensible to a larger > fraction of participants? > > However, I should note that allowing outbound tunnel initiations > still doesn't address the concern I described in my previous message. > > [My proposed text for section 3.2.7 to address this concern.] >>> > >>> While residential IPv6 gateways are not expected to prohibit >>> virtual private networks from operating with tunnel endpoints >>> located at interior nodes, it is important to protect interior >>> networks from being reachable through routes created remotely by >>> exploiting vulnerable interior hosts. Therefore, residential IPv6 >>> gateways are expected to require tunnel encapsulations to be >>> protected by a cryptographic protocol. > > If the perception is that flows encapsulated in tunnels must be > subject to a stateful filtering regime to protect the interior > network against exploits against vulnerable tunnel endpoint hosts, > and if requiring such encapsulated flows to be encrypted with IPsec- > in-IPv6-in-IPv6 is regarded as an acceptable way to meet the > perceived need to protect all encapsulated flows with a > cryptographic protocol, then simply treating outbound tunnel > initiations as any other unrecognized protocol would be insufficient > to address the objections in the working group to taking this draft > to Last Call. > > How should we proceed? > > > -- > james woodyatt > member of technical staff, communications engineering > > > --Apple-Mail-17--34100891 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On = Aug 22, 2009, at 04:01, Yaron Sheffer wrote:

In other words, = the CPE is only required to verify that the *outer* = packet
is protected; if it is = not protected, the standard internal-initiator = policy
applies, plus the = gateway should drop suspicious GRE and IP-IP = tunnels.

Ah, I think I see where the confusion is = arising.  The recommendation to allow IPsec AH and ESP transport = mode in both directions suffice to police the outer packet header = chain.

R20  In their DEFAULT operating mode, IPv6 gateways = MUST NOT prohibit
     the forwarding of = packets, to and from legitimate node addresses,
=      with destination extension headers of type = "Authenticated Header
     (AH)" [RFC4302] = in their outer IP extension header chain.

R21  In their = DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
=      the forwarding of packets, to and from = legitimate node addresses,
     with an = upper layer protocol of type "Encapsulating Security
=      Payload (ESP)" [RFC4303] in their outer IP = extension header chain.

What you would prefer to see is that = section 3.2.7 be deleted in its entirety, which is precisely what I = proposed at IETF 75 in Stockholm, and which failed to achieve consensus. =  Perhaps, after further discussion, this option will seem sensible = to a larger fraction of participants?

However, I should note that = allowing outbound tunnel initiations still doesn't address the concern I = described in my previous message.

[My proposed text for section = 3.2.7 to address this concern.]


While residential IPv6 gateways = are not expected to prohibit virtual private networks from operating = with tunnel endpoints located at interior nodes, it is important to = protect interior networks from being reachable through routes created = remotely by exploiting vulnerable interior hosts.  Therefore, = residential IPv6 gateways are expected to require tunnel encapsulations = to be protected by a cryptographic = protocol.

If the perception is that = flows encapsulated in tunnels must be subject to a stateful filtering = regime to protect the interior network against exploits against = vulnerable tunnel endpoint hosts, and if requiring such encapsulated = flows to be encrypted with IPsec-in-IPv6-in-IPv6 is regarded as an = acceptable way to meet the perceived need to protect all encapsulated = flows with a cryptographic protocol, then simply treating outbound = tunnel initiations as any other unrecognized protocol would be = insufficient to address the objections in the working group to taking = this draft to Last Call.

How should we = proceed?


--
james woodyatt <jhw@apple.com>
member of = technical staff, communications = engineering




= --Apple-Mail-17--34100891-- From owner-v6ops@ops.ietf.org Sat Aug 22 22:35:50 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7923A6A8E for ; Sat, 22 Aug 2009 22:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.623 X-Spam-Level: X-Spam-Status: No, score=-104.623 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 Z1uwC3UMG1Ce for ; Sat, 22 Aug 2009 22:35:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FC7F3A697C for ; Sat, 22 Aug 2009 22:35:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf5i4-000LsV-A9 for v6ops-data0@psg.com; Sun, 23 Aug 2009 05:33:44 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf5hy-000Lr3-IC for v6ops@ops.ietf.org; Sun, 23 Aug 2009 05:33:42 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 0E4287348485 for ; Sat, 22 Aug 2009 22:33:38 -0700 (PDT) X-AuditID: 11807130-b7ca1ae00000654a-e3-4a90d4b1b468 Received: from [17.151.80.241] (Unknown_Domain [17.151.80.241]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 88.38.25930.1B4D09A4; Sat, 22 Aug 2009 22:33:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1075.2) Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows From: james woodyatt In-Reply-To: <390865C6-3343-4C31-9767-6E0FCA4481DD@suspicious.org> Date: Sat, 22 Aug 2009 22:33:37 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> <390865C6-3343-4C31-9767-6E0FCA4481DD@suspicious.org> To: IPv6 Operations X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2009, at 21:58, Truman Boyes wrote: > > This is quite confusing from an implementation perspective; security > is not explicitly increased by prohibiting non-encrypted tunnels but > allowing encrypted (ESP or AH) traffic flows. Wouldn't this simply > serve as a driver to make all tunnel encapsulations use ESP/AH? Yes. I'm not sure I can explain how this is supposed to increase security, but if consensus in the working group emerges around these recommendations and the draft can proceed through working group last call, then that's good enough for me. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Sun Aug 23 02:21:10 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A76C3A69C6 for ; Sun, 23 Aug 2009 02:21:10 -0700 (PDT) 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=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, 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 0yACjCTEd0Wg for ; Sun, 23 Aug 2009 02:21:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FFD93A6964 for ; Sun, 23 Aug 2009 02:21:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf9Ac-000Bfu-9j for v6ops-data0@psg.com; Sun, 23 Aug 2009 09:15:26 +0000 Received: from [202.136.110.247] (helo=smtp4.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mf9AX-000Bed-6J for v6ops@ops.ietf.org; Sun, 23 Aug 2009 09:15:23 +0000 Received: from 114-30-113-149.ip.adam.com.au ([114.30.113.149] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Mf9AT-000347-BM; Sun, 23 Aug 2009 18:45:17 +0930 Received: from opy.nosense.org (localhost.localdomain [127.0.0.1]) by opy.nosense.org (Postfix) with SMTP id 4BF9249298; Sun, 23 Aug 2009 18:45:16 +0930 (CST) Date: Sun, 23 Aug 2009 18:45:16 +0930 From: Mark Smith To: james woodyatt Cc: IPv6 Operations Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows Message-Id: <20090823184516.a8667014.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> <390865C6-3343-4C31-9767-6E0FCA4481DD@suspicious.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sat, 22 Aug 2009 22:33:37 -0700 james woodyatt wrote: > On Aug 22, 2009, at 21:58, Truman Boyes wrote: > > > > This is quite confusing from an implementation perspective; security > > is not explicitly increased by prohibiting non-encrypted tunnels but > > allowing encrypted (ESP or AH) traffic flows. Wouldn't this simply > > serve as a driver to make all tunnel encapsulations use ESP/AH? > > Yes. I'm not sure I can explain how this is supposed to increase > security, but if consensus in the working group emerges around these > recommendations and the draft can proceed through working group last > call, then that's good enough for me. > Maybe I haven't fully understood the question, however isn't the answer as simple as the benefits of IPsec over cleartext? Even the better-than-nothing-mode of IPsec, while vulnerable to man-in-the-middle attacks during session setup, has a much smaller window of opportunity for exploitation over clear text traffic. Regards, Mark. From owner-v6ops@ops.ietf.org Sun Aug 23 03:53:27 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E572D3A67EF for ; Sun, 23 Aug 2009 03:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 DqezDjvGV0UF for ; Sun, 23 Aug 2009 03:53:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABC723A6870 for ; Sun, 23 Aug 2009 03:53:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfAdw-0001FR-Ow for v6ops-data0@psg.com; Sun, 23 Aug 2009 10:49:48 +0000 Received: from [194.29.32.54] (helo=dlpdemo.checkpoint.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfAdr-0001DB-5D for v6ops@ops.ietf.org; Sun, 23 Aug 2009 10:49:45 +0000 Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B387329C002; Sun, 23 Aug 2009 13:49:55 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 62CEF200440; Sun, 23 Aug 2009 13:49:55 +0300 (IDT) X-CheckPoint: {4A911DA8-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n7NAnU3f001191; Sun, 23 Aug 2009 13:49:31 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 23 Aug 2009 13:49:30 +0300 From: Yaron Sheffer To: james woodyatt , IPv6 Operations Date: Sun, 23 Aug 2009 13:49:28 +0300 Subject: RE: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows Thread-Topic: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows Thread-Index: AcojYRi9tfxLVAXeT0yRoxcyLnz4QgAfZWDQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B466@il-ex01.ad.checkpoint.com> References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> In-Reply-To: <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0043_01CA23F8.88824220" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0043_01CA23F8.88824220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi James, You are right. In view of R20 and R21, I would prefer sec. 3.2.7 to be removed. I think the extra complexity of intra-tunnel inspection of packets-in-IPv6-in-IPv6 cannot be justified. Thanks, Yaron > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of james woodyatt > Sent: Saturday, August 22, 2009 22:04 > To: IPv6 Operations > Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated > flows > > On Aug 22, 2009, at 04:01, Yaron Sheffer wrote: > > > > In other words, the CPE is only required to verify that the *outer* > > packet > > is protected; if it is not protected, the standard internal- > > initiator policy > > applies, plus the gateway should drop suspicious GRE and IP-IP > > tunnels. > > Ah, I think I see where the confusion is arising. The recommendation > to allow IPsec AH and ESP transport mode in both directions suffice to > police the outer packet header chain. > > R20 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit > the forwarding of packets, to and from legitimate node addresses, > with destination extension headers of type "Authenticated Header > (AH)" [RFC4302] in their outer IP extension header chain. > > R21 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit > the forwarding of packets, to and from legitimate node addresses, > with an upper layer protocol of type "Encapsulating Security > Payload (ESP)" [RFC4303] in their outer IP extension header > chain. > > What you would prefer to see is that section 3.2.7 be deleted in its > entirety, which is precisely what I proposed at IETF 75 in Stockholm, > and which failed to achieve consensus. Perhaps, after further > discussion, this option will seem sensible to a larger fraction of > participants? > > However, I should note that allowing outbound tunnel initiations still > doesn't address the concern I described in my previous message. > > [My proposed text for section 3.2.7 to address this concern.] > >> > > >> While residential IPv6 gateways are not expected to prohibit > >> virtual private networks from operating with tunnel endpoints > >> located at interior nodes, it is important to protect interior > >> networks from being reachable through routes created remotely by > >> exploiting vulnerable interior hosts. Therefore, residential IPv6 > >> gateways are expected to require tunnel encapsulations to be > >> protected by a cryptographic protocol. > > If the perception is that flows encapsulated in tunnels must be > subject to a stateful filtering regime to protect the interior network > against exploits against vulnerable tunnel endpoint hosts, and if > requiring such encapsulated flows to be encrypted with IPsec-in-IPv6- > in-IPv6 is regarded as an acceptable way to meet the perceived need to > protect all encapsulated flows with a cryptographic protocol, then > simply treating outbound tunnel initiations as any other unrecognized > protocol would be insufficient to address the objections in the > working group to taking this draft to Last Call. > > How should we proceed? > > > -- > james woodyatt > member of technical staff, communications engineering > > > > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0043_01CA23F8.88824220 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgyMzEwNDkyOFowIwYJKoZIhvcNAQkEMRYEFLDdZgv6qgKB wkBfOZ+Le/lhST7PMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA SJRY86OuMwfSw0JXFgobiSwxJ3hMlnURX/Km49TfryAJQHkR8F626EtIvaoqfN23VYlpXXr6GNYg seq0sszNLhPEIvcgfeZ0kULcGkanvpt5KDcPl2AZozbjGNcJ+VS7RRogUhtstOUa6a7YQX9bLBrU guOVrZvXmbi9XuWlDidDdyHv42JeJrpYzzzrinOI1KXm1J4tjr0Cpgf6K9+cEpZC6IvCFwlfgVxC 6nSgatwlQRdS9qPYYTrix4tsFlOiK3ppMhy+nJrb541Ghe6crhTpAruaXViG7FB03AiC27RSlc1r rnbtm5i5M42CvEPrEOvn/8gsbO/TpgWTeoCEVAAAAAAAAA== ------=_NextPart_000_0043_01CA23F8.88824220-- From jose@alejaja.pl Sun Aug 23 10:57:37 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7CA3A6866 for ; Sun, 23 Aug 2009 10:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAAo5i0WCxCc for ; Sun, 23 Aug 2009 10:57:35 -0700 (PDT) Received: from 77-253-123-139.adsl.inetia.pl (77-253-123-139.adsl.inetia.pl [77.253.123.139]) by core3.amsl.com (Postfix) with SMTP id 5049E3A677C for ; Sun, 23 Aug 2009 10:57:33 -0700 (PDT) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090823175734.5049E3A677C@core3.amsl.com> Date: Sun, 23 Aug 2009 10:57:33 -0700 (PDT) Show picture and go to site now! From adhered@manfreda.at Sun Aug 23 11:46:08 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ABF13A68A8 for ; Sun, 23 Aug 2009 11:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.884 X-Spam-Level: * X-Spam-Status: No, score=1.884 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DYN_RDNS_AND_INLINE_IMAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 iie3pGAZoM-G for ; Sun, 23 Aug 2009 11:46:07 -0700 (PDT) Received: from jgmes.orange.es (179.pool85-50-155.dynamic.orange.es [85.50.155.179]) by core3.amsl.com (Postfix) with SMTP id 5A1253A6A1B for ; Sun, 23 Aug 2009 11:46:05 -0700 (PDT) Message-ID: Date: Sun, 23 Aug 2009 20:46:12 +0200 From: Meller Fitzrandolph User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: v6ops-archive@megatron.ietf.org Subject: I carried over my arm, Content-Type: multipart/mixed; boundary="------------050805010903090603050304" This is a multi-part message in MIME format. --------------050805010903090603050304 Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit Uture life. Unceasing self-contemplation, self-analysis, and self-education have been the fundamental characteristics of my life from the very first, and have remained so until these latest days. To stir up, to animate, to awaken, and to strengthen, the pleasure and power of the human being to labour uninterruptedly at his own education, has become and always remained the fundamental principle and aim of my educational work. Great was my joy when I believed I had proved completely to my own satisfaction that I was not destined to go to hell. The stony, oppressive dogmas of orthodox theology I very early explained away, perhaps assisted in this by two circumstances. Firstly, I heard these expressions used over and over again, from my habit of being present at the lessons given by my father in our own house, in preparation for confirmation. I heard them used also in all sorts of ways, so that my mind almost unconsciously constructed some sort of explanation of them. Secondly, I was often a mute witness of the strict way in which my father performed his pastoral duties, and of the frequent scenes between him and the many people who came to the parsonage to seek advice and consolation. I was thus again constantly attracted from the outer to the inner aspects of life. Life, with its inmost motives laid bare, passed before my eyes, with my father's comments pronounced upon it; and thing and word, act and symbol were thus perceived by me in their most vivid relationship. I saw the disjointed, heavy-laden, torn, inharmonious life of man as it appeared in this community of five thousand souls, before the watchful eyes of its earnest, severe pastor. Matrimonial and sexual circumstances especially were often the objects of my father's gravest condemnation and rebuke. The way in which he spoke about these matters showed me that they formed one of the most oppressive and difficult parts of human conduct; and, in my youth and innocence, I felt a deep pain and sorrow that man alone, among all creatures, should be doomed to these separations of sex, whereby the right path was made so difficult for him to find. I felt it a real necessity for the satisfactio --------------050805010903090603050304 Content-Type: image/jpeg; name="ensue.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ensue.jpg" /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDADIiJSwlHzIsKSw4NTI7S31RS0VFS5ltc1p9tZ++u7Kf r6zI4f/zyNT/16yv+v/9////////wfD/////////////2wBDATU4OEtCS5NRUZP/zq/O//////// ////////////////////////////////////////////////////////////wAARCAFJASoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDRpF6f iaXNIvT8TTAWkPXFLSDuaQC0UUUAFFFFABRRRQAUUUDpQAUUUUAIO/1paRen4mlpgFJ/EPpS0n8X 0FAC0n0pTR0FABSN0/EUtIe31oAWiiikAUUUUAIv3R9KWkX7o+lLTAKQdTS0g6mkADqfrQeo+tA6 n60HqPrTAWiimjOOtIB1FJkjqKUHNACDpXP3X/H1N/vn+ddAvT8TXP3X/H1N/vn+dNgdCelIvT8T SnpSL0/E0ALSL92lpF7ikAtFFFABRRRQAUUUUAFIOppaT+L8KAFooooARen4mlpB0/GlpgFJ/Efp S0mcMfpQAp4pB70e5paACkPUfWlpD1H1oAWiiikAUUUUAIv3R9KWkX7o+lLTAKMUUUgEHU/Wg9R9 aB1P1oPUfWmAuKRelLSDgUgFpB3pc0etACL0/E1z91/x9Tf75/nXQDp+Nc/df8fUv++f502B0J6U i9PxNKelNB49eaAHUh65o5PtS7R35oATI9aNw9/ypelG6gVxMj3/ACo3D/8AXS5FHXpQAdaKQgel GPc0DFpBySaTJ9Pypwx2pAFFFFAhB0paRen40tABSD7x+lLSfxH6Uxi0UUUgCkPUfWlpD1H1pgLR RRSAKKKKAEX7o+lLQPug9BTTIo6c0wHUmR60K+SBjg0vAoAaCMn6+lBIyOvX0pQeTQTyPrQAbhSg g9KM0hAPOAaAFopOncijJ/8A1UAC9PxNc/df8fU3++f510Cnj8a5+6/4+pv98/zoYHQYz1oXp+Jp elIp49s0AL0+tITSE1Gz00iWx5aml6jLUwv6c1ViOYm30oeoNx54wRQGPfrRYVy0rhuM80uPWqof FWQdyhvWpaNIu46ggGk5HvQCDSKDkd8/WjPrxS0UAIvT8aWjAA+U0nPpmgBaM/MfpSZx14oB+br2 oELS0lA60hhSHqPrS5HTNIeCBimAtFAz3opAH0pMeppaUUwIZWw2B0HamhHbGBge9THaWzjmgtSA RIwrZJpzYHPrUcj7ULd+1PjJaJCepGaAEB5PB60E8jg0o6n60HqPrTAM+xoJFLQehoARelLikA4o 5HvQAgHH41gXP/H1L/vn+db4PH41gXX/AB9Tf75/nQwOgA/E0jHHHpTidqk1Wd6aVyZOwrPUZbg4 ppJPBo9fQ1djJsCcjntR1+n0o47CgmmIMe9IcUE00mgBc1dhGIVz9aqwRGV+fujrV49OKiT6GkF1 EFBGaKKk0Ex6H86UtsHPJPYUo61BnJJPeolKw0rj957AAUb29vypuaM1nzMqw/e3oDSbs9VFNop8 zCw/Kn+E/pSjZx0B9xio80bj60+di5SUD0/Shuoz61Du/wAinxybjtPJHINNTTYOI+kJApeT1NAG OlaEicn2oIwp5paR/uGgCGSVYkLHnAzgUxppVZGKDy2YDHcZqOZCtrLnrjA+makCMXDSNuK9ABgD 3pDt2DLeYQxLICQD71Yi4hjz1xUajau0AAe1TD7goBsQdT9aD1H1oHU/Wg9R9aYhaKKKQCDpS0i9 KWmAg6fj/Wufuf8Aj6l/3z/OugHT8a5+6/4+pv8AfP8AOhgbtwcRj61UJq86CRCp49DVN4JEP3cj 1FVFozkmN3UZppVh2P5UbTVkWFzSZoCMex/KniCQ9Eb8sUBYjJqSGBpTnovrU0VqBzIc+w6VYPNS 5di1DuCqEXaowBRSAdgTRz6Z+lQWLRQDRSGKKrA8VYqvKNshHbqKzqdy4huxS7vY0zrS5yKyuUPz SE4I96b6fSgZwOOlFwsLu45I/CjNJ689aaSB0pXAVmxTrYFpC3YCoSSzYHU1bVPLRVHXvVwjdik7 IfR+NIDnrS10GQUjfcNLmo5t3kuU+9jikMaRvUqQCD2NMklVPvMB7d6g8q4k/wBZJgHqM09LWNWA ZgWPTJxmkVZLdjTcu/ywp+J/wq5AGWBA5y3OTUKPGVjMeGV2wAvH1NSQy+cJAVAEchQY9qYm10JB 1P1oPUfWkwOeB1owBjFMQ6ikwvt+FGPQmgAXpS0gzjpRkfSgAXp+Jrn7r/j6m/3z/OugXp+Jrn7r /j6m/wB8/wA6GB0HP0oQ8ZobpQvT8TQA7NFMaRViaTIKqCcg+lNilMkbMBuYHBVeo6cc96QElFVW vOSip8+9U65HNNkupY1uchC0WzHB7/jQBcoqBpHTajyJ5hGSFiZuPwNOtpTPbpIQAWHIH1xQBJ/F +FLSDqaWmAYzSY9DS0UAJn1H5U2ZN6ZHJFPowPxpNJqwJ2KQNLuqaWHf8yde4qscqcEYrmlFo2Tu SbqN1RbqN1KwEhamEknA6mlSN5D8o49atRQLFyfmaqjFsTaQkEPljc33j+lSHtR15NIcAiuhK2iM 27ijvRSA9frS9etMkMjoOtNlk8qJ3ZCQo5A60/pQQGBVhkEYIoGQMwMtusWcOd5YD+ED9M8VXtIz PBAzLgq+9nJ5bBP/ANb8qntrcW5LGTcMYUtxtXOcVLB5SpsiI2pxgdqQWK0UL+f9qRdnmNhkYYIX 1+vGfxqRIXjMmJFAdy/3cnmlu5jGhCfeHJPp/wDXpHDEyScPHjK/Mew5+tK5ag7XZMo65pT1H1pI yGQEDAIBA/ClPUfWqI6i4HpSYpaKAADAooooAaBxwcc1gXP/AB9S/wC+f510C9PxNc/df8fU3++f 50MDoSMikU8Ucnp+tIB68igCl5LB2tQuYWcPkdAvce3IqYWrGORWYDdMZMYyCPQipnlVHRTnLZxi klkKGPC8OwBJ7ZpXGotkX2RfnbOXYqwPQAjpjFLHZoqyiT5/NILDkDj/AOvViooS32iZWYsBtxn6 UAle454kdgxB3AYyrEHHpxQkaxIEjG1R0GaiUPD5YlyxLbdwkbr24qxQmElYQAjoRRn1FLRTEAIP SiggGk5HvQAtFJn14+tLQAi8fnSsFb7yg00sqIWdgqjqTTUmjcZVx03c8cevPakw1AwxEnK0qxRj og/GnLgjIIOeQRR/EfpS5UO7F57Ej6U0ZI6mnUgFUITFHHH9KUCg9R9aAAD1paKKACoLyYxRfLnc xwD6VOTiorlHkgKpjnsfrSexULcyuMmceXGRIGHmjJHApy7vMmkQBt23bk8HA5pQ6RnYMs5+baBy eeppZTL5O6NRvHO1ucj0pWHzdELLAkgYFQC3VgOaR1jYuzHgD5vm4/EVVklMsYm3EQyuqbScYXvn nuf0p1xDvnVYFUHy3V9vAAIwAfxp2J5mWDJGApLYDsAuM85HFNM8IJ+c4VtrEq2AenXpUCq0sdtG qODGys5ZSANowee/4U0wSlZtwcxmZi0WMFxwcg/5zTEXtvufzowfX86XOefXnkYooATJ7j8qUEGi ggHrQAi9PxNc/df8fU3++f51vjOOD3rAuf8Aj6l/3z/OhgdDSDp+NLSDp+NAFW4Ui7RoyfMIIx6c cVPJG77PmUbSGJx1I9qk4yDgZHQ0VNi3PYTbllJJyv5GkWNUcsM7j1O4806imTdjBFGCCF6HIGTg H6dKfRRQJtvcKKKKACiiigApMY9qWkx60wIbiJp7aSMcFuh/HNJLcRlGZSVmCMyhlwy8VK8ixRl2 OAM/jSqyyx5HzKw6f0pdR2drkIuMRRFpE3sgYhuM8DnI6f59Kiju/Ml35ZY/s5cqMEgg1ZaJdysP kZRtBXjA9KiSzRAyqzD90Y+eepJzQIclwJPljSSQhVJ6DGRxnkfpU/c1We03oiF1GwKAwT5xj0Oe Ks9zTAQdKD1FKOaiSYS7TGrMpP3ug/WkIlpOaoNqJktJSo8uQY298jOKntpQBOZH6TMBuP0oGOlu UhmVGBwcbnzwuc4/lTHkEiTuRIUjJTap29Byev8An0pq27TxSmRigmYnBX5gO2fp6U4xwwh97uxI 3OoJwT3JA6Z9+KAGZL3UbgSBWtxwpyTz0z/XIq5GMIPlK+xOT+dV3uczLGHAVow4bGSeegH/ANY/ SoZVke9Qxs+Y4t4DDluTx7ZzQBPmC1tCvMkaEqw4bn3/ADo8zDOkMaKUALbjtxkcDj/GqsYe40+f Yh3SykgfiDVqaJpi/wC6iBZcB2+8vH+e9AE4zzkYPp+FB6j60ka7FC5J2gDJ78Up6j60wFooopAF FFHrTARen41z91/x9Tf75/nXQDp+Jrn7n/j6l/3z/OhgdDSDp+NLSZCjJIHPegBaKbuJ+6p+p4o2 serY+gpAOpcUzaO+T9TRsT+4v5UAPxSU3Yn9xfyFGxf7oH04oAdRSbfRmH60nzDsD9OKAHUUm8Zw eD6HiloAKKKKAIZwGtnyu7qfp15pLYh4trKRgKN2MZ445qYDIx25o2jbtwNvTHahrUtS92xFac2s f0P8zSPKweXBUbFBAI+9xmpQiqpVflB/unGPpTZIvMXYWOAACSASfxpWdh3Tk2xBK0kiKgC7o9+S M/h2pYJPNiVyMEjkUrxhkVVCAAYG5d2PpSoixoEXoKFcTcbaDlqlYoywxK8cuQeQTgDn0z/Q1cFB 6j61RBVWxVrWKKU5MZJyvv2qwkUaMzKgDMck980+ikAVTCNJd3aBgqsFByMn7varlFAEH2cidZI3 CKIxHjGTjPvUqooYP1fGNx64zmlBAQEnAxSBsj5QT79qYDqKbhj1IH0o2DuSfqaQCjqfrQeo+tIE U5+RfyoKJx8i8/7IpgOooAAGAAB7UUgCj1oo9aYCL0/E1z91/wAfU3++f510C9PxNc/df8fU3++f 50MDf+Y99v6mhVA5A59adSL0/E0gFpryJGAZGC56U6qqgXDPKw+U/Ko9qGyoq+5a6j2qkC0mqSxs 77AgIAcjsPSpLaQoxt26j7hPcU42q+e0wd1dhg4xj9R7UCas7FI3s0VvMhbc8cgQOcdOf8P1qed3 slifezrna4Yk59xk8dKnS1hSAwBcoTkgk89P8KYbNG8sM7Osf3VbHt7e1Ah13M8CKY1DszhcH8ac txE0ccgb5ZGCj6ntSXEbS+VjA2Sq5yewqnNG8NzGqL+4aZXGB909MUAaRAPBAPtTduPukj2PIqhY wh1uA7YnDEFh1Hv+eakjvGNn9obB2na6gY5z1B/EUAW9xHVfxHNKCCMg5psUglQMFZQQCNw7GnFQ Tkjn1oAF6fiaWmjcBwQfrxRvA+8Cv1pgOpP4j9KUEEZBzSfxH6UALRmiigBB0oPUUAcUjMoIyQPa gB3WgU3cT0X8+KNufvEn2HFIBSwzgcn0FJ8x/wBn68mlJVMAkLk4A9ahvLj7LCH27snGM49aAJVU cEc+hNJLIsMZkkyAOtUrxi1m5DO3A5HCjn9f1qG5Wa1je3+aSKTGw5ztwelAF24uXiljjEYHmNtD E5/HH4+tR+dKb14Hdiqrn92vJPH+NSXcLzXFuyY2xvljn3FAtnF3JOsgXeoGNufT/CgCC7kZJLcB plVnIYbjkjj0p9u7PeuImdoVHziQk4Ptnn/J9qma3WV42kdi0bbhjA9P8Kc0Cm4WbJV+hK8bh70A S0UnPtRk9xTAWj1pMil9aAEXp+Jrn7r/AI+pv98/zroF6fia5+6/4+pv98/zoYHQZ/Gj8cDNKM/Q Uij+tAENw3yCNfvScZ9B3oeSGBQJH2DotNjJllaX1+VPpVPWF2zR/wC7/Wp3LfuqxPOM4IPzDlTV mCRZ4w+AG6MPQ02eHNupX7yqPxqpbzeTMCT8rcN/jSvZltc8bo0XGUKg4yOMdqrtM3lRMDzjLfQc GrNQpAQ0m4ja3A9getOxEWuo5pG3uqgHaufxpfNUKjE434xTLZGVSZBhiefw4qEKXDJ3iBA+ueP5 UD5UyxLAkoIJYErtJU9qgmtdlhJDAhOeRz15FSJ+9kkYHHyhQf1o8/EcRxktjPtRcnlH24K28QII IRQQe3FV4WnmvJw0hRYzhVA/I/kP14q0Spfb/FjNMMOJvNjIDkYORkNTJIkuinlJPEUeRivHIzx+ nNWs4747VnzRz7rVpcOUkJYoOAMj/A1anKSWkpUq67G5ByM4oAlKqTkgZ9e9Jt9Cw/Gs6OaSKztl hOJJmI3McgYOOn4/pVuQzwlmBEkaoTlsZzz6YoAm2n++36f4UbT/AH2/T/Cqkd680UaxKrTvkkc7 UGepq6M4GSCe+KAG7B7n6k0uMY2jA9hUdzuEDsrspVSeMc8Vn6U7yXbl2ZjsPU57igC+91CiSNvB 8v7wHr6U0NO8wQhEXblgrZZf8/TvVNU3rdP5JmV5flwfrz+tWYLRUuDKqeWoGFXOT7k//roAZYf8 fN3kk7XwCTk4yak1CF57dUjAJDgnnHGDUscUcTyMgO6Q5bmpOcelAELQmWPbMw2d1Xp+f/6qmz1x k5oA6GlpgJz9KMeuTS0UANCjJ4HWgqMjgdaUdT9aD1H1oANo9KMehNLRQAnOOmaTj6U6j1oAaCQO nesC5/4+pf8AfP8AOt8Djg45rAuf+PqX/fP86GB0Paq90+2HYDgucfQd6selZ0zGaY7ecnC/T/PN TJ2RdON2XLbaw3L0HAqtqtvJM8PlqW6g4q3GAiBR0FVNRZ32COVVA680bCer0L54GKy7uLypNyj5 Gqwb2NVAG5iB1qvPdiWMp5fXoSaTsXBST2LNjN5kflsfmQce4q1WNDI0UiuByp6eo7ithGDorqch hkU0yakbMWmhk8woCu/uO9OqjqADXNopwRvwQfqKZBbijWJNq5xnvUIhYmUEYGCF/HmoWuHgvJNx zApVSOu3I6/pVxJQ80kQBBjxk+uRSsUpNEdu3mM8vY4ApZXCyx5bC4Of0p4CPHiNhtz1Q02WISSI SAVAOaB3TdxElJVn2/IMkH1pD9nnJ3BSxGORgkUhY+RKjfeVT+I9adHvwm5FI4+YdqdwaQ1rSMw+ WjMqg7lwfunnkfnRJDPIWzMu0oV2gYBJz16+tNRV3sGZ0cuceh5/KppN45V1UD1oE46lWKxeFEaJ gs6/eOSVYZ6GpbR7iTzJJgyqThEIxj9KmjJeNWyRkZxTSztIUTt1J7UCsE0byqybwiMMHC8/nn+l N+zQAoRGvy8DGRgUrF443ZiGxjFNmiCRFskuBncTRcaiSeYiOsSgKccADAxTTIxuQn8ODn60x0Ms x7N5YI9jk05Y2WSMnkgMWPuaWpVkiekPSlpjyorbCcv12gZNMzHjpRVS6uXhMK4EYkbBJOSBxz6d /em27GS+fy52eNVG7JB3H29qALtFFFMBB1P1oPUfWgdT9aD1H1oAWiiikAUDvRR60wEHT8a5+6/4 +pv98/zroF6fia5+6/4+pv8AfP8AOhgbd1JsgIHVuPw7mqMblH3KAT2q5PbySzdVC4AFLHaxLyRu P+1z+lQ02zaMoxjYqZnn6bmHt0p62Dn7zKv6mr/QUU+Ul1H0Kq2MY+8zH9Kf9jg/uH/vo/41PRkf 5xTsieZ9yD7Hb/8APP8A8eP+NTBVVQqjAHTFLkf5xRQhNtiY9CajkhSQgvGpYdGHB/OpaKYiEW6E y5LHzVAbPsMZqKximikm87k/KA3qBkf4VbHrSY9DSApTs9pOwiGftH3Rn7r+vP1p4uJLfyoZQZZ3 /u9h/nNTSwpK0bOpzG25SD/n0pk8JaeK4jALJwR6j/JNAD1ljcOrEKVOGViARn/9dOWLYRtZgB/C eRWXe+ZJNI0UbbAmGO3GRnP+FWLmWSHTbdo2Kn5Rn/gNA7ssypI4K/Lgnr3FLIQcq8bMvsM1BDcT yTXCgIwiYgDoT17/AIVYtpluYhIvGeCPQ0WHzCRlkjQOCWPB74+tJ80crNtLK/p2NRrfxmFpRHLs U4JwP8ae10glSNVZ2kXcuMAY/GgLjiGmRlZdoPTPWkMbvtEjArnkAdaibUI4/MDoyun8JPX6U24n nt0ilcoQSA6AdPp+tAcxbIVcyHjA5PtUMt2qwLJEPNLttUdOapT+at7NboSRMRz6Dr+XJp4s3XUV 4Pkht4I4A74/QCgkdczs0s8bxybEXAVeM/7RNQWjRi8crM6psABYjJ6cf/q9OKvmBmeQSTM8bn7n oPSpQiqSyoqk8HA5oAryW/myQOg2LG5Zi3U9Px7d6maGJpll8sbx3HFSADrS0wE5+lGPXJpaKAGg DJ4oIGRwOtLwCaOM/wD6qLgG0elGPQmlooATn60nfrg06igBoOBWBc/8fUv++f51vgccHHNYFz/x 9S/75/nQwOhoJ9TVW8umt9u0Alu5qrlni824Zip6KOM0W0uK5dku4ox1z9KqPqTH7iAe5qG4KlFK k88EVcWCFjtGFW4ClQB93HJFVa24r32Kj3NyRkllGcZxjmo/Pl/56P8A99Vdjmhd/NkKZMp6jnbt 4piXEflpub95sdd2Puk9P8in8gIJDNFs3Ssdyhhhj0NItxMvSRvx5qy9xGVIEuJPLVfMweoPPPWn faLZmkZlyA+4DaPm4x/9ej5AQpfzKMHDVYj1CM/eBX+VMEEDymNRu2oo3D7pPrxUEEKvdeU4IGSO vIxSsmGpqJKkgyrA/SnVj+XIqiRQwQ9GFTR3ksZAkGRjuMGly9h3NKgjNV472J+rbT/tf5/rVgEE cUhjRnGOo54NVpLa3/dxuzrGCSI93H+efWrQ6fjWfdky3QQdsKKUnYunDmdiUWIZrgswPmnKkdV6 /wD1qms1aOIRvGEKHGV6N71KFAAAHSjHuaZBlRQkWMiSRT+YTlVCtg9PwqYQzNeWxkUrtjwzIOB1 49P88VfwfU0Ae5oAz2sZW8yJsFWbeJcjOfQirHkNKYjcMD5fOF6E+p/z3qxj6/nR0Ix60ANMaNKJ dnzgYDH/AD707HqaWigAHFIeRSPIkYyxAqvJeKPuDd7mi1xFroKie4jTgnn0FUnmeTO5uD2qOq5Q uW3vD/Cv4momuJG/ixUVFOyFcf5jn+Nvzo8x/wC+350ylpiNTufrRR6/WisiwooooARen4mufuv+ Pqb/AHz/ADroF6fia5+6/wCPqb/fP86bA0dSXc8Kjvx/KopPnfCuFVOAatXcUkkkTRgfLycn6VH9 ljUfvDn/AGRxQnZoTVym+GO2NSffqTUi2tw6gNwo6Bj0q+oKr8kO0UbnPoKpzEo2Kq6f/fk/IU77 JAODI2fqKtLHu5ckgVIFTHEa4HtU3Y7IpixiPRnP4ikawT+F2H15q00YHzx8eopj7mkjVG27s84z 2oux2RUNlKpyjg/oajTzbWTzPL5HqOK0Nsy/3GHryKTzdv31ZPcjj86fMxWKsNwgaFXXCJuB75Bp 5QXDW6j7uwAvjoRnj9KlaCGUZAH1Wq72kkZ3Rtuwcj1p3QWGG1fjy/nBBPGO3XoTTVklhOASuD0N OEzRlg0YBZCp429amhkSRYInPHzB8+/Sm3bcEm9hY7//AJ6L+IqO1O+73sfU802WKNIkIb5ioOKh xwDxWbScrI2h7tNyNrINFZjiW3ON444wGz+lKt5MO4P4VXKY3NLj1H50D6j86oC8nIJABA6nB4pP tsvt+tHKwuaFISo5J6Vmm5lb+LH0FMO9hk7j7mjlYXL73ca9DuPtVZ7t24XCiq9LVcqFcUkk5JJo pKekTv8AdXj1piG0oGelWUtQOXOfYVMqqvCr+VS5DsVFgkb+HH1qRbU/xN+VWSCBkilVdwzmp5mO xALZO5aj7Mnq351Y2L7/AJ0jKAMj+dF2Ow/1+tFJzk9OtGT6flQAtFJkUtIBF6fia5+6/wCPqb/f P866Ben4mufuv+Pqb/fP86bA3XOPrgYpY02H1c9TSEgOCfSnxsu3dnk0gEL4J56U04Z+O4zQWZgQ oCilhXknt0FMQ0OCFHQdzUkZQE4Yn8KYVCMdw4PQ0pVTyHAHfmgBHcKx28jHNM6TwZ9/5U4hW6fd 7n1+lIVLzI3YZz+VJjQz7S+WC/wnnjPWrCHO1x0cZx+FQCDYTgsAT2xU4dSyKDznoevSjoLURreJ +VG0+qcVGY5o/SQfkaiaSS3ckhhHGSMdmzkj+gqVLkrtSYfvC204+g5/UUDGmSN/lcYP91xiql1E sbgqMKwrTDRzAj5XAOCCO9Vby2VYS6EgLzt7UnsaU3aRRkVkwjHI6jB4pCQQMDB7+9G47gTzjFPe Vpjyoz7DmlGet2azpNxUUWDKkt0r702E8hl5HH+e9KkcTqNibh5bEZ6k574pBaKyA8o2ORSC1kTO yQcjB46itbo5WmiQRosbr90MIywz93nmhYI/MG5Nv7wgDJ5AHWofscnqv50fY5P7y0adxD4njEZY KgfcOCe2P89KZNMGhRFOMFtwHA68U9bP1f8AIVIttEvUZ+pougsykqljhQT9KnS1Y/eIWrHmIPlQ bj6KKdsmcc4jH5mk5MdhgjihG44+ppRMrMoUEgnr2pQkcfznkj+Jz0psjbpYSCCDnGPpUjJlAIya N4Ee44Cj+VNI3Rlclc55pjQ/uNmMse/v60ncTJWYMmVIIOKFPy/nSbQiAAYAxQNu0hsc5GKYyIyY 5O4wZxn/AD2qZjle2OMYoBQLtHTGMY4pCV24X27YoG3cfjk8nrRg+v50ZAJ+tKCD0piEz6igY7Gl oxmgBoJA6d6wLn/j6l/3z/Ot8Zxwe9YFz/x9S/75/nQwN2RcgY5IpB5eOTg0rHBHrijLHuB9eTSA XPGF4X170eYOi9uw5o2Z6jP+9/hTscYzQA3c57H8abg5ziPP1/8ArVJgelLQBH8x7p/31/8AWow3 oD9DUlBAPUUAR7iOoYfhSh+45+lOwO3FIUB6gH36H86LAO3BhhgCPeo5YFkZnU4kK4BPbuKCpHQ/ 99UbivUEfXpQBDLaybVRPulRuPuM4/Mn9KVpWa181twDSL8vouQMVYD0EI/3lBOQc/TkUARRi3ES yGNUU/dyMk0+Rbcxh22bem7/AOvTXtyVGxj8r7wM4/DP40zYVizIXUeZuycZHuccUDbb3HiBWG6G Ugdudwo8mcdHRvqMU1CJUIzk7jtIO3fx1yKfDLts/Mck7Qc568E0CG+XcekX5n/Cjy7j/pkPxNPM zohMkWOm3DZyScYppuHEgiMY8wnH3sjoTn9KAAQSn70oH0WnC1j/AItzn/aNMjnkZo9wUK7MuB1y M8/pVmgBFUKMKAB6Chun40tNkYhTtGW7CgCnLarLKrszEL/Aehp0hHnxDPOT/Kl8tm/1r8f3U/xp yrHF90AZ7nkmgBykAc9aXcewxTcMe2Pr/hTgmeuT9eB+VADS3OCcn0o+bsp/HipAuBgcD0HFG0el AEfzf7I+rUc+qf8AfX/1qkA5P1oPUfWnoAZB7ilIB6ijGaTaPp9KADHoaMkdR+VGD6/nRn1GKABT x+Nc/df8fU3++f510AAI/Gufuf8Aj6l/3z/OhgdBg+v5UL0/GlpF6fiaAFooopAFFFFABRRRQAUU UUAHekx6cUtFADCg7DH+7x+lJhh05/Q1JQRnrTAYH59/1p4kpu3I5wee/NNKY6Ej9RSsA9gki4Yc ZzwaPLj2bMYTaV29sUzDex/Q0ZYfwsPpz/KgBfIQqQ0jNkAAkjjFCwoHDlyzg5ySOeCP60m9vR/+ +TRub0f8jQA9Y41C4BO1iw9ic5/macXFRfMf4T+JpMH+8PwGaAHl6buLfd5Ht0pQg9Pz5p2PXn60 WAYFJ6nPsP8AGnKuOnH0/wAadRQAij5R9KWgdBzmigAooooAQdT9aD1H1oHU/Wg9R9aYC0UUUgCi iigBAPwOa5+5/wCPqX/fP866Gueuv+Pqb/fP86AOhpF6fiaXpTQeOB3pgOoJA60h9z+AqF7qCLq6 g/XJ/SgCbP1oyfQ1RfVIh90M34YqM6tzxEf++v8A61AGlk+hoz7Gsz+1j/zyP/fX/wBanpqy/wAc bD6EH/CgDQ3D1paqJqNu45bHsRVhWRhlW49QeKAH0UnP1oyDSAWiiimAi9PxNLSL0/E0tAB1puBu P0p1J/EfpQAYHv8AnRj6/nS0UAJtHpQeo+tLSHqPrQAtFFFIAoooo6gIv3R9KWkB4GBQfc4+lMBe lJuH1qKS4hhPzuoPuef8arvqkI+7ub6CgC4DyeD1oJORwetZx1XBOIjj/e/+tSf2sf8Ankf++v8A 61AGnn2NG4etZy6sM/NGw+hz/hUyalA3Viv+8P8A9dAFyio0kjkGUYEeoNP5+tAC1z11/wAfU3++ f510ORXPXX/H1N/vn+dIDclnih5dwPrVCXVMcRJnnq1Vb7/j8l/3qgp3AlluZpfvuceg4FRUUUgC iiigAooooAKVHZDlGKn1BxSUUAXIdSmT7+HH5Gr0N/DNgE7T6NxWLRRcDo/ofwNLk9xVLT/+PEf7 xq8OgpgIvT8aWkFLQAUn8R+lLSH7x+lAC0UUUAFIeo+tLSHqPrQAtISBSnoabH92gBefpTZZI4+Z GA+ppW+8v1rH1X/j8P8AuigRYl1RVG2JSx9TwKpS3c0pOXIB7LxUNFIYUUUUAFFFFABRRRQAKxUg qSCOhFWotQnj+8d49+v51VooA2IdShkwH+Qns3T86y7gg3MpHTef51HRQB//2Q== --------------050805010903090603050304-- From owner-v6ops@ops.ietf.org Sun Aug 23 14:01:44 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45D73A68D8 for ; Sun, 23 Aug 2009 14:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.155 X-Spam-Level: X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 AKCs76yppn66 for ; Sun, 23 Aug 2009 14:01:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E79813A6774 for ; Sun, 23 Aug 2009 14:01:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfK7D-000FJo-Ps for v6ops-data0@psg.com; Sun, 23 Aug 2009 20:56:39 +0000 Received: from [209.85.216.173] (helo=mail-px0-f173.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfK74-000FIc-T8 for v6ops@ops.ietf.org; Sun, 23 Aug 2009 20:56:35 +0000 Received: by pxi3 with SMTP id 3so5810581pxi.32 for ; Sun, 23 Aug 2009 13:56:29 -0700 (PDT) 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=ANQ8F9jctRs97Rg59Gj9l7A9toyiQwAvwy/lmsvohNU=; b=XXlNCHQMruQJ4CYfsG3qd1wSvalqG7C5DQsquawTMQt+nlkGNBUYJMwbeCmlKZXXwv xX/sDA9OQrMmho6/Ob6vBzoTe3vTyen27k4AQJlkAdJzLBDcjxc6mQtv1aGOrqh9v3Ta zJY7qCXpRxs4ehwrxLTwfz2z1RWdShF3c0ktE= 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=PxMyD0eeM9VTnlBs3unp0PXu8AWMy1mEEhnP1+X2lr+pgF7N6E6GnxxXChcMziAfea uuRmgOUu6ysLp75n57GHE+3arvu68srX7QcSV51/4IFHWHBo/63gZ3LHa8dmV8+AJa0u Zs2/KLlg6FUkctVV5dipeIBdEKppv1j1XFCWs= Received: by 10.114.30.9 with SMTP id d9mr4746961wad.200.1251060989281; Sun, 23 Aug 2009 13:56:29 -0700 (PDT) Received: from ?10.1.1.4? (118-92-192-68.dsl.dyn.ihug.co.nz [118.92.192.68]) by mx.google.com with ESMTPS id d20sm7500834waa.12.2009.08.23.13.56.26 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Aug 2009 13:56:28 -0700 (PDT) Message-ID: <4A91ACF5.2000900@gmail.com> Date: Mon, 24 Aug 2009 08:56:21 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith CC: james woodyatt , IPv6 Operations Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> <390865C6-3343-4C31-9767-6E0FCA4481DD@suspicious.org> <20090823184516.a8667014.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20090823184516.a8667014.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2009-08-23 21:15, Mark Smith wrote: > On Sat, 22 Aug 2009 22:33:37 -0700 > james woodyatt wrote: > >> On Aug 22, 2009, at 21:58, Truman Boyes wrote: >>> This is quite confusing from an implementation perspective; security >>> is not explicitly increased by prohibiting non-encrypted tunnels but >>> allowing encrypted (ESP or AH) traffic flows. Wouldn't this simply >>> serve as a driver to make all tunnel encapsulations use ESP/AH? >> Yes. I'm not sure I can explain how this is supposed to increase >> security, but if consensus in the working group emerges around these >> recommendations and the draft can proceed through working group last >> call, then that's good enough for me. >> > > Maybe I haven't fully understood the question, however isn't the answer > as simple as the benefits of IPsec over cleartext? Even the > better-than-nothing-mode of IPsec, while vulnerable to > man-in-the-middle attacks during session setup, has a much smaller > window of opportunity for exploitation over clear text traffic. Not to mention the fact that other secure VPN techniques such as IP-over-TLS will still be fine through a conforming CPE. Brian From oqzxg@altdesign.co.nz Sun Aug 23 21:41:45 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28AED3A6D76 for ; Sun, 23 Aug 2009 21:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.222 X-Spam-Level: X-Spam-Status: No, score=-18.222 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdrs3qFK2nvy for ; Sun, 23 Aug 2009 21:41:42 -0700 (PDT) Received: from airlux.pt (unknown [123.16.142.67]) by core3.amsl.com (Postfix) with SMTP id 03D623A6D97 for ; Sun, 23 Aug 2009 21:41:34 -0700 (PDT) To: Subject: Return mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090824044137.03D623A6D97@core3.amsl.com> Date: Sun, 23 Aug 2009 21:41:34 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Mon Aug 24 04:50:24 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B7C3A6E21 for ; Mon, 24 Aug 2009 04:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 FIfBLYY5Bv1O for ; Mon, 24 Aug 2009 04:50:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 00E353A6B58 for ; Mon, 24 Aug 2009 04:50:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfXy0-0007rp-OK for v6ops-data0@psg.com; Mon, 24 Aug 2009 11:44:04 +0000 Received: from web45510.mail.sp1.yahoo.com ([68.180.197.134]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfXxu-0007qi-1a for v6ops@ops.ietf.org; Mon, 24 Aug 2009 11:44:01 +0000 Received: (qmail 90224 invoked by uid 60001); 24 Aug 2009 11:43:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251114237; bh=vuHLAbMSy6zcbOoUueqA8TbzU4ESksA1bW4qjYizY94=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xKeV/jtHNS/f/hLhHsb3IOKerKznaTIp9L+deKIrkFgP95zJu953jKCUwo8iuM2hWUMTwQct2ISGHjmYm4xUbehap8Qc4HkDftzQ2rhsiOaCzlNUCWSepVlgN5krgpfWfILOhfeuoNXy6ELcoTqfYxAP07Ozs6t/0BQZ/BVCO3c= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=29SXcpI/dE7VEX1uZ3TiRtGpW4rjGvlk/IoI6dj7zfHiykH6sMk9Bk0iOl+TvtiCwjnEFO/ofh2cPPsZ0uaHuq7I1SVaikPIhUQmFHytixfohiOjyEu6HUY+WsOyE3bppr/r9BDV6Q70QRTO1FDs+IyJhIPCGWIb6eQ9GfqnyEY=; Message-ID: <475898.88672.qm@web45510.mail.sp1.yahoo.com> X-YMail-OSG: 0EOTXdEVM1nkTG9q3rRXGw8pcJXBRe20k0bI4xL18xpIzKwMJxJXXWeyXCGM_b05YDw7dkJKDmBsQSl4JoG_eoOzE_xnSu.wDNU7qQwsXHEttAcLUBefiS4pYs5PFvH2777deG1P2M6vAwmok5P.0pc1pojD8nVdY65iC.V7knheRYReF4k0BEnz4C9Qbp02yvsSYagsjTozD22bWV63y2xbyWqRYkYFTQ8XfUabbwP6YOhHccrTqu2hoe5bm0RSNGMvKDJHadjvsPjjgGs- Received: from [89.139.41.78] by web45510.mail.sp1.yahoo.com via HTTP; Mon, 24 Aug 2009 04:43:57 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 Date: Mon, 24 Aug 2009 04:43:57 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" , v6ops Cc: ipv6@ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred,=0AI=A0initially very much=A0liked your suggestion regarding the check= =A0of the neighbor cache before forwarding a packet into the tunnel.=A0It t= ruly addresses the root cause of the problem ans is simple enough to implem= ent. However, I realized that an attacker can send a spoofed=A0RS to the IS= ATAP router as if it came from the 6to4 relay. The router would then send= =A0a RA=A0to it=A0and consequently change its neighbor cache. So it seems= =A0that this defense does not add much.=A0Wouldn't you agree?=A0=0A=A0=0AI = completely agree with your observation on the non-feasibility of verifying= =A0that the destination=A0ISATAP address does not include=A0a local=A0IPv4 = address=A0since the ISATAP address may include a private IPv4 address. On t= he other hand, a check on public IPv4 addresses is acceptable.=A0If the che= ck would be done only on ISATAP addresses that include public IPv4 addresse= s then this will eliminate the attacks in which the two victims reside=A0at= different sites. Note that if attack #3=A0is launched on two ISATAP router= s=A0having private addresses at two different sites then the attack will no= t work anyway since one router can not send a direct=A0IPv4 packet to the o= ther. In addition, to=A0mitigate attacks in which the other victim is a 6to= 4 relay (such as attack #1) then a check would have to be done on a 6to4 ad= dress, i.e. the destination address must not be "2002:::*". In this case the IPv4 address must be public, according= to the 6to4 spec.=0A=A0=0AAs you also noted there is another problem with thi= s check since the string "200::5EFE" is not unique to ISATAP links. On the = other hand, it seems that the probability to encounter a non-malicious pack= et with a destination address having an IID that equals "200:5EFE:" is pretty slim.=0A=A0=0AThis check is definitely not a= =A0perfect solution, and I sure hope that someone will come up with a bette= r one for mitigating the routing loops. However, I would be happy if there = is some kind of other mitigation=A0measures besides packet filtering=A0(pro= to-41 and ingress) by=A0other nodes (which=A0does not necessarily exist). = =0A=A0=0AGabi=0A=A0=0A----- Original Message ----=0AFrom: "Templin, Fred L"= =0ATo: Gabi Nakibly ; v6ops= =0ACc: ipv6@ietf.org; secdir@ietf.org=0ASent: Wednesda= y, August 19, 2009 6:16:18 PM=0ASubject: RE: Routing loop attacks using IPv= 6 tunnels=0A=0AHi Gabi,=0A=0AI'm sorry to have to keep turning this into pl= aintext,=0Abut annotation is difficult otherwise. See below for=0Amy respon= ses (=3D=3D>):=0A=0A________________________________________=0AFrom: Gabi N= akibly [mailto:gnakibly@yahoo.com] =0ASent: Wednesday, August 19, 2009 1:49= AM=0ATo: Templin, Fred L; v6ops=0ACc: ipv6@ietf.org; secdir@ietf.org=0ASub= ject: Re: Routing loop attacks using IPv6 tunnels=0A=0AFred,=0ASee my comme= nts inline ().=0A=0A________________________________________=0AFrom: "T= emplin, Fred L" =0ATo: Gabi Nakibly ; v6ops =0ACc: ipv6@ietf.org; secdir@ietf.org= =0ASent: Tuesday, August 18, 2009 6:48:45 PM=0ASubject: RE: Routing loop at= tacks using IPv6 tunnels=0A=0AGabi,=0A=0A__________________________________= ______=0AFrom: Gabi Nakibly [mailto:gnakibly@yahoo.com] =0ASent: Tuesday, A= ugust 18, 2009 3:29 AM=0ATo: Templin, Fred L; v6ops=0A> Cc: ipv6@ietf.org; = secdir@ietf.org=0A> Subject: Re: Routing loop attacks using IPv6 tunnels=0A= > =0A> Indeed the ISATAP interface of the ISATAP router is meant=0A> to be = an enterprise-interior (note that=A0it is still=A0assumed=0A> that the asso= ciated IPv4 address is=A0non-private). As=A0we=0A> explicitly note in the p= aper, the first three attacks=A0will=0A> be mitigated=A0if proper protocol-= 41 filtering is deployed on=0A> the site's border. However, note that RFC52= 14 does not mandate=0A> or require this filtering.=0A=0AThe RFC5214 Securit= y Considerations makes clear the=0Aconsequences of not implementing IPv4 in= gress filtering=0Aand ip-protocol-41 filtering (i.e., a possible spooing=0A= attack in which spurious ip-protocol-41 packets are=0Ainjected into an ISAT= AP link from outside). RFC5214=0ASection 6.2 additionally requires that an = ISATAP interface's=0Alocator set MUST NOT span multiple sites. This means t= hat the=0AISATAP interface must not decapsulate nor source ip-proto-41=0Apa= ckets within multiple sites, where the enterprise interior=0Ais site #1 and= the global Internet is site #2. ip-protocol-41=0Afiltering is the way in w= hich the ISATAP interface is=0Arestricted to a single site. =0A=0ANow l= et me see that I understand Section 6.2 correctly. In=0Aattack #2, for exam= ple, I assume the ISATAP router has two=0Aphysical interfaces. A site-inter= nal IPv4 interface with an=0Aaddress IPisatap and a site-external IPv6 inte= rface. I also=0Aassume that there=A0is another border router which connects= the=0Asite to the IPv4 Internet.=A0The ISATAP router has an ISATAP=0Ainter= face with a single locator: (IPisatap, site-internal=0Ainterface).=A0When t= he ISATAP router gets an IPv6 via its=0Aexternal interface it will encapsul= ate the packet accordingly=0Aand forward it through the internal IPv4 inter= face. If the=0Aencapsulated packet is=A0destined to a node outside the site= =0Athen the only thing that stops it is=A0a proto-41 filtering=0Aat the=A0o= ther border router of the site. Did I get this right?=0A=0A=0A=3D=3D> = In this case, yes - the ip-proto-41 filtering is at a=0A=3D=3D> border rout= er. I know of at least one major enterprise=0A=3D=3D> network that does thi= s.=0A=0A> It is only mentioned as a possible mitigation against=0A> incomin= g spurious protocol-41 packets. In addition,=0A> Section 10 of RFC5214 only= mentions=A0ingress not=A0egress=0A> filtering.=A0Hence it=A0will not stop = attack #2.=0A=0AWe are now talking about ip-proto-41 filtering; not ingress= =0Afiltering. ip-proto-41 filtering is in both directions. It=0Aprevents ip= -proto-41 packets from entering the enterprise=0Ainterior ISATAP site from = the Internet and prevents=0Aip-proto-41 packets from entering the Internet = ISATAP=0Asite from the enterprise interior. Else the ISATAP=0Ainterface wou= ld span multiple sites.=0A=0ABesides, "ingress" filtering is not about pack= ets coming=0Afrom the Internet into the end site, but rather it is=0Aabout = packets leaving the end site and going out into=0Athe Internet. RFC2827 (BC= P38) documents ingress filtering.=0A=0AOK. I see what you are saying he= re.=0A=0A=0A=3D=3D> OK.=0A=0A> In addition,=0A> as mentioned, protocol= -41 filtering is not helpful when=0A> attack #3 is launched on two routers = that reside in the=0A> same site. Note that=A0it=A0may be=A0possible for=A0= the attack=0A> packet=A0to be sourced from outside the site unless proper= =0A> filtering of incoming IPv6 packets is deployed. If the=0A> attacker re= sides in the site, usually ingress filtering=0A> will not be helpful since = it is deployed in general on=0A> the site's border.=0A=0AHere, we have the = ISATAP router in both cases sourcing a=0Apacket from a foreign prefix. =0A<= gn>=0AWell, I do not see how this is correct. In attacks #1 and #3 the ISAT= AP router sources (actually forwards) an IPv6=A0packet with=A0a source addr= ess having=A0the corresponding=A0prefix of the ISATAP tunnel. In attacks #2= and #3 the ISATAP router sources and IPv4 packet with its own IPv4 address= as the source address.=0A=0A=0A=3D=3D> There were a number of errors = in what I said in my last=0A=3D=3D> message, so let me see if I can get it = right here:=0A=3D=3D>=0A=3D=3D> In attacks #1 and #2 there are two cases to= consider. Case=0A=3D=3D> 1 in which a border router separates the 6to4 rel= ay from the=0A=3D=3D> ISATAP router, and case 2 in which no border router s= eparates=0A=3D=3D> the 6to4 relay from the ISATAP router.=0A=3D=3D>=0A=3D= =3D> In attack #1, we have an IPv6 packet with a local source=0A=3D=3D> add= ress entering the site from the outside. IPv6 ingress=0A=3D=3D> filtering a= t the site border router should prevent the=0A=3D=3D> packet from entering = the site in the first place. If the=0A=3D=3D> 6to4 relay router is outside = the site then ip-proto-41=0A=3D=3D> filtering at the border router will blo= ck the attack in=0A=3D=3D> the first place anyway. If the relay router is *= inside*=0A=3D=3D> the site, then the IPv6 ingress filtering is the lone=0A= =3D=3D> mitigation. The end result is that the 6to4 relay should=0A=3D=3D> = really be positioned outside of the site's border routers;=0A=3D=3D> otherw= ise, it could be spoofed into thinking that the=0A=3D=3D> ISATAP router is = a 6to4 router and not an ISATAP router. =0A=3D=3D>=0A=3D=3D> In attack #2, = we have an IPv6 packet with a foreign source=0A=3D=3D> address being forwar= ded by the ISATAP router to a 6to4=0A=3D=3D> relay, but I mis-spoke when I = said that this would be a=0A=3D=3D> case of the ISATAP router forwarding a = packet with a foreign=0A=3D=3D> source address out of the ISATAP link. For = all the ISATAP=0A=3D=3D> router knows, the 6to4 relay is just an ordinary h= ost on=0A=3D=3D> the ISATAP link, so the ISATAP router actually believes it= =0A=3D=3D> is forwarding the packet *into* the ISATAP link (not out of=0A= =3D=3D> it). But as in attack #1, the attack is blocked by ip-proto-41=0A= =3D=3D> filtering at the border router between the ISATAP router and=0A=3D= =3D> the 6to4 relay. If there is no border router between the ISATAP=0A=3D= =3D> router and the 6to4 relay, then we have an identical instance=0A=3D=3D= > to attack #3 which I will discuss below. But, the best=0A=3D=3D> operatio= nal practice would again be to have the 6to4 relay=0A=3D=3D> oriented outsi= de of a border router that filters ip-proto-41.=0A=3D=3D>=0A=3D=3D> Short s= ummary is that in attack #1, the 6to4 relay thinks it=0A=3D=3D> is talking = to a 6to4 router and not an ISATAP router. In=0A=3D=3D> attack #2, the ISAT= AP router thinks it is talking to a=0A=3D=3D> simple host on the link and n= ot a 6to4 relay. In both cases,=0A=3D=3D> the attacks are mitigated when th= ere is an ip-proto-41=0A=3D=3D> filtering border router between the ISATAP = router and the=0A=3D=3D> 6to4 relay. Oftentimes, the "border router" will b= e a two-=0A=3D=3D> interface router that implements 6to4 on a site-external= =0A=3D=3D> IPv4 interface and implements ISATAP on a site-internal=0A=3D=3D= > IPv4 interface and performs ip-proto-41 filtering on packets=0A=3D=3D> fr= om outside the site with an IPv4 destination corresponding=0A=3D=3D> to the= ISATAP interface. I will discuss attack #3 below:=0A=A0 =A0=0AThis attack = is mitigated by =0AIPv6 ingress filtering which is an IPv6 security conside= ration=0Aand not an ISATAP nor IPv4 security consideration. BCP=0Arecommend= ations for network ingress filtering are documented=0Ain RFC2827 and it is = expected that IPv6 routers that configure=0AISATAP interfaces will implemen= t IPv6 ingress filtering=0Aaccording to the BCP.=0A=0ASo If my last com= ment is correct than I do not see how ingress filtering would help here. Th= e only case where=A0ingress filtering can help is in case of attack #3 when= the routers reside at the same site. In that case if the attack packet (pa= cket 0) is sent from outside the site then ingress filtering on the border = of the site will drop the packet.=0A=0A=0A=3D=3D> Correct about the IP= v6 ingress filtering at the border,=0A=3D=3D> but as with attack #2 my erro= r in the previous message=0A=3D=3D> was in thinking the ISATAP router A was= forwarding the=0A=3D=3D> packet *out* of the ISATAP link when in fact from= the=0A=3D=3D> ISATAP router's perspective it is forwarding the packet=0A= =3D=3D> to a simple host *inside* of the link.=0A=3D=3D>=0A=3D=3D> The prob= lem here is that the ISATAP router is blindly=0A=3D=3D> forwarding a packet= to a node that it assumes is a simple=0A=3D=3D> host on the ISATAP link wi= thout first verifying that the=0A=3D=3D> node has demonstrated a willingnes= s to participate as a=0A=3D=3D> host on the link. As you have pointed out, = this can lead=0A=3D=3D> to strange scenarios when the anonymous node is a t= unnel=0A=3D=3D> router of some sort that does not participate in the=0A=3D= =3D> ISATAP link.=0A=3D=3D>=0A=3D=3D> It would not generally be possible fo= r the ISATAP router=0A=3D=3D> to check whether the IPv6 destination address= is an ISATAP=0A=3D=3D> address that embeds one of its own IPv4 addresses, = because=0A=3D=3D> when IPv4 private addresses are used the same IPv4 addres= s=0A=3D=3D> can (and often does) occur in multiple sites. So for example,= =0A=3D=3D> if the ISATAP router configures an IPv4 address 10.0.0.1=0A=3D= =3D> and is asked to forward an IPv6 packet with ISATAP=0A=3D=3D> destinati= on address 2001:DB8::0:5EFE:10.0.0.1 where the=0A=3D=3D> IPv6 prefix is for= eign, the router can't very well drop the=0A=3D=3D> packet as this would bl= ock legitimate communications. It=0A=3D=3D> is also not generally possible = to check whether a foreign=0A=3D=3D> link is an ISATAP link by looking for = the magic token=0A=3D=3D> "0:5EFE" as that token only has significance for = ISATAP=0A=3D=3D> links and not other link types.=0A=3D=3D>=0A=3D=3D> Instea= d, the mitigation I think makes the most sense is=0A=3D=3D> for the ISATAP = router to first verify that the node which=0A=3D=3D> it assumes to be a sim= ple ISATAP host has demonstrated a=0A=3D=3D> willingness to participate in = the link. That can be done=0A=3D=3D> by having the ISATAP router first chec= k the neighbor cache=0A=3D=3D> when it has a packet to send to verify that = there is a=0A=3D=3D> cached entry corresponding to the destination. For nod= es=0A=3D=3D> that are willing ISATAP hosts on the link, there would=0A=3D= =3D> have been a neighbor cache entry created when the node=0A=3D=3D> sends= a Router Solicitation to the ISATAP router for the=0A=3D=3D> purpose of di= scovering default router lifetimes and on-=0A=3D=3D> link prefixes. So, the= simple mitigations is for the ISATAP=0A=3D=3D> router to forward the packe= t only if there is a pre-existing=0A=3D=3D> neighbor cache entry and drop t= he packet otherwise. This=0A=3D=3D> implies that the router should keep nei= ghbor cache entires=0A=3D=3D> for the duration of the minimum lifetime of t= he prefixes=0A=3D=3D> it advertises in its Router Advertisements.=A0 =0A=0A= > In general, I would like to point out that indeed as in=0A> most other at= tacks these attacks may also be mitigated by=0A> proper firewall rules. How= ever, I do not believe that this=0A> should be our only answer against thes= e attacks. I believe=0A> that since these attacks are made possible due to = the=0A> inherent characteristics of the tunnels they=A0should be=0A> stoppe= d intrinsically as much as possible by the tunnel=0A> participants and not = relay on outside filtering rules.=0A=0AIn RFC5214, Section 10 we have: "res= tricting access to the=0Alink can be achieved by restricting access to the = site". The=0Amitigations do exactly that, and in such a way that ISATAP=0An= odes can operate with only the necessary and sufficient=0Achecks. So on thi= s point, I do not share your opinion.=0A=0AWhat about two ISATAP tunnel= s that reside on the same site like in attack #3. Do you=A0also think that = proto-41 filtering should barrier between the two tunnels within the site?= =A0=0A=0A=0A=3D=3D> I think this may be overcome by the discussion abo= ve.=0A=3D=3D> Short story is that operational practices must be=0A=3D=3D> e= mployed whereby an ISATAP router is not mistaken for=0A=3D=3D> a 6to4 route= r. This is through proper arrangement of=0A=3D=3D> 6to4 router/relay interf= aces outside of the site border=0A=3D=3D> rather than inside, and ISATAP ro= uter interfaces inside=0A=3D=3D> of the site border rather than outside. Al= so proper=0A=3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at=0A= =3D=3D> site borders.=0A=3D=3D>=0A=3D=3D> Also, when there are multiple ISA= TAP links within the=0A=3D=3D> same local IPv4 routing region, an ISATAP ro= uter should=0A=3D=3D> first verify a node's willingness to act as a host on= =0A=3D=3D> the ISATAP link before blindly sending a packet to it.=0A=3D=3D>= =0A=3D=3D> Fred=0A=3D=3D> fred.l.templin@boeing.com=0A=0AFred=0Afred.l.temp= lin@boeing.com=0A=A0=0A________________________________________=0AFrom: "Te= mplin, Fred L" =0ATo: Gabi Nakibly ; v6ops =0ACc: ipv6@ietf.org; secdir@ietf.org=0A= Sent: Monday, August 17, 2009 8:35:08 PM=0ASubject: RE: Routing loop attack= s using IPv6 tunnels=0A=0A=0AGabi,=0A=A0=0AThanks for publishing this work.= In the document, attacks A, B and C=0Acorrespond to a configuration that v= iolates section 6.2 of RFC5214:=0A=A0=0A> 6.2.=A0 ISATAP Interface Address = Configuration=0A>=A0=0A> =A0=A0Each ISATAP interface configures a set of lo= cators consisting of IPv4=0A>=A0=A0 address-to-interface mappings from a si= ngle site; i.e., an ISATAP=0A>=A0=A0 interface's locator set MUST NOT span = multiple sites.=0A=A0=0AIn particular, in scenarios A, B and C the IPv4 loc= ator used for ISATAP=0Ais seen both within the enterprise as site #1 and wi= thin the global Internet=0Aitself as site #2. If the ISATAP interface is to= be used as an enterprise-=0Ainterior interface, it should therefore not ac= cept IP-proto-41 packets=0Acoming from an IPv4 source outside of the enterp= rise nor source=0AIP-proto-41 packets that are destined to an IPv4 node out= side of the=0Aenterprise. This condition should be satisfied by having the = site border=0Arouters implement IPv4 ingress filtering and ip-protocol-41 f= iltering as=0Arequired in Section 10 of RFC5214.=0A=A0=0AIt is mentioned th= at attack C could also occur when the routers reside=0Ain the same site, wh= ere their addresses may be private. This would=0Acorrespond to a case in wh= ich an attacker within the site attacks the=0Asite itself, which can easily= be traced - especially when source address=0Aspoofing from a node within t= he site is prevented through proper ingress=0Afiltering.=0A=A0=0AFred=0Afre= d.l.templin@boeing.com=0A=A0=0A________________________________________=0AF= rom: Gabi Nakibly [mailto:gnakibly@yahoo.com] =0ASent: Monday, August 17, 2= 009 8:21 AM=0ATo: v6ops=0ACc: ipv6@ietf.org; secdir@ietf.org=0ASubject: Rou= ting loop attacks using IPv6 tunnels=0A=A0=0AHi all,=0AI would like to draw= the attention of the list to=A0some=A0research=A0results which my colleagu= e and I at the National EW Research=A0& Simulation=A0Center have recently p= ublished. The research presents a=A0class of routing loop attacks that abus= es 6to4, ISATAP and Teredo. The=A0paper can be found at: http://www.usenix.= org/events/woot09/tech/full_papers/nakibly.pdf=0A=A0=0AHere is the abstract= :=0AIPv6 is the future network layer protocol for the Internet. Since it is= not compatible with its predecessor, some interoperability mechanisms were= designed. An important category of these mechanisms is automatic tunnels, = which enable IPv6 communication over an IPv4 network without prior configur= ation. This category includes ISATAP, 6to4 and Teredo. We present a novel c= lass of attacks that exploit vulnerabilities in these tunnels. These attack= s take advantage of inconsistencies between a tunnel's overlay IPv6 routing= state and the native IPv6 routing state. The attacks form routing loops wh= ich can be abused as a vehicle for traffic amplification to facilitate DoS = attacks. We exhibit five attacks of this class. One of the presented attack= s can DoS a Teredo server using a single packet. The exploited vulnerabilit= ies are embedded in the design of the tunnels; hence any implementation of = these tunnels may be vulnerable. In particular, the attacks were tested=0Aa= gainst the ISATAP, 6to4 and Teredo implementations of Windows Vista and Win= dows Server 2008 R2. =0A=A0=0AI think the results of the research warrant s= ome corrective action. If this=A0indeed shall be the general sentiment of t= he list, I will be happy write an appropriate I-D. The mitigation measures = we suggested in the paper are the best we could think of to completely elim= inate the problem. However they are far from perfect since=A0they would req= uire=A0tunnel implementations to be updated in case new types of automatic = tunnels are introduced.=0A=A0=0AYour comments are welcome.=0A=A0=0AGabi=0A= =0A=0A From owner-v6ops@ops.ietf.org Mon Aug 24 09:16:53 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3361B28C285 for ; Mon, 24 Aug 2009 09:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uonh+YBxkpu for ; Mon, 24 Aug 2009 09:16:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46CF628C217 for ; Mon, 24 Aug 2009 09:16:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfc9S-000Pl1-2l for v6ops-data0@psg.com; Mon, 24 Aug 2009 16:12:10 +0000 Received: from n13.bullet.mail.mud.yahoo.com ([68.142.206.40]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mfc9I-000PjZ-D0 for v6ops@ops.ietf.org; Mon, 24 Aug 2009 16:12:03 +0000 Received: from [209.191.108.97] by n13.bullet.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 16:11:59 -0000 Received: from [68.142.201.248] by t4.bullet.mud.yahoo.com with NNFMP; 24 Aug 2009 16:11:59 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 16:11:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 446245.17851.bm@omp409.mail.mud.yahoo.com Received: (qmail 57852 invoked by uid 60001); 24 Aug 2009 16:11:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251130318; bh=Z5S+vdzSLcYqgBnb1PXmFH30/JUIE1+UrWKg0MnGidA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XGMFXdLb0zdjmRkJhge7ufZk+kHJlAfd1CZfkTXu5/sexJ7zwJ/h2P/XvbN8iBaB7esRZNS9bkX35IS0OUNAUNWV6hJ7BrnQTEeH/2zF4zX8SAdwBtYO/oliLzhP9X3qm0lKlWxxAsE4h8zGPqQCBloFbMnz+Qw2Gpq373EzKtE= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xTka0r3PHg+JqqX48geadQeDIgLMq8N9xv08QdEargNVWDtIzNu+1+rZcLgoLOpxgWyjIZQZGmjjFqn4K2k/yYwwR39cCMSqGRM6VmhR9e/3mVsciq5rzjZM95PbDusfZzNq2SV7hUMX9YUnZdYUR6gyvCE8lZFwaXr+CW6E1+c=; Message-ID: <852107.57254.qm@web45516.mail.sp1.yahoo.com> X-YMail-OSG: BwdE_vYVM1l_QUwItUxA19HWhxOH2XcfwADSMeBP98NOt9z5vTVug3eSdhkThEsX7o2o0yN8v6nAfjZY.e.HDmnWyEUwLc8J0n24VqIW3tDbg3._jBQdcDBpW.1ELeMAHTQcw8LrtIWYnPVT407.OBZRP5_wbpf.DQPuY4BjYJ4Bz1bgjfN0_qnL8e5jK.c5lEaFaBXE4NUIQvOhUPDyQDKU0xE4kffrku7Ye1BruQN.9Z5x1vg- Received: from [93.172.27.171] by web45516.mail.sp1.yahoo.com via HTTP; Mon, 24 Aug 2009 09:11:58 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> <808598.58470.qm@web45510.mail.sp1.yahoo.com> Date: Mon, 24 Aug 2009 09:11:58 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: v6ops , 6man 6man , secdir@ietf.org, Mark Townsley In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Remi,=0ASee my comments inline ().=0A=0AGabi=0A=0A=0A=0A----- Original = Message ----=0AFrom: R=E9mi Despr=E9s =0ATo: Gabi Nak= ibly =0ACc: v6ops ; 6man 6man ; secdir@ietf.org; Mark Townsley =0ASent: Thu= rsday, August 20, 2009 11:34:49 AM=0ASubject: Re: Routing loop attacks usin= g IPv6 tunnels - the 6rd case=0A=0Agabi,=0A=0AThanks for your quick answer.= =0AFurther remarks in line.=0A=0ALe 19 ao=FBt 09 =E0 12:12, Gabi Nakibly a = =E9crit :=0A=0A> Remi,=0A> See my comments inline ().=0A> Gabi=0A> =0A>= From: R=E9mi Despr=E9s =0A> To: Gabi Nakibly =0A> Cc: v6ops ; 6man 6man = ; secdir@ietf.org; Mark Townsley =0A> Sent: Tuesday, Au= gust 18, 2009 8:00:42 PM=0A> Subject: Re: Routing loop attacks using IPv6 t= unnels - the 6rd case=0A> =0A> Hi Gabi,=0A> =0A> First, thanks to you and y= our colleagues for this research, and for the clear presentation of its res= ults.=0A> In my understanding, your contribution is important for transitio= n solutions to be carefully selected, and where needed improved.=0A> =0A> T= his mail is to complement the analysis with what applies to 6rd.=0A> =0A> F= or those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is an automa= tic tunnel mechanism in actual use for IPv6 across IPv4 clouds.=0A> With it= , service providers can offer native IPv6 to their customers while using fo= r this their existing IPv4 infrastructures.=0A> Publication of the RFC that= describes it, RFC 5569, has been delayed since May for a reason related to= intellectual property rights applicable to independent submissions.=0A> Bu= t the draft on which 6rd is based is still available, and a new draft to ex= tend its applicability is also available:=0A> - tools.ietf.org/html/draft-d= espres-6rd-03=0A> - tools.ietf.org/html/draft-townsley-ipv6-6rd-01=0A> = =0A> I must admit that this is the first time I read the spec of 6rd so for= give me if I miss something.=0A> =0A> =0A> (1) Case of ISPs that opera= te 6rd relays and no 6to4 relays (and neither Teredo relays nor ISP-infrast= ructure NATs)=0A> =0A> In its sec. 3, draft-despres-6rd-03 says:=0A> <<<=0A= >=A0 The IPv4 anycast address of 6rd relays may be chosen independently by= =0A>=A0 each ISP.=A0 The only constraint is that routes toward the ISP that= are=0A>=A0 advertised must not include this address.=0A> >>>=0A> In view o= f your study and in my understanding, it should be completed with:=0A> "Als= o, the ISP must not forward toward the global IPv4 global Internet packets = having this address as source."=0A> =0A> With this, an ISP that operates 6r= d relays but operates neither 6to4 relays nor Teredo relays nor NATs is imm= une to the routing loop attack because:=0A> - An IPv6 packet forwarded to t= he IPv6 Internet by a 6rd relay cannot come back to an IPv4 interface of a = 6rd relay of the same ISP: there is no IPv4 route back to the ISP for its 6= rd anycast address.=0A> - An IPv6 packet received from the IPv6 Internet by= a 6rd relay cannot be sent back to the IPv4 global Internet: the source ad= dress of its IPv4 encapsulating packet is the 6rd anycast address, which pr= events it from reaching the IPv4 global Internet.=0A> =0A> Note that, if in= terfaces of the ISP to the IPv4 global Internet are already subject to ingr= ess filtering (packets received by the global Internet are discarded if the= re is no reverse path available for them), the added sentence is not necess= ary. It is just just a double precaution for cases where such ingress filte= ring doesn't apply.=0A> =0A> I agree with you that above check will wor= k. However, I might choose another way here: the relay must make the follow= ing two checks:=0A> 1) When an IPv6 packet is received from the IPv6 Intern= et the 6rd relay must ensure before encapsulation that the intended IPv4 de= stination address belongs to one of the ISP's clients (I assume it can make= this check easily). This way no IPv6 packet received from the IPv6 Interne= t will be relayed to a 6to4 relay (and then back to the 6rd relay through t= he IPv6 Internet).=0A=0AThe problem is that this check is not easy "in gene= ral" because ISPs typically have their IPv4 prefixes allocated one by one a= s they increase the number of their clients.=0A=0A=0A> 2) When an encapsula= ted packet is received from the IPv4 network side the 6rd relay must check = that the IPv6 destination does not include its own IPv4 address. For exampl= e the IPv6 destination address must not be: 2002:::/48. This will prevent the packet from ever reaching back the 6rd relay = through its IPv4 interface=0A=0AThe problem is that to be general, and as y= ou noted, this test depends on a knowledge of all formats used to embed IPv= 4 addresses in IPv6 addresses. When a new format is introduced, a security = weakness therefore holds until all relays are upgraded to support it.=0ABes= ides, and more important, some formats may use _ISP dependent prefixes_ (an= d 6rd is already in this case!). These formats cannot be recognized by a co= nstant code.=0A=0A=0AThis being noted, I agree that, to extend applicabilit= y of 6rd relays to cases where ingress filtering doesn't apply, and to deal= more simply with the case of 6rd ISPs that also operate 6to4 relays, 6rd r= elays SHOULD do as you propose:=0A*In 6rd relays, packets received on the I= Pv4 side should be discarded if their IPv6 destinations are 6to4 addresses = containing the ISP 6rd anycast address.*=0A=0A=0A> =0A> This way all the ch= ecks are done only at the 6rd relay and not in other IPv4 border routers of= the ISP which should not be aware of the 6rd deployment.=0A=0ANote that IP= v4 border routers of the ISP need not to be aware of the 6rd in particular.= =0AThey only have to make sure that ingress filtering "in general" applies = to packets sent toward the global Internet.=0A(If their downstream neighbor= s do ingress filtering as they should, these border routers have nothing sp= ecific to do. In cases where this isn't sure though, they should better pre= vent source address spoofing by filtering themselves source addresses for w= hich they have no reverse path.)=0A=0A=0A=0A- For packets coming from t= he IPv6 side:=A0if the first check I suggested=A0of the ISP's clients is no= t easy, then you can=A0instead check, as you suggested below,=A0the IPv6 so= urce address of the incoming packet to verify that it is not a 6to4 address= containing the 6rd relay IPv4 address. This can make the check of the sour= ce address in other IPv4 border routers redundant.=0A- For packets coming f= rom the IPv4 side: on second thought, if the 6rd spec already ensures that = there is no IPv4 route from an external 6to4 relay to a 6rd relay, then ind= eed the second check I proposed is redundant. Moreover, I completely agree = that=A0this check=A0can=A0only eliminate=A0routing loops=A0with a 6to4 rela= y and not with=A0relays of other types of tunnels.=A0=0A=A0=0A=0A=0A> = =0A> =0A> =0A> (2) Case of ISPs that operate 6rd relays AND 6to4 relay= s (but neither Teredo relays nor ISP-infrastructure NATs)=0A> =0A> In its s= ec. 5 on security, draft-despres-6rd-03 says:=0A> <<<=0A>=A0 o=A0 RELAY PAC= KETS TOWARD THE INTERNET: The IPv6 source must be a 6rd=0A>=A0 =A0 =A0 addr= ess that matches the IPv4 source.=A0 The IPv6 destination must=0A>=A0 =A0 = =A0 not start with the ISP 6rd prefix.=0A> ...=0A>=A0 o=A0 RELAY PACKETS FR= OM THE INTERNET: The IPv6 source must not be a 6rd=0A>=A0 =A0 =A0 address o= f the ISP.=A0 The IPv4 destination must not be multicast,=0A>=A0 =A0 =A0 i.= e. must not start with 224/3...=0A> >>>=0A> =0A> In view of your study and = in my understanding, it MUST be completed with:=0A> - after the first quote= d paragraph:=0A> "Furthermore, if the ISP also operates 6to4 relays that ad= vertise on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source= must be neither the 6to4 anycast address 192.88.99.0 nor any of its equiva= lent IPv4 unicast addresses."=0A> - after the second quoted paragraph:=0A> = "Furthermore, if the ISP also operates 6to4 relays that advertise on the IP= v6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 destination derived fro= m the IPv6 destination must be neither the IPv4 anycast address 192.88.99.0= nor any of its equivalent IPv4 unicast addresses."=0A> =0A> Actually, = I believe that the precautions I suggested above will work here also instea= d of those checks. Won't they?=0A=0AAs explained above, it would be 100% sa= fe only if all embedded IPv4 addresses were guaranteed to be recognized, wh= ich is not the case.=0A=0A=0A> In general, I think that checks performed on= the destination address (IPv4 or IPv6) should be more robust than checks o= n a source address.=0A=0AIn my understanding, not always.=0AEach scenario h= as to be studied for what it is.=0A=0A> =0A> =0A> With this, an ISP th= at operates both 6rd and 6to4 relays is also immune to the routing-loop att= ack because:=0A> - an IPv6 packet forwarded to the global Internet by 6rd r= elays can come back to the ISP IPv4 network via one of the 6to4 relays of t= he ISP BUT cannot be accepted again by a 6rd relay: its IPv4 source address= is then one of a 6to4 relay, which, with the first added sentence, prevent= s it from being accepted by the 6rd relay.=0A> - an IPv6 packet received fr= om the IPv6 Internet by a 6rd relay cannot be sent back to the IPv4 global = Internet via one of the 6to4 relays: the IPv4 address derived from its IPv6= destination would have for this to be one of a 6to4 relays, which, with th= e second added sentence, prevents it from being forwarded by the 6rd relay.= =0A> =0A> Note: RFC 3068, where the 6to4 anycast address is introduced, say= s that "each 6to4 relay router that advertise the 6to4 anycast prefix MUST = also provide an equivalent IPv4 unicast address". Whether this is really im= portant in practice is IMHO unclear. On the other hand, if this MUST is dis= pensed with, the above security precaution can be implemented in 6rd relays= without a need to handle a variable number of addresses, and to administra= tively configure them (with the associated risks of human errors).=0A> =0A>= =0A> If you do the check on the destination address you can avoid this= administrative configuration altogether.=0A=0AAgreed for packets forwarded= to the IPv6 side (see above).=0A=0ANow, for packets from the IPv6 Internet= , rather than checking that the embedded IPv4 destination has one of the IS= P allocated prefixes, there is a better check I hadn't seen before sending = the previous e-mail:=0A*In 6rd relays, packets received on the IPv6 side sh= ould be discarded if their source addresses are 6to4 addresses containing t= he ISP 6rd anycast address.*=0A=0A=0AI fully agree.=0A<\gn>=0A=0A=A0=0A= The above administrative configuration is thus unnecessary, and the 6rd rel= ay cannot participate in a routing loop attack even if its ISP also operate= s 6to4 relays.=0A=0ANOTE: As a matter of fact, a source address check can a= lso be used to improve the Mitigation Measures you proposed for 6to4, ISATA= P and Teredo relays:=0A*In your three forwarding conditions, it would be su= fficient to add "or source" after each occurrence of "destination".*=0AThus= , each of these relays becomes protected against rooting loop attacks via a= ny other 6to4, ISATAP, and Teredo relay, even if this relay doesn't make th= e new check on destination addresses.=0A=0A=0AYou are right. This can a= dd another layer of security. However,=A0one must note=A0that for this chec= k to work the other relay=A0that participates in the routing loop=A0must=A0= indeed validate before it decapsulates a packet that its IPv4 source addres= s corresponds to=A0its IPv6 source address. If this is not true, then the c= heck of the source address you noted above is useless. I am making this not= e, since I have encountered some implementations of 6to4 and ISATAP that do= es not=A0follow their corresponding spec and do not=A0make this=A0validatio= n, as they should.=A0=0ABut, again, I agree that this check can be used as = another layer of security.=0A=0A=0A=0A> =0A> =0A> To conclude:=0A= > - Without needing to modify 6to4 relays, ISATAP relays, and Teredo relays= , ISPs that support 6rd and don't support 6to4 appear to be already protect= ed against routing loop attacks if ingress filtering is operational at thei= r interfaces to the IPv4 global Internet. With an additional simple precaut= ion in 6rd relays, they can also be immune in the absence of such filtering= ..=0A> =0A> I fully agree.=0A=0AThanks.=0AThoughts on the proposal to im= prove your mitigation measures?=0A=0ARegards,=0ARD=0A=0A> =0A> - A nec= essary additional security precaution against routing-loop attacks is now i= dentified for ISPs that support 6rd and that, having started with 6to4, wis= h to keep it for backward compatibility. Thanks again for your analysis whi= ch made it possible.=0A> =0A> =0A> Best regards,=0A> RD=0A> =0A> =0A> =0A> = Le 17 ao=FBt 09 =E0 17:21, Gabi Nakibly a =E9crit :=0A> =0A> > Hi all,=0A> = > I would like to draw the attention of the list to some research results w= hich my colleague and I at the National EW Research & Simulation Center hav= e recently published. The research presents a class of routing loop attacks= that abuses 6to4, ISATAP and Teredo. The paper can be found at: http://www= ..usenix.org/events/woot09/tech/full_papers/nakibly.pdf=0A> >=0A> > Here is = the abstract:=0A> > IPv6 is the future network layer protocol for the Inter= net. Since it is not compatible with its predecessor, some interoperability= mechanisms were designed. An important category of these mechanisms is aut= omatic tunnels, which enable IPv6 communication over an IPv4 network withou= t prior configuration. This category includes ISATAP, 6to4 and Teredo. We p= resent a novel class of attacks that exploit vulnerabilities in these tunne= ls. These attacks take advantage of inconsistencies between a tunnel's over= lay IPv6 routing state and the native IPv6 routing state. The attacks form = routing loops which can be abused as a vehicle for traffic amplification to= facilitate DoS attacks. We exhibit five attacks of this class. One of the = presented attacks can DoS a Teredo server using a single packet. The exploi= ted vulnerabilities are embedded in the design of the tunnels; hence any im= plementation of these tunnels may be vulnerable. In particular, the attacks= were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vist= a and Windows Server 2008 R2.=0A> >=0A> > I think the results of the resear= ch warrant some corrective action. If this indeed shall be the general sent= iment of the list, I will be happy write an appropriate I-D. The mitigation= measures we suggested in the paper are the best we could think of to compl= etely eliminate the problem. However they are far from perfect since they w= ould require tunnel implementations to be updated in case new types of auto= matic tunnels are introduced.=0A> >=0A> > Your comments are welcome.=0A> >= =0A> > Gabi=0A> >=0A> > ---------------------------------------------------= -----------------=0A> > IETF IPv6 working group mailing list=0A> > ipv6@iet= f.org=0A> > Administrative Requests: https://www.ietf.org/mailman/listinfo/= ipv6=0A> > ----------------------------------------------------------------= ----=0A> =0A> =0A> =0A> =0A> =0A=0A=0A From owner-v6ops@ops.ietf.org Mon Aug 24 11:43:48 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD7F28C2DC for ; Mon, 24 Aug 2009 11:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.741 X-Spam-Level: X-Spam-Status: No, score=-4.741 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 QaK7MzOb38Q0 for ; Mon, 24 Aug 2009 11:43:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 37D103A6AE0 for ; Mon, 24 Aug 2009 11:43:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfeSN-000N1g-Rj for v6ops-data0@psg.com; Mon, 24 Aug 2009 18:39:51 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfeSI-000N11-VD for v6ops@ops.ietf.org; Mon, 24 Aug 2009 18:39:49 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2009 18:33:32 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7OIXW6m017007; Mon, 24 Aug 2009 11:33:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7OIXVvA003396; Mon, 24 Aug 2009 18:33:32 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.3959); Mon, 24 Aug 2009 11:33:32 -0700 Received: from sjc-mbaugher-8717.cisco.com ([10.19.93.40]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 11:33:31 -0700 Cc: james woodyatt , IPv6 Operations Message-Id: From: Mark Baugher To: Mark Smith In-Reply-To: <20090823184516.a8667014.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows Date: Mon, 24 Aug 2009 11:33:31 -0700 References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> <390865C6-3343-4C31-9767-6E0FCA4481DD@suspicious.org> <20090823184516.a8667014.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Aug 2009 18:33:31.0899 (UTC) FILETIME=[61B93CB0:01CA24E9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1328; t=1251138812; x=1252002812; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20draft-ietf-v6ops-cpe-simple-security=3A =20filtering=20encapsulated=20flows |Sender:=20; bh=TP0xfKVwwzuUwaHyevsDFMmZjtehoRVelmGyw9NGrQ8=; b=I3bMiBJnOWOG1C6iroUlkLQt0tpYGn2ldGKnIdUIYEnxDRzHVElSblC7hk U2sJ3Q+javHpqNTaKCLuYd9k09pn4HJhOtrs9ufaYP/48asWVEPr98/lhaUb ML5aUEA1fKzPwni18UETIKJQ8codxOBKsNQm/DwIm1yayUs1+LxsA=; Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The node that accepts the IKE phase 1 presumably has some acl or credential requirement to control access - or could have. I thought that this was the idea behind the original recommendation. Mark On 23/08/2009, at 2:15 AM, Mark Smith wrote: > On Sat, 22 Aug 2009 22:33:37 -0700 > james woodyatt wrote: > >> On Aug 22, 2009, at 21:58, Truman Boyes wrote: >>> >>> This is quite confusing from an implementation perspective; security >>> is not explicitly increased by prohibiting non-encrypted tunnels but >>> allowing encrypted (ESP or AH) traffic flows. Wouldn't this simply >>> serve as a driver to make all tunnel encapsulations use ESP/AH? >> >> Yes. I'm not sure I can explain how this is supposed to increase >> security, but if consensus in the working group emerges around these >> recommendations and the draft can proceed through working group last >> call, then that's good enough for me. >> > > Maybe I haven't fully understood the question, however isn't the > answer > as simple as the benefits of IPsec over cleartext? Even the > better-than-nothing-mode of IPsec, while vulnerable to > man-in-the-middle attacks during session setup, has a much smaller > window of opportunity for exploitation over clear text traffic. > > Regards, > Mark. > > > > From owner-v6ops@ops.ietf.org Mon Aug 24 12:01:15 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8693928C342 for ; Mon, 24 Aug 2009 12:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.479 X-Spam-Level: X-Spam-Status: No, score=-104.479 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 uh8Uzd7Tl8xT for ; Mon, 24 Aug 2009 12:01:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 577D43A6E88 for ; Mon, 24 Aug 2009 12:00:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfelJ-000PeP-Um for v6ops-data0@psg.com; Mon, 24 Aug 2009 18:59:25 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfelG-000Pdy-CR for v6ops@ops.ietf.org; Mon, 24 Aug 2009 18:59:23 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id CB8B76F41186 for ; Mon, 24 Aug 2009 11:59:21 -0700 (PDT) X-AuditID: 11807130-b7ca1ae00000654a-8b-4a92e309d3fe Received: from il0602a-dhcp117.apple.com (il0602a-dhcp117.apple.com [17.206.23.245]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id F6.36.25930.903E29A4; Mon, 24 Aug 2009 11:59:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1075.2) Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows From: james woodyatt In-Reply-To: Date: Mon, 24 Aug 2009 11:59:21 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> <390865C6-3343-4C31-9767-6E0FCA4481DD@suspicious.org> <20090823184516.a8667014.ipng@69706e6720323030352d30312d31340a.nosense.org> To: IPv6 Operations X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 24, 2009, at 11:33, Mark Baugher wrote: > The node that accepts the IKE phase 1 presumably has some acl or > credential requirement to control access - or could have. I thought > that this was the idea behind the original recommendation. I'm always getting confused about whether we're presuming that the interior node is well secured or that the interior node has some hypothetical vulnerability that can be remotely exploited to obtain access to the rest of the interior network. I'm often making the wrong assumption in the wrong context, and I suspect I just don't have sufficient network security expertise to know which assumption to make in what scenario. Hence, my tendency to defer to the people with more credible claims to such expertise. Let them take the heat for mistakes of that category. That's what they get paid to do. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Mon Aug 24 13:09:47 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DA828C355 for ; Mon, 24 Aug 2009 13:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 1fGZ66JA598m for ; Mon, 24 Aug 2009 13:09:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 096513A67E7 for ; Mon, 24 Aug 2009 13:09:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mffmh-0009I8-IY for v6ops-data0@psg.com; Mon, 24 Aug 2009 20:04:55 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mffmb-0009H4-Cs for v6ops@ops.ietf.org; Mon, 24 Aug 2009 20:04:52 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7OK4bpE010056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2009 13:04:38 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7OK4bvn018369; Mon, 24 Aug 2009 15:04:37 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7OK4ZZJ018294; Mon, 24 Aug 2009 15:04:37 -0500 (CDT) 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.3959); Mon, 24 Aug 2009 13:04:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Routing loop attacks using IPv6 tunnels Date: Mon, 24 Aug 2009 13:04:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <475898.88672.qm@web45510.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcoksCuqHixy6VRJRM+9z8CEAFFcGAAKv6pg References: <475898.88672.qm@web45510.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" Cc: , X-OriginalArrivalTime: 24 Aug 2009 20:04:36.0496 (UTC) FILETIME=[1AE09100:01CA24F6] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Monday, August 24, 2009 4:44 AM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Fred, > I=A0initially very much=A0liked your suggestion regarding the = check=A0of the neighbor cache before > forwarding a packet into the tunnel.=A0It truly addresses the root = cause of the problem ans is simple > enough to implement. However, I realized that an attacker can send a = spoofed=A0RS to the ISATAP router > as if it came from the 6to4 relay. The router would then send=A0a = RA=A0to it=A0and consequently change its > neighbor cache. So it seems=A0that this defense does not add = much.=A0Wouldn't you agree? I agree that my proposed mitigation is only useful when there is assurance of a coherent neighbor cache in the ISATAP router. That would be true in the case in which the ISATAP router is located within a site protected by border routers that perform ip-proto-41 and ingress filtering, and in which there is no untraceable IPv4 source address spoofing. So AFAICT, my proposed mitigation is still necessary for preventing attack #3 when ISATAP routers A and B are on separate ISATAP links within the same site-internal IPv4 routing region. > I completely agree with your observation on the non-feasibility of = verifying=A0that the > destination=A0ISATAP address does not include=A0a local=A0IPv4 = address=A0since the ISATAP address may include > a private IPv4 address. On the other hand, a check on public IPv4 = addresses is acceptable.=A0If the > check would be done only on ISATAP addresses that include public IPv4 = addresses then this will > eliminate the attacks in which the two victims reside=A0at different = sites. Note that if attack #3=A0is > launched on two ISATAP routers=A0having private addresses at two = different sites then the attack will > not work anyway since one router can not send a direct=A0IPv4 packet = to the other. In addition, > to=A0mitigate attacks in which the other victim is a 6to4 relay (such = as attack #1) then a check would > have to be done on a 6to4 address, i.e. the destination address must = not be "2002: the ISATAP router>::*". In this case the IPv4 address must be public, = according to > the 6to4 spec. >=20 > As you also noted there is another problem with this check since the = string "200::5EFE" is not unique > to ISATAP links. On the other hand, it seems that the probability to = encounter a non-malicious packet > with a destination address having an IID that equals "200:5EFE:" is > pretty slim. >=20 > This check is definitely not a=A0perfect solution, and I sure hope = that someone will come up with a > better one for mitigating the routing loops. However, I would be happy = if there is some kind of other > mitigation=A0measures besides packet filtering=A0(proto-41 and = ingress) by=A0other nodes (which=A0does not > necessarily exist). You seem to be envisioning a scenario of ISATAP router operation with public IPv4 addresses and outside of any site border routers that perform ingress filtering and ip-proto-41 filtering. That has traditionally been seen as the domain of 6to4, but I am happy to discuss the possibility of what I called the "inside-out ISATAP model" in a list message long ago (which AFAICT is the scenario you are alluding to). So, if the public IPv4 Internet were considered as one gigantic "site" and we wanted to do ISATAP on that site, it would be nice to divide the site into multiple logical partitions, with each partition identified by a PRL name and a unique set of IPv6 prefixes. But then, we have the scenario you are describing in which we can't trust the integrity of the ISATAP router's neighbor cache due to the possibility for untraceable IPv4 source address spoofing such that the neighbor cache check mitigation can be subverted. This means that if we want to support the inside-out ISATAP model then the routing loops could be mitigated either by 1) implementing the destination address checks you are suggesting, or 2) by not allowing ISATAP router interfaces that are not behind filtering border routers to advertise non-link-local on-link IPv6 prefixes and/or forward packets from non-link-local prefixes in the first place. If we took the easy way out and did 2), then the entire IPv4 Internet would look like one gigantic ISATAP link that only did IPv6 link-local. So, nodes could ping6 each others' ISATAP link-local addresses but that's about it.=20 If we took the more ambitious route and allowed ISATAP to flourish fully within the global IPv4 Internet, then we would essentially be deprecating 6to4 - so it isn't surprising that your address checks mostly involve 6to4 suppression. Assuming this, if I read your attack scenarios 1 through 3 correctly then scenarios 1 and 3 are mitigated by a receive-side check and scenario 2 is mitigated by a send-side check. In particular, the pseudo-code would be: isatap_rcv() { ... if (dst =3D=3D "2002:::*") drop_pkt(); /* attack #1 mitigation */ if (dst =3D=3D "*::0200:5efe:") drop_pkt(); /* attack #3 mitigation */ ... } isatap_xmt() { ... if (dst =3D=3D "*::0200:5efe:192.88.99.1") drop_pkt(); /* attack #2 mitigation */ ... } Does the above look right to you? And is this everything, or are there other scenarios we need to consider? Thanks - Fred fred.l.templin@boeing.com >=20 > Gabi >=20 > ----- Original Message ---- > From: "Templin, Fred L" > To: Gabi Nakibly ; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Sent: Wednesday, August 19, 2009 6:16:18 PM > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 > Hi Gabi, >=20 > I'm sorry to have to keep turning this into plaintext, > but annotation is difficult otherwise. See below for > my responses (=3D=3D>): >=20 > ________________________________________ > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Wednesday, August 19, 2009 1:49 AM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Fred, > See my comments inline (). >=20 > ________________________________________ > From: "Templin, Fred L" > To: Gabi Nakibly ; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Sent: Tuesday, August 18, 2009 6:48:45 PM > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 > Gabi, >=20 > ________________________________________ > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Tuesday, August 18, 2009 3:29 AM > To: Templin, Fred L; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > Indeed the ISATAP interface of the ISATAP router is meant > > to be an enterprise-interior (note that=A0it is still=A0assumed > > that the associated IPv4 address is=A0non-private). As=A0we > > explicitly note in the paper, the first three attacks=A0will > > be mitigated=A0if proper protocol-41 filtering is deployed on > > the site's border. However, note that RFC5214 does not mandate > > or require this filtering. >=20 > The RFC5214 Security Considerations makes clear the > consequences of not implementing IPv4 ingress filtering > and ip-protocol-41 filtering (i.e., a possible spooing > attack in which spurious ip-protocol-41 packets are > injected into an ISATAP link from outside). RFC5214 > Section 6.2 additionally requires that an ISATAP interface's > locator set MUST NOT span multiple sites. This means that the > ISATAP interface must not decapsulate nor source ip-proto-41 > packets within multiple sites, where the enterprise interior > is site #1 and the global Internet is site #2. ip-protocol-41 > filtering is the way in which the ISATAP interface is > restricted to a single site. > > Now let me see that I understand Section 6.2 correctly. In > attack #2, for example, I assume the ISATAP router has two > physical interfaces. A site-internal IPv4 interface with an > address IPisatap and a site-external IPv6 interface. I also > assume that there=A0is another border router which connects the > site to the IPv4 Internet.=A0The ISATAP router has an ISATAP > interface with a single locator: (IPisatap, site-internal > interface).=A0When the ISATAP router gets an IPv6 via its > external interface it will encapsulate the packet accordingly > and forward it through the internal IPv4 interface. If the > encapsulated packet is=A0destined to a node outside the site > then the only thing that stops it is=A0a proto-41 filtering > at the=A0other border router of the site. Did I get this right? > >=20 > =3D=3D> In this case, yes - the ip-proto-41 filtering is at a > =3D=3D> border router. I know of at least one major enterprise > =3D=3D> network that does this. >=20 > > It is only mentioned as a possible mitigation against > > incoming spurious protocol-41 packets. In addition, > > Section 10 of RFC5214 only mentions=A0ingress not=A0egress > > filtering.=A0Hence it=A0will not stop attack #2. >=20 > We are now talking about ip-proto-41 filtering; not ingress > filtering. ip-proto-41 filtering is in both directions. It > prevents ip-proto-41 packets from entering the enterprise > interior ISATAP site from the Internet and prevents > ip-proto-41 packets from entering the Internet ISATAP > site from the enterprise interior. Else the ISATAP > interface would span multiple sites. >=20 > Besides, "ingress" filtering is not about packets coming > from the Internet into the end site, but rather it is > about packets leaving the end site and going out into > the Internet. RFC2827 (BCP38) documents ingress filtering. > > OK. I see what you are saying here. > >=20 > =3D=3D> OK. >=20 > > In addition, > > as mentioned, protocol-41 filtering is not helpful when > > attack #3 is launched on two routers that reside in the > > same site. Note that=A0it=A0may be=A0possible for=A0the attack > > packet=A0to be sourced from outside the site unless proper > > filtering of incoming IPv6 packets is deployed. If the > > attacker resides in the site, usually ingress filtering > > will not be helpful since it is deployed in general on > > the site's border. >=20 > Here, we have the ISATAP router in both cases sourcing a > packet from a foreign prefix. > > Well, I do not see how this is correct. In attacks #1 and #3 the = ISATAP router sources (actually > forwards) an IPv6=A0packet with=A0a source address having=A0the = corresponding=A0prefix of the ISATAP tunnel. > In attacks #2 and #3 the ISATAP router sources and IPv4 packet with = its own IPv4 address as the > source address. > >=20 > =3D=3D> There were a number of errors in what I said in my last > =3D=3D> message, so let me see if I can get it right here: > =3D=3D> > =3D=3D> In attacks #1 and #2 there are two cases to consider. Case > =3D=3D> 1 in which a border router separates the 6to4 relay from the > =3D=3D> ISATAP router, and case 2 in which no border router separates > =3D=3D> the 6to4 relay from the ISATAP router. > =3D=3D> > =3D=3D> In attack #1, we have an IPv6 packet with a local source > =3D=3D> address entering the site from the outside. IPv6 ingress > =3D=3D> filtering at the site border router should prevent the > =3D=3D> packet from entering the site in the first place. If the > =3D=3D> 6to4 relay router is outside the site then ip-proto-41 > =3D=3D> filtering at the border router will block the attack in > =3D=3D> the first place anyway. If the relay router is *inside* > =3D=3D> the site, then the IPv6 ingress filtering is the lone > =3D=3D> mitigation. The end result is that the 6to4 relay should > =3D=3D> really be positioned outside of the site's border routers; > =3D=3D> otherwise, it could be spoofed into thinking that the > =3D=3D> ISATAP router is a 6to4 router and not an ISATAP router. > =3D=3D> > =3D=3D> In attack #2, we have an IPv6 packet with a foreign source > =3D=3D> address being forwarded by the ISATAP router to a 6to4 > =3D=3D> relay, but I mis-spoke when I said that this would be a > =3D=3D> case of the ISATAP router forwarding a packet with a foreign > =3D=3D> source address out of the ISATAP link. For all the ISATAP > =3D=3D> router knows, the 6to4 relay is just an ordinary host on > =3D=3D> the ISATAP link, so the ISATAP router actually believes it > =3D=3D> is forwarding the packet *into* the ISATAP link (not out of > =3D=3D> it). But as in attack #1, the attack is blocked by ip-proto-41 > =3D=3D> filtering at the border router between the ISATAP router and > =3D=3D> the 6to4 relay. If there is no border router between the = ISATAP > =3D=3D> router and the 6to4 relay, then we have an identical instance > =3D=3D> to attack #3 which I will discuss below. But, the best > =3D=3D> operational practice would again be to have the 6to4 relay > =3D=3D> oriented outside of a border router that filters ip-proto-41. > =3D=3D> > =3D=3D> Short summary is that in attack #1, the 6to4 relay thinks it > =3D=3D> is talking to a 6to4 router and not an ISATAP router. In > =3D=3D> attack #2, the ISATAP router thinks it is talking to a > =3D=3D> simple host on the link and not a 6to4 relay. In both cases, > =3D=3D> the attacks are mitigated when there is an ip-proto-41 > =3D=3D> filtering border router between the ISATAP router and the > =3D=3D> 6to4 relay. Oftentimes, the "border router" will be a two- > =3D=3D> interface router that implements 6to4 on a site-external > =3D=3D> IPv4 interface and implements ISATAP on a site-internal > =3D=3D> IPv4 interface and performs ip-proto-41 filtering on packets > =3D=3D> from outside the site with an IPv4 destination corresponding > =3D=3D> to the ISATAP interface. I will discuss attack #3 below: >=20 > This attack is mitigated by > IPv6 ingress filtering which is an IPv6 security consideration > and not an ISATAP nor IPv4 security consideration. BCP > recommendations for network ingress filtering are documented > in RFC2827 and it is expected that IPv6 routers that configure > ISATAP interfaces will implement IPv6 ingress filtering > according to the BCP. > > So If my last comment is correct than I do not see how ingress = filtering would help here. The only > case where=A0ingress filtering can help is in case of attack #3 when = the routers reside at the same > site. In that case if the attack packet (packet 0) is sent from = outside the site then ingress > filtering on the border of the site will drop the packet. > >=20 > =3D=3D> Correct about the IPv6 ingress filtering at the border, > =3D=3D> but as with attack #2 my error in the previous message > =3D=3D> was in thinking the ISATAP router A was forwarding the > =3D=3D> packet *out* of the ISATAP link when in fact from the > =3D=3D> ISATAP router's perspective it is forwarding the packet > =3D=3D> to a simple host *inside* of the link. > =3D=3D> > =3D=3D> The problem here is that the ISATAP router is blindly > =3D=3D> forwarding a packet to a node that it assumes is a simple > =3D=3D> host on the ISATAP link without first verifying that the > =3D=3D> node has demonstrated a willingness to participate as a > =3D=3D> host on the link. As you have pointed out, this can lead > =3D=3D> to strange scenarios when the anonymous node is a tunnel > =3D=3D> router of some sort that does not participate in the > =3D=3D> ISATAP link. > =3D=3D> > =3D=3D> It would not generally be possible for the ISATAP router > =3D=3D> to check whether the IPv6 destination address is an ISATAP > =3D=3D> address that embeds one of its own IPv4 addresses, because > =3D=3D> when IPv4 private addresses are used the same IPv4 address > =3D=3D> can (and often does) occur in multiple sites. So for example, > =3D=3D> if the ISATAP router configures an IPv4 address 10.0.0.1 > =3D=3D> and is asked to forward an IPv6 packet with ISATAP > =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where the > =3D=3D> IPv6 prefix is foreign, the router can't very well drop the > =3D=3D> packet as this would block legitimate communications. It > =3D=3D> is also not generally possible to check whether a foreign > =3D=3D> link is an ISATAP link by looking for the magic token > =3D=3D> "0:5EFE" as that token only has significance for ISATAP > =3D=3D> links and not other link types. > =3D=3D> > =3D=3D> Instead, the mitigation I think makes the most sense is > =3D=3D> for the ISATAP router to first verify that the node which > =3D=3D> it assumes to be a simple ISATAP host has demonstrated a > =3D=3D> willingness to participate in the link. That can be done > =3D=3D> by having the ISATAP router first check the neighbor cache > =3D=3D> when it has a packet to send to verify that there is a > =3D=3D> cached entry corresponding to the destination. For nodes > =3D=3D> that are willing ISATAP hosts on the link, there would > =3D=3D> have been a neighbor cache entry created when the node > =3D=3D> sends a Router Solicitation to the ISATAP router for the > =3D=3D> purpose of discovering default router lifetimes and on- > =3D=3D> link prefixes. So, the simple mitigations is for the ISATAP > =3D=3D> router to forward the packet only if there is a pre-existing > =3D=3D> neighbor cache entry and drop the packet otherwise. This > =3D=3D> implies that the router should keep neighbor cache entires > =3D=3D> for the duration of the minimum lifetime of the prefixes > =3D=3D> it advertises in its Router Advertisements. >=20 > > In general, I would like to point out that indeed as in > > most other attacks these attacks may also be mitigated by > > proper firewall rules. However, I do not believe that this > > should be our only answer against these attacks. I believe > > that since these attacks are made possible due to the > > inherent characteristics of the tunnels they=A0should be > > stopped intrinsically as much as possible by the tunnel > > participants and not relay on outside filtering rules. >=20 > In RFC5214, Section 10 we have: "restricting access to the > link can be achieved by restricting access to the site". The > mitigations do exactly that, and in such a way that ISATAP > nodes can operate with only the necessary and sufficient > checks. So on this point, I do not share your opinion. > > What about two ISATAP tunnels that reside on the same site like in = attack #3. Do you=A0also think that > proto-41 filtering should barrier between the two tunnels within the = site? > >=20 > =3D=3D> I think this may be overcome by the discussion above. > =3D=3D> Short story is that operational practices must be > =3D=3D> employed whereby an ISATAP router is not mistaken for > =3D=3D> a 6to4 router. This is through proper arrangement of > =3D=3D> 6to4 router/relay interfaces outside of the site border > =3D=3D> rather than inside, and ISATAP router interfaces inside > =3D=3D> of the site border rather than outside. Also proper > =3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at > =3D=3D> site borders. > =3D=3D> > =3D=3D> Also, when there are multiple ISATAP links within the > =3D=3D> same local IPv4 routing region, an ISATAP router should > =3D=3D> first verify a node's willingness to act as a host on > =3D=3D> the ISATAP link before blindly sending a packet to it. > =3D=3D> > =3D=3D> Fred > =3D=3D> fred.l.templin@boeing.com >=20 > Fred > fred.l.templin@boeing.com >=20 > ________________________________________ > From: "Templin, Fred L" > To: Gabi Nakibly ; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Sent: Monday, August 17, 2009 8:35:08 PM > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 >=20 > Gabi, >=20 > Thanks for publishing this work. In the document, attacks A, B and C > correspond to a configuration that violates section 6.2 of RFC5214: >=20 > > 6.2.=A0 ISATAP Interface Address Configuration > > > > =A0=A0Each ISATAP interface configures a set of locators consisting = of IPv4 > >=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP > >=A0=A0 interface's locator set MUST NOT span multiple sites. >=20 > In particular, in scenarios A, B and C the IPv4 locator used for = ISATAP > is seen both within the enterprise as site #1 and within the global = Internet > itself as site #2. If the ISATAP interface is to be used as an = enterprise- > interior interface, it should therefore not accept IP-proto-41 packets > coming from an IPv4 source outside of the enterprise nor source > IP-proto-41 packets that are destined to an IPv4 node outside of the > enterprise. This condition should be satisfied by having the site = border > routers implement IPv4 ingress filtering and ip-protocol-41 filtering = as > required in Section 10 of RFC5214. >=20 > It is mentioned that attack C could also occur when the routers reside > in the same site, where their addresses may be private. This would > correspond to a case in which an attacker within the site attacks the > site itself, which can easily be traced - especially when source = address > spoofing from a node within the site is prevented through proper = ingress > filtering. >=20 > Fred > fred.l.templin@boeing.com >=20 > ________________________________________ > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Monday, August 17, 2009 8:21 AM > To: v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Routing loop attacks using IPv6 tunnels >=20 > Hi all, > I would like to draw the attention of the list = to=A0some=A0research=A0results which my colleague and I at > the National EW Research=A0& Simulation=A0Center have recently = published. The research presents a=A0class > of routing loop attacks that abuses 6to4, ISATAP and Teredo. = The=A0paper can be found at: > http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf >=20 > Here is the abstract: > IPv6 is the future network layer protocol for the Internet. Since it = is not compatible with its > predecessor, some interoperability mechanisms were designed. An = important category of these > mechanisms is automatic tunnels, which enable IPv6 communication over = an IPv4 network without prior > configuration. This category includes ISATAP, 6to4 and Teredo. We = present a novel class of attacks > that exploit vulnerabilities in these tunnels. These attacks take = advantage of inconsistencies > between a tunnel's overlay IPv6 routing state and the native IPv6 = routing state. The attacks form > routing loops which can be abused as a vehicle for traffic = amplification to facilitate DoS attacks. > We exhibit five attacks of this class. One of the presented attacks = can DoS a Teredo server using a > single packet. The exploited vulnerabilities are embedded in the = design of the tunnels; hence any > implementation of these tunnels may be vulnerable. In particular, the = attacks were tested > against the ISATAP, 6to4 and Teredo implementations of Windows Vista = and Windows Server 2008 R2. >=20 > I think the results of the research warrant some corrective action. If = this=A0indeed shall be the > general sentiment of the list, I will be happy write an appropriate = I-D. The mitigation measures we > suggested in the paper are the best we could think of to completely = eliminate the problem. However > they are far from perfect since=A0they would require=A0tunnel = implementations to be updated in case new > types of automatic tunnels are introduced. >=20 > Your comments are welcome. >=20 > Gabi >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Aug 24 13:55:31 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E67328C22D for ; Mon, 24 Aug 2009 13:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 cnmStBHErbfU for ; Mon, 24 Aug 2009 13:55:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A63113A6EA7 for ; Mon, 24 Aug 2009 13:55:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfgXS-000IWg-W2 for v6ops-data0@psg.com; Mon, 24 Aug 2009 20:53:14 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfgXP-000IW5-DU for v6ops@ops.ietf.org; Mon, 24 Aug 2009 20:53:13 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7OKr6D2007877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2009 13:53:06 -0700 (PDT) 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 n7OKr6bd005336; Mon, 24 Aug 2009 13:53:06 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7OKr5xV005279; Mon, 24 Aug 2009 13:53:06 -0700 (PDT) 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.3959); Mon, 24 Aug 2009 13:53:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Routing loop attacks using IPv6 tunnels Date: Mon, 24 Aug 2009 13:53:00 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcoksCuqHixy6VRJRM+9z8CEAFFcGAAKv6pgAAhXLcA= References: <475898.88672.qm@web45510.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" Cc: , X-OriginalArrivalTime: 24 Aug 2009 20:53:02.0615 (UTC) FILETIME=[DF0F2270:01CA24FC] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Slight correction: > if (dst =3D=3D "*::0200:5efe:") > drop_pkt(); /* attack #3 mitigation */ should be: if (dst =3D=3D "::0200:5efe:") drop_pkt(); /* attack #3 mitigation */ Fred fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Mon Aug 24 14:39:30 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD9B3A6ECD for ; Mon, 24 Aug 2009 14:39:30 -0700 (PDT) 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=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, 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 Z60gA8kkKGhW for ; Mon, 24 Aug 2009 14:39:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D18E33A6EDC for ; Mon, 24 Aug 2009 14:39:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfhDL-000PD0-S9 for v6ops-data0@psg.com; Mon, 24 Aug 2009 21:36:31 +0000 Received: from [202.136.110.253] (helo=smtp1.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfhDH-000PCW-Pj for v6ops@ops.ietf.org; Mon, 24 Aug 2009 21:36:29 +0000 Received: from 114-30-113-149.ip.adam.com.au ([114.30.113.149] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1MfhDD-0006Rv-2A; Tue, 25 Aug 2009 07:06:23 +0930 Received: from opy.nosense.org (localhost.localdomain [127.0.0.1]) by opy.nosense.org (Postfix) with SMTP id 454BA49298; Tue, 25 Aug 2009 07:06:22 +0930 (CST) Date: Tue, 25 Aug 2009 07:06:22 +0930 From: Mark Smith To: james woodyatt Cc: IPv6 Operations Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows Message-Id: <20090825070622.8a808d97.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <805241AA-DC9A-4498-9D54-8D491DD62A0D@apple.com> <2D21500B-207B-43FB-9728-8A7BCEC82CB1@apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120B3E6@il-ex01.ad.checkpoint.com> <47CF65DB-E3E1-4666-B1E9-51A49B372AD5@apple.com> <390865C6-3343-4C31-9767-6E0FCA4481DD@suspicious.org> <20090823184516.a8667014.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi James, On Mon, 24 Aug 2009 11:59:21 -0700 james woodyatt wrote: > On Aug 24, 2009, at 11:33, Mark Baugher wrote: > > > The node that accepts the IKE phase 1 presumably has some acl or > > credential requirement to control access - or could have. I thought > > that this was the idea behind the original recommendation. > > I'm always getting confused about whether we're presuming that the > interior node is well secured or that the interior node has some > hypothetical vulnerability that can be remotely exploited to obtain > access to the rest of the interior network. I'm often making the > wrong assumption in the wrong context, and I suspect I just don't have > sufficient network security expertise to know which assumption to make > in what scenario. > I'm assuming a well secured interior node. When exploits are discovered in good VoIP handset vendors' devices, and they fix them, rather than saying "these devices shouldn't be plugged into the Internet", then I think any device / OS, from a good vendor, which has the more common possibility of being plugged into the Internet than a VoIP handset, can also be assumed to be well secured by default (if the end user switches it off, that's their problem). I think vendors are going to have to accept that once they give a device the possibility of being connected to the Internet, there'll be somebody who will (and possibly lots of people, if a different but related use emerges). The only safe choice for a vendor is secured by default. > Hence, my tendency to defer to the people with more credible claims to > such expertise. Let them take the heat for mistakes of that > category. That's what they get paid to do. > > > -- > james woodyatt > member of technical staff, communications engineering > > > From owner-v6ops@ops.ietf.org Tue Aug 25 04:56:54 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5603B3A6B6C for ; Tue, 25 Aug 2009 04:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgYkjm4I0jxx for ; Tue, 25 Aug 2009 04:56:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E3F53A6802 for ; Tue, 25 Aug 2009 04:56:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfuYP-0004AL-TZ for v6ops-data0@psg.com; Tue, 25 Aug 2009 11:51:09 +0000 Received: from [2001:7b8:200:2202:230:48ff:fe29:44a6] (helo=betonmix.noc.ams-ix.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfuYK-00049R-HW for v6ops@ops.ietf.org; Tue, 25 Aug 2009 11:51:07 +0000 Received: from localhost (localhost [127.0.0.1]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id E2C4F1027AF for ; Tue, 25 Aug 2009 13:51:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from betonmix.noc.ams-ix.net ([127.0.0.1]) by localhost (betonmix.noc.ams-ix.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nCcp5ZB40nUN for ; Tue, 25 Aug 2009 13:51:02 +0200 (CEST) Received: from fizzix (miraculix.noc.ams-ix.net [IPv6:2001:7b8:200:120::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id B1ED51027AE for ; Tue, 25 Aug 2009 13:51:02 +0200 (CEST) Date: Tue, 25 Aug 2009 13:50:28 +0200 From: Martin Pels To: v6ops@ops.ietf.org Subject: Re: comments on draft-ietf-v6ops-v6inixp-01.txt Message-ID: <20090825135028.08f2b1a9@fizzix> In-Reply-To: <4A81634A.2010301@inex.ie> References: <4A6EE42A.7020809@inex.ie> <4A702AFD.6040803@inex.ie> <20090730175043.14100900@fizzix> <4A81634A.2010301@inex.ie> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 11 Aug 2009 13:25:46 +0100 Nick Hilliard wrote: > On 30/07/2009 16:50, Martin Pels wrote: > > We've had a couple of students research this. > > Sounds interesting. Are the results of this work publicly available? > http://staff.science.uva.nl/~delaat/sne-2008-2009/p23/report.pdf Kind regards, Martin From m7g@1.is Tue Aug 25 07:25:16 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4693A6906 for ; Tue, 25 Aug 2009 07:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.39 X-Spam-Level: X-Spam-Status: No, score=-19.39 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_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, 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_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf3OfXN7cp6o for ; Tue, 25 Aug 2009 07:25:16 -0700 (PDT) Received: from 4-172-235-201.fibertel.com.ar (4-172-235-201.fibertel.com.ar [201.235.172.4]) by core3.amsl.com (Postfix) with SMTP id 570C03A659C for ; Tue, 25 Aug 2009 07:25:14 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090825142515.570C03A659C@core3.amsl.com> Date: Tue, 25 Aug 2009 07:25:14 -0700 (PDT) Show picture and go to site now! From stiffenedh816@irgold.net Tue Aug 25 09:40:32 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91D128C2BC; Tue, 25 Aug 2009 09:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.166 X-Spam-Level: X-Spam-Status: No, score=-44.166 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, FS_WILL_HELP=2.749, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X91OU1VfU8eS; Tue, 25 Aug 2009 09:40:32 -0700 (PDT) Received: from ip-88-153-207-114.unitymediagroup.de (ip-88-153-207-114.unitymediagroup.de [88.153.207.114]) by core3.amsl.com (Postfix) with ESMTP id 8819F28C29A; Tue, 25 Aug 2009 09:40:31 -0700 (PDT) Received: from 88.153.207.114 by mail.irgold.net with smtp QO61R9167; Tue, 25 Aug 2009 18:39:26 +0100 Message-ID: <000d01ca25a2$9c3cf250$6400a8c0@stiffenedh816> From: Adelle Perez To: Subject: They say that fruits like this will help us live to 100 years, what do you think? Date: Tue, 25 Aug 2009 18:39:26 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA25A2.9C3CF250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA25A2.9C3CF250 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Make a change in your life today, click and see to find out more, try it fr= ee!   My new friends told me about this miracle magic, I ordered lol.. =A0 Get inside ------=_NextPart_000_0007_01CA25A2.9C3CF250 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Make a change in your life today, click and see to f= ind out more, try it free!
 
My new friends told me about this miracle ma= gic, I ordered lol..
=A0
Get inside
------=_NextPart_000_0007_01CA25A2.9C3CF250-- From vpim-bounces@ietf.org Tue Aug 25 09:40:35 2009 Return-Path: X-Original-To: v6ops-archive@ietf.org Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF3028C370 for ; Tue, 25 Aug 2009 09:40:35 -0700 (PDT) Subject: The results of your email commands From: vpim-bounces@ietf.org To: v6ops-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1730042930==" Message-ID: Date: Tue, 25 Aug 2009 09:40:33 -0700 Precedence: bulk X-BeenThere: vpim@ietf.org X-Mailman-Version: 2.1.9 List-Id: Voice Profile for Internet Mail Discussion Archive X-List-Administrivia: yes Sender: vpim-bounces@ietf.org Errors-To: vpim-bounces@ietf.org --===============1730042930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: ee!   My new friends told me about this miracle magic, I ordered lol.. =A0 Get inside - Done. --===============1730042930== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: vpim-request@core3.amsl.com Delivered-To: vpim-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91D128C2BC; Tue, 25 Aug 2009 09:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.166 X-Spam-Level: X-Spam-Status: No, score=-44.166 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, FS_WILL_HELP=2.749, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X91OU1VfU8eS; Tue, 25 Aug 2009 09:40:32 -0700 (PDT) Received: from ip-88-153-207-114.unitymediagroup.de (ip-88-153-207-114.unitymediagroup.de [88.153.207.114]) by core3.amsl.com (Postfix) with ESMTP id 8819F28C29A; Tue, 25 Aug 2009 09:40:31 -0700 (PDT) Received: from 88.153.207.114 by mail.irgold.net with smtp QO61R9167; Tue, 25 Aug 2009 18:39:26 +0100 Message-ID: <000d01ca25a2$9c3cf250$6400a8c0@stiffenedh816> From: Adelle Perez To: Subject: They say that fruits like this will help us live to 100 years, what do you think? Date: Tue, 25 Aug 2009 18:39:26 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA25A2.9C3CF250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA25A2.9C3CF250 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Make a change in your life today, click and see to find out more, try it fr= ee!   My new friends told me about this miracle magic, I ordered lol.. =A0 Get inside ------=_NextPart_000_0007_01CA25A2.9C3CF250 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Make a change in your life today, click and see to f= ind out more, try it free!
 
My new friends told me about this miracle ma= gic, I ordered lol..
=A0
Get inside
------=_NextPart_000_0007_01CA25A2.9C3CF250-- --===============1730042930==-- From mcleod@abcmortgage.com Tue Aug 25 20:58:18 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6483A6B57 for ; Tue, 25 Aug 2009 20:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.751 X-Spam-Level: X-Spam-Status: No, score=-9.751 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, 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, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7-yDor1R9re for ; Tue, 25 Aug 2009 20:58:17 -0700 (PDT) Received: from cpe-68-172-249-249.nj.res.rr.com (cpe-68-172-249-249.nj.res.rr.com [68.172.249.249]) by core3.amsl.com (Postfix) with SMTP id DCCB13A6B2B for ; Tue, 25 Aug 2009 20:57:45 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090826035746.DCCB13A6B2B@core3.amsl.com> Date: Tue, 25 Aug 2009 20:57:45 -0700 (PDT) Show picture and go to site now! From elegiesi1@mtsthelensglass.com Tue Aug 25 22:07:25 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6360D3A7043; Tue, 25 Aug 2009 22:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.825 X-Spam-Level: X-Spam-Status: No, score=-31.825 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_ADLTSUB2=1.23, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30B0EOJqqRh5; Tue, 25 Aug 2009 22:07:24 -0700 (PDT) Received: from 190-121-65-240.bk26-dsl.surnet.cl (190-121-65-240.bk26-dsl.surnet.cl [190.121.65.240]) by core3.amsl.com (Postfix) with ESMTP id 7CFF73A7049; Tue, 25 Aug 2009 22:07:24 -0700 (PDT) Received: from 190.121.65.240 by mx2.balanced.spunky.mail.dreamhost.com; Wed, 26 Aug 2009 02:07:28 -0300 From: urlreg-archive@ietf.org To: urlreg-archive@ietf.org Subject: your free trial for a skinny tight body Date: Wed, 26 Aug 2009 02:07:28 -0300 Message-ID: MIME-version: 1.0 Content-type: text/html; charset="utf-8"
Improve your life, visit your future body today!, try it free
 
The ACAl is one of the world's most interesting and unique foods. It may also be one of its healthiest. Chock-full of antioxidants, amino acids, AND essential fatty acids, the tiny little ACAl Berry packs a nutritional wallop rarely seen in the natural world. In fact, some experts consider it to be the world's most "complete" natural food.
From owner-v6ops@ops.ietf.org Fri Aug 28 09:29:05 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7043A6784 for ; Fri, 28 Aug 2009 09:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 jI0+xdaGau9z for ; Fri, 28 Aug 2009 09:29:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E1FA3A7154 for ; Fri, 28 Aug 2009 09:28:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh4ET-000Mvq-6J for v6ops-data0@psg.com; Fri, 28 Aug 2009 16:23:21 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh4EP-000Muq-82 for v6ops@ops.ietf.org; Fri, 28 Aug 2009 16:23:19 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7SGNDxX025191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2009 09:23:13 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7SGNCeL017183; Fri, 28 Aug 2009 11:23:12 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7SGN6ew016973; Fri, 28 Aug 2009 11:23:12 -0500 (CDT) 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.3959); Fri, 28 Aug 2009 09:23:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Routing loop attacks using IPv6 tunnels Date: Fri, 28 Aug 2009 09:23:03 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcoksCuqHixy6VRJRM+9z8CEAFFcGAAKv6pgAAhXLcAAv7YZEA== References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" Cc: , X-OriginalArrivalTime: 28 Aug 2009 16:23:06.0629 (UTC) FILETIME=[D326CB50:01CA27FB] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gabi, Correct me if I am wrong, but if there were a new version of ISATAP that did not use ip-proto-41 encapsulation but instead used a different kind of encapsulation, then it need not concern itself with routing loop interactions with 6to4 relays since 6to4 relays only know about ip-proto-41. Does that match your understanding?=20 Thanks - Fred fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Fri Aug 28 11:35:47 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38BAE3A682E for ; Fri, 28 Aug 2009 11:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 D+5XxFUwjmkx for ; Fri, 28 Aug 2009 11:35:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27B0A3A6802 for ; Fri, 28 Aug 2009 11:35:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6Er-0008LU-GX for v6ops-data0@psg.com; Fri, 28 Aug 2009 18:31:53 +0000 Received: from [2001:13c7:7001:4000::3] (helo=mail.lacnic.net.uy) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6Em-0008J9-2e for v6ops@ops.ietf.org; Fri, 28 Aug 2009 18:31:50 +0000 Received: from [IPv6:2001:13c7:7001:5128:225:ff:fe4b:94a8] (unknown [IPv6:2001:13c7:7001:5128:225:ff:fe4b:94a8]) by mail.lacnic.net.uy (Postfix) with ESMTP id 3882F3084F3; Fri, 28 Aug 2009 15:31:43 -0300 (UYT) Cc: v6ops WG Message-Id: From: Roque Gagliano To: Martin Pels In-Reply-To: <20090825135028.08f2b1a9@fizzix> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: comments on draft-ietf-v6ops-v6inixp-01.txt Date: Fri, 28 Aug 2009 15:31:42 -0300 References: <4A6EE42A.7020809@inex.ie> <4A702AFD.6040803@inex.ie> <20090730175043.14100900@fizzix> <4A81634A.2010301@inex.ie> <20090825135028.08f2b1a9@fizzix> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 martin, this is excellent material, not only for the IXP document but also on =20= how ND is handled in practice. referring to the next version of the document, I was thinking in add =20 the following comment when I talk about solicited-node multicast =20 addresses: solicited-node multicast groups. "Depending on the addressing plan selected by the IXP, each solocited-=20= node multicast group may be shared by a sub-set of participants' =20 caused by how the last three octects of the addresses are selected. =20 In example 1 in Section 3, only participants with ASNs with the same =20= two last digits are going to share the same solocited-node multicast =20 group." However, your test show that it may not make a difference in router =20 resources consumption, depending on implementations. what do you think? Roque. On Aug 25, 2009, at 8:50 AM, Martin Pels wrote: > On Tue, 11 Aug 2009 13:25:46 +0100 > Nick Hilliard wrote: > >> On 30/07/2009 16:50, Martin Pels wrote: >>> We've had a couple of students research this. >> >> Sounds interesting. Are the results of this work publicly available? >> > > http://staff.science.uva.nl/~delaat/sne-2008-2009/p23/report.pdf > > Kind regards, > Martin - ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkqYIo4ACgkQnk+WSgHpbO7UyACfeu9fHz4loGDOGjjXVO1EJwuK Sq8AniiUP6UTKvR1vk9Iwdm7NPTWl+17 =3DPSj1 -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Fri Aug 28 12:06:14 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEAE3A71A5 for ; Fri, 28 Aug 2009 12:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, J_CHICKENPOX_13=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 T3lPGQtI3A1T for ; Fri, 28 Aug 2009 12:06:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 094093A71B0 for ; Fri, 28 Aug 2009 12:04:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6iN-000JD5-Qb for v6ops-data0@psg.com; Fri, 28 Aug 2009 19:02:23 +0000 Received: from web45503.mail.sp1.yahoo.com ([68.180.197.71]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6iG-000JBC-50 for v6ops@ops.ietf.org; Fri, 28 Aug 2009 19:02:19 +0000 Received: (qmail 27272 invoked by uid 60001); 28 Aug 2009 19:02:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251486135; bh=1rWX6Ca2vyI34/6hckZmzscZXLqhYMhK1M9hGa9EkCc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XxbgmzTAHKDDo72y1ls0UlSIB3baN74mwAEycMqKmANdeWGWJMrX5H9vG/6JQF1KazWtYAJCXEfeTODSDkkIGoR6SNd82bg6YtA6QwvVqQjnGBrAwPZE011jTJsMRGjgzORfAnmq/eUG9lXriPwvqX+Sth1mL/lhMbiCRTj/uEQ= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2mFoFaAGGoF25aNACEsW+AnHlymvWqCuQGNTAEEfH+C7GaiSLO24F7VLI6YwZ3VYIshw3w5kfnGfiUzYwGSVib5mQgQpTarI82ntDGdGow7cYhU993zrLtJFSlxZWZAH43uj6KNKBB25PB8Vqe4/CV8IJMGS4H6T8MSJiEl4PMY=; Message-ID: <31484.26522.qm@web45503.mail.sp1.yahoo.com> X-YMail-OSG: CDAsN4sVM1kTTvXTgBHqq7Z2wFNUjk8VQxgQHHWi_tcmAnJIrjN7fZtNrNsE2cXdyZwSlBL2wU08RYdAQPNQYPM38cauY5ebgxB4XzLKHIN6bJEhD6Q26L0ico8FF9Iz7vV9hCoUW5k0379fS.UJq.Rsd4q9Y93iUghJLT1TJNtJ1pXhn984eYSgmG55cQ44RyhXcRbzdv61xlTngNacRpOuZlh86KCKmJU9ymqwHnmPEAzLhNfTpN6lWgnPq5pbNISIBY1_ Received: from [89.138.8.21] by web45503.mail.sp1.yahoo.com via HTTP; Fri, 28 Aug 2009 12:02:14 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 Date: Fri, 28 Aug 2009 12:02:14 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" , v6ops Cc: ipv6@ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred,=0AA quick summary of our discussion up until now: the best mitigation= of=A0most of these=A0attacks is indeed the proto-41 and ingress filtering = on the border of the ISATAP site. If it is indeed implemented. I=A0assume t= hat not all sites deploy such filtering for lack of awareness or since the = proto-41 filtering may break other tunnels the site may employ. However, I = do not have hard evidence on this. I would be happy if others on the list w= ill refute or justify this assumption.=0A=A0=0AIf this assumption is (even = partially) correct than I think that the ISATAP router should defend itself= . Moreover, as I mention below the proo-41 filtering is not effective in ca= se of attack #3=A0and=A0the attacker is internal to the site. So IMHO the b= est way is the mitigations I suggested and that you illustrated below in ps= eudo-code.=0A=A0=0ASee=A0further comments inline.=0A=A0=0AGabi=0A=0A----- O= riginal Message ----=0A> From: "Templin, Fred L" =0A> To: Gabi Nakibly ; v6ops =0A>= Cc: ipv6@ietf.org; secdir@ietf.org=0A> Sent: Monday, August 24, 2009 10:04= :34 PM=0A> Subject: RE: Routing loop attacks using IPv6 tunnels=0A> =0A> Ga= bi,=0A> =0A> > -----Original Message-----=0A> > From: Gabi Nakibly [mailto:= gnakibly@yahoo.com]=0A> > Sent: Monday, August 24, 2009 4:44 AM=0A> > To: T= emplin, Fred L; v6ops=0A> > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > Subjec= t: Re: Routing loop attacks using IPv6 tunnels=0A> > =0A> > Fred,=0A> > I= =A0initially very much=A0liked your suggestion regarding the check=A0of the= =0A> neighbor cache before=0A> > forwarding a packet into the tunnel.=A0It= truly addresses the root cause of the =0A> problem ans is simple=0A> > eno= ugh to implement. However, I realized that an attacker can send a =0A> spoo= fed=A0RS to the ISATAP router=0A> > as if it came from the 6to4 relay. The = router would then send=A0a RA=A0to it=A0and =0A> consequently change its=0A= > > neighbor cache. So it seems=A0that this defense does not add much.=A0Wo= uldn't you =0A> agree?=0A> =0A> I agree that my proposed mitigation is only= useful when there=0A> is assurance of a coherent neighbor cache in the ISA= TAP router.=0A> That would be true in the case in which the ISATAP router i= s=0A> located within a site protected by border routers that perform=0A> ip= -proto-41 and ingress filtering, and in which there is no=0A> untraceable I= Pv4 source address spoofing. So AFAICT, my proposed=0A> mitigation is still= necessary for preventing attack #3 when=0A> ISATAP routers A and B are on = separate ISATAP links within=0A> the same site-internal IPv4 routing region= .=0A> =0A=0AThis is only true when the attacker is outside the site and pro= to-41 filtering is employed. If the attacker is internal to the site then t= he proto-41 filtering will not help and the neighbor cache can be poisoned.= =0A=0A> > I completely agree with your observation on the non-feasibility o= f =0A> verifying=A0that the=0A> > destination=A0ISATAP address does not inc= lude=A0a local=A0IPv4 address=A0since the =0A> ISATAP address may include= =0A> > a private IPv4 address. On the other hand, a check on public IPv4 ad= dresses is =0A> acceptable.=A0If the=0A> > check would be done only on ISAT= AP addresses that include public IPv4 =0A> addresses then this will=0A> > e= liminate the attacks in which the two victims reside=A0at different sites. = Note =0A> that if attack #3=A0is=0A> > launched on two ISATAP routers=A0hav= ing private addresses at two different sites =0A> then the attack will=0A> = > not work anyway since one router can not send a direct=A0IPv4 packet to t= he =0A> other. In addition,=0A> > to=A0mitigate attacks in which the other = victim is a 6to4 relay (such as attack =0A> #1) then a check would=0A> > ha= ve to be done on a 6to4 address, i.e. the destination address must not be = =0A> "2002:> > the ISATAP router>::*". In this case the IPv4 address must b= e public, =0A> according to=0A> >=A0 the 6to4 spec.=0A> > =0A> > As you als= o noted there is another problem with this check since the string =0A> "200= ::5EFE" is not unique=0A> > to ISATAP links. On the other hand, it seems th= at the probability to encounter =0A> a non-malicious packet=0A> > with a de= stination address having an IID that equals "200:5EFE:> IPv4 address>" is= =0A> > pretty slim.=0A> > =0A> > This check is definitely not a=A0perfect s= olution, and I sure hope that someone =0A> will come up with a=0A> > better= one for mitigating the routing loops. However, I would be happy if =0A> th= ere is some kind of other=0A> > mitigation=A0measures besides packet filter= ing=A0(proto-41 and ingress) by=A0other =0A> nodes (which=A0does not=0A> > = necessarily exist).=0A> =0A> You seem to be envisioning a scenario of ISATA= P router operation=0A> with public IPv4 addresses and outside of any site b= order routers=0A> that perform ingress filtering and ip-proto-41 filtering.= That has=0A> traditionally been seen as the domain of 6to4, but I am happy= to=0A> discuss the possibility of what I called the "inside-out ISATAP=0A>= model" in a list message long ago (which AFAICT is the scenario=0A> you ar= e alluding to).=0A> =0A=0AWell,=A0I am referring to any=A0ISATAP deployment= =A0with public IPv4 addresses and no proto-41 filtering. I imagine that in = practice there are such deployments which are not the "inside-out ISATAP mo= del"=A0. However, I must admit that I do not rely here on hard evidence.=0A= =0A> So, if the public IPv4 Internet were considered as one gigantic=0A> "s= ite" and we wanted to do ISATAP on that site, it would be nice=0A> to divid= e the site into multiple logical partitions, with each=0A> partition identi= fied by a PRL name and a unique set of IPv6=0A> prefixes. But then, we have= the scenario you are describing in=0A> which we can't trust the integrity = of the ISATAP router's=0A> neighbor cache due to the possibility for untrac= eable IPv4=0A> source address spoofing such that the neighbor cache check= =0A> mitigation can be subverted.=0A> =0A> This means that if we want to su= pport the inside-out ISATAP=0A> model then the routing loops could be mitig= ated either by=0A> 1) implementing the destination address checks you are= =0A> suggesting, or 2) by not allowing ISATAP router interfaces=0A> that ar= e not behind filtering border routers to advertise=0A> non-link-local on-li= nk IPv6 prefixes and/or forward packets=0A> from non-link-local prefixes in= the first place.=0A> =0A> If we took the easy way out and did 2), then the= entire=0A> IPv4 Internet would look like one gigantic ISATAP link that=0A>= only did IPv6 link-local. So, nodes could ping6 each others'=0A> ISATAP li= nk-local addresses but that's about it. =0A> =0A> If we took the more ambit= ious route and allowed ISATAP to=0A> flourish fully within the global IPv4 = Internet, then we=0A> would essentially be deprecating 6to4 - so it isn't= =0A> surprising that your address checks mostly involve 6to4=0A> suppressio= n. Assuming this, if I read your attack scenarios=0A> 1 through 3 correctly= then scenarios 1 and 3 are mitigated=0A> by a receive-side check and scena= rio 2 is mitigated by a=0A> send-side check. In particular, the pseudo-code= would be:=0A> =0A> =A0 isatap_rcv() {=0A> =A0 =A0 ...=0A> =A0 =A0 if (dst = =3D=3D "2002:::*")=0A> =A0 =A0 =A0 drop_pkt(); /* attack #1 m= itigation */=0A> =0A> =A0 =A0 if (dst =3D=3D "*::0200:5efe:")= =0A> =A0=A0=A0 drop_pkt(); /* attack #3 mitigation */=0A> =A0 =A0 ...=0A> = =A0 }=0A> =0A=A0=0ACorrect (with the correction you sent after this email).= =0A=0A> =A0 isatap_xmt() {=0A> =A0 =A0 ...=0A> =A0 =A0 if (dst =3D=3D "*::0= 200:5efe:192.88.99.1")=0A> =A0 =A0 =A0 drop_pkt(); /* attack #2 mitigation = */=0A> =A0 =A0 ...=0A> =A0 }=0A=A0=0AThis will not necessarily work, since = the 6to4 relay may have a=A0unicast address the ISATAP router may not be aw= are of. The best way to mitigate attack #2 is=A0by the 6to4 relay with a ch= eck similar to that of attack #2 above. IMO, the second best way, as Remi s= uggested on another thread, is for the ISATAP router to drop the packet if = (src=A0 =3D=3D 2002:::*"). However, this check is useful only= when the 6to4 relay validates that the IPv6 source address corresponds to = the IPv4 one (this is in=A0accordance=A0with the 6to4 spec, however it does= not always get implemented). If this is not true then the attacker does no= t have to send the attack packet with such an address.=0A=A0=0A> =0A> Does = the above look right to you? And is this everything,=0A> or are there other= scenarios we need to consider?=0A>=A0=0A=0A=0A> Thanks - Fred=0A> fred.l.t= emplin@boeing.com=0A> =0A> > =0A> > Gabi=0A> > =0A> > ----- Original Messag= e ----=0A> > From: "Templin, Fred L" =0A> > To: Gabi Nakibly ; v6ops =0A> >= Cc: ipv6@ietf.org; secdir@ietf.org=0A> > Sent: Wednesday, August 19, 2009 = 6:16:18 PM=0A> > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> >= =0A> > Hi Gabi,=0A> > =0A> > I'm sorry to have to keep turning this into p= laintext,=0A> > but annotation is difficult otherwise. See below for=0A> > = my responses (=3D=3D>):=0A> > =0A> > ______________________________________= __=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > Sent: Wednesd= ay, August 19, 2009 1:49 AM=0A> > To: Templin, Fred L; v6ops=0A> > Cc: ipv6= @ietf.org; secdir@ietf.org=0A> > Subject: Re: Routing loop attacks using IP= v6 tunnels=0A> > =0A> > Fred,=0A> > See my comments inline ().=0A> > =0A> >= ________________________________________=0A> > From: "Templin, Fred L" =0A= > > To: Gabi Nakibly ; v6ops =0A> > Cc: ipv6@ietf.org; secdir@ietf.org=0A> = > Sent: Tuesday, August 18, 2009 6:48:45 PM=0A> > Subject: RE: Routing loop= attacks using IPv6 tunnels=0A> > =0A> > Gabi,=0A> > =0A> > _______________= _________________________=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.c= om]=0A> > Sent: Tuesday, August 18, 2009 3:29 AM=0A> > To: Templin, Fred L;= v6ops=0A> > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > Subject: Re: Rout= ing loop attacks using IPv6 tunnels=0A> > >=0A> > > Indeed the ISATAP inter= face of the ISATAP router is meant=0A> > > to be an enterprise-interior (no= te that=A0it is still=A0assumed=0A> > > that the associated IPv4 address is= =A0non-private). As=A0we=0A> > > explicitly note in the paper, the first th= ree attacks=A0will=0A> > > be mitigated=A0if proper protocol-41 filtering i= s deployed on=0A> > > the site's border. However, note that RFC5214 does no= t mandate=0A> > > or require this filtering.=0A> > =0A> > The RFC5214 Secur= ity Considerations makes clear the=0A> > consequences of not implementing I= Pv4 ingress filtering=0A> > and ip-protocol-41 filtering (i.e., a possible = spooing=0A> > attack in which spurious ip-protocol-41 packets are=0A> > inj= ected into an ISATAP link from outside). RFC5214=0A> > Section 6.2 addition= ally requires that an ISATAP interface's=0A> > locator set MUST NOT span mu= ltiple sites. This means that the=0A> > ISATAP interface must not decapsula= te nor source ip-proto-41=0A> > packets within multiple sites, where the en= terprise interior=0A> > is site #1 and the global Internet is site #2. ip-p= rotocol-41=0A> > filtering is the way in which the ISATAP interface is=0A> = > restricted to a single site.=0A> > =0A> > Now let me see that I understan= d Section 6.2 correctly. In=0A> > attack #2, for example, I assume the ISAT= AP router has two=0A> > physical interfaces. A site-internal IPv4 interface= with an=0A> > address IPisatap and a site-external IPv6 interface. I also= =0A> > assume that there=A0is another border router which connects the=0A> = > site to the IPv4 Internet.=A0The ISATAP router has an ISATAP=0A> > interf= ace with a single locator: (IPisatap, site-internal=0A> > interface).=A0Whe= n the ISATAP router gets an IPv6 via its=0A> > external interface it will e= ncapsulate the packet accordingly=0A> > and forward it through the internal= IPv4 interface. If the=0A> > encapsulated packet is=A0destined to a node o= utside the site=0A> > then the only thing that stops it is=A0a proto-41 fil= tering=0A> > at the=A0other border router of the site. Did I get this right= ?=0A> > =0A> > =0A> > =3D=3D> In this case, yes - the ip-proto-41 filtering= is at a=0A> > =3D=3D> border router. I know of at least one major enterpri= se=0A> > =3D=3D> network that does this.=0A> > =0A> > > It is only mentione= d as a possible mitigation against=0A> > > incoming spurious protocol-41 pa= ckets. In addition,=0A> > > Section 10 of RFC5214 only mentions=A0ingress n= ot=A0egress=0A> > > filtering.=A0Hence it=A0will not stop attack #2.=0A> > = =0A> > We are now talking about ip-proto-41 filtering; not ingress=0A> > fi= ltering. ip-proto-41 filtering is in both directions. It=0A> > prevents ip-= proto-41 packets from entering the enterprise=0A> > interior ISATAP site fr= om the Internet and prevents=0A> > ip-proto-41 packets from entering the In= ternet ISATAP=0A> > site from the enterprise interior. Else the ISATAP=0A> = > interface would span multiple sites.=0A> > =0A> > Besides, "ingress" filt= ering is not about packets coming=0A> > from the Internet into the end site= , but rather it is=0A> > about packets leaving the end site and going out i= nto=0A> > the Internet. RFC2827 (BCP38) documents ingress filtering.=0A> > = =0A> > OK. I see what you are saying here.=0A> > =0A> > =0A> > =3D=3D> OK.= =0A> > =0A> > > In addition,=0A> > > as mentioned, protocol-41 filtering is= not helpful when=0A> > > attack #3 is launched on two routers that reside = in the=0A> > > same site. Note that=A0it=A0may be=A0possible for=A0the atta= ck=0A> > > packet=A0to be sourced from outside the site unless proper=0A> >= > filtering of incoming IPv6 packets is deployed. If the=0A> > > attacker = resides in the site, usually ingress filtering=0A> > > will not be helpful = since it is deployed in general on=0A> > > the site's border.=0A> > =0A> > = Here, we have the ISATAP router in both cases sourcing a=0A> > packet from = a foreign prefix.=0A> > =0A> > Well, I do not see how this is correct. In a= ttacks #1 and #3 the ISATAP router =0A> sources (actually=0A> > forwards) a= n IPv6=A0packet with=A0a source address having=A0the corresponding=A0prefix= =0A> of the ISATAP tunnel.=0A> > In attacks #2 and #3 the ISATAP router so= urces and IPv4 packet with its own =0A> IPv4 address as the=0A> > source ad= dress.=0A> > =0A> > =0A> > =3D=3D> There were a number of errors in what I = said in my last=0A> > =3D=3D> message, so let me see if I can get it right = here:=0A> > =3D=3D>=0A> > =3D=3D> In attacks #1 and #2 there are two cases = to consider. Case=0A> > =3D=3D> 1 in which a border router separates the 6t= o4 relay from the=0A> > =3D=3D> ISATAP router, and case 2 in which no borde= r router separates=0A> > =3D=3D> the 6to4 relay from the ISATAP router.=0A>= > =3D=3D>=0A> > =3D=3D> In attack #1, we have an IPv6 packet with a local = source=0A> > =3D=3D> address entering the site from the outside. IPv6 ingre= ss=0A> > =3D=3D> filtering at the site border router should prevent the=0A>= > =3D=3D> packet from entering the site in the first place. If the=0A> > = =3D=3D> 6to4 relay router is outside the site then ip-proto-41=0A> > =3D=3D= > filtering at the border router will block the attack in=0A> > =3D=3D> the= first place anyway. If the relay router is *inside*=0A> > =3D=3D> the site= , then the IPv6 ingress filtering is the lone=0A> > =3D=3D> mitigation. The= end result is that the 6to4 relay should=0A> > =3D=3D> really be positione= d outside of the site's border routers;=0A> > =3D=3D> otherwise, it could b= e spoofed into thinking that the=0A> > =3D=3D> ISATAP router is a 6to4 rout= er and not an ISATAP router.=0A> > =3D=3D>=0A> > =3D=3D> In attack #2, we h= ave an IPv6 packet with a foreign source=0A> > =3D=3D> address being forwar= ded by the ISATAP router to a 6to4=0A> > =3D=3D> relay, but I mis-spoke whe= n I said that this would be a=0A> > =3D=3D> case of the ISATAP router forwa= rding a packet with a foreign=0A> > =3D=3D> source address out of the ISATA= P link. For all the ISATAP=0A> > =3D=3D> router knows, the 6to4 relay is ju= st an ordinary host on=0A> > =3D=3D> the ISATAP link, so the ISATAP router = actually believes it=0A> > =3D=3D> is forwarding the packet *into* the ISAT= AP link (not out of=0A> > =3D=3D> it). But as in attack #1, the attack is b= locked by ip-proto-41=0A> > =3D=3D> filtering at the border router between = the ISATAP router and=0A> > =3D=3D> the 6to4 relay. If there is no border r= outer between the ISATAP=0A> > =3D=3D> router and the 6to4 relay, then we h= ave an identical instance=0A> > =3D=3D> to attack #3 which I will discuss b= elow. But, the best=0A> > =3D=3D> operational practice would again be to ha= ve the 6to4 relay=0A> > =3D=3D> oriented outside of a border router that fi= lters ip-proto-41.=0A> > =3D=3D>=0A> > =3D=3D> Short summary is that in att= ack #1, the 6to4 relay thinks it=0A> > =3D=3D> is talking to a 6to4 router = and not an ISATAP router. In=0A> > =3D=3D> attack #2, the ISATAP router thi= nks it is talking to a=0A> > =3D=3D> simple host on the link and not a 6to4= relay. In both cases,=0A> > =3D=3D> the attacks are mitigated when there i= s an ip-proto-41=0A> > =3D=3D> filtering border router between the ISATAP r= outer and the=0A> > =3D=3D> 6to4 relay. Oftentimes, the "border router" wil= l be a two-=0A> > =3D=3D> interface router that implements 6to4 on a site-e= xternal=0A> > =3D=3D> IPv4 interface and implements ISATAP on a site-intern= al=0A> > =3D=3D> IPv4 interface and performs ip-proto-41 filtering on packe= ts=0A> > =3D=3D> from outside the site with an IPv4 destination correspondi= ng=0A> > =3D=3D> to the ISATAP interface. I will discuss attack #3 below:= =0A> > =0A> > This attack is mitigated by=0A> > IPv6 ingress filtering whic= h is an IPv6 security consideration=0A> > and not an ISATAP nor IPv4 securi= ty consideration. BCP=0A> > recommendations for network ingress filtering a= re documented=0A> > in RFC2827 and it is expected that IPv6 routers that co= nfigure=0A> > ISATAP interfaces will implement IPv6 ingress filtering=0A> >= according to the BCP.=0A> > =0A> > So If my last comment is correct than I= do not see how ingress filtering would =0A> help here. The only=0A> > case= where=A0ingress filtering can help is in case of attack #3 when the router= s =0A> reside at the same=0A> > site. In that case if the attack packet (pa= cket 0) is sent from outside the =0A> site then ingress=0A> > filtering on = the border of the site will drop the packet.=0A> > =0A> > =0A> > =3D=3D> Co= rrect about the IPv6 ingress filtering at the border,=0A> > =3D=3D> but as = with attack #2 my error in the previous message=0A> > =3D=3D> was in thinki= ng the ISATAP router A was forwarding the=0A> > =3D=3D> packet *out* of the= ISATAP link when in fact from the=0A> > =3D=3D> ISATAP router's perspectiv= e it is forwarding the packet=0A> > =3D=3D> to a simple host *inside* of th= e link.=0A> > =3D=3D>=0A> > =3D=3D> The problem here is that the ISATAP rou= ter is blindly=0A> > =3D=3D> forwarding a packet to a node that it assumes = is a simple=0A> > =3D=3D> host on the ISATAP link without first verifying t= hat the=0A> > =3D=3D> node has demonstrated a willingness to participate as= a=0A> > =3D=3D> host on the link. As you have pointed out, this can lead= =0A> > =3D=3D> to strange scenarios when the anonymous node is a tunnel=0A>= > =3D=3D> router of some sort that does not participate in the=0A> > =3D= =3D> ISATAP link.=0A> > =3D=3D>=0A> > =3D=3D> It would not generally be pos= sible for the ISATAP router=0A> > =3D=3D> to check whether the IPv6 destina= tion address is an ISATAP=0A> > =3D=3D> address that embeds one of its own = IPv4 addresses, because=0A> > =3D=3D> when IPv4 private addresses are used = the same IPv4 address=0A> > =3D=3D> can (and often does) occur in multiple = sites. So for example,=0A> > =3D=3D> if the ISATAP router configures an IPv= 4 address 10.0.0.1=0A> > =3D=3D> and is asked to forward an IPv6 packet wit= h ISATAP=0A> > =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where = the=0A> > =3D=3D> IPv6 prefix is foreign, the router can't very well drop t= he=0A> > =3D=3D> packet as this would block legitimate communications. It= =0A> > =3D=3D> is also not generally possible to check whether a foreign=0A= > > =3D=3D> link is an ISATAP link by looking for the magic token=0A> > =3D= =3D> "0:5EFE" as that token only has significance for ISATAP=0A> > =3D=3D> = links and not other link types.=0A> > =3D=3D>=0A> > =3D=3D> Instead, the mi= tigation I think makes the most sense is=0A> > =3D=3D> for the ISATAP route= r to first verify that the node which=0A> > =3D=3D> it assumes to be a simp= le ISATAP host has demonstrated a=0A> > =3D=3D> willingness to participate = in the link. That can be done=0A> > =3D=3D> by having the ISATAP router fir= st check the neighbor cache=0A> > =3D=3D> when it has a packet to send to v= erify that there is a=0A> > =3D=3D> cached entry corresponding to the desti= nation. For nodes=0A> > =3D=3D> that are willing ISATAP hosts on the link, = there would=0A> > =3D=3D> have been a neighbor cache entry created when the= node=0A> > =3D=3D> sends a Router Solicitation to the ISATAP router for th= e=0A> > =3D=3D> purpose of discovering default router lifetimes and on-=0A>= > =3D=3D> link prefixes. So, the simple mitigations is for the ISATAP=0A> = > =3D=3D> router to forward the packet only if there is a pre-existing=0A> = > =3D=3D> neighbor cache entry and drop the packet otherwise. This=0A> > = =3D=3D> implies that the router should keep neighbor cache entires=0A> > = =3D=3D> for the duration of the minimum lifetime of the prefixes=0A> > =3D= =3D> it advertises in its Router Advertisements.=0A> > =0A> > > In general,= I would like to point out that indeed as in=0A> > > most other attacks the= se attacks may also be mitigated by=0A> > > proper firewall rules. However,= I do not believe that this=0A> > > should be our only answer against these= attacks. I believe=0A> > > that since these attacks are made possible due = to the=0A> > > inherent characteristics of the tunnels they=A0should be=0A>= > > stopped intrinsically as much as possible by the tunnel=0A> > > partic= ipants and not relay on outside filtering rules.=0A> > =0A> > In RFC5214, S= ection 10 we have: "restricting access to the=0A> > link can be achieved by= restricting access to the site". The=0A> > mitigations do exactly that, an= d in such a way that ISATAP=0A> > nodes can operate with only the necessary= and sufficient=0A> > checks. So on this point, I do not share your opinion= .=0A> > =0A> > What about two ISATAP tunnels that reside on the same site l= ike in attack #3. =0A> Do you=A0also think that=0A> > proto-41 filtering sh= ould barrier between the two tunnels within the site?=0A> > =0A> > =0A> > = =3D=3D> I think this may be overcome by the discussion above.=0A> > =3D=3D>= Short story is that operational practices must be=0A> > =3D=3D> employed w= hereby an ISATAP router is not mistaken for=0A> > =3D=3D> a 6to4 router. Th= is is through proper arrangement of=0A> > =3D=3D> 6to4 router/relay interfa= ces outside of the site border=0A> > =3D=3D> rather than inside, and ISATAP= router interfaces inside=0A> > =3D=3D> of the site border rather than outs= ide. Also proper=0A> > =3D=3D> ip-proto-41 filtering and IPv6 ingress filte= ring at=0A> > =3D=3D> site borders.=0A> > =3D=3D>=0A> > =3D=3D> Also, when = there are multiple ISATAP links within the=0A> > =3D=3D> same local IPv4 ro= uting region, an ISATAP router should=0A> > =3D=3D> first verify a node's w= illingness to act as a host on=0A> > =3D=3D> the ISATAP link before blindly= sending a packet to it.=0A> > =3D=3D>=0A> > =3D=3D> Fred=0A> > =3D=3D> fre= d.l.templin@boeing.com=0A> > =0A> > Fred=0A> > fred.l.templin@boeing.com=0A= > > =0A> > ________________________________________=0A> > From: "Templin, F= red L" =0A> > To: Gabi Nakibly ; v6ops =0A> > Cc: ipv6@ietf.org; secdir@iet= f.org=0A> > Sent: Monday, August 17, 2009 8:35:08 PM=0A> > Subject: RE: Rou= ting loop attacks using IPv6 tunnels=0A> > =0A> > =0A> > Gabi,=0A> > =0A> >= Thanks for publishing this work. In the document, attacks A, B and C=0A> >= correspond to a configuration that violates section 6.2 of RFC5214:=0A> > = =0A> > > 6.2.=A0 ISATAP Interface Address Configuration=0A> > >=0A> > > =A0= =A0Each ISATAP interface configures a set of locators consisting of IPv4=0A= > > >=A0=A0 address-to-interface mappings from a single site; i.e., an ISAT= AP=0A> > >=A0=A0 interface's locator set MUST NOT span multiple sites.=0A> = > =0A> > In particular, in scenarios A, B and C the IPv4 locator used for I= SATAP=0A> > is seen both within the enterprise as site #1 and within the gl= obal Internet=0A> > itself as site #2. If the ISATAP interface is to be use= d as an enterprise-=0A> > interior interface, it should therefore not accep= t IP-proto-41 packets=0A> > coming from an IPv4 source outside of the enter= prise nor source=0A> > IP-proto-41 packets that are destined to an IPv4 nod= e outside of the=0A> > enterprise. This condition should be satisfied by ha= ving the site border=0A> > routers implement IPv4 ingress filtering and ip-= protocol-41 filtering as=0A> > required in Section 10 of RFC5214.=0A> > =0A= > > It is mentioned that attack C could also occur when the routers reside= =0A> > in the same site, where their addresses may be private. This would= =0A> > correspond to a case in which an attacker within the site attacks th= e=0A> > site itself, which can easily be traced - especially when source ad= dress=0A> > spoofing from a node within the site is prevented through prope= r ingress=0A> > filtering.=0A> > =0A> > Fred=0A> > fred.l.templin@boeing.co= m=0A> > =0A> > ________________________________________=0A> > From: Gabi Na= kibly [mailto:gnakibly@yahoo.com]=0A> > Sent: Monday, August 17, 2009 8:21 = AM=0A> > To: v6ops=0A> > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > Subject: = Routing loop attacks using IPv6 tunnels=0A> > =0A> > Hi all,=0A> > I would = like to draw the attention of the list to=A0some=A0research=A0results which= =0A> my colleague and I at=0A> > the National EW Research=A0& Simulation= =A0Center have recently published. The =0A> research presents a=A0class=0A>= > of routing loop attacks that abuses 6to4, ISATAP and Teredo. The=A0paper= can be =0A> found at:=0A> > http://www.usenix.org/events/woot09/tech/full_= papers/nakibly.pdf=0A> > =0A> > Here is the abstract:=0A> > IPv6 is the fut= ure network layer protocol for the Internet. Since it is not =0A> compatibl= e with its=0A> > predecessor, some interoperability mechanisms were designe= d. An important =0A> category of these=0A> > mechanisms is automatic tunnel= s, which enable IPv6 communication over an IPv4 =0A> network without prior= =0A> > configuration. This category includes ISATAP, 6to4 and Teredo. We pr= esent a =0A> novel class of attacks=0A> > that exploit vulnerabilities in t= hese tunnels. These attacks take advantage of =0A> inconsistencies=0A> > be= tween a tunnel's overlay IPv6 routing state and the native IPv6 routing =0A= > state. The attacks form=0A> > routing loops which can be abused as a vehi= cle for traffic amplification to =0A> facilitate DoS attacks.=0A> > We exhi= bit five attacks of this class. One of the presented attacks can DoS a =0A>= Teredo server using a=0A> > single packet. The exploited vulnerabilities a= re embedded in the design of the =0A> tunnels; hence any=0A> > implementati= on of these tunnels may be vulnerable. In particular, the attacks =0A> were= tested=0A> > against the ISATAP, 6to4 and Teredo implementations of Window= s Vista and =0A> Windows Server 2008 R2.=0A> > =0A> > I think the results o= f the research warrant some corrective action. If =0A> this=A0indeed shall = be the=0A> > general sentiment of the list, I will be happy write an approp= riate I-D. The =0A> mitigation measures we=0A> > suggested in the paper are= the best we could think of to completely eliminate =0A> the problem. Howev= er=0A> > they are far from perfect since=A0they would require=A0tunnel impl= ementations to =0A> be updated in case new=0A> > types of automatic tunnels= are introduced.=0A> > =0A> > Your comments are welcome.=0A> > =0A> > Gabi= =0A> > =0A> > =0A> > =0A=0A=0A From owner-v6ops@ops.ietf.org Fri Aug 28 12:10:43 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A593A7157 for ; Fri, 28 Aug 2009 12:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, J_CHICKENPOX_13=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 8c3ZO2w+jK31 for ; Fri, 28 Aug 2009 12:10:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C9E83A7190 for ; Fri, 28 Aug 2009 12:08:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6my-000LA9-H3 for v6ops-data0@psg.com; Fri, 28 Aug 2009 19:07:08 +0000 Received: from web45502.mail.sp1.yahoo.com ([68.180.197.62]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh6mt-000L7Y-M7 for v6ops@ops.ietf.org; Fri, 28 Aug 2009 19:07:05 +0000 Received: (qmail 99142 invoked by uid 60001); 28 Aug 2009 19:07:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251486423; bh=u9sTV+ETcDmLh9HMJ0AxLWBOytdZazWudvXsvE1vMDA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UMyWe38nLkLyql3gAKR6UXbSZjAwlLDHbMI7hwgY9qfVM4tbjcXcl1CAh3OwcGVIosd8eGG4IUaNis1At+h0HhhHTD8WwK/AbPeC7QdqfpYE4SP+IiEKHf+zH5VTfZzARkFyiofQbwZdzb44qD0l0EY0X1TxlKMjuLAHGXi1PQI= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pPlx7cL2MRce1y2zN2UZIkbdnTGxw/vd4In+hSEKzoVgANfmN5Tb1PFezkjjL3FbeytRDV20BeWUaJ3B1UcpjejYDKs5gY+UUbYsAyWZVsHgJO6LrWaIHerR1ZroEtxDXlGuVoEkLKfXpilfHvD/8sAPbJaYSRhQ017qWuOo9Is=; Message-ID: <212591.98462.qm@web45502.mail.sp1.yahoo.com> X-YMail-OSG: iGaZMakVM1mFX9CKJHXfcLiq7rG9hdY0Y7gK4pPx.r41WoxfvWLEkxQcDn42bT6GcfqU_g5xZQUFluLaFnxoRF9lmoI_mlOTT9doHOeG2w04Rb94PbQv05qCrT8gFHuCerMyCwbAor7rkumyLA3pNSSS4iBxJZ59JVaAhmb9ivvMyR.qXhRcemhkU_usZsBn0Olyb_gHXos1olcD2r3G5ib6VvNmb7yDM6jFLdtph19sIkJyH0OnhU79fUCYcaR4Axh8VNBP Received: from [89.138.8.21] by web45502.mail.sp1.yahoo.com via HTTP; Fri, 28 Aug 2009 12:07:03 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> Date: Fri, 28 Aug 2009 12:07:03 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" , v6ops Cc: ipv6@ietf.org, secdir@ietf.org In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Correct. All the attacks rely on the fact that the ISATAP router encapsulates/decapsulates a packet the 6to4 relay decapsulates/encapsulates, respectively. So the two tunnels must have the same encapsulation type. ----- Original Message ---- > From: "Templin, Fred L" > To: Gabi Nakibly ; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Sent: Friday, August 28, 2009 7:23:03 PM > Subject: RE: Routing loop attacks using IPv6 tunnels > > Gabi, > > Correct me if I am wrong, but if there were a new version > of ISATAP that did not use ip-proto-41 encapsulation but > instead used a different kind of encapsulation, then it > need not concern itself with routing loop interactions > with 6to4 relays since 6to4 relays only know about > ip-proto-41. Does that match your understanding? > > Thanks - Fred > fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Fri Aug 28 13:28:35 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F843A6ED3 for ; Fri, 28 Aug 2009 13:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.594 X-Spam-Level: X-Spam-Status: No, score=-4.594 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 HtUIgCsE+HGN for ; Fri, 28 Aug 2009 13:28:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5350528C1E5 for ; Fri, 28 Aug 2009 13:28:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh80q-000Du3-7r for v6ops-data0@psg.com; Fri, 28 Aug 2009 20:25:32 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh80l-000Dt1-S4 for v6ops@ops.ietf.org; Fri, 28 Aug 2009 20:25:30 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7SKPRiU028364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 13:25:27 -0700 (PDT) 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 n7SKPQuS008869; Fri, 28 Aug 2009 13:25:27 -0700 (PDT) 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 n7SKPLGl008655; Fri, 28 Aug 2009 13:25:26 -0700 (PDT) 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.3959); Fri, 28 Aug 2009 13:25:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Routing loop attacks using IPv6 tunnels Date: Fri, 28 Aug 2009 13:25:23 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <212591.98462.qm@web45502.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooErw/GQXNMWvASRqGPthARajqOQACrWeA References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> <212591.98462.qm@web45502.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" Cc: , X-OriginalArrivalTime: 28 Aug 2009 20:25:26.0120 (UTC) FILETIME=[AD5D0E80:01CA281D] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Friday, August 28, 2009 12:07 PM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Correct. All the attacks rely on the fact that the ISATAP router encapsulates/decapsulates a packet > the 6to4 relay decapsulates/encapsulates, respectively. So the two tunnels must have the same > encapsulation type. OK. That will greatly simplify the checks needed for new automatic tunneling protocols that have a format other than ip-proto-41. Fred fred.l.templin@boeing.com > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Friday, August 28, 2009 7:23:03 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > Correct me if I am wrong, but if there were a new version > > of ISATAP that did not use ip-proto-41 encapsulation but > > instead used a different kind of encapsulation, then it > > need not concern itself with routing loop interactions > > with 6to4 relays since 6to4 relays only know about > > ip-proto-41. Does that match your understanding? > > > > Thanks - Fred > > fred.l.templin@boeing.com >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Aug 28 13:28:36 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274033A6C2E for ; Fri, 28 Aug 2009 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.572 X-Spam-Level: X-Spam-Status: No, score=-4.572 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 92wFlvd4E31z for ; Fri, 28 Aug 2009 13:28:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E1CA28C179 for ; Fri, 28 Aug 2009 13:28:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh7zG-000Dde-J5 for v6ops-data0@psg.com; Fri, 28 Aug 2009 20:23:54 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mh7zA-000Dck-2q for v6ops@ops.ietf.org; Fri, 28 Aug 2009 20:23:50 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7SKNicT027530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 13:23:44 -0700 (PDT) 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 n7SKNiE0006208; Fri, 28 Aug 2009 13:23:44 -0700 (PDT) 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 n7SKNhkh006170; Fri, 28 Aug 2009 13:23:43 -0700 (PDT) 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.3959); Fri, 28 Aug 2009 13:23:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Routing loop attacks using IPv6 tunnels Date: Fri, 28 Aug 2009 13:23:40 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <31484.26522.qm@web45503.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooEhDsb5iTYmmfSmCH2zbFJmnM8QACX3Vw References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" Cc: , X-OriginalArrivalTime: 28 Aug 2009 20:23:43.0525 (UTC) FILETIME=[70364D50:01CA281D] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gabi, Thanks for your continued correspondence, and see below: > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Friday, August 28, 2009 12:02 PM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Fred, > A quick summary of our discussion up until now: the best mitigation = of=A0most of these=A0attacks is > indeed the proto-41 and ingress filtering on the border of the ISATAP = site. If it is indeed > implemented. I=A0assume that not all sites deploy such filtering for = lack of awareness or since the > proto-41 filtering may break other tunnels the site may employ. = However, I do not have hard evidence > on this. I would be happy if others on the list will refute or justify = this assumption. >=20 > If this assumption is (even partially) correct than I think that the = ISATAP router should defend > itself. If there is operational assurance of filtering, then I think there is no problem. For the other cases, I am beginning to come around to your opinion. > Moreover, as I mention below the proo-41 filtering is not effective in = case of attack > #3=A0and=A0the attacker is internal to the site. I'll speak more on this below. > So IMHO the best way is the mitigations I suggested and > that you illustrated below in pseudo-code. OK. > See=A0further comments inline. >=20 > Gabi >=20 > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Monday, August 24, 2009 10:04:34 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Monday, August 24, 2009 4:44 AM > > > To: Templin, Fred L; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Fred, > > > I=A0initially very much=A0liked your suggestion regarding the = check=A0of the > > neighbor cache before > > > forwarding a packet into the tunnel.=A0It truly addresses the root = cause of the > > problem ans is simple > > > enough to implement. However, I realized that an attacker can send = a > > spoofed=A0RS to the ISATAP router > > > as if it came from the 6to4 relay. The router would then send=A0a = RA=A0to it=A0and > > consequently change its > > > neighbor cache. So it seems=A0that this defense does not add = much.=A0Wouldn't you > > agree? > > > > I agree that my proposed mitigation is only useful when there > > is assurance of a coherent neighbor cache in the ISATAP router. > > That would be true in the case in which the ISATAP router is > > located within a site protected by border routers that perform > > ip-proto-41 and ingress filtering, and in which there is no > > untraceable IPv4 source address spoofing. So AFAICT, my proposed > > mitigation is still necessary for preventing attack #3 when > > ISATAP routers A and B are on separate ISATAP links within > > the same site-internal IPv4 routing region. > > >=20 > This is only true when the attacker is outside the site and proto-41 = filtering is employed. If the > attacker is internal to the site then the proto-41 filtering will not = help and the neighbor cache can > be poisoned. Since the ISATAP checks require that the IPv6 source embed the IPv4 source and/or the IPv4 source is a PRL router, you must be speaking here about IPv4 source address spoofing from within the site. For sites that allow intra-site source address spoofing, I think much more serious problems could manifest themselves that would be completely unrelated to ISATAP. I believe you will also find other automatic tunneling protocols besides ISATAP that operate under an assumption of no intra-site IPv4 source address spoofing.=20 > > > I completely agree with your observation on the non-feasibility of > > verifying=A0that the > > > destination=A0ISATAP address does not include=A0a local=A0IPv4 = address=A0since the > > ISATAP address may include > > > a private IPv4 address. On the other hand, a check on public IPv4 = addresses is > > acceptable.=A0If the > > > check would be done only on ISATAP addresses that include public = IPv4 > > addresses then this will > > > eliminate the attacks in which the two victims reside=A0at = different sites. Note > > that if attack #3=A0is > > > launched on two ISATAP routers=A0having private addresses at two = different sites > > then the attack will > > > not work anyway since one router can not send a direct=A0IPv4 = packet to the > > other. In addition, > > > to=A0mitigate attacks in which the other victim is a 6to4 relay = (such as attack > > #1) then a check would > > > have to be done on a 6to4 address, i.e. the destination address = must not be > > "2002:> > the ISATAP router>::*". In this case the IPv4 address must = be public, > > according to > > >=A0 the 6to4 spec. > > > > > > As you also noted there is another problem with this check since = the string > > "200::5EFE" is not unique > > > to ISATAP links. On the other hand, it seems that the probability = to encounter > > a non-malicious packet > > > with a destination address having an IID that equals "200:5EFE:> = IPv4 address>" is > > > pretty slim. > > > > > > This check is definitely not a=A0perfect solution, and I sure hope = that someone > > will come up with a > > > better one for mitigating the routing loops. However, I would be = happy if > > there is some kind of other > > > mitigation=A0measures besides packet filtering=A0(proto-41 and = ingress) by=A0other > > nodes (which=A0does not > > > necessarily exist). > > > > You seem to be envisioning a scenario of ISATAP router operation > > with public IPv4 addresses and outside of any site border routers > > that perform ingress filtering and ip-proto-41 filtering. That has > > traditionally been seen as the domain of 6to4, but I am happy to > > discuss the possibility of what I called the "inside-out ISATAP > > model" in a list message long ago (which AFAICT is the scenario > > you are alluding to). > > >=20 > Well,=A0I am referring to any=A0ISATAP deployment=A0with public IPv4 = addresses and no proto-41 filtering. I > imagine that in practice there are such deployments which are not the = "inside-out ISATAP model"=A0. > However, I must admit that I do not rely here on hard evidence. >=20 > > So, if the public IPv4 Internet were considered as one gigantic > > "site" and we wanted to do ISATAP on that site, it would be nice > > to divide the site into multiple logical partitions, with each > > partition identified by a PRL name and a unique set of IPv6 > > prefixes. But then, we have the scenario you are describing in > > which we can't trust the integrity of the ISATAP router's > > neighbor cache due to the possibility for untraceable IPv4 > > source address spoofing such that the neighbor cache check > > mitigation can be subverted. > > > > This means that if we want to support the inside-out ISATAP > > model then the routing loops could be mitigated either by > > 1) implementing the destination address checks you are > > suggesting, or 2) by not allowing ISATAP router interfaces > > that are not behind filtering border routers to advertise > > non-link-local on-link IPv6 prefixes and/or forward packets > > from non-link-local prefixes in the first place. > > > > If we took the easy way out and did 2), then the entire > > IPv4 Internet would look like one gigantic ISATAP link that > > only did IPv6 link-local. So, nodes could ping6 each others' > > ISATAP link-local addresses but that's about it. > > > > If we took the more ambitious route and allowed ISATAP to > > flourish fully within the global IPv4 Internet, then we > > would essentially be deprecating 6to4 - so it isn't > > surprising that your address checks mostly involve 6to4 > > suppression. Assuming this, if I read your attack scenarios > > 1 through 3 correctly then scenarios 1 and 3 are mitigated > > by a receive-side check and scenario 2 is mitigated by a > > send-side check. In particular, the pseudo-code would be: > > > > =A0 isatap_rcv() { > > =A0 =A0 ... > > =A0 =A0 if (dst =3D=3D "2002:::*") > > =A0 =A0 =A0 drop_pkt(); /* attack #1 mitigation */ > > > > =A0 =A0 if (dst =3D=3D "*::0200:5efe:") > > =A0=A0=A0 drop_pkt(); /* attack #3 mitigation */ > > =A0 =A0 ... > > =A0 } > > >=20 > Correct (with the correction you sent after this email). OK. =20 > > =A0 isatap_xmt() { > > =A0 =A0 ... > > =A0 =A0 if (dst =3D=3D "*::0200:5efe:192.88.99.1") > > =A0 =A0 =A0 drop_pkt(); /* attack #2 mitigation */ > > =A0 =A0 ... > > =A0 } >=20 > This will not necessarily work, since the 6to4 relay may have = a=A0unicast address the ISATAP router may > not be aware of. The best way to mitigate attack #2 is=A0by the 6to4 = relay with a check similar to that > of attack #2 above. IMO, the second best way, as Remi suggested on = another thread, is for the ISATAP > router to drop the packet if (src=A0 =3D=3D 2002:::*"). = However, this check is useful only > when the 6to4 relay validates that the IPv6 source address corresponds = to the IPv4 one (this is > in=A0accordance=A0with the 6to4 spec, however it does not always get = implemented). If this is not true > then the attacker does not have to send the attack packet with such an = address. Keeping with the philosophy of the ISATAP router defending itself, I believe it would be best to take Remi's suggestion and lay any complications at the doorstep of the 6to4 relay if it fails to adhere to the spec. Thanks - Fred fred.l.templin@boeing.com > > Does the above look right to you? And is this everything, > > or are there other scenarios we need to consider? > > >=20 >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > > > > Gabi > > > > > > ----- Original Message ---- > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Wednesday, August 19, 2009 6:16:18 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > Hi Gabi, > > > > > > I'm sorry to have to keep turning this into plaintext, > > > but annotation is difficult otherwise. See below for > > > my responses (=3D=3D>): > > > > > > ________________________________________ > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Wednesday, August 19, 2009 1:49 AM > > > To: Templin, Fred L; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Fred, > > > See my comments inline (). > > > > > > ________________________________________ > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Tuesday, August 18, 2009 6:48:45 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > Gabi, > > > > > > ________________________________________ > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Tuesday, August 18, 2009 3:29 AM > > > To: Templin, Fred L; v6ops > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > Indeed the ISATAP interface of the ISATAP router is meant > > > > to be an enterprise-interior (note that=A0it is still=A0assumed > > > > that the associated IPv4 address is=A0non-private). As=A0we > > > > explicitly note in the paper, the first three attacks=A0will > > > > be mitigated=A0if proper protocol-41 filtering is deployed on > > > > the site's border. However, note that RFC5214 does not mandate > > > > or require this filtering. > > > > > > The RFC5214 Security Considerations makes clear the > > > consequences of not implementing IPv4 ingress filtering > > > and ip-protocol-41 filtering (i.e., a possible spooing > > > attack in which spurious ip-protocol-41 packets are > > > injected into an ISATAP link from outside). RFC5214 > > > Section 6.2 additionally requires that an ISATAP interface's > > > locator set MUST NOT span multiple sites. This means that the > > > ISATAP interface must not decapsulate nor source ip-proto-41 > > > packets within multiple sites, where the enterprise interior > > > is site #1 and the global Internet is site #2. ip-protocol-41 > > > filtering is the way in which the ISATAP interface is > > > restricted to a single site. > > > > > > Now let me see that I understand Section 6.2 correctly. In > > > attack #2, for example, I assume the ISATAP router has two > > > physical interfaces. A site-internal IPv4 interface with an > > > address IPisatap and a site-external IPv6 interface. I also > > > assume that there=A0is another border router which connects the > > > site to the IPv4 Internet.=A0The ISATAP router has an ISATAP > > > interface with a single locator: (IPisatap, site-internal > > > interface).=A0When the ISATAP router gets an IPv6 via its > > > external interface it will encapsulate the packet accordingly > > > and forward it through the internal IPv4 interface. If the > > > encapsulated packet is=A0destined to a node outside the site > > > then the only thing that stops it is=A0a proto-41 filtering > > > at the=A0other border router of the site. Did I get this right? > > > > > > > > > =3D=3D> In this case, yes - the ip-proto-41 filtering is at a > > > =3D=3D> border router. I know of at least one major enterprise > > > =3D=3D> network that does this. > > > > > > > It is only mentioned as a possible mitigation against > > > > incoming spurious protocol-41 packets. In addition, > > > > Section 10 of RFC5214 only mentions=A0ingress not=A0egress > > > > filtering.=A0Hence it=A0will not stop attack #2. > > > > > > We are now talking about ip-proto-41 filtering; not ingress > > > filtering. ip-proto-41 filtering is in both directions. It > > > prevents ip-proto-41 packets from entering the enterprise > > > interior ISATAP site from the Internet and prevents > > > ip-proto-41 packets from entering the Internet ISATAP > > > site from the enterprise interior. Else the ISATAP > > > interface would span multiple sites. > > > > > > Besides, "ingress" filtering is not about packets coming > > > from the Internet into the end site, but rather it is > > > about packets leaving the end site and going out into > > > the Internet. RFC2827 (BCP38) documents ingress filtering. > > > > > > OK. I see what you are saying here. > > > > > > > > > =3D=3D> OK. > > > > > > > In addition, > > > > as mentioned, protocol-41 filtering is not helpful when > > > > attack #3 is launched on two routers that reside in the > > > > same site. Note that=A0it=A0may be=A0possible for=A0the attack > > > > packet=A0to be sourced from outside the site unless proper > > > > filtering of incoming IPv6 packets is deployed. If the > > > > attacker resides in the site, usually ingress filtering > > > > will not be helpful since it is deployed in general on > > > > the site's border. > > > > > > Here, we have the ISATAP router in both cases sourcing a > > > packet from a foreign prefix. > > > > > > Well, I do not see how this is correct. In attacks #1 and #3 the = ISATAP router > > sources (actually > > > forwards) an IPv6=A0packet with=A0a source address having=A0the = corresponding=A0prefix > > of the ISATAP tunnel. > > > In attacks #2 and #3 the ISATAP router sources and IPv4 packet = with its own > > IPv4 address as the > > > source address. > > > > > > > > > =3D=3D> There were a number of errors in what I said in my last > > > =3D=3D> message, so let me see if I can get it right here: > > > =3D=3D> > > > =3D=3D> In attacks #1 and #2 there are two cases to consider. Case > > > =3D=3D> 1 in which a border router separates the 6to4 relay from = the > > > =3D=3D> ISATAP router, and case 2 in which no border router = separates > > > =3D=3D> the 6to4 relay from the ISATAP router. > > > =3D=3D> > > > =3D=3D> In attack #1, we have an IPv6 packet with a local source > > > =3D=3D> address entering the site from the outside. IPv6 ingress > > > =3D=3D> filtering at the site border router should prevent the > > > =3D=3D> packet from entering the site in the first place. If the > > > =3D=3D> 6to4 relay router is outside the site then ip-proto-41 > > > =3D=3D> filtering at the border router will block the attack in > > > =3D=3D> the first place anyway. If the relay router is *inside* > > > =3D=3D> the site, then the IPv6 ingress filtering is the lone > > > =3D=3D> mitigation. The end result is that the 6to4 relay should > > > =3D=3D> really be positioned outside of the site's border routers; > > > =3D=3D> otherwise, it could be spoofed into thinking that the > > > =3D=3D> ISATAP router is a 6to4 router and not an ISATAP router. > > > =3D=3D> > > > =3D=3D> In attack #2, we have an IPv6 packet with a foreign source > > > =3D=3D> address being forwarded by the ISATAP router to a 6to4 > > > =3D=3D> relay, but I mis-spoke when I said that this would be a > > > =3D=3D> case of the ISATAP router forwarding a packet with a = foreign > > > =3D=3D> source address out of the ISATAP link. For all the ISATAP > > > =3D=3D> router knows, the 6to4 relay is just an ordinary host on > > > =3D=3D> the ISATAP link, so the ISATAP router actually believes it > > > =3D=3D> is forwarding the packet *into* the ISATAP link (not out = of > > > =3D=3D> it). But as in attack #1, the attack is blocked by = ip-proto-41 > > > =3D=3D> filtering at the border router between the ISATAP router = and > > > =3D=3D> the 6to4 relay. If there is no border router between the = ISATAP > > > =3D=3D> router and the 6to4 relay, then we have an identical = instance > > > =3D=3D> to attack #3 which I will discuss below. But, the best > > > =3D=3D> operational practice would again be to have the 6to4 relay > > > =3D=3D> oriented outside of a border router that filters = ip-proto-41. > > > =3D=3D> > > > =3D=3D> Short summary is that in attack #1, the 6to4 relay thinks = it > > > =3D=3D> is talking to a 6to4 router and not an ISATAP router. In > > > =3D=3D> attack #2, the ISATAP router thinks it is talking to a > > > =3D=3D> simple host on the link and not a 6to4 relay. In both = cases, > > > =3D=3D> the attacks are mitigated when there is an ip-proto-41 > > > =3D=3D> filtering border router between the ISATAP router and the > > > =3D=3D> 6to4 relay. Oftentimes, the "border router" will be a two- > > > =3D=3D> interface router that implements 6to4 on a site-external > > > =3D=3D> IPv4 interface and implements ISATAP on a site-internal > > > =3D=3D> IPv4 interface and performs ip-proto-41 filtering on = packets > > > =3D=3D> from outside the site with an IPv4 destination = corresponding > > > =3D=3D> to the ISATAP interface. I will discuss attack #3 below: > > > > > > This attack is mitigated by > > > IPv6 ingress filtering which is an IPv6 security consideration > > > and not an ISATAP nor IPv4 security consideration. BCP > > > recommendations for network ingress filtering are documented > > > in RFC2827 and it is expected that IPv6 routers that configure > > > ISATAP interfaces will implement IPv6 ingress filtering > > > according to the BCP. > > > > > > So If my last comment is correct than I do not see how ingress = filtering would > > help here. The only > > > case where=A0ingress filtering can help is in case of attack #3 = when the routers > > reside at the same > > > site. In that case if the attack packet (packet 0) is sent from = outside the > > site then ingress > > > filtering on the border of the site will drop the packet. > > > > > > > > > =3D=3D> Correct about the IPv6 ingress filtering at the border, > > > =3D=3D> but as with attack #2 my error in the previous message > > > =3D=3D> was in thinking the ISATAP router A was forwarding the > > > =3D=3D> packet *out* of the ISATAP link when in fact from the > > > =3D=3D> ISATAP router's perspective it is forwarding the packet > > > =3D=3D> to a simple host *inside* of the link. > > > =3D=3D> > > > =3D=3D> The problem here is that the ISATAP router is blindly > > > =3D=3D> forwarding a packet to a node that it assumes is a simple > > > =3D=3D> host on the ISATAP link without first verifying that the > > > =3D=3D> node has demonstrated a willingness to participate as a > > > =3D=3D> host on the link. As you have pointed out, this can lead > > > =3D=3D> to strange scenarios when the anonymous node is a tunnel > > > =3D=3D> router of some sort that does not participate in the > > > =3D=3D> ISATAP link. > > > =3D=3D> > > > =3D=3D> It would not generally be possible for the ISATAP router > > > =3D=3D> to check whether the IPv6 destination address is an ISATAP > > > =3D=3D> address that embeds one of its own IPv4 addresses, because > > > =3D=3D> when IPv4 private addresses are used the same IPv4 address > > > =3D=3D> can (and often does) occur in multiple sites. So for = example, > > > =3D=3D> if the ISATAP router configures an IPv4 address 10.0.0.1 > > > =3D=3D> and is asked to forward an IPv6 packet with ISATAP > > > =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where the > > > =3D=3D> IPv6 prefix is foreign, the router can't very well drop = the > > > =3D=3D> packet as this would block legitimate communications. It > > > =3D=3D> is also not generally possible to check whether a foreign > > > =3D=3D> link is an ISATAP link by looking for the magic token > > > =3D=3D> "0:5EFE" as that token only has significance for ISATAP > > > =3D=3D> links and not other link types. > > > =3D=3D> > > > =3D=3D> Instead, the mitigation I think makes the most sense is > > > =3D=3D> for the ISATAP router to first verify that the node which > > > =3D=3D> it assumes to be a simple ISATAP host has demonstrated a > > > =3D=3D> willingness to participate in the link. That can be done > > > =3D=3D> by having the ISATAP router first check the neighbor cache > > > =3D=3D> when it has a packet to send to verify that there is a > > > =3D=3D> cached entry corresponding to the destination. For nodes > > > =3D=3D> that are willing ISATAP hosts on the link, there would > > > =3D=3D> have been a neighbor cache entry created when the node > > > =3D=3D> sends a Router Solicitation to the ISATAP router for the > > > =3D=3D> purpose of discovering default router lifetimes and on- > > > =3D=3D> link prefixes. So, the simple mitigations is for the = ISATAP > > > =3D=3D> router to forward the packet only if there is a = pre-existing > > > =3D=3D> neighbor cache entry and drop the packet otherwise. This > > > =3D=3D> implies that the router should keep neighbor cache entires > > > =3D=3D> for the duration of the minimum lifetime of the prefixes > > > =3D=3D> it advertises in its Router Advertisements. > > > > > > > In general, I would like to point out that indeed as in > > > > most other attacks these attacks may also be mitigated by > > > > proper firewall rules. However, I do not believe that this > > > > should be our only answer against these attacks. I believe > > > > that since these attacks are made possible due to the > > > > inherent characteristics of the tunnels they=A0should be > > > > stopped intrinsically as much as possible by the tunnel > > > > participants and not relay on outside filtering rules. > > > > > > In RFC5214, Section 10 we have: "restricting access to the > > > link can be achieved by restricting access to the site". The > > > mitigations do exactly that, and in such a way that ISATAP > > > nodes can operate with only the necessary and sufficient > > > checks. So on this point, I do not share your opinion. > > > > > > What about two ISATAP tunnels that reside on the same site like in = attack #3. > > Do you=A0also think that > > > proto-41 filtering should barrier between the two tunnels within = the site? > > > > > > > > > =3D=3D> I think this may be overcome by the discussion above. > > > =3D=3D> Short story is that operational practices must be > > > =3D=3D> employed whereby an ISATAP router is not mistaken for > > > =3D=3D> a 6to4 router. This is through proper arrangement of > > > =3D=3D> 6to4 router/relay interfaces outside of the site border > > > =3D=3D> rather than inside, and ISATAP router interfaces inside > > > =3D=3D> of the site border rather than outside. Also proper > > > =3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at > > > =3D=3D> site borders. > > > =3D=3D> > > > =3D=3D> Also, when there are multiple ISATAP links within the > > > =3D=3D> same local IPv4 routing region, an ISATAP router should > > > =3D=3D> first verify a node's willingness to act as a host on > > > =3D=3D> the ISATAP link before blindly sending a packet to it. > > > =3D=3D> > > > =3D=3D> Fred > > > =3D=3D> fred.l.templin@boeing.com > > > > > > Fred > > > fred.l.templin@boeing.com > > > > > > ________________________________________ > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Monday, August 17, 2009 8:35:08 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > Gabi, > > > > > > Thanks for publishing this work. In the document, attacks A, B and = C > > > correspond to a configuration that violates section 6.2 of = RFC5214: > > > > > > > 6.2.=A0 ISATAP Interface Address Configuration > > > > > > > > =A0=A0Each ISATAP interface configures a set of locators = consisting of IPv4 > > > >=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP > > > >=A0=A0 interface's locator set MUST NOT span multiple sites. > > > > > > In particular, in scenarios A, B and C the IPv4 locator used for = ISATAP > > > is seen both within the enterprise as site #1 and within the = global Internet > > > itself as site #2. If the ISATAP interface is to be used as an = enterprise- > > > interior interface, it should therefore not accept IP-proto-41 = packets > > > coming from an IPv4 source outside of the enterprise nor source > > > IP-proto-41 packets that are destined to an IPv4 node outside of = the > > > enterprise. This condition should be satisfied by having the site = border > > > routers implement IPv4 ingress filtering and ip-protocol-41 = filtering as > > > required in Section 10 of RFC5214. > > > > > > It is mentioned that attack C could also occur when the routers = reside > > > in the same site, where their addresses may be private. This would > > > correspond to a case in which an attacker within the site attacks = the > > > site itself, which can easily be traced - especially when source = address > > > spoofing from a node within the site is prevented through proper = ingress > > > filtering. > > > > > > Fred > > > fred.l.templin@boeing.com > > > > > > ________________________________________ > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Monday, August 17, 2009 8:21 AM > > > To: v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Routing loop attacks using IPv6 tunnels > > > > > > Hi all, > > > I would like to draw the attention of the list = to=A0some=A0research=A0results which > > my colleague and I at > > > the National EW Research=A0& Simulation=A0Center have recently = published. The > > research presents a=A0class > > > of routing loop attacks that abuses 6to4, ISATAP and Teredo. = The=A0paper can be > > found at: > > > http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf > > > > > > Here is the abstract: > > > IPv6 is the future network layer protocol for the Internet. Since = it is not > > compatible with its > > > predecessor, some interoperability mechanisms were designed. An = important > > category of these > > > mechanisms is automatic tunnels, which enable IPv6 communication = over an IPv4 > > network without prior > > > configuration. This category includes ISATAP, 6to4 and Teredo. We = present a > > novel class of attacks > > > that exploit vulnerabilities in these tunnels. These attacks take = advantage of > > inconsistencies > > > between a tunnel's overlay IPv6 routing state and the native IPv6 = routing > > state. The attacks form > > > routing loops which can be abused as a vehicle for traffic = amplification to > > facilitate DoS attacks. > > > We exhibit five attacks of this class. One of the presented = attacks can DoS a > > Teredo server using a > > > single packet. The exploited vulnerabilities are embedded in the = design of the > > tunnels; hence any > > > implementation of these tunnels may be vulnerable. In particular, = the attacks > > were tested > > > against the ISATAP, 6to4 and Teredo implementations of Windows = Vista and > > Windows Server 2008 R2. > > > > > > I think the results of the research warrant some corrective = action. If > > this=A0indeed shall be the > > > general sentiment of the list, I will be happy write an = appropriate I-D. The > > mitigation measures we > > > suggested in the paper are the best we could think of to = completely eliminate > > the problem. However > > > they are far from perfect since=A0they would require=A0tunnel = implementations to > > be updated in case new > > > types of automatic tunnels are introduced. > > > > > > Your comments are welcome. > > > > > > Gabi > > > > > > > > > >=20 >=20 >=20 From noel5544pdv@ae.com Fri Aug 28 17:54:23 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082E23A68B3 for ; Fri, 28 Aug 2009 17:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.931 X-Spam-Level: X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaFFdcEgb2Fz for ; Fri, 28 Aug 2009 17:54:16 -0700 (PDT) Received: from 209-234-150-15.static.twtelecom.net (209-234-150-15.static.twtelecom.net [209.234.150.15]) by core3.amsl.com (Postfix) with SMTP id D83033A6AA2 for ; Fri, 28 Aug 2009 17:54:14 -0700 (PDT) To: Subject: Return mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090829005414.D83033A6AA2@core3.amsl.com> Date: Fri, 28 Aug 2009 17:54:14 -0700 (PDT) Show picture and go to site now! From zolad57@pousadafelissimo.com.br Fri Aug 28 20:39:07 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC013A68A6; Fri, 28 Aug 2009 20:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.293 X-Spam-Level: X-Spam-Status: No, score=-44.293 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_RELAY_NODNS=1.451, FS_START_LOSE=1.493, GB_I_INVITATION=-2, HS_INDEX_PARAM=0.001, HTML_MESSAGE=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, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SUBJECT_DIET=1.466, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKf2ZVO5CGLI; Fri, 28 Aug 2009 20:39:07 -0700 (PDT) Received: from smtp.coopsar.com.ar (unknown [201.251.79.185]) by core3.amsl.com (Postfix) with ESMTP id 512FA3A68A0; Fri, 28 Aug 2009 20:39:05 -0700 (PDT) Received: from 201.251.79.185 by pousadafelissimo.com.br; Sat, 29 Aug 2009 05:39:05 +0100 Message-ID: <000d01ca285a$425f9b10$6400a8c0@zolad57> From: Sharon Reece To: Subject: Lose 12lbs in 1 month Date: Sat, 29 Aug 2009 05:39:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA285A.425F9B10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA285A.425F9B10 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What do you think about testing my secret for free.   The ACAl is one of the world's most=20 interesting and unique foods. It may also be=20 one of its healthiest. Chock-full of antioxidants,=20 amino acids, AND essential fatty acids, the tiny=20 little ACAl Berry packs a nutritional wallop rarely=20 seen in the natural world. In fact, some experts consider=20 it to be the world's most "complete" natural food. =20 Invitation to click ------=_NextPart_000_0007_01CA285A.425F9B10 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Wha= t do you think about testing my secret for free.
&n= bsp;
The ACAl is one of the world's most=20 interesting and unique foods. It may also be=20 one of its healthiest. Chock-full of antioxidants,=20 amino acids, AND essential fatty acids, the tiny=20 little ACAl Berry packs a nutritional wallop rarely=20 seen in the natural world. In fact, some experts consider=20 it to be the world's most "complete" natural food.


=
<= A=20 href=3D"http://www.graftkeblinz.biz/?blsnbwiryndx">Invitation to click<= /FONT>
------=_NextPart_000_0007_01CA285A.425F9B10-- From khesterdd@amc.toshiba.co.jp Sat Aug 29 08:19:35 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7733A6BED for ; Sat, 29 Aug 2009 08:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, 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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al9RELjmjS-n for ; Sat, 29 Aug 2009 08:19:29 -0700 (PDT) Received: from pool-71-175-198-24.phlapa.east.verizon.net (pool-71-175-198-24.phlapa.east.verizon.net [71.175.198.24]) by core3.amsl.com (Postfix) with SMTP id 9B0E63A687C for ; Sat, 29 Aug 2009 08:19:28 -0700 (PDT) To: Subject: no-reply From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090829151928.9B0E63A687C@core3.amsl.com> Date: Sat, 29 Aug 2009 08:19:28 -0700 (PDT) Show picture and go to site now! From tafthyd8@rebeccafox.com Sat Aug 29 15:30:19 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10DF3A6ACD for ; Sat, 29 Aug 2009 15:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.487 X-Spam-Level: X-Spam-Status: No, score=-77.487 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, FM_SCHOOLING=5.657, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_3AC1D=0.688] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q02uKYNv7I4D for ; Sat, 29 Aug 2009 15:30:19 -0700 (PDT) Received: from host-88-132-1-86.prtelecom.hu (host-88-132-1-86.prtelecom.hu [88.132.1.86]) by core3.amsl.com (Postfix) with ESMTP id 69B093A690C for ; Sat, 29 Aug 2009 15:30:18 -0700 (PDT) Received: from 88.132.1.86 by mail.0web-hosting.com; Sun, 30 Aug 2009 00:30:21 +0100 Message-ID: <000d01ca28f8$4b2f4530$6400a8c0@tafthyd8> From: "Kotkell" To: Subject: Stereikt Date: Sun, 30 Aug 2009 00:30:21 +0100 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Now you can get real degree just in 4-5 weeks on base of your professional experience We will help you get a Degree:- Bachelors, Masters and PhD Call us right now 1-305.460.5721 Drop us your msg, with your full name and contact number so we can call you back. From lbwlmjyxel@amber-tech.fr Sat Aug 29 16:41:47 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C05A3A67CC for ; Sat, 29 Aug 2009 16:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.855 X-Spam-Level: X-Spam-Status: No, score=-15.855 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIB3b+4n1Nmt for ; Sat, 29 Aug 2009 16:41:45 -0700 (PDT) Received: from aliancadobrasil.com.br (unknown [190.156.252.250]) by core3.amsl.com (Postfix) with SMTP id A52333A659B for ; Sat, 29 Aug 2009 16:41:41 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090829234144.A52333A659B@core3.amsl.com> Date: Sat, 29 Aug 2009 16:41:41 -0700 (PDT) Show picture and go to site now! From o.khaddour@afpc.net.sy Sun Aug 30 09:37:55 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C476B3A6B25 for ; Sun, 30 Aug 2009 09:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.753 X-Spam-Level: X-Spam-Status: No, score=-22.753 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HELO_IS_SMALL6=0.556, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwN9wZ4iauom for ; Sun, 30 Aug 2009 09:37:54 -0700 (PDT) Received: from 1dk.jp (unknown [189.110.154.133]) by core3.amsl.com (Postfix) with SMTP id 2821D3A6A8A for ; Sun, 30 Aug 2009 09:37:50 -0700 (PDT) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090830163753.2821D3A6A8A@core3.amsl.com> Date: Sun, 30 Aug 2009 09:37:50 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Mon Aug 31 12:49:23 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7E73A6C12 for ; Mon, 31 Aug 2009 12:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, J_CHICKENPOX_13=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 O39fOnDbKE0k for ; Mon, 31 Aug 2009 12:49:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F1C43A6ED4 for ; Mon, 31 Aug 2009 12:46:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiCkD-000Mq6-2N for v6ops-data0@psg.com; Mon, 31 Aug 2009 19:40:49 +0000 Received: from web45509.mail.sp1.yahoo.com ([68.180.197.125]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiCk5-000Mnq-TA for v6ops@ops.ietf.org; Mon, 31 Aug 2009 19:40:45 +0000 Received: (qmail 98032 invoked by uid 60001); 31 Aug 2009 19:40:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251747641; bh=zhNPsfKDxwgYpOdxPcJ/kFAj/cU9X04ofIKwq2shxAg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bAe4oZIClVliTdACPXT+K2MxhTSoGi6My0PdW/a7MIy/GMfmnBtRcsGHoxFiwrNknAn0uHYu3l5gkVuWOwscvcRs5l+Yq7pEXCOXhV2FYc0ARI4eGomUCzLuCV7lwZFx6jUcg0iyeuQCiL5yXKglKobhh6Np6OKUf24s8qsTLog= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hGctNg/yOxQvJFiHrck/ytD8oFj14u4sAUyW5kgdDdukR+57fRg1Z3qAsoZNf+/B/ba9o4npoBmxyPgI9ywIFLqjZ4vkd78RQcvt3SeAvmtICurGx+EeXmy2VU+6MsOhwvuj1RNgJm/mjswI9OXLQwQixiGpV9uaqk4WFGoKVso=; Message-ID: <373420.97768.qm@web45509.mail.sp1.yahoo.com> X-YMail-OSG: Ps8fNCwVM1kh5gxir1qDsI6hm.rpcqKXMZQGBHuSxCUlb5Y6WnErmKUYDwPJJ4MmdWcTiY.SS5jphrkGpAmrEeChKZvWnGF7k8GNJHEN.gRn7DpUe.AWB2Vbim.C8DcWR9YIwSOKPxsRAms5iMaLSx9L6feyymr2BWCRYjE2arHDzmVVoePpQpLqTkPG1kyIkjh6elUX6xt_A8rvUphmXt2c6ENXgv_cyHoUjV73Zi3GtrQk7IOFQP54RduKE0tsa_mfPl3k Received: from [89.138.8.21] by web45509.mail.sp1.yahoo.com via HTTP; Mon, 31 Aug 2009 12:40:41 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> Date: Mon, 31 Aug 2009 12:40:41 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" , v6ops Cc: ipv6@ietf.org, secdir@ietf.org In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred,=0A=0AI agree that the source address check discussed below should be = made. I would also add a forth check=A0to mitigate attack #3 as a second la= yer of defense in case the opposite ISATAP router does not make the=A0prope= r check on the destination address.=0A=0Aisatap_xmt() {=0A=A0=A0=A0=A0 ...= =0A=A0=A0=A0=A0 if (src =3D=3D "::0200:5efe:= ")=0A=A0=A0=A0=A0=A0=A0 drop_pkt(); /* attack #3 mitigation */=0A=A0=A0=A0= =A0 ...=0A=A0}=0A=0AGabi=0A=0A----- Original Message ----=0A> From: "Templi= n, Fred L" =0A> To: Gabi Nakibly ; v6ops =0A> Cc: ipv6@ietf.org; secdir@ietf.org=0A= > Sent: Friday, August 28, 2009 11:23:40 PM=0A> Subject: RE: Routing loop a= ttacks using IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> Thanks for your continued= correspondence, and see below:=0A> =0A> > -----Original Message-----=0A> >= From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > Sent: Friday, August = 28, 2009 12:02 PM=0A> > To: Templin, Fred L; v6ops=0A> > Cc: ipv6@ietf.org;= secdir@ietf.org=0A> > Subject: Re: Routing loop attacks using IPv6 tunnels= =0A> > =0A> > Fred,=0A> > A quick summary of our discussion up until now: t= he best mitigation of=A0most of =0A> these=A0attacks is=0A> > indeed the pr= oto-41 and ingress filtering on the border of the ISATAP site. If =0A> it i= s indeed=0A> > implemented. I=A0assume that not all sites deploy such filte= ring for lack of =0A> awareness or since the=0A> > proto-41 filtering may b= reak other tunnels the site may employ. However, I do =0A> not have hard ev= idence=0A> > on this. I would be happy if others on the list will refute or= justify this =0A> assumption.=0A> > =0A> > If this assumption is (even par= tially) correct than I think that the ISATAP =0A> router should defend=0A> = > itself.=0A> =0A> If there is operational assurance of filtering, then I t= hink there=0A> is no problem. For the other cases, I am beginning to come a= round=0A> to your opinion.=0A> =0A> > Moreover, as I mention below the proo= -41 filtering is not effective in case of =0A> attack=0A> > #3=A0and=A0the = attacker is internal to the site.=0A> =0A> I'll speak more on this below.= =0A> =0A> > So IMHO the best way is the mitigations I suggested and=0A> > t= hat you illustrated below in pseudo-code.=0A> =0A> OK.=0A> =0A> > See=A0fur= ther comments inline.=0A> > =0A> > Gabi=0A> > =0A> > ----- Original Message= ----=0A> > > From: "Templin, Fred L" =0A> > > To: Gabi Nakibly ; v6ops =0A= > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > Sent: Monday, August 24, 2= 009 10:04:34 PM=0A> > > Subject: RE: Routing loop attacks using IPv6 tunnel= s=0A> > >=0A> > > Gabi,=0A> > >=0A> > > > -----Original Message-----=0A> > = > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > Sent: Monday, = August 24, 2009 4:44 AM=0A> > > > To: Templin, Fred L; v6ops=0A> > > > Cc: = ipv6@ietf.org; secdir@ietf.org=0A> > > > Subject: Re: Routing loop attacks = using IPv6 tunnels=0A> > > >=0A> > > > Fred,=0A> > > > I=A0initially very m= uch=A0liked your suggestion regarding the check=A0of the=0A> > > neighbor c= ache before=0A> > > > forwarding a packet into the tunnel.=A0It truly addre= sses the root cause of =0A> the=0A> > > problem ans is simple=0A> > > > eno= ugh to implement. However, I realized that an attacker can send a=0A> > > s= poofed=A0RS to the ISATAP router=0A> > > > as if it came from the 6to4 rela= y. The router would then send=A0a RA=A0to =0A> it=A0and=0A> > > consequentl= y change its=0A> > > > neighbor cache. So it seems=A0that this defense does= not add much.=A0Wouldn't =0A> you=0A> > > agree?=0A> > >=0A> > > I agree t= hat my proposed mitigation is only useful when there=0A> > > is assurance o= f a coherent neighbor cache in the ISATAP router.=0A> > > That would be tru= e in the case in which the ISATAP router is=0A> > > located within a site p= rotected by border routers that perform=0A> > > ip-proto-41 and ingress fil= tering, and in which there is no=0A> > > untraceable IPv4 source address sp= oofing. So AFAICT, my proposed=0A> > > mitigation is still necessary for pr= eventing attack #3 when=0A> > > ISATAP routers A and B are on separate ISAT= AP links within=0A> > > the same site-internal IPv4 routing region.=0A> > >= =0A> > =0A> > This is only true when the attacker is outside the site and p= roto-41 filtering =0A> is employed. If the=0A> > attacker is internal to th= e site then the proto-41 filtering will not help and =0A> the neighbor cach= e can=0A> > be poisoned.=0A> =0A> Since the ISATAP checks require that the = IPv6 source embed the=0A> IPv4 source and/or the IPv4 source is a PRL route= r, you must be=0A> speaking here about IPv4 source address spoofing from wi= thin the=0A> site. For sites that allow intra-site source address spoofing,= =0A> I think much more serious problems could manifest themselves=0A> that = would be completely unrelated to ISATAP. I believe you=0A> will also find o= ther automatic tunneling protocols besides=0A> ISATAP that operate under an= assumption of no intra-site IPv4=0A> source address spoofing. =0A> =0A> > = > > I completely agree with your observation on the non-feasibility of=0A> = > > verifying=A0that the=0A> > > > destination=A0ISATAP address does not in= clude=A0a local=A0IPv4 address=A0since the=0A> > > ISATAP address may inclu= de=0A> > > > a private IPv4 address. On the other hand, a check on public I= Pv4 =0A> addresses is=0A> > > acceptable.=A0If the=0A> > > > check would be= done only on ISATAP addresses that include public IPv4=0A> > > addresses t= hen this will=0A> > > > eliminate the attacks in which the two victims resi= de=A0at different sites. =0A> Note=0A> > > that if attack #3=A0is=0A> > > >= launched on two ISATAP routers=A0having private addresses at two different= =0A> sites=0A> > > then the attack will=0A> > > > not work anyway since on= e router can not send a direct=A0IPv4 packet to the=0A> > > other. In addit= ion,=0A> > > > to=A0mitigate attacks in which the other victim is a 6to4 re= lay (such as =0A> attack=0A> > > #1) then a check would=0A> > > > have to b= e done on a 6to4 address, i.e. the destination address must not =0A> be=0A>= > > "2002:> > the ISATAP router>::*". In this case the IPv4 address must b= e =0A> public,=0A> > > according to=0A> > > >=A0 the 6to4 spec.=0A> > > >= =0A> > > > As you also noted there is another problem with this check since= the =0A> string=0A> > > "200::5EFE" is not unique=0A> > > > to ISATAP link= s. On the other hand, it seems that the probability to =0A> encounter=0A> >= > a non-malicious packet=0A> > > > with a destination address having an II= D that equals "200:5EFE:> IPv4 =0A> address>" is=0A> > > > pretty slim.=0A>= > > >=0A> > > > This check is definitely not a=A0perfect solution, and I s= ure hope that =0A> someone=0A> > > will come up with a=0A> > > > better one= for mitigating the routing loops. However, I would be happy if=0A> > > the= re is some kind of other=0A> > > > mitigation=A0measures besides packet fil= tering=A0(proto-41 and ingress) =0A> by=A0other=0A> > > nodes (which=A0does= not=0A> > > > necessarily exist).=0A> > >=0A> > > You seem to be envisioni= ng a scenario of ISATAP router operation=0A> > > with public IPv4 addresses= and outside of any site border routers=0A> > > that perform ingress filter= ing and ip-proto-41 filtering. That has=0A> > > traditionally been seen as = the domain of 6to4, but I am happy to=0A> > > discuss the possibility of wh= at I called the "inside-out ISATAP=0A> > > model" in a list message long ag= o (which AFAICT is the scenario=0A> > > you are alluding to).=0A> > >=0A> >= =0A> > Well,=A0I am referring to any=A0ISATAP deployment=A0with public IPv= 4 addresses and =0A> no proto-41 filtering. I=0A> > imagine that in practic= e there are such deployments which are not the =0A> "inside-out ISATAP mode= l"=A0.=0A> > However, I must admit that I do not rely here on hard evidence= .=0A> > =0A> > > So, if the public IPv4 Internet were considered as one gig= antic=0A> > > "site" and we wanted to do ISATAP on that site, it would be n= ice=0A> > > to divide the site into multiple logical partitions, with each= =0A> > > partition identified by a PRL name and a unique set of IPv6=0A> > = > prefixes. But then, we have the scenario you are describing in=0A> > > wh= ich we can't trust the integrity of the ISATAP router's=0A> > > neighbor ca= che due to the possibility for untraceable IPv4=0A> > > source address spoo= fing such that the neighbor cache check=0A> > > mitigation can be subverted= .=0A> > >=0A> > > This means that if we want to support the inside-out ISAT= AP=0A> > > model then the routing loops could be mitigated either by=0A> > = > 1) implementing the destination address checks you are=0A> > > suggesting= , or 2) by not allowing ISATAP router interfaces=0A> > > that are not behin= d filtering border routers to advertise=0A> > > non-link-local on-link IPv6= prefixes and/or forward packets=0A> > > from non-link-local prefixes in th= e first place.=0A> > >=0A> > > If we took the easy way out and did 2), then= the entire=0A> > > IPv4 Internet would look like one gigantic ISATAP link = that=0A> > > only did IPv6 link-local. So, nodes could ping6 each others'= =0A> > > ISATAP link-local addresses but that's about it.=0A> > >=0A> > > I= f we took the more ambitious route and allowed ISATAP to=0A> > > flourish f= ully within the global IPv4 Internet, then we=0A> > > would essentially be = deprecating 6to4 - so it isn't=0A> > > surprising that your address checks = mostly involve 6to4=0A> > > suppression. Assuming this, if I read your atta= ck scenarios=0A> > > 1 through 3 correctly then scenarios 1 and 3 are mitig= ated=0A> > > by a receive-side check and scenario 2 is mitigated by a=0A> >= > send-side check. In particular, the pseudo-code would be:=0A> > >=0A> > = > =A0 isatap_rcv() {=0A> > > =A0 =A0 ...=0A> > > =A0 =A0 if (dst =3D=3D "20= 02:::*")=0A> > > =A0 =A0 =A0 drop_pkt(); /* attack #1 mitigation */=0A> > >= =0A> > > =A0 =A0 if (dst =3D=3D "*::0200:5efe:")=0A> > > =A0=A0=A0 drop_pkt= (); /* attack #3 mitigation */=0A> > > =A0 =A0 ...=0A> > > =A0 }=0A> > >=0A= > > =0A> > Correct (with the correction you sent after this email).=0A> =0A= > OK.=0A> =0A> > > =A0 isatap_xmt() {=0A> > > =A0 =A0 ...=0A> > > =A0 =A0 i= f (dst =3D=3D "*::0200:5efe:192.88.99.1")=0A> > > =A0 =A0 =A0 drop_pkt(); /= * attack #2 mitigation */=0A> > > =A0 =A0 ...=0A> > > =A0 }=0A> > =0A> > Th= is will not necessarily work, since the 6to4 relay may have a=A0unicast =0A= > address the ISATAP router may=0A> > not be aware of. The best way to miti= gate attack #2 is=A0by the 6to4 relay with =0A> a check similar to that=0A>= > of attack #2 above. IMO, the second best way, as Remi suggested on anoth= er =0A> thread, is for the ISATAP=0A> > router to drop the packet if (src= =A0 =3D=3D 2002:::*"). However, this =0A> check is useful only=0A> > when t= he 6to4 relay validates that the IPv6 source address corresponds to the =0A= > IPv4 one (this is=0A> > in=A0accordance=A0with the 6to4 spec, however it = does not always get implemented). =0A> If this is not true=0A> > then the a= ttacker does not have to send the attack packet with such an =0A> address.= =0A> =0A> Keeping with the philosophy of the ISATAP router defending itself= ,=0A> I believe it would be best to take Remi's suggestion and lay any=0A> = complications at the doorstep of the 6to4 relay if it fails to=0A> adhere t= o the spec.=0A> =0A> Thanks - Fred=0A> fred.l.templin@boeing.com=0A> =0A> >= > Does the above look right to you? And is this everything,=0A> > > or are= there other scenarios we need to consider?=0A> > >=0A> > =0A> > =0A> > > T= hanks - Fred=0A> > > fred.l.templin@boeing.com=0A> > >=0A> > > >=0A> > > > = Gabi=0A> > > >=0A> > > > ----- Original Message ----=0A> > > > From: "Templ= in, Fred L"=0A> > > > To: Gabi Nakibly ; v6ops=0A> > > > Cc: ipv6@ietf.org;= secdir@ietf.org=0A> > > > Sent: Wednesday, August 19, 2009 6:16:18 PM=0A> = > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > >=0A> > = > > Hi Gabi,=0A> > > >=0A> > > > I'm sorry to have to keep turning this int= o plaintext,=0A> > > > but annotation is difficult otherwise. See below for= =0A> > > > my responses (=3D=3D>):=0A> > > >=0A> > > > ____________________= ____________________=0A> > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.co= m]=0A> > > > Sent: Wednesday, August 19, 2009 1:49 AM=0A> > > > To: Templin= , Fred L; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > Subj= ect: Re: Routing loop attacks using IPv6 tunnels=0A> > > >=0A> > > > Fred,= =0A> > > > See my comments inline ().=0A> > > >=0A> > > > _________________= _______________________=0A> > > > From: "Templin, Fred L"=0A> > > > To: Gab= i Nakibly ; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > Se= nt: Tuesday, August 18, 2009 6:48:45 PM=0A> > > > Subject: RE: Routing loop= attacks using IPv6 tunnels=0A> > > >=0A> > > > Gabi,=0A> > > >=0A> > > > _= _______________________________________=0A> > > > From: Gabi Nakibly [mailt= o:gnakibly@yahoo.com]=0A> > > > Sent: Tuesday, August 18, 2009 3:29 AM=0A> = > > > To: Templin, Fred L; v6ops=0A> > > > > Cc: ipv6@ietf.org; secdir@ietf= .org=0A> > > > > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> >= > > >=0A> > > > > Indeed the ISATAP interface of the ISATAP router is mean= t=0A> > > > > to be an enterprise-interior (note that=A0it is still=A0assum= ed=0A> > > > > that the associated IPv4 address is=A0non-private). As=A0we= =0A> > > > > explicitly note in the paper, the first three attacks=A0will= =0A> > > > > be mitigated=A0if proper protocol-41 filtering is deployed on= =0A> > > > > the site's border. However, note that RFC5214 does not mandate= =0A> > > > > or require this filtering.=0A> > > >=0A> > > > The RFC5214 Sec= urity Considerations makes clear the=0A> > > > consequences of not implemen= ting IPv4 ingress filtering=0A> > > > and ip-protocol-41 filtering (i.e., a= possible spooing=0A> > > > attack in which spurious ip-protocol-41 packets= are=0A> > > > injected into an ISATAP link from outside). RFC5214=0A> > > = > Section 6.2 additionally requires that an ISATAP interface's=0A> > > > lo= cator set MUST NOT span multiple sites. This means that the=0A> > > > ISATA= P interface must not decapsulate nor source ip-proto-41=0A> > > > packets w= ithin multiple sites, where the enterprise interior=0A> > > > is site #1 an= d the global Internet is site #2. ip-protocol-41=0A> > > > filtering is the= way in which the ISATAP interface is=0A> > > > restricted to a single site= .=0A> > > >=0A> > > > Now let me see that I understand Section 6.2 correctl= y. In=0A> > > > attack #2, for example, I assume the ISATAP router has two= =0A> > > > physical interfaces. A site-internal IPv4 interface with an=0A> = > > > address IPisatap and a site-external IPv6 interface. I also=0A> > > >= assume that there=A0is another border router which connects the=0A> > > > = site to the IPv4 Internet.=A0The ISATAP router has an ISATAP=0A> > > > inte= rface with a single locator: (IPisatap, site-internal=0A> > > > interface).= =A0When the ISATAP router gets an IPv6 via its=0A> > > > external interface= it will encapsulate the packet accordingly=0A> > > > and forward it throug= h the internal IPv4 interface. If the=0A> > > > encapsulated packet is=A0de= stined to a node outside the site=0A> > > > then the only thing that stops = it is=A0a proto-41 filtering=0A> > > > at the=A0other border router of the = site. Did I get this right?=0A> > > >=0A> > > >=0A> > > > =3D=3D> In this c= ase, yes - the ip-proto-41 filtering is at a=0A> > > > =3D=3D> border route= r. I know of at least one major enterprise=0A> > > > =3D=3D> network that d= oes this.=0A> > > >=0A> > > > > It is only mentioned as a possible mitigati= on against=0A> > > > > incoming spurious protocol-41 packets. In addition,= =0A> > > > > Section 10 of RFC5214 only mentions=A0ingress not=A0egress=0A>= > > > > filtering.=A0Hence it=A0will not stop attack #2.=0A> > > >=0A> > >= > We are now talking about ip-proto-41 filtering; not ingress=0A> > > > fi= ltering. ip-proto-41 filtering is in both directions. It=0A> > > > prevents= ip-proto-41 packets from entering the enterprise=0A> > > > interior ISATAP= site from the Internet and prevents=0A> > > > ip-proto-41 packets from ent= ering the Internet ISATAP=0A> > > > site from the enterprise interior. Else= the ISATAP=0A> > > > interface would span multiple sites.=0A> > > >=0A> > = > > Besides, "ingress" filtering is not about packets coming=0A> > > > from= the Internet into the end site, but rather it is=0A> > > > about packets l= eaving the end site and going out into=0A> > > > the Internet. RFC2827 (BCP= 38) documents ingress filtering.=0A> > > >=0A> > > > OK. I see what you are= saying here.=0A> > > >=0A> > > >=0A> > > > =3D=3D> OK.=0A> > > >=0A> > > >= > In addition,=0A> > > > > as mentioned, protocol-41 filtering is not help= ful when=0A> > > > > attack #3 is launched on two routers that reside in th= e=0A> > > > > same site. Note that=A0it=A0may be=A0possible for=A0the attac= k=0A> > > > > packet=A0to be sourced from outside the site unless proper=0A= > > > > > filtering of incoming IPv6 packets is deployed. If the=0A> > > > = > attacker resides in the site, usually ingress filtering=0A> > > > > will = not be helpful since it is deployed in general on=0A> > > > > the site's bo= rder.=0A> > > >=0A> > > > Here, we have the ISATAP router in both cases sou= rcing a=0A> > > > packet from a foreign prefix.=0A> > > >=0A> > > > Well, I= do not see how this is correct. In attacks #1 and #3 the ISATAP =0A> route= r=0A> > > sources (actually=0A> > > > forwards) an IPv6=A0packet with=A0a s= ource address having=A0the =0A> corresponding=A0prefix=0A> > > of the ISATA= P tunnel.=0A> > > > In attacks #2 and #3 the ISATAP router sources and IPv4= packet with its =0A> own=0A> > > IPv4 address as the=0A> > > > source addr= ess.=0A> > > >=0A> > > >=0A> > > > =3D=3D> There were a number of errors in= what I said in my last=0A> > > > =3D=3D> message, so let me see if I can g= et it right here:=0A> > > > =3D=3D>=0A> > > > =3D=3D> In attacks #1 and #2 = there are two cases to consider. Case=0A> > > > =3D=3D> 1 in which a border= router separates the 6to4 relay from the=0A> > > > =3D=3D> ISATAP router, = and case 2 in which no border router separates=0A> > > > =3D=3D> the 6to4 r= elay from the ISATAP router.=0A> > > > =3D=3D>=0A> > > > =3D=3D> In attack = #1, we have an IPv6 packet with a local source=0A> > > > =3D=3D> address en= tering the site from the outside. IPv6 ingress=0A> > > > =3D=3D> filtering = at the site border router should prevent the=0A> > > > =3D=3D> packet from = entering the site in the first place. If the=0A> > > > =3D=3D> 6to4 relay r= outer is outside the site then ip-proto-41=0A> > > > =3D=3D> filtering at t= he border router will block the attack in=0A> > > > =3D=3D> the first place= anyway. If the relay router is *inside*=0A> > > > =3D=3D> the site, then t= he IPv6 ingress filtering is the lone=0A> > > > =3D=3D> mitigation. The end= result is that the 6to4 relay should=0A> > > > =3D=3D> really be positione= d outside of the site's border routers;=0A> > > > =3D=3D> otherwise, it cou= ld be spoofed into thinking that the=0A> > > > =3D=3D> ISATAP router is a 6= to4 router and not an ISATAP router.=0A> > > > =3D=3D>=0A> > > > =3D=3D> In= attack #2, we have an IPv6 packet with a foreign source=0A> > > > =3D=3D> = address being forwarded by the ISATAP router to a 6to4=0A> > > > =3D=3D> re= lay, but I mis-spoke when I said that this would be a=0A> > > > =3D=3D> cas= e of the ISATAP router forwarding a packet with a foreign=0A> > > > =3D=3D>= source address out of the ISATAP link. For all the ISATAP=0A> > > > =3D=3D= > router knows, the 6to4 relay is just an ordinary host on=0A> > > > =3D=3D= > the ISATAP link, so the ISATAP router actually believes it=0A> > > > =3D= =3D> is forwarding the packet *into* the ISATAP link (not out of=0A> > > > = =3D=3D> it). But as in attack #1, the attack is blocked by ip-proto-41=0A> = > > > =3D=3D> filtering at the border router between the ISATAP router and= =0A> > > > =3D=3D> the 6to4 relay. If there is no border router between the= ISATAP=0A> > > > =3D=3D> router and the 6to4 relay, then we have an identi= cal instance=0A> > > > =3D=3D> to attack #3 which I will discuss below. But= , the best=0A> > > > =3D=3D> operational practice would again be to have th= e 6to4 relay=0A> > > > =3D=3D> oriented outside of a border router that fil= ters ip-proto-41.=0A> > > > =3D=3D>=0A> > > > =3D=3D> Short summary is that= in attack #1, the 6to4 relay thinks it=0A> > > > =3D=3D> is talking to a 6= to4 router and not an ISATAP router. In=0A> > > > =3D=3D> attack #2, the IS= ATAP router thinks it is talking to a=0A> > > > =3D=3D> simple host on the = link and not a 6to4 relay. In both cases,=0A> > > > =3D=3D> the attacks are= mitigated when there is an ip-proto-41=0A> > > > =3D=3D> filtering border = router between the ISATAP router and the=0A> > > > =3D=3D> 6to4 relay. Ofte= ntimes, the "border router" will be a two-=0A> > > > =3D=3D> interface rout= er that implements 6to4 on a site-external=0A> > > > =3D=3D> IPv4 interface= and implements ISATAP on a site-internal=0A> > > > =3D=3D> IPv4 interface = and performs ip-proto-41 filtering on packets=0A> > > > =3D=3D> from outsid= e the site with an IPv4 destination corresponding=0A> > > > =3D=3D> to the = ISATAP interface. I will discuss attack #3 below:=0A> > > >=0A> > > > This = attack is mitigated by=0A> > > > IPv6 ingress filtering which is an IPv6 se= curity consideration=0A> > > > and not an ISATAP nor IPv4 security consider= ation. BCP=0A> > > > recommendations for network ingress filtering are docu= mented=0A> > > > in RFC2827 and it is expected that IPv6 routers that confi= gure=0A> > > > ISATAP interfaces will implement IPv6 ingress filtering=0A> = > > > according to the BCP.=0A> > > >=0A> > > > So If my last comment is co= rrect than I do not see how ingress filtering =0A> would=0A> > > help here.= The only=0A> > > > case where=A0ingress filtering can help is in case of a= ttack #3 when the =0A> routers=0A> > > reside at the same=0A> > > > site. I= n that case if the attack packet (packet 0) is sent from outside =0A> the= =0A> > > site then ingress=0A> > > > filtering on the border of the site wi= ll drop the packet.=0A> > > >=0A> > > >=0A> > > > =3D=3D> Correct about the= IPv6 ingress filtering at the border,=0A> > > > =3D=3D> but as with attack= #2 my error in the previous message=0A> > > > =3D=3D> was in thinking the = ISATAP router A was forwarding the=0A> > > > =3D=3D> packet *out* of the IS= ATAP link when in fact from the=0A> > > > =3D=3D> ISATAP router's perspecti= ve it is forwarding the packet=0A> > > > =3D=3D> to a simple host *inside* = of the link.=0A> > > > =3D=3D>=0A> > > > =3D=3D> The problem here is that t= he ISATAP router is blindly=0A> > > > =3D=3D> forwarding a packet to a node= that it assumes is a simple=0A> > > > =3D=3D> host on the ISATAP link with= out first verifying that the=0A> > > > =3D=3D> node has demonstrated a will= ingness to participate as a=0A> > > > =3D=3D> host on the link. As you have= pointed out, this can lead=0A> > > > =3D=3D> to strange scenarios when the= anonymous node is a tunnel=0A> > > > =3D=3D> router of some sort that does= not participate in the=0A> > > > =3D=3D> ISATAP link.=0A> > > > =3D=3D>=0A= > > > > =3D=3D> It would not generally be possible for the ISATAP router=0A= > > > > =3D=3D> to check whether the IPv6 destination address is an ISATAP= =0A> > > > =3D=3D> address that embeds one of its own IPv4 addresses, becau= se=0A> > > > =3D=3D> when IPv4 private addresses are used the same IPv4 add= ress=0A> > > > =3D=3D> can (and often does) occur in multiple sites. So for= example,=0A> > > > =3D=3D> if the ISATAP router configures an IPv4 address= 10.0.0.1=0A> > > > =3D=3D> and is asked to forward an IPv6 packet with ISA= TAP=0A> > > > =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where t= he=0A> > > > =3D=3D> IPv6 prefix is foreign, the router can't very well dro= p the=0A> > > > =3D=3D> packet as this would block legitimate communication= s. It=0A> > > > =3D=3D> is also not generally possible to check whether a f= oreign=0A> > > > =3D=3D> link is an ISATAP link by looking for the magic to= ken=0A> > > > =3D=3D> "0:5EFE" as that token only has significance for ISAT= AP=0A> > > > =3D=3D> links and not other link types.=0A> > > > =3D=3D>=0A> = > > > =3D=3D> Instead, the mitigation I think makes the most sense is=0A> >= > > =3D=3D> for the ISATAP router to first verify that the node which=0A> = > > > =3D=3D> it assumes to be a simple ISATAP host has demonstrated a=0A> = > > > =3D=3D> willingness to participate in the link. That can be done=0A> = > > > =3D=3D> by having the ISATAP router first check the neighbor cache=0A= > > > > =3D=3D> when it has a packet to send to verify that there is a=0A> = > > > =3D=3D> cached entry corresponding to the destination. For nodes=0A> = > > > =3D=3D> that are willing ISATAP hosts on the link, there would=0A> > = > > =3D=3D> have been a neighbor cache entry created when the node=0A> > > = > =3D=3D> sends a Router Solicitation to the ISATAP router for the=0A> > > = > =3D=3D> purpose of discovering default router lifetimes and on-=0A> > > >= =3D=3D> link prefixes. So, the simple mitigations is for the ISATAP=0A> > = > > =3D=3D> router to forward the packet only if there is a pre-existing=0A= > > > > =3D=3D> neighbor cache entry and drop the packet otherwise. This=0A= > > > > =3D=3D> implies that the router should keep neighbor cache entires= =0A> > > > =3D=3D> for the duration of the minimum lifetime of the prefixes= =0A> > > > =3D=3D> it advertises in its Router Advertisements.=0A> > > >=0A= > > > > > In general, I would like to point out that indeed as in=0A> > > >= > most other attacks these attacks may also be mitigated by=0A> > > > > pr= oper firewall rules. However, I do not believe that this=0A> > > > > should= be our only answer against these attacks. I believe=0A> > > > > that since= these attacks are made possible due to the=0A> > > > > inherent characteri= stics of the tunnels they=A0should be=0A> > > > > stopped intrinsically as = much as possible by the tunnel=0A> > > > > participants and not relay on ou= tside filtering rules.=0A> > > >=0A> > > > In RFC5214, Section 10 we have: = "restricting access to the=0A> > > > link can be achieved by restricting ac= cess to the site". The=0A> > > > mitigations do exactly that, and in such a= way that ISATAP=0A> > > > nodes can operate with only the necessary and su= fficient=0A> > > > checks. So on this point, I do not share your opinion.= =0A> > > >=0A> > > > What about two ISATAP tunnels that reside on the same = site like in attack =0A> #3.=0A> > > Do you=A0also think that=0A> > > > pro= to-41 filtering should barrier between the two tunnels within the site?=0A>= > > >=0A> > > >=0A> > > > =3D=3D> I think this may be overcome by the disc= ussion above.=0A> > > > =3D=3D> Short story is that operational practices m= ust be=0A> > > > =3D=3D> employed whereby an ISATAP router is not mistaken = for=0A> > > > =3D=3D> a 6to4 router. This is through proper arrangement of= =0A> > > > =3D=3D> 6to4 router/relay interfaces outside of the site border= =0A> > > > =3D=3D> rather than inside, and ISATAP router interfaces inside= =0A> > > > =3D=3D> of the site border rather than outside. Also proper=0A> = > > > =3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at=0A> > > >= =3D=3D> site borders.=0A> > > > =3D=3D>=0A> > > > =3D=3D> Also, when there= are multiple ISATAP links within the=0A> > > > =3D=3D> same local IPv4 rou= ting region, an ISATAP router should=0A> > > > =3D=3D> first verify a node'= s willingness to act as a host on=0A> > > > =3D=3D> the ISATAP link before = blindly sending a packet to it.=0A> > > > =3D=3D>=0A> > > > =3D=3D> Fred=0A= > > > > =3D=3D> fred.l.templin@boeing.com=0A> > > >=0A> > > > Fred=0A> > > = > fred.l.templin@boeing.com=0A> > > >=0A> > > > ___________________________= _____________=0A> > > > From: "Templin, Fred L"=0A> > > > To: Gabi Nakibly = ; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > Sent: Monday= , August 17, 2009 8:35:08 PM=0A> > > > Subject: RE: Routing loop attacks us= ing IPv6 tunnels=0A> > > >=0A> > > >=0A> > > > Gabi,=0A> > > >=0A> > > > Th= anks for publishing this work. In the document, attacks A, B and C=0A> > > = > correspond to a configuration that violates section 6.2 of RFC5214:=0A> >= > >=0A> > > > > 6.2.=A0 ISATAP Interface Address Configuration=0A> > > > >= =0A> > > > > =A0=A0Each ISATAP interface configures a set of locators consi= sting of IPv4=0A> > > > >=A0=A0 address-to-interface mappings from a single= site; i.e., an ISATAP=0A> > > > >=A0=A0 interface's locator set MUST NOT s= pan multiple sites.=0A> > > >=0A> > > > In particular, in scenarios A, B an= d C the IPv4 locator used for ISATAP=0A> > > > is seen both within the ente= rprise as site #1 and within the global =0A> Internet=0A> > > > itself as s= ite #2. If the ISATAP interface is to be used as an enterprise-=0A> > > > i= nterior interface, it should therefore not accept IP-proto-41 packets=0A> >= > > coming from an IPv4 source outside of the enterprise nor source=0A> > = > > IP-proto-41 packets that are destined to an IPv4 node outside of the=0A= > > > > enterprise. This condition should be satisfied by having the site b= order=0A> > > > routers implement IPv4 ingress filtering and ip-protocol-41= filtering as=0A> > > > required in Section 10 of RFC5214.=0A> > > >=0A> > = > > It is mentioned that attack C could also occur when the routers reside= =0A> > > > in the same site, where their addresses may be private. This wou= ld=0A> > > > correspond to a case in which an attacker within the site atta= cks the=0A> > > > site itself, which can easily be traced - especially when= source address=0A> > > > spoofing from a node within the site is prevented= through proper ingress=0A> > > > filtering.=0A> > > >=0A> > > > Fred=0A> >= > > fred.l.templin@boeing.com=0A> > > >=0A> > > > ________________________= ________________=0A> > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]= =0A> > > > Sent: Monday, August 17, 2009 8:21 AM=0A> > > > To: v6ops=0A> > = > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > Subject: Routing loop atta= cks using IPv6 tunnels=0A> > > >=0A> > > > Hi all,=0A> > > > I would like t= o draw the attention of the list to=A0some=A0research=A0results =0A> which= =0A> > > my colleague and I at=0A> > > > the National EW Research=A0& Simul= ation=A0Center have recently published. The=0A> > > research presents a=A0c= lass=0A> > > > of routing loop attacks that abuses 6to4, ISATAP and Teredo.= The=A0paper can =0A> be=0A> > > found at:=0A> > > > http://www.usenix.org/= events/woot09/tech/full_papers/nakibly.pdf=0A> > > >=0A> > > > Here is the = abstract:=0A> > > > IPv6 is the future network layer protocol for the Inter= net. Since it is =0A> not=0A> > > compatible with its=0A> > > > predecessor= , some interoperability mechanisms were designed. An important=0A> > > cate= gory of these=0A> > > > mechanisms is automatic tunnels, which enable IPv6 = communication over an =0A> IPv4=0A> > > network without prior=0A> > > > con= figuration. This category includes ISATAP, 6to4 and Teredo. We present =0A>= a=0A> > > novel class of attacks=0A> > > > that exploit vulnerabilities in= these tunnels. These attacks take =0A> advantage of=0A> > > inconsistencie= s=0A> > > > between a tunnel's overlay IPv6 routing state and the native IP= v6 routing=0A> > > state. The attacks form=0A> > > > routing loops which ca= n be abused as a vehicle for traffic amplification =0A> to=0A> > > facilita= te DoS attacks.=0A> > > > We exhibit five attacks of this class. One of the= presented attacks can =0A> DoS a=0A> > > Teredo server using a=0A> > > > s= ingle packet. The exploited vulnerabilities are embedded in the design of = =0A> the=0A> > > tunnels; hence any=0A> > > > implementation of these tunne= ls may be vulnerable. In particular, the =0A> attacks=0A> > > were tested= =0A> > > > against the ISATAP, 6to4 and Teredo implementations of Windows V= ista and=0A> > > Windows Server 2008 R2.=0A> > > >=0A> > > > I think the re= sults of the research warrant some corrective action. If=0A> > > this=A0ind= eed shall be the=0A> > > > general sentiment of the list, I will be happy w= rite an appropriate I-D. =0A> The=0A> > > mitigation measures we=0A> > > > = suggested in the paper are the best we could think of to completely =0A> el= iminate=0A> > > the problem. However=0A> > > > they are far from perfect si= nce=A0they would require=A0tunnel implementations =0A> to=0A> > > be update= d in case new=0A> > > > types of automatic tunnels are introduced.=0A> > > = >=0A> > > > Your comments are welcome.=0A> > > >=0A> > > > Gabi=0A> > > >= =0A> > > >=0A> > > >=0A> > =0A> > =0A> > =0A=0A=0A=0A From jsorg@allenbusinessmachines.com Mon Aug 31 19:04:40 2009 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31DD83A6877 for ; Mon, 31 Aug 2009 19:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.782 X-Spam-Level: X-Spam-Status: No, score=-17.782 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_NONE=0.1, RELAY_IS_203=0.994, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJTdvgzSE9Nv for ; Mon, 31 Aug 2009 19:04:34 -0700 (PDT) Received: from amsa.com (unknown [203.102.57.175]) by core3.amsl.com (Postfix) with SMTP id 888FF28C219 for ; Mon, 31 Aug 2009 19:04:32 -0700 (PDT) To: Subject: no-reply From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090901020433.888FF28C219@core3.amsl.com> Date: Mon, 31 Aug 2009 19:04:32 -0700 (PDT) Show picture and go to site now!