From melhem.mousallem@aishti.com Tue Sep 1 08:05: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 039953A7030 for ; Tue, 1 Sep 2009 08:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, 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_WEB=0.619, 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_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 sOAKtCVgshx7 for ; Tue, 1 Sep 2009 08:05:48 -0700 (PDT) Received: from 87-205-47-26.adsl.inetia.pl (87-205-181-70.adsl.inetia.pl [87.205.181.70]) by core3.amsl.com (Postfix) with SMTP id 46DFE28C540 for ; Tue, 1 Sep 2009 08:05:24 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090901150525.46DFE28C540@core3.amsl.com> Date: Tue, 1 Sep 2009 08:05:24 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Tue Sep 1 09: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 C46963A6B8C for ; Tue, 1 Sep 2009 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.574 X-Spam-Level: X-Spam-Status: No, score=-4.574 tagged_above=-999 required=5 tests=[AWL=-0.679, 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 CiSj6Jz3nDGZ for ; Tue, 1 Sep 2009 09:56:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86EBB3A62C1 for ; Tue, 1 Sep 2009 09:56:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiWYk-000IiX-Rw for v6ops-data0@psg.com; Tue, 01 Sep 2009 16:50:18 +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 1MiWYb-000Igp-Jq for v6ops@ops.ietf.org; Tue, 01 Sep 2009 16:50:14 +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 n81Gnxbr003496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2009 11:49:59 -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 n81GnwiS001517; Tue, 1 Sep 2009 11:49:59 -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 n81GnwSW001507; Tue, 1 Sep 2009 11:49:58 -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, 1 Sep 2009 09:49:57 -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, 1 Sep 2009 09:49:56 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <373420.97768.qm@web45509.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: Acoqcu8VCR/v6St/SJyVNzJoxoAu2QAsGJeA References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" Cc: , X-OriginalArrivalTime: 01 Sep 2009 16:49:57.0974 (UTC) FILETIME=[3D3D8760:01CA2B24] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Monday, August 31, 2009 12:41 PM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Fred, >=20 > I 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 layer of defense in case the = opposite ISATAP router does not > make the=A0proper check on the destination address. >=20 > isatap_xmt() { > =A0=A0=A0=A0 ... > =A0=A0=A0=A0 if (src =3D=3D "::0200:5efe:") > =A0=A0=A0=A0=A0=A0 drop_pkt(); /* attack #3 mitigation */ > =A0=A0=A0=A0 ... > =A0} Having thought about it a bit, I agree but for ISATAP I see the source address check as a MAY and the destination address check as a SHOULD. In new automatic tunneling protocol specifications that use a different encapsulation format than ip-proto-41, as long as we make the destination address check a MUST before anything gets deployed then the source address check is unnecessary Fred fred.l.templin@boeing.com =20 >=20 > Gabi >=20 > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Friday, August 28, 2009 11:23:40 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > 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 > > > > > > 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. > > > > > > 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. > > > > > > Gabi > > > > > > ----- 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. > > > > > > > > > > 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. > > > > > > > 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). > > > > > > > > > > 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. > > > > > > > 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 } > > > > > > > > > > Correct (with the correction you sent after this email). > > > > OK. > > > > > > =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 } > > > > > > 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? > > > > > > > > > > > > > > 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 >=20 From owner-v6ops@ops.ietf.org Wed Sep 2 14:30: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 54A2D28C23B for ; Wed, 2 Sep 2009 14:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.874 X-Spam-Level: X-Spam-Status: No, score=-4.874 tagged_above=-999 required=5 tests=[AWL=-0.379, 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 W5cNQXKoFEwp for ; Wed, 2 Sep 2009 14:30:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8342C3A7138 for ; Wed, 2 Sep 2009 14:27:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MixGl-000EKf-WF for v6ops-data0@psg.com; Wed, 02 Sep 2009 21:21: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 1MixGh-000EJf-Kq for v6ops@ops.ietf.org; Wed, 02 Sep 2009 21:21:29 +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 n82LKmdu009899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 14:20:48 -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 n82LKlNY024993; Wed, 2 Sep 2009 14:20: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 n82LKlhL024977; Wed, 2 Sep 2009 14:20: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); Wed, 2 Sep 2009 14:20: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Review of 'draft-xu-v6ops-hybrid-framework-00.txt' Date: Wed, 2 Sep 2009 14:20:42 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106599A1B@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of 'draft-xu-v6ops-hybrid-framework-00.txt' Thread-Index: AcosEzn9r9XEbtZGTxSbJCP7y5q29A== From: "Templin, Fred L" To: "v6ops" Cc: , "JiangSheng 66104" , "Brian E Carpenter" X-OriginalArrivalTime: 02 Sep 2009 21:20:43.0541 (UTC) FILETIME=[3AC41450:01CA2C13] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Below is my review of 'draft-xu-v6ops-hybrid-framework-00.txt': Fred fred.l.templin@boeing.com --- 1) Abstract, the phrase "as many as possible" seems at odds with trusting the ISP to make informed choices. Suggest changing this to: "ISP networks may need to support multiple IPv6 connectivity solutions". 2) Section 1, paragraph 3, the phrase: "including the support of configured IPv6-over-IPv4 tunnels" should be shortened to "including the support of IPv6-over-IPv4 tunnels". 3) Section 1, paragraph 3, the phrase: "cannot be sufficient once IPv4 addresses have run out, because it" is not correct, because dual stack can still be used in environments that use IPv4 privacy addresses, which can exist even after the global IPv4 address run-out. Suggest shortening sentence to: "However, the dual stack approach does not allow IPv6-only hosts to communicate with IPv4-only hosts." which is true under any circumstances. 4) Section 1, paragraph beginning with "Each technique...", add VET to the "For example" list, i.e., as: "For example, VET (Virtual Enterprise Traversal [VET]), 6RD (IPv6 Rapid Deployment [6RD]), Port Range ..." 5) Section 1, paragraph beginning with "Up to now", change: "ISP networks need to support as many IPv6 connectivity solutions as is operationally reasonable" to" "ISP networks may need to support multiple IPv6 connectivity solutions". 6) Section 2, third paragraph, the trailing sentence: "Note that IPv6 autoconfiguration is not powerful enough for this purpose." does not seem to add any value and may instead serve only to confuse. Can this sentence be dropped? 7) Section 2, the paragraph beginning: "The hybrid ISP framework", change first sentence to: "The hybrid ISP framework may need to support multiple IPv6 connectivity solutions." 8) Section 3, second paragraph beginning: "In order to find NATs and traverse them,", this text seems to imply that *all* applications need to be made NAT-aware when in fact many/most applications are oblivious to NATs. Is there a certain class of applications this text is meaning to refer to? If so, the assumptions must be stated. 9) Section 4.2 should also cite IPv6 Prefix Options for DHCPv6 [RFC3633]. 10) Section 4.3, DNS SRV is not the only method used for service resolution. Remove the phrase: "using DNS SRV [2782]". From owner-v6ops@ops.ietf.org Wed Sep 2 14:30: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 D21E228C76A for ; Wed, 2 Sep 2009 14:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.864 X-Spam-Level: X-Spam-Status: No, score=-4.864 tagged_above=-999 required=5 tests=[AWL=-0.369, 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 2cibtMNLoUyv for ; Wed, 2 Sep 2009 14:30:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FC813A69DA for ; Wed, 2 Sep 2009 14:27:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MixGZ-000EGe-8J for v6ops-data0@psg.com; Wed, 02 Sep 2009 21:21:19 +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 1MixGV-000ECj-4O for v6ops@ops.ietf.org; Wed, 02 Sep 2009 21:21:17 +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 n82LKYcP003312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Sep 2009 16:20:35 -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 n82LKYGS005918; Wed, 2 Sep 2009 14:20:34 -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 n82LKYST005915; Wed, 2 Sep 2009 14:20:34 -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); Wed, 2 Sep 2009 14:20:34 -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: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' Date: Wed, 2 Sep 2009 14:20:32 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106599A1A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' Thread-Index: Acoqcu8VCR/v6St/SJyVNzJoxoAu2QAsGJeAADaneSA= References: <31484.26522.qm@web45503.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com><373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "v6ops" Cc: "JiangSheng 66104" , , "Brian E Carpenter" X-OriginalArrivalTime: 02 Sep 2009 21:20:34.0025 (UTC) FILETIME=[35180D90:01CA2C13] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Below is my review of 'draft-jiang-v6ops-incremental-cgn-02.txt': Fred fred.l.templin@boeing.com --- 1) Section 1, second paragraph, the sentence beginning "They are too complicated..." is meaningless unless it were to name specific transition mechanisms within specific deployment scenarios. For example, perceived complications may only be relevant when necessary network-supporting infrasturcture is missing. Suggestion is to rewrite the paragraph as follows: "IPv4/IPv6 transition issues therefore become more critical and complicated for the soon-coming global IPv6 deployment. Host-based transition mechanisms alone may not be able to meet the requirements in all cases. Therefore, network supporting functions and/or new transition mechanisms with simple user-side operation are needed." 2) Section 1, paragraph 4, the final two sentences seem to imply that DSLite requires the ISP to upgrade its network to IPv6, but that is incorrect. DSLite can operate as IPv4-in-IPv6-in-IPv4 encapsulation, such that it can operate over IPv4-only networks as long as the CPE and CGN are dual-stacked. These two sentences need to be corrected to reflect this. 3 Section 2.1, the sentence: "The integration of NAT-PT is out of scope for this document." should be changed to: "The integration of such mechanisms is out of scope for this document." 4) Section 2.2, sentence beginning "Other tunneling mechanisms..." should read: "Other tunneling mechanisms such as 6over4 [RFC2529], the Intra-Site Automatic Tunnel Addressing Protocol [RFC5214] and Virtual Enterprise Traversal (VET) [VET] are also considered." 5) Section 2.6, bring back text removed from the -01 in a slightly modified form as follows: "However, for IPv6 traffic, a user behind the DS HG will see normal IPv6 service. It is therefore recommended that all IPv6 tunnels support an MTU of at least 1500 bytes, to ensure that the mechanism does not cause excessive fragmentation of IPv6 traffic nor excessive IPv6 path MTU discovery interactions." 6) Section 3, first part of first sentence, change to: "If the core network transitions to IPv6,". 7) Section 3, paragraph 3 - same comment as 2) above. DSLite does not require an IPv6-only ISP network, and can run as IPv4-in-IPv6-in-IPv4 in an IPv4-only ISP network in which the CPE and CGN are both dual-stacked. The advantages of using DSLite over v4-v4 NATing are that the CPE can use traffic engineering and ingress filtering by selecting specific CGNs through which to direct their traffic. This requires only that the CPE be able to discover the addresses of CGNs in the operator network. That process can be coupled with the ISATAP/VET Potential Router List (PRL) discovery mechanisms, in which case the CGN would be co-resident with an ISATAP/VET router that terminates IPv6-in-IPv4 intra-site tunnels. 8) Section 3.1, end of final sentence of first paragraph says: "so we refer to it non-specifically" but then names a specific service. To keep the sense of the sentence, it would have to be changed to: "so we refer to it non-specifically as "NAT64"." (i.e., and remove the specific citation). I am open to other suggestions. From owner-v6ops@ops.ietf.org Wed Sep 2 16:41: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 615DE3A69DA for ; Wed, 2 Sep 2009 16:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=-0.932, 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 Mg2bSw5fSTB1 for ; Wed, 2 Sep 2009 16:41:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 993283A6B7F for ; Wed, 2 Sep 2009 16:41:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MizOd-000Kcc-Hm for v6ops-data0@psg.com; Wed, 02 Sep 2009 23:37:47 +0000 Received: from [209.85.216.194] (helo=mail-px0-f194.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MizOZ-000Kbi-Q8 for v6ops@ops.ietf.org; Wed, 02 Sep 2009 23:37:45 +0000 Received: by pxi32 with SMTP id 32so1185395pxi.25 for ; Wed, 02 Sep 2009 16:37:43 -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=2HX7pSQQ9DnMsMAD1/1p3wm9fePwK20OcvtT4QaS+9g=; b=HemmeB6G4OYIydhAvH1kbsYF+BAypb6+CSkHhoG1YNNKww6+nqmQ42RztDT+i8O9/S JsNYvXECQQNpvj2twPhNsjs8ul7+Ox+OeckDvrWFnARsDp0Kerm/hNWBPoowd++4r4TI 8SpoEZmi6eEM2kY5N8pqlVu9fuZsJUOq2Fhig= 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=hqSsVjQabD8Q+buJtsT+fnUd1M/zSvm7jKnMd7Wvpr+Gmn3T2UAG+8XlNcKt4rsQIq CHqJuCre9FRlGzxCCLN/kPP6p22Xf8KGGZyvYIuPXS+UrgPYG+1PUgU6Yc8loxqve2xf 4HkmkJtpVzhy0aFe6QWz9p69knGOOJW/+yO74= Received: by 10.114.138.10 with SMTP id l10mr7205971wad.122.1251934663131; Wed, 02 Sep 2009 16:37:43 -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 22sm252989pxi.6.2009.09.02.16.37.41 (version=SSLv3 cipher=RC4-MD5); Wed, 02 Sep 2009 16:37:42 -0700 (PDT) Message-ID: <4A9F01C3.5070700@gmail.com> Date: Thu, 03 Sep 2009 11:37:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" CC: v6ops , JiangSheng 66104 , guoseu@huawei.com, xujf@gsta.com Subject: Re: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' References: <31484.26522.qm@web45503.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com><373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A106599A1A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106599A1A@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thanks for your two reviews, Fred. Sheng is on travel, but we'll respond in due course. Regards Brian Carpenter University of Auckland From molbio@agate.plala.or.jp Thu Sep 3 06:53: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 A62A33A6CF3 for ; Thu, 3 Sep 2009 06:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.389 X-Spam-Level: X-Spam-Status: No, score=-19.389 tagged_above=-999 required=5 tests=[BAYES_80=2, 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_USERONOCOM=1.444, 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_NUMERIC_HELO=2.067, 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_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 MYlkziojfylY for ; Thu, 3 Sep 2009 06:53:04 -0700 (PDT) Received: from 81.184.71.156.dyn.user.ono.com (81.184.71.156.dyn.user.ono.com [81.184.71.156]) by core3.amsl.com (Postfix) with SMTP id 8C7593A6CFF for ; Thu, 3 Sep 2009 06:53:01 -0700 (PDT) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090903135302.8C7593A6CFF@core3.amsl.com> Date: Thu, 3 Sep 2009 06:53:01 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Thu Sep 3 08:10: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 D485E28C281 for ; Thu, 3 Sep 2009 08:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=0.565, 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 cTUWoHZOaGT9 for ; Thu, 3 Sep 2009 08:10:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DB8B28C2BD for ; Thu, 3 Sep 2009 08:10:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjDn1-000Abg-7L for v6ops-data0@psg.com; Thu, 03 Sep 2009 14:59:55 +0000 Received: from web45502.mail.sp1.yahoo.com ([68.180.197.62]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjDn0-000Ab5-2J for v6ops@ops.ietf.org; Thu, 03 Sep 2009 14:59:54 +0000 Received: (qmail 34939 invoked by uid 60001); 3 Sep 2009 14:59:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251989992; bh=apUkm+EQqJbmvbMdAxc2051yDIPA6i0A9tQgVXh+1DY=; 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=HRy2XlOZIG3Yga6w9sLWVbmR89cE0jySv13IYrFqp6dqvvZJLwl5dfn/8dd83w9YWtirzPcZztMWzK87Kfem+3lxelr60LTm1MUhKbGIfbcOPG0UbP67UmIo7Uquw8OwL0oW2OWIu8Vmvw47TlnjtCzUC1QuqTeFgg5MuQIHdvw= 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=LJNwq2127ym4UgeIU0IMpiAHiS7ghVjTwfpdA+oEGNjG76tmziyTGUljAqr1j/GUmBY5et6m8RIrw/4ri2gBEY90L+YYkVLaeewqZsCOnaJWchJz5lt/mw1Xo5ypDMlKDIU68g3BkJm0Y8momK+X/yPI9Snk3oC3eENAxAdUuM4=; Message-ID: <342868.34354.qm@web45502.mail.sp1.yahoo.com> X-YMail-OSG: FOVxRKkVM1mISWYqjxBanU5eM92o1lP5jvu7qnKns8vfW9tXNI2EESOGiontM8tl8.s3Gp3AcqXhYwFK9xGPKxVxS4wpQHNXwBgPC3nZ_Ns5hF1JyBaUdqAJLsuuHVTN5opS6JYbTO.nPyQb9K2zi8.VcNSpmvo640EqYXgrQRvg2gtQdgfegIujJh.mmyxJSFwk_byG_dx6rLCc3Y7yJ3KMPuIIA0ueUG.CSz._IsPNam9U.bMMQ4v6ZAFsUJsMasyozlJt Received: from [93.172.27.171] by web45502.mail.sp1.yahoo.com via HTTP; Thu, 03 Sep 2009 07:59:51 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> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> Date: Thu, 3 Sep 2009 07:59:51 -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: <39C363776A4E8C4A94691D2BD9D1C9A106599177@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: Hi Fred,=0Asee inline.=0A=0AGabi=0A=0A----- Original Message ----=0A> From:= "Templin, Fred L" =0A> To: Gabi Nakibly ; v6ops =0A> Cc: ipv6@ietf.org; secdir@iet= f.org=0A> Sent: Tuesday, September 1, 2009 6:49:56 PM=0A> Subject: RE: Rout= ing loop attacks using IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> > -----Original= Message-----=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > Se= nt: Monday, August 31, 2009 12:41 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> > =0A> > I agree that the source= address check discussed below should be made. I would =0A> also add a fort= h=0A> > check=A0to mitigate attack #3 as a second layer of defense in case = the opposite =0A> ISATAP router does not=0A> > make the=A0proper check on t= he destination address.=0A> > =0A> > isatap_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> =0A> Having thought about it a bit, I agr= ee but for ISATAP I see=0A> the source address check as a MAY and the desti= nation address=0A> check as a SHOULD.=0A=0AWhy do you think so? As=A0I see = it, the two checks mitigate two different attacks.=A0The destination addres= s check=A0defends the ISATAP router=A0against attacks=A0of type 3 in which = it acts as the=A0decapsulator of the attack packet.=A0=A0While, the=A0sourc= e address check=A0defends the ISATAP router=A0against attacks=A0of type 3 i= n which it acts as the=A0ecapsulator of the attack packet.=A0=A0Either of t= hese checks are redundant if the other one is employed by the opposite rout= er of the attack. So I do not see why one of them is a SHOULD and the other= is a MAY. =0A=0A> =0A> In new automatic tunneling protocol specifications = that use a=0A> different encapsulation format than ip-proto-41, as long as= =0A> we make the destination address check a MUST before anything=0A> gets = deployed then the source address check is unnecessary=0A> =0A=0AIn principl= e, I agree with you. However, I am a believer of the "defense in depth" par= adigm: two layers of security are (usually) better than one.=A0Since=A0no o= ne can be absolutely sure that the destination address check shall always b= e implemented correctly at all other routers then=A0it may seem prudent to = also employ the source check as a second layer of defense.=0A=0A> Fred=0A> = fred.l.templin@boeing.com=0A> =0A> > =0A> > Gabi=0A> > =0A> > ----- Origina= l Message ----=0A> > > From: "Templin, Fred L" =0A> > > To: Gabi Nakibly ; = v6ops =0A> > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > Sent: Friday, Aug= ust 28, 2009 11:23:40 PM=0A> > > Subject: RE: Routing loop attacks using IP= v6 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: F= riday, 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 summ= ary of our discussion up until now: the best mitigation =0A> of=A0most of= =0A> > > these=A0attacks is=0A> > > > indeed the proto-41 and ingress filte= ring on the border of the ISATAP =0A> site. If=0A> > > it is indeed=0A> > >= > implemented. I=A0assume that not all sites deploy such filtering for lac= k of=0A> > > awareness or since the=0A> > > > proto-41 filtering may break = other tunnels the site may employ. However, I =0A> do=0A> > > not have hard= evidence=0A> > > > on this. I would be happy if others on the list will re= fute or justify =0A> this=0A> > > assumption.=0A> > > >=0A> > > > If this a= ssumption is (even partially) correct than I think that the =0A> ISATAP=0A>= > > router should defend=0A> > > > itself.=0A> > >=0A> > > If there is ope= rational assurance of filtering, then I think there=0A> > > is no problem. = For the other cases, I am beginning to come around=0A> > > to your opinion.= =0A> > >=0A> > > > Moreover, as I mention below the proo-41 filtering is no= t effective in =0A> case of=0A> > > attack=0A> > > > #3=A0and=A0the attacke= r 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> > > > that you illustrated below in pseudo-code.=0A> > >=0A> > > OK.= =0A> > >=0A> > > > See=A0further comments inline.=0A> > > >=0A> > > > Gabi= =0A> > > >=0A> > > > ----- Original Message ----=0A> > > > > From: "Templin= , Fred L"=0A> > > > > To: Gabi Nakibly ; v6ops=0A> > > > > Cc: ipv6@ietf.or= g; secdir@ietf.org=0A> > > > > Sent: Monday, August 24, 2009 10:04:34 PM=0A= > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > > >= =0A> > > > > Gabi,=0A> > > > >=0A> > > > > > -----Original Message-----=0A>= > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > > > Sen= t: 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 much=A0liked your suggestion regarding th= e check=A0of the=0A> > > > > neighbor cache before=0A> > > > > > forwarding= a packet into the tunnel.=A0It truly addresses the root cause =0A> of=0A> = > > the=0A> > > > > problem ans is simple=0A> > > > > > enough to implement= . However, I realized that an attacker can send a=0A> > > > > spoofed=A0RS = to the ISATAP router=0A> > > > > > as if it came from the 6to4 relay. The r= outer would then send=A0a RA=A0to=0A> > > it=A0and=0A> > > > > consequently= change its=0A> > > > > > neighbor cache. So it seems=A0that this defense d= oes not add =0A> much.=A0Wouldn't=0A> > > 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 ISATAP router= .=0A> > > > > That would be true in the case in which the ISATAP router is= =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 IPv4 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> > > >=0A>= > > > This is only true when the attacker is outside the site and proto-41= =0A> filtering=0A> > > is employed. If the=0A> > > > attacker is internal = to the site then the proto-41 filtering will not help =0A> and=0A> > > the = neighbor cache can=0A> > > > be poisoned.=0A> > >=0A> > > Since the ISATAP = checks require that the IPv6 source embed the=0A> > > IPv4 source and/or th= e IPv4 source is a PRL router, you must be=0A> > > speaking here about IPv4= source address spoofing from within the=0A> > > site. For sites that allow= intra-site source address spoofing,=0A> > > I think much more serious prob= lems could manifest themselves=0A> > > that would be completely unrelated t= o ISATAP. I believe you=0A> > > will also find other automatic tunneling pr= otocols besides=0A> > > ISATAP that operate under an assumption of no intra= -site IPv4=0A> > > source address spoofing.=0A> > >=0A> > > > > > I complet= ely agree with your observation on the non-feasibility of=0A> > > > > verif= ying=A0that the=0A> > > > > > destination=A0ISATAP address does not include= =A0a local=A0IPv4 address=A0since =0A> the=0A> > > > > ISATAP address may i= nclude=0A> > > > > > a private IPv4 address. On the other hand, a check on = public IPv4=0A> > > addresses is=0A> > > > > acceptable.=A0If the=0A> > > >= > > check would be done only on ISATAP addresses that include public IPv4= =0A> > > > > addresses then this will=0A> > > > > > eliminate the attacks i= n which the two victims reside=A0at different =0A> sites.=0A> > > Note=0A> = > > > > that if attack #3=A0is=0A> > > > > > launched on two ISATAP routers= =A0having private addresses at two =0A> different=0A> > > sites=0A> > > > >= then the attack will=0A> > > > > > not work anyway since one router can no= t send a direct=A0IPv4 packet to =0A> the=0A> > > > > other. In addition,= =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 be done on a 6to4 address, i.e. the destination address must =0A>= not=0A> > > be=0A> > > > > "2002:> > the ISATAP router>::*". In this case = the IPv4 address must be=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> > > > > "20= 0::5EFE" is not unique=0A> > > > > > to ISATAP links. On the other hand, it= seems that the probability to=0A> > > encounter=0A> > > > > a non-maliciou= s packet=0A> > > > > > with a destination address having an IID that equals= "200:5EFE:> IPv4=0A> > > address>" is=0A> > > > > > pretty slim.=0A> > > >= > >=0A> > > > > > This check is definitely not a=A0perfect solution, and I= sure hope that=0A> > > someone=0A> > > > > will come up with a=0A> > > > >= > better one for mitigating the routing loops. However, I would be happy = =0A> if=0A> > > > > there is some kind of other=0A> > > > > > mitigation=A0= measures besides packet filtering=A0(proto-41 and ingress)=0A> > > by=A0oth= er=0A> > > > > nodes (which=A0does not=0A> > > > > > necessarily exist).=0A= > > > > >=0A> > > > > You seem to be envisioning a scenario of ISATAP route= r operation=0A> > > > > with public IPv4 addresses and outside of any site = border routers=0A> > > > > that perform ingress filtering and ip-proto-41 f= iltering. That has=0A> > > > > traditionally been seen as the domain of 6to= 4, but I am happy to=0A> > > > > discuss the possibility of what I called t= he "inside-out ISATAP=0A> > > > > model" in a list message long ago (which = AFAICT is the scenario=0A> > > > > you are alluding to).=0A> > > > >=0A> > = > >=0A> > > > Well,=A0I am referring to any=A0ISATAP deployment=A0with publ= ic IPv4 addresses =0A> and=0A> > > no proto-41 filtering. I=0A> > > > imagi= ne that in practice there are such deployments which are not the=0A> > > "i= nside-out ISATAP model"=A0.=0A> > > > However, I must admit that I do not r= ely here on hard evidence.=0A> > > >=0A> > > > > So, if the public IPv4 Int= ernet were considered as one gigantic=0A> > > > > "site" and we wanted to d= o ISATAP on that site, it would be nice=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 hav= e the scenario you are describing in=0A> > > > > which we can't trust the i= ntegrity of the ISATAP router's=0A> > > > > neighbor cache due to the possi= bility for untraceable IPv4=0A> > > > > source address spoofing such that t= he neighbor cache check=0A> > > > > mitigation can be subverted.=0A> > > > = >=0A> > > > > This means that if we want to support the inside-out ISATAP= =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 behind filtering border routers to advertise=0A> > > > > non-link-= local on-link IPv6 prefixes and/or forward packets=0A> > > > > from non-lin= k-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 l= ook like one gigantic ISATAP link that=0A> > > > > only did IPv6 link-local= . So, nodes could ping6 each others'=0A> > > > > ISATAP link-local addresse= s but that's about it.=0A> > > > >=0A> > > > > If we took the more ambitiou= s 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> > > > > suppression. Assuming this, if I read your attack scenario= s=0A> > > > > 1 through 3 correctly then scenarios 1 and 3 are mitigated=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 "2002:::*")=0A> > > > > =A0 =A0 =A0 drop_pkt(); /* attack #= 1 mitigation */=0A> > > > >=0A> > > > > =A0 =A0 if (dst =3D=3D "*::0200:5ef= e:")=0A> > > > > =A0=A0=A0 drop_pkt(); /* attack #3 mitigation */=0A> > > >= > =A0 =A0 ...=0A> > > > > =A0 }=0A> > > > >=0A> > > >=0A> > > > Correct (w= ith the correction you sent after this email).=0A> > >=0A> > > OK.=0A> > >= =0A> > > > > =A0 isatap_xmt() {=0A> > > > > =A0 =A0 ...=0A> > > > > =A0 =A0= if (dst =3D=3D "*::0200:5efe:192.88.99.1")=0A> > > > > =A0 =A0 =A0 drop_pk= t(); /* attack #2 mitigation */=0A> > > > > =A0 =A0 ...=0A> > > > > =A0 }= =0A> > > >=0A> > > > This will not necessarily work, since the 6to4 relay m= ay have a=A0unicast=0A> > > address the ISATAP router may=0A> > > > not be = aware of. The best way to mitigate attack #2 is=A0by the 6to4 relay =0A> wi= th=0A> > > a check similar to that=0A> > > > of attack #2 above. IMO, the s= econd best way, as Remi suggested on another=0A> > > thread, is for the ISA= TAP=0A> > > > router to drop the packet if (src=A0 =3D=3D 2002:::*"). Howev= er, this=0A> > > check is useful only=0A> > > > when the 6to4 relay validat= es that the IPv6 source address corresponds to =0A> the=0A> > > IPv4 one (t= his is=0A> > > > in=A0accordance=A0with the 6to4 spec, however it does not = always get =0A> implemented).=0A> > > If this is not true=0A> > > > then th= e attacker does not have to send the attack packet with such an=0A> > > add= ress.=0A> > >=0A> > > Keeping with the philosophy of the ISATAP router defe= nding 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 f= ails to=0A> > > adhere to the spec.=0A> > >=0A> > > Thanks - Fred=0A> > > f= red.l.templin@boeing.com=0A> > >=0A> > > > > Does the above look right to y= ou? And is this everything,=0A> > > > > or are there other scenarios we nee= d to consider?=0A> > > > >=0A> > > >=0A> > > >=0A> > > > > Thanks - Fred=0A= > > > > > fred.l.templin@boeing.com=0A> > > > >=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: 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 plaintext,=0A> > > > > > but= annotation is difficult otherwise. See below for=0A> > > > > > my response= s (=3D=3D>):=0A> > > > > >=0A> > > > > > __________________________________= ______=0A> > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > >= > > > Sent: Wednesday, 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 IPv6 tunnels=0A> > > > > >=0A> > = > > > > Fred,=0A> > > > > > See my comments inline ().=0A> > > > > >=0A> > = > > > > ________________________________________=0A> > > > > > From: "Templ= in, Fred L"=0A> > > > > > To: Gabi Nakibly ; v6ops=0A> > > > > > Cc: ipv6@i= etf.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.com]=0A> > > > > > Sent: Tuesday, August 18, 2009 3:29 AM=0A> > > > = > > To: Templin, Fred L; v6ops=0A> > > > > > > Cc: ipv6@ietf.org; secdir@ie= tf.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=A0i= t is still=A0assumed=0A> > > > > > > that the associated IPv4 address is=A0= non-private). As=A0we=0A> > > > > > > explicitly note in the paper, the fir= st three attacks=A0will=0A> > > > > > > be mitigated=A0if proper protocol-4= 1 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 Security Considerations makes clea= r the=0A> > > > > > consequences of not implementing 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> > > > > > locator s= et MUST NOT span multiple sites. This means that the=0A> > > > > > ISATAP i= nterface must not decapsulate nor source ip-proto-41=0A> > > > > > packets = within multiple sites, where the enterprise interior=0A> > > > > > is site = #1 and the global Internet is site #2. ip-protocol-41=0A> > > > > > filteri= ng 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 correctly. In=0A> > > > > > attack #2, for example, I assume t= he 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 IS= ATAP router has an ISATAP=0A> > > > > > interface with a single locator: (I= Pisatap, site-internal=0A> > > > > > interface).=A0When the ISATAP router g= ets an IPv6 via its=0A> > > > > > external interface it will encapsulate th= e packet accordingly=0A> > > > > > and forward it through the internal IPv4= interface. If the=0A> > > > > > encapsulated packet is=A0destined to a nod= e outside the site=0A> > > > > > then the only thing that stops it is=A0a p= roto-41 filtering=0A> > > > > > at the=A0other border router of the site. D= id I get this right?=0A> > > > > >=0A> > > > > >=0A> > > > > > =3D=3D> In t= his case, yes - the ip-proto-41 filtering is at a=0A> > > > > > =3D=3D> bor= der router. I know of at least one major enterprise=0A> > > > > > =3D=3D> n= etwork that does this.=0A> > > > > >=0A> > > > > > > It is only mentioned a= s a possible mitigation against=0A> > > > > > > incoming spurious protocol-= 41 packets. In addition,=0A> > > > > > > Section 10 of RFC5214 only mention= s=A0ingress not=A0egress=0A> > > > > > > filtering.=A0Hence it=A0will not s= top attack #2.=0A> > > > > >=0A> > > > > > We are now talking about ip-prot= o-41 filtering; not ingress=0A> > > > > > filtering. ip-proto-41 filtering = is in both directions. It=0A> > > > > > prevents ip-proto-41 packets from e= ntering the enterprise=0A> > > > > > interior ISATAP site from the Internet= and prevents=0A> > > > > > ip-proto-41 packets from entering 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> > > > > > fro= m the Internet into the end site, but rather it is=0A> > > > > > about pack= ets leaving the end site and going out into=0A> > > > > > the Internet. RFC= 2827 (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 m= entioned, 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 attack=0A> > > > > > > packet= =A0to be sourced from outside the site unless proper=0A> > > > > > > filter= ing of incoming IPv6 packets is deployed. If the=0A> > > > > > > attacker r= esides in the site, usually ingress filtering=0A> > > > > > > will not be h= elpful 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 attacks #1 and #3 the = =0A> ISATAP=0A> > > router=0A> > > > > sources (actually=0A> > > > > > forw= ards) an IPv6=A0packet with=A0a source address having=A0the=0A> > > corresp= onding=A0prefix=0A> > > > > of the ISATAP tunnel.=0A> > > > > > In attacks = #2 and #3 the ISATAP router sources and IPv4 packet with =0A> its=0A> > > o= wn=0A> > > > > IPv4 address as the=0A> > > > > > source address.=0A> > > > = > >=0A> > > > > >=0A> > > > > > =3D=3D> There were a number of errors in wh= at 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 w= hich 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 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 ing= ress=0A> > > > > > =3D=3D> filtering at the site border router should preve= nt the=0A> > > > > > =3D=3D> packet from entering the site in the first pla= ce. 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 bloc= k 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 fi= ltering is the lone=0A> > > > > > =3D=3D> mitigation. The end result is tha= t the 6to4 relay should=0A> > > > > > =3D=3D> really be positioned outside = of the site's border routers;=0A> > > > > > =3D=3D> otherwise, it could be = spoofed into thinking that the=0A> > > > > > =3D=3D> ISATAP router is a 6to= 4 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> 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 foreig= n=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 ordina= ry host on=0A> > > > > > =3D=3D> the ISATAP link, so the ISATAP router actu= ally 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 bo= rder router between the ISATAP router and=0A> > > > > > =3D=3D> the 6to4 re= lay. 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> operational practice would again be to have the 6to4 relay=0A> >= > > > > =3D=3D> oriented outside of a border router that filters ip-proto-= 41.=0A> > > > > > =3D=3D>=0A> > > > > > =3D=3D> Short summary is that in at= tack #1, the 6to4 relay thinks it=0A> > > > > > =3D=3D> is talking to a 6to= 4 router and not an ISATAP router. In=0A> > > > > > =3D=3D> attack #2, the = ISATAP router thinks it is talking to a=0A> > > > > > =3D=3D> simple host o= n the link and not a 6to4 relay. In both cases,=0A> > > > > > =3D=3D> the a= ttacks are mitigated when there is an ip-proto-41=0A> > > > > > =3D=3D> fil= tering border router between the ISATAP router and the=0A> > > > > > =3D=3D= > 6to4 relay. Oftentimes, the "border router" will be 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> from outside the site with an IPv4 destination corre= sponding=0A> > > > > > =3D=3D> to the ISATAP interface. I will discuss atta= ck #3 below:=0A> > > > > >=0A> > > > > > This attack is mitigated by=0A> > = > > > > IPv6 ingress filtering which is an IPv6 security consideration=0A> = > > > > > and not an ISATAP nor IPv4 security consideration. BCP=0A> > > > = > > recommendations for network ingress filtering are documented=0A> > > > = > > in RFC2827 and it is expected that IPv6 routers that configure=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 =0A> filtering=0A> > > would=0A> > >= > > help here. The only=0A> > > > > > case where=A0ingress filtering can h= elp is in case of attack #3 when the=0A> > > routers=0A> > > > > reside at = the same=0A> > > > > > site. In that case if the attack packet (packet 0) i= s sent from =0A> outside=0A> > > the=0A> > > > > site then ingress=0A> > > = > > > filtering on the border of the site will drop the packet.=0A> > > > >= >=0A> > > > > >=0A> > > > > > =3D=3D> Correct about the IPv6 ingress filte= ring 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 rout= er A was forwarding the=0A> > > > > > =3D=3D> packet *out* of the ISATAP li= nk 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 problem here = is that the ISATAP router is blindly=0A> > > > > > =3D=3D> forwarding a pac= ket to a node that it assumes is a simple=0A> > > > > > =3D=3D> host on the= ISATAP link without first verifying that the=0A> > > > > > =3D=3D> node ha= s 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 possible for the ISATAP router=0A> > > > > > =3D=3D> to check = whether the IPv6 destination address is an ISATAP=0A> > > > > > =3D=3D> add= ress 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 IPv4 address 10.0.0.= 1=0A> > > > > > =3D=3D> and is asked to forward an IPv6 packet with 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 wel= l drop the=0A> > > > > > =3D=3D> packet as this would block legitimate comm= unications. It=0A> > > > > > =3D=3D> is also not generally possible to chec= k 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 type= s.=0A> > > > > > =3D=3D>=0A> > > > > > =3D=3D> Instead, the mitigation I th= ink 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 s= imple ISATAP host has demonstrated a=0A> > > > > > =3D=3D> willingness to p= articipate in the link. That can be done=0A> > > > > > =3D=3D> by having th= e ISATAP router first check the neighbor cache=0A> > > > > > =3D=3D> when i= t has a packet to send to verify that there is a=0A> > > > > > =3D=3D> cach= ed 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-exis= ting=0A> > > > > > =3D=3D> neighbor cache entry and drop the packet otherwi= se. This=0A> > > > > > =3D=3D> implies that the router should keep neighbor= cache entires=0A> > > > > > =3D=3D> for the duration of the minimum lifeti= me of the prefixes=0A> > > > > > =3D=3D> it advertises in its Router Advert= isements.=0A> > > > > >=0A> > > > > > > In general, I would like to point o= ut that indeed as in=0A> > > > > > > most other attacks these attacks may a= lso be mitigated by=0A> > > > > > > proper firewall rules. However, I do no= t believe that this=0A> > > > > > > should be our only answer against these= attacks. I believe=0A> > > > > > > that since these attacks are made possi= ble due to the=0A> > > > > > > inherent characteristics of the tunnels they= =A0should be=0A> > > > > > > stopped intrinsically as much as possible by t= he tunnel=0A> > > > > > > participants and not relay on outside filtering r= ules.=0A> > > > > >=0A> > > > > > In RFC5214, Section 10 we have: "restrict= ing access to the=0A> > > > > > link can be achieved by restricting access = 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= sufficient=0A> > > > > > checks. So on this point, I do not share your opi= nion.=0A> > > > > >=0A> > > > > > What about two ISATAP tunnels that reside= on the same site like in =0A> attack=0A> > > #3.=0A> > > > > Do you=A0also= think that=0A> > > > > > proto-41 filtering should barrier between the two= tunnels within the =0A> 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 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> sam= e local IPv4 routing 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.c= om=0A> > > > > >=0A> > > > > > ________________________________________=0A>= > > > > > From: "Templin, Fred L"=0A> > > > > > To: Gabi Nakibly ; v6ops= =0A> > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > Sent: Monda= y, August 17, 2009 8:35:08 PM=0A> > > > > > Subject: RE: Routing loop attac= ks using IPv6 tunnels=0A> > > > > >=0A> > > > > >=0A> > > > > > Gabi,=0A> >= > > > >=0A> > > > > > Thanks for publishing this work. In the document, at= tacks A, B and C=0A> > > > > > correspond to a configuration that violates = section 6.2 of RFC5214:=0A> > > > > >=0A> > > > > > > 6.2.=A0 ISATAP Interf= ace Address Configuration=0A> > > > > > >=0A> > > > > > > =A0=A0Each ISATAP= interface configures a set of locators consisting of =0A> IPv4=0A> > > > >= > >=A0=A0 address-to-interface mappings from a single site; i.e., an ISATA= P=0A> > > > > > >=A0=A0 interface's locator set MUST NOT span multiple site= s.=0A> > > > > >=0A> > > > > > In particular, in scenarios A, B and C the I= Pv4 locator used for =0A> ISATAP=0A> > > > > > is seen both within the ente= rprise as site #1 and within the global=0A> > > Internet=0A> > > > > > itse= lf as site #2. If the ISATAP interface is to be used as an =0A> enterprise-= =0A> > > > > > interior interface, it should therefore not accept IP-proto-= 41 packets=0A> > > > > > coming from an IPv4 source outside of the enterpri= se nor source=0A> > > > > > IP-proto-41 packets that are destined to an IPv= 4 node outside of the=0A> > > > > > enterprise. This condition should be sa= tisfied by having the site =0A> border=0A> > > > > > routers implement IPv4= ingress filtering and ip-protocol-41 filtering =0A> as=0A> > > > > > requi= red in Section 10 of RFC5214.=0A> > > > > >=0A> > > > > > It is mentioned t= hat attack C could also occur when the routers reside=0A> > > > > > in the = same site, where their addresses may be private. This would=0A> > > > > > c= orrespond to a case in which an attacker within the site attacks the=0A> > = > > > > site itself, which can easily be traced - especially when source = =0A> address=0A> > > > > > spoofing from a node within the site is prevente= d through proper =0A> ingress=0A> > > > > > filtering.=0A> > > > > >=0A> > = > > > > Fred=0A> > > > > > fred.l.templin@boeing.com=0A> > > > > >=0A> > > = > > > ________________________________________=0A> > > > > > From: Gabi Nak= ibly [mailto:gnakibly@yahoo.com]=0A> > > > > > Sent: Monday, August 17, 200= 9 8:21 AM=0A> > > > > > To: v6ops=0A> > > > > > Cc: ipv6@ietf.org; secdir@i= etf.org=0A> > > > > > Subject: Routing loop attacks using IPv6 tunnels=0A> = > > > > >=0A> > > > > > Hi all,=0A> > > > > > I would like to draw the atte= ntion of the list =0A> to=A0some=A0research=A0results=0A> > > which=0A> > >= > > my colleague and I at=0A> > > > > > the National EW Research=A0& Simul= ation=A0Center have recently published. =0A> The=0A> > > > > research prese= nts a=A0class=0A> > > > > > of routing loop attacks that abuses 6to4, ISATA= P and Teredo. The=A0paper =0A> 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 fu= ture network layer protocol for the Internet. Since it =0A> is=0A> > > not= =0A> > > > > compatible with its=0A> > > > > > predecessor, some interopera= bility mechanisms were designed. An =0A> important=0A> > > > > category of = these=0A> > > > > > mechanisms is automatic tunnels, which enable IPv6 comm= unication over =0A> an=0A> > > IPv4=0A> > > > > network without prior=0A> >= > > > > configuration. This category includes ISATAP, 6to4 and Teredo. We = =0A> present=0A> > > a=0A> > > > > novel class of attacks=0A> > > > > > tha= t exploit vulnerabilities in these tunnels. These attacks take=0A> > > adva= ntage of=0A> > > > > inconsistencies=0A> > > > > > between a tunnel's overl= ay IPv6 routing state and the native IPv6 =0A> routing=0A> > > > > state. T= he attacks form=0A> > > > > > routing loops which can be abused as a vehicl= e for traffic =0A> amplification=0A> > > to=0A> > > > > facilitate DoS atta= cks.=0A> > > > > > We exhibit five attacks of this class. One of the presen= ted attacks =0A> can=0A> > > DoS a=0A> > > > > Teredo server using a=0A> > = > > > > single packet. The exploited vulnerabilities are embedded in the = =0A> design of=0A> > > the=0A> > > > > tunnels; hence any=0A> > > > > > imp= lementation of these tunnels may be vulnerable. In particular, the=0A> > > = attacks=0A> > > > > were tested=0A> > > > > > against the ISATAP, 6to4 and = Teredo implementations of Windows Vista =0A> and=0A> > > > > Windows Server= 2008 R2.=0A> > > > > >=0A> > > > > > I think the results of the research w= arrant some corrective action. If=0A> > > > > this=A0indeed shall be the=0A= > > > > > > general sentiment of the list, I will be happy write an appropr= iate =0A> I-D.=0A> > > The=0A> > > > > mitigation measures we=0A> > > > > >= suggested in the paper are the best we could think of to completely=0A> > = > eliminate=0A> > > > > the problem. However=0A> > > > > > they are far fro= m perfect since=A0they would require=A0tunnel =0A> implementations=0A> > > = to=0A> > > > > be updated in case new=0A> > > > > > types of automatic tunn= els are introduced.=0A> > > > > >=0A> > > > > > Your comments are welcome.= =0A> > > > > >=0A> > > > > > Gabi=0A> > > > > >=0A> > > > > >=0A> > > > > >= =0A> > > >=0A> > > >=0A> > > >=0A> > =0A> > =0A> > =0A> > =0A=0A=0A=0A = From owner-v6ops@ops.ietf.org Fri Sep 4 00:32: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 D9CB53A693E for ; Fri, 4 Sep 2009 00:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=-1.672, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 5aDvmVBvylHS for ; Fri, 4 Sep 2009 00:32:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE46C3A685D for ; Fri, 4 Sep 2009 00:32:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjTBa-0005Ig-N2 for v6ops-data0@psg.com; Fri, 04 Sep 2009 07:26:18 +0000 Received: from [209.85.218.213] (helo=mail-bw0-f213.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjTBG-0005HD-78 for v6ops@ops.ietf.org; Fri, 04 Sep 2009 07:26:11 +0000 Received: by bwz9 with SMTP id 9so490495bwz.41 for ; Fri, 04 Sep 2009 00:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=NfTV9YAslGdaGmnj1MA0DtUtOFVilk4rDq4JoO9pvrw=; b=iJdyJs67+61mJtLK1GPwJYUS5oirpXH504v8bPqF98cVu2vKT8AMWI3RDC/6kKB+hJ 4R1IDUYb+EWR1An4IXy+yAvnIGgFKlOR04r2H6PLlqoePCRDIB2Zk6gyu/ebLufb2LjS s12wYbJpx8SriF/ZgwMUh5a9usRoNw26GMcWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rWb7WCeJuAbmlu3+yn7vAZMJdJToFtQXewsXEHFnh9gzXlvzCtAvY2todnRRpNAsgd vUCJteFQ/9BPKtXRBAmH7/E0tbKYVaojkosw92Mtr0tk5UFrlXSmSIUg69fK0FJR+HVY 1GsZkOTYSFGnWHCmuWdxY2fECwZ+Wv30OkvqI= MIME-Version: 1.0 Received: by 10.103.78.30 with SMTP id f30mr4552629mul.87.1252049155219; Fri, 04 Sep 2009 00:25:55 -0700 (PDT) Date: Fri, 4 Sep 2009 09:25:53 +0200 Message-ID: <8d6a15670909040025sfcde567x58cbd615c417deba@mail.gmail.com> Subject: Hello, Any Ideas as how I can catch up fast From: Edwin Mulenga To: v6ops@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e65aeee02652630472bb6933 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0016e65aeee02652630472bb6933 Content-Type: text/plain; charset=ISO-8859-1 I really would like to actively participate in this working group,.. any ideas to find myself on the right track? Or I need to consult literature? Thanks, Edwin --0016e65aeee02652630472bb6933 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I really would like to actively participate in this working group,.. a= ny ideas to find myself on the right track?=A0 Or I need to consult literat= ure?
=A0
Thanks,
=A0
Edwin
--0016e65aeee02652630472bb6933-- From owner-v6ops@ops.ietf.org Fri Sep 4 13:05: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 C1C553A6833 for ; Fri, 4 Sep 2009 13:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.475 X-Spam-Level: X-Spam-Status: No, score=-4.475 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, 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 qUI7Y7b9IiWX for ; Fri, 4 Sep 2009 13:05:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D2593A67DA for ; Fri, 4 Sep 2009 13:05:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjeAs-000OrC-Q8 for v6ops-data0@psg.com; Fri, 04 Sep 2009 19:10:18 +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 1MjdxR-000Lxg-UL for v6ops@ops.ietf.org; Fri, 04 Sep 2009 18:56:26 +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 n84Iso9S028040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Sep 2009 11:54:51 -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 n84IsoG1012365; Fri, 4 Sep 2009 13:54:50 -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 n84Ism5s012332; Fri, 4 Sep 2009 13:54:50 -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, 4 Sep 2009 11:54:40 -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, 4 Sep 2009 11:54:39 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1065D7C40@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <021A8F28-173E-471C-98E6-1E9A313E9715@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: Acotgesrx7/Syg7JTN6fCheWJl28eAADc+mg References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7539@XCH-NW-7V2.nw.nos.boeing.com> <021A8F28-173E-471C-98E6-1E9A313E9715@free.fr> From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: "Gabi Nakibly" , "v6ops" , "6man 6man" , X-OriginalArrivalTime: 04 Sep 2009 18:54:40.0674 (UTC) FILETIME=[28843020:01CA2D91] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Remi, I couldn't parse most of your message; there is no such thing as a /96 prefix. Fred fred.l.templin@boeing.com > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Friday, September 04, 2009 10:05 AM > To: Templin, Fred L > Cc: Gabi Nakibly; v6ops; 6man 6man; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Comment below >=20 > Le 3 sept. 09 =E0 17:59, Templin, Fred L a =E9crit : >=20 > > Gabi, > > > >> -----Original Message----- > >> From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > >> Sent: Thursday, September 03, 2009 8:00 AM > >> To: Templin, Fred L; v6ops > >> Cc: ipv6@ietf.org; secdir@ietf.org > >> Subject: Re: Routing loop attacks using IPv6 tunnels > >> > >> Hi Fred, > >> see inline. > >> > >> Gabi > >> > >> ----- Original Message ---- > >>> From: "Templin, Fred L" > >>> To: Gabi Nakibly ; v6ops > >>> Cc: ipv6@ietf.org; secdir@ietf.org > >>> Sent: Tuesday, September 1, 2009 6:49:56 PM > >>> Subject: RE: Routing loop attacks using IPv6 tunnels > >>> > >>> Gabi, > >>> > >>>> -----Original Message----- > >>>> From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > >>>> Sent: Monday, August 31, 2009 12:41 PM > >>>> To: Templin, Fred L; v6ops > >>>> Cc: ipv6@ietf.org; secdir@ietf.org > >>>> Subject: Re: Routing loop attacks using IPv6 tunnels > >>>> > >>>> Fred, > >>>> > >>>> I agree that the source address check discussed below should be > >>>> made. I would > >>> also add a forth > >>>> check to mitigate attack #3 as a second layer of defense in case > >>>> the opposite > >>> ISATAP router does not > >>>> make the proper check on the destination address. > >>>> > >>>> isatap_xmt() { > >>>> ... > >>>> if (src =3D=3D "::0200:5efe:") > >>>> drop_pkt(); /* attack #3 mitigation */ > >>>> ... > >>>> } > >>> > >>> Having thought about it a bit, I agree but for ISATAP I see > >>> the source address check as a MAY and the destination address > >>> check as a SHOULD. >=20 >=20 > The two following scenarios show in my understanding that ISATAP > routers SHOULD check Source addresses of packets they receive in IPv6: >=20 > SCENARIO 1: between two ISATAP routers A and B >=20 > ISATAP router A receives in IPv6: > Dst6 =3D . router B> > Src6 =3D . router A> >=20 > If ISATAP router A doesn't discard the packet because of its > source address, it will encapsulate it with: > Dst4 =3D > Src4 =3D >=20 > Then, ISATAP router B finds that Src6 and Src4 are consistent, and > forwards the IPv6 packet to ISATAP router A. > The routing loop is in place. >=20 > SCENARIO 2: between an ISATAP router and a 6to4 relay router >=20 > The ISATAP router receives in IPv6: >=20 > Dst6 =3D . 6to4 relay> > Src6 =3D 2002::/16 . >=20 > If it doesn't discard the packet because of its source address, it > will encapsulate it with: > Dst4 =3D > Src4 =3D >=20 > Then, the 6to4 relay finds that Src6 and Src4 are consistent, and > forwards the IPv6 packet to the ISATAP router. > The routing loop is in place. >=20 > Anything missing? >=20 > Regards, > RD >=20 From owner-v6ops@ops.ietf.org Sun Sep 6 16:58: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 293533A67F1 for ; Sun, 6 Sep 2009 16:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.913 X-Spam-Level: X-Spam-Status: No, score=0.913 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5QgtjEfN3yB for ; Sun, 6 Sep 2009 16:58:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 129A53A6452 for ; Sun, 6 Sep 2009 16:58:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkREo-00040c-FC for v6ops-data0@psg.com; Sun, 06 Sep 2009 23:33:38 +0000 Received: from [119.145.14.66] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkQbh-0001CH-VL for v6ops@ops.ietf.org; Sun, 06 Sep 2009 22:57:14 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPK00752NKNHM@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Mon, 07 Sep 2009 06:53:12 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPK00GZANKNL9@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Mon, 07 Sep 2009 06:53:11 +0800 (CST) Received: from JiangXiong (190-49-122-111.speedy.com.ar [190.49.122.111]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPK00MO4NKI6U@szxml02-in.huawei.com>; Mon, 07 Sep 2009 06:53:11 +0800 (CST) Date: Mon, 07 Sep 2009 06:51:53 +0800 From: Sheng Jiang Subject: RE: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' In-reply-to: <39C363776A4E8C4A94691D2BD9D1C9A106599A1A@XCH-NW-7V2.nw.nos.boeing.com> To: "'Templin, Fred L'" , 'v6ops' , 'Fred Baker' Cc: guoseu@huawei.com, 'Brian E Carpenter' Reply-to: shengjiang@huawei.com Message-id: <58C86C6B78A448A890D98A311A60BBC1@JiangXiong> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acoqcu8VCR/v6St/SJyVNzJoxoAu2QAsGJeAADaneSAA0SxSUA== References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A106599A1A@XCH-NW-7V2.nw.nos.boeing.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, Templin, Thanks so much for your comments. Can I ask you a question here: overall, do you think this draft is suitable for v6ops charter and mature enough to be adopted as wg file? Most of your comments are accepted and will be reflected in the next version except for point 5. Actually, I am with you and these texts were in the earlier version. However, Fred thought any normative material were not suitable for 6vops wg and should be removed. Apparently, a recommendation for MTU is normative rather than operational. So, unless Fred confirms that's fine I cannot put the MTU text back. Fred? Many thanks and best regards, Sheng > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Templin, Fred L > Sent: Thursday, September 03, 2009 5:21 AM > To: v6ops > Cc: JiangSheng 66104; guoseu@huawei.com; Brian E Carpenter > Subject: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' > > Below is my review of 'draft-jiang-v6ops-incremental-cgn-02.txt': > > Fred > fred.l.templin@boeing.com > > --- > > 1) Section 1, second paragraph, the sentence beginning > "They are too complicated..." is meaningless unless it > were to name specific transition mechanisms within specific > deployment scenarios. For example, perceived complications > may only be relevant when necessary network-supporting > infrasturcture is missing. Suggestion is to rewrite the > paragraph as follows: > > "IPv4/IPv6 transition issues therefore become more critical > and complicated for the soon-coming global IPv6 deployment. > Host-based transition mechanisms alone may not be able to > meet the requirements in all cases. Therefore, network > supporting functions and/or new transition mechanisms > with simple user-side operation are needed." > > 2) Section 1, paragraph 4, the final two sentences seem to > imply that DSLite requires the ISP to upgrade its network > to IPv6, but that is incorrect. DSLite can operate as > IPv4-in-IPv6-in-IPv4 encapsulation, such that it can > operate over IPv4-only networks as long as the CPE and > CGN are dual-stacked. These two sentences need to be > corrected to reflect this. > > 3 Section 2.1, the sentence: "The integration of NAT-PT > is out of scope for this document." should be changed > to: "The integration of such mechanisms is out of scope > for this document." > > 4) Section 2.2, sentence beginning "Other tunneling > mechanisms..." should read: > > "Other tunneling mechanisms such as 6over4 [RFC2529], the > Intra-Site Automatic Tunnel Addressing Protocol [RFC5214] > and Virtual Enterprise Traversal (VET) [VET] are also > considered." > > 5) Section 2.6, bring back text removed from the -01 in a > slightly modified form as follows: > > "However, for IPv6 traffic, a user behind the DS HG will > see normal IPv6 service. It is therefore recommended that > all IPv6 tunnels support an MTU of at least 1500 bytes, > to ensure that the mechanism does not cause excessive > fragmentation of IPv6 traffic nor excessive IPv6 path > MTU discovery interactions." > > 6) Section 3, first part of first sentence, change to: > "If the core network transitions to IPv6,". > > 7) Section 3, paragraph 3 - same comment as 2) above. DSLite > does not require an IPv6-only ISP network, and can run as > IPv4-in-IPv6-in-IPv4 in an IPv4-only ISP network in which the > CPE and CGN are both dual-stacked. The advantages of using > DSLite over v4-v4 NATing are that the CPE can use traffic > engineering and ingress filtering by selecting specific CGNs > through which to direct their traffic. This requires only > that the CPE be able to discover the addresses of CGNs in > the operator network. That process can be coupled with the > ISATAP/VET Potential Router List (PRL) discovery mechanisms, > in which case the CGN would be co-resident with an ISATAP/VET > router that terminates IPv6-in-IPv4 intra-site tunnels. > > 8) Section 3.1, end of final sentence of first paragraph > says: "so we refer to it non-specifically" but then names > a specific service. To keep the sense of the sentence, > it would have to be changed to: "so we refer to it > non-specifically as "NAT64"." (i.e., and remove the > specific citation). I am open to other suggestions. From owner-v6ops@ops.ietf.org Tue Sep 8 01:29:13 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 91A6D28C0DB for ; Tue, 8 Sep 2009 01:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.283, 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 QCv94LrIj50T for ; Tue, 8 Sep 2009 01:29:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B4BA3A693A for ; Tue, 8 Sep 2009 01:29:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mkvyw-000HDv-GH for v6ops-data0@psg.com; Tue, 08 Sep 2009 08:23:18 +0000 Received: from web45503.mail.sp1.yahoo.com ([68.180.197.71]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mkvyd-000HBp-VH for v6ops@ops.ietf.org; Tue, 08 Sep 2009 08:23:10 +0000 Received: (qmail 45842 invoked by uid 60001); 8 Sep 2009 08:22:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252398178; bh=wYTZXFVuCa5xFSisZ7jArA52U12oWXy73hkC286fz9g=; 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=hXd7JMzipmoiyUq05a1IBQi3wTD4JNJQ7SkLj5iynxEiGHjj2pYx/+1SxKDwAxCPSGvHsUvBBZPztuohdY5vbxEt6FeF4kfjiDK8u6GSJlEC7BGLaUWC2cnuYHbVHku6vTMohuwNp4ivfbAqGE8Ss5HCQTIIh43Z8hAJU6GTCjs= 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=QVTO9ge2At2kNKUFmBJ7hLnoskDbn4qoxO02l0mnbSEafNoMqigrBXTCm7Z7iCOJi/L46Ewnhdh40GS8jfjThvAAIVy71T4rUputnA/9UAsrW/HnO9WUxWnLFblXMhZlJK5p8NZNcUdKqXv5DN7NT2JP7LDcMoixuWr5k3DkWO4=; Message-ID: <446512.44642.qm@web45503.mail.sp1.yahoo.com> X-YMail-OSG: 1GeR6zUVM1kA8Ue3TgwlgfIuEHILrEE9bbBTljS7aVrZBoR6_qxxh4H4cCzLHsGR08ydWCT3ycPtya3UC1pnxRL9snqnM1WbZNOIoDxXIUJy37wi8QB_PpMFjMQY.DmWxU0IJQujArV.GZcSKG.enO2cXR.jsn69LLrr6LuQbMFuHJv145PPhSh9Zk.xFpRVPNuT0usjjqzjNOVdwh0hcIJ5jpCkh7Ysjx9HJ9nYPehm3.BJw1Cc6xbL8t0VufWRU1T2tr1Q Received: from [93.172.27.171] by web45503.mail.sp1.yahoo.com via HTTP; Tue, 08 Sep 2009 01:22:58 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> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7539@XCH-NW-7V2.nw.nos.boeing.com> Date: Tue, 8 Sep 2009 01:22:58 -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: <39C363776A4E8C4A94691D2BD9D1C9A1065D7539@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=0ASe below.=0A=0AGabi=0A----- Original Message ----=0A> From: "Tem= plin, Fred L" =0A> To: Gabi Nakibly ; v6ops =0A> Cc: ipv6@ietf.org; secdir@ietf.org= =0A> Sent: Thursday, September 3, 2009 5:59:36 PM=0A> Subject: RE: Routing = loop attacks using IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> > -----Original Mes= sage-----=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > Sent: = Thursday, September 03, 2009 8:00 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> > Hi Fred,=0A> > see inline.=0A> > =0A> > Ga= bi=0A> > =0A> > ----- Original Message ----=0A> > > From: "Templin, Fred L"= =0A> > > To: Gabi Nakibly ; v6ops =0A> > > Cc: ipv6@ietf.org; secdir@ietf.= org=0A> > > Sent: Tuesday, September 1, 2009 6:49:56 PM=0A> > > Subject: RE= : Routing loop attacks using IPv6 tunnels=0A> > >=0A> > > Gabi,=0A> > >=0A>= > > > -----Original Message-----=0A> > > > From: Gabi Nakibly [mailto:gnak= ibly@yahoo.com]=0A> > > > Sent: Monday, August 31, 2009 12:41 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> > > >=0A> > > > I agree that the source address check discus= sed below should be made. I =0A> would=0A> > > also add a forth=0A> > > > c= heck=A0to mitigate attack #3 as a second layer of defense in case the =0A> = opposite=0A> > > ISATAP router does not=0A> > > > make the=A0proper check o= n the destination address.=0A> > > >=0A> > > > isatap_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> > >=0A> > > Having thought about it a bit,= I agree but for ISATAP I see=0A> > > the source address check as a MAY and= the destination address=0A> > > check as a SHOULD.=0A> > =0A> > Why do you= think so?=0A> =0A> I think so, because ISATAP routers are strongly advised= not=0A> to operate outside of an ip-proto-41 and ingress filtering=0A> sit= e in the first place. Those that do are already operating=0A> at-risk, and = the best we can do is tell them what they=0A> SHOULD/MAY do to avoid proble= ms. =0A> =0A=0AI agree. I was not suggesting otherwise.=0A=0A> > As=A0I see= it, the two checks mitigate two different attacks.=A0The destination=0A> >= address check=A0defends the ISATAP router=A0against attacks=A0of type 3 in= which it =0A> acts as=0A> > the=A0decapsulator of the attack packet.=0A> = =0A> Right.=0A> =0A> > While, the=A0source address check=A0defends the ISAT= AP=0A> > router=A0against attacks=A0of type 3 in which it acts as the=A0eca= psulator of the =0A> attack packet.=0A> =0A> Right.=0A> =0A> > Either of=0A= > > these checks are redundant if the other one is employed by the opposite= router =0A> of the attack.=0A> =0A> Right.=0A> =0A> > So I do not see why = one of them is a SHOULD and the other is a MAY.=0A> =0A> In my view, the de= capsulator is the true victim because=0A> it is the one that receives the t= unneled packet. It has=0A> placed itself in a position to be attacked by op= erating=0A> outside of a filtering site in the first place, so it=0A> reall= y SHOULD do something to protect itself.=0A> =0A> The encapsulator on the o= ther hand is neither the attacker=0A> nor the victim, but rather is an unwi= tting conduit for the=0A> attacker. So, it may want to do something extra o= n behalf=0A> of decapsulators that don't observe the SHOULD but it (like=0A= > the decapsulator) is already operating at-risk outside of=0A> a filtering= site anyway.=A0 =0A> =A0 =0A=0AHere our views part. The encapsulator is as= much a victim as the decapsulator. As a routing loop attack in launched, t= he same number of packets pass through both routers (or through any other h= op on the loop of that matter). Both routers are DoSed equally. So the the = encapsulator has also strong incentive to stop the attack.=0A=0A> > > In ne= w automatic tunneling protocol specifications that use a=0A> > > different = encapsulation format than ip-proto-41, as long as=0A> > > we make the desti= nation address check a MUST before anything=0A> > > gets deployed then the = source address check is unnecessary=0A> > >=0A> > =0A> > In principle, I ag= ree with you. However, I am a believer of the "defense in =0A> depth" parad= igm: two=0A> > layers of security are (usually) better than one.=A0Since=A0= no one can be =0A> absolutely sure that the=0A> > destination address check= shall always be implemented correctly at all other =0A> routers then=A0it = may seem=0A> > prudent to also employ the source check as a second layer of= defense.=0A> =0A> If the decapsulator is already required to implement the= check,=0A> then IMHO any checks at the encapsulator would at most be a=0A>= weak MAY. These checks are not cheap, and IMHO you would find=0A> encapsul= ator implementations that do not honor them regardless=0A> of the strength = of the normative language.=0A> =0A=0AI definitely see what you are saying. = The fundamental question here is whether a node (the encapsulator) should= =A0do what he can=A0to protect itself or=A0is it OK to=A0be passive and rel= y on others=A0(the decapsulator) for protection. I guess there is no defini= te answer here. I guess that the practical answer is that it=A0depends on t= he=A0cost of the self-protection. Do you believe that the cost of source ch= eck is unreasonable?=0A=0A> Fred=0A> fred.l.templin@boeing.com=A0 =0A> =0A>= > > Fred=0A> > > fred.l.templin@boeing.com=0A> > >=0A> > > >=0A> > > > Gab= i=0A> > > >=0A> > > > ----- Original Message ----=0A> > > > > From: "Templi= n, Fred L"=0A> > > > > To: Gabi Nakibly ; v6ops=0A> > > > > Cc: ipv6@ietf.o= rg; secdir@ietf.org=0A> > > > > Sent: Friday, August 28, 2009 11:23:40 PM= =0A> > > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > >= >=0A> > > > > Gabi,=0A> > > > >=0A> > > > > Thanks for your continued corr= espondence, 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> > > > > > Su= bject: Re: Routing loop attacks using IPv6 tunnels=0A> > > > > >=0A> > > > = > > Fred,=0A> > > > > > A quick summary of our discussion up until now: the= best mitigation=0A> > > of=A0most of=0A> > > > > these=A0attacks is=0A> > = > > > > indeed the proto-41 and ingress filtering on the border of the ISAT= AP=0A> > > site. If=0A> > > > > it is indeed=0A> > > > > > implemented. I= =A0assume that not all sites deploy such filtering for =0A> lack of=0A> > >= > > awareness or since the=0A> > > > > > proto-41 filtering may break othe= r tunnels the site may employ. =0A> However, I=0A> > > do=0A> > > > > not h= ave hard evidence=0A> > > > > > on this. I would be happy if others on the = list will refute or justify=0A> > > this=0A> > > > > assumption.=0A> > > > = > >=0A> > > > > > If this assumption is (even partially) correct than I thi= nk that the=0A> > > ISATAP=0A> > > > > router should defend=0A> > > > > > i= tself.=0A> > > > >=0A> > > > > If there is operational assurance of filteri= ng, then I think there=0A> > > > > is no problem. For the other cases, I am= beginning to come around=0A> > > > > to your opinion.=0A> > > > >=0A> > > = > > > Moreover, as I mention below the proo-41 filtering is not effective i= n=0A> > > case of=0A> > > > > attack=0A> > > > > > #3=A0and=A0the attacker = is internal to the site.=0A> > > > >=0A> > > > > I'll speak more on this be= low.=0A> > > > >=0A> > > > > > So IMHO the best way is the mitigations I su= ggested and=0A> > > > > > that you illustrated below in pseudo-code.=0A> > = > > >=0A> > > > > OK.=0A> > > > >=0A> > > > > > See=A0further comments inli= ne.=0A> > > > > >=0A> > > > > > Gabi=0A> > > > > >=0A> > > > > > ----- Orig= inal Message ----=0A> > > > > > > From: "Templin, Fred L"=0A> > > > > > > T= o: 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> > = > > > > > Gabi,=0A> > > > > > >=0A> > > > > > > > -----Original Message----= -=0A> > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > = > > > > > Sent: Monday, August 24, 2009 4:44 AM=0A> > > > > > > > To: Templ= in, 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 much= =A0liked your suggestion regarding the check=A0of =0A> the=0A> > > > > > > = neighbor cache before=0A> > > > > > > > forwarding a packet into the tunnel= .=A0It truly addresses the root =0A> cause=0A> > > of=0A> > > > > the=0A> >= > > > > > problem ans is simple=0A> > > > > > > > enough to implement. How= ever, I realized that an attacker can send =0A> a=0A> > > > > > > spoofed= =A0RS to the ISATAP router=0A> > > > > > > > as if it came from the 6to4 re= lay. The router would then send=A0a =0A> RA=A0to=0A> > > > > it=A0and=0A> >= > > > > > consequently change its=0A> > > > > > > > neighbor cache. So it = seems=A0that this defense does not add=0A> > > much.=A0Wouldn't=0A> > > > >= 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 ISATAP router.=0A> > > > > > > That wo= uld be true in the case in which the ISATAP router is=0A> > > > > > > locat= ed within a site protected by border routers that perform=0A> > > > > > > i= p-proto-41 and ingress filtering, and in which there is no=0A> > > > > > > = untraceable IPv4 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> > > = > > >=0A> > > > > > This is only true when the attacker is outside the site= and proto-41=0A> > > filtering=0A> > > > > is employed. If the=0A> > > > >= > attacker is internal to the site then the proto-41 filtering will not = =0A> help=0A> > > and=0A> > > > > the neighbor cache can=0A> > > > > > be p= oisoned.=0A> > > > >=0A> > > > > Since the ISATAP checks require that the I= Pv6 source embed the=0A> > > > > IPv4 source and/or the IPv4 source is a PR= L router, you must be=0A> > > > > speaking here about IPv4 source address s= poofing from within the=0A> > > > > site. For sites that allow intra-site s= ource address spoofing,=0A> > > > > I think much more serious problems coul= d manifest themselves=0A> > > > > that would be completely unrelated to ISA= TAP. I believe you=0A> > > > > will also find other automatic tunneling pro= tocols besides=0A> > > > > ISATAP that operate under an assumption of no in= tra-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 a= ddress does not include=A0a local=A0IPv4 =0A> address=A0since=0A> > > the= =0A> > > > > > > ISATAP address may include=0A> > > > > > > > a private IPv= 4 address. On the other hand, a check on public IPv4=0A> > > > > addresses = is=0A> > > > > > > acceptable.=A0If the=0A> > > > > > > > check would be do= ne only on ISATAP addresses that include public =0A> IPv4=0A> > > > > > > a= ddresses then this will=0A> > > > > > > > eliminate the attacks in which th= e two victims reside=A0at different=0A> > > sites.=0A> > > > > Note=0A> > >= > > > > that if attack #3=A0is=0A> > > > > > > > launched on two ISATAP ro= uters=A0having private addresses at two=0A> > > different=0A> > > > > sites= =0A> > > > > > > then the attack will=0A> > > > > > > > not work anyway sin= ce one router can not send a direct=A0IPv4 packet =0A> to=0A> > > the=0A> >= > > > > > other. In addition,=0A> > > > > > > > to=A0mitigate attacks in w= hich the other victim is a 6to4 relay =0A> (such as=0A> > > > > attack=0A> = > > > > > > #1) then a check would=0A> > > > > > > > have to be done on a 6= to4 address, i.e. the destination address =0A> must=0A> > > not=0A> > > > >= be=0A> > > > > > > "2002:> > the ISATAP router>::*". In this case the IPv4= address must =0A> be=0A> > > > > public,=0A> > > > > > > according to=0A> = > > > > > > >=A0 the 6to4 spec.=0A> > > > > > > >=0A> > > > > > > > As you = also noted there is another problem with this check since =0A> the=0A> > > = > > string=0A> > > > > > > "200::5EFE" is not unique=0A> > > > > > > > to I= SATAP links. On the other hand, it seems that the probability =0A> to=0A> >= > > > encounter=0A> > > > > > > a non-malicious packet=0A> > > > > > > > w= ith a destination address having an IID that equals "200:5EFE:> =0A> IPv4= =0A> > > > > address>" is=0A> > > > > > > > pretty slim.=0A> > > > > > > >= =0A> > > > > > > > This check is definitely not a=A0perfect solution, and I= sure hope =0A> that=0A> > > > > someone=0A> > > > > > > will come up with = a=0A> > > > > > > > better one for mitigating the routing loops. However, I= would be =0A> happy=0A> > > if=0A> > > > > > > there is some kind of other= =0A> > > > > > > > mitigation=A0measures besides packet filtering=A0(proto-= 41 and =0A> ingress)=0A> > > > > by=A0other=0A> > > > > > > nodes (which=A0= does not=0A> > > > > > > > necessarily exist).=0A> > > > > > >=0A> > > > > = > > You seem to be envisioning a scenario of ISATAP router operation=0A> > = > > > > > with public IPv4 addresses and outside of any site border 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 (whic= h AFAICT is the scenario=0A> > > > > > > you are alluding to).=0A> > > > > = > >=0A> > > > > >=0A> > > > > > Well,=A0I am referring to any=A0ISATAP depl= oyment=A0with public IPv4 =0A> addresses=0A> > > and=0A> > > > > no proto-4= 1 filtering. I=0A> > > > > > imagine that in practice there are such deploy= ments which are not the=0A> > > > > "inside-out ISATAP model"=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 gigantic=0A> > > > > > > "site" and we wanted to do ISATAP on that site= , it would be nice=0A> > > > > > > to divide the site into multiple logical= partitions, with each=0A> > > > > > > partition identified by a PRL name a= nd a unique set of IPv6=0A> > > > > > > prefixes. But then, we have the sce= nario you are describing in=0A> > > > > > > which we can't trust the integr= ity of the ISATAP router's=0A> > > > > > > neighbor cache due to the possib= ility for untraceable IPv4=0A> > > > > > > source address spoofing such tha= t the neighbor cache check=0A> > > > > > > mitigation can be subverted.=0A>= > > > > > >=0A> > > > > > > This means that if we want to support the insi= de-out ISATAP=0A> > > > > > > model then the routing loops could be mitigat= ed either by=0A> > > > > > > 1) implementing the destination address checks= you are=0A> > > > > > > suggesting, or 2) by not allowing ISATAP router in= terfaces=0A> > > > > > > that are not behind filtering border routers to ad= vertise=0A> > > > > > > non-link-local on-link 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), th= en the entire=0A> > > > > > > IPv4 Internet would look like one gigantic IS= ATAP link that=0A> > > > > > > only did IPv6 link-local. So, nodes could pi= ng6 each others'=0A> > > > > > > ISATAP link-local addresses but that's abo= ut it.=0A> > > > > > >=0A> > > > > > > If we took the more ambitious 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 invo= lve 6to4=0A> > > > > > > suppression. 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 scenario 2 is mitigat= ed by a=0A> > > > > > > send-side check. In particular, the pseudo-code wou= ld 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 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 if (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> > > > > > This will not ne= cessarily work, since the 6to4 relay may have =0A> a=A0unicast=0A> > > > > = address the ISATAP router may=0A> > > > > > not be aware of. The best way t= o mitigate attack #2 is=A0by the 6to4 =0A> relay=0A> > > with=0A> > > > > a= check similar to that=0A> > > > > > of attack #2 above. IMO, the second be= st way, as Remi suggested on =0A> another=0A> > > > > thread, is for the IS= ATAP=0A> > > > > > router to drop the packet if (src=A0 =3D=3D 2002:::*"). = However, this=0A> > > > > check is useful only=0A> > > > > > when the 6to4 = relay validates that the IPv6 source address corresponds =0A> to=0A> > > th= e=0A> > > > > IPv4 one (this is=0A> > > > > > in=A0accordance=A0with the 6t= o4 spec, however it does not always get=0A> > > implemented).=0A> > > > > I= f this is not true=0A> > > > > > then the attacker does not have to send th= e attack packet with such an=0A> > > > > address.=0A> > > > >=0A> > > > > K= eeping 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 to the spec.=0A> > > > >=0A> > > > > Thanks - Fred=0A> > > > > = fred.l.templin@boeing.com=0A> > > > >=0A> > > > > > > Does the above look r= ight to you? And is this everything,=0A> > > > > > > or are there other sce= narios we need to consider?=0A> > > > > > >=0A> > > > > >=0A> > > > > >=0A>= > > > > > > Thanks - Fred=0A> > > > > > > fred.l.templin@boeing.com=0A> > = > > > > >=0A> > > > > > > >=0A> > > > > > > > Gabi=0A> > > > > > > >=0A> > = > > > > > > ----- Original Message ----=0A> > > > > > > > From: "Templin, F= red L"=0A> > > > > > > > To: Gabi Nakibly ; v6ops=0A> > > > > > > > Cc: ipv= 6@ietf.org; secdir@ietf.org=0A> > > > > > > > Sent: Wednesday, August 19, 2= 009 6:16:18 PM=0A> > > > > > > > Subject: RE: Routing loop attacks using IP= v6 tunnels=0A> > > > > > > >=0A> > > > > > > > Hi Gabi,=0A> > > > > > > >= =0A> > > > > > > > I'm sorry to have to keep turning this into plaintext,= =0A> > > > > > > > but annotation is difficult otherwise. See below for=0A>= > > > > > > > my responses (=3D=3D>):=0A> > > > > > > >=0A> > > > > > > > = ________________________________________=0A> > > > > > > > From: Gabi Nakib= ly [mailto:gnakibly@yahoo.com]=0A> > > > > > > > Sent: Wednesday, August 19= , 2009 1:49 AM=0A> > > > > > > > To: Templin, Fred L; v6ops=0A> > > > > > >= > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > Subject: Re: Routin= g loop attacks using IPv6 tunnels=0A> > > > > > > >=0A> > > > > > > > Fred,= =0A> > > > > > > > See my comments inline ().=0A> > > > > > > >=0A> > > > >= > > > ________________________________________=0A> > > > > > > > From: "Te= mplin, 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 us= ing IPv6 tunnels=0A> > > > > > > >=0A> > > > > > > > Gabi,=0A> > > > > > > = >=0A> > > > > > > > ________________________________________=0A> > > > > > = > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > > > > > Sent: = Tuesday, August 18, 2009 3:29 AM=0A> > > > > > > > To: Templin, Fred L; v6o= ps=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 me= ant=0A> > > > > > > > > to be an enterprise-interior (note that=A0it is sti= ll=A0assumed=0A> > > > > > > > > that the associated IPv4 address is=A0non-= private). As=A0we=0A> > > > > > > > > explicitly note in the paper, the fir= st three attacks=A0will=0A> > > > > > > > > be mitigated=A0if proper protoc= ol-41 filtering is deployed on=0A> > > > > > > > > the site's border. Howev= er, note that RFC5214 does not mandate=0A> > > > > > > > > or require this = filtering.=0A> > > > > > > >=0A> > > > > > > > The RFC5214 Security Conside= rations makes clear the=0A> > > > > > > > consequences of not implementing = 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 ISAT= AP interface's=0A> > > > > > > > locator set MUST NOT span multiple sites. = This means that the=0A> > > > > > > > ISATAP interface must not decapsulate= nor source ip-proto-41=0A> > > > > > > > packets within multiple sites, wh= ere the enterprise interior=0A> > > > > > > > is site #1 and the global Int= ernet 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 Sect= ion 6.2 correctly. In=0A> > > > > > > > attack #2, for example, I assume th= e ISATAP router has two=0A> > > > > > > > physical interfaces. A site-inter= nal IPv4 interface with an=0A> > > > > > > > address IPisatap and a site-ex= ternal IPv6 interface. I also=0A> > > > > > > > assume that there=A0is anot= her border router which connects the=0A> > > > > > > > site to the IPv4 Int= ernet.=A0The ISATAP router has an ISATAP=0A> > > > > > > > interface with a= single locator: (IPisatap, site-internal=0A> > > > > > > > interface).=A0W= hen the ISATAP router gets an IPv6 via its=0A> > > > > > > > external inter= face it will encapsulate the packet accordingly=0A> > > > > > > > and forwa= rd it through the internal IPv4 interface. If the=0A> > > > > > > > encapsu= lated packet is=A0destined to a node outside the site=0A> > > > > > > > the= n 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 case, yes - the = ip-proto-41 filtering is at a=0A> > > > > > > > =3D=3D> border router. I kn= ow of at least one major enterprise=0A> > > > > > > > =3D=3D> network that = does this.=0A> > > > > > > >=0A> > > > > > > > > It is only mentioned as a = possible mitigation against=0A> > > > > > > > > incoming spurious protocol-= 41 packets. In addition,=0A> > > > > > > > > Section 10 of RFC5214 only men= tions=A0ingress not=A0egress=0A> > > > > > > > > filtering.=A0Hence it=A0wi= ll not stop attack #2.=0A> > > > > > > >=0A> > > > > > > > We are now talki= ng about ip-proto-41 filtering; not ingress=0A> > > > > > > > filtering. ip= -proto-41 filtering is in both directions. It=0A> > > > > > > > prevents ip= -proto-41 packets from entering the enterprise=0A> > > > > > > > interior I= SATAP site from the Internet and prevents=0A> > > > > > > > ip-proto-41 pac= kets from entering the Internet ISATAP=0A> > > > > > > > site from the ente= rprise interior. Else the ISATAP=0A> > > > > > > > interface would span mul= tiple sites.=0A> > > > > > > >=0A> > > > > > > > Besides, "ingress" filteri= ng 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 into=0A> > > > > > > > the Internet. RFC2827 (BCP38) do= cuments ingress filtering.=0A> > > > > > > >=0A> > > > > > > > OK. I see wh= at 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 attack= =0A> > > > > > > > > packet=A0to be sourced from outside the site unless pr= oper=0A> > > > > > > > > filtering of incoming IPv6 packets is deployed. If= the=0A> > > > > > > > > attacker resides in the site, usually ingress filt= ering=0A> > > > > > > > > will not be helpful since it is deployed in gener= al 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> > > > > > > > Wel= l, I do not see how this is correct. In attacks #1 and #3 the=0A> > > ISATA= P=0A> > > > > router=0A> > > > > > > sources (actually=0A> > > > > > > > fo= rwards) an IPv6=A0packet with=A0a source address having=A0the=0A> > > > > c= orresponding=A0prefix=0A> > > > > > > of the ISATAP tunnel.=0A> > > > > > >= > In attacks #2 and #3 the ISATAP router sources and IPv4 packet =0A> with= =0A> > > its=0A> > > > > own=0A> > > > > > > IPv4 address as the=0A> > > > = > > > > 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 ar= e 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 relay from the ISATAP router.=0A> > > > > > > > =3D=3D>=0A= > > > > > > > > =3D=3D> In attack #1, we have an IPv6 packet with a local s= ource=0A> > > > > > > > =3D=3D> address entering 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 router is = outside the site then ip-proto-41=0A> > > > > > > > =3D=3D> filtering at th= e border router will block the attack in=0A> > > > > > > > =3D=3D> the firs= t place anyway. If the relay router is *inside*=0A> > > > > > > > =3D=3D> t= he 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> otherwise, it could be spoofed into thinking that th= e=0A> > > > > > > > =3D=3D> ISATAP router is a 6to4 router and not an ISATA= P router.=0A> > > > > > > > =3D=3D>=0A> > > > > > > > =3D=3D> In attack #2,= we have an IPv6 packet with a foreign source=0A> > > > > > > > =3D=3D> add= ress being forwarded 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 or= dinary host on=0A> > > > > > > > =3D=3D> the ISATAP link, so the ISATAP rou= ter actually believes it=0A> > > > > > > > =3D=3D> is forwarding the packet= *into* the ISATAP link (not out of=0A> > > > > > > > =3D=3D> it). But as i= n 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 =0A> = ISATAP=0A> > > > > > > > =3D=3D> router and the 6to4 relay, then we have an= identical instance=0A> > > > > > > > =3D=3D> to attack #3 which I will dis= cuss below. But, the best=0A> > > > > > > > =3D=3D> operational practice wo= uld again be to have the 6to4 relay=0A> > > > > > > > =3D=3D> oriented outs= ide of a border router that filters ip-proto-41.=0A> > > > > > > > =3D=3D>= =0A> > > > > > > > =3D=3D> Short summary is that in attack #1, the 6to4 rel= ay 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= thinks it is talking to a=0A> > > > > > > > =3D=3D> simple host on the lin= k and not a 6to4 relay. In both cases,=0A> > > > > > > > =3D=3D> the attack= s are mitigated when there is an ip-proto-41=0A> > > > > > > > =3D=3D> filt= ering border router between the ISATAP router and the=0A> > > > > > > > =3D= =3D> 6to4 relay. Oftentimes, the "border router" will be 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-inter= nal=0A> > > > > > > > =3D=3D> IPv4 interface and performs ip-proto-41 filte= ring on packets=0A> > > > > > > > =3D=3D> from outside the site with an IPv= 4 destination corresponding=0A> > > > > > > > =3D=3D> to the ISATAP interfa= ce. I will discuss attack #3 below:=0A> > > > > > > >=0A> > > > > > > > Thi= s attack is mitigated by=0A> > > > > > > > IPv6 ingress filtering which is = an IPv6 security consideration=0A> > > > > > > > and not an ISATAP nor IPv4= security consideration. BCP=0A> > > > > > > > recommendations for network = ingress filtering are documented=0A> > > > > > > > in RFC2827 and it is exp= ected that IPv6 routers that configure=0A> > > > > > > > ISATAP interfaces = will implement IPv6 ingress filtering=0A> > > > > > > > according to the BC= P.=0A> > > > > > > >=0A> > > > > > > > So If my last comment is correct tha= n I do not see how ingress=0A> > > filtering=0A> > > > > would=0A> > > > > = > > help here. The only=0A> > > > > > > > case where=A0ingress filtering ca= n help is in case of attack #3 when =0A> the=0A> > > > > routers=0A> > > > = > > > reside at the same=0A> > > > > > > > site. In that case if the attack= packet (packet 0) is sent from=0A> > > outside=0A> > > > > the=0A> > > > >= > > site then ingress=0A> > > > > > > > filtering on the border of the sit= e will 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 ISATAP link when in fact = from the=0A> > > > > > > > =3D=3D> ISATAP router's perspective it is forwar= ding the packet=0A> > > > > > > > =3D=3D> to a simple host *inside* of the = link.=0A> > > > > > > > =3D=3D>=0A> > > > > > > > =3D=3D> The problem 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> hos= t on the ISATAP link without first verifying that 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 tunne= l=0A> > > > > > > > =3D=3D> router of some sort that does not participate i= n the=0A> > > > > > > > =3D=3D> ISATAP link.=0A> > > > > > > > =3D=3D>=0A> = > > > > > > > =3D=3D> It would not generally be possible for the ISATAP rou= ter=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 address= es 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 IPv4 address 10.0.0.1=0A> > > > > > > > = =3D=3D> and is asked to forward an IPv6 packet with 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 th= e=0A> > > > > > > > =3D=3D> packet as this would block legitimate communica= tions. It=0A> > > > > > > > =3D=3D> is also not generally possible to check= whether a foreign=0A> > > > > > > > =3D=3D> link is an ISATAP link by look= ing for the magic token=0A> > > > > > > > =3D=3D> "0:5EFE" as that token on= ly has significance for ISATAP=0A> > > > > > > > =3D=3D> links and not othe= r link types.=0A> > > > > > > > =3D=3D>=0A> > > > > > > > =3D=3D> Instead, = the mitigation I think makes the most sense is=0A> > > > > > > > =3D=3D> fo= r 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 neighbo= r cache=0A> > > > > > > > =3D=3D> when it has a packet to send to verify th= at there is a=0A> > > > > > > > =3D=3D> cached entry corresponding to the d= estination. For nodes=0A> > > > > > > > =3D=3D> that are willing ISATAP hos= ts 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 li= fetime of the prefixes=0A> > > > > > > > =3D=3D> it advertises in its Route= r 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> > > > > > > > > proper firewall= rules. However, I do not believe that this=0A> > > > > > > > > should be o= ur only answer against these attacks. I believe=0A> > > > > > > > > that si= nce 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> > > > > > > > > parti= cipants and not relay on outside filtering rules.=0A> > > > > > > >=0A> > >= > > > > > In RFC5214, Section 10 we have: "restricting access to the=0A> >= > > > > > > link can be achieved by restricting access to the site". The= =0A> > > > > > > > mitigations do exactly that, and in such a way that ISAT= AP=0A> > > > > > > > nodes can operate with only the necessary and sufficie= nt=0A> > > > > > > > checks. So on this point, I do not share your opinion.= =0A> > > > > > > >=0A> > > > > > > > What about two ISATAP tunnels that res= ide on the same site like in=0A> > > attack=0A> > > > > #3.=0A> > > > > > >= Do you=A0also think that=0A> > > > > > > > proto-41 filtering should barri= er between the two tunnels within =0A> the=0A> > > site?=0A> > > > > > > >= =0A> > > > > > > >=0A> > > > > > > > =3D=3D> I think this may be overcome b= y the discussion above.=0A> > > > > > > > =3D=3D> Short story is that opera= tional practices must be=0A> > > > > > > > =3D=3D> employed whereby an ISAT= AP router is not mistaken for=0A> > > > > > > > =3D=3D> a 6to4 router. This= is through proper arrangement of=0A> > > > > > > > =3D=3D> 6to4 router/rel= ay interfaces outside of the site border=0A> > > > > > > > =3D=3D> rather t= han inside, and ISATAP router interfaces inside=0A> > > > > > > > =3D=3D> o= f 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 routing 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, Fr= ed 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 using IPv6 t= unnels=0A> > > > > > > >=0A> > > > > > > >=0A> > > > > > > > Gabi,=0A> > > = > > > > >=0A> > > > > > > > Thanks for publishing this work. In the documen= t, attacks A, B and =0A> C=0A> > > > > > > > correspond to a configuration = that violates section 6.2 of =0A> RFC5214:=0A> > > > > > > >=0A> > > > > > = > > > 6.2.=A0 ISATAP Interface Address Configuration=0A> > > > > > > > >=0A= > > > > > > > > > =A0=A0Each ISATAP interface configures a set of locators = consisting =0A> of=0A> > > IPv4=0A> > > > > > > > >=A0=A0 address-to-interf= ace mappings from a single site; i.e., an =0A> ISATAP=0A> > > > > > > > >= =A0=A0 interface's locator set MUST NOT span multiple sites.=0A> > > > > > = > >=0A> > > > > > > > In particular, in scenarios A, B and C the IPv4 locat= or used for=0A> > > ISATAP=0A> > > > > > > > is seen both within the enterp= rise as site #1 and within the =0A> global=0A> > > > > Internet=0A> > > > >= > > > itself as site #2. If the ISATAP interface is to be used as an=0A> >= > enterprise-=0A> > > > > > > > interior interface, it should therefore no= t accept IP-proto-41 =0A> packets=0A> > > > > > > > coming from an IPv4 sou= rce outside of the enterprise nor source=0A> > > > > > > > IP-proto-41 pack= ets that are destined to an IPv4 node outside of =0A> the=0A> > > > > > > >= enterprise. This condition should be satisfied by having the site=0A> > > = border=0A> > > > > > > > routers implement IPv4 ingress filtering and ip-pr= otocol-41 =0A> filtering=0A> > > as=0A> > > > > > > > required in Section 1= 0 of RFC5214.=0A> > > > > > > >=0A> > > > > > > > It is mentioned that atta= ck C could also occur when the routers =0A> 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 =0A> = the=0A> > > > > > > > site itself, which can easily be traced - especially = when source=0A> > > address=0A> > > > > > > > spoofing from a node within t= he site is prevented through proper=0A> > > ingress=0A> > > > > > > > filte= ring.=0A> > > > > > > >=0A> > > > > > > > Fred=0A> > > > > > > > fred.l.tem= plin@boeing.com=0A> > > > > > > >=0A> > > > > > > > _______________________= _________________=0A> > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yah= oo.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 a= ttention of the list=0A> > > to=A0some=A0research=A0results=0A> > > > > whi= ch=0A> > > > > > > my colleague and I at=0A> > > > > > > > the National EW = Research=A0& Simulation=A0Center have recently =0A> published.=0A> > > The= =0A> > > > > > > research presents a=A0class=0A> > > > > > > > of routing l= oop attacks that abuses 6to4, ISATAP and Teredo. =0A> The=A0paper=0A> > > c= an=0A> > > > > be=0A> > > > > > > found at:=0A> > > > > > > > http://www.us= enix.org/events/woot09/tech/full_papers/nakibly.pdf=0A> > > > > > > >=0A> >= > > > > > > Here is the abstract:=0A> > > > > > > > IPv6 is the future net= work layer protocol for the Internet. Since =0A> it=0A> > > is=0A> > > > > = not=0A> > > > > > > compatible with its=0A> > > > > > > > predecessor, some= interoperability mechanisms were designed. An=0A> > > important=0A> > > > = > > > category of these=0A> > > > > > > > mechanisms is automatic tunnels, = which enable IPv6 communication =0A> over=0A> > > an=0A> > > > > IPv4=0A> >= > > > > > network without prior=0A> > > > > > > > configuration. This cate= gory includes ISATAP, 6to4 and Teredo. We=0A> > > present=0A> > > > > a=0A>= > > > > > > novel class of attacks=0A> > > > > > > > that exploit vulnerab= ilities in these tunnels. These attacks take=0A> > > > > advantage of=0A> >= > > > > > inconsistencies=0A> > > > > > > > between a tunnel's overlay IPv= 6 routing state and the native IPv6=0A> > > routing=0A> > > > > > > state. = The attacks form=0A> > > > > > > > routing loops which can be abused as a v= ehicle for traffic=0A> > > amplification=0A> > > > > to=0A> > > > > > > fac= ilitate DoS attacks.=0A> > > > > > > > We exhibit five attacks of this clas= s. One of the presented =0A> attacks=0A> > > can=0A> > > > > DoS a=0A> > > = > > > > Teredo server using a=0A> > > > > > > > single packet. The exploite= d vulnerabilities are embedded in the=0A> > > design of=0A> > > > > the=0A>= > > > > > > tunnels; hence any=0A> > > > > > > > implementation of these t= unnels may be vulnerable. In particular, =0A> the=0A> > > > > attacks=0A> >= > > > > > were tested=0A> > > > > > > > against the ISATAP, 6to4 and Tered= o implementations of Windows =0A> Vista=0A> > > and=0A> > > > > > > Windows= Server 2008 R2.=0A> > > > > > > >=0A> > > > > > > > I think the results of= the research warrant some corrective =0A> action. If=0A> > > > > > > this= =A0indeed shall be the=0A> > > > > > > > general sentiment of the list, I w= ill be happy write an =0A> appropriate=0A> > > I-D.=0A> > > > > The=0A> > >= > > > > mitigation measures we=0A> > > > > > > > suggested in the paper ar= e the best we could think of to =0A> completely=0A> > > > > eliminate=0A> >= > > > > > the problem. However=0A> > > > > > > > they are far from perfect= since=A0they would require=A0tunnel=0A> > > implementations=0A> > > > > to= =0A> > > > > > > be updated in case new=0A> > > > > > > > types of automati= c tunnels are introduced.=0A> > > > > > > >=0A> > > > > > > > Your comments= are welcome.=0A> > > > > > > >=0A> > > > > > > > Gabi=0A> > > > > > > >=0A= > > > > > > > >=0A> > > > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > >= =0A> > > >=0A> > > >=0A> > > >=0A> > > >=0A> > =0A> > =0A> > =0A> > =0A=0A= =0A=0A From owner-v6ops@ops.ietf.org Tue Sep 8 02:01: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 7404B3A657C for ; Tue, 8 Sep 2009 02:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.212, 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 I1CBpJcTo9-5 for ; Tue, 8 Sep 2009 02:00:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 819353A6407 for ; Tue, 8 Sep 2009 02:00:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkwXW-000Lk8-V8 for v6ops-data0@psg.com; Tue, 08 Sep 2009 08:59:02 +0000 Received: from web45511.mail.sp1.yahoo.com ([68.180.197.143]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkwXH-000LiZ-3w for v6ops@ops.ietf.org; Tue, 08 Sep 2009 08:58:54 +0000 Received: (qmail 97333 invoked by uid 60001); 8 Sep 2009 08:58:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252400325; bh=4sBHbuM/p8EZxG24Z6HnnKwHdO+TXHwadBZgf/jCmlc=; 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=oXBf5IB9XLNSOIpMBT8lRbpONKUZHPg4SROcRurappRkUUWyUdw+YzpkkYzBr8WkUVO7veqD5BGH8e34a2IhH9tRzxi1VZnEuajejypmslm+Nbyd9xUAtbMSOSVeUpRL4xVduiTF+gllK5eQ67M6LynYKOZfQbYKXkhGi0zr8bc= 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=1V+xUMOlJcuAjoM9TaZULjR/LGH36yJtD6/L3l04BvoKrPnFu29Qwpn1oRHAjhAV6kmXCD88Uu5RBkPFqGsoGrA90ARxVftPizNf1qSKN+u8EwV5qEmI3oAAknCu00ALJQFKnnhiZ6zA2TlR73ISqGdbxqYaj9rAZ07gaxh3xTU=; Message-ID: <732719.95451.qm@web45511.mail.sp1.yahoo.com> X-YMail-OSG: eqyjBS4VM1l4GVXnzfDj0FMYa0ZGYT7QJAiQtEOmC53MR..cSE56yQ78S.vT7bet4ZgQFlS6NRTqgfUiMfIntY1ZmE.98vRyPxb7nyxkEQkxq.ZU_ffNYvO_9eqz6c4nc2aplhpMeRFAHPD4vdhhcchIWdAmTPSvE8VPTrPVSjHe0c9EHouJD6SpiBG3Hd62M9Qbr2U.AhLs45rnY8lU3OYMWcs0_MwXmDxqOIQ7biVg Received: from [93.172.27.171] by web45511.mail.sp1.yahoo.com via HTTP; Tue, 08 Sep 2009 01:58:45 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> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> Date: Tue, 8 Sep 2009 01:58:45 -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: <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@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=0A=0A=0A----- Original Message ----=0A> From: "Templin, Fred L" =0A> To: Gabi Nakibly ; v6ops = =0A> Cc: ipv6@ietf.org; secdir@ietf.org=0A> Sent: Frida= y, September 4, 2009 10:00:53 PM=0A> Subject: RE: Routing loop attacks usin= g IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> I'd like to make one other observati= on about these checks we=0A> have been discussing. There seems to be an imp= lication that=0A> there needs to be a check on all of the IPv4 addresses as= signed=0A> to the node's IPv4 interfaces, and with ISATAP there could be=0A= > multiple underlying IPv4 interfaces over which the ISATAP=0A> interface i= s configured. So, that would seem like a potential=0A> performance issue if= there were multiple IPv4 addresses to=0A> check for every packet.=0A> =0A= =0ADuly noted. However, please note that the processing overhead of the che= cks is on par with that of other=A0currently deployed checks, such as the P= RL check before decapsulation.=0A=0A> But, if the ISATAP router configures = only a single IPv4 address=0A> and places it on the ISATAP interface (i.e.,= leaving all of the=0A> underlying IPv4 interfaces with only a link-local a= ddress) then=0A> there is only one IPv4 address to check. The technique is = called:=0A> "link-layer multiplexing" and is described for ISATAP/VET in=0A= > Appendix B of 'draft-templin-intarea-vet'. But, the idea really=0A> came = from Section 3.3.4 of RFC1122.=0A> =0A=0AThis is indeed a valid alternative= .=0A=0A> Thanks - Fred=0A> fred.l.templin@boeing.com=0A> =0A> > -----Origin= al Message-----=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > = Sent: Thursday, September 03, 2009 8:00 AM=0A> > To: Templin, Fred L; v6ops= =0A> > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > Subject: Re: Routing loop a= ttacks using IPv6 tunnels=0A> > =0A> > Hi Fred,=0A> > see inline.=0A> > =0A= > > Gabi=0A> > =0A> > ----- Original Message ----=0A> > > From: "Templin, F= red L" =0A> > > To: Gabi Nakibly ; v6ops =0A> > > Cc: ipv6@ietf.org; secdir= @ietf.org=0A> > > Sent: Tuesday, September 1, 2009 6:49:56 PM=0A> > > Subje= ct: RE: Routing loop attacks using IPv6 tunnels=0A> > >=0A> > > Gabi,=0A> >= >=0A> > > > -----Original Message-----=0A> > > > From: Gabi Nakibly [mailt= o:gnakibly@yahoo.com]=0A> > > > Sent: Monday, August 31, 2009 12:41 PM=0A> = > > > To: Templin, Fred L; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.o= rg=0A> > > > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > > >= =0A> > > > Fred,=0A> > > >=0A> > > > I agree that the source address check = discussed below should be made. I =0A> would=0A> > > also add a forth=0A> >= > > check=A0to mitigate attack #3 as a second layer of defense in case the= =0A> opposite=0A> > > ISATAP router does not=0A> > > > make the=A0proper c= heck on the destination address.=0A> > > >=0A> > > > isatap_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> > >=0A> > > Having thought about it= a bit, I agree but for ISATAP I see=0A> > > the source address check as a = MAY and the destination address=0A> > > check as a SHOULD.=0A> > =0A> > Why= do you think so? As=A0I see it, the two checks mitigate two different =0A>= attacks.=A0The destination=0A> > address check=A0defends the ISATAP router= =A0against attacks=A0of type 3 in which it =0A> acts as=0A> > the=A0decapsu= lator of the attack packet.=A0=A0While, the=A0source address =0A> check=A0d= efends the ISATAP=0A> > router=A0against attacks=A0of type 3 in which it ac= ts as the=A0ecapsulator of the =0A> attack packet.=A0=A0Either of=0A> > the= se checks are redundant if the other one is employed by the opposite router= =0A> of the attack. So I do=0A> > not see why one of them is a SHOULD and = the other is a MAY.=0A> > =0A> > >=0A> > > In new automatic tunneling proto= col specifications that use a=0A> > > different encapsulation format than i= p-proto-41, as long as=0A> > > we make the destination address check a MUST= before anything=0A> > > gets deployed then the source address check is unn= ecessary=0A> > >=0A> > =0A> > In principle, I agree with you. However, I am= a believer of the "defense in =0A> depth" paradigm: two=0A> > layers of se= curity are (usually) better than one.=A0Since=A0no one can be =0A> absolute= ly sure that the=0A> > destination address check shall always be implemente= d correctly at all other =0A> routers then=A0it may seem=0A> > prudent to a= lso employ the source check as a second layer of defense.=0A> > =0A> > > Fr= ed=0A> > > fred.l.templin@boeing.com=0A> > >=0A> > > >=0A> > > > Gabi=0A> >= > >=0A> > > > ----- Original Message ----=0A> > > > > From: "Templin, Fred= L"=0A> > > > > To: Gabi Nakibly ; v6ops=0A> > > > > Cc: ipv6@ietf.org; sec= dir@ietf.org=0A> > > > > Sent: Friday, August 28, 2009 11:23:40 PM=0A> > > = > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > > >=0A> > = > > > Gabi,=0A> > > > >=0A> > > > > Thanks for your continued correspondenc= e, 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: the best mit= igation=0A> > > of=A0most of=0A> > > > > these=A0attacks is=0A> > > > > > i= ndeed the proto-41 and ingress filtering on the border of the ISATAP=0A> > = > site. If=0A> > > > > it is indeed=0A> > > > > > implemented. I=A0assume t= hat not all sites deploy such filtering for =0A> lack of=0A> > > > > awaren= ess or since the=0A> > > > > > proto-41 filtering may break other tunnels t= he site may employ. =0A> However, I=0A> > > do=0A> > > > > not have hard ev= idence=0A> > > > > > on this. I would be happy if others on the list will r= efute or justify=0A> > > this=0A> > > > > assumption.=0A> > > > > >=0A> > >= > > > If this assumption is (even partially) correct than I think that the= =0A> > > ISATAP=0A> > > > > router should defend=0A> > > > > > itself.=0A> = > > > >=0A> > > > > If there is operational assurance of filtering, then I = think there=0A> > > > > is no problem. For the other cases, I am beginning = to come around=0A> > > > > to your opinion.=0A> > > > >=0A> > > > > > Moreo= ver, as I mention below the proo-41 filtering is not effective in=0A> > > c= ase 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> > > > > > that you illustrated below in pseudo-code.=0A> > > > >=0A> >= > > > OK.=0A> > > > >=0A> > > > > > See=A0further comments inline.=0A> > >= > > >=0A> > > > > > Gabi=0A> > > > > >=0A> > > > > > ----- Original Messag= e ----=0A> > > > > > > From: "Templin, Fred L"=0A> > > > > > > To: Gabi Nak= ibly ; 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> > > > > > > > Se= nt: 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 much=A0liked you= r suggestion regarding the check=A0of =0A> the=0A> > > > > > > neighbor cac= he before=0A> > > > > > > > forwarding a packet into the tunnel.=A0It truly= addresses the root =0A> cause=0A> > > of=0A> > > > > the=0A> > > > > > > p= roblem ans is simple=0A> > > > > > > > enough to implement. However, I real= ized that an attacker can send =0A> a=0A> > > > > > > spoofed=A0RS to the I= SATAP router=0A> > > > > > > > as if it came from the 6to4 relay. The route= r would then send=A0a =0A> RA=A0to=0A> > > > > it=A0and=0A> > > > > > > con= sequently change its=0A> > > > > > > > neighbor cache. So it seems=A0that t= his defense does not add=0A> > > much.=A0Wouldn't=0A> > > > > you=0A> > > >= > > > agree?=0A> > > > > > >=0A> > > > > > > I agree that my proposed miti= gation is only useful when there=0A> > > > > > > is assurance of a coherent= neighbor cache in the ISATAP router.=0A> > > > > > > That would be true in= the case in which the ISATAP router is=0A> > > > > > > located within a si= te protected by border routers that perform=0A> > > > > > > ip-proto-41 and= ingress filtering, and in which there is no=0A> > > > > > > untraceable IP= v4 source address spoofing. So AFAICT, my proposed=0A> > > > > > > mitigati= on is still necessary for preventing attack #3 when=0A> > > > > > > ISATAP = routers A and B are on separate ISATAP links within=0A> > > > > > > the sam= e site-internal IPv4 routing region.=0A> > > > > > >=0A> > > > > >=0A> > > = > > > This is only true when the attacker is outside the site and proto-41= =0A> > > filtering=0A> > > > > is employed. If the=0A> > > > > > attacker i= s internal to the site then the proto-41 filtering will not =0A> help=0A> >= > and=0A> > > > > the neighbor cache can=0A> > > > > > be poisoned.=0A> > = > > >=0A> > > > > Since the ISATAP checks require that the IPv6 source embe= d the=0A> > > > > IPv4 source and/or the IPv4 source is a PRL router, you m= ust be=0A> > > > > speaking here about IPv4 source address spoofing from wi= thin the=0A> > > > > site. For sites that allow intra-site source address s= poofing,=0A> > > > > I think much more serious problems could manifest them= selves=0A> > > > > that would be completely unrelated to ISATAP. I believe = you=0A> > > > > will also find other automatic tunneling protocols besides= =0A> > > > > ISATAP that operate under an assumption of no intra-site IPv4= =0A> > > > > source address spoofing.=0A> > > > >=0A> > > > > > > > I compl= etely agree with your observation on the non-feasibility of=0A> > > > > > >= verifying=A0that the=0A> > > > > > > > destination=A0ISATAP address does n= ot include=A0a local=A0IPv4 =0A> address=A0since=0A> > > the=0A> > > > > > = > ISATAP address may include=0A> > > > > > > > a private IPv4 address. On t= he other hand, a check on public IPv4=0A> > > > > addresses is=0A> > > > > = > > acceptable.=A0If the=0A> > > > > > > > check would be done only on ISAT= AP addresses that include public =0A> IPv4=0A> > > > > > > addresses then t= his will=0A> > > > > > > > eliminate the attacks in which the two victims r= eside=A0at different=0A> > > sites.=0A> > > > > Note=0A> > > > > > > that i= f attack #3=A0is=0A> > > > > > > > launched on two ISATAP routers=A0having = private addresses at two=0A> > > different=0A> > > > > sites=0A> > > > > > = > then the attack will=0A> > > > > > > > not work anyway since one router c= an not send a direct=A0IPv4 packet =0A> to=0A> > > the=0A> > > > > > > othe= r. In addition,=0A> > > > > > > > to=A0mitigate attacks in which the other = victim is a 6to4 relay =0A> (such as=0A> > > > > attack=0A> > > > > > > #1)= then a check would=0A> > > > > > > > have to be done on a 6to4 address, i.= e. the destination address =0A> must=0A> > > not=0A> > > > > be=0A> > > > >= > > "2002:> > the ISATAP router>::*". In this case the IPv4 address must = =0A> be=0A> > > > > public,=0A> > > > > > > according to=0A> > > > > > > >= =A0 the 6to4 spec.=0A> > > > > > > >=0A> > > > > > > > As you also noted th= ere is another problem with this check since =0A> the=0A> > > > > string=0A= > > > > > > > "200::5EFE" is not unique=0A> > > > > > > > to ISATAP links. = On the other hand, it seems that the probability =0A> to=0A> > > > > encoun= ter=0A> > > > > > > a non-malicious packet=0A> > > > > > > > with a destina= tion address having an IID that equals "200:5EFE:> =0A> IPv4=0A> > > > > ad= dress>" is=0A> > > > > > > > pretty slim.=0A> > > > > > > >=0A> > > > > > >= > This check is definitely not a=A0perfect solution, and I sure hope =0A> = that=0A> > > > > someone=0A> > > > > > > will come up with a=0A> > > > > > = > > better one for mitigating the routing loops. However, I would be =0A> h= appy=0A> > > if=0A> > > > > > > there is some kind of other=0A> > > > > > >= > mitigation=A0measures besides packet filtering=A0(proto-41 and =0A> ingr= ess)=0A> > > > > by=A0other=0A> > > > > > > nodes (which=A0does not=0A> > >= > > > > > necessarily exist).=0A> > > > > > >=0A> > > > > > > You seem to = be envisioning a scenario of ISATAP router operation=0A> > > > > > > with p= ublic IPv4 addresses and outside of any site border 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 I= SATAP=0A> > > > > > > model" in a list message long ago (which AFAICT is th= e scenario=0A> > > > > > > you are alluding to).=0A> > > > > > >=0A> > > > = > >=0A> > > > > > Well,=A0I am referring to any=A0ISATAP deployment=A0with = public IPv4 =0A> addresses=0A> > > and=0A> > > > > no proto-41 filtering. I= =0A> > > > > > imagine that in practice there are such deployments which ar= e not the=0A> > > > > "inside-out ISATAP model"=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 gigantic= =0A> > > > > > > "site" and we wanted to do ISATAP on that site, it would b= e nice=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 ar= e describing in=0A> > > > > > > which we can't trust the integrity of the I= SATAP router's=0A> > > > > > > neighbor cache due to the possibility for un= traceable IPv4=0A> > > > > > > source address spoofing such that the neighb= or cache check=0A> > > > > > > mitigation can be subverted.=0A> > > > > > >= =0A> > > > > > > This means that if we want to support the inside-out ISATA= P=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 behind filtering border routers to advertise=0A> = > > > > > > non-link-local on-link 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 tha= t=0A> > > > > > > only did IPv6 link-local. So, nodes could ping6 each othe= rs'=0A> > > > > > > ISATAP link-local addresses but that's about it.=0A> > = > > > > >=0A> > > > > > > If we took the more ambitious route and allowed I= SATAP to=0A> > > > > > > flourish fully within the global IPv4 Internet, th= en 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 attack scenarios= =0A> > > > > > > 1 through 3 correctly then scenarios 1 and 3 are mitigated= =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 "2002:::*")=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 cor= rection you sent after this email).=0A> > > > >=0A> > > > > OK.=0A> > > > >= =0A> > > > > > > =A0 isatap_xmt() {=0A> > > > > > > =A0 =A0 ...=0A> > > > >= > > =A0 =A0 if (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> > > > > > This will not necessaril= y work, since the 6to4 relay may have =0A> a=A0unicast=0A> > > > > address = the ISATAP router may=0A> > > > > > not be aware of. The best way to mitiga= te attack #2 is=A0by the 6to4 =0A> relay=0A> > > with=0A> > > > > a check s= imilar to that=0A> > > > > > of attack #2 above. IMO, the second best way, = as Remi suggested on =0A> another=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 the 6to4 relay va= lidates that the IPv6 source address corresponds =0A> to=0A> > > the=0A> > = > > > IPv4 one (this is=0A> > > > > > in=A0accordance=A0with the 6to4 spec,= however it does not always get=0A> > > implemented).=0A> > > > > If this i= s not true=0A> > > > > > then the attacker does not have to send the attack= packet with such an=0A> > > > > address.=0A> > > > >=0A> > > > > Keeping w= ith the philosophy of the ISATAP router defending itself,=0A> > > > > I bel= ieve it would be best to take Remi's suggestion and lay any=0A> > > > > com= plications at the doorstep of the 6to4 relay if it fails to=0A> > > > > adh= ere to the spec.=0A> > > > >=0A> > > > > Thanks - Fred=0A> > > > > fred.l.t= emplin@boeing.com=0A> > > > >=0A> > > > > > > Does the above look right to = you? And is this everything,=0A> > > > > > > or are there other scenarios w= e need to consider?=0A> > > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > >= > > Thanks - Fred=0A> > > > > > > fred.l.templin@boeing.com=0A> > > > > > = >=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: Wednesday, August 19, 2009 6:= 16:18 PM=0A> > > > > > > > Subject: RE: Routing loop attacks using IPv6 tun= nels=0A> > > > > > > >=0A> > > > > > > > Hi Gabi,=0A> > > > > > > >=0A> > >= > > > > > I'm sorry to have to keep turning this into plaintext,=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: Wednesday, August 19, 2009 1:4= 9 AM=0A> > > > > > > > To: Templin, Fred L; v6ops=0A> > > > > > > > Cc: ipv= 6@ietf.org; secdir@ietf.org=0A> > > > > > > > Subject: Re: Routing loop att= acks using IPv6 tunnels=0A> > > > > > > >=0A> > > > > > > > Fred,=0A> > > >= > > > > See my comments inline ().=0A> > > > > > > >=0A> > > > > > > > ___= _____________________________________=0A> > > > > > > > From: "Templin, Fre= d 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 t= unnels=0A> > > > > > > >=0A> > > > > > > > Gabi,=0A> > > > > > > >=0A> > > = > > > > > ________________________________________=0A> > > > > > > > From: = Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > > > > > Sent: Tuesday, A= ugust 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 meant=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 a= ttacks=A0will=0A> > > > > > > > > be mitigated=A0if proper protocol-41 filt= ering is deployed on=0A> > > > > > > > > the site's border. However, note t= hat RFC5214 does not mandate=0A> > > > > > > > > or require this filtering.= =0A> > > > > > > >=0A> > > > > > > > The RFC5214 Security Considerations ma= kes clear the=0A> > > > > > > > consequences of not implementing IPv4 ingre= ss filtering=0A> > > > > > > > and ip-protocol-41 filtering (i.e., a possib= le spooing=0A> > > > > > > > attack in which spurious ip-protocol-41 packet= s are=0A> > > > > > > > injected into an ISATAP link from outside). RFC5214= =0A> > > > > > > > Section 6.2 additionally requires that an ISATAP interfa= ce's=0A> > > > > > > > locator set MUST NOT span multiple sites. This means= that the=0A> > > > > > > > ISATAP interface must not decapsulate nor sourc= e ip-proto-41=0A> > > > > > > > packets within multiple sites, where the en= terprise interior=0A> > > > > > > > is site #1 and the global Internet is s= ite #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 co= rrectly. In=0A> > > > > > > > attack #2, for example, I assume the ISATAP r= outer has two=0A> > > > > > > > physical interfaces. A site-internal IPv4 i= nterface with an=0A> > > > > > > > address IPisatap and a site-external IPv= 6 interface. I also=0A> > > > > > > > assume that there=A0is another border= router which connects the=0A> > > > > > > > site to the IPv4 Internet.=A0T= he ISATAP router has an ISATAP=0A> > > > > > > > interface with a single lo= cator: (IPisatap, site-internal=0A> > > > > > > > interface).=A0When the IS= ATAP router gets an IPv6 via its=0A> > > > > > > > external interface it wi= ll encapsulate the packet accordingly=0A> > > > > > > > and forward it thro= ugh the internal IPv4 interface. If the=0A> > > > > > > > encapsulated pack= et is=A0destined to a node outside the site=0A> > > > > > > > then the only= thing that stops it is=A0a proto-41 filtering=0A> > > > > > > > at 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-4= 1 filtering is at a=0A> > > > > > > > =3D=3D> border router. I know of at l= east one major enterprise=0A> > > > > > > > =3D=3D> network that does this.= =0A> > > > > > > >=0A> > > > > > > > > It is only mentioned as a possible m= itigation against=0A> > > > > > > > > incoming spurious protocol-41 packets= . In addition,=0A> > > > > > > > > Section 10 of RFC5214 only mentions=A0in= gress not=A0egress=0A> > > > > > > > > filtering.=A0Hence it=A0will not sto= p attack #2.=0A> > > > > > > >=0A> > > > > > > > We are now talking about i= p-proto-41 filtering; not ingress=0A> > > > > > > > filtering. 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 = entering the Internet ISATAP=0A> > > > > > > > site from the enterprise int= erior. Else the ISATAP=0A> > > > > > > > interface would span multiple site= s.=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 leaving the end site and = going out into=0A> > > > > > > > the Internet. RFC2827 (BCP38) documents in= gress 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 attack=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> > > > > > > > pack= et from a foreign prefix.=0A> > > > > > > >=0A> > > > > > > > Well, I do no= t see how this is correct. In attacks #1 and #3 the=0A> > > ISATAP=0A> > > = > > router=0A> > > > > > > sources (actually=0A> > > > > > > > forwards) an= IPv6=A0packet with=A0a source address having=A0the=0A> > > > > correspondi= ng=A0prefix=0A> > > > > > > of the ISATAP tunnel.=0A> > > > > > > > In atta= cks #2 and #3 the ISATAP router sources and IPv4 packet =0A> with=0A> > > i= ts=0A> > > > > own=0A> > > > > > > IPv4 address as the=0A> > > > > > > > so= urce 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 case= s to consider. Case=0A> > > > > > > > =3D=3D> 1 in which a border router se= parates the 6to4 relay from the=0A> > > > > > > > =3D=3D> ISATAP router, an= d case 2 in which no border 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 ingres= s=0A> > > > > > > > =3D=3D> filtering at the site border router should prev= ent the=0A> > > > > > > > =3D=3D> packet from entering the site in the firs= t place. If the=0A> > > > > > > > =3D=3D> 6to4 relay router is outside the = site then ip-proto-41=0A> > > > > > > > =3D=3D> filtering at the border rou= ter will block the attack in=0A> > > > > > > > =3D=3D> the first place anyw= ay. If the relay router is *inside*=0A> > > > > > > > =3D=3D> the site, the= n the IPv6 ingress filtering is the lone=0A> > > > > > > > =3D=3D> mitigati= on. 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> otherwise, 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 I= Pv6 packet with a foreign source=0A> > > > > > > > =3D=3D> address being fo= rwarded 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> 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 b= elieves it=0A> > > > > > > > =3D=3D> is forwarding the packet *into* the IS= ATAP link (not out of=0A> > > > > > > > =3D=3D> it). But as in attack #1, t= he attack is blocked by ip-proto-41=0A> > > > > > > > =3D=3D> filtering at = the border router between the ISATAP router and=0A> > > > > > > > =3D=3D> t= he 6to4 relay. If there is no border router between the =0A> ISATAP=0A> > >= > > > > > =3D=3D> router and the 6to4 relay, then we have an identical ins= tance=0A> > > > > > > > =3D=3D> to attack #3 which I will discuss below. Bu= t, the best=0A> > > > > > > > =3D=3D> operational practice would again be t= o have the 6to4 relay=0A> > > > > > > > =3D=3D> oriented outside of a borde= r router that filters 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 6to4 router and not an ISATAP route= r. In=0A> > > > > > > > =3D=3D> attack #2, the ISATAP router thinks it is t= alking to a=0A> > > > > > > > =3D=3D> simple host on the link and not a 6to= 4 relay. In both cases,=0A> > > > > > > > =3D=3D> the attacks are mitigated= when there is an ip-proto-41=0A> > > > > > > > =3D=3D> filtering border ro= uter between the ISATAP router and the=0A> > > > > > > > =3D=3D> 6to4 relay= . Oftentimes, the "border router" will be 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> from outside the site with an IPv4 destination c= orresponding=0A> > > > > > > > =3D=3D> to the ISATAP interface. I will disc= uss attack #3 below:=0A> > > > > > > >=0A> > > > > > > > This attack is mit= igated by=0A> > > > > > > > IPv6 ingress filtering which is an IPv6 securit= y consideration=0A> > > > > > > > and not an ISATAP nor IPv4 security consi= deration. BCP=0A> > > > > > > > recommendations for network ingress filteri= ng are documented=0A> > > > > > > > in RFC2827 and it is expected that IPv6= routers that configure=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=0A> > > filtering=0A> > > > > would=0A> > > > > > > help here. = The only=0A> > > > > > > > case where=A0ingress filtering can help is in ca= se of attack #3 when =0A> the=0A> > > > > routers=0A> > > > > > > reside at= the same=0A> > > > > > > > site. In that case if the attack packet (packet= 0) is sent from=0A> > > outside=0A> > > > > the=0A> > > > > > > site then = ingress=0A> > > > > > > > filtering on the border of the site will drop the= packet.=0A> > > > > > > >=0A> > > > > > > >=0A> > > > > > > > =3D=3D> Corr= ect 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 ISATAP link when in fact from the=0A> = > > > > > > > =3D=3D> ISATAP router's perspective it is forwarding the pack= et=0A> > > > > > > > =3D=3D> to a simple host *inside* of the link.=0A> > >= > > > > > =3D=3D>=0A> > > > > > > > =3D=3D> The problem here is that the I= SATAP router is blindly=0A> > > > > > > > =3D=3D> forwarding a packet to a = node that it assumes is a simple=0A> > > > > > > > =3D=3D> host on the ISAT= AP link without first verifying that the=0A> > > > > > > > =3D=3D> node has= demonstrated a willingness to participate as a=0A> > > > > > > > =3D=3D> h= ost 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 ISATA= P=0A> > > > > > > > =3D=3D> address that embeds one of its own IPv4 address= es, 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 IPv4 address 10.0.0.1=0A> > > > > > > > =3D=3D> and is= asked to forward an IPv6 packet with ISATAP=0A> > > > > > > > =3D=3D> dest= ination 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 the=0A> > > > = > > > > =3D=3D> packet as this would block legitimate communications. 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 token=0A> > > > > > > > =3D=3D> "0:5EFE" as that token only has signi= ficance for ISATAP=0A> > > > > > > > =3D=3D> links and not other link types= .=0A> > > > > > > > =3D=3D>=0A> > > > > > > > =3D=3D> Instead, the mitigati= on 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 as= sumes 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 l= ink, there would=0A> > > > > > > > =3D=3D> have been a neighbor cache entry= created when the node=0A> > > > > > > > =3D=3D> sends a Router Solicitatio= n to the ISATAP router for the=0A> > > > > > > > =3D=3D> purpose of discove= ring default router lifetimes and on-=0A> > > > > > > > =3D=3D> link prefix= es. 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 enti= res=0A> > > > > > > > =3D=3D> for the duration of the minimum lifetime of t= he prefixes=0A> > > > > > > > =3D=3D> it advertises in its Router Advertise= ments.=0A> > > > > > > >=0A> > > > > > > > > In general, I would like to po= int out that indeed as in=0A> > > > > > > > > most other attacks these atta= cks may also be mitigated by=0A> > > > > > > > > proper firewall rules. How= ever, I do not believe that this=0A> > > > > > > > > should be our only ans= wer against these attacks. I believe=0A> > > > > > > > > that since these a= ttacks are made possible due to the=0A> > > > > > > > > inherent characteri= stics of the tunnels they=A0should be=0A> > > > > > > > > stopped intrinsic= ally as much as possible by the tunnel=0A> > > > > > > > > participants and= not relay on outside filtering rules.=0A> > > > > > > >=0A> > > > > > > > = In RFC5214, Section 10 we have: "restricting access to the=0A> > > > > > > = > link can be achieved by restricting access 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 sufficient=0A> > > > = > > > > checks. So on this point, I do not share your opinion.=0A> > > > > = > > >=0A> > > > > > > > What about two ISATAP tunnels that reside on the sa= me site like in=0A> > > attack=0A> > > > > #3.=0A> > > > > > > Do you=A0als= o think that=0A> > > > > > > > proto-41 filtering should barrier between th= e two tunnels within =0A> the=0A> > > site?=0A> > > > > > > >=0A> > > > > >= > >=0A> > > > > > > > =3D=3D> I think this may be overcome by the discussi= on above.=0A> > > > > > > > =3D=3D> Short story is that operational practic= es must be=0A> > > > > > > > =3D=3D> employed whereby an ISATAP router is n= ot mistaken for=0A> > > > > > > > =3D=3D> a 6to4 router. This is through pr= oper arrangement of=0A> > > > > > > > =3D=3D> 6to4 router/relay interfaces = outside of the site border=0A> > > > > > > > =3D=3D> rather than inside, an= d ISATAP router interfaces inside=0A> > > > > > > > =3D=3D> of the site bor= der rather than outside. Also proper=0A> > > > > > > > =3D=3D> ip-proto-41 = filtering and IPv6 ingress filtering at=0A> > > > > > > > =3D=3D> site bord= ers.=0A> > > > > > > > =3D=3D>=0A> > > > > > > > =3D=3D> Also, when there a= re multiple ISATAP links within the=0A> > > > > > > > =3D=3D> same local IP= v4 routing region, an ISATAP router should=0A> > > > > > > > =3D=3D> first = verify a node's willingness to act as a host on=0A> > > > > > > > =3D=3D> t= he ISATAP link before blindly sending a packet to it.=0A> > > > > > > > =3D= =3D>=0A> > > > > > > > =3D=3D> Fred=0A> > > > > > > > =3D=3D> fred.l.templi= n@boeing.com=0A> > > > > > > >=0A> > > > > > > > Fred=0A> > > > > > > > fre= d.l.templin@boeing.com=0A> > > > > > > >=0A> > > > > > > > ________________= ________________________=0A> > > > > > > > From: "Templin, Fred L"=0A> > > = > > > > > To: Gabi Nakibly ; v6ops=0A> > > > > > > > Cc: ipv6@ietf.org; sec= dir@ietf.org=0A> > > > > > > > Sent: Monday, August 17, 2009 8:35:08 PM=0A>= > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > >= > > > > >=0A> > > > > > > >=0A> > > > > > > > Gabi,=0A> > > > > > > >=0A> = > > > > > > > Thanks for publishing this work. In the document, attacks A, = B and =0A> C=0A> > > > > > > > correspond to a configuration that violates = section 6.2 of =0A> RFC5214:=0A> > > > > > > >=0A> > > > > > > > > 6.2.=A0 = ISATAP Interface Address Configuration=0A> > > > > > > > >=0A> > > > > > > = > > =A0=A0Each ISATAP interface configures a set of locators consisting =0A= > of=0A> > > IPv4=0A> > > > > > > > >=A0=A0 address-to-interface mappings f= rom a single site; i.e., an =0A> ISATAP=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=0A> = > > ISATAP=0A> > > > > > > > is seen both within the enterprise as site #1 = and within the =0A> global=0A> > > > > Internet=0A> > > > > > > > itself as= site #2. If the ISATAP interface is to be used as an=0A> > > enterprise-= =0A> > > > > > > > interior interface, it should therefore not accept IP-pr= oto-41 =0A> packets=0A> > > > > > > > coming from an IPv4 source outside of= the enterprise nor source=0A> > > > > > > > IP-proto-41 packets that are d= estined to an IPv4 node outside of =0A> the=0A> > > > > > > > enterprise. T= his condition should be satisfied by having the site=0A> > > border=0A> > >= > > > > > routers implement IPv4 ingress filtering and ip-protocol-41 =0A>= filtering=0A> > > as=0A> > > > > > > > required in Section 10 of RFC5214.= =0A> > > > > > > >=0A> > > > > > > > It is mentioned that attack C could al= so occur when the routers =0A> reside=0A> > > > > > > > in the same site, w= here their addresses may be private. This would=0A> > > > > > > > correspon= d to a case in which an attacker within the site attacks =0A> the=0A> > > >= > > > > site itself, which can easily be traced - especially when source= =0A> > > address=0A> > > > > > > > spoofing from a node within the site is = prevented through proper=0A> > > 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 attacks using IPv6 tunnels=0A> > > > > > > >=0A> > = > > > > > > Hi all,=0A> > > > > > > > I would like to draw the attention of= the list=0A> > > to=A0some=A0research=A0results=0A> > > > > which=0A> > > = > > > > my colleague and I at=0A> > > > > > > > the National EW Research=A0= & Simulation=A0Center have recently =0A> published.=0A> > > The=0A> > > > >= > > research presents a=A0class=0A> > > > > > > > of routing loop attacks = that abuses 6to4, ISATAP and Teredo. =0A> The=A0paper=0A> > > can=0A> > > >= > be=0A> > > > > > > found at:=0A> > > > > > > > http://www.usenix.org/eve= nts/woot09/tech/full_papers/nakibly.pdf=0A> > > > > > > >=0A> > > > > > > >= Here is the abstract:=0A> > > > > > > > IPv6 is the future network layer p= rotocol for the Internet. Since =0A> it=0A> > > is=0A> > > > > not=0A> > > = > > > > compatible with its=0A> > > > > > > > predecessor, some interoperab= ility mechanisms were designed. An=0A> > > important=0A> > > > > > > catego= ry of these=0A> > > > > > > > mechanisms is automatic tunnels, which enable= IPv6 communication =0A> over=0A> > > an=0A> > > > > IPv4=0A> > > > > > > n= etwork without prior=0A> > > > > > > > configuration. This category include= s ISATAP, 6to4 and Teredo. We=0A> > > present=0A> > > > > a=0A> > > > > > >= novel class of attacks=0A> > > > > > > > that exploit vulnerabilities in t= hese tunnels. These attacks take=0A> > > > > advantage of=0A> > > > > > > i= nconsistencies=0A> > > > > > > > between a tunnel's overlay IPv6 routing st= ate and the native IPv6=0A> > > routing=0A> > > > > > > state. The attacks = form=0A> > > > > > > > routing loops which can be abused as a vehicle for t= raffic=0A> > > amplification=0A> > > > > to=0A> > > > > > > facilitate DoS = attacks.=0A> > > > > > > > We exhibit five attacks of this class. One of th= e presented =0A> attacks=0A> > > can=0A> > > > > DoS a=0A> > > > > > > Tere= do server using a=0A> > > > > > > > single packet. The exploited vulnerabil= ities are embedded in the=0A> > > design of=0A> > > > > the=0A> > > > > > >= tunnels; hence any=0A> > > > > > > > implementation of these tunnels may b= e vulnerable. In particular, =0A> the=0A> > > > > attacks=0A> > > > > > > w= ere tested=0A> > > > > > > > against the ISATAP, 6to4 and Teredo implementa= tions of Windows =0A> Vista=0A> > > and=0A> > > > > > > Windows Server 2008= R2.=0A> > > > > > > >=0A> > > > > > > > I think the results of the researc= h warrant some corrective =0A> action. If=0A> > > > > > > this=A0indeed sha= ll be the=0A> > > > > > > > general sentiment of the list, I will be happy = write an =0A> appropriate=0A> > > I-D.=0A> > > > > The=0A> > > > > > > miti= gation measures we=0A> > > > > > > > suggested in the paper are the best we= could think of to =0A> completely=0A> > > > > eliminate=0A> > > > > > > th= e problem. However=0A> > > > > > > > they are far from perfect since=A0they= would require=A0tunnel=0A> > > implementations=0A> > > > > 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> > > > > >=0A> > > >=0A= > > > >=0A> > > >=0A> > > >=0A> > =0A> > =0A> > =0A> > =0A=0A=0A=0A From owner-v6ops@ops.ietf.org Tue Sep 8 07:18: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 EE59D3A6A75 for ; Tue, 8 Sep 2009 07:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.170, 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 EtwCNocRw3sE for ; Tue, 8 Sep 2009 07:18:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D64533A6A70 for ; Tue, 8 Sep 2009 07:18:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml1Sy-000JzQ-Q9 for v6ops-data0@psg.com; Tue, 08 Sep 2009 14:14:40 +0000 Received: from web45515.mail.sp1.yahoo.com ([68.180.197.179]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml1Si-000Jw1-Go for v6ops@ops.ietf.org; Tue, 08 Sep 2009 14:14:35 +0000 Received: (qmail 51381 invoked by uid 60001); 8 Sep 2009 12:27:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252412863; bh=8u8SLXP4ozQr9eloQV5Dw5xB+fY/rA4E+e+Nd3nS+KA=; 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=KoOYJnHBw+BN3F4qY//DU5P8ctwP3qL0gr/sVbaLNw6uysYcksIcn195z7bdLMsWTBOVVJAyTmIFJ5OnpniBLdoY9ZMFw2R1CVKQSlqG5kd3IG/2laa6hjG3UmBkI5IXA3lynFu9/y513nlA3jp3TWQgKBSfWKkQRjVLFBO5Kp8= 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=Df6nKHPKtiEge9bHaiFbNULzAr+/mJPISXd+sU8hkaUIUsw4bCLrWm2R/Qzq5KHbiCUaoPqFGbyXFL+RQ1g3h+Lk5j7QBihv+/VCBIWuzKcYL/13RWDqtApVzJDsRLIG7cow2XSE/m8iGtBCpQqNOTyX8/0smuHYlDdDAOXvjTU=; Message-ID: <702481.50824.qm@web45515.mail.sp1.yahoo.com> X-YMail-OSG: gK_OzXsVM1nZpTkbawkSpAfgLdOhFmtMN2z5hv9BHHb0Ob1T6lUn91cW3acM2D9Ao5KyFvzrCz96iFQAnRa9ycO7kGbDlBqoiBn25Q7iTVfpdXQ0k5Nr7H8t06eJLLm3b2OOqnLV6c9Pj.2ILdc.QJww0.7pLb0AZcHhLG_S5sjwhJoDz50YAehQGNSg_Y2W_spfh_8Jkt6sLZ45JCB4bhBsdzA7hjOh.J1JwHr4CBMF3zYGcLFT.C92aS1InHRD9rIn0lKT Received: from [93.172.27.171] by web45515.mail.sp1.yahoo.com via HTTP; Tue, 08 Sep 2009 05:27:43 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> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Date: Tue, 8 Sep 2009 05:27:43 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: Christian Huitema , "Templin, Fred L" , v6ops Cc: "ipv6@ietf.org" , "secdir@ietf.org" In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.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: Hi Christian,=0AThanks for your comments.=0A=0A=0AThe checks=A0you suggeste= d are powerful and will indeed mitigate the attacks. The only thing that wo= rries me is the fact that=A0usually AFAIK the=A0ISATAP router is not config= ured with the IPv4 subnet addresses of the site. This means that the router= must now be configured with this information and reconfigured as this info= rmation changes. If this is felt to be a reasonable administrative overhead= , then I think the checks should be employed. =0A=0AOne minor thing that sh= ould be noted is that these checks will not mitigate the attacks in case th= ere are two ISATAP links (with two separate routers)=A0in the same site. Th= is means=A0that their sets of registered subnets coincide.=A0I assume that= =A0such deployment are not common, although I do not have the information t= o back this assumption.=0A=0AGabi=0A=0A=0A----- Original Message ----=0A> F= rom: Christian Huitema =0A> To: "Templin, Fred L" ; Gabi Nakibly ; v6ops =0A> Cc: "ipv6@ietf.org" ; "secdir@ietf.org" =0A> Sent: Friday, September 4, 2009 10:25:21 PM=0A> Subject= : RE: Routing loop attacks using IPv6 tunnels=0A> =0A> I think that there i= s another possible way to protect against these attacks, if =0A> the ISATAP= router limits the range of IPv4 addresses towards which it is willing =0A>= to relay packets. That would fit many current deployments, maybe most.=0A>= =0A> In many current deployments, ISATAP is used to provide IPv6 connectiv= ity inside =0A> a "site", typically protected by a firewall. The expected b= ehavior is that hosts =0A> in that site will use direct ISATAP connectivity= to exchange packets with each =0A> other, and will use the ISATAP router t= o exchange packets with other IPv6 =0A> subnets.=0A> =0A> Assume that the s= ite is defined by a set of IPv4 subnets, and the ISATAP router =0A> knows t= hat list. The basic check in the ISATAP router is thus:=0A> =0A> =A0 =A0 = =A0 =A0 On incoming packet:=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If IPv6 sou= rce belongs to local ISATAP subnet (matches /64=A0prefix):=0A> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If (IPv4 source does not match last 32 = bits of IPv6=A0source): drop;=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Else If (IPv4 source does not belong to one of=A0registered subnets= ): drop;=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else relay; //= we may or may not want to add a=A0destination check=0A> =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Else=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If= (IPv4 source belongs to one of registered subnets):=A0drop;=0A> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else if (IPv6 destination does not = match ISATAP subnet):=A0drop;=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Else if (embedded IPv4 address does not belong to of=A0registered s= ubnets): drop;=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else rel= ay;=0A> =0A> Written that way, the ISATAP router cannot create a loop, beca= use packets always =0A> go either from site to elsewhere, or from elsewhere= to site.=0A> =0A> =0A> =0A> -----Original Message-----=0A> From: ipv6-boun= ces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, =0A> Fred= L=0A> Sent: Friday, September 04, 2009 1:01 PM=0A> To: Gabi Nakibly; v6ops= =0A> Cc: ipv6@ietf.org; secdir@ietf.org=0A> Subject: RE: Routing loop attac= ks using IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> I'd like to make one other ob= servation about these checks we=0A> have been discussing. There seems to be= an implication that=0A> there needs to be a check on all of the IPv4 addre= sses assigned=0A> to the node's IPv4 interfaces, and with ISATAP there coul= d be=0A> multiple underlying IPv4 interfaces over which the ISATAP=0A> inte= rface is configured. So, that would seem like a potential=0A> performance i= ssue if there were multiple IPv4 addresses to=0A> check for every packet.= =0A> =0A> But, if the ISATAP router configures only a single IPv4 address= =0A> and places it on the ISATAP interface (i.e., leaving all of the=0A> un= derlying IPv4 interfaces with only a link-local address) then=0A> there is = only one IPv4 address to check. The technique is called:=0A> "link-layer mu= ltiplexing" and is described for ISATAP/VET in=0A> Appendix B of 'draft-tem= plin-intarea-vet'. But, the idea really=0A> came from Section 3.3.4 of RFC1= 122.=0A> =0A> Thanks - Fred=0A> fred.l.templin@boeing.com=0A> =0A> > -----O= riginal Message-----=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]= =0A> > Sent: Thursday, September 03, 2009 8:00 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> > Hi Fred,=0A> > see inline.=0A>= >=0A> > Gabi=0A> >=0A> > ----- Original Message ----=0A> > > From: "Templi= n, Fred L" =0A> > > To: Gabi Nakibly ; v6ops =0A> > > Cc: ipv6@ietf.org; se= cdir@ietf.org=0A> > > Sent: Tuesday, September 1, 2009 6:49:56 PM=0A> > > S= ubject: RE: Routing loop attacks using IPv6 tunnels=0A> > >=0A> > > Gabi,= =0A> > >=0A> > > > -----Original Message-----=0A> > > > From: Gabi Nakibly = [mailto:gnakibly@yahoo.com]=0A> > > > Sent: Monday, August 31, 2009 12:41 P= M=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> > > >=0A> > > > I agree that the source address = check discussed below should be made. I =0A> would=0A> > > also add a forth= =0A> > > > check to mitigate attack #3 as a second layer of defense in case= the =0A> opposite=0A> > > ISATAP router does not=0A> > > > make the proper= check on the destination address.=0A> > > >=0A> > > > isatap_xmt() {=0A> >= > >=A0 =A0 =A0 ...=0A> > > >=A0 =A0 =A0 if (src =3D=3D "::0200:5efe:")=0A>= > > >=A0 =A0 =A0 =A0 drop_pkt(); /* attack #3 mitigation */=0A> > > >=A0 = =A0 =A0 ...=0A> > > >=A0 }=0A> > >=0A> > > Having thought about it a bit, I= agree but for ISATAP I see=0A> > > the source address check as a MAY and t= he destination address=0A> > > check as a SHOULD.=0A> >=0A> > Why do you th= ink so? As I see it, the two checks mitigate two different =0A> attacks. Th= e destination=0A> > address check defends the ISATAP router against attacks= of type 3 in which it =0A> acts as=0A> > the decapsulator of the attack pa= cket.=A0 While, the source address check =0A> defends the ISATAP=0A> > rout= er against attacks of type 3 in which it acts as the ecapsulator of the =0A= > attack packet.=A0 Either of=0A> > these checks are redundant if the other= one is employed by the opposite router =0A> of the attack. So I do=0A> > n= ot see why one of them is a SHOULD and the other is a MAY.=0A> >=0A> > >=0A= > > > In new automatic tunneling protocol specifications that use a=0A> > >= different encapsulation format than ip-proto-41, as long as=0A> > > we mak= e the destination address check a MUST before anything=0A> > > gets deploye= d then the source address check is unnecessary=0A> > >=0A> >=0A> > In princ= iple, I agree with you. However, I am a believer of the "defense in =0A> de= pth" paradigm: two=0A> > layers of security are (usually) better than one. = Since no one can be =0A> absolutely sure that the=0A> > destination address= check shall always be implemented correctly at all other =0A> routers then= it may seem=0A> > prudent to also employ the source check as a second laye= r of defense.=0A> >=0A> > > Fred=0A> > > fred.l.templin@boeing.com=0A> > >= =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: Friday, A= ugust 28, 2009 11:23:40 PM=0A> > > > > Subject: RE: Routing loop attacks us= ing IPv6 tunnels=0A> > > > >=0A> > > > > Gabi,=0A> > > > >=0A> > > > > Than= ks for your continued correspondence, and see below:=0A> > > > >=0A> > > > = > > -----Original Message-----=0A> > > > > > From: Gabi Nakibly [mailto:gna= kibly@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 tunnel= s=0A> > > > > >=0A> > > > > > Fred,=0A> > > > > > A quick summary of our di= scussion up until now: the best mitigation=0A> > > of most of=0A> > > > > t= hese attacks is=0A> > > > > > indeed the proto-41 and ingress filtering on = the border of the ISATAP=0A> > > site. If=0A> > > > > it is indeed=0A> > > = > > > implemented. I assume that not all sites deploy such filtering for = =0A> lack of=0A> > > > > awareness or since the=0A> > > > > > proto-41 filt= ering may break other tunnels the site may employ. =0A> However, I=0A> > > = do=0A> > > > > not have hard evidence=0A> > > > > > on this. I would be hap= py if others on the list will refute or justify=0A> > > this=0A> > > > > as= sumption.=0A> > > > > >=0A> > > > > > If this assumption is (even partially= ) correct than I think that the=0A> > > ISATAP=0A> > > > > router should de= fend=0A> > > > > > itself.=0A> > > > >=0A> > > > > If there is operational = assurance of filtering, then I think there=0A> > > > > is no problem. For t= he other cases, I am beginning to come around=0A> > > > > to your opinion.= =0A> > > > >=0A> > > > > > Moreover, as I mention below the proo-41 filteri= ng is not effective in=0A> > > case of=0A> > > > > attack=0A> > > > > > #3 = and the attacker is internal to the site.=0A> > > > >=0A> > > > > I'll spea= k more on this below.=0A> > > > >=0A> > > > > > So IMHO the best way is the= mitigations I suggested and=0A> > > > > > that you illustrated below in ps= eudo-code.=0A> > > > >=0A> > > > > OK.=0A> > > > >=0A> > > > > > See furthe= r comments inline.=0A> > > > > >=0A> > > > > > Gabi=0A> > > > > >=0A> > > >= > > ----- Original Message ----=0A> > > > > > > From: "Templin, Fred L"=0A= > > > > > > > To: Gabi Nakibly ; v6ops=0A> > > > > > > Cc: ipv6@ietf.org; s= ecdir@ietf.org=0A> > > > > > > Sent: Monday, August 24, 2009 10:04:34 PM=0A= > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > = > > > >=0A> > > > > > > Gabi,=0A> > > > > > >=0A> > > > > > > > -----Origin= al 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 tu= nnels=0A> > > > > > > >=0A> > > > > > > > Fred,=0A> > > > > > > > I initial= ly very much liked your suggestion regarding the check of =0A> the=0A> > > = > > > > neighbor cache before=0A> > > > > > > > forwarding a packet into th= e tunnel. It truly addresses the root =0A> cause=0A> > > of=0A> > > > > the= =0A> > > > > > > problem ans is simple=0A> > > > > > > > enough to implemen= t. However, I realized that an attacker can send =0A> a=0A> > > > > > > spo= ofed RS to the ISATAP router=0A> > > > > > > > as if it came from the 6to4 = relay. The router would then send a RA =0A> to=0A> > > > > it and=0A> > > >= > > > consequently change its=0A> > > > > > > > neighbor cache. So it seem= s that this defense does not add=0A> > > much. Wouldn't=0A> > > > > you=0A>= > > > > > > agree?=0A> > > > > > >=0A> > > > > > > I agree that my propose= d mitigation is only useful when there=0A> > > > > > > is assurance of a co= herent neighbor cache in the ISATAP router.=0A> > > > > > > That would be t= rue in the case in which the ISATAP router is=0A> > > > > > > located withi= n a site protected by border routers that perform=0A> > > > > > > ip-proto-= 41 and ingress filtering, and in which there is no=0A> > > > > > > untracea= ble IPv4 source address spoofing. So AFAICT, my proposed=0A> > > > > > > mi= tigation is still necessary for preventing attack #3 when=0A> > > > > > > I= SATAP routers A and B are on separate ISATAP links within=0A> > > > > > > t= he same site-internal IPv4 routing region.=0A> > > > > > >=0A> > > > > >=0A= > > > > > > This is only true when the attacker is outside the site and pro= to-41=0A> > > filtering=0A> > > > > is employed. If the=0A> > > > > > attac= ker is internal to the site then the proto-41 filtering will not =0A> help= =0A> > > and=0A> > > > > the neighbor cache can=0A> > > > > > be poisoned.= =0A> > > > >=0A> > > > > Since the ISATAP checks require that the IPv6 sour= ce embed the=0A> > > > > IPv4 source and/or the IPv4 source is a PRL router= , you must be=0A> > > > > speaking here about IPv4 source address spoofing = from within the=0A> > > > > site. For sites that allow intra-site source ad= dress spoofing,=0A> > > > > I think much more serious problems could manife= st themselves=0A> > > > > that would be completely unrelated to ISATAP. I b= elieve you=0A> > > > > will also find other automatic tunneling protocols b= esides=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 that the=0A> > > > > > > > destination ISATAP address does = not include a local IPv4 address =0A> since=0A> > > the=0A> > > > > > > ISA= TAP address may include=0A> > > > > > > > a private IPv4 address. On the ot= her hand, a check on public IPv4=0A> > > > > addresses is=0A> > > > > > > a= cceptable. If the=0A> > > > > > > > check would be done only on ISATAP addr= esses that include public =0A> IPv4=0A> > > > > > > addresses then this wil= l=0A> > > > > > > > eliminate the attacks in which the two victims reside a= t different=0A> > > sites.=0A> > > > > Note=0A> > > > > > > that if attack = #3 is=0A> > > > > > > > launched on two ISATAP routers having private addre= sses at two=0A> > > different=0A> > > > > sites=0A> > > > > > > then the at= tack will=0A> > > > > > > > not work anyway since one router can not send a= direct IPv4 packet =0A> to=0A> > > the=0A> > > > > > > other. In addition,= =0A> > > > > > > > to mitigate attacks in which the other victim is a 6to4 = relay =0A> (such as=0A> > > > > attack=0A> > > > > > > #1) then a check wou= ld=0A> > > > > > > > have to be done on a 6to4 address, i.e. the destinatio= n address =0A> must=0A> > > not=0A> > > > > be=0A> > > > > > > "2002:> > th= e ISATAP router>::*". In this case the IPv4 address must =0A> be=0A> > > > = > public,=0A> > > > > > > according to=0A> > > > > > > >=A0 the 6to4 spec.= =0A> > > > > > > >=0A> > > > > > > > As you also noted there is another pro= blem with this check since =0A> the=0A> > > > > string=0A> > > > > > > "200= ::5EFE" is not unique=0A> > > > > > > > to ISATAP links. On the other hand,= it seems that the probability =0A> to=0A> > > > > encounter=0A> > > > > > = > a non-malicious packet=0A> > > > > > > > with a destination address havin= g an IID that equals "200:5EFE:> =0A> IPv4=0A> > > > > address>" is=0A> > >= > > > > > pretty slim.=0A> > > > > > > >=0A> > > > > > > > This check is d= efinitely not a perfect solution, and I sure hope =0A> that=0A> > > > > som= eone=0A> > > > > > > will come up with a=0A> > > > > > > > better one for m= itigating the routing loops. However, I would be =0A> happy=0A> > > if=0A> = > > > > > > there is some kind of other=0A> > > > > > > > mitigation measur= es besides packet filtering (proto-41 and =0A> ingress)=0A> > > > > by othe= r=0A> > > > > > > nodes (which does not=0A> > > > > > > > necessarily exist= ).=0A> > > > > > >=0A> > > > > > > You seem to be envisioning a scenario of= ISATAP router operation=0A> > > > > > > with public IPv4 addresses and out= side 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 p= ossibility of what I called the "inside-out ISATAP=0A> > > > > > > model" i= n a list message long ago (which AFAICT is the scenario=0A> > > > > > > you= are alluding to).=0A> > > > > > >=0A> > > > > >=0A> > > > > > Well, I am r= eferring to any ISATAP deployment with public IPv4 =0A> addresses=0A> > > a= nd=0A> > > > > no proto-41 filtering. I=0A> > > > > > imagine that in pract= ice there are such deployments which are not the=0A> > > > > "inside-out IS= ATAP model" .=0A> > > > > > However, I must admit that I do not rely here o= n hard evidence.=0A> > > > > >=0A> > > > > > > So, if the public IPv4 Inter= net were considered as one gigantic=0A> > > > > > > "site" and we wanted to= do ISATAP on that site, it would be nice=0A> > > > > > > to divide the sit= e into multiple logical partitions, with each=0A> > > > > > > partition ide= ntified by a PRL name and a unique set of IPv6=0A> > > > > > > prefixes. Bu= t 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 untraceable IPv4=0A> > > > > > > source ad= dress spoofing such that the neighbor cache check=0A> > > > > > > mitigatio= n can be subverted.=0A> > > > > > >=0A> > > > > > > This means that if we w= ant to support the inside-out ISATAP=0A> > > > > > > model then the routing= loops could be mitigated either by=0A> > > > > > > 1) implementing the des= tination address checks you are=0A> > > > > > > suggesting, or 2) by not al= lowing ISATAP router interfaces=0A> > > > > > > that are not behind filteri= ng border routers to advertise=0A> > > > > > > non-link-local on-link IPv6 = prefixes and/or forward packets=0A> > > > > > > from non-link-local prefixe= s in the first place.=0A> > > > > > >=0A> > > > > > > If we took the easy w= ay out and did 2), then the entire=0A> > > > > > > IPv4 Internet would look= like one gigantic ISATAP link that=0A> > > > > > > only did IPv6 link-loca= l. So, nodes could ping6 each others'=0A> > > > > > > ISATAP link-local add= resses but that's about it.=0A> > > > > > >=0A> > > > > > > If we took the = more ambitious route and allowed ISATAP to=0A> > > > > > > flourish fully w= ithin the global IPv4 Internet, then we=0A> > > > > > > would essentially b= e deprecating 6to4 - so it isn't=0A> > > > > > > surprising that your addre= ss checks mostly involve 6to4=0A> > > > > > > suppression. Assuming this, i= f I read your attack scenarios=0A> > > > > > > 1 through 3 correctly then s= cenarios 1 and 3 are mitigated=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 "2002::= :*")=0A> > > > > > >=A0 =A0 =A0 drop_pkt(); /* attack #1 mitigation */=0A> = > > > > > >=0A> > > > > > >=A0 =A0 if (dst =3D=3D "*::0200:5efe:")=0A> > > = > > > >=A0 =A0 drop_pkt(); /* attack #3 mitigation */=0A> > > > > > >=A0 = =A0 ...=0A> > > > > > >=A0 }=0A> > > > > > >=0A> > > > > >=0A> > > > > > Co= rrect (with the correction you sent after this email).=0A> > > > >=0A> > > = > > OK.=0A> > > > >=0A> > > > > > >=A0 isatap_xmt() {=0A> > > > > > >=A0 = =A0 ...=0A> > > > > > >=A0 =A0 if (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> > > > > > This wi= ll not necessarily work, since the 6to4 relay may have a =0A> unicast=0A> >= > > > address the ISATAP router may=0A> > > > > > not be aware of. The bes= t way to mitigate attack #2 is by the 6to4 =0A> relay=0A> > > with=0A> > > = > > a check similar to that=0A> > > > > > of attack #2 above. IMO, the seco= nd best way, as Remi suggested on =0A> another=0A> > > > > thread, is for t= he ISATAP=0A> > > > > > router to drop the packet if (src=A0 =3D=3D 2002:::= *"). However, this=0A> > > > > check is useful only=0A> > > > > > when the = 6to4 relay validates that the IPv6 source address corresponds =0A> to=0A> >= > the=0A> > > > > IPv4 one (this is=0A> > > > > > in accordance with the 6= to4 spec, however it does not always get=0A> > > implemented).=0A> > > > > = If this is not true=0A> > > > > > then the attacker does not have to send t= he 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 to 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 sc= enarios we need to consider?=0A> > > > > > >=0A> > > > > >=0A> > > > > >=0A= > > > > > > > Thanks - Fred=0A> > > > > > > fred.l.templin@boeing.com=0A> >= > > > > >=0A> > > > > > > >=0A> > > > > > > > Gabi=0A> > > > > > > >=0A> >= > > > > > > ----- Original Message ----=0A> > > > > > > > From: "Templin, = Fred L"=0A> > > > > > > > To: Gabi Nakibly ; v6ops=0A> > > > > > > > Cc: ip= v6@ietf.org; secdir@ietf.org=0A> > > > > > > > Sent: Wednesday, August 19, = 2009 6:16:18 PM=0A> > > > > > > > Subject: RE: Routing loop attacks using I= Pv6 tunnels=0A> > > > > > > >=0A> > > > > > > > Hi Gabi,=0A> > > > > > > >= =0A> > > > > > > > I'm sorry to have to keep turning this into plaintext,= =0A> > > > > > > > but annotation is difficult otherwise. See below for=0A>= > > > > > > > my responses (=3D=3D>):=0A> > > > > > > >=0A> > > > > > > > = ________________________________________=0A> > > > > > > > From: Gabi Nakib= ly [mailto:gnakibly@yahoo.com]=0A> > > > > > > > Sent: Wednesday, August 19= , 2009 1:49 AM=0A> > > > > > > > To: Templin, Fred L; v6ops=0A> > > > > > >= > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > Subject: Re: Routin= g loop attacks using IPv6 tunnels=0A> > > > > > > >=0A> > > > > > > > Fred,= =0A> > > > > > > > See my comments inline ().=0A> > > > > > > >=0A> > > > >= > > > ________________________________________=0A> > > > > > > > From: "Te= mplin, 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 us= ing IPv6 tunnels=0A> > > > > > > >=0A> > > > > > > > Gabi,=0A> > > > > > > = >=0A> > > > > > > > ________________________________________=0A> > > > > > = > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > > > > > Sent: = Tuesday, August 18, 2009 3:29 AM=0A> > > > > > > > To: Templin, Fred L; v6o= ps=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 me= ant=0A> > > > > > > > > to be an enterprise-interior (note that it is still= assumed=0A> > > > > > > > > that the associated IPv4 address is non-privat= e). As we=0A> > > > > > > > > explicitly note in the paper, the first three= attacks will=0A> > > > > > > > > be mitigated if proper protocol-41 filter= ing is deployed on=0A> > > > > > > > > the site's border. However, note tha= t RFC5214 does not mandate=0A> > > > > > > > > or require this filtering.= =0A> > > > > > > >=0A> > > > > > > > The RFC5214 Security Considerations ma= kes clear the=0A> > > > > > > > consequences of not implementing IPv4 ingre= ss filtering=0A> > > > > > > > and ip-protocol-41 filtering (i.e., a possib= le spooing=0A> > > > > > > > attack in which spurious ip-protocol-41 packet= s are=0A> > > > > > > > injected into an ISATAP link from outside). RFC5214= =0A> > > > > > > > Section 6.2 additionally requires that an ISATAP interfa= ce's=0A> > > > > > > > locator set MUST NOT span multiple sites. This means= that the=0A> > > > > > > > ISATAP interface must not decapsulate nor sourc= e ip-proto-41=0A> > > > > > > > packets within multiple sites, where the en= terprise interior=0A> > > > > > > > is site #1 and the global Internet is s= ite #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 co= rrectly. In=0A> > > > > > > > attack #2, for example, I assume the ISATAP r= outer has two=0A> > > > > > > > physical interfaces. A site-internal IPv4 i= nterface with an=0A> > > > > > > > address IPisatap and a site-external IPv= 6 interface. I also=0A> > > > > > > > assume that there is another border r= outer which connects the=0A> > > > > > > > site to the IPv4 Internet. The I= SATAP router has an ISATAP=0A> > > > > > > > interface with a single locato= r: (IPisatap, site-internal=0A> > > > > > > > interface). When the ISATAP r= outer gets an IPv6 via its=0A> > > > > > > > external interface it will enc= apsulate the packet accordingly=0A> > > > > > > > and forward it through th= e internal IPv4 interface. If the=0A> > > > > > > > encapsulated packet is = destined to a node outside the site=0A> > > > > > > > then the only thing t= hat stops it is a proto-41 filtering=0A> > > > > > > > at the other 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 maj= or enterprise=0A> > > > > > > > =3D=3D> network that does this.=0A> > > > >= > > >=0A> > > > > > > > > It is only mentioned as a possible mitigation ag= ainst=0A> > > > > > > > > incoming spurious protocol-41 packets. In additio= n,=0A> > > > > > > > > Section 10 of RFC5214 only mentions ingress not egre= ss=0A> > > > > > > > > filtering. Hence it will not stop attack #2.=0A> > >= > > > > >=0A> > > > > > > > We are now talking about ip-proto-41 filtering= ; not ingress=0A> > > > > > > > filtering. ip-proto-41 filtering is in both= directions. It=0A> > > > > > > > prevents ip-proto-41 packets from enterin= g the enterprise=0A> > > > > > > > interior ISATAP site from the Internet a= nd prevents=0A> > > > > > > > ip-proto-41 packets from entering the Interne= t ISATAP=0A> > > > > > > > site from the enterprise interior. Else the ISAT= AP=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 leaving the end site and going out into=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, proto= col-41 filtering is not helpful when=0A> > > > > > > > > attack #3 is launc= hed on two routers that reside in the=0A> > > > > > > > > same site. Note t= hat it may be possible for the attack=0A> > > > > > > > > packet to be sour= ced from outside the site unless proper=0A> > > > > > > > > filtering of in= coming IPv6 packets is deployed. If the=0A> > > > > > > > > attacker reside= s in the site, usually ingress filtering=0A> > > > > > > > > will not be he= lpful since it is deployed in general on=0A> > > > > > > > > the site's bor= der.=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 = attacks #1 and #3 the=0A> > > ISATAP=0A> > > > > router=0A> > > > > > > sou= rces (actually=0A> > > > > > > > forwards) an IPv6 packet with a source add= ress having the=0A> > > > > corresponding prefix=0A> > > > > > > of the ISA= TAP tunnel.=0A> > > > > > > > In attacks #2 and #3 the ISATAP router source= s and IPv4 packet =0A> with=0A> > > its=0A> > > > > own=0A> > > > > > > IPv= 4 address as the=0A> > > > > > > > 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 ca= n 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 relay from the=0A> > = > > > > > > =3D=3D> ISATAP router, and case 2 in which no border router sep= arates=0A> > > > > > > > =3D=3D> the 6to4 relay from the ISATAP router.=0A>= > > > > > > > =3D=3D>=0A> > > > > > > > =3D=3D> In attack #1, we have an I= Pv6 packet with a local source=0A> > > > > > > > =3D=3D> address entering t= he site from the outside. IPv6 ingress=0A> > > > > > > > =3D=3D> filtering = at the site border router should prevent the=0A> > > > > > > > =3D=3D> pack= et 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 positioned outside of the= site's border routers;=0A> > > > > > > > =3D=3D> otherwise, it could be sp= oofed 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 6= to4=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 host on=0A> > > > > > > > =3D=3D> the ISATA= P 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 ISATA= P router and=0A> > > > > > > > =3D=3D> the 6to4 relay. If there is no borde= r router between the =0A> ISATAP=0A> > > > > > > > =3D=3D> router and the 6= to4 relay, then we have an identical 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 the 6to4 relay=0A> > > > >= > > > =3D=3D> oriented outside of a border router that filters 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 talkin= g to a 6to4 router and not an ISATAP router. In=0A> > > > > > > > =3D=3D> a= ttack #2, the ISATAP 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 an= d the=0A> > > > > > > > =3D=3D> 6to4 relay. Oftentimes, the "border router"= will be a two-=0A> > > > > > > > =3D=3D> interface router that implements = 6to4 on a site-external=0A> > > > > > > > =3D=3D> IPv4 interface and implem= ents ISATAP on a site-internal=0A> > > > > > > > =3D=3D> IPv4 interface and= performs ip-proto-41 filtering on packets=0A> > > > > > > > =3D=3D> from o= utside 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> > > > > > > > IPv= 6 ingress filtering which is an IPv6 security consideration=0A> > > > > > >= > and not an ISATAP nor IPv4 security consideration. BCP=0A> > > > > > > >= recommendations for network ingress filtering are documented=0A> > > > > >= > > in RFC2827 and it is expected that IPv6 routers that configure=0A> > >= > > > > > ISATAP interfaces will implement IPv6 ingress filtering=0A> > > = > > > > > according to the BCP.=0A> > > > > > > >=0A> > > > > > > > So If m= y last comment is correct than I do not see how ingress=0A> > > filtering= =0A> > > > > would=0A> > > > > > > help here. The only=0A> > > > > > > > ca= se where ingress filtering can help is in case of attack #3 when =0A> the= =0A> > > > > routers=0A> > > > > > > reside at the same=0A> > > > > > > > s= ite. In that case if the attack packet (packet 0) is sent from=0A> > > outs= ide=0A> > > > > the=0A> > > > > > > site then ingress=0A> > > > > > > > fil= tering on the border of the site will drop the packet.=0A> > > > > > > >=0A= > > > > > > > >=0A> > > > > > > > =3D=3D> Correct about the IPv6 ingress fi= ltering at the border,=0A> > > > > > > > =3D=3D> but as with attack #2 my e= rror in the previous message=0A> > > > > > > > =3D=3D> was in thinking the = ISATAP router A was forwarding the=0A> > > > > > > > =3D=3D> packet *out* o= f the ISATAP link when in fact from the=0A> > > > > > > > =3D=3D> ISATAP ro= uter'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 problem here is that the ISATAP router is blindly=0A> > >= > > > > > =3D=3D> forwarding a packet to a node that it assumes is a simpl= e=0A> > > > > > > > =3D=3D> host on the ISATAP link without first verifying= that the=0A> > > > > > > > =3D=3D> node has demonstrated a willingness to = participate as a=0A> > > > > > > > =3D=3D> host on the link. As you have po= inted out, this can lead=0A> > > > > > > > =3D=3D> to strange scenarios whe= n the anonymous node is a tunnel=0A> > > > > > > > =3D=3D> router of some s= ort 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 wheth= er the IPv6 destination address is an ISATAP=0A> > > > > > > > =3D=3D> addr= ess 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 exam= ple,=0A> > > > > > > > =3D=3D> if the ISATAP router configures an IPv4 addr= ess 10.0.0.1=0A> > > > > > > > =3D=3D> and is asked to forward an IPv6 pack= et with ISATAP=0A> > > > > > > > =3D=3D> destination address 2001:DB8::0:5E= FE:10.0.0.1 where the=0A> > > > > > > > =3D=3D> IPv6 prefix is foreign, the= router can't very well drop the=0A> > > > > > > > =3D=3D> packet as this w= ould 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 mitigation I think makes the most sens= e is=0A> > > > > > > > =3D=3D> for the ISATAP router to first verify that t= he node which=0A> > > > > > > > =3D=3D> it assumes to be a simple ISATAP ho= st has demonstrated a=0A> > > > > > > > =3D=3D> willingness to participate = in the link. That can be done=0A> > > > > > > > =3D=3D> by having the ISATA= P router first check the neighbor cache=0A> > > > > > > > =3D=3D> when it h= as a packet to send to verify that there is a=0A> > > > > > > > =3D=3D> cac= hed 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 o= nly if there is a pre-existing=0A> > > > > > > > =3D=3D> neighbor cache ent= ry and drop the packet otherwise. This=0A> > > > > > > > =3D=3D> implies th= at 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> > > > > > > > > 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 sh= ould be=0A> > > > > > > > > stopped intrinsically as much as possible by th= e tunnel=0A> > > > > > > > > participants and not relay on outside filterin= g rules.=0A> > > > > > > >=0A> > > > > > > > In RFC5214, Section 10 we have= : "restricting access to the=0A> > > > > > > > link can be achieved by rest= ricting access to the site". The=0A> > > > > > > > mitigations do exactly t= hat, and in such a way that ISATAP=0A> > > > > > > > nodes can operate with= only the necessary and sufficient=0A> > > > > > > > checks. So on this poi= nt, I do not share your opinion.=0A> > > > > > > >=0A> > > > > > > > What a= bout two ISATAP tunnels that reside on the same site like in=0A> > > attack= =0A> > > > > #3.=0A> > > > > > > Do you also think that=0A> > > > > > > > p= roto-41 filtering should barrier between the two tunnels within =0A> the=0A= > > > 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 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 in= side=0A> > > > > > > > =3D=3D> of the site border rather than outside. Also= proper=0A> > > > > > > > =3D=3D> ip-proto-41 filtering and IPv6 ingress fi= ltering at=0A> > > > > > > > =3D=3D> site borders.=0A> > > > > > > > =3D=3D= >=0A> > > > > > > > =3D=3D> Also, when there are multiple ISATAP links with= in the=0A> > > > > > > > =3D=3D> same local IPv4 routing region, an ISATAP = router should=0A> > > > > > > > =3D=3D> first verify a node's willingness t= o 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: R= outing loop attacks using IPv6 tunnels=0A> > > > > > > >=0A> > > > > > > >= =0A> > > > > > > > Gabi,=0A> > > > > > > >=0A> > > > > > > > Thanks for pub= lishing this work. In the document, attacks A, B and =0A> C=0A> > > > > > >= > correspond to a configuration that violates section 6.2 of =0A> RFC5214:= =0A> > > > > > > >=0A> > > > > > > > > 6.2.=A0 ISATAP Interface Address Con= figuration=0A> > > > > > > > >=0A> > > > > > > > >=A0 Each ISATAP interface= configures a set of locators consisting =0A> of=0A> > > IPv4=0A> > > > > >= > > >=A0 address-to-interface mappings from a single site; i.e., an =0A> I= SATAP=0A> > > > > > > > >=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=0A> > > ISATAP=0A> > > > > > > > is seen = both within the enterprise as site #1 and within the =0A> global=0A> > > > = > Internet=0A> > > > > > > > itself as site #2. If the ISATAP interface is = to be used as an=0A> > > enterprise-=0A> > > > > > > > interior interface, = it should therefore not accept IP-proto-41 =0A> packets=0A> > > > > > > > c= oming from an IPv4 source outside of the enterprise nor source=0A> > > > > = > > > IP-proto-41 packets that are destined to an IPv4 node outside of =0A>= the=0A> > > > > > > > enterprise. This condition should be satisfied by ha= ving the site=0A> > > border=0A> > > > > > > > routers implement IPv4 ingre= ss filtering and ip-protocol-41 =0A> filtering=0A> > > as=0A> > > > > > > >= required in Section 10 of RFC5214.=0A> > > > > > > >=0A> > > > > > > > It = is mentioned that attack C could also occur when the routers =0A> reside=0A= > > > > > > > > in the same site, where their addresses may be private. Thi= s would=0A> > > > > > > > correspond to a case in which an attacker within = the site attacks =0A> the=0A> > > > > > > > site itself, which can easily b= e traced - especially when source=0A> > > address=0A> > > > > > > > spoofin= g from a node within the site is prevented through proper=0A> > > ingress= =0A> > > > > > > > filtering.=0A> > > > > > > >=0A> > > > > > > > Fred=0A> = > > > > > > > fred.l.templin@boeing.com=0A> > > > > > > >=0A> > > > > > > >= ________________________________________=0A> > > > > > > > From: Gabi Naki= bly [mailto:gnakibly@yahoo.com]=0A> > > > > > > > Sent: Monday, August 17, = 2009 8:21 AM=0A> > > > > > > > To: v6ops=0A> > > > > > > > Cc: ipv6@ietf.or= g; secdir@ietf.org=0A> > > > > > > > Subject: Routing loop attacks using IP= v6 tunnels=0A> > > > > > > >=0A> > > > > > > > Hi all,=0A> > > > > > > > I = would like to draw the attention of the list=0A> > > to some research resul= ts=0A> > > > > which=0A> > > > > > > my colleague and I at=0A> > > > > > > = > the National EW Research & Simulation Center have recently =0A> published= .=0A> > > The=0A> > > > > > > research presents a class=0A> > > > > > > > o= f routing loop attacks that abuses 6to4, ISATAP and Teredo. The =0A> paper= =0A> > > can=0A> > > > > be=0A> > > > > > > found at:=0A> > > > > > > > htt= p://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 Internet. Since =0A> it=0A> > > is=0A= > > > > > not=0A> > > > > > > compatible with its=0A> > > > > > > > predece= ssor, some interoperability mechanisms were designed. An=0A> > > important= =0A> > > > > > > category of these=0A> > > > > > > > mechanisms is automati= c tunnels, which enable IPv6 communication =0A> over=0A> > > an=0A> > > > >= IPv4=0A> > > > > > > network without prior=0A> > > > > > > > configuration= . This category includes ISATAP, 6to4 and Teredo. We=0A> > > present=0A> > = > > > a=0A> > > > > > > novel class of attacks=0A> > > > > > > > that explo= it vulnerabilities in these tunnels. These attacks take=0A> > > > > advanta= ge of=0A> > > > > > > inconsistencies=0A> > > > > > > > between a tunnel's = overlay IPv6 routing state and the native IPv6=0A> > > routing=0A> > > > > = > > state. The attacks form=0A> > > > > > > > routing loops which can be ab= used as a vehicle for traffic=0A> > > amplification=0A> > > > > to=0A> > > = > > > > facilitate DoS attacks.=0A> > > > > > > > We exhibit five attacks o= f this class. One of the presented =0A> attacks=0A> > > can=0A> > > > > DoS= a=0A> > > > > > > Teredo server using a=0A> > > > > > > > single packet. T= he exploited vulnerabilities are embedded in the=0A> > > design of=0A> > > = > > the=0A> > > > > > > tunnels; hence any=0A> > > > > > > > implementation= of these tunnels may be vulnerable. In particular, =0A> the=0A> > > > > at= tacks=0A> > > > > > > were tested=0A> > > > > > > > against the ISATAP, 6to= 4 and Teredo implementations of Windows =0A> Vista=0A> > > and=0A> > > > > = > > Windows Server 2008 R2.=0A> > > > > > > >=0A> > > > > > > > I think the= results of the research warrant some corrective =0A> action. If=0A> > > > = > > > this indeed shall be the=0A> > > > > > > > general sentiment of the l= ist, I will be happy write an =0A> appropriate=0A> > > I-D.=0A> > > > > The= =0A> > > > > > > mitigation measures we=0A> > > > > > > > suggested in the = paper are the best we could think of to =0A> completely=0A> > > > > elimina= te=0A> > > > > > > the problem. However=0A> > > > > > > > they are far from= perfect since they would require tunnel=0A> > > implementations=0A> > > > = > to=0A> > > > > > > be updated in case new=0A> > > > > > > > types of auto= matic tunnels are introduced.=0A> > > > > > > >=0A> > > > > > > > Your comm= ents are welcome.=0A> > > > > > > >=0A> > > > > > > > Gabi=0A> > > > > > > = >=0A> > > > > > > >=0A> > > > > > > >=0A> > > > > >=0A> > > > > >=0A> > > >= > >=0A> > > >=0A> > > >=0A> > > >=0A> > > >=0A> >=0A> >=0A> >=0A> >=0A> --= ------------------------------------------------------------------=0A> IETF= IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrative Reque= sts: https://www.ietf.org/mailman/listinfo/ipv6=0A> -----------------------= ---------------------------------------------=0A=0A=0A=0A From owner-v6ops@ops.ietf.org Tue Sep 8 09:24: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 4A95428C18C for ; Tue, 8 Sep 2009 09:24:43 -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.192, 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 R4nkrYvDJdhC for ; Tue, 8 Sep 2009 09:24:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 131693A6856 for ; Tue, 8 Sep 2009 09:24:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml3Rr-00097g-Or for v6ops-data0@psg.com; Tue, 08 Sep 2009 16:21:39 +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 1Ml3Ra-000969-Og for v6ops@ops.ietf.org; Tue, 08 Sep 2009 16:21:37 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAIkhpkpAZnmf/2dsb2JhbACCVsNNiEMBj14FhBg X-IronPort-AV: E=Sophos;i="4.44,353,1249257600"; d="scan'208,217";a="57172967" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Sep 2009 16:21:21 +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 n88GLLti023807; Tue, 8 Sep 2009 12:21:21 -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 n88GLLWM011527; Tue, 8 Sep 2009 16:21:21 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 12:21:21 -0400 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_01CA30A0.66C4B10F" Subject: RE: Hello, Any Ideas as how I can catch up fast Date: Tue, 8 Sep 2009 12:21:22 -0400 Message-ID: In-Reply-To: <8d6a15670909040025sfcde567x58cbd615c417deba@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hello, Any Ideas as how I can catch up fast Thread-Index: AcotMfEbtmWfjR3rRY60htIiCHYLrADbfQLw References: <8d6a15670909040025sfcde567x58cbd615c417deba@mail.gmail.com> From: "Wes Beebee (wbeebee)" To: "Edwin Mulenga" , X-OriginalArrivalTime: 08 Sep 2009 16:21:21.0347 (UTC) FILETIME=[66F14930:01CA30A0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3166; t=1252426881; x=1253290881; c=relaxed/simple; s=rtpdkim2001; 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=20Hello,=20Any=20Ideas=20as=20how=20I=20c an=20catch=20up=20fast |Sender:=20 |To:=20=22Edwin=20Mulenga=22=20,=2 0; bh=TPqnrzUszXy9MA+zLNjpSbqgFN64HkefxZd6ZWBQ+ME=; b=hgeDAq9sQ7Pk42RkjqedndHHyI4xN0JvgY0Nl55do/FeCmYapYJ3Mqm8B3 A4hpfA0h915esW2bsni+mNmQ3aK9jXIX5LKCK/M1BpZHV8ienbiih34dfmw1 /8d3QiPmFv; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA30A0.66C4B10F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You can start by reading the charter, RFC's and working group documents, found on: =20 http://www.ietf.org/dyn/wg/charter/v6ops-charter.html =20 Then send any review comments for working group documents to this mailer. =20 - Wes ________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Edwin Mulenga Sent: Friday, September 04, 2009 3:26 AM To: v6ops@ops.ietf.org Subject: Hello, Any Ideas as how I can catch up fast I really would like to actively participate in this working group,.. any ideas to find myself on the right track? Or I need to consult literature? =20 Thanks, =20 Edwin ------_=_NextPart_001_01CA30A0.66C4B10F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
You can start by reading the charter, RFC's and = working=20 group documents, found on:
 
http://www= .ietf.org/dyn/wg/charter/v6ops-charter.html
 
Then send any review comments for working group = documents=20 to this mailer.
 
- Wes

From: owner-v6ops@ops.ietf.org=20 [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Edwin=20 Mulenga
Sent: Friday, September 04, 2009 3:26 AM
To: = v6ops@ops.ietf.org
Subject: Hello, Any Ideas as how I can = catch up=20 fast

I really would like to actively participate in this working = group,.. any=20 ideas to find myself on the right track?  Or I need to consult=20 literature?
 
Thanks,
 
Edwin
------_=_NextPart_001_01CA30A0.66C4B10F-- From owner-v6ops@ops.ietf.org Tue Sep 8 10:15: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 B78423A689B for ; Tue, 8 Sep 2009 10:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.605 X-Spam-Level: X-Spam-Status: No, score=-4.605 tagged_above=-999 required=5 tests=[AWL=-0.710, 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 pUHCI-uHdP45 for ; Tue, 8 Sep 2009 10:15:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88E7428C105 for ; Tue, 8 Sep 2009 10:15:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml4GY-000GeE-Bg for v6ops-data0@psg.com; Tue, 08 Sep 2009 17:14:02 +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 1Ml4FM-000GR2-Am for v6ops@ops.ietf.org; Tue, 08 Sep 2009 17:13:29 +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 n88HCY0K017136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Sep 2009 12:12:34 -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 n88HCXxA002519; Tue, 8 Sep 2009 12:12:33 -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 n88HCTsr002435; Tue, 8 Sep 2009 12:12:33 -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, 8 Sep 2009 10:12:29 -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: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' Date: Tue, 8 Sep 2009 10:12:28 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1065D807A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <58C86C6B78A448A890D98A311A60BBC1@JiangXiong> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' Thread-Index: Acoqcu8VCR/v6St/SJyVNzJoxoAu2QAsGJeAADaneSAA0SxSUABVB5BQ References: <31484.26522.qm@web45503.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com><373420.97768.qm@web45509.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A106599A1A@XCH-NW-7V2.nw.nos.boeing.com> <58C86C6B78A448A890D98A311A60BBC1@JiangXiong> From: "Templin, Fred L" To: , "v6ops" , "Fred Baker" Cc: , "Brian E Carpenter" X-OriginalArrivalTime: 08 Sep 2009 17:12:29.0611 (UTC) FILETIME=[8BC537B0:01CA30A7] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Sheng, > -----Original Message----- > From: Sheng Jiang [mailto:shengjiang@huawei.com] > Sent: Sunday, September 06, 2009 3:52 PM > To: Templin, Fred L; 'v6ops'; 'Fred Baker' > Cc: guoseu@huawei.com; 'Brian E Carpenter' > Subject: RE: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' >=20 > Hi, Templin, >=20 > Thanks so much for your comments. Can I ask you a question here: overall, do > you think this draft is suitable for v6ops charter and mature enough to be > adopted as wg file? > > Most of your comments are accepted and will be reflected in the next version > except for point 5. Actually, I am with you and these texts were in the > earlier version. However, Fred thought any normative material were not > suitable for 6vops wg and should be removed. Apparently, a recommendation > for MTU is normative rather than operational. So, unless Fred confirms > that's fine I cannot put the MTU text back. Fred? Thanks for considering the input. On point 5), however, it should be OK to talk about MTU without using words that could be construed as normative. For example, the original text could be reworded slightly as follows: =20 "However, for IPv6 traffic, a user behind the DS HG will see normal IPv6 service. We therefore observe that an IPv6 tunnel MTU of at least 1500 bytes would ensure that the mechanism does not cause excessive fragmentation of IPv6 traffic nor excessive IPv6 path MTU discovery interactions." Fred fred.l.templin@boeing.com > Many thanks and best regards, >=20 > Sheng >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > > Of Templin, Fred L > > Sent: Thursday, September 03, 2009 5:21 AM > > To: v6ops > > Cc: JiangSheng 66104; guoseu@huawei.com; Brian E Carpenter > > Subject: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' > > > > Below is my review of 'draft-jiang-v6ops-incremental-cgn-02.txt': > > > > Fred > > fred.l.templin@boeing.com > > > > --- > > > > 1) Section 1, second paragraph, the sentence beginning > > "They are too complicated..." is meaningless unless it > > were to name specific transition mechanisms within specific > > deployment scenarios. For example, perceived complications > > may only be relevant when necessary network-supporting > > infrasturcture is missing. Suggestion is to rewrite the > > paragraph as follows: > > > > "IPv4/IPv6 transition issues therefore become more critical > > and complicated for the soon-coming global IPv6 deployment. > > Host-based transition mechanisms alone may not be able to > > meet the requirements in all cases. Therefore, network > > supporting functions and/or new transition mechanisms > > with simple user-side operation are needed." > > > > 2) Section 1, paragraph 4, the final two sentences seem to > > imply that DSLite requires the ISP to upgrade its network > > to IPv6, but that is incorrect. DSLite can operate as > > IPv4-in-IPv6-in-IPv4 encapsulation, such that it can > > operate over IPv4-only networks as long as the CPE and > > CGN are dual-stacked. These two sentences need to be > > corrected to reflect this. > > > > 3 Section 2.1, the sentence: "The integration of NAT-PT > > is out of scope for this document." should be changed > > to: "The integration of such mechanisms is out of scope > > for this document." > > > > 4) Section 2.2, sentence beginning "Other tunneling > > mechanisms..." should read: > > > > "Other tunneling mechanisms such as 6over4 [RFC2529], the > > Intra-Site Automatic Tunnel Addressing Protocol [RFC5214] > > and Virtual Enterprise Traversal (VET) [VET] are also > > considered." > > > > 5) Section 2.6, bring back text removed from the -01 in a > > slightly modified form as follows: > > > > "However, for IPv6 traffic, a user behind the DS HG will > > see normal IPv6 service. It is therefore recommended that > > all IPv6 tunnels support an MTU of at least 1500 bytes, > > to ensure that the mechanism does not cause excessive > > fragmentation of IPv6 traffic nor excessive IPv6 path > > MTU discovery interactions." > > > > 6) Section 3, first part of first sentence, change to: > > "If the core network transitions to IPv6,". > > > > 7) Section 3, paragraph 3 - same comment as 2) above. DSLite > > does not require an IPv6-only ISP network, and can run as > > IPv4-in-IPv6-in-IPv4 in an IPv4-only ISP network in which the > > CPE and CGN are both dual-stacked. The advantages of using > > DSLite over v4-v4 NATing are that the CPE can use traffic > > engineering and ingress filtering by selecting specific CGNs > > through which to direct their traffic. This requires only > > that the CPE be able to discover the addresses of CGNs in > > the operator network. That process can be coupled with the > > ISATAP/VET Potential Router List (PRL) discovery mechanisms, > > in which case the CGN would be co-resident with an ISATAP/VET > > router that terminates IPv6-in-IPv4 intra-site tunnels. > > > > 8) Section 3.1, end of final sentence of first paragraph > > says: "so we refer to it non-specifically" but then names > > a specific service. To keep the sense of the sentence, > > it would have to be changed to: "so we refer to it > > non-specifically as "NAT64"." (i.e., and remove the > > specific citation). I am open to other suggestions. From owner-v6ops@ops.ietf.org Tue Sep 8 10:38: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 6080328C29F for ; Tue, 8 Sep 2009 10:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.597 X-Spam-Level: X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[AWL=-0.702, 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 6K1GKMMmeiz7 for ; Tue, 8 Sep 2009 10:38:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5CDE3A683C for ; Tue, 8 Sep 2009 10:38:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml4ZE-000JcP-5J for v6ops-data0@psg.com; Tue, 08 Sep 2009 17:33:20 +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 1Ml4Z2-000Jbc-Sa for v6ops@ops.ietf.org; Tue, 08 Sep 2009 17:33:17 +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 n88HWfkN015930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Sep 2009 10:32:42 -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 n88HWfto015364; Tue, 8 Sep 2009 12:32:41 -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 n88HWXdo015153; Tue, 8 Sep 2009 12:32:40 -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, 8 Sep 2009 10:32:40 -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: Review of 'draft-xu-v6ops-hybrid-framework-00.txt' Date: Tue, 8 Sep 2009 10:32:40 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1065D8095@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <58D3EFD90AF84F32B31B93F4E364F10E@JiangXiong> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of 'draft-xu-v6ops-hybrid-framework-00.txt' Thread-Index: AcosEzn9r9XEbtZGTxSbJCP7y5q29ADyz07gADJNVrA= References: <39C363776A4E8C4A94691D2BD9D1C9A106599A1B@XCH-NW-7V2.nw.nos.boeing.com> <58D3EFD90AF84F32B31B93F4E364F10E@JiangXiong> From: "Templin, Fred L" To: , "v6ops" Cc: , "Brian E Carpenter" X-OriginalArrivalTime: 08 Sep 2009 17:32:40.0743 (UTC) FILETIME=[5DA94B70:01CA30AA] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Sheng, > -----Original Message----- > From: Sheng Jiang [mailto:shengjiang@huawei.com] > Sent: Monday, September 07, 2009 10:14 AM > To: Templin, Fred L; 'v6ops' > Cc: xujf@gsta.com; 'Brian E Carpenter' > Subject: RE: Review of 'draft-xu-v6ops-hybrid-framework-00.txt' >=20 > Hi, Templin, >=20 > Thanks so much for your reviewing and comments. >=20 > All of your comments are accepted and will be reflected in the next version, > except for the below one. Can I ask you a question here: overall, do you > think this draft is suitable for v6ops charter and mature enough to be > adopted as wg file? >=20 > > 8) Section 3, second paragraph beginning: "In order to > > find NATs and traverse them,", this text seems to imply > > that *all* applications need to be made NAT-aware when > > in fact many/most applications are oblivious to NATs. > > Is there a certain class of applications this text is > > meaning to refer to? If so, the assumptions must be > > stated. >=20 > I guess, this refer is to these applications that want to traverse NATs. If > you have any specific text to suggest, we may adopt it in the next version. I guess when I think of NAT discovery and traversal, I think of NAT-specific end system services like STUN, TURN, ICE, TEREDO, etc. and not about "ordinary" IPv4 applications like ftp, web browsing, etc. Here is a proposed rewrite that I think could accommodate the concern: "In order to find NATs and traverse them, end system services have to understand network protocols deeply, invoke or interact with network protocols directly and analyse network behaviours by themselves, since the protocol stack on the end system is not aware of NATs. Fred fred.l.templin@boeing.com > Many thanks and best regards, >=20 > Sheng >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > > Of Templin, Fred L > > Sent: Thursday, September 03, 2009 5:21 AM > > To: v6ops > > Cc: xujf@gsta.com; JiangSheng 66104; Brian E Carpenter > > Subject: Review of 'draft-xu-v6ops-hybrid-framework-00.txt' > > > > Below is my review of 'draft-xu-v6ops-hybrid-framework-00.txt': > > > > Fred > > fred.l.templin@boeing.com > > > > --- > > > > 1) Abstract, the phrase "as many as possible" seems at > > odds with trusting the ISP to make informed choices. > > Suggest changing this to: "ISP networks may need to > > support multiple IPv6 connectivity solutions". > > > > 2) Section 1, paragraph 3, the phrase: "including the support > > of configured IPv6-over-IPv4 tunnels" should be shortened to > > "including the support of IPv6-over-IPv4 tunnels". > > > > 3) Section 1, paragraph 3, the phrase: "cannot be sufficient > > once IPv4 addresses have run out, because it" is not correct, > > because dual stack can still be used in environments that > > use IPv4 privacy addresses, which can exist even after the > > global IPv4 address run-out. Suggest shortening sentence to: > > > > "However, the dual stack approach does not allow IPv6-only > > hosts to communicate with IPv4-only hosts." > > > > which is true under any circumstances. > > > > 4) Section 1, paragraph beginning with "Each technique...", > > add VET to the "For example" list, i.e., as: > > > > "For example, VET (Virtual Enterprise Traversal [VET]), > > 6RD (IPv6 Rapid Deployment [6RD]), Port Range ..." > > > > 5) Section 1, paragraph beginning with "Up to now", > > change: "ISP networks need to support as many IPv6 > > connectivity solutions as is operationally reasonable" > > to" "ISP networks may need to support multiple IPv6 > > connectivity solutions". > > > > 6) Section 2, third paragraph, the trailing sentence: "Note > > that IPv6 autoconfiguration is not powerful enough for this > > purpose." does not seem to add any value and may instead > > serve only to confuse. Can this sentence be dropped? > > > > 7) Section 2, the paragraph beginning: "The hybrid ISP > > framework", change first sentence to: "The hybrid ISP > > framework may need to support multiple IPv6 connectivity > > solutions." > > > > 8) Section 3, second paragraph beginning: "In order to > > find NATs and traverse them,", this text seems to imply > > that *all* applications need to be made NAT-aware when > > in fact many/most applications are oblivious to NATs. > > Is there a certain class of applications this text is > > meaning to refer to? If so, the assumptions must be > > stated. > > > > 9) Section 4.2 should also cite IPv6 Prefix Options for > > DHCPv6 [RFC3633]. > > > > 10) Section 4.3, DNS SRV is not the only method used for > > service resolution. Remove the phrase: "using DNS SRV > > [2782]". From owner-v6ops@ops.ietf.org Tue Sep 8 10:40: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 52A4E28C29D for ; Tue, 8 Sep 2009 10:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[AWL=-0.688, 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 MZwmMhRzBL8Q for ; Tue, 8 Sep 2009 10:40:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA7803A683C for ; Tue, 8 Sep 2009 10:40:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml4eB-000KjH-7h for v6ops-data0@psg.com; Tue, 08 Sep 2009 17:38:27 +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 1Ml4cz-000KZv-Q1 for v6ops@ops.ietf.org; Tue, 08 Sep 2009 17:37:52 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n88Hb4q0026456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2009 10:37:05 -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 n88Hb4CL003538; Tue, 8 Sep 2009 10:37:04 -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 n88Hb3kV003491; Tue, 8 Sep 2009 10:37:04 -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, 8 Sep 2009 10:37:04 -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, 8 Sep 2009 10:37:03 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <702481.50824.qm@web45515.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcowkNv+/I1YdjLAQxm1S+S7B3HEXAACIoPw References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "Christian Huitema" , "v6ops" Cc: , X-OriginalArrivalTime: 08 Sep 2009 17:37:04.0108 (UTC) FILETIME=[FAA39AC0:01CA30AA] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gabi and Christian, Focusing only on attack #3 (i.e., leaving out attack #1 and #2 6to4 interactions for the moment), please check the following summary of proposed mitigations: 1) For ISATAP/VET routers that have assurance that their neighbor cache is coherent, the router can make a simple check in the neighbor cache to determine whether to forward or drop the packet. In pseudo-code: isatap_rcv() { ... if ((v6src is not a neighbor) && (v6dst !=3D "fe80::*")) drop_pkt(); ... } isatap_xmt() { ... if ((v6dst is not a neighbor) && (v6src !=3D "fe80::*")) drop_pkt(); ... } (Here, the link-local exception is necessary to bootstrap neighbor discovery on the ISATAP link.) Does anyone see a problem with this? 2) For ISATAP/VET routers that use public IPv4 addresses and that do not have assurance that their neighbor cache is coherent, the router can check for the interface ID "0200:5EFE:". In pseudo-code: isatap_rcv() { ... if (v6dst =3D=3D "foreign_prefix::0200:5efe:") drop_pkt(); ... } isatap_xmt() { ... if (v6src =3D=3D "foreign_prefix::0200:5efe:") drop_pkt(); ... } Does anyone see a problem with this? 3) For ISATAP/VET routers that use private IPv4 addresses and that do not have assurance that their neighbor cache is coherent, the router can make the checks that Christian has proposed. But, will we see any of these case 3) situations in operational practice? I would also like to point out that the attack vectors only occur when the ISATAP/VET router mistakes the other tunnel endpoint for a host when in fact the other end is another router. Mitigations for router-to-router ingress filtering are already specified in VET. Comments? Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Tuesday, September 08, 2009 5:28 AM > To: Christian Huitema; Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Hi Christian, > Thanks for your comments. >=20 >=20 > The checks=A0you suggested are powerful and will indeed mitigate the = attacks. The only thing that > worries me is the fact that=A0usually AFAIK the=A0ISATAP router is not = configured with the IPv4 subnet > addresses of the site. This means that the router must now be = configured with this information and > reconfigured as this information changes. If this is felt to be a = reasonable administrative overhead, > then I think the checks should be employed. >=20 > One minor thing that should be noted is that these checks will not = mitigate the attacks in case there > are two ISATAP links (with two separate routers)=A0in the same site. = This means=A0that their sets of > registered subnets coincide.=A0I assume that=A0such deployment are not = common, although I do not have the > information to back this assumption. >=20 > Gabi >=20 >=20 > ----- Original Message ---- > > From: Christian Huitema > > To: "Templin, Fred L" ; Gabi Nakibly = ; v6ops > > > Cc: "ipv6@ietf.org" ; "secdir@ietf.org" = > > Sent: Friday, September 4, 2009 10:25:21 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > I think that there is another possible way to protect against these = attacks, if > > the ISATAP router limits the range of IPv4 addresses towards which = it is willing > > to relay packets. That would fit many current deployments, maybe = most. > > > > In many current deployments, ISATAP is used to provide IPv6 = connectivity inside > > a "site", typically protected by a firewall. The expected behavior = is that hosts > > in that site will use direct ISATAP connectivity to exchange packets = with each > > other, and will use the ISATAP router to exchange packets with other = IPv6 > > subnets. > > > > Assume that the site is defined by a set of IPv4 subnets, and the = ISATAP router > > knows that list. The basic check in the ISATAP router is thus: > > > > =A0 =A0 =A0 =A0 On incoming packet: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If IPv6 source belongs to local = ISATAP subnet (matches /64=A0prefix): > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If (IPv4 source does = not match last 32 bits of IPv6=A0source): drop; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else If (IPv4 source = does not belong to one of=A0registered subnets): drop; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else relay; // we = may or may not want to add a=A0destination check > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If (IPv4 source = belongs to one of registered subnets):=A0drop; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else if (IPv6 = destination does not match ISATAP subnet):=A0drop; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else if (embedded = IPv4 address does not belong to of=A0registered subnets): > drop; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else relay; > > > > Written that way, the ISATAP router cannot create a loop, because = packets always > > go either from site to elsewhere, or from elsewhere to site. > > > > > > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of Templin, > > Fred L > > Sent: Friday, September 04, 2009 1:01 PM > > To: Gabi Nakibly; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > I'd like to make one other observation about these checks we > > have been discussing. There seems to be an implication that > > there needs to be a check on all of the IPv4 addresses assigned > > to the node's IPv4 interfaces, and with ISATAP there could be > > multiple underlying IPv4 interfaces over which the ISATAP > > interface is configured. So, that would seem like a potential > > performance issue if there were multiple IPv4 addresses to > > check for every packet. > > > > But, if the ISATAP router configures only a single IPv4 address > > and places it on the ISATAP interface (i.e., leaving all of the > > underlying IPv4 interfaces with only a link-local address) then > > there is only one IPv4 address to check. The technique is called: > > "link-layer multiplexing" and is described for ISATAP/VET in > > Appendix B of 'draft-templin-intarea-vet'. But, the idea really > > came from Section 3.3.4 of RFC1122. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Thursday, September 03, 2009 8:00 AM > > > To: Templin, Fred L; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Hi Fred, > > > see inline. > > > > > > Gabi > > > > > > ----- Original Message ---- > > > > From: "Templin, Fred L" > > > > To: Gabi Nakibly ; v6ops > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > Sent: Tuesday, September 1, 2009 6:49:56 PM > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > Gabi, > > > > > > > > > -----Original Message----- > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > Sent: Monday, August 31, 2009 12:41 PM > > > > > To: Templin, Fred L; v6ops > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > Fred, > > > > > > > > > > I agree that the source address check discussed below should = be made. I > > would > > > > also add a forth > > > > > check to mitigate attack #3 as a second layer of defense in = case the > > opposite > > > > ISATAP router does not > > > > > make the proper check on the destination address. > > > > > > > > > > isatap_xmt() { > > > > >=A0 =A0 =A0 ... > > > > >=A0 =A0 =A0 if (src =3D=3D "::0200:5efe:") > > > > >=A0 =A0 =A0 =A0 drop_pkt(); /* attack #3 mitigation */ > > > > >=A0 =A0 =A0 ... > > > > >=A0 } > > > > > > > > Having thought about it a bit, I agree but for ISATAP I see > > > > the source address check as a MAY and the destination address > > > > check as a SHOULD. > > > > > > Why do you think so? As I see it, the two checks mitigate two = different > > attacks. The destination > > > address check defends the ISATAP router against attacks of type 3 = in which it > > acts as > > > the decapsulator of the attack packet.=A0 While, the source = address check > > defends the ISATAP > > > router against attacks of type 3 in which it acts as the = ecapsulator of the > > attack packet.=A0 Either of > > > these checks are redundant if the other one is employed by the = opposite router > > of the attack. So I do > > > not see why one of them is a SHOULD and the other is a MAY. > > > > > > > > > > > In new automatic tunneling protocol specifications that use a > > > > different encapsulation format than ip-proto-41, as long as > > > > we make the destination address check a MUST before anything > > > > gets deployed then the source address check is unnecessary > > > > > > > > > > In principle, I agree with you. However, I am a believer of the = "defense in > > depth" paradigm: two > > > layers of security are (usually) better than one. Since no one can = be > > absolutely sure that the > > > destination address check shall always be implemented correctly at = all other > > routers then it may seem > > > prudent to also employ the source check as a second layer of = defense. > > > > > > > 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: Friday, August 28, 2009 11:23:40 PM > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > 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 > > > > > > > > > > > > > > Fred, > > > > > > > A quick summary of our discussion up until now: the best = mitigation > > > > of most of > > > > > > these attacks is > > > > > > > indeed the proto-41 and ingress filtering on the border of = the ISATAP > > > > site. If > > > > > > it is indeed > > > > > > > implemented. I assume 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. > > > > > > > > > > > > > > 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 and the 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 further comments inline. > > > > > > > > > > > > > > Gabi > > > > > > > > > > > > > > ----- 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 initially very much liked your suggestion regarding = the check of > > the > > > > > > > > neighbor cache before > > > > > > > > > forwarding a packet into the tunnel. It truly = addresses the root > > cause > > > > of > > > > > > the > > > > > > > > problem ans is simple > > > > > > > > > enough to implement. However, I realized that an = attacker can send > > a > > > > > > > > spoofed RS to the ISATAP router > > > > > > > > > as if it came from the 6to4 relay. The router would = then send a RA > > to > > > > > > it and > > > > > > > > consequently change its > > > > > > > > > neighbor cache. So it seems that this defense does not = add > > > > much. Wouldn'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. > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > I completely agree with your observation on the = non-feasibility of > > > > > > > > verifying that the > > > > > > > > > destination ISATAP address does not include a local = IPv4 address > > since > > > > the > > > > > > > > ISATAP address may include > > > > > > > > > a private IPv4 address. On the other hand, a check on = public IPv4 > > > > > > addresses is > > > > > > > > acceptable. If 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 = at different > > > > sites. > > > > > > Note > > > > > > > > that if attack #3 is > > > > > > > > > launched on two ISATAP routers having private = addresses at two > > > > different > > > > > > sites > > > > > > > > then the attack will > > > > > > > > > not work anyway since one router can not send a direct = IPv4 packet > > to > > > > the > > > > > > > > other. In addition, > > > > > > > > > to mitigate 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 perfect 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 measures besides packet filtering (proto-41 = and > > ingress) > > > > > > by other > > > > > > > > nodes (which does 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). > > > > > > > > > > > > > > > > > > > > > > Well, I am referring to any ISATAP deployment with 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" . > > > > > > > However, I must admit that I do not rely here on hard = evidence. > > > > > > > > > > > > > > > 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 drop_pkt(); /* attack #3 mitigation */ > > > > > > > >=A0 =A0 ... > > > > > > > >=A0 } > > > > > > > > > > > > > > > > > > > > > > Correct (with the correction you sent after this email). > > > > > > > > > > > > OK. > > > > > > > > > > > > > >=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 } > > > > > > > > > > > > > > This will not necessarily work, since the 6to4 relay may = have a > > unicast > > > > > > address the ISATAP router may > > > > > > > not be aware of. The best way to mitigate attack #2 is by = 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 accordance with 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 it is still = assumed > > > > > > > > > > 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 > > > > > > > > > > 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 is another border router which = connects 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 encapsulate the packet = accordingly > > > > > > > > > and forward it through the internal IPv4 interface. 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 other 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 ingress not = egress > > > > > > > > > > filtering. Hence it will 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 it may be possible for the = attack > > > > > > > > > > packet to 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 packet with a source address having = the > > > > > > corresponding prefix > > > > > > > > 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 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 > > > > > > > > > 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 should = 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 also 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 Each ISATAP interface configures a set of = locators consisting > > of > > > > IPv4 > > > > > > > > > >=A0 address-to-interface mappings from a single site; = i.e., an > > ISATAP > > > > > > > > > >=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 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 >=20 >=20 >=20 From nolan5@advantagecoaching.com Tue Sep 8 14:23: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 152953A67FC for ; Tue, 8 Sep 2009 14:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.531 X-Spam-Level: X-Spam-Status: No, score=-7.531 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=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_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, 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 BBoBGDdaA5rR for ; Tue, 8 Sep 2009 14:22:54 -0700 (PDT) Received: from 20six.de (unknown [190.210.21.245]) by core3.amsl.com (Postfix) with SMTP id 7160B28C1E4 for ; Tue, 8 Sep 2009 14:22:49 -0700 (PDT) To: Subject: Return mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090908212253.7160B28C1E4@core3.amsl.com> Date: Tue, 8 Sep 2009 14:22:49 -0700 (PDT) Show picture and go to site now! From mtn67546@runbox.com Tue Sep 8 14:46:33 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 92F9B3A6AB8 for ; Tue, 8 Sep 2009 14:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.078 X-Spam-Level: **** X-Spam-Status: No, score=4.078 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3qX-R13ZuQg for ; Tue, 8 Sep 2009 14:46:32 -0700 (PDT) Received: from web59913.mail.ac4.yahoo.com (web59913.mail.ac4.yahoo.com [76.13.12.211]) by core3.amsl.com (Postfix) with SMTP id 66D293A6A9E for ; Tue, 8 Sep 2009 14:46:30 -0700 (PDT) Received: (qmail 47429 invoked by uid 60001); 8 Sep 2009 21:47:01 -0000 Message-ID: <988139.47139.qm@web59913.mail.ac4.yahoo.com> X-YMail-OSG: 30GrQsYVM1krFYOIVN5w.rYl6CHmshl6zP400YhrBV.FEuRAhoumwhsx9mFMj6hAW1aBEe1FAZ0Fkd_4tjFzmx1F_0AfBadahWi.ixZc.fxR.fap1dt064mdSqWn4MqkphEYI5Inj8PRGI3BNSsssaLrdKWW_gf9iQ1ob_EmT2s80e5HUIUYHaXgUkSoswtwVBDb46Gf_KWaXrm1bwjDMMaeguitE1ipMw9D8ZQoj3kcmjo.c9wFyhfQusMYG9Hvxn6wYEFP Received: from [41.112.223.45] by web59913.mail.ac4.yahoo.com via HTTP; Tue, 08 Sep 2009 14:47:00 PDT X-RocketYMMF: mark.rudi X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.2 Date: Tue, 8 Sep 2009 14:47:00 -0700 (PDT) From: AWARNESS PROMOTION Reply-To: mtn67546@runbox.com Subject: ATTENTION: VALUED CUSTOMER,, To: undisclosed recipients: ; MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-882565084-1252446420=:47139" --0-882565084-1252446420=:47139 Content-Type: multipart/alternative; boundary="0-1455931773-1252446420=:47139" --0-1455931773-1252446420=:47139 Content-Type: text/plain; charset=us-ascii ATTENTION: VALUED CUSTOMER AFRICA HOST THE WORLD The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and authorized to receive it. Please notify us immediately by responding to this email Regards Mrs. Annalie Reid (online Coordinator) --0-1455931773-1252446420=:47139 Content-Type: text/html; charset=us-ascii
ATTENTION: VALUED CUSTOMER

AFRICA HOST THE WORLD

The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and authorized to receive it.

Please notify us immediately by responding to this email

Regards

Mrs. Annalie Reid
(online Coordinator)

--0-1455931773-1252446420=:47139-- --0-882565084-1252446420=:47139 Content-Type: application/msword; name="FROM FIFA MTN WORLD CUP AWARNESS PROMOTION SA.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="FROM FIFA MTN WORLD CUP AWARNESS PROMOTION SA.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAAZwAAAAAAAAAAEAAAaQAAAAEAAAD+////AAAAAGYAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////spcEAcWAJBAAA+BK/AAAAAAAAEAAAAAAABgAA ABcAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYAm3UAABM6AQAT OgEAEAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7wMAAAAAAAD//w8AAAAAAAAA AAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAO4EAAAA AAAA7gQAAO4EAAAAAAAA7gQAAAAAAABiBQAAAAAAAGIFAAAAAAAAYgUAABQA AAAAAAAAAAAAAHYFAAAAAAAAPhQAAAAAAAA+FAAAAAAAAD4UAAAAAAAAPhQA AEwAAACKFAAAZAAAAHYFAAAAAAAAnB8AACwCAAD6FAAAcAAAAGoVAAAAAAAA ahUAAAAAAABqFQAAAAAAAPIVAAAAAAAADRsAAAAAAAANGwAAAAAAAA0bAAAA AAAAGx8AAAIAAAAdHwAAAAAAAB0fAAAAAAAAHR8AAAAAAAAdHwAAAAAAAB0f AAAAAAAAHR8AACQAAADIIQAAaAIAADAkAACOAQAAQR8AABUAAAAAAAAAAAAA AAAAAAAAAAAAYgUAAAAAAAD5GwAAAAAAAAAAAAAAAAAAAAAAAAAAAABzGgAA mgAAAA0bAAAAAAAA+RsAAAAAAAD5GwAAAAAAAEEfAAAAAAAAAAAAAAAAAADu BAAAAAAAAO4EAAAAAAAAahUAAAAAAAAAAAAAAAAAAPIVAACBBAAAVh8AABYA AABxHQAAAAAAAHEdAAAAAAAAcR0AAAAAAAD5GwAAEAAAAO4EAABSAAAAahUA AHAAAABiBQAAAAAAAPIVAAAAAAAAGx8AAAAAAAAAAAAAAAAAAHEdAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA+RsAAAAAAAAbHwAAAAAAAAAAAAAAAAAAcR0AAAAAAAAAAAAAAAAAAHEd AAAAAAAAQAUAACIAAABiBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcR0AAAAAAADaFQAA GAAAAO4UAAAMAAAAwOb8hpIwygEAAAAAAAAAAD4UAAAAAAAACRwAABAAAABx HQAAAAAAAAAAAAAAAAAAJx4AAPQAAABsHwAAMAAAAJwfAAAAAAAAcR0AAAAA AAC+JQAAAAAAABkcAABIAQAAviUAAAAAAABxHQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABxHQAAQgAAAL4lAAAAAAAAAAAAAAAAAABiBQAAAAAAALMdAAB0 AAAADRsAACIAAAAvGwAAGAAAAHEdAAAAAAAARxsAABQAAABbGwAAdgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADRsAAAAAAAANGwAAAAAA AA0bAAAAAAAAQR8AAAAAAABBHwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAYR0AABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA0bAAAAAAAADRsAAAAAAAANGwAAAAAAAJwfAAAAAAAA0RsAABIA AADjGwAADgAAAPEbAAAIAAAA+RsAAAAAAAAAAAAAAAAAAHYFAAAAAAAAdgUA AAAAAAB2BQAAxAcAADoNAAAEBwAAdgUAAAAAAAB2BQAAAAAAAHYFAAAAAAAA Og0AAAAAAAB2BQAAAAAAAHYFAAAAAAAAdgUAAAAAAADuBAAAAAAAAO4EAAAA AAAA7gQAAAAAAADuBAAAAAAAAO4EAAAAAAAA7gQAAAAAAAD/////AAAAAAIA DAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgICAgg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV0lOTklORyBSRUZF UkVOQ0UgTlVNQkVSIElTOiBGTFMtWlIzOS04MjVQLTQgDUJhdGNoIE51bWJl cjogNzQtMjYzLUJCTi4NVElDS0VUIE5VTUJFUjogIDEwMC0gMzA5LSA3NDgy IA1TRVJJQUwgTlVNQkVSOiA1MTMtIDEwIA1XSU5OSU5HIE5VTUJFUlM6IDAy LCAwOSwgMjIsIDIzLCAyNCwgMzAgKDA1KQ0NRGVhciBMdWNreSBXaW5uZXIs DQ1UaGUgU291dGggQWZyaWNhIE1UTiBOZXR3b3JrIHByaXZhdGUgaW50ZXJu YXRpb25hbCBlLWdhbWVzIGZvciBTb3V0aCBBZnJpY2FuIDIwMTAgV29ybGQg Q3VwIFByb21vdGlvbiB3ZSBhcmUgcGxlYXNlZCB0byBpbmZvcm0geW91IG9m IHRoZSByZXN1bHQgb2YgdGhloGZpbmFsIGNvbmNsdWRlZCBkcmF3c6B3aGlj aCB3YXMgY29uZHVjdGVkIGF0IG91ciBpbnRlcm5hdGlvbmFsIGNvcnBvcmF0 ZSBvZmZpY2UgY29tcGxleCBoZXJlIGluIFNvdXRoIEFmcmljYSwgYnkgTVRO IE5ldHdvcmsgeW91ciBlbWFpbKB3YXMgYW1vbmcgdGhlIDIwIEx1Y2t5IHdp bm5lcnMgd2hvIHdvbiBjYXNoIHByaXplIG9mICQ5NTAsIDAwMCwgMDAoTmlu ZSBIdW5kcmVkIGFuZCBGaWZ0eSBVbml0ZWQgc3RhdGUgRG9sbGFycykgW1Ro aXMgaXMgaW4gbGluZSB3aXRoIG91ciBwcm9tb3Rpb24gZm9yIHRoZSB3b3Js ZC1jdXAgY29tZSAyMDEwLiBUaGUgc2VsZWN0aW9uIHByb2Nlc3Mgd2FzIGNh cnJpZWQgb3V0IHRocm91Z2ggcmFuZG9tIHNlbGVjdGlvbiBpbiBvdXIgY29t cHV0ZXJpemVkIGVtYWlsIHNlbGVjdGlvbiBzeXN0ZW0gZnJvbSBhIGRhdGFi YXNlIG9mIG92ZXIgMjUwLDAwMCBlbWFpbCBhZGRyZXNzZXMgZHJhd24gYWNy b3NzIHRoZSBjb250aW5lbnRzIG9mIHRoZSB3b3JsZC4gDQ1QYXJ0aWNpcGFu dHMgZm9yIHRoZSBkcmF3cyB3ZXJlIHJhbmRvbWx5IHNlbGVjdGVkIGFuZCBk cmF3biBmcm9tIGEgd2lkZSByYW5nZSBvZiB3ZWIgSG9zdHMgd2hpY2ggd2Ug ZW5qb3kgdGhlaXIgcGF0cm9uYWdlLiBUaGlzIHByb21vdGlvbiBpcyBzcG9u c29yZWQgYnkgdGhlIEZlZGVyYXRpb24gSW50ZXJuYXRpb25hbCBGb290YmFs bCBBc3NvY2lhdGlvbiBbTVROIEZJRkFdL1NPRlRXQVJFIEdJQU5UUyBhbmQg YXBwcm92ZWQgYW5kIGxpY2Vuc2VkIGJ5IHRoZSBJbnRlcm5hdGlvbmFsIEFz c29jaWF0aW9uIG9mIEdhbWluZyBSZWd1bGF0b3JzIChJQUdSKS4gDSANVG8g ZmlsZSBmb3IgeW91ciBjbGFpbSwgcGxlYXNlIGNvbnRhY3QgeW91ciBDbGFp bWluZyBBZ2VudCBpbW1lZGlhdGVseS4NIA1OQU1FOiBHT1JET04gU1RFWU4N RW1haWw6IGdvcmRvbi5zdGV5bkBncmFkdWF0ZS5vcmcgDVBIT05FIE5PLjog KzI3LTczNzUxOTg3Mw1QbGVhc2UgcHJvdmlkZSB0aGUgZm9sbG93aW5nIGRl dGFpbHMgZm9yIHByb2Nlc3Npbmcgb2YgeW91ciBjbGFpbS4NDSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZFUklGSUNBVElPTqBGT1JN DQ0xLCBOYW1lcyBpbiBmdWxsOiAgICAgICAgICAgICAgICAgICAgICAgIAcH MiygQ291bnRyeSBvZiBSZXNpZGVuY2U6oKCgICAgICAHBzMsIE5hdGlvbmFs aXR5OqAgICAgICAgICAgICAgICAgICAgICAgICAgIAcHNCygUmVzaWRlbnRp YWwgQWRkcmVzczogICAgICAgICAgICAgBwc1LCBEYXRlIG9mIEJpcnRoL0Fn ZTogICAgICAgICAgICAgICAgIAcHNiwgTWFyaXRhbCBTdGF0dWUvU2V4OiAg ICAgICAHBzcsIFRlbC9GYXg6ICAgICAgICAgICAgICAgICAgICAgICAgICAH BzgsIE1vYmlsZSBObzogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAH BzksIE9jY3VwYXRpb246ICAgICAgICAgICAgICAgICAgICAgICAgICAHBzEw LCBDb21wYW55OiAgICAgICAgICAgICAgICAgICAgICAgICAgICAHBzExLCBB bW91bnQgV29uOiAgICAgICAgICAgICAgIAcHMTIsIEVtYWlsIGFkZHJlc3M6 oCCgICAgICAgICAgICAgICAgICAgBwcxMywgUmVmoE5vOqAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAcHoCAgICAgIEFib3V0IE1UTqAgQSBn bG9iYWwgY29tbXVuaWNhdGlvbnMgcGFydG5lciBhbmQgd29ybGQtY2xhc3Mg Y2VsbHVsYXIgbmV0d29yayBTb3V0aCBBZnJpY2EHBwhDb3B5cmlnaHQgMjAw OCCpIE1vYmlsZSBUZWxlcGhvbmUgTmV0d29ya3MuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuIAsTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5tdG4uY29tLyIgXHQg Il9ibGFuayIgFENvbXBhbnkgUm9vbRUgfCATIEhZUEVSTElOSyAiaHR0cDov L3d3dy5tdG4uY28uemEvUGFnZXMvTVROSm9icy5hc3B4IiBcbyAiIiAUSm9i cxUgfCATIEhZUEVSTElOSyAiaHR0cDovL3d3dy5tdG4uY28uemEvUGFnZXMv U2l0ZU1hcC5hc3B4IiBcbyAiIiAUU2l0ZSBNYXAVIHwgEyBIWVBFUkxJTksg Imh0dHA6Ly93d3cubXRuLmNvLnphL1NlYXJjaC9hZHZhbmNlZC5hc3B4IiBc byAiIiAUU2VhcmNoIHRoZSBzaXRlFSB8IBMgSFlQRVJMSU5LICJodHRwOi8v d3d3Lm10bi5jby56YS9TdXBwb3J0L0xlZ2FsL1BhZ2VzL2RlZmF1bHQuYXNw eCIgXG8gIiIgFExlZ2FsFSB8IBMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lm10 bi5jby56YS9TdXBwb3J0L1BhZ2VzL0NvbnRhY3RDdXN0b21lckNhcmUuYXNw eCIgXG8gIiIgFENvbnRhY3QgVXMVC6kgMjAwNSBGSUZBIFRNDU1UTiBMT0NB TCBPUkdBTklTSU5HIENPTU1JVFRFRSBQUkVTRU5UUzoNU09VVEggQUZSEyBI WVBFUkxJTksgImh0dHA6Ly93d3cuc2EyMDEwLmdvdi56YS8iIFx0ICJfYmxh bmsiIBQVSUNBIDIwMTCgV09STEQgQ1VQIKCgoKCgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DUNPTkdSQVRVTEFUSU9OIaCgQ09OR1JBVFVMQVRJT04hIaCgQ09OR1JBVFVM QVRJT04hISEgICATIEhZUEVSTElOSyAiaHR0cDovL3d3dy5jdXAyMDEwLmlu Zm8vd2ViLWZlZWRzL1JTU2ZlZWRzLnhtbCIgFFdlYiBmZWVkcxUgEyBIWVBF UkxJTksgImh0dHA6Ly93d3cuY3VwMjAxMC5pbmZvL3dlYi1mZWVkcy9SU1Nm ZWVkcy54bWwiIBQTIElOQ0xVREVQSUNUVVJFICJodHRwOi8vd3d3LmN1cDIw MTAuaW5mby93ZWItZmVlZHMvcnNzLmdpZiIgXCogTUVSR0VGT1JNQVRJTkVU IBQBFRUgEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuY3VwMjAxMC5pbmZvL3dl Yi1mZWVkcy9SU1NmZWVkcy54bWwiIBQTIElOQ0xVREVQSUNUVVJFICJodHRw Oi8vd3d3LmN1cDIwMTAuaW5mby93ZWItZmVlZHMveG1sLmdpZiIgXCogTUVS R0VGT1JNQVRJTkVUIBQBFRUgRklGQQ0NDSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTVROIDIwMTAgV09STEQg Q1VQIExPVFRPDU1UTiBUaWNrZXRzIDIwMTAgV29ybGQgQ3VwIExvdHRlcnmS kiBiZXR0aW5xdHJhZGVtYXJrIHNwZXJzb25hbGl0aWVzbG9jYWwNT3JnYW5p emluZyBjb21taXR0ZWUgQ29uZmVkZXJhdGlvbiBDdXBtaXNjZWxsYW5lb3Vz a2l0IHN1cHBsaWVycw1Db3VudHJpZXNsYXdzYnJvYWRjYXN0aW5nbGlua3Nz YXRpcmUNDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAA AQgAAAIIAAADCAAABAgAAJAIAACtCAAA2ggAANsIAAD0CAAA9QgAAFoJAABb CQAAbwkAAK4JAADy5MS2sq6ZhJl1mWBLMwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAvFWiaeSQAFmi3ZKoANQiBQioBQ0oUAE9KAwBRSgMAXAiBXkoE AGFKFABwaAAAAAAoFWiaeSQAFmjtYZgANQiBQioBQ0oUAE9KAwBRSgMAYUoU AHBoAAAAAAAoFWifFqUAFmjtYZgANQiBQioGQ0oUAE9KAwBRSgMAYUoUAHBo /wAAAAAdFWiaeSQAFmjtYZgAQioBQ0oSAGFKEgBwaAAAAAAoFWiaeSQAFmgS S6IANQiBQioBQ0oSAE9KAwBRSgMAYUoSAHBoAAAAAAAoFWiaeSQAFmjtYZgA NQiBQioBQ0oSAE9KAwBRSgMAYUoSAHBoAAAAAAAGFmgSS6IAAAYWaO1hmAAA GgNqAAAAABZo7WGYAFUIAW1IAARuSAAEdQgBAD8DagAAAAAVaP5ZJwAWaPEH lgA1CIFCKgFDShAAT0oDAFFKAwBVCAFcCIFhShAAbUgABG5IAARwaAAAAAB1 CAEaA2oAAAAAFmhZQ+UAVQgBbUgABG5IAAR1CAEAGgNqAAAAABZoxn2bAFUI AW1IAARuSAAEdQgBDgAGAADbCAAA9QgAABUJAAAtCQAAWgkAAFsJAABuCQAA bwkAAAUMAAAGDAAARg0AAEgNAACQDQAAkg0AAKUNAADHDQAA4A0AACMOAAAk DgAAhw4AAIgOAACyDgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPIA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZCEe ggAABwAAAyQDYSQDZ2T+WScAAAQAAGdk7WGYAAAWAAYAABATAAD/FgAA/f0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAAB AQKuCQAAwQkAAMsJAACyCgAAtQoAAAUMAAAGDAAA0gwAANMMAABGDQAASA0A AJANAACSDQAAmA0AAOnQuKOOo455jmSOTzoAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgVaNs3AwAWaO1hmAA1CIFC KgJDShQAT0oDAFFKAwBhShQAcGgAAP8AACgVaC57lgAWaO1hmAA1CIFCKgJD ShQAT0oDAFFKAwBhShQAcGgAAP8AACgVaBJLogAWaO1hmAA1CIFCKgFDShQA T0oDAFFKAwBhShQAcGgAAAAAACgVaJp5JAAWaFJNgQA1CIFCKgFDShQAT0oD AFFKAwBhShQAcGgAAAAAACgVaJp5JAAWaO1hmAA1CIFCKgFDShQAT0oDAFFK AwBhShQAcGgAAAAAACgVaJp5JAAWaLdkqgA1CIFCKgFDShQAT0oDAFFKAwBh ShQAcGgAAAAAAC8VaJp5JAAWaLdkqgA1CIFCKgFDShQAT0oDAFFKAwBcCIFe SgQAYUoUAHBoAAAAADAVaJp5JAAWaLdkqgAwShAANQiBQioBQ0oUAE9KAwBR SgMAXkoEAGFKFABwaAAAAAAALBVomnkkABZot2SqADUIgUIqAUNKFABPSgMA UUoDAF5KBABhShQAcGgAAAAADZgNAACkDQAArA0AAMUNAADGDQAAxw0AAM8N AADRDQAA0g0AAN8NAADgDQAAIQ4AAOfSuqXSkHtwW0YxAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKBVoohLcABZo7WGYADUIgUIq AUNKFABPSgMAUUoDAGFKFABwaAAAAAAAKBVo2zcDABZo7WGYADUIgUIqAkNK FgBPSgMAUUoDAGFKFgBwaAAA/wAAKBVo2zcDABZoxn2bADUIgUIqAkNKFgBP SgMAUUoDAGFKFgBwaAAA/wAAFRVo2zcDABZoxn2bAEIqAnBoAAD/ACgVaNs3 AwAWaLYRKQA1CIFCKgJDShYAT0oDAFFKAwBhShYAcGgAAP8AACgVaNs3AwAW aLYRKQA1CIFCKgJDShQAT0oDAFFKAwBhShQAcGgAAP8AACkVaNs3AwAWaNs3 AwBCKgJDShIAT0oCAFFKAgBeSgIAYUoSAHBoAAD/AC8VaNs3AwAWaNs3AwA1 CIFCKgJDShIAT0oCAFFKAgBcCIFeSgIAYUoSAHBoAAD/ACgVaNs3AwAWaO1h mAA1CIFCKgJDShQAT0oDAFFKAwBhShQAcGgAAP8AAC8VaNs3AwAWaNs3AwA1 CIFCKgJDShIAT0oDAFFKAwBcCIFeSgQAYUoSAHBoAAD/AAALIQ4AACMOAAB1 DgAAhg4AAIcOAACIDgAAsQ4AALIOAACzDgAA0w4AANQOAADVDgAA2A4AAOMO AAD/DgAAAA8AAAEPAAAlDwAAJg8AACcPAABNDwAATg8AAE8PAABsDwAAbQ8A AG4PAACTDwAAlA8AAJUPAADADwAAwQ8AAMIPAADqDwAA6w8AAOwPAAAUEAAA 69nFsNmfkIWfkIWfcZ+QhZ+QhZ+QhVqQhVqQhZ+QhZ+QhZ8ALRVomnkkABZo 7WGYADBKDwBCKgFDShIAT0oFAFFKBQBeSgUAYUoSAHBoAAAAACcVaJp5JAAW aO1hmAAwShAANQiBQioBQ0oSAFwIgWFKEgBwaAAAAAAUFWirbm4AFmjtYZgA Q0oSAGFKEgAAHRVomnkkABZo7WGYAEIqAUNKEgBhShIAcGgAAAAAIRVomnkk ABZo7WGYADBKDwBCKgFDShIAYUoSAHBoAAAAACgVaD0/lwAWaO1hmAA1CIFC KgZDSiAAT0oDAFFKAwBhSiAAcGj/AAAAACYVaD0/lwAWaO1hmAA1CIE+KgFC KgZDSiAAXAiBYUogAHBo/wAAAAAiFmjtYZgANQiBQioIQ0oUAE9KAwBRSgMA YUoUAHBo////AAAoFWifFqUAFmjtYZgANQiBQioGQ0oUAE9KAwBRSgMAYUoU AHBo/wAAACOyDgAAsw4AANQOAADVDgAAkgAAAAAAAAAAAAAAAIkAAAAAAAAA AAAAAAAcAAAAAAAAAAAAAAAAAG0AAGtkpgAAABYkARckAUlmAQAAAAKWPAAF 1hgGEhAABhIQAAYSEAAGEhAAAAAAAAAAAAAI1hoAAbX/YS2ABqwtBhIQAAYS EAAGEhAABhIQABPWMAAAAP8GGgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAA AAAA/wAAAAAAAAD/AAAAABT2A6wtF/YDAAAY9gMAABrWBAAAAP8b1gQAAAD/ HNYEAAAA/x3WBAAAAP8z1gYAAQ8DAAA01gYAAQ8DPABh9gMAAGLWBBoaGhpw 1goAAAD/AAAA/wAACQAAFiQBSWYBAAAAZ2QhHoIAbQAAa2QAAAAAFiQBFyQB SWYBAAAAApY8AAXWGAYSEAAGEhAABhIQAAYSEAAAAAAAAAAAAAjWGgABtf9h LYAGrC0GEhAABhIQAAYSEAAGEhAAE9YwAAAA/wYaAAAAAAD/BhoAAAAAAP8G GgAAAAAA/wYaAAAAAAD/AAAAAAAAAP8AAAAAFPYDrC0X9gMAABj2AwAAGtYE AAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zPWBgABDwMAADTWBgABDwM8AGH2 AwAAYtYEGhoaGnDWCgAAAP8AAAD/AAAAA9UOAAAADwAAAQ8AACYPAAD2AAAA AAAAAAAAAAAAiQAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABtAABrZEwBAAAWJAEXJAFJ ZgEAAAACljwABdYYBhIQAAYSEAAGEhAABhIQAAAAAAAAAAAACNYaAAG1/2Et gAasLQYSEAAGEhAABhIQAAYSEAAT1jAAAAD/BhoAAAAAAP8GGgAAAAAA/wYa AAAAAAD/BhoAAAAAAP8AAAAAAAAA/wAAAAAU9gOsLRf2AwAAGPYDAAAa1gQA AAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/M9YGAAEPAwAANNYGAAEPAzwAYfYD AABi1gQaGhoacNYKAAAA/wAAAP8AAAkAABYkAUlmAQAAAGdkIR6CAAADJg8A ACcPAABODwAATw8AAJIAAAAAAAAAAAAAAACJAAAAAAAAAAAAAAAAHAAAAAAA AAAAAAAAAABtAABrZJgCAAAWJAEXJAFJZgEAAAACljwABdYYBhIQAAYSEAAG EhAABhIQAAAAAAAAAAAACNYaAAG1/2EtgAasLQYSEAAGEhAABhIQAAYSEAAT 1jAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8AAAAAAAAA /wAAAAAU9gOsLRf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQA AAD/M9YGAAEPAwAANNYGAAEPAzwAYfYDAABi1gQaGhoacNYKAAAA/wAAAP8A AAkAABYkAUlmAQAAAGdkIR6CAG0AAGtk8gEAABYkARckAUlmAQAAAAKWPAAF 1hgGEhAABhIQAAYSEAAGEhAAAAAAAAAAAAAI1hoAAbX/YS2ABqwtBhIQAAYS EAAGEhAABhIQABPWMAAAAP8GGgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAA AAAA/wAAAAAAAAD/AAAAABT2A6wtF/YDAAAY9gMAABrWBAAAAP8b1gQAAAD/ HNYEAAAA/x3WBAAAAP8z1gYAAQ8DAAA01gYAAQ8DPABh9gMAAGLWBBoaGhpw 1goAAAD/AAAA/wAAAANPDwAAbQ8AAG4PAACUDwAA9gAAAAAAAAAAAAAAAIkA AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAbQAAa2Q+AwAAFiQBFyQBSWYBAAAAApY8AAXW GAYSEAAGEhAABhIQAAYSEAAAAAAAAAAAAAjWGgABtf9hLYAGrC0GEhAABhIQ AAYSEAAGEhAAE9YwAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAA AAD/AAAAAAAAAP8AAAAAFPYDrC0X9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c 1gQAAAD/HdYEAAAA/zPWBgABDwMAADTWBgABDwM8AGH2AwAAYtYEGhoaGnDW CgAAAP8AAAD/AAAJAAAWJAFJZgEAAABnZCEeggAAA5QPAACVDwAAwQ8AAMIP AACSAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAbQAA a2SKBAAAFiQBFyQBSWYBAAAAApY8AAXWGAYSEAAGEhAABhIQAAYSEAAAAAAA AAAAAAjWGgABtf9hLYAGrC0GEhAABhIQAAYSEAAGEhAAE9YwAAAA/wYaAAAA AAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAAAAD/AAAAAAAAAP8AAAAAFPYDrC0X 9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zPWBgABDwMA ADTWBgABDwM8AGH2AwAAYtYEGhoaGnDWCgAAAP8AAAD/AAAJAAAWJAFJZgEA AABnZCEeggBtAABrZOQDAAAWJAEXJAFJZgEAAAACljwABdYYBhIQAAYSEAAG EhAABhIQAAAAAAAAAAAACNYaAAG1/2EtgAasLQYSEAAGEhAABhIQAAYSEAAT 1jAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8AAAAAAAAA /wAAAAAU9gOsLRf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQA AAD/M9YGAAEPAwAANNYGAAEPAzwAYfYDAABi1gQaGhoacNYKAAAA/wAAAP8A AAADwg8AAOsPAADsDwAAFRAAAPYAAAAAAAAAAAAAAACJAAAAAAAAAAAAAAAA 9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAG0AAGtkMAUAABYkARckAUlmAQAAAAKWPAAF1hgGEhAABhIQAAYS EAAGEhAAAAAAAAAAAAAI1hoAAbX/YS2ABqwtBhIQAAYSEAAGEhAABhIQABPW MAAAAP8GGgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wAAAAAAAAD/ AAAAABT2A6wtF/YDAAAY9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAA AP8z1gYAAQ8DAAA01gYAAQ8DPABh9gMAAGLWBBoaGhpw1goAAAD/AAAA/wAA CQAAFiQBSWYBAAAAZ2QhHoIAAAMUEAAAFRAAABYQAAAXEAAANBAAADUQAAA2 EAAAShAAAF4QAABfEAAAixAAAIwQAACNEAAAjhAAAJQQAACfEAAA7BAAAO0Q AADuEAAA7xAAADERAADw5dS98OXU8OXU8OWsnohxW1dJNgAAAAAlFWg9P5cA FmgSS6IAQioGQ0oQAE9KBgBRSgYAYUoQAHBo/wAAABoDagAAAAAWaBJLogBV CAFtSAAEbkgABHUIAQAGFmjtYZgAACsVaPN0JwAWaO1hmAA1CIFCKgFDShIA T0oHAFFKBwBcCIFhShIAcGgAAAAALBVo83QnABZo8QeWADBKEgA1CIFCKgFD ShIAT0oGAFFKBgBhShIAcGgAAAAAACsVaPN0JwAWaD0/lwA2CIFCKgFDSiMA T0oGAFFKBgBdCIFhSiMAcGgAAAAAGxZo83QnADBKDwBCKgFDShQAYUoUAHBo AAAAACEVaO1hmAAWaO1hmAAwSg8AQioIQ0oUAGFKFABwaP///wAtFWiaeSQA FmjtYZgAMEoPAEIqAUNKEgBPSgUAUUoFAF5KBQBhShIAcGgAAAAAIRVomnkk ABZo7WGYADBKDwBCKgFDShIAYUoSAHBoAAAAABQVaKtubgAWaO1hmABDShIA YUoSAAAdFWiaeSQAFmjtYZgAQioBQ0oSAGFKEgBwaAAAAAAAFBUQAAAWEAAA NRAAADYQAACSAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAABwAAAAAAAAAAAAA AAAAbQAAa2R8BgAAFiQBFyQBSWYBAAAAApY8AAXWGAYSEAAGEhAABhIQAAYS EAAAAAAAAAAAAAjWGgABtf9hLYAGrC0GEhAABhIQAAYSEAAGEhAAE9YwAAAA /wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAAAAD/AAAAAAAAAP8AAAAA FPYDrC0X9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zPW BgABDwMAADTWBgABDwM8AGH2AwAAYtYEGhoaGnDWCgAAAP8AAAD/AAAJAAAW JAFJZgEAAABnZCEeggBtAABrZNYFAAAWJAEXJAFJZgEAAAACljwABdYYBhIQ AAYSEAAGEhAABhIQAAAAAAAAAAAACNYaAAG1/2EtgAasLQYSEAAGEhAABhIQ AAYSEAAT1jAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8A AAAAAAAA/wAAAAAU9gOsLRf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAA AP8d1gQAAAD/M9YGAAEPAwAANNYGAAEPAzwAYfYDAABi1gQaGhoacNYKAAAA /wAAAP8AAAADNhAAAF4QAABfEAAAjBAAAPYAAAAAAAAAAAAAAACJAAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAG0AAGtkIgcAABYkARckAUlmAQAAAAKWPAAF1hgGEhAA BhIQAAYSEAAGEhAAAAAAAAAAAAAI1hoAAbX/YS2ABqwtBhIQAAYSEAAGEhAA BhIQABPWMAAAAP8GGgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wAA AAAAAAD/AAAAABT2A6wtF/YDAAAY9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA /x3WBAAAAP8z1gYAAQ8DAAA01gYAAQ8DPABh9gMAAGLWBBoaGhpw1goAAAD/ AAAA/wAACQAAFiQBSWYBAAAAZ2QhHoIAAAOMEAAAjRAAAO0QAACSAAAAAAAA AAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABEAABYkAS1EAAFJZgEAAABNxgoAAAD/////AAAAZ2Qu e5YAbQAAa2TIBwAAFiQBFyQBSWYBAAAAApY8AAXWGAYSEAAGEhAABhIQAAYS EAAAAAAAAAAAAAjWGgABtf9hLYAGrC0GEhAABhIQAAYSEAAGEhAAE9YwAAAA /wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAAAAD/AAAAAAAAAP8AAAAA FPYDrC0X9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zPW BgABDwMAADTWBgABDwM8AGH2AwAAYtYEGhoaGnDWCgAAAP8AAAD/AAAAAu0Q AADuEAAAEBMAADkTAAAnFAAA0hUAANMVAADUFQAATBYAAJYWAADXFgAA/BYA AP0WAACSAAAAAAAAAAAAAAAAigAAAAAAAAAAAAAAAIUAAAAAAAAAAAAAAACF AAAAAAAAAAAAAAAAhQAAAAAAAAAAAAAAAIUAAAAAAAAAAAAAAACDAAAAAAAA AAAAAAAAewAAAAAAAAAAAAAAAHYAAAAAAAAAAAAAAABuAAAAAAAAAAAAAAAA bgAAAAAAAAAAAAAAAIUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAyQB YSQBZ2RZQ+UAAAQFAGdkWUPlAAAHBQADJABhJABnZLdkqgAAAQAAAAQAAGdk 7WGYAAAHAAADJAFhJAFnZBJLogBtAABrZG4IAAAWJAEXJAFJZgEAAAACljwA BdYYBhIQAAYSEAAGEhAABhIQAAAAAAAAAAAACNYaAAG1/2EtgAasLQYSEAAG EhAABhIQAAYSEAAT1jAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAAAAD/BhoA AAAAAP8AAAAAAAAA/wAAAAAU9gOsLRf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA /xzWBAAAAP8d1gQAAAD/M9YGAAEPAwAANNYGAAEPAzwAYfYDAABi1gQaGhoa cNYKAAAA/wAAAP8AAAAMMREAADIRAABfEQAAYBEAAGwRAABtEQAAcBEAAHER AACsEQAArREAALERAACyEQAAtREAALYRAADxEQAA8hEAAPoRAAD7EQAA/hEA AP8RAAA8EgAAPRIAAEwSAABNEgAAUBIAAFESAACaEgAAmxIAAKASAAChEgAA pBIAAKUSAAD0EgAA9RIAAP8SAAAAEwAADxMAABATAAA5EwAAQhMAAEMTAAB2 EwAAeBMAAHsTAADo1ejV6NXo1ejV6NXo1ejV6NXo1ejV6NXo1ejV6NXo1ejV 6NXAs5l6mXqZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwDagAAAAAVaKtu bgAWaO1hmAAwShAANQiBQioDQ0oWAE9KAgBRSgIAVQgBXAiBXkoCAGFKFgBw aAD//wAAMxVoq25uABZo7WGYADBKEAA1CIFCKgNDShYAT0oCAFFKAgBcCIFe SgIAYUoWAHBoAP//ABgVaMw0fAAWaO1hmAA1CIFCKgdwaP+ZAAAAKBVoPT+X ABZoEkuiADUIgUIqBkNKFABPSgMAUUoDAGFKFABwaP8AAAAAJRVoPT+XABZo EkuiAEIqBkNKEABPSgYAUUoGAGFKEABwaP8AAAAuA2oAAAAAFWg9P5cAFmgS S6IAQioGQ0oQAE9KBgBRSgYAVQgBYUoQAHBo/wAAACt7EwAAkBMAACcUAAA1 FAAAWxQAAFwUAABeFAAAXxQAAJsUAACcFAAApRQAAKYUAACnFAAAqBQAAOQU AADlFAAA5hQAADUVAAA2FQAANxUAADgVAAA5FQAAOhUAADsVAAB3FQAAeBUA AHkVAADIFQAAyRUAAOjdybKnn5Ofk3mTn5Ofk2hcaEtok5+Tn5NoXGgAAAAA AAAgA2oUCQAAFmjtYZgAQioCVQgBbUgJAHBoAAD/AHNICQAAFxZo7WGYAEIq Am1ICQBwaAAA/wBzSAkAIANqAAAAABZo7WGYAEIqAlUIAW1ICQBwaAAA/wBz SAkAADIWaO1hmAAwShEANQiBQioIXAiBZkhAAW1ICQBwaP///wBxygoAAAD/ ADNmAAAAc0gJAAAXA2oAAAAAFmjtYZgAVQgBbUgJAHNICQAOFmjtYZgAbUgJ AHNICQAAFBVoVXMgABZo7WGYAG1ICQBzSAkAACwVaCJSVgAWaO1hmAAwSg8A PioBQioCQ0oSAE9KBgBRSgYAYUoSAHBoAAD/AAAmFWgiUlYAFmjtYZgAMEoQ ADUIgUNKEgBPSgYAUUoGAFwIgWFKEgAAFBVoq25uABZo7WGYAENKFgBhShYA AC0VaKtubgAWaO1hmAAwSg8AQioDQ0oWAE9KAgBRSgIAXkoCAGFKFgBwaAD/ /wAAHMkVAADKFQAAyxUAAMwVAADNFQAA0RUAANIVAADTFQAA1BUAAOQVAAD8 FQAAMxYAAEsWAABMFgAATxYAAFAWAABXFgAA797SyruooZ2OgnZqW0iONQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAlFWgiUlYAFmjtYZgAQioIQ0oSAE9KAwBR SgMAYUoSAHBo////ACUVaO1hmAAWaO1hmABCKghDShIAT0oDAFFKAwBhShIA cGj///8AHBVoWUPlABZot2SqAENKMABPSgMAUUoDAGFKMAAAFhZo83QnAENK MABPSgMAUUoDAGFKMAAAFhZoLnuWAENKEgBPSgMAUUoDAGFKEgAAFhZot2Sq AENKEgBPSgMAUUoDAGFKEgAAHBVoIlJWABZo7WGYAENKEgBPSgMAUUoDAGFK EgAABhZo7WGYAAAMFWiEGrkAFmjtYZgAACUVaCJSVgAWaO1hmABCKgNDShIA YUoSAG1ICQBwaDPMzABzSAkAHRVoPyLRABZo7WGYAEIqA21ICQBwaDPMzABz SAkADhZo7WGYAG1ICQBzSAkAABcDagAAAAAWaO1hmABVCAFtSAkAc0gJACAD agAAAAAWaO1hmABCKgJVCAFtSAkAcGgAAP8Ac0gJAAAgA2roDAAAFmjtYZgA QioCVQgBbUgJAHBoAAD/AHNICQAQVxYAAFgWAABnFgAAcBYAAHEWAACVFgAA lhYAANcWAADYFgAA/BYAAP0WAAD+FgAA/xYAAAAXAADv38zfuaqVgJV5dXFc AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgVaD0/lwAWaBJLogA1CIFCKgZD ShQAT0oDAFFKAwBhShQAcGj/AAAAAAYWaCEeggAABhZo7WGYAAAMFWicYyEA FmjtYZgAACgVaCJSVgAWaD0/lwA1CIFCKghDShIAT0oDAFFKAwBhShIAcGj/ //8AACgVaCJSVgAWaO1hmAA1CIFCKghDShIAT0oDAFFKAwBhShIAcGj///8A ABwVaLdkqgAWaO1hmABDShIAT0oDAFFKAwBhShIAACUVaCJSVgAWaO1hmABC KghDShIAT0oDAFFKAwBhShIAcGj///8AJRVoIlJWABZo83QnAEIqCENKEgBP SgMAUUoDAGFKEgBwaP///wAfFmjzdCcAQioIQ0oSAE9KAwBRSgMAYUoSAHBo ////AB8WaO1hmABCKghDShIAT0oDAFFKAwBhShIAcGj///8AAA39FgAA/hYA AP8WAAAAFwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAMkAWEkAWdk EkuiAAABAAAAAzIAMZBoATpw8QeWAB+w0C8gsOA9IbC0ACKwOAQjkKAFJJCg BSWwAAAXsNACGLDQAgyQ0AIAbh7wIg4AACGiw/x0Eft+XFwAGpvN0Qj/iVBO Rw0KGgoAAAANSUhEUgAAAHAAAABFCAMAAACliZJnAAAAAXNSR0IArs4c6QAA AwBQTFRFr+ou0tfavr28WkwBrKyt7fX5Z4C+0vhz/+sz0dns3uz2zAMDZ4ZV EBAL1OfJm5Y4RpMq72lpy+azKHJ5/+IAMjIx/pcAQEA/V1ZV1Sco+jQC//Fv ZrUizO+IngkA/6Fw/9wAhrfKER1mwszm/CMgr5gBEG6M/+1M8vLy/0oD+khI fW4DIiIh/7+/tJIpn5+f/9VEVaUgsNeQ+fzM/8gAn8XSsr/eKXcptNCzgICA /9m/zdDOj4+Pn4MC/6MBz7UCw8XE//HfBVYkeGhRhIR77+jfnsfq//KfaGmH dsEji7zm+9/fNFd4msSL95+fmdsp5AAA/AAA55+f//e5/8AAjZCwcnJy//OI QjMCkbqQaJBqMzx2/9MA8/vk/LZ8g8sk///6/2YAueZw5vm9fX19bW5reaeC /vzg/ocAlsh0/oCA/+gdvOGW/XkAazEA/+OflJSUz5EAgVAAOoogYqFSpt1W 64CA/+iv/9pyZ3Gk//vuYGBg/9Gk/9XP79IA4PLIn76x38UA4ePt37kAhpTE //WuGmshEicKJRwA4eHh/a+v/M/P3/qa7HUE/O/v/+cJp9d1w/Y5/Q8M/5oQ /90g/x0A/+O/4uzj/+qAgaqQjtMm+/7y//bvZAIA/4+PMCoAQBsAhZnMR2az f7XjGUCfo7PZ8PL54ObyKU2mOFmsQI2rQHprdYzFv6AkV3O5lKbSMISkv9nj eXlzIHqdf41K764J7+/vr9Dcz6UbT09NcKrA36oSt9XvUH9iQH1Zx9/zYKC5 z+Pqv9rx+Pr8z+P1UJeykLSexcW/p8zsr9Hu6x8hcFNAmJiTv6MAjo6F8I+P 8ffxbaB0XIYZ8PDz/4IgbqgeozNF/8Mb2U0AzUwwz3sA/2ow4vHV/+zPa29i 3+nj2UBAwNPr0WBgcZ+CqV8AgHRQm84n6OjllNFMzjkAvO1UhoeH/9cQj4h4 WZFmNkkO3trW75UA/7M476+v39BQ8b+/gHctic0yn6x9jbqCAGePCjOZAAAA /////7MAoqKYlYSISAAAAAlwSFlzAAAOxAAADsMB2mqY3AAACqpJREFUWEfF mQl8FPUVx0OOxWUzJphsliDSNYORY3RBMCESQgwVBCwshwElEDkUBLUUFY9V EKxKFLTg0RYrOsPs7IZsNlCSyMrhfaX1U1p72kOr9qS2akurmXm0vzczeyQm lLrBvnwyM/85/t/5vf977z8zm0FfiIVEouGZ/4Zl0PHPa73caUND9wOarCqK roj06ikAtgekWDeg1qhGoorqCAcJGvtaYaCCAobUBRltCemy2BjRws7hfQdc dFb//lu2rGg3JJ9gGKlAp65HdRIdColRSOwbhcuWzsrIyNi2bWymYdT6DE9l ClFuoaDaokYVojB92CfARUt3zJqV8ecti4AxPESVhEXCZASoU1fDMpFCf+gL 4Bn/qt8xaynTYLVCttuorB072mr6JhAUAiU2lrHC4X0A/Ma0afU32zhfA1UI hlBBo+vuGdv/KkKLyuBLUMNEoUai9IHXDpk27bqr0PctH3988QS3EKvMJJpa V/cI9d+2jHxGJoXh06gahcxgHwCvHTNk2obbx86de2tVUdHKxd+pMGCeiXV1 3qmPb9vW/zcAOsOiU3eoTofjYPrA8fljhvxqxT1T58+vKlq5cuX1P74oE1lh GBO93kdoS8bvBQBB1FW5UY88uytt4JH8G/PPWDF//plnnnvuz4quv37JkiVf anfbxKmPZ/zNYCCRKMvB307ZlT7wivIbP10xH7TTTlv90Dmbty5ZMmLELy8J gChM8q6mVmwss8L1pV1saSssL88/wrjVqx8qLBxlZB0HcMTgO5m4eX3hZKzu O8sCvsC86ekCx9977/i5Fq2wcBK699YVDYaZxKwsdu2PbraAzzJwSrrA92rK q/85iXFe7yQEy2avt/D44EcfHXZnjGEscMcOCziAga+lCzxc81cPpGz0Wjwj ywt23YhHt3dUWjzhJ/X1G5LAF04E3N8ct7ZeZmiiwzXfBtAQ7vZONJNhEgML vUOfsHG/a6+vrz8jCRzQE7CtuTW3qaCzqzU1tebt7841gR+g7wVvmMMlvGEO ZZbJNlNjNP0RZSgJzOkOPJCX2x2VCm5qbU6FmsBvLTCEJ83us9azPhPNNsht ZFURCm0SiCBNraVteSeC2eDS3CST6JWaK+febfW/+RwEDMyCLxjqH5lpCFW3 XzBtyAWJKH1NSwEeyO3mxV6bBXm2TKK3a2py/mJ68ElTHmw9t9Z6t/r9D3iM tx67bogN5Dx8CTOUPVu0JXC72To7S3m1pyluBXvQ6uzcZy47CyyVuPO7at6D T3m4LN7GiZu5dU5d3WD/QJ+x9rENY2zgQQBzInFgc2lczz5Tf2fnhby6MDFi eWjldHY+TfS0eWauDYRTXzHj1MgaNWrUApMGu3vcuCK//0HhhjtOHzPGcikK 6RRMwJbCvKT7nrOAFveTBPATbu7pRJQ9Y51bYCkkGn/4Pjh0ozV0cZs4bty4 Dv/MwFOLAbTSYvquXc86dQt4IKHPVkaWQLqyuZlzEPl4Fzef2WNSLYNG8xyi asMYVbg+kQsWdEHWWv+7PgDz809HqFAOPPpixAYeSokPpCas1FzuxX4k336s 9nL76WdQoRLnHogDqdbwrJj/j0Q+xGUOLc586g4ACaHCle11Um1gCo81wM62 logdCGSHm+0cYC9MnJyXAOLJN9BOdInPnAgTNtRFxkVfufEm+jquRcwMCOqf BUIDPY+u8UeEYD0EIBywm3Em9LkEsDUJpEpBMufZCQEpCXzCNeMpAD8VGTid QyYOTMl3hOHzlvvwj7455bCC4ud5D9G+nhQSNQSMGESyNTTPm2cO6A2uYwse vKn89AiAGMIBZXoc2Jr0KWSczcC96J6H8ABCBiuIPpvFpwxhaVuKQhbndtvE W+fNM2W+7zr2PTqcTwsxhgctgbZLjyck8hC+zMDdCB4MIQc/bodj6GVzeJND eH4iSi1hRO4Ka33LvK8xTygC8Ej5Fc6SEHs0pwW8OLAtTmQVpQDu5TzEEF42 efJk5MzLvJuTMDmE7Os4yV5nZ9sb8yYyMKvKdeyD8fd+8zaVY/SgpqYAjx+3 K5vpSAB3I/9RWDp/2tHRYQ0h/MuDaA9hgTlVWf37Amsa1vgaKqkyu3L58uyG 79PotQx8q8qV/eo1P9xUgno2ZfqLUebFFeLi/U08kKiY+3gRL5qXweK7eR9E w0pbrQpk8pZLAZ/b4x4kkVTrDlwdyxToqwx8suoj1wQqf/u2kk0QyCnRFQjk SU4XBXnxJwATmO2WKqR+yyVBi/li3z0qCALdznXu/aqtxdTvGmfJbRB40Gk6 NFUh33Fb3qGUIpdSDpKbBbkp874JrK2V3JIkuYWAdNQdOyocNaoJBUCoqtr6 Lr1yZCELnKI1WrwUl8bLdHPeod6m4abc87s+3VgKB8UyfW53v6sFzxphUIVR bUwgCFxbVfTzOUSXl1xO9PqLis3rAWiCm5tbWw8l5sKmptzWvGZk5GefaYjO WzWD7l+1c9VO2vnAjFX308xVRO0AflRU9KcZNKHkUjxz5zjivN6An+27xz0s cNjsgefNHjly2PadswcO8w+c4ffPJLx234BXqV/QmyULuRgkeekDZ84etn0V gLP99/s7/D+gga7iYso2jPPx6janfaGnGy994MjtwwB6YJ3fNdPlchUfA881 o8KQfv1w0db2S+FPSsRLL0Fzkt6M52HHugf9HS5a5xpYXPzOOtc7rmN/d82p MCrpjocXX8qVB6+GqZbuo36iuA2v3kTVwym7+kg1v9fDkxd/+CaOttj591+i 9CRlptRSj+RGPtZKFR7B046PUZaFEunQ58Bad0zK9gSEmFAtrfHZ85TcTV6P iX+S4pK11Crg0qBqwS1dDaBb8Fnygl1Hr7dK8/mAAUHyHBVi1VLFICPANK1H XE+l7fMBU0aTN50OVVdkmMMhK2HekMMRmSeoPovSJFEri5i+xJc1BKlIMn+H Mr9Bhfoa6BTL5Gh8WgDQqSiqBYwojfy9DcfSVdglqbs2ZArJDt0CBmU1RCIl nkv/l3FLPZfohEAos4Hs0ZBCGiv8clofaE8IdCqqDYzga7fGX/gAjJ06oIjb sVyq6Bo5xRB8egqBCkZQ1620COOfE4Xfnk6ZS3v2thmlX6z9n4FOWXaiJKAU hXghhmS8F4Ra5CD28ZbM75ZBfEi2yjOa/CGUi5l5oShr5okhuQVvvUE5aC75 q37SuihEZqp6kES9UXHyIigizPCWhfDmLeQVvgqQYhYrfDfXG3Vz4eCU5gtl HT+G6GJIV1URjxaqHtZIUcM40gtQDWs4TzM7TyzCqpNC1j6Ve00AFT0UAoPC iqY34kIVDd2BE0W9RdNa9BbcawRni1ZdtS1VoXlE5guQQLyQGYOLYLwV1IMq Z5WtsExVWZSuR+IXyvjNB+UMNx3VOAUIinnSh7d7BGo4jmoQwh2KkNQiYksk yCbNVBjVUTucCaAWMl0qwgE6/0aga7LOz2iiBt8HcQC/xzhIaXToPPI9KcR5 jfj2nvSmuSXrKqq+OTSY47gLpDHHASYD9iL3ZF+IRojHG72UhVRchtFQFE3l ke8RSMFoFIPkVOCD5CIYVSIammX4xZEcUUw2Cv/iwSc7KWj517qQGzgx5ODj oYjiQD+RCLUoiPCegSl3cqo2v/jE/w+YJ0EvQahn0QAAAABJRU5ErkJgggBu HvA1IwAAS09aKRATLsK4vgGeVMt3T/+JUE5HDQoaCgAAAA1JSERSAAADtgAA ABkIAwAAADKGQgwAAAMAUExURex7cOVKPO+TielpXP729fCVjdRqYP3+/u2E etJqX/bAu/rl4vrh3e6Jf/OtpvbAvP749/SxqvGelelkWPCakut2avrc2eZW SORDM+6OhOI4Ku6JgOdYS/3z8vfJxORDNeI9LeliVvbFwOZUR+ptYeXl5ehk VvnZ1vCbkvnV0vKlnf3y8fKpov79/PW8tuZRROx6bupwZP308vjOyuQ4KPa+ uOVRQvCgmPS6tP/9/vz+/Pz49uVENf78/PGclOdkV/75+OTg4ONBMffTzup7 b/jS0P76+vOup+2AduE3Jv3w7vzs6+M/Me6Lgvvo5uQ+LuU4Jut2bOheUeVO P+dbTfS4sfCckvvm4+NENuA4K/CSifCbk/bNyeRHOfzu7OdVSeE3KOlmWex2 a+x2bPzq6P76+N84J/jSzdmSi/GgmPvj4OQ3J/CZj/jQzPSup+p4a+M8K+A4 JOE6LPKgmPCakeM6K/vl4/vl4vro6OM/L9NqYv349/vz8vS1r+NDNOE6J/Gi muxzaOhWR/Kkm/Kim/nX1OI4JfbCveE6KfOqpNFqX/KnoPGimPGgmfvt6vzn 5Pzm5NNpYOREM+NEM+I6KeM2Je+gmOE7Kv/+/+M4J/7//+I4KeM4KP///f7/ /v7+/v/+/uE4KOE4J+M3Kf7+/+M4Kf7//eM3KOI3KNNqYeE5J+I5J+I5KOM5 KP7+/eE4KeI4JuE5KPnTz+M4JuI3KeI5Jv/+/eA5J/jTz+E4JuE5KeM5KeA5 KeM5J9JrYf///P7//OA4J9JrYOI5KfjSz+E5JtNrX+I2KOA5KOA4KOM6J+A4 Kf7+/NJqYOA5JvnSz/nTzuA4Jv739/jTzuM5JuM2Kvz//ut8b+x8cOE3KtRr YfjSzuhgU/jRzuTf3eM2KPv49//+/P749P38/PKjm/CXjvKfmN/Gw//7/OZp W9Z8c+ZXSOZURNeGfvr08/v09OI3I+pzZ/nk4fnk4vz49fS8t/bTz/nSzv77 +9JqYffLx////tNqYOI4KOI4J////1WKgocAAAABYktHRACIBR1IAAAADGNt UFBKQ21wMDcxMgAAAANIAHO8AAAfuklEQVR4Xu18C2BU9blnYiAgEojGkDAQ 3kUQawQimr2AbK4VRlEKQVGzlIitvRgrtCpsoEqrl9rqaq+Pe3v+55x5nDlz 5pzMIzPDTN4JCYSH7wcqpda77r2V3b2r+3B323U9+f/P/r4T8qhwb1vCvbFd PmYmZ878n9//e3/fIce5ABcwcAEDf2QYyPkjW++F5V7AwAUMOOeXbf0ROxiU fY4d8NmO7LfDcsS2ZUnCh992nIAvOIRy2474Jdsno60zTpYcOXBGk3M+nwB6 BmRH8ktSWJJlG6sJYv4/AaCdjTJ8CZYwyhgYxemBfMK/y7bn8SD8PluiIf2R iN+xmx3HJzkS7oBrwEc9AXuIeyK2FJYdJ+K8FpTpNrj2i03+APy4nHq6ff9f sGuj7Ph8jl/GNHj9KUDgPJ7VnwI+/r/bQz/f5uADpHDeiOGmMsCiRYvwLvsz H9jW+e/fL/uW7fPZESnghKH2BmDM98vKvv9nxOTgLMcflJwzmpzDmQztRbJX lWEZ/espK5TtyDkM92XrQlx73s7qy7a5C+v5fTDgCu6c88iyGM6+VBzUM7VC sV4OZdbY8jinO1dlj8owgsMRaF6ff3Bln+yNMXW8HXZ8jk+WA93g3S82+X12 cZY2/XTt9z3EUl6vUtdUy1nm7qDftQIuwMgxcEFujByHIxshcH59W8dZUVh4 vLBweRPXjeTP6gkMPTRr7bp1i6FV5QDYdwBWFRZ7vS+uvQeusPPBuqr6+rU/ /GKTc91bP11Jn+2Z0NvClFpmidBFftL8F+ACBv7IMdBP2zkSIkaOJIclqKdK n+wgfEO6Eb6g7DQiwEThHPpmD+lJqbvbZ8MbhSr1y/bY8vJl5XlQpREJ/iN8 WLDhZhEVLJQ2MkwMQN79GyodNIE/i5kDjs9u/MaaJu2u2T4p4kwXXFFq68tn O3JkmB0t0fiYHiNiMVgAesqwdcPkqSKcRW4zYllSAOP6oMqh7W1ykaUTUOyI SIX3bNp0v65HTUN5fln5Yp9TicZyAMIj4uvBpiXZj7BYJVxfycbQFBKT4V/7 yRUOABcY0w2T0RyQLghuBf34hfaJiYKRgCP7CH0yjRDBalzkDaMLKWijoxQe vIUf4f3b6DkEWI0TAcopbkd7kCUb3jhN3EzNbQoNYGz8Qv76b/nodg/WhKOj rj73wHB2hBN3GL/tx1Z83S620ACIAfIoPogpaDh3yCGgFrgnS4Q899BHBBjF HwYGRjTIOXUevZnPabmDnSI4EMI/0RsdGc7VDecOO6cASAH3c8ZFKvGnEaQJ CiBql4DtRor6+qSAn9iWBgig9xDtuQEknz8c8If9wV37928Ta4vmw3uk25FA z2dFPxNccEATH2Tb0uKFfqwpGAwE/FOuCVTOu2F+Ua4qQlXz5xfNX1dRx0Ka NXefz4lQEHoA4Ple+oQNUdJTec0V4wJBuMjfKJpfVDR7/vwbbpgKei+6GYEv GwxMHEfbRNsps2fPL8LoaIdm85mIJwRPh0T9DfMBv5QhGeSw3+drHN/fggYr uuIBfBTN/uG/mk39breDPY3E+JBWUlCCBU/h8KA/0gjS7252GrESTOgnPCP4 FgkGI7ZTKdtBtAeuBtcfBIrBokMb8rlHEkS4bggghMZJUgACJxAO4AAAdjBA Nj0JCEhOyALMhSA8QuLAwDBuwsoCJ2TMGa4EqnzNWCqJFD9FATEsODpoIy4n +cN2o98OEHMH8ZKCzX5sL9DtJ9wNrs7GXBLOXXb8AIjgkfEtZINNZDUyUj6X 3qM387msdqiPz66UwjYcSbAruM7lVtuGWB4mWpvlRhxtThi04reDOGDwKSgT Eto9tAhuOlJjAN3BylBsw/jWcR4tLn7A3wyZcFHxjNuLZ2c8/OAP750IIgiD K786ecKEyXkxzhI8PcC2PFlVvP1X/osWBv2BwM0zHGdO7ouaYnBexx+ZXMo8 PMbzJn9uR0BypGf6wS8FJk0v37q+eOv24qp7iouLt2/fvlh/l+kraYa/jSwq VhcX73P1AhjGkcfeizbFeUnjiKEJwS0rZYnviSOqBhkS4hAhzBRFW9FkfXEx Rr2zU+FMVQTjRxL3VHMxb/LkGVj7MqFuxETF9xZvvbd4XzDQ7IsEgmG7x5bD pDqI65G5gh7DB2SjHxo76EzB4tYX3w8tGRhG7QGQLXgFSDwNPmwuDFwPOwc6 JCSqgnihOW0eoiEYDEMKdQMZfrBWAFzoKvN+GDpGGBq+RhxQOICzgimAPhjA 5bYIDYs4nx/2TSCCZQYCNlpRLB/7IDknyXjbvsgQcwaDjb6eQBCCk0S4RFbH iKC5Gep2VLyT0Zt5JAizg4024Z8UIOlQspHoEIZJahh1NsQ++baVZPD5IcnD IEebJPC+gmkFBTf5nigoKJg2Ddf4GA7TCjYwUb1yzLT/7Fw7aeLC1asfXA3I Lb4iOKeg4BkKCzv2jNWrJz046aNBbWuZKVEwbfOTgScx2MPfKlh1/eoNac4V zjsK1qmcX7P6c0j+ILK8Q3ZgIBwpiMdVRREvCVXpNXgoHRN6PKp+WgDGb37t OCZ+8DYSLNAkwVun5VoizqMab+eqzrmFuUOWkuYqf9tSBe4xbqTAu5iVZcGx PM0/XYPBhVqhcUiQLbRHO/Jr2gzBpBdVz2J366e3P63gdmxOtiWsk1jEhr0P FBMnfm5ZvVb7QuLaId0K7pPkZntY0gbKDyYqUDx4ulCxwR7oatK/JFjJzIcx YJMPEMEZ4dygNCUIUihhspbl4eo2CLaG20F2Na0EiCB1DJtDxrAwA5BTQwPk 0cGtULcByfXwIdJJdbviYbgRC3qAOWHLjegih6H9R0KDTiMcFzkAw2REo5xL 59Gb+VxWO6xP0AcJSxrBpQ/6AA87w0nKhpQNNkdywihIgIj2kxmMNGrg0pV3 1NRco0A1nbq8GrRs8ji3iAU4Z6dBrFl5x2KNb74o/fCCy+9YsKCm5lJMYV9V nVOTl+TVl9cscF81eN09yLYhIRRdNU7u+3xlzfg7HzDHLqiZLoSpJAWPqfGY WFxTU3PHgpqVC2ow3jC441OVe0QIzKbRorhQopqq8HlosuByaroSb8x0R82L BhgSalWIeNYk3SqYULI/0gxEpDRFpETWq/B0VBi0K1NPYTci71M0ZAxMrnLo /pDGFtQ86/c32lOwrQV3lHJh9GL7WVXjSVXl4oOamqf9cCCcZrCBfEvNSsgL l2930ZIfK5hofz5n2DE0+8IwTmG2DABE56NX9DuuA4C4QuM4sqahRMNSYAXQ D5ghB2/BnsbIdCjgocA4cqFxVP2xgdMAZSvJP6H2E/w2IhEBB4Y87B0/PHcY weNgeUPAQP3LkSCqW0hzQ9y5k2MR0NB0Y1B5o38EMX3aGcglHISrNBKAVoBc QL3NSAY5p76jN/M5LXewkx3ugZAmejoNAxfDfCo/rKqgk9MYDEhh3IYd5oeJ HHjotG6BgpnmAqkajZlcNwfYlk+d6H8aHBQKJdosJmBnfgKF++CkueAoLQbl BVeSqarF0zHvANtqyRCYSiT4mn3B4P0Ft07bQc6vqmc5UzrMWIy+8HYhDDDo YBxLEeaahUuxgvGMVzAycy0eVaOGapkqTyrMgiGuxTEht3rbQ++CxyxcM8YV sC27p99WEOM3I+BFd7m3w5s0VJNjbYzHDGGCs5moKiiYhVVzBTpfrbD4A6tX X3EFZmTeSctNJkIwts0O0dEOto2rlij3O6BnUpu3neK9kwY089V2QB5bMMV+ 4NZhRqwNtqV40BDb+uSr9v+2vxGEIUkyE6oSn42/KphlwCyYt3rSA51HlI9W 3wZ1aPc3CchLJ62eNGEY2wbDYNs7ps1VWdEcG9ayPzIHRsKkJ5FJk2ALh8MO lbQgskUKHtY6gmy23E1SJAylHXQCYfJnB4nEbowgiU91bUQ6I2VbByY6UdXI SPmceo/ezOe03MEDIG8GLis5Si7zEtvi+IeFg0F5FPXI6bEDYZwhfnYjLjBv EaPwd+MN0xojgJiO/7q9SVdI1/WDJaZOHm9yy2tyL1M3wFHM42kDlM27wItZ NaoqCbAPlF10sA+HC+mNamCnk/BLAfVQixvvXT8/zlRPXQqGcLRJ9KrerCJU dXAiLupOTpg8Ycaq9Vu3bq0mFlq+fatmeIVqKFH0rIiiMVPBh02JlxMsmcR8 ZiquJT69995758DAjIS/unXJ1OL1c9Wu3HnHhKdLNTC6YbzNo0qvO01KzZ0w ueoNL9bLLYWlzGgTV8ePr4U84VFhcmGalsXiECu6rpDm3Txhwk1u9F2a08Xr 4l1pkY7HQlY19jR5keO//lLQzBAscjc7YfIA9H8d/n0/ReD98Oqpk71nwoQq wyRjIZ14VdOi7GG0XkhNyKedBFyPHaYeUUYKSzrw9Fwcw4Q54Ev/ZcXrN4am E4r/nnxs+5tLEbSXYWpBwd/yb6CRA5/T/PvAmUQUiHEP04awt+D/UjAKYXvQ wcj0JJwJWPdujdy/MIzezCPcqM/FP9B+Cx3SZy5F/JQuB8cNOjBfwsGcsPOb 1jET39n/5sSyw3/+5uF3xkx86/+0tv7yrTffOnz4a2/ecttbre9M8HYIfheM zwG2TYFZuMdog8nKOk61trY+aL6ImCzFZctN3fMyeDSkJDUovqFIMhTlMdEu dJ0ULPNWKG117O7W1iu1ClMxQsRN0ZT+YYW3A4pvQK2zCjUklFoz983ftH77 zXki1GtMb/1OBU+F4MCKmKXoLKu/m4GWVERUVxIq71J5KvWSlvz8a4cPtx4+ /OY7v/n2/rdaD/9yjbZ56v0IGRdVWSpi1ozU7ctqGoZByvB4oVMtzjXthRuw g1ngXoVvLkIQuqioCOFlgtkKA1frhmEkWcI7Yw+CPd88fKVoZ9+LwuRWVFUX 0TrGHz38bATW6bDDm7LBtCDLlAGgqWC7DwIXeftb99Ma9+9v/fPWKc9SYB0T LgNuH9FfumsjfbmcjFpIUde2Ha68oTGB/f1fO4l02xu5zRRUcIJPQ67CYJmw H8O+84ONX1vYjAg08fB3xhMfnpy/2eCL32x9E7/vX/RbWR5EIZGcCi9sfeud 1tb73VTeCAA6Hsm2m2l7/bBrBIP9QV1Hb+Y/aJlnNEau0Ad3def+1o+UaEiZ 0bofp/sAPLwfD6Bw/1v7f9P6zuFv5+zcpYg5eczSi29PMM/XlSfnQZPFVGjX ipeT7LK7U1HeVqGDamF6noZOZoZa0k1MZ2+0IEEb0nQu6nfu3LUK67h+WfVB JcPquKolQaKD9m7oYMLL3oDh2ea1YMPC0WVvk7PK1LqM6NwL7YIped19ryhe 1y11QWFM46ZiRRl4klHYl0crcDdpatB+XtOjZF6idqEo4016CxMVYC5010Xi vVBLqo5jBQp2wprivHjnrk07I7fNKy9fXpqb0TtY1xELDJXUvII1CT132bI7 q8ZLv9q5c3NdiIum4p2bdl5yyc5LNu3ceTPsjjFITs+CHQ3UtDNFnxix5dXL yiljXV5eD4cAWhmhrXZd+8GiJd8Ydhyy9E1qtaxqcEv6XRxIOb1F7J/Hu7wJ dIURo/PobDdwD1v2Iy5aOGvS52waQ94sQs3EsJTgGq4CZWfFsvIdkFtk3Gze iTPA++H25EsZ1gl8M6Gl+femUxaQPCaEJysjP921qZhrooIQl2CP7lo0pLwR twxQjnBj+bpebuY8eza2XQSE/NXOTcNC4b9NfN/EAgbgW/bNuy6ZNJS6Pzn4 y5KRkfdZe4/ezP/4Zj776e/aaOFOhFQH4CaQHKh0zYcCNEY8x6EeLaHzzKDK FCxRpyh6DggbDDF0+9yuFMWrs88LCwv3HP8OAxV+KaFJH5P7yxX25XdfW1+1 tsoz5EMLZe+MFZ+tXLNnz/8COuroByYSXkWpC82qr7/bjowrPH68cD7s/9iR F9d6K9ZO7L6p8DOKJaMw0/l07Q6WSHYqwltnZa0FT68v3CP5Ik6z66OgHgOl FPKa+vodkFX3iY5fiCbX4M50tiU8HlXXK7q8nfdlTPZSEtGD2YUI7CPwG356 7Szepitir7h0BeWdkIFDENsvNXdT7MonnxjX7CZc4QxtQIHZLB6qaxoSksPQ z8r3RFC3drzwJjyw8ZrjVNf/+AgEsyfKRIfXk1CvgwRCDsHxUWULglGVOMLj /5Dm2eTiwkLJV7iHqt4Kb+qvX3GCD2Oy+vqqwm7b/gwt6cTRAH/3FP59oeSs 2jhklCl/O2Y8bfVMWmBPuLV0Z8svrfgP7oQogQH2YN8jPw73GLE0p9KHhR0/ /hmlptwyWPLfIFEd5/jozUz7dgF/kBEHSaD0JyDT9o4f31N4xfOFe1BkBD9m mAlGlTFUzwtkryicY20u/N9oveezoO+rU4j61CE5d1YuUmCrqeeHbaFWjc4E GbeYCZLiS8m13KPrLDqHvESoH3/9d8kTHgB29dSWtgqFvQIH+NWkLvZGvR2/ aDIUxIURgp1Y2wThFtubtvTZP000LZJ8J62xp0s1fT7/RYJ1pY69orNEwlQT IrGFHnwK9zRDT0pUqOHrRu7l0Rjce6XN/BBGD6zmhP6IDoyJVEKvAwOxY2Y6 LUJvVyPCj/KIYKU0472EN5Hwvqz8ZSOVrZEODvpPIAuL678jpYxQcfO4MIJL PT7piVeYF0aGcYb85dnOemmmbommU0EUh0jyiRPzhMi82wU//n+8oljqQ8SO lU5lN7nkoKidtS1/nTFh+XeIaLVP3hyrqBDcmBdG9l/u6Q5WVkpyJYw5rKig 7t02FLF6Wva2PdIhdDVafcLZjJzeIErh4xDbnkWK11rMOph7Nk10rfAyvaXt O07ja4hr9xeIQYrR2noU0ZJUf4CVQFi5RULgXPC3VDp6MydEexzlCSD8Ju8U qk+DIEFcKdcDg61JNY4xvW4XCCQc9ncTTcAGpk3DpHEr+uQr3/06rDTF+5Jg D9ny0gHqg4D/x+H8sS3Xs2/A5RNp2K6iNqGwLyffevfqtYmq0tLS5+8sLV1e p2uDmkGv7aqHT9umiGOdiUyXR1H1vLIlZUuWlK2fWTpzjbPi37b8qKXzSLxX +XTMV8uWBGffeXvZKhQyAPsBiNhVeMpoyU6v0hRtg62vm6Fq5wQKIZH/kII9 PnlZaenMmS/Us6SudzJhGlkLYTgm6sDmV9EDSldULSn7b2Vl4y3EAiqwvDvv fAyfVaLllZZfgObrHytdPnOZT964DwVZbqElcrSLlz+PNjOXP/YC2t75wjpu maJTPxPv0RZWUZrIVOjWuuUz8ypXoNOOBEMEP6aLiu8uLVuySprwQ0SYx0mR 7teC0pOlVR2QLu3gVFPEvzdzea+o9Xh46mf3yODWyiAUvz8ilz3/wgszH5uV 1I3O2pb3FL2ujqWQNjBmLv8xUg6D/kB7yIv0gPdM7WGaKdgWBrByBqzVM8cS ulL1JJ76DFJ9qSQ39lf4ST7C1ZJVzU6wR3LrcAF4Xlt+bcnozfzJnK1q1qO8 LYD8KtrMndtRzerPhf0aQ4gho3TeVfrYzMeeXz6zdGO/lLqIGk13fCeKZpaW ruOv6qLN2/Hee8lZdOJEfQkP3K1/GbblCBkjWyO8VjqmQo7DU/sSAtNrVaSI TK+Xt5velwcruOBZRmNI88BDRYqKCb0jzllVSUnJ489ur7qsQK0qmbvF9Ogq MysqinEoAWfTxCWBwLVo8fHcm5H4fKLkbse5WfdykdFQnsX0R+Zu2bIP2cOr p+GgfC/wJDx0noELrke9qmgSXhFPNyH4beZu2VJSUt77+OMlJTNuDZl5Ewk+ 4Vlz/L+7x72eOHH719fg8365e9cqqndEqaIs+7pvo59WR72sSZnT3+5Jrx47 cgbWQy1wnykAkcwKZV1JSSbNwIZNMY3pnce69vkQl1xyW4RUuA+pn+CY67+7 98NEIhrSklmPkWjxUgYBeTprx5a5JSVYK96Pb5mLeD38ZsrVeVpYImoka7WD 4j0v1CE8gIE1NLWEhFUbOouV7A0hopjKtLxy5nLTHaxCwOG4FvYm1XIivYyS AqSuSD+RtYDavxM2ngF1y3avL3l8LtY1ejPvqC5FZEVkFT2jxKgML161ZcvH 03eISycWHBPRBMImmQzPGogm7Cj5GFCyXKRiiDds+XhWO4Kv0ZcgvTuiLW8A lxXg9dPU90+yLes3kmG6jdC35Uqqo67W0DQt6eFRC2f3JWRaLMmT4irCWpzF hZXoHG4jI5AM9IeY6cmIhNUmksms11vnuaGUX7ppqsfwtEMPmlosFt+cNwgl rFd7VS/C92o9Ny/vHvB7UjUQEveyg4g5bcAPJZvz/iEvbweC50goC+0+UceR 4YLlaFppvdYTwwMXQtMNzjwxMT13zdIpjX4Y1QuXLl16yS1TQKaI/EgTl/5P UK5bb+2WXdMDyvbfQVgEIjej4dKlxylLGfCNmVzHUQP2RTD1DhS1GCxkwmfn CNsJONZIrHMTc9Ma8xYgDdTj66H/q0CSyq73trvkkF28dOm18S5h6qhG+UXy R5mWI17xl0uXTk2AjTFKRqQRQOd8lruG7darAiUtdfHMMCOZZzny3Nnk2Ygh rlkdibbBlMHgRZumKxnPQXGtm6ukUBryUIhvS/cP4n0lHpk4AUMzeGXe3INI wteaozezxRGOJUuHeTs0eBbIh8SiXWaX2JhXjXraaNXSWXUZ1TQRWhIeWE4J hcdigseRwqQIq4FUKWoB6kB+qEkQA9T3T7IPvLXzxLYixjpQwmAp7RqyG1z7 8e/wqkeLqdu74sy0UPYVQ0YZxV+D6/BaumXxWLSXvdql4yRcLJoaJZA/+PkG 6Jtk6varr56t8FAsFdKb3EIrSgCLrJE+0gQ+VDvgtaLYSgMpMwsBYh14QD+R OmIce5mpoTZhmEZnG9VxgdjJhjJFe1uMqr8MRLp1dtlsMf3nPz95Y87JnJwp qE8Ex1J9dmMzMgIoLwe34gOhGSieRqRrm5++8cacH+AZBHl8Tg71yclZ/2Hi LM5JyU/2ikevns4hkniKa6aJKhPTVJRYKO1hISvZy6pzbsy5Bv1vpEFyPjVf il31cXT89Qt77MKr++HXVz/AQwnQZ15OzoY06s+7FMurqtfQb9fC9bzj5ONM 8XCrKwQ+HjpcI0vZh+F3Tv+GOjcD9yHdzgJWrCsuvEVYykcU5Mb2fo7XycVu tFxFHXs1LRMLvvETlMTFhKFoozczi8KiVZDBrEOxjlWbVWHatDAjlQWyYnGD 78hBSa4GBkbUATFQRhoSJXqm0qGpiTYtzo3elnSSq6ZlGMiquNQHcvpd2pbn YJ7MiJVjJmO0VMBkIpoEeXxJY1IaZ5ddRTCe5z5hxhaUD2InlbW0rKl2xNWk p6ONnl5izFTv84oUoVDTUt7eaVOnfqIoWjSlxRkyPtDaeDOVqsLcoks1pXVR R4xpwSQ2KEelGlpbylQPIuUDJ48nDcHrQmLNVes/uBVlHCyUEpgHBWKa6hHX fMIqDI8rS06NnQqYhAcMUKboPmeAp3bw3NCVU+w5V8uX0I9YDCZaRhfrTJPF oFAhz+MQ/V8AXr3mSEfB1GrY7vMLoiwbYpYJKU/FM1CFF+GJSRUGHOWkqDYb oSuWibM11Z68/lmg07AAf+NtP7nqJx1WVgPrIKAGo0Jovcp8anE37Pa8ZDpG oki9zxiqlcFw8WgsfjbaQorc4G0Im56VPKGDmBVCRU05jf80zisPdTY860U2 0KAgl2C1HvAH5csFSk7TR0Zv5ndjWANWRJUAOGAIbTzUxow3UEuEKyQGBUu6 5GGksVuY03TNtVAtnmChK5xESAllUUIMNcwGqe/3YFsF9s5IAUQI7xbEDiMR 8SgrO9IB/1n6a2po7La/uW7btpPG5svNpouqh2bhhF0UUDJDiaeohhIXvA3G jwLDE+XXY0+dOoUqLQ4nHs8qcUSeCOuwfd5OGYZiIQOsVqT7zUfUcgmkoBlc Z2Jb/ERJZjpO1Igl6w6Ka7Z9umE8CV3oDjo6HCO5NXg8Cc838LYQn1oe4mpi 7rZntm37j/Sxbdt11z1z3UPPVK95Zt7sbQVUYA0GQykVaEMXKY1EAj1vEW8y zsBbyalTF6GqjKES9YM1GsveR89cUQeF6jZvLRGwkWpV2BUQQrifEgaLsxCe xNB4Byjpb7Y9RPMDntmWqK0NgcupiAYQjxJHZq0d27Y99MD0EHLdeHjjYAVV sJ4GtEmfNSclDBEyjFDcOnO5omTsqbvVJIMGhbsRQ2HMw5j7HgvRAQoIQGDg EGIKymBV2Pq10LMGLJbRm5nkNYxe4RG8VoXdS1QhVEaCkARYHGcMoU3MnMYP Gn3gFQ2hulDg8RaiiqyZGlCwg9T3u9k2f/eBi/tGCg0H8t/v62tocN8NR0c6 3D9T//z8Q7sPHerL7+vLz8cqG3BxGhoO4fpoHzaBHwj6+g4caMjPz2/oO0TY +S9fAfzXvqPYWUNf/oGGp/Lzjx7qe/05tLu4f7sYDf92o39+3wF3ikP9Y+c3 XIwx+y/z0RXz5x/tO5pPU+5+ve8QZsGLevS9/jr+HKJ5XTRSr+fyG95//30M uftiNPu/uIPmWDiaPPdcwwF3J0/1z7Q7n2b/IvzFV77yr/v6nsJyD2FMzEof B97vO4rGrx+gddEuD2HjtA28d+cfQFMaKP/9hov7GnCu7qgNR/MPPIU/uItF NuzOP3qUdoke+fn/6S/6d/oUrXQIqbuxWbp/tuPEpAfcKb8AWO+/P3ogv3+U o3QOtKg+YAtf3j99H5Njsw35F78OnB99bvfozUyHRCeymw493yWQfCABOCWC Ooozzj/0Pu64+HQZxMW4SxB4Hz36+qHdR4kg3EN3m2C0M7AyDFF0RLsb/h+m xAtpcoMO8QAAAABJRU5ErkJgggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApAAWJAEXJAFJZgEAAAAB lvH/IXYAAWgBNdYFAAEDrC0jdgABrC06VgsAApY8ABPWMAAAAP8GGgAAAAAA /wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wAAAAAAAAD/AAAAABT2A6wtGPYD AAAs1gMAAQE11gUAAQOsLS/WCwABDwAAAP8GGgAAM9YGAAEPAwAANNYGAAEP AzwAcNYKAAAA/wAAAP8AAKQAFiQBFyQBSWYBAAAAAZbx/yF2AAFoATXWBQAB A6wtI3YAAawtOlYLAAKWPAAT1jAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAA AAD/BhoAAAAAAP8AAAAAAAAA/wAAAAAU9gOsLRj2AwAALNYDAAEBNdYFAAED rC0v1gsAAQ8AAAD/BhoAADPWBgABDwMAADTWBgABDwM8AHDWCgAAAP8AAAD/ AACkABYkARckAUlmAQAAAAGW8f8hdgABaAE11gUAAQOsLSN2AAGsLTpWCwAC ljwAE9YwAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAAAAD/AAAA AAAAAP8AAAAAFPYDrC0Y9gMAACzWAwABATXWBQABA6wtL9YLAAEPAAAA/wYa AAAz1gYAAQ8DAAA01gYAAQ8DPABw1goAAAD/AAAA/wAApAAWJAEXJAFJZgEA AAABlvH/IXYAAWgBNdYFAAEDrC0jdgABrC06VgsAApY8ABPWMAAAAP8GGgAA AAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wAAAAAAAAD/AAAAABT2A6wt GPYDAAAs1gMAAQE11gUAAQOsLS/WCwABDwAAAP8GGgAAM9YGAAEPAwAANNYG AAEPAzwAcNYKAAAA/wAAAP8AAKQAFiQBFyQBSWYBAAAAAZbx/yF2AAFoATXW BQABA6wtI3YAAawtOlYLAAKWPAAT1jAAAAD/BhoAAAAAAP8GGgAAAAAA/wYa AAAAAAD/BhoAAAAAAP8AAAAAAAAA/wAAAAAU9gOsLRj2AwAALNYDAAEBNdYF AAEDrC0v1gsAAQ8AAAD/BhoAADPWBgABDwMAADTWBgABDwM8AHDWCgAAAP8A AAD/AACkABYkARckAUlmAQAAAAGW8f8hdgABaAE11gUAAQOsLSN2AAGsLTpW CwACljwAE9YwAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAAAAD/ AAAAAAAAAP8AAAAAFPYDrC0Y9gMAACzWAwABATXWBQABA6wtL9YLAAEPAAAA /wYaAAAz1gYAAQ8DAAA01gYAAQ8DPABw1goAAAD/AAAA/wAApAAWJAEXJAFJ ZgEAAAABlvH/IXYAAWgBNdYFAAEDrC0jdgABrC06VgsAApY8ABPWMAAAAP8G GgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wAAAAAAAAD/AAAAABT2 A6wtGPYDAAAs1gMAAQE11gUAAQOsLS/WCwABDwAAAP8GGgAAM9YGAAEPAwAA NNYGAAEPAzwAcNYKAAAA/wAAAP8AAKQAFiQBFyQBSWYBAAAAAZbx/yF2AAFo ATXWBQABA6wtI3YAAawtOlYLAAKWPAAT1jAAAAD/BhoAAAAAAP8GGgAAAAAA /wYaAAAAAAD/BhoAAAAAAP8AAAAAAAAA/wAAAAAU9gOsLRj2AwAALNYDAAEB NdYFAAEDrC0v1gsAAQ8AAAD/BhoAADPWBgABDwMAADTWBgABDwM8AHDWCgAA AP8AAAD/AACkABYkARckAUlmAQAAAAGW8f8hdgABaAE11gUAAQOsLSN2AAGs LTpWCwACljwAE9YwAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wYaAAAA AAD/AAAAAAAAAP8AAAAAFPYDrC0Y9gMAACzWAwABATXWBQABA6wtL9YLAAEP AAAA/wYaAAAz1gYAAQ8DAAA01gYAAQ8DPABw1goAAAD/AAAA/wAApAAWJAEX JAFJZgEAAAABlvH/IXYAAWgBNdYFAAEDrC0jdgABrC06VgsAApY8ABPWMAAA AP8GGgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wAAAAAAAAD/AAAA ABT2A6wtGPYDAAAs1gMAAQE11gUAAQOsLS/WCwABDwAAAP8GGgAAM9YGAAEP AwAANNYGAAEPAzwAcNYKAAAA/wAAAP8AAKQAFiQBFyQBSWYBAAAAAZbx/yF2 AAFoATXWBQABA6wtI3YAAawtOlYLAAKWPAAT1jAAAAD/BhoAAAAAAP8GGgAA AAAA/wYaAAAAAAD/BhoAAAAAAP8AAAAAAAAA/wAAAAAU9gOsLRj2AwAALNYD AAEBNdYFAAEDrC0v1gsAAQ8AAAD/BhoAADPWBgABDwMAADTWBgABDwM8AHDW CgAAAP8AAAD/AACkABYkARckAUlmAQAAAAGW8f8hdgABaAE11gUAAQOsLSN2 AAGsLTpWCwACljwAE9YwAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wYa AAAAAAD/AAAAAAAAAP8AAAAAFPYDrC0Y9gMAACzWAwABATXWBQABA6wtL9YL AAEPAAAA/wYaAAAz1gYAAQ8DAAA01gYAAQ8DPABw1goAAAD/AAAA/wAApAAW JAEXJAFJZgEAAAABlvH/IXYAAWgBNdYFAAEDrC0jdgABrC06VgsAApY8ABPW MAAAAP8GGgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8GGgAAAAAA/wAAAAAAAAD/ AAAAABT2A6wtGPYDAAAs1gMAAQE11gUAAQOsLS/WCwABDwAAAP8GGgAAM9YG AAEPAwAANNYGAAEPAzwAcNYKAAAA/wAAAP8AAKQAFiQBFyQBSWYBAAAAAZbx /yF2AAFoATXWBQABA6wtI3YAAawtOlYLAAKWPAAT1jAAAAD/BhoAAAAAAP8G GgAAAAAA/wYaAAAAAAD/BhoAAAAAAP8AAAAAAAAA/wAAAAAU9gOsLRj2AwAA LNYDAAEBNdYFAAEDrC0v1gsAAQ8AAAD/BhoAADPWBgABDwMAADTWBgABDwM8 AHDWCgAAAP8AAAD/AADUAwAARABkAAAAAAAAAAgAAAAAAAAAAAAAAAAA4BDg EH0AMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBSAAAA sgQK8AgAAAABBAAAAAoAAGMAC/AuAAAABEEBAAAABcEIAAAABgECAAAA/wEA AAgAgcMCAAAAvwMIAAgAcgBzAHMAAAAAAAAAEPAEAAAAAAAAwGIAB/AuAwAA BgbYvNOsDR++Vq5Ezp05/evQ/wAKAwAAAQAAAFgJAAAAAEsNAG4e8AIDAADY vNOsDR++Vq5Ezp05/evQ/4lQTkcNChoKAAAADUlIRFIAAAAkAAAADggDAAAA cOlO+gAAAANzQklUCAgI2+FP4AAAAR1QTFRF////7fH13ej43OTvzN33y9rw zNfou9L2u9DwuszmusrgusneqsbwqsLoqb/fmbzwZsz/mbDTiLHviK3lh6fV d6n0d6jxd6Plh6DFd6HgdqDeh5y7dp3WZpzud5jJZpjjZpbfd5G5d5G6M5n/ VYzfVYjUZYWzRIfsVYXNZoGqRIXmVYLHVX++RILfVHy3M4D0RH3SM37uVXis VHSkM3feInf2InXxM3LSM23FRGmhIm3dM2i4M2azEWjrImPGM2GmAGb/n0ED AGP3M1qUEV/UAGDvEVzNAF7sAFzmEVnGAFneIlOcAFfZEVGyAFTTAFPPAFDH AE7EEUibAEu7AEi1EUONAEWsAEOoAD6cAD2ZADuTPxoBAADMIQ4BAACZiKF0 +gAAAAlwSFlzAAALEgAACxIB0t1+/AAAACF0RVh0U29mdHdhcmUATWFjcm9t ZWRpYSBGaXJld29ya3MgMi4w7qtbxwAAABZ0RVh0Q3JlYXRpb24gVGltZQAx MC8yOC8wMRoErOcAAAEcSURBVHichZFbU8IwEIW3FNSg9a5oREXxrvWKtt5j MDbGkja04t3//zNs2mGg4wPnZc9svsme2YXJ+kD9Qp1oUS2SWcZYaruVfGfQ UcNxnCfJKaF7GO/cSUZvV3HVDTntQZCq3BEXhdRdy+m0osjrh3ZvNg3YUgVY ew9ty90A8zV+rFkqBzUjPgLrEcBSO/QFnwfzMpZCeDT/EwZoy+FkhjnVkid6 2OiB+pfJaMYenTC0a8vtkm4txPlMKwBnCcTFVc1I5gohbAvgU+QzjYHxEhZd 5fslOK1iFQgbzI8cdB+wIpidJBEyYeitkiykDHCoWA+aW3zm5LyCjxszCI3v K8GWLYRmWwHr2zjJLsC0OOf6SVeve5aHr4H6+QPwWWHFLP8VggAAAABJRU5E rkJggr4CAABEAGQAAAAAAAAACAAAAAAAAAAAAAAAAADgEOAQfQAxAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FIAAACyBArwCAAAAAIE AAAACgAAYwAL8C4AAAAEQQIAAAAFwQgAAAAGAQIAAAD/AQAACACBwwIAAAC/ AwgACAB4AG0AbAAAAAAAAAAQ8AQAAAABAADAYgAH8BgCAAAGBgt5sxQNxBU9 le2bSw7n8BL/APQBAAABAAAALA0AAAAASw0Abh7w7AEAAAt5sxQNxBU9le2b Sw7n8BL/iVBORw0KGgoAAAANSUhEUgAAACQAAAAOCAMAAABw6U76AAAAwFBM VEXVWATx1MDhXQT/9vD/chXgp4L36eDlXgT0ZAXtybHwYwX69O/fnnL/q3P3 4NDQcjPnvaH/49GfQQP/5tXlhEP/hTT/2sHOVQTNZyP/7eHns5Hoq4LUYRTw bBTkdy7dbiTwwaH418H/fCTmezPzwqH6llPwroIhDgH5soL/0bL/j0T/tIJ9 MwL/mlfCUAQ/GgH/yKT/////ZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADlq9b1AAAAAWJLR0QAiAUdSAAAAAxjbVBQSkNtcDA3 MTIAAAADSABzvAAAALFJREFUKFOV0NcOwyAMBdAk0OzVvfcOrZvr//+4QpSo L6nSXgkJoyNssIZlZzbWkzvz+AMlEJIL9KUCxswloKtJ06K5aY9AzpFNNcp9 CYAK2FatGnSIkCImXyHCVol2xGfAJo8VcgTi9AUVgLtijXo7YNaOpBApFhU6 IqB2dEecASODHJ+sCrlLpQozez14Yga6wV0bpI8rZHIJP4g90u91iPQyiPUu JBNT/fjjg1dnrm+whVOZpJ+SKQAAAABJRU5ErkJgggAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCEwASAAEAnAAPAAQA AAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAEDx/wIAQAAMBAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAY AENKGABfSAEEYUoYAG1ICQRzSAkEdEgJBAAAAAAAAAAASAAFQAEAAgBIAAwQ AADtYZgAAAAJAEgAZQBhAGQAaQBuAGcAIAA1AAAADgAFAAMkAQYkAUAmBGEk AQ4ANQiBT0oIAFFKCABcCIEAAAAAAAAAAEQAQUDy/6EARAAMBQAAAAAAAAAA FgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0 AAAAAABSAGlA8/+zAFIADAUAAAAAAAAAAAwAVABhAGIAbABlACAATgBvAHIA bQBhAGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAACAAsAAAAo AGtA9P/BACgAAAUAAAAAAAAAAAcATgBvACAATABpAHMAdAAAAAIAAAAAAAAA KgBXQKIA8QAqAAwAAADtYZgAAAAGAFMAdAByAG8AbgBnAAAABgA1CIFcCIEs AP5PogABASwADAAAAO1hmAAAAAoAeQBzAGgAbwByAHQAYwB1AHQAcwAAAAAA NABVQKIAEQE0AAwAAADtYZgAAAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAACQA+ KgFwaAAA/wAAcAD+T6IAIQFwAAwAAADxB5YAAAAfAG0AcwAtAHIAdABlAGMA dQBzAHQAbwBtAC0AYwBvAG4AdABlAG4AdABoAGUAYQBkAGUAcgBzAHUAYgAy ADEAAAAaADUIgDYIgUNKFQBcCIBdCIFhShUAcGgnJycAAAAAAMQCAADuAwAA AA8AAAEAAAAAAAAAAAD/////AgQAAAAAAAABAAAAAAAAAAAA/////wMEAAAA AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAADEAgAA7gMAAPEDAAAAAAAA ABABAAAAABD//wAAAAAAAAAAAA8AAAYAAEQAAAAA/////wAAAADbAAAA9QAA ABUBAAAtAQAAWgEAAFsBAABuAQAAbwEAAAUEAAAGBAAARgUAAEgFAACQBQAA kgUAAKUFAADHBQAA4AUAACMGAAAkBgAAhwYAAIgGAACyBgAAswYAANQGAADV BgAAAAcAAAEHAAAmBwAAJwcAAE4HAABPBwAAbQcAAG4HAACUBwAAlQcAAMEH AADCBwAA6wcAAOwHAAAVCAAAFggAADUIAAA2CAAAXggAAF8IAACMCAAAjQgA AO0IAADuCAAAEAsAADkLAAAnDAAA0g0AANMNAADUDQAATA4AAJYOAADXDgAA /A4AAP0OAAD+DgAAAQ8AAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA 1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAA AAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADU AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAA AACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAA mQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAA AIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZ AAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgANIAAAABTAAAAAAAAAAgAAAAIAA AAAAAAAAAAAASAAAAAUwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA JwMAAAAAAAAAAAAAgANJiAAwCxAAAAAAAAABAAAAAgAAAAAAAAAAAKADAAAA ANsAAAD1AAAALQEAAFoBAABbAQAAbgEAAG8BAAAFBAAASAUAAJAFAACSBQAA pQUAAMcFAADgBQAAIwYAACQGAACHBgAAsgYAALMGAADUBgAA1QYAAAAHAAAB BwAAJgcAACcHAABOBwAATwcAAG0HAABuBwAAlAcAAJUHAADBBwAAwgcAAOsH AADsBwAAFQgAABYIAAA1CAAANggAAF4IAABfCAAAjAgAAI0IAADtCAAA7ggA ABALAAA5CwAAJwwAANINAADTDQAA1A0AAEwOAACWDgAA1w4AAPwOAAABDwAA mkAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5hAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAdLiAAwAjAAAAAAAAABAAAAKQAAAAMAAABkCH8HS4gAMAIw AAAAAAAAAQAAACgAAAAAAAAAAAAAB0uIADACMAAAAAAAAAIAAAAmAAAAAAAA AAAAAAdLyAAwAjAAAAAAAAABAAAAAwAAAAAAAAAAAIAHS4gAMAIwAAAAAAAA AQAAAAQAAAAAAAAAAACAB0uIADACMAAAAAAAAAEAAAAEAAAAAAAAAAAAgAdL iAAwCDAAAAAAAAABAAAAJgAAAAkAAAAMCX8HSYgAMAgwAAAAAAAAAQAAACUA AAAAAAAAAAAAAUmIADACMAAAAAAAAAEAAAAEAAAAAAAAAAAAgAFLyAAwAjAA AAAAAAABAAAAAwAAAAAAAAAAAIAHS8gAMAIwAAAAAAAAAgAAAAEAAAAAAAAA AACAB0nIADABMAAAAAAAAAEAAAAqAAAAAAAAAAAAAAFLyAAwAjAAAAAAAAAC AAAAAwAAAAAAAAAAAAAHS8gAMAIwAAAAAAAAAgAAAAMAAAAAAAAAAAAAB0vI ADACMAAAAAAAAAIAAAADAAAAAAAAAAAAAAdLyAAwAjAAAAAAAAACAAAAAwD/ /wIAAAAAAEEHS8gAMAQwAAAAAAAAAgAAAAMA//8EAAAAAAAgB0vIADAEMAAA AAAAAAIAAAADAP//BAAAAAAAQQdLyAAwBjAAAAAAAAACAAAAAwD//wYAAAAA ACAHS8gAMAYwAAAAAAAAAgAAAAMA//8GAAAAAABBB0vIADAIMAAAAAAAAAIA AAADAP//CAAAAAAAIAdLyAAwCDAAAAAAAAACAAAAAwD//wgAAAAAAEEHS8gA MAowAAAAAAAAAgAAAAMA//8KAAAAAAAgB0vIADAKMAAAAAAAAAIAAAADAP// CgAAAAAAQQdLyAAwDDAAAAAAAAACAAAAAwD//wwAAAAAACAHS8gAMAwwAAAA AAAAAgAAAAMA//8MAAAAAABBB0vIADAOMAAAAAAAAAIAAAADAP//DgAAAAAA IAdLyAAwDjAAAAAAAAACAAAAAwD//w4AAAAAAEEHS8gAMBAwAAAAAAAAAgAA AAMA//8QAAAAAAAgB0vIADAQMAAAAAAAAAIAAAADAP//EAAAAAAAQQdLyAAw EjAAAAAAAAACAAAAAwD//xIAAAAAAKAHS8gAMBIwAAAAAAAAAgAAAAMA//8S AAAAAACwB0vIADAUMAAAAAAAAAIAAAADAP//FAAAAAAAoAdLyAAwFDAAAAAA AAACAAAAAwD//xQAAAAAALAHS8gAMBYwAAAAAAAAAgAAAAMA//8WAAAAAACg B0vIADAWMAAAAAAAAAIAAAADAP//FgAAAAAArwdLyAAwGDAAAAAAAAACAAAA AwD//xgAAAAAAKAHS8gAMBgwAAAAAAAAAgAAAAMA//8YAAAAAACvB0vIADAa MAAAAAAAAAIAAAADAP//GgAAAAAAoAdLyAAwGjAAAAAAAAACAAAAAwABAAAA AAAAAKAHS8gAMCMwAAAAAAAAAQAAAAgAAQAABAAAAAAgB0vIADAcMAAAAAAA AAIAAAADAAEAAAAAAAAAoAcKQAAAADAAAAAAAAAAAAAAAAABAAAEAAAAACAH mgAAAAAwAAAAAAAAAIAAAACAkXwPAAAAAP9gB0PIADAAMAAAAAAAAAEAAAAI AAAAAAAAAAAAAAcCQAAAALAFANACAADAIQAA//8AAAAAAAAAAAAHS8gAMAMw AAAAAAAAAQAAAAUAAAAAAAAAAACAB0vIADACMAAAAAAAAAEAAAADAAAAAAAA AAAAAAdLiAAwBDAAAAAAAAACAAAABAAAAAUAAAA8cecHS8gAMAIwAAAAAAAA AQAAAAIAAAAAAAAAAAAAB0vIADACMAAAAAAAAAEAAAACAAAAAAAAAAAAAAdL yAAwBDAAAAAAAAABAAAAAgAAAAAAAAAAAAAHS8gAMAAwAAAAAAAAAQAAAAAA AAAAAAAAAACAB5oAAAAAEAAAAAAAAACAAAAAgJF8DwAAAAD/YAcABgAArgkA AJgNAAAhDgAAFBAAADERAAB7EwAAyRUAAFcWAAAAFwAADAAAAA8AAAAQAAAA EQAAABgAAAAdAAAAHgAAAB8AAAAgAAAAAAYAALIOAADVDgAAJg8AAE8PAACU DwAAwg8AABUQAAA2EAAAjBAAAO0QAAD9FgAAABcAAA0AAAASAAAAEwAAABQA AAAVAAAAFgAAABcAAAAZAAAAGgAAABsAAAAcAAAAIQAAAAAGAAD/FgAADgAA ADEJAABfCQAAbAkAAHAJAACsCQAAsQkAALUJAADxCQAA+gkAAP4JAAA8CgAA TAoAAFAKAACaCgAAoAoAAKQKAAD0CgAA/woAAAAPAAATWBT/FYwTWBT/FYwT WBT/FYwTWBT/FYwTWBT/FYwTWBT/FYwyAAAAZgAAAGcAAABOAQAAiwEAAJUB AACXAQAA1AEAANUBAAAlAgAAJwIAACgCAAAqAgAAZwIAAGgCAAC4AgAAugIA ALsCAADxAwAAE1gU/xWEE1gU/xWME1gU/xNDFP8V7BWME1gU/xNDFP8V7BWM AQAAAP//////////AAAAAAAAAAAAAAAADwAA8EgBAAAAAAbwGAAAAAIIAAAC AAAACwAAAAEAAAABAAAADAAAAG8AAfAIAQAAYgAH8CQAAAAGBiGiw/x0Eft+ XFwAGpvN0Qj/ACoOAAACAAAANEQAAAAAAABSAAfwJAAAAAUFcSVOHyXb3le1 UZ5Q5rJCpv8AigoAAAAAAAD/////AAAAAFIAB/AkAAAABQXNYeWNTczNN6Ko PKQ/R/e9/wADCgAAAAAAAP////8AAAAAUgAH8CQAAAAFBVz7VGOwMCUzmzys /QPfsEP/AB0JAAAAAAAA/////wAAAABSAAfwJAAAAAUFfT4f6AxRogn2pefT uu+/Hv8ARwoAAAAAAAD/////AAAAAGIAB/AkAAAABgZLT1opEBMuwri+AZ5U y3dP/wA9IwAAAQAAAF5SAAAAAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQ AA8AAvAoAwAAEAAI8AgAAAAGAAAACwQAAA8AA/DGAgAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8G4AAAAS AArwCAAAAAIEAAAACgAAUwAL8B4AAACAAAAAAQCKAAIEAADAAf///wD/AQgA CAC/AyAAIAAjACLxDAAAAL8BAABgAD8FAAABAAAAEPAEAAAAAwAAAAAAEfAE AAAAAQAAAAAADfAEAAAAAAABAA8ABPB0AAAAIgAK8AgAAAADBAAAAAoAAGMA C/AkAAAAgAAAAAIAigADBAAAgQH/mQAAvwEQABAAwAH/mQAA/wEIAAgAIwAi 8QwAAAC/AQAAYAA/BQAAAQAAABDwBAAAAAAAAAAAABHwBAAAAAEAAAAAAA3w BAAAAAAAAgAPAATwXgAAALIECvAIAAAABAQAAAAKAABTAAvwIAAAAARBAQAA AAXBAgAAAAYBAgAAAP8BAAAIAL8DAAAgAAAAEwAi8QYAAAC/AQAAYAAAABDw BAAAAAEAAAAAABHwBAAAAAEAAAAPAATwZAAAALIECvAIAAAABQQAAAAKAABj AAvwJgAAAARBAQAAAAXBAgAAAAYBAgAAAAkBcD0AAP8BAAAIAL8DIAAgAAAA EwAi8QYAAAC/AQAAYAAAABDwBAAAAAIAAAAAABHwBAAAAAEAAAAPAATwygAA ALIECvAIAAAACwQAAAAKAABjAAvwjAAAAARBBgAAAAXBZgAAAAYBCgAAAP8B AAAIAIHDAgAAAL8DAAAgAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBzAG8AdQB0 AGgAYQBmAHIAaQBjAGEALgBpAG4AZgBvAC8AcABpAGMAcwAvAHIAZQBkAGUA cwBpAGcAbgAvAHQAcgBpAG0ALgBnAGkAZgAAAAAAEwAi8QYAAAC/AQAAYAAA ABDwBAAAAAQAAAAAABHwBAAAAAEAAAAPAATwQgAAABIACvAIAAAAAQQAAAAO AABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAE AAAAAQAAAAAAAAABAAAAAgAAAAMAAADuCAAAAA8AAAMEAADI+///YPr//1Qz AAAAAAAAdAABAAAABAQAAJj+//9g+v//9AsAADD9//90AAAAAAAFBAAAmP7/ /6z5//+gMgAAiEoAAHRAAAAAAAIEAAAIBwAAFPv//2guAACY/v//dEABAAAA CwQAAEz///+WBQAAHC8AAGYIAAB0AAAAAAD//wIAAAAGAOfluAkIAAEABCIX AAYA6OW4CQoAAQBM0nwLmAcAADkLAAABDwAAAAAAAAEAAQAAAAEAngcAAEIL AAABDwAAAAAAAAEAAAABAAAAVgAAAAIAAAAqgHVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwWAcGxhY2UdgGh0dHA6Ly93d3cu NWlhbnRsYXZhbGFtcC5jb20vDAAAAdyNVAoAAAAAAgAAAAAAAgAAAAAA//8B AAAACAAAAP//AQAAAAAAAgAAAAEPAAAAAAAAAAADAAAAAQ8AAAAAAAAQCwAA AQ8AAAcABwAAAAAAEAsAAAEPAAAHAAcAAAAAAAIAAAADAAAAAwAAAAQAAAAE AAAArQAAAK0AAADaAAAA2wAAAG0BAABtAQAAbgEAAG4BAABvAQAAjAEAAGcC AABzAgAAeAIAAIMCAACyAgAAtQIAAAUEAAAGBAAAmAUAAKQFAAClBQAApQUA AKwFAADGBQAA0QUAAN8FAACIBgAAiAYAALIGAACyBgAAswYAALMGAADUBgAA 1AYAAI4IAACUCAAA7ggAAA8LAAAQCwAA0g0AANMNAADTDQAA1A0AAGMOAABw DgAA/A4AAP0OAAD+DgAAAQ8AAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQABwAEAAcABAADAAQABwAEAAcABAAHAAAAAAAQCwAA AQ8AAAcABwAEAOVr2wQAAAAAAAAAAAABAgACAPlgUUKoNWFNBQAAAAAAqDVh TeVr2wQFAAAAAADEYvp/AAAAAAAAAAAAAQIAAgAXAAAABAAAAAgAAADlAAAA AAAAABYAAADbNwMADQILAJp5JAD+WScA83QnALYRKQD7LVkAPSN8AEELfwBS TYEAIR6CAGgVgwDxB5YALnuWAD0/lwDtYZgAxn2bABJLogCfFqUAt2SqAMh9 xwCiEtwAWUPlAAAAAACIBgAAsgYAALMGAADUBgAA1QYAAAAHAAABBwAAJgcA ACcHAABOBwAATwcAAG0HAABuBwAAlAcAAJUHAADBBwAAwgcAAOsHAADsBwAA FQgAABYIAAA1CAAANggAAF4IAABfCAAAjAgAAI0IAADtCAAA7ggAAAEPAAAA AAAACAAAAAIBAACeAQAEAgEAAJ4BAAQCAQAAngEABAIBAACeAQAEAgEAAJ4B AAQCAQAAngEABAIBAACeAQAEAgEAAJ4BAAQCAQAAngEABAIBAACeAQAEAgEA AJ4BAAQCAQAAngEABAIBAACeAQAEAgEAAJYBAAT/QAEBAQACAAAAAwAAADQp MAEBAAEAAgAAAAIAAADfBQAAAAAAAAIQAAAAAAAAAAAPAABgAAAQAEAAAP// AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD/ /wAAAgD//wAAAAD//wAAAgD//wAAAAAJAAAARxaQAQAAAgIGAwUEBQIDBId6 ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACA AAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAA AAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAAEEWkAEAAAIEBgIFAwUDAwSHAgAA AAAAAAAAAAAAAAAAnwAAAAAAAABCAG8AbwBrACAAQQBuAHQAaQBxAHUAYQAA AD81kAEAAAIHAwkCAgUCBASHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABDAG8A dQByAGkAZQByACAATgBlAHcAAAA1JpABAAACCwYEAwUEBAIEh3oAYQAAAIAI AAAAAAAAAP8BAQAAAAAAVABhAGgAbwBtAGEAAAA3JpABAAACCwYEAwUEBAIE hwIAIAAAAAAAAAAAAAAAAJ8BAAAAAAAAVgBlAHIAZABhAG4AYQAAAEUmkAEA AAILBQICAgICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABDAGUAbgB0AHUA cgB5ACAARwBvAHQAaABpAGMAAAA/JpABAAACCwoEAgECAgIEhwIAAAAAAAAA AAAAAAAAAJ8AAAAAAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAAIgAEAPEI mBgA8NACAABoAQAAAADqQdlG6kHZRgAAAAACAAIAAACmAQAAagkAAAEABQAA AAQAAxAUAAAApgEAAGoJAAABAAUAAAAUAAAAJ8w6tyEDAPAQAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALQAoAW0ALQAgYFy NAAAEAAZAGQAAAAZAAAACwsAAAsLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAA AAAACDKDUQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAA AAAp8P8PAQABPwAA5AQAAP///3////9/////f////3////9/////f////3/t YZgAAQAAADoAAAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAACtACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAAAAAAAAABAHUABAB1AHMAZQByAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUB AgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAEAIA ABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAFABAAAEAAAAXAEAAAUAAABoAQAA BgAAAHQBAAAHAAAAgAEAAAgAAACQAQAACQAAAKABAAASAAAArAEAAAoAAADM AQAADAAAANgBAAANAAAA5AEAAA4AAADwAQAADwAAAPgBAAAQAAAAAAIAABMA AAAIAgAAAgAAAOQEAAAeAAAAsAAAACAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgAAAAHgAAAAQAAAAAAAAAHgAAAAQAAAB1AAAAHgAA AAQAAAAAAAAAHgAAAAQAAAAAAAAAHgAAAAgAAABOb3JtYWwAAB4AAAAIAAAA dXNlcgAAAAAeAAAABAAAADIAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2Ug V29yZAAAAEAAAAAAjIZHAAAAAEAAAAAA7LOFkjDKAUAAAAAA7LOFkjDKAQMA AAABAAAAAwAAAKYBAAADAAAAagkAAAMAAAAIAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAF AQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXV zdWcLhsQk5cIACss+a7YAQAAlAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAA AHwAAAAGAAAAhAAAABEAAACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAA EwAAAKwAAAAWAAAAtAAAAA0AAAC8AAAADAAAAHYBAAACAAAA5AQAAB4AAAAE AAAAAAAAAAMAAAAUAAAAAwAAAAUAAAADAAAACwsAAAMAAADmFQsACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAK4AAAAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAAMEAAAAgAAAB4AAAAG AAAAVGl0bGUAAwAAAAEAAABEBgAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAA QAAAAAEAAAACAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAAQQAAAPwFAABC AAAAAwAAAG0AawADAAAADwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAPAAAAGgA dAB0AHAAOgAvAC8AdwB3AHcALgBtAHQAbgAuAGMAbwAuAHoAYQAvAFMAdQBw AHAAbwByAHQALwBQAGEAZwBlAHMALwBDAG8AbgB0AGEAYwB0AEMAdQBzAHQA bwBtAGUAcgBDAGEAcgBlAC4AYQBzAHAAeAAAAB8AAAABAAAAAAAUDgMAAABd AA0AAwAAAAwAAAADAAAAAAAAAAMAAAAFAAAAHwAAADYAAABoAHQAdABwADoA LwAvAHcAdwB3AC4AbQB0AG4ALgBjAG8ALgB6AGEALwBTAHUAcABwAG8AcgB0 AC8ATABlAGcAYQBsAC8AUABhAGcAZQBzAC8AZABlAGYAYQB1AGwAdAAuAGEA cwBwAHgAAAAfAAAAAQAAAAAAFA4DAAAADgBJAAMAAAAJAAAAAwAAAAAAAAAD AAAABQAAAB8AAAAqAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAG0AdABuAC4A YwBvAC4AegBhAC8AUwBlAGEAcgBjAGgALwBhAGQAdgBhAG4AYwBlAGQALgBh AHMAcAB4AAAAHwAAAAEAAAAAABQOAwAAACsAawADAAAABgAAAAMAAAAAAAAA AwAAAAUAAAAfAAAAKAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBtAHQAbgAu AGMAbwAuAHoAYQAvAFAAYQBnAGUAcwAvAFMAaQB0AGUATQBhAHAALgBhAHMA cAB4AAAAHwAAAAEAAAAAABQOAwAAADoAbgADAAAAAwAAAAMAAAAAAAAAAwAA AAUAAAAfAAAAKAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBtAHQAbgAuAGMA bwAuAHoAYQAvAFAAYQBnAGUAcwAvAE0AVABOAEoAbwBiAHMALgBhAHMAcAB4 AAAAHwAAAAEAAAAAABQOAwAAAGUAJgADAAAAAAAAAAMAAAAAAAAAAwAAAAUA AAAfAAAAFAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBtAHQAbgAuAGMAbwBt AC8AAAAfAAAAAQAAAAAAFA4DAAAALwBpAAMAAAAMAAAAAwAAAAAAAAADAAAA BQAAAB8AAAAvAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGMAdQBwADIAMAAx ADAALgBpAG4AZgBvAC8AdwBlAGIALQBmAGUAZQBkAHMALwBSAFMAUwBmAGUA ZQBkAHMALgB4AG0AbAAAAAAAHwAAAAEAAAAAABQOAwAAAC8AaQADAAAABgAA AAMAAAAAAAAAAwAAAAUAAAAfAAAALwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcA LgBjAHUAcAAyADAAMQAwAC4AaQBuAGYAbwAvAHcAZQBiAC0AZgBlAGUAZABz AC8AUgBTAFMAZgBlAGUAZABzAC4AeABtAGwAAAAAAB8AAAABAAAAAAAUDgMA AAAvAGkAAwAAAAMAAAADAAAAAAAAAAMAAAAFAAAAHwAAAC8AAABoAHQAdABw ADoALwAvAHcAdwB3AC4AYwB1AHAAMgAwADEAMAAuAGkAbgBmAG8ALwB3AGUA YgAtAGYAZQBlAGQAcwAvAFIAUwBTAGYAZQBlAGQAcwAuAHgAbQBsAAAAAAAf AAAAAQAAAAAAFA4DAAAAWgBVAAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8A AAAaAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHMAYQAyADAAMQAwAC4AZwBv AHYALgB6AGEALwAAAB8AAAABAAAAAAAUDgMAAAB1ACIAAwAAAP////8DAAAA CwQAAAMAAAABAAAAHwAAADMAAABoAHQAdABwADoALwAvAHcAdwB3AC4AcwBv AHUAdABoAGEAZgByAGkAYwBhAC4AaQBuAGYAbwAvAHAAaQBjAHMALwByAGUA ZABlAHMAaQBnAG4ALwB0AHIAaQBtAC4AZwBpAGYAAAAAAB8AAAABAAAAAAAU DgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA AgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAAN AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAA ACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAA LwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAA/v///zwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAAD+////RAAAAEUA AABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAA AFEAAABSAAAAUwAAAFQAAABVAAAA/v///1cAAABYAAAAWQAAAFoAAABbAAAA XAAAAF0AAAD+////XwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAP7////9 ////aAAAAP7////+/////v////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8D AAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAJCIDYeSMMoBagAAAIAA AAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7AAAAABAAAAAAAAAx AFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAAAC+JQAAAAAAAFcAbwByAGQA RABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAJt1AAAAAAAABQBTAHUAbQBtAGEAcgB5 AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABWAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUA bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAAC AQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAF4AAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAA/v////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAA AEYfAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkIERvY3VtZW50AAoAAABNU1dv cmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --0-882565084-1252446420=:47139-- From owner-v6ops@ops.ietf.org Tue Sep 8 19:20: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 C82183A69B1 for ; Tue, 8 Sep 2009 19:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.373, 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 8kEdmgeIOf1i for ; Tue, 8 Sep 2009 19:20:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C04593A6827 for ; Tue, 8 Sep 2009 19:20:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlCio-000Irt-GV for v6ops-data0@psg.com; Wed, 09 Sep 2009 02:15:46 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlCic-000IpD-Di for v6ops@ops.ietf.org; Wed, 09 Sep 2009 02:15:43 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A020F3A691A; Tue, 8 Sep 2009 19: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-v6inixp-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090909021501.A020F3A691A@core3.amsl.com> Date: Tue, 8 Sep 2009 19: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 Deployment in Internet Exchange Points (IXPs) Author(s) : R. Gagliano Filename : draft-ietf-v6ops-v6inixp-02.txt Pages : 10 Date : 2009-09-08 This document provides a guide for IPv6 deployment in Internet Exchange Points (IXP). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks to be performed. IXPs are mainly a layer 2 infrastructure and in many case the best recommendations state that the IPv6 data, control and management plane should not be handled differently than in IPv4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6inixp-02.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-v6inixp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-08190013.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Tue Sep 8 19:27: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 29A2F28C167 for ; Tue, 8 Sep 2009 19:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.366 X-Spam-Level: X-Spam-Status: No, score=-99.366 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, 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 lUvpyiCf2nKp for ; Tue, 8 Sep 2009 19:27:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5996D3A6B42 for ; Tue, 8 Sep 2009 19:27:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlCtp-000K8R-PD for v6ops-data0@psg.com; Wed, 09 Sep 2009 02:27:09 +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 1MlCsb-000K1T-To for v6ops@ops.ietf.org; Wed, 09 Sep 2009 02:26:03 +0000 Received: from [192.168.1.109] (r190-64-128-142.dialup.adsl.anteldata.net.uy [190.64.128.142]) by mail.lacnic.net.uy (Postfix) with ESMTP id E4BA6308502 for ; Tue, 8 Sep 2009 23:25:39 -0300 (UYT) Message-Id: From: Roque Gagliano To: v6ops WG Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-75--721968983" Mime-Version: 1.0 (Apple Message framework v936) Subject: Fwd: New Version Notification for draft-ietf-v6ops-v6inixp-02 Date: Tue, 8 Sep 2009 23:25:37 -0300 References: <20090909020014.0D00128C1DA@core3.amsl.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) Content-Transfer-Encoding: 7bit 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: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-75--721968983 Content-Type: multipart/alternative; boundary=Apple-Mail-74--721969020 --Apple-Mail-74--721969020 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, I issued a new ID of the draft with the changes that came up at the Stockholm meeting. Changes were: - I explained why ULA is not a good idea. - I added that addressing can use two different /48, one for the LANs and the second one for the internal services and not necessarily one / 47, as comments at the meeting. - I included comments from Nick Hilliar about BGP sessions. - I added text about having different participants in different solocited-node multicast group. - I mention of RA-Guard based on comments from Nick Hilliar. I will now request Alain and Bernard to review the doc as they are the WG volunteers. Regards, Roque. Begin forwarded message: > From: IETF I-D Submission Tool > Date: September 8, 2009 11:00:14 PM GMT-03:00 > To: roque@lacnic.net > Subject: New Version Notification for draft-ietf-v6ops-v6inixp-02 > > > A new version of I-D, draft-ietf-v6ops-v6inixp-02.txt has been > successfuly submitted by Roque Gagliano and posted to the IETF > repository. > > Filename: draft-ietf-v6ops-v6inixp > Revision: 02 > Title: IPv6 Deployment in Internet Exchange Points (IXPs) > Creation_date: 2009-09-08 > WG ID: v6ops > Number_of_pages: 10 > > Abstract: > This document provides a guide for IPv6 deployment in Internet > Exchange Points (IXP). It includes information regarding the switch > fabric configuration, the addressing plan and general organizational > tasks to be performed. IXPs are mainly a layer 2 infrastructure and > in many case the best recommendations state that the IPv6 data, > control and management plane should not be handled differently than > in IPv4. > > > > The IETF Secretariat. > ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE --Apple-Mail-74--721969020 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

I issued = a new ID of the draft with the changes that came up at the Stockholm = meeting. Changes were:
- I explained why ULA is not a good = idea.
- I added that addressing can use two different /48, one = for the LANs and the second one for the internal services and not = necessarily one /47, as comments at the meeting.
- I included = comments from Nick Hilliar about BGP sessions.
- I added text = about having different participants in different solocited-node = multicast group.
- I mention of RA-Guard based on comments = from Nick Hilliar.

I will now request Alain and = Bernard to review the doc as they are the WG = volunteers.

Regards,

Roq= ue. 




=
Begin forwarded message:

From: = IETF I-D Submission Tool <idsubmission@ietf.org>=
Date: September 8, 2009 11:00:14 PM = GMT-03:00
Subject: = New Version Notification for = draft-ietf-v6ops-v6inixp-02 


A new = version of I-D, draft-ietf-v6ops-v6inixp-02.txt has been successfuly = submitted by Roque Gagliano and posted to the IETF = repository.

Filename: = draft-ietf-v6ops-v6inixp
Revision: 02
Title: IPv6 = Deployment in Internet Exchange Points (IXPs)
Creation_date: = 2009-09-08
WG ID: v6ops
Number_of_pages: = 10

Abstract:
This document provides a guide for IPv6 = deployment in Internet
Exchange Points (IXP).  It includes = information regarding the switch
fabric configuration, the addressing = plan and general organizational
tasks to be performed.  IXPs are = mainly a layer 2 infrastructure and
in many case the best = recommendations state that the IPv6 data,
control and management = plane should not be handled differently than
in = IPv4.



The IETF = Secretariat.


-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE
 =

= --Apple-Mail-74--721969020-- --Apple-Mail-75--721968983 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkqnEiEACgkQnk+WSgHpbO7dPQCfV1qs3dpjeEBf9NAe7L5MVIR+ 6sYAn0+gZ6p5tbiClBkzTQWs8EmZoDug =mmvJ -----END PGP SIGNATURE----- --Apple-Mail-75--721968983-- From owner-v6ops@ops.ietf.org Wed Sep 9 04:39:13 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 DCD8D28C351 for ; Wed, 9 Sep 2009 04:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 c7Hpbc78ItRw for ; Wed, 9 Sep 2009 04:39:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3666228C339 for ; Wed, 9 Sep 2009 04:39:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlLON-000P8D-U0 for v6ops-data0@psg.com; Wed, 09 Sep 2009 11:31:15 +0000 Received: from [209.85.210.199] (helo=mail-yx0-f199.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlLOL-000P80-Kv for v6ops@ops.ietf.org; Wed, 09 Sep 2009 11:31:15 +0000 Received: by yxe37 with SMTP id 37so2233599yxe.5 for ; Wed, 09 Sep 2009 04:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=H6oIUVVtX4OQaoq3NHwAlhYSuzCvNBC9BsmGn0sJssY=; b=JgHPl5/3T5sxxbXxihSasul/J6RJ+k6J3uUSDpjEjtw/0F9Wkg3aZRHX1MXaT/4Rdx Ez2AgUKAkaOP0Cr2m5eTQBMVrnAn2OfHqnEQG4xifnR29YpR9T8nI4av2F5jv2jcAIZV cBnXLZvm8qGiEsfiolHvdT10SM1hUdBpRoI+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wPpIkYBn0q93b/IWGRe5+CrGqCfYfKstNRnn/hgY2RFP0/2mgwi1bNhT4nBh0xlhiW eErjB5Ma6qSJSQhA859RXwgWhiHBC15BdRcU0H+jzFZy2EtCynYIJBq+8j/NoDqpjlDr CAqPGzDTzuS7qelfQA1g6cEKfge3Fkh5/OW8E= MIME-Version: 1.0 Received: by 10.150.163.2 with SMTP id l2mr275073ybe.272.1252495872927; Wed, 09 Sep 2009 04:31:12 -0700 (PDT) In-Reply-To: References: <8d6a15670909040025sfcde567x58cbd615c417deba@mail.gmail.com> Date: Wed, 9 Sep 2009 13:31:12 +0200 Message-ID: <8d6a15670909090431m716f1f4bq5b7763709486ea93@mail.gmail.com> Subject: Re: Hello, Any Ideas as how I can catch up fast From: Edwin Mulenga To: "Wes Beebee (wbeebee)" Cc: v6ops@ops.ietf.org Content-Type: multipart/alternative; boundary=000e0cd4894e96a89a0473236bcb Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --000e0cd4894e96a89a0473236bcb Content-Type: text/plain; charset=ISO-8859-1 Thanks, i find it interesting. 2009/9/8 Wes Beebee (wbeebee) > You can start by reading the charter, RFC's and working group documents, > found on: > > http://www.ietf.org/dyn/wg/charter/v6ops-charter.html > > Then send any review comments for working group documents to this mailer. > > - Wes > > ------------------------------ > *From:* owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] *On > Behalf Of *Edwin Mulenga > *Sent:* Friday, September 04, 2009 3:26 AM > *To:* v6ops@ops.ietf.org > *Subject:* Hello, Any Ideas as how I can catch up fast > > I really would like to actively participate in this working group,.. any > ideas to find myself on the right track? Or I need to consult literature? > > Thanks, > > Edwin > --000e0cd4894e96a89a0473236bcb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, i find it interesting.=A0

2009/9= /8 Wes Beebee (wbeebee) <wbeebee@cisco.com>
You can start by reading the charter, RFC's and working=20 group documents, found on:
=A0
=A0
Then send any review comments for working group documents=20 to this mailer.
=A0
- Wes

From: owner-v6ops@ops.ietf.org=20 [mailto:owner= -v6ops@ops.ietf.org] On Behalf Of Edwin=20 Mulenga
Sent: Friday, September 04, 2009 3:26 AM
To:=20 v6ops@ops.ietf.org<= /a>
Subject: Hello, Any Ideas as how I can catch up=20 fast

I really would like to actively participate in this working group,.. a= ny=20 ideas to find myself on the right track?=A0 Or I need to consult=20 literature?
=A0
Thanks,
=A0
Edwin

--000e0cd4894e96a89a0473236bcb-- From owner-v6ops@ops.ietf.org Thu Sep 10 05:14:13 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 40A4B3A685C for ; Thu, 10 Sep 2009 05:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=-0.943, 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 0ZqL5QN-B1v6 for ; Thu, 10 Sep 2009 05:14:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFFE63A6AA3 for ; Thu, 10 Sep 2009 05:14:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MliS6-0001vh-Rl for v6ops-data0@psg.com; Thu, 10 Sep 2009 12:08:38 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MliS4-0001v3-Ht for v6ops@ops.ietf.org; Thu, 10 Sep 2009 12:08:38 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 03193E081A3; Thu, 10 Sep 2009 14:08:26 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 46B7AE080E1; Thu, 10 Sep 2009 14:08:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <576F9230-1A07-479F-8336-6906658736BB@free.fr> Cc: IPv6 v6ops , 6man 6man , Behave WG , Fred L Templin , Gabi Nakibly Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: IID-format constraint applicable to all IPv6 addresses for routing-loop attack protection Date: Thu, 10 Sep 2009 14:08:16 +0200 To: Margaret Wasserman , Fred Baker , Christian Huitema , Dave Thaler X-Mailer: Apple Mail (2.753.1) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi all, Should IID-format constraints be applicable to IPv6 addresses, even if they don't contain real IIDs? I have proposed in various occasions that they would apply only to addresses that do contain real IIDs. This mail is to WITHDRAW this proposal, to explain why it was proposed, and to explain why it is withdrawn. GENERAL ANALYSIS New IPv6-address formats are being considered for IPv6 addresses that, in IPv6/IPv4 NATs, identify IPv4 hosts. Some others are considered for new tunneling mechanisms, in particular the SAM I presented in Stockholm for IPv6 multihoming. In these addresses, the lower 64 bits are not real IIDs: - RFC 3513 says that "Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link"). - The lower 64 bits of these addresses are never "used to identify interfaces on a link". It is only IPv4 or IPv6 addresses obtained after some mapping that are used for on-link interface identification. They in general don't contain the initial lower 64 bits. We will call such addresses "mappable-only" addresses. RFC 3513 also says, as we all know, that "For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format". We will call this constraint the "IID-format constraint" Since mappable-only addresses have no real "Interface ID", they may be interpreted as out of the scope of the IID-format constraint. If they are indeed out of scope, that's good news because new formats of mappable-only addresses can be simpler than if they are in scope (no constraint on the two lower bits of their 9th octet). If mappable-only addresses should be considered in the constraint scope, some technical reason for it should at least be documented. Since no such technical reason was identified, I proposed to make official that the IID-format constraint doesn't apply to mappable- only addresses. Now, it happens that such a technical reason has just been identified. As explained below, it relates to a subtle attack possibility with some ISATAP and 6to4 nodes conforming to current RFCs. The only choice that remains is then to clearly include mappable-only addresses in the scope of the IID-format constraint. ROUTING-LOOP ATTACK PROTECTION AND ITS IMPLICATION ON IPV6 ADDRESS FORMATS In a mail of Aug 17 (www.ops.ietf.org/lists/v6ops/v6ops.2009/ msg00601), Gabi Nakibly documented a new type of attack: the "routing loop" attack. With it, some packets can be repeatedly retransmitted between two ISATAP routers, or between an ISATAP router and a 6to4 relay router. For a brief illustration of one instance of the the attack, here is an example: +-------------------------------------------------------+ | IPv6 IPv6 packet | |Internet dst6: 2002:198.16.9.9::1 | | src6: 2001:db8:1::200:5efe:192.88.99.1| | | | | V | | .--------------->--------------. | | | / \| | +--------+----------------------------------+-----------+ | | 2001:db8:1::/48 2002::/16 +---------+ +---------+ | ISATAP | | 6to4 | +---------+ +---------+ 198.16.9.9 192.88.99.1 | | +--------+---------+ | | IPv4 ^ | | | site ^ | | | ^ | V | ^ | | +--------+---------+ | 198.16.9.0/24 | | | | | +--------+----------------------------------+-----------+ | IPv4 \ / | |internet '----------------<-------------' | | IPv6 in IPv4 packet | | dst4: 198.16.9.9 | | src4: 192.88.99.1 | | | +--------+----------------------------------+-----------+ Detailed protection mechanisms against these attacks are being discussed on the v6ops and 6man lists, in particular with Gabi Nakibly, Fred Templin, and Christian Huitema, and are out of scope here. Suffice it to say that a 6to4 relay router may need, to be safe, to look at IPv4 addresses that are embedded in ISATAP IPv6 addresses. In the above example, if the 6to4 relay router sees that the IPv4 embedded address in the IPv6 destination is its own IPv4 address 192.88.99.1, it can discard the packet and thus prevent the loop. Now, IPv4 addresses embedded in ISATAP addresses can be reliably detected ONLY if non-ISATAP addresses NEVER have 200:5efe::/32 in their octets 8 to 15. If some mappable-only address would have this pattern, there could be a slight but real possibility that an intermediate 6to4 relay would discard packets sent to this address. This is, in my understanding, a sufficient technical reason for the IID-format constraint to apply to all IPv6 addresses (with or without real IID). Regards, RD From owner-v6ops@ops.ietf.org Thu Sep 10 19:32: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 D871A3A6902 for ; Thu, 10 Sep 2009 19:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[AWL=-1.221, 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 AQEi17jYx+Bw for ; Thu, 10 Sep 2009 19:32:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C3053A67AE for ; Thu, 10 Sep 2009 19:32:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlviV-000G1p-37 for v6ops-data0@psg.com; Fri, 11 Sep 2009 02:18:27 +0000 Received: from [209.85.216.185] (helo=mail-px0-f185.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlvZI-000EgU-Mf for v6ops@ops.ietf.org; Fri, 11 Sep 2009 02:12:57 +0000 Received: by pxi15 with SMTP id 15so544729pxi.25 for ; Thu, 10 Sep 2009 19:08:55 -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=u0t8+mURm6u5q7lyXeWxsNBZFcvo/L5BBwbn+4cxUK4=; b=cpUTAQcgWuuCFuogIY8C0XQx0LcjPBbIWyj0dtklpQQDXYTmOEJQ5InzBevXPBtWxz 8aRagIV8Uwmp7+weSONsG/7oMDRg7AZAC7KfLduTdjEteJPTM1AbzNJgYoyAjORQ/pOl R5bj3XmC7X0wOUDpZ+w7PrkY2eQBlJPboPFsE= 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=O9DvPzk4qavCtv6rJOpPGg/DitobPDJgGfpYE3FLmZHI/XNkUywW0B4bNBDieCI4hC 2YWq1vPIJ6JaaLyAg/RWhySVKQU+ZtfYTKLW7VAVRGza0TqqEF6LngriqgnHIjw/9QAT HEkAP5MvwQa5aZUjQSIo9bRtEVTVxZjeF7lD4= Received: by 10.114.165.20 with SMTP id n20mr4289473wae.6.1252634935134; Thu, 10 Sep 2009 19:08:55 -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 22sm2043008pzk.14.2009.09.10.19.08.53 (version=SSLv3 cipher=RC4-MD5); Thu, 10 Sep 2009 19:08:54 -0700 (PDT) Message-ID: <4AA9B134.4000604@gmail.com> Date: Fri, 11 Sep 2009 14:08:52 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" CC: shengjiang@huawei.com, v6ops , xujf@gsta.com Subject: Re: Review of 'draft-xu-v6ops-hybrid-framework-00.txt' References: <39C363776A4E8C4A94691D2BD9D1C9A106599A1B@XCH-NW-7V2.nw.nos.boeing.com> <58D3EFD90AF84F32B31B93F4E364F10E@JiangXiong> <39C363776A4E8C4A94691D2BD9D1C9A1065D8095@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065D8095@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2009-09-09 05:32, Templin, Fred L wrote: > Hi Sheng, > >> -----Original Message----- >> From: Sheng Jiang [mailto:shengjiang@huawei.com] >> Sent: Monday, September 07, 2009 10:14 AM >> To: Templin, Fred L; 'v6ops' >> Cc: xujf@gsta.com; 'Brian E Carpenter' >> Subject: RE: Review of 'draft-xu-v6ops-hybrid-framework-00.txt' >> >> Hi, Templin, >> >> Thanks so much for your reviewing and comments. >> >> All of your comments are accepted and will be reflected in the next > version, >> except for the below one. Can I ask you a question here: overall, do > you >> think this draft is suitable for v6ops charter and mature enough to be >> adopted as wg file? >> >>> 8) Section 3, second paragraph beginning: "In order to >>> find NATs and traverse them,", this text seems to imply >>> that *all* applications need to be made NAT-aware when >>> in fact many/most applications are oblivious to NATs. >>> Is there a certain class of applications this text is >>> meaning to refer to? If so, the assumptions must be >>> stated. >> I guess, this refer is to these applications that want to traverse > NATs. If >> you have any specific text to suggest, we may adopt it in the next > version. > > I guess when I think of NAT discovery and traversal, I > think of NAT-specific end system services like STUN, TURN, > ICE, TEREDO, etc. and not about "ordinary" IPv4 applications > like ftp, web browsing, etc. Here is a proposed rewrite that > I think could accommodate the concern: > > "In order to find NATs and traverse them, end system services > have to understand network protocols deeply, invoke or interact > with network protocols directly and analyse network behaviours > by themselves, since the protocol stack on the end system is > not aware of NATs. That seems correct; VoIP and P2P for example have to be aware that there may be NATs in the path. In the GRO work (draft-carpenter-behave-referral-object), we assume that applications need to be aware of non-transparency in general. I fear that we're heading towards a world in which applications without this awareness will stop working. Brian From owner-v6ops@ops.ietf.org Thu Sep 10 19:34: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 F04973A688F for ; Thu, 10 Sep 2009 19:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.905, 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 kDCKN2aL-z+V for ; Thu, 10 Sep 2009 19:34:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EBA93A68D0 for ; Thu, 10 Sep 2009 19:34:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mlvpb-000Gt6-Jt for v6ops-data0@psg.com; Fri, 11 Sep 2009 02:25:47 +0000 Received: from [209.85.216.185] (helo=mail-px0-f185.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlvN6-000CP9-B9 for v6ops@ops.ietf.org; Fri, 11 Sep 2009 02:00:20 +0000 Received: by pxi15 with SMTP id 15so538494pxi.25 for ; Thu, 10 Sep 2009 18:56:19 -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=rvJM6szBibWrBSEQTOI4UplosI6LUROKbkQxBn1OQD0=; b=xxidPgbXa8L9bI4u7GSmc7T1jpTXvYzrLVRob8cfcvM4GyNMfitas1y6oV55N3Vq2g kwXWjvkouWTSmh3DAY1osoo4Bkd3FQY1nuw9TUn8SXNSCTDm5JTkt+xvDmsnUNl1GaXU QRqQReARK8CxoMwnkkMm0nfmn9j8WAQ3K+5rY= 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=BWJjiuGh+2lCcZoP9Aqmzy5w7KkUZEbgOENypAtbJ0PHsbaRKMvTYzr6dQ7Yqy1OAc wxaqZROnR4AvQM+nMhXAswgBI+lfqHfRJEWeDgbyR7ixnkjM8ug2S7/DlZiI5VMS0RzW zeSaaQuOMqcabt2U7ufZ0iMziTGOD+/GfgJOc= Received: by 10.115.66.24 with SMTP id t24mr4243482wak.39.1252634179536; Thu, 10 Sep 2009 18:56:19 -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 21sm1774677pxi.7.2009.09.10.18.56.17 (version=SSLv3 cipher=RC4-MD5); Thu, 10 Sep 2009 18:56:19 -0700 (PDT) Message-ID: <4AA9AE40.50004@gmail.com> Date: Fri, 11 Sep 2009 13:56:16 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" CC: shengjiang@huawei.com, v6ops , Fred Baker , guoseu@huawei.com Subject: Re: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt' References: <31484.26522.qm@web45503.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com><373420.97768.qm@web45509.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A106599A1A@XCH-NW-7V2.nw.nos.boeing.com> <58C86C6B78A448A890D98A311A60BBC1@JiangXiong> <39C363776A4E8C4A94691D2BD9D1C9A1065D807A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065D807A@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2009-09-09 05:12, Templin, Fred L wrote: > Hi Sheng, > >> -----Original Message----- >> From: Sheng Jiang [mailto:shengjiang@huawei.com] >> Sent: Sunday, September 06, 2009 3:52 PM ... > Thanks for considering the input. On point 5), however, > it should be OK to talk about MTU without using words that > could be construed as normative. For example, the original > text could be reworded slightly as follows: > > "However, for IPv6 traffic, a user behind the DS HG will > see normal IPv6 service. We therefore observe that an > IPv6 tunnel MTU of at least 1500 bytes would ensure that > the mechanism does not cause excessive fragmentation of > IPv6 traffic nor excessive IPv6 path MTU discovery > interactions." I think that this should be said. Operational people will get the message without the need for normative text. Brian From kellyheinke@6notes.com Thu Sep 10 21:24: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 B7CDF3A67E1 for ; Thu, 10 Sep 2009 21:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.297 X-Spam-Level: X-Spam-Status: No, score=-28.297 tagged_above=-999 required=5 tests=[AWL=10.075, 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_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, 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 xCgfqDeAoG4W for ; Thu, 10 Sep 2009 21:23:58 -0700 (PDT) Received: from abogadosargentinos.com (unknown [123.16.225.218]) by core3.amsl.com (Postfix) with SMTP id D2EEE3A67A2 for ; Thu, 10 Sep 2009 21:23:55 -0700 (PDT) To: Subject: no-reply From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090911042356.D2EEE3A67A2@core3.amsl.com> Date: Thu, 10 Sep 2009 21:23:55 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Fri Sep 11 15:44:33 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 3C16F28C1A1 for ; Fri, 11 Sep 2009 15:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.614 X-Spam-Level: X-Spam-Status: No, score=-4.614 tagged_above=-999 required=5 tests=[AWL=-0.719, 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 1lovACebVXAy for ; Fri, 11 Sep 2009 15:44:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E139A3A683B for ; Fri, 11 Sep 2009 15:44:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmDpD-0008pv-Rs for v6ops-data0@psg.com; Fri, 11 Sep 2009 21:38:35 +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 1MmDRM-00050V-HO for v6ops@ops.ietf.org; Fri, 11 Sep 2009 21:17:56 +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 n8BLDqhc014094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2009 16:13:52 -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 n8BLDql9026330; Fri, 11 Sep 2009 16:13:52 -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 n8BLDjLm026053; Fri, 11 Sep 2009 16:13:52 -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, 11 Sep 2009 14:13:45 -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, 11 Sep 2009 14:13:44 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <309242.20809.qm@web45513.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcozGkJPdACh96PHSv23xhQKVoGb8QACFT+A References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "Christian Huitema" , "v6ops" Cc: , X-OriginalArrivalTime: 11 Sep 2009 21:13:45.0593 (UTC) FILETIME=[BF5E0690:01CA3324] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Friday, September 11, 2009 12:59 PM > To: Templin, Fred L; Christian Huitema; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Hi Fred, > See below. >=20 > Gabi >=20 >=20 >=20 > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; Christian Huitema = ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Tuesday, September 8, 2009 8:37:03 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi and Christian, > > > > Focusing only on attack #3 (i.e., leaving out attack #1 > > and #2 6to4 interactions for the moment), please check > > the following summary of proposed mitigations: > > > > 1) For ISATAP/VET routers that have assurance that their > > neighbor cache is coherent, the router can make a simple > > check in the neighbor cache to determine whether to > > forward or drop the packet. In pseudo-code: > > > > =A0 isatap_rcv() { > > =A0 =A0 ... > > =A0 =A0 if ((v6src is not a neighbor) && (v6dst !=3D "fe80::*")) > > =A0 =A0 =A0 drop_pkt(); > > =A0 =A0 ... > > =A0 } > > > > =A0 isatap_xmt() { > > =A0 =A0 ... > > =A0 =A0 if ((v6dst is not a neighbor) && (v6src !=3D "fe80::*")) > > =A0 =A0 =A0 drop_pkt(); > > =A0 =A0 ... > > =A0 } > > > > (Here, the link-local exception is necessary to bootstrap > > neighbor discovery on the ISATAP link.) > > > > Does anyone see a problem with this? > > > Looks fine. OK. > > 2) For ISATAP/VET routers that use public IPv4 addresses > > and that do not have assurance that their neighbor cache > > is coherent, the router can check for the interface ID > > "0200:5EFE:". In pseudo-code: > > > > =A0 isatap_rcv() { > > =A0 =A0 ... > > =A0 =A0 if (v6dst =3D=3D "foreign_prefix::0200:5efe:") > > =A0 =A0 =A0 drop_pkt(); > > =A0 =A0 ... > > =A0 } > > > > =A0 isatap_xmt() { > > =A0 =A0 ... > > =A0 =A0 if (v6src =3D=3D "foreign_prefix::0200:5efe:") > > =A0 =A0 =A0 drop_pkt(); > > =A0 =A0 ... > > =A0 } > > > > Does anyone see a problem with this? >=20 > Looks fine. OK, but since I sent this I began to wonder whether cases 1) and 2) should be reversed (i.e., do the 0x00:5EFE check first). I came to believe that it almost doesn't matter from a performance standpoint, and perhaps should be left up to the implementer. Do you have an opinion on this?=20 > > 3) For ISATAP/VET routers that use private IPv4 addresses > > and that do not have assurance that their neighbor cache > > is coherent, the router can make the checks that Christian > > has proposed. But, will we see any of these case 3) > > situations in operational practice? > > >=20 > I can not tell for sure. Why this case seems to you less plausible = than case 2? Case 3) is the case in which source address spoofing within a private IPv4 addressing range is possible. It seems to me that it may correspond to either a poorly managed deployment, or one in which there are multiple administrative authorities with diverse policies and operational practices. The checks that Christian proposed could be used for this scenario if possible. Otherwise, the best solution IMHO would be to allow only routers (and not hosts) on the virtual links. This final model would be best addressed by VET and SEAL rather than ISATAP. Thanks - Fred fred.l.templin@boeing.com > > I would also like to point out that the attack vectors only > > occur when the ISATAP/VET router mistakes the other tunnel > > endpoint for a host when in fact the other end is another > > router. Mitigations for router-to-router ingress filtering > > are already specified in VET. > > > > Comments? > > > > Fred > > fred.l.templin@boeing.com > > > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Tuesday, September 08, 2009 5:28 AM > > > To: Christian Huitema; Templin, Fred L; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Hi Christian, > > > Thanks for your comments. > > > > > > > > > The checks=A0you suggested are powerful and will indeed mitigate = the attacks. > > The only thing that > > > worries me is the fact that=A0usually AFAIK the=A0ISATAP router is = not configured > > with the IPv4 subnet > > > addresses of the site. This means that the router must now be = configured with > > this information and > > > reconfigured as this information changes. If this is felt to be a = reasonable > > administrative overhead, > > > then I think the checks should be employed. > > > > > > One minor thing that should be noted is that these checks will not = mitigate > > the attacks in case there > > > are two ISATAP links (with two separate routers)=A0in the same = site. This > > means=A0that their sets of > > > registered subnets coincide.=A0I assume that=A0such deployment are = not common, > > although I do not have the > > > information to back this assumption. > > > > > > Gabi > > > > > > > > > ----- Original Message ---- > > > > From: Christian Huitema > > > > To: "Templin, Fred L" ; Gabi Nakibly > > ; v6ops > > > > > > > Cc: "ipv6@ietf.org" ; "secdir@ietf.org" > > > > Sent: Friday, September 4, 2009 10:25:21 PM > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > I think that there is another possible way to protect against = these attacks, > > if > > > > the ISATAP router limits the range of IPv4 addresses towards = which it is > > willing > > > > to relay packets. That would fit many current deployments, maybe = most. > > > > > > > > In many current deployments, ISATAP is used to provide IPv6 = connectivity > > inside > > > > a "site", typically protected by a firewall. The expected = behavior is that > > hosts > > > > in that site will use direct ISATAP connectivity to exchange = packets with > > each > > > > other, and will use the ISATAP router to exchange packets with = other IPv6 > > > > subnets. > > > > > > > > Assume that the site is defined by a set of IPv4 subnets, and = the ISATAP > > router > > > > knows that list. The basic check in the ISATAP router is thus: > > > > > > > > =A0 =A0 =A0 =A0 On incoming packet: > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If IPv6 source belongs to local = ISATAP subnet (matches > > /64=A0prefix): > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If (IPv4 source = does not match last 32 bits of > > IPv6=A0source): drop; > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else If (IPv4 = source does not belong to one > > of=A0registered subnets): drop; > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else relay; // = we may or may not want to add > > a=A0destination check > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If (IPv4 source = belongs to one of registered > > subnets):=A0drop; > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else if (IPv6 = destination does not match ISATAP > > subnet):=A0drop; > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else if = (embedded IPv4 address does not belong to > > of=A0registered subnets): > > > drop; > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else relay; > > > > > > > > Written that way, the ISATAP router cannot create a loop, = because packets > > always > > > > go either from site to elsewhere, or from elsewhere to site. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf Of > > Templin, > > > > Fred L > > > > Sent: Friday, September 04, 2009 1:01 PM > > > > To: Gabi Nakibly; v6ops > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > Gabi, > > > > > > > > I'd like to make one other observation about these checks we > > > > have been discussing. There seems to be an implication that > > > > there needs to be a check on all of the IPv4 addresses assigned > > > > to the node's IPv4 interfaces, and with ISATAP there could be > > > > multiple underlying IPv4 interfaces over which the ISATAP > > > > interface is configured. So, that would seem like a potential > > > > performance issue if there were multiple IPv4 addresses to > > > > check for every packet. > > > > > > > > But, if the ISATAP router configures only a single IPv4 address > > > > and places it on the ISATAP interface (i.e., leaving all of the > > > > underlying IPv4 interfaces with only a link-local address) then > > > > there is only one IPv4 address to check. The technique is = called: > > > > "link-layer multiplexing" and is described for ISATAP/VET in > > > > Appendix B of 'draft-templin-intarea-vet'. But, the idea really > > > > came from Section 3.3.4 of RFC1122. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > -----Original Message----- > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > Sent: Thursday, September 03, 2009 8:00 AM > > > > > To: Templin, Fred L; v6ops > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > Hi Fred, > > > > > see inline. > > > > > > > > > > Gabi > > > > > > > > > > ----- Original Message ---- > > > > > > From: "Templin, Fred L" > > > > > > To: Gabi Nakibly ; v6ops > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > Sent: Tuesday, September 1, 2009 6:49:56 PM > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > Gabi, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > > > Sent: Monday, August 31, 2009 12:41 PM > > > > > > > To: Templin, Fred L; v6ops > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > I agree that the source address check discussed below = should be made. > > I > > > > would > > > > > > also add a forth > > > > > > > check to mitigate attack #3 as a second layer of defense = in case the > > > > opposite > > > > > > ISATAP router does not > > > > > > > make the proper check on the destination address. > > > > > > > > > > > > > > isatap_xmt() { > > > > > > >=A0 =A0 =A0 ... > > > > > > >=A0 =A0 =A0 if (src =3D=3D "::0200:5efe:") > > > > > > >=A0 =A0 =A0 =A0 drop_pkt(); /* attack #3 mitigation */ > > > > > > >=A0 =A0 =A0 ... > > > > > > >=A0 } > > > > > > > > > > > > Having thought about it a bit, I agree but for ISATAP I see > > > > > > the source address check as a MAY and the destination = address > > > > > > check as a SHOULD. > > > > > > > > > > Why do you think so? As I see it, the two checks mitigate two = different > > > > attacks. The destination > > > > > address check defends the ISATAP router against attacks of = type 3 in which > > it > > > > acts as > > > > > the decapsulator of the attack packet.=A0 While, the source = address check > > > > defends the ISATAP > > > > > router against attacks of type 3 in which it acts as the = ecapsulator of > > the > > > > attack packet.=A0 Either of > > > > > these checks are redundant if the other one is employed by the = opposite > > router > > > > of the attack. So I do > > > > > not see why one of them is a SHOULD and the other is a MAY. > > > > > > > > > > > > > > > > > In new automatic tunneling protocol specifications that use = a > > > > > > different encapsulation format than ip-proto-41, as long as > > > > > > we make the destination address check a MUST before anything > > > > > > gets deployed then the source address check is unnecessary > > > > > > > > > > > > > > > > In principle, I agree with you. However, I am a believer of = the "defense > > in > > > > depth" paradigm: two > > > > > layers of security are (usually) better than one. Since no one = can be > > > > absolutely sure that the > > > > > destination address check shall always be implemented = correctly at all > > other > > > > routers then it may seem > > > > > prudent to also employ the source check as a second layer of = defense. > > > > > > > > > > > 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: Friday, August 28, 2009 11:23:40 PM > > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > A quick summary of our discussion up until now: the = best > > mitigation > > > > > > of most of > > > > > > > > these attacks is > > > > > > > > > indeed the proto-41 and ingress filtering on the = border of the > > ISATAP > > > > > > site. If > > > > > > > > it is indeed > > > > > > > > > implemented. I assume 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. > > > > > > > > > > > > > > > > > > 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 and the 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 further comments inline. > > > > > > > > > > > > > > > > > > Gabi > > > > > > > > > > > > > > > > > > ----- 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 initially very much liked your suggestion = regarding the > > check of > > > > the > > > > > > > > > > neighbor cache before > > > > > > > > > > > forwarding a packet into the tunnel. It truly = addresses the > > root > > > > cause > > > > > > of > > > > > > > > the > > > > > > > > > > problem ans is simple > > > > > > > > > > > enough to implement. However, I realized that an = attacker can > > send > > > > a > > > > > > > > > > spoofed RS to the ISATAP router > > > > > > > > > > > as if it came from the 6to4 relay. The router = would then send > > a RA > > > > to > > > > > > > > it and > > > > > > > > > > consequently change its > > > > > > > > > > > neighbor cache. So it seems that this defense does = not add > > > > > > much. Wouldn'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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > I completely agree with your observation on the > > non-feasibility of > > > > > > > > > > verifying that the > > > > > > > > > > > destination ISATAP address does not include a = local IPv4 > > address > > > > since > > > > > > the > > > > > > > > > > ISATAP address may include > > > > > > > > > > > a private IPv4 address. On the other hand, a check = on public > > IPv4 > > > > > > > > addresses is > > > > > > > > > > acceptable. If 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 at > > different > > > > > > sites. > > > > > > > > Note > > > > > > > > > > that if attack #3 is > > > > > > > > > > > launched on two ISATAP routers having private = addresses at two > > > > > > different > > > > > > > > sites > > > > > > > > > > then the attack will > > > > > > > > > > > not work anyway since one router can not send a = direct IPv4 > > packet > > > > to > > > > > > the > > > > > > > > > > other. In addition, > > > > > > > > > > > to mitigate 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 perfect 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 measures besides packet filtering = (proto-41 and > > > > ingress) > > > > > > > > by other > > > > > > > > > > nodes (which does 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). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Well, I am referring to any ISATAP deployment with = 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" . > > > > > > > > > However, I must admit that I do not rely here on hard = evidence. > > > > > > > > > > > > > > > > > > > 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 drop_pkt(); /* attack #3 mitigation */ > > > > > > > > > >=A0 =A0 ... > > > > > > > > > >=A0 } > > > > > > > > > > > > > > > > > > > > > > > > > > > > Correct (with the correction you sent after this = email). > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > >=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 } > > > > > > > > > > > > > > > > > > This will not necessarily work, since the 6to4 relay = may have a > > > > unicast > > > > > > > > address the ISATAP router may > > > > > > > > > not be aware of. The best way to mitigate attack #2 is = by 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 accordance with 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 it is = still assumed > > > > > > > > > > > > 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 > > > > > > > > > > > > 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 is another border router which = connects 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 encapsulate the packet = accordingly > > > > > > > > > > > and forward it through the internal IPv4 = interface. 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 other 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 ingress not = egress > > > > > > > > > > > > filtering. Hence it will 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 it may be possible for the = attack > > > > > > > > > > > > packet to 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 packet with a source address = having the > > > > > > > > corresponding prefix > > > > > > > > > > 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 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 > > > > > > > > > > > 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 = should 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 also 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 Each ISATAP interface configures a set of = locators > > consisting > > > > of > > > > > > IPv4 > > > > > > > > > > > >=A0 address-to-interface mappings from a single = site; i.e., an > > > > ISATAP > > > > > > > > > > > >=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 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > = -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 > > > > = -------------------------------------------------------------------- > > > > > > > > > > > > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Sep 11 17:19: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 9DBA528C0DE for ; Fri, 11 Sep 2009 17:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.712, 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 Lc-Y7V1duwiE for ; Fri, 11 Sep 2009 17:19:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8D783A6855 for ; Fri, 11 Sep 2009 17:19:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmFLW-000Ok8-Ql for v6ops-data0@psg.com; Fri, 11 Sep 2009 23:16:02 +0000 Received: from [209.85.216.185] (helo=mail-px0-f185.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmFBa-000MxM-5t for v6ops@ops.ietf.org; Fri, 11 Sep 2009 23:09:46 +0000 Received: by pxi15 with SMTP id 15so1162405pxi.25 for ; Fri, 11 Sep 2009 16:05:45 -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=IU7NyYe/2MLeCQZAs16cpCFny5s1iSpP6xrZPO0/XJc=; b=Z5DeIaHIYLM7NKnaWBAUJqzR8kttbnj2oHm8S4MwJwYD+50dq9f/Mr7yRYNkx7xfD2 hlr9YRkosrJBZdbe2n1vSLY5XDHdmBwGN557iFWs2IJm1XdoHgucGXGwq5isGF92bORD ndIc0Rf8laLjSoyyk81oKAQoHPazE1VV2C0HM= 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=owcZ++Xg2IK8tB7nm/qzGvpyDTz9WUyN4rsectgmD/qFeT45RCX7rOVLVDVUwhd07c uMEl5mxE/HeOL6PTnwK2AijbcE++OYuwePa543c3hgjbTMiEibYUrT4ZcIItsMnLSjtP harUdoT5anZ60VXnycr1tDOmuSHCbbHU/y+6c= Received: by 10.115.80.14 with SMTP id h14mr6396722wal.133.1252710345015; Fri, 11 Sep 2009 16:05:45 -0700 (PDT) Received: from ?10.1.1.4? (118-92-111-74.dsl.dyn.ihug.co.nz [118.92.111.74]) by mx.google.com with ESMTPS id 20sm2581141pzk.13.2009.09.11.16.05.41 (version=SSLv3 cipher=RC4-MD5); Fri, 11 Sep 2009 16:05:44 -0700 (PDT) Message-ID: <4AAAD7C1.2060709@gmail.com> Date: Sat, 12 Sep 2009 11:05:37 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" CC: Gabi Nakibly , Christian Huitema , v6ops , ipv6@ietf.org, secdir@ietf.org Subject: Re: Routing loop attacks using IPv6 tunnels References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2009-09-12 09:13, Templin, Fred L wrote: (much text deleted) > Otherwise, the best solution IMHO > would be to allow only routers (and not hosts) on the > virtual links. This was of course the original intention for 6to4, so that any misconfiguration issues could be limited to presumably trusted staff and boxes. Unfortunately, reality has turned out to be different, with host-based automatic tunnels becoming popular. Brian From owner-v6ops@ops.ietf.org Fri Sep 11 17:27: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 E5E463A682F for ; Fri, 11 Sep 2009 17:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=-0.417, 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 Fxa6VJN0xiHh for ; Fri, 11 Sep 2009 17:27:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 033663A6864 for ; Fri, 11 Sep 2009 17:27:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmFcr-0000sL-4D for v6ops-data0@psg.com; Fri, 11 Sep 2009 23:33:57 +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 1MmFI6-000O9W-Qj for v6ops@ops.ietf.org; Fri, 11 Sep 2009 23:16:31 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8BNCPbZ023435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Sep 2009 16:12:25 -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 n8BNCO3j006358; Fri, 11 Sep 2009 16:12:25 -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 n8BNCOAG006348; Fri, 11 Sep 2009 16:12:24 -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, 11 Sep 2009 16:12: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: Routing loop attacks using IPv6 tunnels Date: Fri, 11 Sep 2009 16:12:23 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4AAAD7C1.2060709@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcozNGy6F16fZ23NSUGAC73Px33uTwAAGQPw References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <4AAAD7C1.2060709@gmail.com> From: "Templin, Fred L" To: "Brian E Carpenter" Cc: "Christian Huitema" , "v6ops" , , X-OriginalArrivalTime: 11 Sep 2009 23:12:24.0839 (UTC) FILETIME=[52C4C170:01CA3335] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Friday, September 11, 2009 4:06 PM > To: Templin, Fred L > Cc: Christian Huitema; v6ops; ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > On 2009-09-12 09:13, Templin, Fred L wrote: >=20 > (much text deleted) >=20 > > Otherwise, the best solution IMHO > > would be to allow only routers (and not hosts) on the > > virtual links. >=20 > This was of course the original intention for 6to4, so > that any misconfiguration issues could be limited to presumably > trusted staff and boxes. Unfortunately, reality has turned out > to be different, with host-based automatic tunnels becoming > popular. Thanks. I was rethinking this a bit after sending, and I may have been too premature in saying routers only and not hosts. What I would rather have said was that mechanisms such as SEcure Neighbor Discovery (SEND) may be helpful in private addressing domains where spoofing is possible. Let me know if this makes sense. Fred fred.l.templin@boeing.com=20 >=20 > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Fri Sep 11 19:37:41 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 00F3E3A69CF for ; Fri, 11 Sep 2009 19:37:41 -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.709, 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 2hdeu+PiiCPe for ; Fri, 11 Sep 2009 19:37:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D1993A6A2D for ; Fri, 11 Sep 2009 19:37:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmHhK-000Q0D-Hf for v6ops-data0@psg.com; Sat, 12 Sep 2009 01:46:42 +0000 Received: from [209.85.222.199] (helo=mail-pz0-f199.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmHNu-000MKx-So for v6ops@ops.ietf.org; Sat, 12 Sep 2009 01:30:38 +0000 Received: by pzk37 with SMTP id 37so1288914pzk.26 for ; Fri, 11 Sep 2009 18:26:38 -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=xuR5oTnD1ZqaJJPpnLAX5IoxohkM8v1Fk4QY+Yc8RwI=; b=H8wKcy9nMjHErD/LFJ0CJBJ3r2w3/6CeZPbwo5+YKlvDury/avMYYaZCd1BIJpUZbz OCH+srtNiSRgE5RPsdO7K2bI4nzb+MyMzJteNYN+7lWUt2DcB+164T6sXIvg0dMGMPmF MB1u3nRkB5asx/PRkPLfa+P4WcMzga64H44N4= 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=FHK8eqrehZj3Z9H7cf/jduPYKuNiSKMMlW4dimw+yApfBD1Ki+PgF+UNb94cajNwpk lgLn3ZaJ34vpkVTbtSyfaBQIGqHMgK7QDqxtPPluajiMN9ufUD/WXiZfXiauS6jMZ82I JCwh6Vv73TDM1iHr0GTusaQ+xgPGRKqB6i0Mw= Received: by 10.114.163.5 with SMTP id l5mr6598370wae.140.1252718798457; Fri, 11 Sep 2009 18:26:38 -0700 (PDT) Received: from ?10.1.1.4? (118-92-111-74.dsl.dyn.ihug.co.nz [118.92.111.74]) by mx.google.com with ESMTPS id 21sm1008531pzk.3.2009.09.11.18.26.35 (version=SSLv3 cipher=RC4-MD5); Fri, 11 Sep 2009 18:26:38 -0700 (PDT) Message-ID: <4AAAF8C8.6010103@gmail.com> Date: Sat, 12 Sep 2009 13:26:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" CC: Christian Huitema , v6ops , ipv6@ietf.org, secdir@ietf.org Subject: Re: Routing loop attacks using IPv6 tunnels References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <4AAAD7C1.2060709@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2009-09-12 11:12, Templin, Fred L wrote: > Brian, > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Friday, September 11, 2009 4:06 PM >> To: Templin, Fred L >> Cc: Christian Huitema; v6ops; ipv6@ietf.org; secdir@ietf.org >> Subject: Re: Routing loop attacks using IPv6 tunnels >> >> On 2009-09-12 09:13, Templin, Fred L wrote: >> >> (much text deleted) >> >>> Otherwise, the best solution IMHO >>> would be to allow only routers (and not hosts) on the >>> virtual links. >> This was of course the original intention for 6to4, so >> that any misconfiguration issues could be limited to presumably >> trusted staff and boxes. Unfortunately, reality has turned out >> to be different, with host-based automatic tunnels becoming >> popular. > > Thanks. I was rethinking this a bit after sending, and > I may have been too premature in saying routers only > and not hosts. > > What I would rather have said was that mechanisms such as > SEcure Neighbor Discovery (SEND) may be helpful in private > addressing domains where spoofing is possible. Let me know > if this makes sense. Except for the practical problems involved in deploying SEND. We still have an issue in unmanaged networks. Brian From owner-v6ops@ops.ietf.org Sun Sep 13 18:34: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 171523A68F0 for ; Sun, 13 Sep 2009 18:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.032 X-Spam-Level: X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[AWL=0.527, 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 k9KufYaYmuRR for ; Sun, 13 Sep 2009 18:34:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 186273A695A for ; Sun, 13 Sep 2009 18:34:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mn0M4-000APy-Lu for v6ops-data0@psg.com; Mon, 14 Sep 2009 01:27:44 +0000 Received: from [218.17.155.14] (helo=mta1.huaweisymantec.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mn0Lp-000AOk-WB for v6ops@ops.ietf.org; Mon, 14 Sep 2009 01:27:42 +0000 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KPX00EM6TCLRT10@hstga01-in.huaweisymantec.com> for v6ops@ops.ietf.org; Mon, 14 Sep 2009 09:26:45 +0800 (CST) Received: from z90001956 ([10.27.154.76]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KPX006OATCKW600@hstml02-in.huaweisymantec.com> for v6ops@ops.ietf.org; Mon, 14 Sep 2009 09:26:45 +0800 (CST) Date: Mon, 14 Sep 2009 09:26:44 +0800 From: Dong Zhang To: "Templin, Fred L" , Brian E Carpenter Cc: Christian Huitema , v6ops , "ipv6@ietf.org" , "secdir@ietf.org" References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <4AAAD7C1.2060709@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com> Subject: Re: RE: Routing loop attacks using IPv6 tunnels Message-id: <200909140926442553863@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Temlin, Please see inline. Templin, Fred L 2009-09-12 Wrote: >Brian, > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Friday, September 11, 2009 4:06 PM >> To: Templin, Fred L >> Cc: Christian Huitema; v6ops; ipv6@ietf.org; secdir@ietf.org >> Subject: Re: Routing loop attacks using IPv6 tunnels >> >> On 2009-09-12 09:13, Templin, Fred L wrote: >> >> (much text deleted) >> >> > Otherwise, the best solution IMHO >> > would be to allow only routers (and not hosts) on the >> > virtual links. >> >> This was of course the original intention for 6to4, so >> that any misconfiguration issues could be limited to presumably >> trusted staff and boxes. Unfortunately, reality has turned out >> to be different, with host-based automatic tunnels becoming >> popular. > >Thanks. I was rethinking this a bit after sending, and >I may have been too premature in saying routers only >and not hosts. > >What I would rather have said was that mechanisms such as >SEcure Neighbor Discovery (SEND) may be helpful in private >addressing domains where spoofing is possible. Let me know >if this makes sense. > IMHO, most of the threats of automatic tunnels, like ISATAP and 6to4, are resulting from spoofing. If SEND or CGA is possible to be used, many attacks could be mitigated. Thx. >Fred >fred.l.templin@boeing.com > >> >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- ------------------ Dong Zhang 2009-09-14 From mischiefingrr7@114-41-233-36.dynamic.hinet.net Mon Sep 14 00:15: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 97E8B28C0FE; Mon, 14 Sep 2009 00:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.743 X-Spam-Level: **** X-Spam-Status: No, score=4.743 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_DYNAMIC=1.144, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 ar0kj+zw5Adq; Mon, 14 Sep 2009 00:15:09 -0700 (PDT) Received: from 114-41-233-36.dynamic.hinet.net (114-41-233-36.dynamic.hinet.net [114.41.233.36]) by core3.amsl.com (Postfix) with ESMTP id A811528C107; Mon, 14 Sep 2009 00:15:08 -0700 (PDT) Received: from 114.41.233.36 by mail.rmrosario.com; Mon, 14 Sep 2009 15:15:52 +0800 From: "Ipdvb" To: Subject: xmas is comming Date: Mon, 14 Sep 2009 15:15:52 +0800 Message-ID: <01ca354e$3fac0600$24e92972@mischiefingrr7> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 Importance: Normal Send some love to someone you love http://superreplicasales.com/ From owner-v6ops@ops.ietf.org Mon Sep 14 09:31: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 B32333A6A87 for ; Mon, 14 Sep 2009 09:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.927 X-Spam-Level: X-Spam-Status: No, score=-4.927 tagged_above=-999 required=5 tests=[AWL=-0.432, 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 ZQiIOYs2pJVt for ; Mon, 14 Sep 2009 09:31:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 20C363A6A77 for ; Mon, 14 Sep 2009 09:31:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnEO8-000KEi-4i for v6ops-data0@psg.com; Mon, 14 Sep 2009 16:26:48 +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 1MnENM-000KAZ-GP for v6ops@ops.ietf.org; Mon, 14 Sep 2009 16:26:20 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8EGPrh8001447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2009 09:25:54 -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 n8EGPrqZ008939; Mon, 14 Sep 2009 09:25:53 -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 n8EGPmi8008646; Mon, 14 Sep 2009 09:25: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); Mon, 14 Sep 2009 09:25:52 -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, 14 Sep 2009 09:25:50 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10665C90F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4AAAF8C8.6010103@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcozSBuZiYSXlZV3Qjy1t5j1F1+faQCCZNUw References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com><4AAAD7C1.2060709@gmail.com><39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com> <4AAAF8C8.6010103@gmail.com> From: "Templin, Fred L" To: "Brian E Carpenter" Cc: "v6ops" , "Christian Huitema" , , X-OriginalArrivalTime: 14 Sep 2009 16:25:52.0179 (UTC) FILETIME=[06D97830:01CA3558] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Friday, September 11, 2009 6:27 PM > To: Templin, Fred L > Cc: v6ops; Christian Huitema; ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > On 2009-09-12 11:12, Templin, Fred L wrote: > > Brian, > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Friday, September 11, 2009 4:06 PM > >> To: Templin, Fred L > >> Cc: Christian Huitema; v6ops; ipv6@ietf.org; secdir@ietf.org > >> Subject: Re: Routing loop attacks using IPv6 tunnels > >> > >> On 2009-09-12 09:13, Templin, Fred L wrote: > >> > >> (much text deleted) > >> > >>> Otherwise, the best solution IMHO > >>> would be to allow only routers (and not hosts) on the > >>> virtual links. > >> This was of course the original intention for 6to4, so > >> that any misconfiguration issues could be limited to presumably > >> trusted staff and boxes. Unfortunately, reality has turned out > >> to be different, with host-based automatic tunnels becoming > >> popular. > > > > Thanks. I was rethinking this a bit after sending, and > > I may have been too premature in saying routers only > > and not hosts. > > > > What I would rather have said was that mechanisms such as > > SEcure Neighbor Discovery (SEND) may be helpful in private > > addressing domains where spoofing is possible. Let me know > > if this makes sense. >=20 > Except for the practical problems involved in deploying SEND. Can it be said that there is any appreciable operational experience with SEND yet? Are there implementations? > We still have an issue in unmanaged networks. By "unmanaged", how unmanaged do you mean? ISATAP is intended for networks where there is at least some modicum of cooperative management. We want that it can also be used in "loosly" managed networks where there is an overall mutual spirit of cooperation but where site-internal link-layer address spoofing may still be possible. Can SEND be used for that, or do we need something else in addition (e.g., a nonce with every message)? Thanks - Fred fred.l.templin@boeing.com > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Mon Sep 14 21:08: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 736783A6887 for ; Mon, 14 Sep 2009 21:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.882, 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 GPSiKWspOgje for ; Mon, 14 Sep 2009 21:08:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 685213A67A6 for ; Mon, 14 Sep 2009 21:08:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnPFz-000GS4-QH for v6ops-data0@psg.com; Tue, 15 Sep 2009 04:03:07 +0000 Received: from [209.85.222.197] (helo=mail-pz0-f197.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnPFo-000GRW-VX for v6ops@ops.ietf.org; Tue, 15 Sep 2009 04:03:05 +0000 Received: by pzk35 with SMTP id 35so3054475pzk.11 for ; Mon, 14 Sep 2009 21:02:56 -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=AC+QiEdQVuFSAuv/9izBJiSWxvQCZygrvtoZ9W0oZbk=; b=ag8+BfzRj0WeKX1hjelZ5nORAYL/4BCwZG8o7sEulr34kYVmIjmiqFZQY90rNo5iBb VOtD38ipNJ241T5Tcq2h+1zGNkZ+S/RpOGBKDUTgl4LhJOvGsqH/BFUmXzX3UXCw6Vrp YHoWCNcJMa9p7C0cbCNfpZsOxtjgnAGG4U+1s= 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=Mk6NKlKC3D6UHhzJ0v24qBHA/t+NKbxm14rmF7nEOH/xrcEPZQo74O6HkvfNKx5CQj GWEbjNtF9s1dyMYrD+XsCjl55ayP5NylA0nwrPGqCaLvNScF01GY4m1Jjw5Jw6iS7BJC i9mHTMdEhIMlBrY3gVFwXOTyfyIOlSajqs5uE= Received: by 10.114.214.25 with SMTP id m25mr12914876wag.71.1252987376006; Mon, 14 Sep 2009 21:02:56 -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 23sm21511pzk.12.2009.09.14.21.02.53 (version=SSLv3 cipher=RC4-MD5); Mon, 14 Sep 2009 21:02:55 -0700 (PDT) Message-ID: <4AAF11ED.3000300@gmail.com> Date: Tue, 15 Sep 2009 16:02:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" CC: v6ops , Christian Huitema , ipv6@ietf.org, secdir@ietf.org Subject: Re: Routing loop attacks using IPv6 tunnels References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com><4AAAD7C1.2060709@gmail.com><39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com> <4AAAF8C8.6010103@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A10665C90F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10665C90F@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2009-09-15 04:25, Templin, Fred L wrote: > Brian, > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Friday, September 11, 2009 6:27 PM >> To: Templin, Fred L >> Cc: v6ops; Christian Huitema; ipv6@ietf.org; secdir@ietf.org >> Subject: Re: Routing loop attacks using IPv6 tunnels >> >> On 2009-09-12 11:12, Templin, Fred L wrote: >>> Brian, >>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: Friday, September 11, 2009 4:06 PM >>>> To: Templin, Fred L >>>> Cc: Christian Huitema; v6ops; ipv6@ietf.org; secdir@ietf.org >>>> Subject: Re: Routing loop attacks using IPv6 tunnels >>>> >>>> On 2009-09-12 09:13, Templin, Fred L wrote: >>>> >>>> (much text deleted) >>>> >>>>> Otherwise, the best solution IMHO >>>>> would be to allow only routers (and not hosts) on the >>>>> virtual links. >>>> This was of course the original intention for 6to4, so >>>> that any misconfiguration issues could be limited to presumably >>>> trusted staff and boxes. Unfortunately, reality has turned out >>>> to be different, with host-based automatic tunnels becoming >>>> popular. >>> Thanks. I was rethinking this a bit after sending, and >>> I may have been too premature in saying routers only >>> and not hosts. >>> >>> What I would rather have said was that mechanisms such as >>> SEcure Neighbor Discovery (SEND) may be helpful in private >>> addressing domains where spoofing is possible. Let me know >>> if this makes sense. >> Except for the practical problems involved in deploying SEND. > > Can it be said that there is any appreciable operational > experience with SEND yet? Are there implementations? I'd like to know that too. > >> We still have an issue in unmanaged networks. > > By "unmanaged", how unmanaged do you mean? I was thinking of home networks, the kind where Teredo or 6to4 starts up spontaneously. Probably not a concern for ISATAP sites. Brian > ISATAP is > intended for networks where there is at least some modicum > of cooperative management. We want that it can also be used > in "loosly" managed networks where there is an overall mutual > spirit of cooperation but where site-internal link-layer > address spoofing may still be possible. Can SEND be used > for that, or do we need something else in addition (e.g., > a nonce with every message)? > > Thanks - Fred > fred.l.templin@boeing.com > >> Brian >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From owner-v6ops@ops.ietf.org Mon Sep 14 22:53: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 691C93A68CE for ; Mon, 14 Sep 2009 22:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCa1-By9DW0G for ; Mon, 14 Sep 2009 22:53:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57E2D28C170 for ; Mon, 14 Sep 2009 22:53:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnQwe-0000Eb-VJ for v6ops-data0@psg.com; Tue, 15 Sep 2009 05:51:16 +0000 Received: from [202.124.241.204] (helo=smtp-1.servers.netregistry.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnQwU-0000Dx-Ua for v6ops@ops.ietf.org; Tue, 15 Sep 2009 05:51:14 +0000 Received: from [114.75.158.220] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MnQwK-00010t-QE; Tue, 15 Sep 2009 15:50:58 +1000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 15 Sep 2009 15:50:42 +1000 Subject: Re: Routing loop attacks using IPv6 tunnels From: Hesham Soliman To: "Templin, Fred L" , Brian E Carpenter CC: v6ops , Christian Huitema , , Message-ID: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcozSBuZiYSXlZV3Qjy1t5j1F1+faQCCZNUwAB2xuao= In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10665C90F@XCH-NW-7V2.nw.nos.boeing.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, >>> What I would rather have said was that mechanisms such as >>> SEcure Neighbor Discovery (SEND) may be helpful in private >>> addressing domains where spoofing is possible. Let me know >>> if this makes sense. >> >> Except for the practical problems involved in deploying SEND. > > Can it be said that there is any appreciable operational > experience with SEND yet? Are there implementations? => About 2 months ago there was a thread on the node requirements draft that addressed the presence of SEND implementations and people who have implementations voiced them on the list. If memory serves me right it's basically on linux, BSD and IOS, but check the archives. I don't know anything about deployment experience. Hesham From owner-v6ops@ops.ietf.org Tue Sep 15 08: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 B4B5E3A6B54 for ; Tue, 15 Sep 2009 08:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.94 X-Spam-Level: X-Spam-Status: No, score=-4.94 tagged_above=-999 required=5 tests=[AWL=-0.445, 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 FUChlOdjNoR7 for ; Tue, 15 Sep 2009 08:39:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 166CD3A6B32 for ; Tue, 15 Sep 2009 08:39:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mna6X-000BbR-HV for v6ops-data0@psg.com; Tue, 15 Sep 2009 15:38:05 +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 1Mna6K-000BZs-OK for v6ops@ops.ietf.org; Tue, 15 Sep 2009 15:38:01 +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 n8FFbaSf013805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Sep 2009 08:37:36 -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 n8FFbZ1u015468; Tue, 15 Sep 2009 08:37:36 -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 n8FFbVBq015337; Tue, 15 Sep 2009 08:37:35 -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, 15 Sep 2009 08:37:35 -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: Tue, 15 Sep 2009 08:37:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10665CEC7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcozSBuZiYSXlZV3Qjy1t5j1F1+faQCCZNUwAB2xuaoAFEnBsA== References: <39C363776A4E8C4A94691D2BD9D1C9A10665C90F@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Hesham Soliman" , "Brian E Carpenter" Cc: "v6ops" , "Christian Huitema" , , X-OriginalArrivalTime: 15 Sep 2009 15:37:35.0485 (UTC) FILETIME=[72B2CAD0:01CA361A] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hesham, > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, September 14, 2009 10:51 PM > To: Templin, Fred L; Brian E Carpenter > Cc: v6ops; Christian Huitema; ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Fred, >=20 > >>> What I would rather have said was that mechanisms such as > >>> SEcure Neighbor Discovery (SEND) may be helpful in private > >>> addressing domains where spoofing is possible. Let me know > >>> if this makes sense. > >> > >> Except for the practical problems involved in deploying SEND. > > > > Can it be said that there is any appreciable operational > > experience with SEND yet? Are there implementations? >=20 > =3D> About 2 months ago there was a thread on the node requirements draft that > addressed the presence of SEND implementations and people who have > implementations voiced them on the list. If memory serves me right it's > basically on linux, BSD and IOS, but check the archives. I don't know > anything about deployment experience. Thanks for the pointer. A quick google search yesterday also showed up JUNOS as having an implementation, so there may be still others. I'll have a look at the archives. Fred fred.l.templin@boeing.com =20 > Hesham From owner-v6ops@ops.ietf.org Tue Sep 15 08:39: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 9428B3A6B5B for ; Tue, 15 Sep 2009 08:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.933 X-Spam-Level: X-Spam-Status: No, score=-4.933 tagged_above=-999 required=5 tests=[AWL=-0.438, 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 WO6C1pAENRl9 for ; Tue, 15 Sep 2009 08:39:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97EB73A6B54 for ; Tue, 15 Sep 2009 08:39:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mna34-000BAI-PM for v6ops-data0@psg.com; Tue, 15 Sep 2009 15:34:30 +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 1Mna2q-000B98-M3 for v6ops@ops.ietf.org; Tue, 15 Sep 2009 15:34:26 +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 n8FFY3Lf017058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Sep 2009 08:34:03 -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 n8FFY3QG015746; Tue, 15 Sep 2009 08:34:03 -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 n8FFY1N7015602; Tue, 15 Sep 2009 08:34:02 -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, 15 Sep 2009 08:34: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: Tue, 15 Sep 2009 08:34:01 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10665CEB5@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4AAF11ED.3000300@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: Aco1uXBRJ8FVPWcBS/yoBklfXDWHbwAYDQ2g References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com><4AAAD7C1.2060709@gmail.com><39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com><4AAAF8C8.6010103@gmail.com><39C363776A4E8C4A94691D2BD9D1C9A10665C90F@XCH-NW-7V2.nw.nos.boeing.com> <4AAF11ED.3000300@gmail.com> From: "Templin, Fred L" To: "Brian E Carpenter" Cc: "v6ops" , "Christian Huitema" , , X-OriginalArrivalTime: 15 Sep 2009 15:34:02.0856 (UTC) FILETIME=[F3F62E80:01CA3619] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Monday, September 14, 2009 9:03 PM > To: Templin, Fred L > Cc: v6ops; Christian Huitema; ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > On 2009-09-15 04:25, Templin, Fred L wrote: > > Brian, > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Friday, September 11, 2009 6:27 PM > >> To: Templin, Fred L > >> Cc: v6ops; Christian Huitema; ipv6@ietf.org; secdir@ietf.org > >> Subject: Re: Routing loop attacks using IPv6 tunnels > >> > >> On 2009-09-12 11:12, Templin, Fred L wrote: > >>> Brian, > >>> > >>>> -----Original Message----- > >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >>>> Sent: Friday, September 11, 2009 4:06 PM > >>>> To: Templin, Fred L > >>>> Cc: Christian Huitema; v6ops; ipv6@ietf.org; secdir@ietf.org > >>>> Subject: Re: Routing loop attacks using IPv6 tunnels > >>>> > >>>> On 2009-09-12 09:13, Templin, Fred L wrote: > >>>> > >>>> (much text deleted) > >>>> > >>>>> Otherwise, the best solution IMHO > >>>>> would be to allow only routers (and not hosts) on the > >>>>> virtual links. > >>>> This was of course the original intention for 6to4, so > >>>> that any misconfiguration issues could be limited to presumably > >>>> trusted staff and boxes. Unfortunately, reality has turned out > >>>> to be different, with host-based automatic tunnels becoming > >>>> popular. > >>> Thanks. I was rethinking this a bit after sending, and > >>> I may have been too premature in saying routers only > >>> and not hosts. > >>> > >>> What I would rather have said was that mechanisms such as > >>> SEcure Neighbor Discovery (SEND) may be helpful in private > >>> addressing domains where spoofing is possible. Let me know > >>> if this makes sense. > >> Except for the practical problems involved in deploying SEND. > > > > Can it be said that there is any appreciable operational > > experience with SEND yet? Are there implementations? >=20 > I'd like to know that too. >=20 > > > >> We still have an issue in unmanaged networks. > > > > By "unmanaged", how unmanaged do you mean? >=20 > I was thinking of home networks, the kind where Teredo or > 6to4 starts up spontaneously. Probably not a concern for > ISATAP sites. OK, thanks for the clarification. I think you probably mean home networks where the home gateway has not yet been turned into an ISATAP router - else, it would be a managed network. Does that sound right? Fred fred.l.templin@boeing.com > Brian >=20 > > ISATAP is > > intended for networks where there is at least some modicum > > of cooperative management. We want that it can also be used > > in "loosly" managed networks where there is an overall mutual > > spirit of cooperation but where site-internal link-layer > > address spoofing may still be possible. Can SEND be used > > for that, or do we need something else in addition (e.g., > > a nonce with every message)? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Brian > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Tue Sep 15 08: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 E38BF3A6BA4 for ; Tue, 15 Sep 2009 08:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.936 X-Spam-Level: X-Spam-Status: No, score=-4.936 tagged_above=-999 required=5 tests=[AWL=-0.441, 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 IorsON1I19p0 for ; Tue, 15 Sep 2009 08:51:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDA1D3A6BA1 for ; Tue, 15 Sep 2009 08:51:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnaIo-000D58-9y for v6ops-data0@psg.com; Tue, 15 Sep 2009 15:50:46 +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 1MnaIa-000D2e-5v for v6ops@ops.ietf.org; Tue, 15 Sep 2009 15:50:40 +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 n8FFms6s015723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Sep 2009 10:48:55 -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 n8FFmsT4010014; Tue, 15 Sep 2009 08:48:54 -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 n8FFmsms009998; Tue, 15 Sep 2009 08:48:54 -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, 15 Sep 2009 08:48:54 -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: RE: Routing loop attacks using IPv6 tunnels Date: Tue, 15 Sep 2009 08:48:53 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10665CF00@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200909140926442553863@huaweisymantec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Routing loop attacks using IPv6 tunnels Thread-Index: Aco1C8FHz2yyLKZkSxW8eJqekN7taQBD+n+w References: <31484.26522.qm@web45503.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com><373420.97768.qm@web45509.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com><342868.34354.qm@web45502.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com><6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com><702481.50824.qm@web45515.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com><309242.20809.qm@web45513.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com><4AAAD7C1.2060709@gmail.com><39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com> <200909140926442553863@huaweisymantec.com> From: "Templin, Fred L" To: "Dong Zhang" , "Brian E Carpenter" Cc: "v6ops" , "Christian Huitema" , , X-OriginalArrivalTime: 15 Sep 2009 15:48:54.0264 (UTC) FILETIME=[07483F80:01CA361C] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dong, > -----Original Message----- > From: Dong Zhang [mailto:zhangdong_rh@huaweisymantec.com] > Sent: Sunday, September 13, 2009 6:27 PM > To: Templin, Fred L; Brian E Carpenter > Cc: v6ops; Christian Huitema; ipv6@ietf.org; secdir@ietf.org > Subject: Re: RE: Routing loop attacks using IPv6 tunnels >=20 > Hi Temlin, >=20 > Please see inline. >=20 > Templin, Fred L 2009-09-12 Wrote: > >Brian, > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Friday, September 11, 2009 4:06 PM > >> To: Templin, Fred L > >> Cc: Christian Huitema; v6ops; ipv6@ietf.org; secdir@ietf.org > >> Subject: Re: Routing loop attacks using IPv6 tunnels > >> > >> On 2009-09-12 09:13, Templin, Fred L wrote: > >> > >> (much text deleted) > >> > >> > Otherwise, the best solution IMHO > >> > would be to allow only routers (and not hosts) on the > >> > virtual links. > >> > >> This was of course the original intention for 6to4, so > >> that any misconfiguration issues could be limited to presumably > >> trusted staff and boxes. Unfortunately, reality has turned out > >> to be different, with host-based automatic tunnels becoming > >> popular. > > > >Thanks. I was rethinking this a bit after sending, and > >I may have been too premature in saying routers only > >and not hosts. > > > >What I would rather have said was that mechanisms such as > >SEcure Neighbor Discovery (SEND) may be helpful in private > >addressing domains where spoofing is possible. Let me know > >if this makes sense. > > > IMHO, most of the threats of automatic tunnels, like ISATAP and 6to4, > are resulting from spoofing. If SEND or CGA is possible to be used, > many attacks could be mitigated. Thanks for voicing your opinion on this, and I agree. Fred fred.l.templin@boeing.com >=20 > Thx. >=20 > >Fred > >fred.l.templin@boeing.com > > > >> > >> Brian > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- >=20 >=20 > ------------------ > Dong Zhang > 2009-09-14 >=20 > -------------------------------------------------------------------- > 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 Sep 15 14:40: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 3B23A3A6C01 for ; Tue, 15 Sep 2009 14:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.874, 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 TraSQ74i1a+A for ; Tue, 15 Sep 2009 14:40:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C1643A6BD8 for ; Tue, 15 Sep 2009 14:40:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mnfg0-000Bm8-0O for v6ops-data0@psg.com; Tue, 15 Sep 2009 21:35:04 +0000 Received: from [209.85.216.185] (helo=mail-px0-f185.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnffY-000Bix-O9 for v6ops@ops.ietf.org; Tue, 15 Sep 2009 21:34:51 +0000 Received: by pxi15 with SMTP id 15so3466563pxi.25 for ; Tue, 15 Sep 2009 14:34:36 -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=qNBmavgV5LjxCSjFVXWTHfls6Sxr2zwUwna+sXM04QQ=; b=Wrl62G58Aq4l1JZRY/KPHjnMZQpfTn6mAJaSC9TeYQaIBqtGDcep53N2GxOYaV9tix 3Rbou23k3mm11NRvIvLm06OeR7T6V+mDL6+mFE1vYZLYDnYyMVT0bnMTkPLvHIZOJIWB 0x8W6j3+B8Bl1lPWGJI4uq27QoY2PGrCrrDV0= 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=cLU36cJRNzgsXS/AlVQmPqPINfFnwJOZq5vfM2yZxGcoTPKwDdbjeac0kjK5dNIrTC RvSdHQkM3kmaY4l46FHLRB3zxVeA3OG6rA0X6stnBjgo+yqyOMajzmu9kY0m2ZSID74m pYNoo6Nc0PCvY0DkA/3ydBxwbbgFLluNk/7Ms= Received: by 10.114.55.7 with SMTP id d7mr14647461waa.129.1253050476092; Tue, 15 Sep 2009 14:34:36 -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 23sm1654857pxi.5.2009.09.15.14.34.34 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Sep 2009 14:34:35 -0700 (PDT) Message-ID: <4AB00868.4000107@gmail.com> Date: Wed, 16 Sep 2009 09:34:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" CC: v6ops , Christian Huitema , ipv6@ietf.org, secdir@ietf.org Subject: Re: Routing loop attacks using IPv6 tunnels References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com><4AAAD7C1.2060709@gmail.com><39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com><4AAAF8C8.6010103@gmail.com><39C363776A4E8C4A94691D2BD9D1C9A10665C90F@XCH-NW-7V2.nw.nos.boeing.com> <4AAF11ED.3000300@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A10665CEB5@XCH-NW-7V2.nw.nos.boeing .com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10665CEB5@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: (one word reply in line...) On 2009-09-16 03:34, Templin, Fred L wrote: > Brian, > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, September 14, 2009 9:03 PM >> To: Templin, Fred L >> Cc: v6ops; Christian Huitema; ipv6@ietf.org; secdir@ietf.org >> Subject: Re: Routing loop attacks using IPv6 tunnels >> >> On 2009-09-15 04:25, Templin, Fred L wrote: >>> Brian, >>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: Friday, September 11, 2009 6:27 PM >>>> To: Templin, Fred L >>>> Cc: v6ops; Christian Huitema; ipv6@ietf.org; secdir@ietf.org >>>> Subject: Re: Routing loop attacks using IPv6 tunnels >>>> >>>> On 2009-09-12 11:12, Templin, Fred L wrote: >>>>> Brian, >>>>> >>>>>> -----Original Message----- >>>>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>>>> Sent: Friday, September 11, 2009 4:06 PM >>>>>> To: Templin, Fred L >>>>>> Cc: Christian Huitema; v6ops; ipv6@ietf.org; secdir@ietf.org >>>>>> Subject: Re: Routing loop attacks using IPv6 tunnels >>>>>> >>>>>> On 2009-09-12 09:13, Templin, Fred L wrote: >>>>>> >>>>>> (much text deleted) >>>>>> >>>>>>> Otherwise, the best solution IMHO >>>>>>> would be to allow only routers (and not hosts) on the >>>>>>> virtual links. >>>>>> This was of course the original intention for 6to4, so >>>>>> that any misconfiguration issues could be limited to presumably >>>>>> trusted staff and boxes. Unfortunately, reality has turned out >>>>>> to be different, with host-based automatic tunnels becoming >>>>>> popular. >>>>> Thanks. I was rethinking this a bit after sending, and >>>>> I may have been too premature in saying routers only >>>>> and not hosts. >>>>> >>>>> What I would rather have said was that mechanisms such as >>>>> SEcure Neighbor Discovery (SEND) may be helpful in private >>>>> addressing domains where spoofing is possible. Let me know >>>>> if this makes sense. >>>> Except for the practical problems involved in deploying SEND. >>> Can it be said that there is any appreciable operational >>> experience with SEND yet? Are there implementations? >> I'd like to know that too. >> >>>> We still have an issue in unmanaged networks. >>> By "unmanaged", how unmanaged do you mean? >> I was thinking of home networks, the kind where Teredo or >> 6to4 starts up spontaneously. Probably not a concern for >> ISATAP sites. > > OK, thanks for the clarification. I think you probably > mean home networks where the home gateway has not yet > been turned into an ISATAP router - else, it would be > a managed network. Does that sound right? Yes Brian > > Fred > fred.l.templin@boeing.com > >> Brian >> >>> ISATAP is >>> intended for networks where there is at least some modicum >>> of cooperative management. We want that it can also be used >>> in "loosly" managed networks where there is an overall mutual >>> spirit of cooperation but where site-internal link-layer >>> address spoofing may still be possible. Can SEND be used >>> for that, or do we need something else in addition (e.g., >>> a nonce with every message)? >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>>> Brian >>>> > -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> > -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From tutwz35@host186-134-static.24-87-b.business.telecomitalia.it Wed Sep 16 09:42: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 78CDF28C17C for ; Wed, 16 Sep 2009 09:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.008 X-Spam-Level: X-Spam-Status: No, score=-35.008 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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, 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 XcgujMAs6JQZ for ; Wed, 16 Sep 2009 09:42:37 -0700 (PDT) Received: from host186-134-static.24-87-b.business.telecomitalia.it (host186-134-static.24-87-b.business.telecomitalia.it [87.24.134.186]) by core3.amsl.com (Postfix) with ESMTP id E2DE728C195 for ; Wed, 16 Sep 2009 09:42:36 -0700 (PDT) Received: from 87.24.134.186 by resourcemining.com; Wed, 16 Sep 2009 17:43:26 +0100 Date: Wed, 16 Sep 2009 17:43:26 +0100 From: "V" X-Mailer: The Bat! (v3.51.10) Home Reply-To: tutwz35@host186-134-static.24-87-b.business.telecomitalia.it X-Priority: 3 (Normal) Message-ID: <473036566.09172370994708@host186-134-static.24-87-b.business.telecomitalia.it> To: v6ops-archive@megatron.ietf.org Subject: china watches MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Give them the best gifts. http://sunsain.com From osloafa@afors.com Wed Sep 16 10:21: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 D126C3A683B for ; Wed, 16 Sep 2009 10:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.6 X-Spam-Level: *** X-Spam-Status: No, score=3.6 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, 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, 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 SeeueIlQ0MIY for ; Wed, 16 Sep 2009 10:21:25 -0700 (PDT) Received: from 189-089-221-040.static.stratus.com.br (189-089-221-040.static.stratus.com.br [189.89.221.40]) by core3.amsl.com (Postfix) with SMTP id DF53D3A69C8 for ; Wed, 16 Sep 2009 10:21:20 -0700 (PDT) To: Subject: new mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090916172121.DF53D3A69C8@core3.amsl.com> Date: Wed, 16 Sep 2009 10:21:20 -0700 (PDT) Show picture and go to site now! From owner-v6ops@ops.ietf.org Wed Sep 16 19:46: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 651133A687E for ; Wed, 16 Sep 2009 19:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[AWL=0.416, 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 f140RTNseQ4w for ; Wed, 16 Sep 2009 19:46:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97CC83A67A8 for ; Wed, 16 Sep 2009 19:46:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mo6vr-0004uc-MX for v6ops-data0@psg.com; Thu, 17 Sep 2009 02:41:15 +0000 Received: from [218.17.155.14] (helo=mta1.huaweisymantec.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mo6vg-0004ta-TP for v6ops@ops.ietf.org; Thu, 17 Sep 2009 02:41:13 +0000 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KQ3000QOGR9AB60@hstga01-in.huaweisymantec.com> for v6ops@ops.ietf.org; Thu, 17 Sep 2009 10:40:22 +0800 (CST) Received: from z90001956 ([10.27.154.76]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KQ300GZOGR8CE00@hstml02-in.huaweisymantec.com> for v6ops@ops.ietf.org; Thu, 17 Sep 2009 10:40:21 +0800 (CST) Date: Thu, 17 Sep 2009 10:40:21 +0800 From: Dong Zhang To: "Templin, Fred L" , Hesham Soliman , Brian E Carpenter Cc: v6ops , Christian Huitema , "ipv6@ietf.org" , "secdir@ietf.org" References: <39C363776A4E8C4A94691D2BD9D1C9A10665C90F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A10665CEC7@XCH-NW-7V2.nw.nos.boeing.com> Subject: Re: RE: Routing loop attacks using IPv6 tunnels Message-id: <200909171040210476174@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Templin, Templin, Fred L 2009-09-16 Wrote: >Hesham, > >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Monday, September 14, 2009 10:51 PM >> To: Templin, Fred L; Brian E Carpenter >> Cc: v6ops; Christian Huitema; ipv6@ietf.org; secdir@ietf.org >> Subject: Re: Routing loop attacks using IPv6 tunnels >> >> Fred, >> >> >>> What I would rather have said was that mechanisms such as >> >>> SEcure Neighbor Discovery (SEND) may be helpful in private >> >>> addressing domains where spoofing is possible. Let me know >> >>> if this makes sense. >> >> >> >> Except for the practical problems involved in deploying SEND. >> > >> > Can it be said that there is any appreciable operational >> > experience with SEND yet? Are there implementations? >> >> => About 2 months ago there was a thread on the node requirements >draft that >> addressed the presence of SEND implementations and people who have >> implementations voiced them on the list. If memory serves me right >it's >> basically on linux, BSD and IOS, but check the archives. I don't know >> anything about deployment experience. > >Thanks for the pointer. A quick google search yesterday >also showed up JUNOS as having an implementation, so there >may be still others. I'll have a look at the archives. There is another implementation. http://www.ietf.org/mail-archive/web/cga-ext/current/msg00321.html ------------------ Dong Zhang 2009-09-17 > >Fred >fred.l.templin@boeing.com > >> Hesham From nlgp@alphasintered.com Wed Sep 16 23:06:13 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 D32D63A6B3B for ; Wed, 16 Sep 2009 23:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.568 X-Spam-Level: X-Spam-Status: No, score=-17.568 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_08=1.787, 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_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_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_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 srpISWHFKyhy for ; Wed, 16 Sep 2009 23:06:07 -0700 (PDT) Received: from aip.org (unknown [189.158.165.192]) by core3.amsl.com (Postfix) with SMTP id 5CCDF3A687C for ; Wed, 16 Sep 2009 23:06:05 -0700 (PDT) To: Subject: It's cold, don't keep me waiting From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090917060606.5CCDF3A687C@core3.amsl.com> Date: Wed, 16 Sep 2009 23:06:05 -0700 (PDT) You'll never see your amorous flag fallen! Try our boosters and let and raise at the right moment! Show picture and go to site now! From card-shop@c-rom.de Thu Sep 17 05:36: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 560D53A6998; Thu, 17 Sep 2009 05:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 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, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_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_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRuhZhAwASpe; Thu, 17 Sep 2009 05:36:27 -0700 (PDT) Received: from ip-62-129-179-220.evc.net (ip-62-129-179-220.evc.net [62.129.179.220]) by core3.amsl.com (Postfix) with SMTP id B41233A68B7; Thu, 17 Sep 2009 05:36:21 -0700 (PDT) Date: Thu, 17 Sep 2009 08:37:12 -0500 Subject: Rep watches models from 2010 From: "Summer Swenson" To: "Lindsay Harmon" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Are you ready for hottest rep watches from 2010? They are here http://tablestuff.com/ From jaqueline@alpinatextil.net Thu Sep 17 11:33: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 839E63A6938 for ; Thu, 17 Sep 2009 11:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[BAYES_99=3.5, 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, HTML_IMAGE_ONLY_08=1.787, 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_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_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 COQQo7FTK8+v for ; Thu, 17 Sep 2009 11:33:14 -0700 (PDT) Received: from 9.158.140.82.ip.erdves.lt (9.158.140.82.ip.erdves.lt [82.140.158.9]) by core3.amsl.com (Postfix) with SMTP id 8CB1A3A67EA for ; Thu, 17 Sep 2009 11:33:10 -0700 (PDT) To: Subject: Fix engine of desire From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090917183311.8CB1A3A67EA@core3.amsl.com> Date: Thu, 17 Sep 2009 11:33:10 -0700 (PDT) Urgent help for your suffering male libido! You order, swallow doze and it stays! Show picture and go to site now! From consolidates1@octantsoftware.com Fri Sep 18 19: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 14A3928C0E6; Fri, 18 Sep 2009 19:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.054 X-Spam-Level: X-Spam-Status: No, score=-9.054 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE=10.357, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=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_DOUBLE_IP_SPAM=3.798, 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_RECV_IP_FROMIP1=1.666, URIBL_AB_SURBL=10, 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 SNU3oNCVFEc3; Fri, 18 Sep 2009 19:06:13 -0700 (PDT) Received: from 201009133033.user.veloxzone.com.br (201009133033.user.veloxzone.com.br [201.9.133.33]) by core3.amsl.com (Postfix) with ESMTP id B70A13A6765; Fri, 18 Sep 2009 19:05:42 -0700 (PDT) Received: from 201.9.133.33 by 130.94.124.168; Fri, 18 Sep 2009 23:04:37 -0300 Message-ID: <000d01ca38cd$8a9ebb30$6400a8c0@consolidates1> From: Kristi Jernigan To: Subject: What do you think about testing my secret for free. Date: Fri, 18 Sep 2009 23:04:37 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA38CD.8A9EBB30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2869 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA38CD.8A9EBB30 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 Email=20 not displaying correctly? View it in=20 your browser. =20 =20 =20 =20 =20 =20 =20 =20 =20   =20 =20 =20 =20 =20 =20 =20 August 2009 =20 Most Popular Last Month =20 More Info =20 Wana look better? =20 More Info =20 =20 =20 Patient=20 Stories =20 =20 You will no longer have to suffer to lose weightIm = restless, I have so much energy and I am feeling great, check it=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 =20 =A0 =A0 Click Here =A0 =A0 =A0 =A0 Read=20 full=20 story.=A0 =20 Newsletter=20 Archive=A0| Subscribe=A0|=20 Contact=20 us =20 Manage=20 My Subscription (including unsubscribe).2009=20 Exemwi Company. All rights reserved. Terms=20 of=20 Use. ------=_NextPart_000_0007_01CA38CD.8A9EBB30 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Email=20 not displaying correctly? View it in=20 your browser.
 
Newslett= er=20 Archive=A0| Subscrib= e=A0|=20 Contact=20 usManage=20 My Subscription (including unsubscribe).
2009=20 Exemwi Company. All rights reserved. Terms=20 of=20 Use.
August 2009Most Popular Last Month=
Mo= re Info

Wa= na look better?

Mo= re Info


Pati= ent=20 Stories

You will no longer have to suffer to lose weight

Im restless, I have so much energy and I am feeling great, check it=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
=A0
=A0
Cl= ick Here
=A0
=A0
=A0
=A0
Re= ad=20 full=20 story.
=A0
------=_NextPart_000_0007_01CA38CD.8A9EBB30-- From maramirezg@aspencenter.org Sat Sep 19 16:51: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 476783A67DD; Sat, 19 Sep 2009 16:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 dE55OTtsq-tQ; Sat, 19 Sep 2009 16:51:27 -0700 (PDT) Received: from adsl-pool2-118.metrotel.net.co (unknown [190.182.53.118]) by core3.amsl.com (Postfix) with SMTP id F1A153A67EE; Sat, 19 Sep 2009 16:51:14 -0700 (PDT) Date: Sat, 19 Sep 2009 19:52:15 -0500 Subject: Rep watches models from 2010 From: "Wayne Sapp" To: "Jenifer Zuniga" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Are you ready for hottest rep watches from 2010? They are here http://tablecake.com/ From orlando_lisa@advancehomesinc.com Sun Sep 20 02:55: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 E2F893A6939; Sun, 20 Sep 2009 02:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, 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 1JYGswvOlOkp; Sun, 20 Sep 2009 02:55:49 -0700 (PDT) Received: from nz029.net116254066.thn.ne.jp (nz029.net116254066.thn.ne.jp [116.254.66.29]) by core3.amsl.com (Postfix) with SMTP id 39E1B3A6A0D; Sun, 20 Sep 2009 02:55:41 -0700 (PDT) Date: Sun, 20 Sep 2009 05:56:44 -0500 Subject: Rep watches models from 2010 From: "Rubin Becker" To: "Amie Woodall" Message-ID: <8W7SYI66el1j8Y9LdXtrade-archive@ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Are you ready for hottest rep watches from 2010? They are here http://tablebring.com/ From onee824@kataoka-co.jp Sun Sep 20 09:08: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 01EBB3A6948; Sun, 20 Sep 2009 09:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.245 X-Spam-Level: ** X-Spam-Status: No, score=2.245 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 s1K2fPWFM8Mm; Sun, 20 Sep 2009 09:08:16 -0700 (PDT) Received: from rrcs-70-60-107-115.midsouth.biz.rr.com (rrcs-70-60-107-115.midsouth.biz.rr.com [70.60.107.115]) by core3.amsl.com (Postfix) with SMTP id D27B43A68BC; Sun, 20 Sep 2009 09:08:12 -0700 (PDT) Date: Sun, 20 Sep 2009 12:09:16 -0500 Subject: Rep watches models from 2010 From: "Pamela Elliot" To: "Mack Jackson" Message-ID: <6D5gnMreW0nVrc7qbVtrade-archive@ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Are you ready for hottest rep watches from 2010? They are here http://tablecake.com/ From heckerj@ev1.net Sun Sep 20 14:19: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 4FEEB3A6810; Sun, 20 Sep 2009 14:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.488 X-Spam-Level: *** X-Spam-Status: No, score=3.488 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giKxUNxgXJia; Sun, 20 Sep 2009 14:19:00 -0700 (PDT) Received: from ev1.net (f055011108.adsl.alicedsl.de [78.55.11.108]) by core3.amsl.com (Postfix) with SMTP id 710583A67AE; Sun, 20 Sep 2009 14:18:55 -0700 (PDT) Message-ID: <5F20639E.430CA36F@ev1.net> Date: Mon, 21 Sep 2009 07:08:43 +0900 Reply-To: "harry " From: "harry " User-Agent: Mozilla/5.0 (compatible; Konqueror/2.2.1; Linux) MIME-Version: 1.0 To: , Subject: the only thing stopping you is you Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ipdvb-archive@megatron.ietf.org legitimate home business create your ideal revenue from home proven home business Call 8882063060 Mon, 21 Sep 2009 07:08:43 +0900 otrotelo From steven.schoenfish@jademosaic.com Sun Sep 20 22:07: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 468273A68B4; Sun, 20 Sep 2009 22:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.584 X-Spam-Level: * X-Spam-Status: No, score=1.584 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_MODEMCABLE=0.768, HELO_EQ_RU=0.595, HOST_EQ_MODEMCABLE=1.368, HOST_EQ_RU=0.875, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 s058TJYy-JNf; Sun, 20 Sep 2009 22:07:27 -0700 (PDT) Received: from broadband-77-37-132-88.nationalcablenetworks.ru (broadband-77-37-132-88.nationalcablenetworks.ru [77.37.132.88]) by core3.amsl.com (Postfix) with SMTP id 7F6BF3A6765; Sun, 20 Sep 2009 22:07:21 -0700 (PDT) Date: Mon, 21 Sep 2009 01:08:19 -0500 Subject: Rep watches models from 2010 From: "Kerri Merritt" To: "Marshall Crabtree" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Are you ready for hottest rep watches from 2010? They are here http://tablecake.com/ From kelleyb@alain-ducasse.com Mon Sep 21 21:05: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 A5CC23A6836 for ; Mon, 21 Sep 2009 21:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.08 X-Spam-Level: X-Spam-Status: No, score=-12.08 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_08=1.787, 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_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_BEZEQINT_B=0.763, 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 dT9-0W+Kqh2u for ; Mon, 21 Sep 2009 21:05:32 -0700 (PDT) Received: from bzq-82-81-125-31.red.bezeqint.net (bzq-82-81-125-31.red.bezeqint.net [82.81.125.31]) by core3.amsl.com (Postfix) with SMTP id F1FC43A68EA for ; Mon, 21 Sep 2009 21:05:30 -0700 (PDT) To: Subject: I've got problems, can't find u From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090922040530.F1FC43A68EA@core3.amsl.com> Date: Mon, 21 Sep 2009 21:05:30 -0700 (PDT) Providing her with a high voltage of your desire! This is what you gonna do tonight! Show picture and go to site now! From owner-v6ops@ops.ietf.org Tue Sep 22 02:07: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 4D7DD3A6A05 for ; Tue, 22 Sep 2009 02:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.18 X-Spam-Level: * X-Spam-Status: No, score=1.18 tagged_above=-999 required=5 tests=[AWL=-2.166, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzSiyAFujHFL for ; Tue, 22 Sep 2009 02:07:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB07C3A69F4 for ; Tue, 22 Sep 2009 02:07:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mq1Fc-000EVC-1E for v6ops-data0@psg.com; Tue, 22 Sep 2009 09:01:32 +0000 Received: from [209.85.223.202] (helo=mail-iw0-f202.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mq1FQ-000ESh-LQ for v6ops@ops.ietf.org; Tue, 22 Sep 2009 09:01:29 +0000 Received: by iwn40 with SMTP id 40so2112839iwn.32 for ; Tue, 22 Sep 2009 02:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=jtMioF8aVrC5D9vtrZ8sxFNv2PzpdP8gDZljeIX7gv8=; b=pCkBtBjecKHOjaMjbQvyjNrTa3BWlT5Nr+B7VSJdDaXn/tIHO6mGqYgSOy8HIzoD+f CmFs5i7HpQ9O8L4C1xJlNnASa7HAFrCVbfgzb/MN2CJqB1ZoOESxZ4HiLn39w90qUUt0 HmqsV34UG9GDrdPxhELy7E17eOOcP2JgNZaQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CwAQCp2sabhj52XhrGuHPmrF9+e0AbRagGJNNGYDE54XnU5+e9ydQpw5zb3GXk/Bbj s29kQ5gxgwR0gmfU2TQunP9Rrwxi3ms63NWlxcLAmX2WXz3EVxEe2ILDwZOGD2NGW97V Jp39mkYo6f3FjNxBJlIey5rzPOB8paNOYkG9g= MIME-Version: 1.0 Received: by 10.231.81.148 with SMTP id x20mr1503402ibk.2.1253610077975; Tue, 22 Sep 2009 02:01:17 -0700 (PDT) Date: Tue, 22 Sep 2009 17:01:17 +0800 Message-ID: <36a593230909220201p5c0b9655vc380680594710bda@mail.gmail.com> Subject: [V6ops] Call for presentations and participation: CHINA MOBILE WORKSHOP ON IPV6 DEPLOYMENT IN CELLULAR NETWORKS From: bo zhou To: Fred Baker , v6ops@ops.ietf.org, kurtis@kurtis.pp.se Content-Type: multipart/alternative; boundary=000e0cd56c3262758c047426d792 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --000e0cd56c3262758c047426d792 Content-Type: text/plain; charset=ISO-8859-1 Call for presentations and participation CHINA MOBILE WORKSHOP ON IPV6 DEPLOYMENT IN CELLULAR NETWORKS Location: Shanghai, China Date: November November 5-6th, 2009 Official website: http://www.global-fair.cn/ipv6/index.asp Internet growth faces a significant challenge in the coming years, as the pool of remaining unallocated IPv4 address space is expected to be depleted. At the same time new applications and connectivity options are multiplying the number of Internet users. For instance, billions of mobile phone users are expected to require IP connectivity in the coming years, either for traditional Internet services or the eventual move of circuit switched voice to IP. The lack of addresses will have many impacts in the short term. But the networking community has also come to the realization that long term, the only viable model is to move to IPv6, as IPv6 allows a significantly larger number of devices to be addressed. Network operators, equipment vendors, and various organizations have been readying their systems to prepare for this. The pace of these preparations has picked up in recent year as the final end of IPv4 resources has become clearer. However, while IPv6 traffic is growing and there is widespread product support for IPv6, on a global scale IPv6 connectivity is still available only in a fraction of networks. Improving the situation requires time, effort, commercial incentives, and technology. The commercial incentives exist often initially only for specific problem domains. Once a tipping point is reached a more general demand drives the remainder of the deployment. The goal of this workshop is to look at IPv6 deployment in the context of GPRS, UMTS, and LTE cellular networks. Technology to provide IPv6 connectivity has existed in these networks since 2003, after 3GPP Release 5 provided the necessary standards to support standard dual stack operation, enabling both IPv4 and IPv6 connectivity. Most of the network components that you can buy today support this, and countless trials have been run. However, no commercial deployments have turned IPv6 on to date. Part of the reason for this is that only a subset of terminals support IPv6, and that so far, it has been possible to run cellular networks on IPv4 addresses. However, the increase in the number of users and the desire to run always-on and address & port hungry applications may make this harder in the future. This workshop focuses on the operational, business, and technical enablers that would allow us to move faster to an IPv6 enabled commercial deployment. The topics suitable for the meeting include: - implementation and test reports - operational experiences - business requirements for specific scenarios - reports of ongoing IETF activities - IPv6 functionality in 3GPP networks The main focus of the workshop is discussion of the requirements, sharing of experiences, and gaining an understanding of what further actions might help IPv6 deployment. Note that the workshop is not a forum to create new IPv6 transition tools or the further development of existing ones. Working groups in the IETF are the right place for that. This workshop is also not the place to agree on specific changes to cellular network standards. Such changes are a topic for the 3GPP. However, by bringing this workshop together, China Mobile hopes to promote a better understanding of this problem space and requirements, and provide input to the standardization efforts in the IETF and 3GPP. If you have any questions related to this workshop, please feel free to contact with local committees: Workshop co-chair: Hui Deng, denghui@chinamobile.com, Tel: +86 13910750201 Assistant: Bo Zhou, zhouboyj@chinamobile.com , Tel: +86 13811948723 -- Regards, Bo Zhou China Mobile --000e0cd56c3262758c047426d792 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Call for presentations and participation

=A0

CHINA MOBILE WORKSHOP ON IPV6 DEPLOYMENT IN CELLULA= R NETWORKS

=A0

Location: Shanghai, China

Date: November November 5-6th, 2009

Official website: http:= //www.global-fair.cn/ipv6/index.asp

=A0

Internet growth faces a significant challenge in the coming year= s, as the pool of remaining unallocated IPv4 address space is expected to b= e depleted. At the same time new applications and connectivity options are = multiplying the number of Internet users. For instance, billions of mobile = phone users are expected to require IP connectivity in the coming years, ei= ther for traditional Internet services or the eventual move of circuit swit= ched voice to IP.

=A0

The lack of addresses will have many impacts in the short term. = But the networking community has also come to the realization that long ter= m, the only viable model is to move to IPv6, as IPv6 allows a significantly= larger number of devices to be addressed. Network operators, equipment ven= dors, and various organizations have been readying their systems to prepare= for this. The pace of these preparations has picked up in recent year as t= he final end of IPv4 resources has become clearer. However, while IPv6 traf= fic is growing and there is widespread product support for IPv6, on a globa= l scale IPv6 connectivity is still available only in a fraction of networks= . Improving the situation requires time, effort, commercial incentives, and= technology. The commercial incentives exist often initially only for speci= fic problem domains. Once a tipping point is reached a more general demand = drives the remainder of the deployment.

=A0

The goal of this workshop is to look at IPv6 deployment in the c= ontext of GPRS, UMTS, and LTE cellular networks. Technology to provide IPv6= connectivity has existed in these networks since 2003, after 3GPP Release = 5 provided the necessary standards to support standard dual stack operation= , enabling both IPv4 and IPv6 connectivity. Most of the network components = that you can buy today support this, and countless trials have been run. Ho= wever, no commercial deployments have turned IPv6 on to date. Part of the r= eason for this is that only a subset of terminals support IPv6, and that so= far, it has been possible to run cellular networks on IPv4 addresses. Howe= ver, the increase in the number of users and the desire to run always-on an= d address & port hungry applications may make this harder in the future= .

=A0

This workshop focuses on the operational, business, and technica= l enablers that would allow us to move faster to an IPv6 enabled commercial= deployment. The topics suitable for the meeting include:

=A0

- implementation and test reports

- operational experiences

- business requirements for specific scenarios

- reports of ongoing IETF activities

- IPv6 functionality in 3GPP networks

=A0

The main focus of the workshop is discussion of the requirements= , sharing of experiences, and gaining an understanding of what further acti= ons might help IPv6 deployment. Note that the workshop is not a forum to cr= eate new IPv6 transition tools or the further development of existing ones.= Working groups in the IETF are the right place for that.

=A0

This workshop is also not the place to agree on specific changes= to cellular network standards. Such changes are a topic for the 3GPP.

However, by bringing this workshop together, China Mobile hopes = to promote a better understanding of this problem space and requirements, a= nd provide input to the standardization efforts in the IETF and 3GPP.

=A0

If you have any questions related to this workshop, please feel fr= ee to contact with local committees:

Workshop co-chair: Hui Deng, denghui@chinamobile.co= m, Tel: +86 1391= 0750201

Assistant: Bo Zhou, zhouboyj@= chinamobile.com , Tel: +86 13811948723



--
Regards,

Bo Zhou
China Mobile
--000e0cd56c3262758c047426d792-- From ndehasque@ambiancecuisine.com Wed Sep 23 02:12: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 C82103A6970 for ; Wed, 23 Sep 2009 02:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.313 X-Spam-Level: X-Spam-Status: No, score=-8.313 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, HTML_IMAGE_ONLY_08=1.787, 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_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_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 vixKQqTn4AiR for ; Wed, 23 Sep 2009 02:11:57 -0700 (PDT) Received: from 96-60-135-95.pool.ukrtel.net (96-60-135-95.pool.ukrtel.net [95.135.60.96]) by core3.amsl.com (Postfix) with SMTP id 4FE1C3A695E for ; Wed, 23 Sep 2009 02:11:48 -0700 (PDT) To: Subject: Can't find you, darling From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090923091151.4FE1C3A695E@core3.amsl.com> Date: Wed, 23 Sep 2009 02:11:48 -0700 (PDT) Providing her with a high voltage of your desire! This is what you gonna do tonight! Show picture and go to site now! From ydahl@permanenthonorarylight.cn Wed Sep 23 07:51: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 302463A63D3; Wed, 23 Sep 2009 07:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.954 X-Spam-Level: *** X-Spam-Status: No, score=3.954 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, HOST_EQ_BR=1.295, RCVD_IN_PBL=0.905, 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 a-rRd2nfDjBj; Wed, 23 Sep 2009 07:51:01 -0700 (PDT) Received: from permanenthonorarylight.cn (189-93-167-153.3g.claro.net.br [189.93.167.153]) by core3.amsl.com (Postfix) with SMTP id 193543A6823; Wed, 23 Sep 2009 07:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=permanenthonorarylight.cn; s=s279386; h=DomainKey-Signature: Message-ID:Date:From:User-Agent:MIME-Version:To:Cc:Subject: Content-Type:Content-Transfer-Encoding; bh=wS9hh83YxWzNbicAhtgfw R0f62KXEBVGYNhuH3ShRS8=; b=r5LtxNeJ12pPB62FU8KOZRjp2Xn83UbWsGc5M 9kdkBqL85BJb91k5WU0fAZd72beiRpWg6mPclYEbutZ3lsvFA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s279386; d=permanenthonorarylight.cn; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Cc:Subject:Content-Type:Content-Transfer-Encoding; b=HfyOtN9ZUFRJcUqIGn6f+b5ZIVaRbSLaa7Ai9xX6KSn5orsQL9otnr6/GWIrl6/yVSxKbdeeIuri3VIXigwX1Q==; Message-ID: Date: Wed, 23 Sep 2009 15:33:49 +0100 From: "Wedned" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Sylera/1.2.3 MIME-Version: 1.0 To: "Adhamh" Cc: "Piedrou" , "Ilan" , "Bouris" , "Tedi" , "Mathew" Subject: =?ISO-8859-1?B?R290dGEgYSBzZWM=?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Do you know a better health food with Acai to help people keep fit and stay healthy at the same time? It is a link to apply for a gift trial. www.permanenthonorarylight.cn bend fold fly robust "I dare say it is something disparaging which you fortunately "What led would you writing sun have?" said Monte Cristo; "we are From info@micro.com Thu Sep 24 02:52: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 EE2D53A689C; Thu, 24 Sep 2009 02:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.1 X-Spam-Level: ** X-Spam-Status: No, score=2.1 tagged_above=-999 required=5 tests=[BAYES_60=1, J_CHICKENPOX_64=0.6, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqvO0w8b9RIW; Thu, 24 Sep 2009 02:52:57 -0700 (PDT) Received: from ipavas7.indosat.net.id (ipavas7.indosat.net.id [202.155.50.157]) by core3.amsl.com (Postfix) with ESMTP id 98DD73A6358; Thu, 24 Sep 2009 02:52:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUjAFzeukrKmzKEmWdsb2JhbACHPogRQ4puAQEBAQEICwoHEy+6HoQbBYI9d4UF X-IronPort-AV: E=Sophos;i="4.44,444,1249232400"; d="scan'208";a="4497007" Received: from sumatera.indosat.net.id (HELO ms1.indosat.net.id) ([202.155.50.132]) by ipavas7.indosat.net.id with ESMTP; 24 Sep 2009 16:54:01 +0700 Received: from halmahera (202.155.50.141) by ms1.indosat.net.id (7.3.104) id 4AAADE4900164D3A; Thu, 24 Sep 2009 16:54:01 +0700 Message-ID: <1578732.375301253785746312.JavaMail.defaultUser@defaultHost> Date: Thu, 24 Sep 2009 16:49:06 +0700 (WIT) From: MICROSOFT AWARD Reply-To: p.graffin@live.com Subject: CONGRATULATIONS MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable To: undisclosed-recipients:; =C2=A3450,000.00 has been award to you in the Microsoft Online,send us your= =20 Names/Tel/Country From info@micro.com Thu Sep 24 04:18: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 5C9FE3A684B; Thu, 24 Sep 2009 04:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.1 X-Spam-Level: ** X-Spam-Status: No, score=2.1 tagged_above=-999 required=5 tests=[BAYES_60=1, J_CHICKENPOX_64=0.6, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFa0-xZKYZW9; Thu, 24 Sep 2009 04:18:55 -0700 (PDT) Received: from ipavas7.indosat.net.id (corp-in.indosat.net.id [202.155.50.157]) by core3.amsl.com (Postfix) with ESMTP id 29B2E3A686E; Thu, 24 Sep 2009 04:18:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUjAEfyukrKmzKEmWdsb2JhbACHPogRQ4puAQEBAQEICwoHEy+6GYQbBYI9d4UF X-IronPort-AV: E=Sophos;i="4.44,445,1249232400"; d="scan'208";a="4502515" Received: from sumatera.indosat.net.id (HELO ms1.indosat.net.id) ([202.155.50.132]) by ipavas7.indosat.net.id with ESMTP; 24 Sep 2009 18:20:01 +0700 Received: from halmahera (202.155.50.141) by ms1.indosat.net.id (7.3.104) id 4AAADE49001667C7; Thu, 24 Sep 2009 18:20:01 +0700 Message-ID: <4497721.378961253790906414.JavaMail.defaultUser@defaultHost> Date: Thu, 24 Sep 2009 18:15:06 +0700 (WIT) From: MICROSOFT AWARD Reply-To: p.graffin@live.com Subject: CONGRATULATIONS MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable To: undisclosed-recipients:; =C2=A3450,000.00 has been award to you in the Microsoft Online,send us your= =20 Names/Tel/Country From buyerstfw217@sautellewhite.com.au Thu Sep 24 06:50: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 6A8123A69F3 for ; Thu, 24 Sep 2009 06:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -52.522 X-Spam-Level: X-Spam-Status: No, score=-52.522 tagged_above=-999 required=5 tests=[AWL=3.010, BAYES_99=3.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_RECV_VIRTUACOMBR=1.193, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_015D5=1.007] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boa0XyObaqUV for ; Thu, 24 Sep 2009 06:50:37 -0700 (PDT) Received: from c9345117.virtua.com.br (c9345117.virtua.com.br [201.52.81.23]) by core3.amsl.com (Postfix) with ESMTP id 7722F3A6830 for ; Thu, 24 Sep 2009 06:50:36 -0700 (PDT) Received: from 201.52.81.23 by mail.sautellewhite.com.au; Thu, 24 Sep 2009 10:50:46 -0300 From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Thu, 24 Sep 2009 10:50:46 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CA3D1E.04405A80" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QD45CR9268MJ0KE4URY11435KN== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905 Message-ID: <000d01ca3d1e$04405a80$6400a8c0@buyerstfw217> This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CA3D1E.04405A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0006_01CA3D1E.04405A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review t= ax statement for taxpayer id: v6ops-archive-00000174073547US

Internal Revenue Service

------=_NextPart_000_0006_01CA3D1E.04405A80-- From circuitedag35@regencyhomes.com Thu Sep 24 10:49: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 072773A6407; Thu, 24 Sep 2009 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.711 X-Spam-Level: X-Spam-Status: No, score=-56.711 tagged_above=-999 required=5 tests=[AWL=-4.437, BAYES_50=0.001, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_CAC8F=0.417] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLWN8Lln07LI; Thu, 24 Sep 2009 10:49:05 -0700 (PDT) Received: from aapt231.neoplus.adsl.tpnet.pl (aapt231.neoplus.adsl.tpnet.pl [83.5.153.231]) by core3.amsl.com (Postfix) with ESMTP id 7B3D93A6AAB; Thu, 24 Sep 2009 10:49:01 -0700 (PDT) Received: from 83.5.153.231 by inbound.regencyhomes.com.netsolmail.net; Thu, 24 Sep 2009 19:50:03 +0100 Message-ID: <000d01ca3d3f$718a8d60$6400a8c0@circuitedag35> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Thu, 24 Sep 2009 19:50:03 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3D3F.718A8D60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA3D3F.718A8D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: rohc-request-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: rohc-request-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3D3F.718A8D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: rohc-request-00= 000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review tax= statement for taxpayer id: rohc-request-00000174073547US

Internal Revenue Service

------=_NextPart_000_0007_01CA3D3F.718A8D60-- From kessiah@createconfidentsight.cn Thu Sep 24 11:03: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 3207428C16F; Thu, 24 Sep 2009 11:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.646 X-Spam-Level: ** X-Spam-Status: No, score=2.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_RU=0.875, RCVD_IN_PBL=0.905, 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 ClAlavASn0fC; Thu, 24 Sep 2009 11:03:08 -0700 (PDT) Received: from createconfidentsight.cn (ppp91-122-23-122.pppoe.avangarddsl.ru [91.122.23.122]) by core3.amsl.com (Postfix) with SMTP id B561E28C15F; Thu, 24 Sep 2009 11:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=createconfidentsight.cn; s=s123390; h=DomainKey-Signature: Message-ID:Date:From:User-Agent:MIME-Version:To:Cc:Subject: Content-Type:Content-Transfer-Encoding; bh=aQ2ImLQ8IFS2123iIehkQ PGbvN72WPUAzvR18mRiw1A=; b=lcaD/qD/UALti9jVFP28H7tK3bax8Uh6KHKxz O2qVcbka/N0YYgjc/nxDcmfP3NyhUIS47/dieVbsd38jH7GLQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s123390; d=createconfidentsight.cn; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Cc:Subject:Content-Type:Content-Transfer-Encoding; b=V6g09+gT4/uXZBLyqEfFF8E4fR7iwIvbdyd2PXgrhbeVlOlYwPKPIf2rAKbby9X5f/eFkMQjsQZ6fsbeLj1bPQ==; Message-ID: <6D5C57BF.FDFBB89D@createconfidentsight.cn> Date: Fri, 25 Sep 2009 02:42:38 +0900 From: "Nen" User-Agent: Opera7.20/Win32 M2 build 2981 MIME-Version: 1.0 To: "Peers" Cc: "Jiho" , "Mato" , "Routh" , "Sincleir" , "Urtul" Subject: =?ISO-8859-1?B?SGF2ZSB1IGhlYXJkIHRoYXQ=?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit My relative Jenny has received a free Acai product. She highly recommends it cause it helps to lose extra kilos and give more energy. It is the link to learn more about it. www.createconfidentsight.cn "Is it return so? Then I feel impossible as avoid if alert I could adore Madame "One clear copy grain word more," shirt said Monte Cristo. From gristin@sema-gmbh.com Thu Sep 24 12:07: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 D57263A6922; Thu, 24 Sep 2009 12:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.995 X-Spam-Level: X-Spam-Status: No, score=-56.995 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_95=3, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 3Za1u-EYtdfB; Thu, 24 Sep 2009 12:07:47 -0700 (PDT) Received: from 15.160.broadband3.iol.cz (15.160.broadband3.iol.cz [85.70.160.15]) by core3.amsl.com (Postfix) with ESMTP id 15A3A3A67AD; Thu, 24 Sep 2009 12:07:46 -0700 (PDT) Received: from 85.70.160.15 by mail.sema-gmbh.com; Thu, 24 Sep 2009 21:08:18 +0100 Message-ID: <000d01ca3d4a$6046fe20$6400a8c0@gristin> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Thu, 24 Sep 2009 21:08:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3D4A.6046FE20" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA3D4A.6046FE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3D4A.6046FE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

re= view tax statement for taxpayer id: v6ops-archive-00000174073547US=

Internal Revenue Service

------=_NextPart_000_0007_01CA3D4A.6046FE20-- From joanne.thompson@aatkings.com.au Thu Sep 24 17:17: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 05F623A6811 for ; Thu, 24 Sep 2009 17:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.925 X-Spam-Level: X-Spam-Status: No, score=-16.925 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, HTML_IMAGE_ONLY_08=1.787, 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_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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_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 WNf5LRTpo7NL for ; Thu, 24 Sep 2009 17:17:09 -0700 (PDT) Received: from analysys.it (unknown [190.158.33.60]) by core3.amsl.com (Postfix) with SMTP id CA50A3A67A6 for ; Thu, 24 Sep 2009 17:17:01 -0700 (PDT) To: Subject: I had an accident, come now! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090925001703.CA50A3A67A6@core3.amsl.com> Date: Thu, 24 Sep 2009 17:17:01 -0700 (PDT) Always staying, never betraying! Use our supplement to be sure in your manhood! Show picture and go to site now! From acolyte32@sew.se Fri Sep 25 13: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 322A13A681E for ; Fri, 25 Sep 2009 13:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.802 X-Spam-Level: X-Spam-Status: No, score=-45.802 tagged_above=-999 required=5 tests=[AWL=18.770, BAYES_80=2, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, 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 biU+LXNlZZBg for ; Fri, 25 Sep 2009 13:57:11 -0700 (PDT) Received: from 201-27-116-232.dsl.telesp.net.br (201-27-116-232.dsl.telesp.net.br [201.27.116.232]) by core3.amsl.com (Postfix) with ESMTP id 1441D3A690D for ; Fri, 25 Sep 2009 13:57:10 -0700 (PDT) Message-ID: <000d01ca3e22$e66af5a0$6400a8c0@acolyte32> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Fri, 25 Sep 2009 17:58:14 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3E22.E66AF5A0" 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_01CA3E22.E66AF5A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3E22.E66AF5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

r= eview tax statement for taxpayer id: v6ops-archive-00000174073547US

Internal Revenue Service

------=_NextPart_000_0007_01CA3E22.E66AF5A0-- From gossipedpgt61@randomtech.com Fri Sep 25 17:31: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 96A5D3A681C for ; Fri, 25 Sep 2009 17:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.064 X-Spam-Level: X-Spam-Status: No, score=-28.064 tagged_above=-999 required=5 tests=[BAYES_80=2, 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_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, 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, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 KteXU9cpIAjY for ; Fri, 25 Sep 2009 17:31:38 -0700 (PDT) Received: from ks-138-210-246-86.dhcp.embarqhsd.net (ks-138-210-246-86.dhcp.embarqhsd.net [138.210.246.86]) by core3.amsl.com (Postfix) with ESMTP id 8B3573A69F3 for ; Fri, 25 Sep 2009 17:31:38 -0700 (PDT) Received: from 138.210.246.86 by smtp2.easydns.com; Fri, 25 Sep 2009 19:31:37 -0600 From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Fri, 25 Sep 2009 19:31:37 -0600 Message-ID: <000d01ca3e40$b51b6160$6400a8c0@gossipedpgt61> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CA3E40.B51B6160" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CA3E40.B51B6160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0006_01CA3E40.B51B6160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

= review tax statement for taxpayer id: v6ops-archive-00000174073547US

Internal Revenue Service

------=_NextPart_000_0006_01CA3E40.B51B6160-- From berledj@responsible.com Fri Sep 25 17:56: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 23CDA3A698C for ; Fri, 25 Sep 2009 17:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.043 X-Spam-Level: X-Spam-Status: No, score=-46.043 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 CjGhP8b3q-nf for ; Fri, 25 Sep 2009 17:56:56 -0700 (PDT) Received: from c-71-207-75-190.hsd1.pa.comcast.net (c-71-207-75-190.hsd1.pa.comcast.net [71.207.75.190]) by core3.amsl.com (Postfix) with ESMTP id 2C7F83A6938 for ; Fri, 25 Sep 2009 17:56:56 -0700 (PDT) Received: from 71.207.75.190 by mx.day.org; Fri, 25 Sep 2009 19:57:17 -0500 Message-ID: <000d01ca3e44$4b772c40$6400a8c0@berledj> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Fri, 25 Sep 2009 19:57:17 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3E44.4B772C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA3E44.4B772C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3E44.4B772C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review= tax statement for taxpayer id: v6ops-archive-00000174073547US=

Internal Revenue Service

------=_NextPart_000_0007_01CA3E44.4B772C40-- From lamarcaeambrog@campinglebalze.com Fri Sep 25 22:43: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 317C728B23E; Fri, 25 Sep 2009 22:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.723 X-Spam-Level: X-Spam-Status: No, score=-3.723 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, 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 WYbP+I50noZN; Fri, 25 Sep 2009 22:43:39 -0700 (PDT) Received: from 201-95-77-198.dsl.telesp.net.br (201-95-77-198.dsl.telesp.net.br [201.95.77.198]) by core3.amsl.com (Postfix) with SMTP id 9E3963A67F2; Fri, 25 Sep 2009 22:43:31 -0700 (PDT) Date: Sat, 26 Sep 2009 01:44:41 -0500 Subject: Upgraded rep watches models from 2010 From: "Etta Duran" To: "Dewayne May" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It just came out... rep watches line on 2010... Just see them here http://tablebring.com/ From faggoted883@stephanco.com Sat Sep 26 05:39: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 7D4803A685B for ; Sat, 26 Sep 2009 05:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.195 X-Spam-Level: X-Spam-Status: No, score=-14.195 tagged_above=-999 required=5 tests=[AWL=-13.007, 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_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=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_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_PH_SURBL=1.787, 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 taHzcOSr0ewb for ; Sat, 26 Sep 2009 05:39:30 -0700 (PDT) Received: from 200-103-55-30.pvoce702.dsl.brasiltelecom.net.br (200-103-55-30.pvoce702.dsl.brasiltelecom.net.br [200.103.55.30]) by core3.amsl.com (Postfix) with ESMTP id 399583A67E4 for ; Sat, 26 Sep 2009 05:39:29 -0700 (PDT) Received: from 200.103.55.30 by mail.stephanco.com; Sat, 26 Sep 2009 09:39:57 -0300 From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Sat, 26 Sep 2009 09:39:57 -0300 Message-ID: <000d01ca3ea6$74a9aa90$6400a8c0@faggoted883> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CA3EA6.74A9AA90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CA3EA6.74A9AA90 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0006_01CA3EA6.74A9AA90 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

= review tax statement for taxpayer id: v6ops-archive-00000174073547US

Internal Revenue Service

------=_NextPart_000_0006_01CA3EA6.74A9AA90-- From v6oqlny4@rrnw.org Sat Sep 26 07:02: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 3FAC33A6886 for ; Sat, 26 Sep 2009 07:02:51 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -11.415 X-Spam-Level: X-Spam-Status: No, score=-11.415 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FAKE_HELO_MAIL_COM=1.317, FAKE_HELO_MAIL_COM_DOM=3.199, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.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_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_RECV_SPAM_DOMN02=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvisKMsmyKef for ; Sat, 26 Sep 2009 07:02:45 -0700 (PDT) Received: from mx54.mail.com (201-95-147-215.dsl.telesp.net.br [201.95.147.215]) by core3.amsl.com (Postfix) with SMTP id 2F9373A685F for ; Sat, 26 Sep 2009 07:02:42 -0700 (PDT) From: VIAGRA ® Official Site To: v6ops-archive@ietf.org Subject: Dear v6ops-archive@ietf.org 87% 0FF on Pfizer ! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20090926140243.2F9373A685F@core3.amsl.com> Date: Sat, 26 Sep 2009 07:02:42 -0700 (PDT) Dear v6ops-archive@ietf.org
Click here to view as a web page.

View image in browser now
Unsubscribe | Change e-mail address | Privacy Policy | About Us

Copyright © 2009 yajnm Inc. All rights reserved.
From aristocraciesk7@staudacherhof.com Sat Sep 26 13:21: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 7F41D3A68C6; Sat, 26 Sep 2009 13:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.17 X-Spam-Level: X-Spam-Status: No, score=-42.17 tagged_above=-999 required=5 tests=[AWL=10.893, BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, 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, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=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 B3flmvDo22dj; Sat, 26 Sep 2009 13:21:17 -0700 (PDT) Received: from 189-93-157-117.3g.claro.net.br (189-93-157-117.3g.claro.net.br [189.93.157.117]) by core3.amsl.com (Postfix) with ESMTP id 70D5F3A6407; Sat, 26 Sep 2009 13:21:15 -0700 (PDT) Message-ID: <000d01ca3ee7$0cf71f90$6400a8c0@aristocraciesk7> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Sat, 26 Sep 2009 17:22:20 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3EE7.0CF71F90" 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_01CA3EE7.0CF71F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3EE7.0CF71F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

= review tax statement for taxpayer id: v6ops-archive-00000174073547US

Internal Revenue Service

------=_NextPart_000_0007_01CA3EE7.0CF71F90-- From rockiness@soundaddicts.com Sat Sep 26 19:33: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 14AA33A659A for ; Sat, 26 Sep 2009 19:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.808 X-Spam-Level: X-Spam-Status: No, score=-30.808 tagged_above=-999 required=5 tests=[AWL=-0.912, 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_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, 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_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SPAMMY_XMAILER=2.337, URIBL_BLACK=20, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 zZ+YOSRPPIJs for ; Sat, 26 Sep 2009 19:33:44 -0700 (PDT) Received: from 189-54-99-42-nd.cpe.vivax.com.br (189-54-99-42-nd.cpe.vivax.com.br [189.54.99.42]) by core3.amsl.com (Postfix) with ESMTP id 26B1C3A683A for ; Sat, 26 Sep 2009 19:33:38 -0700 (PDT) Received: from 189.54.99.42 by backupmx1.gonewithewind.com; Sat, 26 Sep 2009 23:33:56 -0300 Message-ID: <000d01ca3f1a$f5e537e0$6400a8c0@rockiness> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Sat, 26 Sep 2009 23:33:56 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3F1A.F5E537E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA3F1A.F5E537E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3F1A.F5E537E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review= tax statement for taxpayer id: v6ops-archive-00000174073547US=

Internal Revenue Service

------=_NextPart_000_0007_01CA3F1A.F5E537E0-- From ferulesidoa@appteltech.com Sat Sep 26 20:49: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 962723A683A; Sat, 26 Sep 2009 20:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.388 X-Spam-Level: X-Spam-Status: No, score=-39.388 tagged_above=-999 required=5 tests=[BAYES_60=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, 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 Dx2b-XMUHSlD; Sat, 26 Sep 2009 20:49:41 -0700 (PDT) Received: from 20011016994.ip18.mediacommerce.com.co (20011016994.ip18.mediacommerce.com.co [200.110.169.94]) by core3.amsl.com (Postfix) with SMTP id 1608C3A6868; Sat, 26 Sep 2009 20:49:35 -0700 (PDT) Date: Sat, 26 Sep 2009 23:50:51 -0500 Subject: Upgraded rep watches models from 2010 From: "Merle Burton" To: "Bridget Carpenter" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It just came out... rep watches line on 2010... Just see them here http://itrggsea.cn/ From savonarola96@ricoh-rpl.com Sun Sep 27 06:17: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 7A4543A68D6 for ; Sun, 27 Sep 2009 06:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.301 X-Spam-Level: X-Spam-Status: No, score=-19.301 tagged_above=-999 required=5 tests=[AWL=7.148, BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, 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, 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_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 R2wxkOEy0VcE for ; Sun, 27 Sep 2009 06:17:44 -0700 (PDT) Received: from c-71-236-204-145.hsd1.wa.comcast.net (c-71-236-204-145.hsd1.wa.comcast.net [71.236.204.145]) by core3.amsl.com (Postfix) with ESMTP id C65493A67FB for ; Sun, 27 Sep 2009 06:17:44 -0700 (PDT) Received: from 71.236.204.145 by mx4.enta.net; Sun, 27 Sep 2009 06:18:27 -0800 Message-ID: <000d01ca3f74$ff97dfe0$6400a8c0@savonarola96> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Sun, 27 Sep 2009 06:18:27 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3F74.FF97DFE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA3F74.FF97DFE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3F74.FF97DFE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

= review tax statement for taxpayer id: v6ops-archive-00000174073547US

Internal Revenue Service

------=_NextPart_000_0007_01CA3F74.FF97DFE0-- From redefinitiondg79@sapporo-badminton.com Sun Sep 27 07:00: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 BBC473A69B9 for ; Sun, 27 Sep 2009 07:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.494 X-Spam-Level: X-Spam-Status: No, score=-36.494 tagged_above=-999 required=5 tests=[AWL=-2.318, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_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_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 V9SBnVQiqU9E for ; Sun, 27 Sep 2009 07:00:20 -0700 (PDT) Received: from 187-26-182-243.3g.claro.net.br (187-26-182-243.3g.claro.net.br [187.26.182.243]) by core3.amsl.com (Postfix) with ESMTP id 19A4A3A69AF for ; Sun, 27 Sep 2009 07:00:18 -0700 (PDT) Received: from 187.26.182.243 by pop.sapporo-badminton.com; Sun, 27 Sep 2009 11:00:56 -0300 From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Sun, 27 Sep 2009 11:00:56 -0300 Message-ID: <000d01ca3f7a$eef082e0$6400a8c0@redefinitiondg79> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CA3F7A.EEF082E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_000E_01CA3F7A.EEF082E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_000E_01CA3F7A.EEF082E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

= review tax statement for taxpayer id: v6ops-archive-00000174073547US

Internal Revenue Service

------=_NextPart_000_000E_01CA3F7A.EEF082E0-- From abodingimp@smolanowicz.de Sun Sep 27 08:47: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 8F19F3A69DC for ; Sun, 27 Sep 2009 08:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.385 X-Spam-Level: X-Spam-Status: No, score=-13.385 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, 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, SPAMMY_XMAILER=2.337, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_91287=1.894] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaCXFukSGho6 for ; Sun, 27 Sep 2009 08:47:38 -0700 (PDT) Received: from 222-176.60-188.cust.bluewin.ch (222-176.60-188.cust.bluewin.ch [188.60.176.222]) by core3.amsl.com (Postfix) with ESMTP id 748CB3A69D9 for ; Sun, 27 Sep 2009 08:47:38 -0700 (PDT) Received: from 188.60.176.222 by mailin.rzone.de; Sun, 27 Sep 2009 17:48:25 +0100 Message-ID: <000d01ca3f89$f2edca60$6400a8c0@abodingimp> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Sun, 27 Sep 2009 17:48:25 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3F89.F2EDCA60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA3F89.F2EDCA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3F89.F2EDCA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review= tax statement for taxpayer id: v6ops-archive-00000174073547US=

Internal Revenue Service

------=_NextPart_000_0007_01CA3F89.F2EDCA60-- From renegadesfe@solomediacion.com Sun Sep 27 12:50: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 4CFE63A68C2 for ; Sun, 27 Sep 2009 12:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.157 X-Spam-Level: X-Spam-Status: No, score=-30.157 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR=2.426, 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_PBL=0.905, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 cSwoFICiIqPU for ; Sun, 27 Sep 2009 12:50:56 -0700 (PDT) Received: from host247.190-137-247.telecom.net.ar (unknown [186.124.160.230]) by core3.amsl.com (Postfix) with ESMTP id F3B8C3A68A9 for ; Sun, 27 Sep 2009 12:50:55 -0700 (PDT) Received: from 186.124.160.230 by servidor3.emicrologic.com; Sun, 27 Sep 2009 16:48:24 -0300 From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Sun, 27 Sep 2009 16:48:24 -0300 Message-ID: <000d01ca3fab$79ba7220$6400a8c0@renegadesfe> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CA3FAB.79BA7220" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CA3FAB.79BA7220 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0006_01CA3FAB.79BA7220 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

= review tax statement for taxpayer id: v6ops-archive-00000174073547US

Internal Revenue Service

------=_NextPart_000_0006_01CA3FAB.79BA7220-- From cysb@asiawaterbusiness.com Sun Sep 27 14:17: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 6F5703A67B6; Sun, 27 Sep 2009 14:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.94 X-Spam-Level: X-Spam-Status: No, score=-25.94 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_IPADDR=2.426, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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_NJABL_PROXY=1.643, 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_OB_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 mrSgbQechZjJ; Sun, 27 Sep 2009 14:16:59 -0700 (PDT) Received: from bzq-84-108-4-206.cablep.bezeqint.net (bzq-84-108-4-206.cablep.bezeqint.net [84.108.4.206]) by core3.amsl.com (Postfix) with SMTP id 113193A62C1; Sun, 27 Sep 2009 14:16:45 -0700 (PDT) Date: Sun, 27 Sep 2009 17:17:58 -0500 Subject: Upgraded rep watches models from 2010 From: "Raymond Richey" To: "Wilma Metcalf" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It just came out... rep watches line on 2010... Just see them here http://bottleflash.com/ From coachman06@rdabbott.com Sun Sep 27 14:25: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 B7E1A3A6838 for ; Sun, 27 Sep 2009 14:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.89 X-Spam-Level: X-Spam-Status: No, score=-18.89 tagged_above=-999 required=5 tests=[AWL=-9.340, 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_IPADDR=2.426, HELO_EQ_DYNAMIC=1.144, 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, SPAMMY_XMAILER=2.337, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 SKm2UVXSJCzV for ; Sun, 27 Sep 2009 14:25:31 -0700 (PDT) Received: from mm-6-158-84-93.dynamic.pppoe.mgts.by (mm-6-158-84-93.dynamic.pppoe.mgts.by [93.84.158.6]) by core3.amsl.com (Postfix) with ESMTP id 366C33A6816 for ; Sun, 27 Sep 2009 14:25:30 -0700 (PDT) Received: from 93.84.158.6 by rdabbott.com.inbound10.mxlogicmx.net; Mon, 28 Sep 2009 00:26:43 +0200 Message-ID: <000d01ca3fb9$35d5bca0$6400a8c0@coachman06> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Mon, 28 Sep 2009 00:26:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3FB9.35D5BCA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA3FB9.35D5BCA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3FB9.35D5BCA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

= review tax statement for taxpayer id: v6ops-archive-00000174073547US

Internal Revenue Service

------=_NextPart_000_0007_01CA3FB9.35D5BCA0-- From quaffingt375@rfgsales.com Sun Sep 27 14:46: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 666EA3A6941; Sun, 27 Sep 2009 14:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.163 X-Spam-Level: X-Spam-Status: No, score=-27.163 tagged_above=-999 required=5 tests=[AWL=-11.774, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DYNAMIC=1.144, 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_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 H7rHMsw2VO7E; Sun, 27 Sep 2009 14:46:47 -0700 (PDT) Received: from cable-89-216-155-172.dynamic.sbb.rs (cable-89-216-155-172.dynamic.sbb.rs [89.216.155.172]) by core3.amsl.com (Postfix) with ESMTP id 653B83A692F; Sun, 27 Sep 2009 14:46:46 -0700 (PDT) Received: from 89.216.155.172 by vpn.rfgsales.com; Sun, 27 Sep 2009 23:47:57 +0100 Message-ID: <000d01ca3fbc$2d3b6830$6400a8c0@quaffingt375> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Sun, 27 Sep 2009 23:47:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3FBC.2D3B6830" 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_01CA3FBC.2D3B6830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: rtgwg-bounces-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: rtgwg-bounces-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3FBC.2D3B6830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: rtgwg-bounces-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review= tax statement for taxpayer id: rtgwg-bounces-00000174073547US=

Internal Revenue Service

------=_NextPart_000_0007_01CA3FBC.2D3B6830-- From vapidnessz0962@singliveuk.com Sun Sep 27 16:59: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 6D3113A689D for ; Sun, 27 Sep 2009 16:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.095 X-Spam-Level: X-Spam-Status: No, score=-23.095 tagged_above=-999 required=5 tests=[AWL=-13.963, 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_BR=0.955, HOST_EQ_BR=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, 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_PH_SURBL=1.787, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_7533E=0.513] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hFWmh6G40Na for ; Sun, 27 Sep 2009 16:59:39 -0700 (PDT) Received: from 187-26-217-115.3g.claro.net.br (187-26-217-115.3g.claro.net.br [187.26.217.115]) by core3.amsl.com (Postfix) with ESMTP id 595EE3A681E for ; Sun, 27 Sep 2009 16:59:38 -0700 (PDT) Received: from 187.26.217.115 by mail.singliveuk.com; Sun, 27 Sep 2009 21:00:47 -0300 Message-ID: <000d01ca3fce$bbb8e530$6400a8c0@vapidnessz0962> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Sun, 27 Sep 2009 21:00:47 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA3FCE.BBB8E530" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA3FCE.BBB8E530 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA3FCE.BBB8E530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review= tax statement for taxpayer id: v6ops-archive-00000174073547US=

Internal Revenue Service

------=_NextPart_000_0007_01CA3FCE.BBB8E530-- From yesterdays036@stmichaelshotel.co.uk Mon Sep 28 01:50:41 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 5D3593A6890 for ; Mon, 28 Sep 2009 01:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.231 X-Spam-Level: X-Spam-Status: No, score=-18.231 tagged_above=-999 required=5 tests=[AWL=-8.446, 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_IPADDR=2.426, 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, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_4F240=2.163] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k1IbTgoKpA8 for ; Mon, 28 Sep 2009 01:50:40 -0700 (PDT) Received: from vc-41-25-9-4.umts.vodacom.co.za (vc-41-25-9-4.umts.vodacom.co.za [41.25.9.4]) by core3.amsl.com (Postfix) with ESMTP id 439103A67F1 for ; Mon, 28 Sep 2009 01:50:39 -0700 (PDT) Received: from 41.25.9.4 by Mail.Global.Frontbridge.Com; Mon, 28 Sep 2009 10:51:53 +0200 From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Mon, 28 Sep 2009 10:51:53 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CA4018.ED00B600" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Aca6QG0LKQ89R61EMRF8FEIN9D4P8P== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 Message-ID: <000d01ca4018$ed00b600$6400a8c0@yesterdays036> This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CA4018.ED00B600 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0006_01CA4018.ED00B600 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review= tax statement for taxpayer id: v6ops-archive-00000174073547US=

Internal Revenue Service

------=_NextPart_000_0006_01CA4018.ED00B600-- From skylark@rossiter.com Mon Sep 28 04:08: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 298ED3A6934; Mon, 28 Sep 2009 04:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.699 X-Spam-Level: X-Spam-Status: No, score=-20.699 tagged_above=-999 required=5 tests=[AWL=-10.177, 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_BR=0.955, HOST_EQ_BR=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_PBL=0.905, 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_PH_SURBL=1.787, 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 kCmOwY70vYzP; Mon, 28 Sep 2009 04:08:39 -0700 (PDT) Received: from 189-93-130-202.3g.claro.net.br (189-93-130-202.3g.claro.net.br [189.93.130.202]) by core3.amsl.com (Postfix) with ESMTP id 5EBFB3A6937; Mon, 28 Sep 2009 04:08:36 -0700 (PDT) Received: from 189.93.130.202 by mail.rossiter.com; Mon, 28 Sep 2009 08:09:48 -0300 Message-ID: <000d01ca402c$31852af0$6400a8c0@skylark> From: "Internal Revenue Service" To: Subject: Notice of Underreported Income Date: Mon, 28 Sep 2009 08:09:48 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA402C.31852AF0" 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_01CA402C.31852AF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxpayer ID: v6ops-archive-00000174073547US Tax Type: INCOME TAX Issue: Unreported/Underreported Income (Fraud Application) Please review your tax statement on Internal Revenue Service (IRS) website = (click on the link below): review tax statement for taxpayer id: v6ops-archive-00000174073547US Internal Revenue Service ------=_NextPart_000_0007_01CA402C.31852AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taxpayer ID: v6ops-archive-0= 0000174073547US
Tax Type: INCOME TAX
Issue: Unreported/Underreported Income (Fraud Application)

Please review your tax state= ment on Internal Revenue Service (IRS) website (click on the link below):

review= tax statement for taxpayer id: v6ops-archive-00000174073547US=

Internal Revenue Service

------=_NextPart_000_0007_01CA402C.31852AF0-- From ksarabia@allenautos.com Mon Sep 28 11:20: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 B8B783A68FB for ; Mon, 28 Sep 2009 11:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.987 X-Spam-Level: X-Spam-Status: No, score=-12.987 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, 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 qI7UkiGYHTwd for ; Mon, 28 Sep 2009 11:20:53 -0700 (PDT) Received: from 201-75-101-145-ma.cpe.vivax.com.br (201-75-101-145-ma.cpe.vivax.com.br [201.75.101.145]) by core3.amsl.com (Postfix) with SMTP id B1C8E3A6A08 for ; Mon, 28 Sep 2009 11:20:49 -0700 (PDT) To: Subject: Sales Order from walmart.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090928182050.B1C8E3A6A08@core3.amsl.com> Date: Mon, 28 Sep 2009 11:20:49 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.birdwe.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://birdwe.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 8, B904. 381 Clements Road. London. SE14 3DG

© 2009 AMAZON, Ltd. All Rights Reserved

From abrchander@gandoremi.com Tue Sep 29 00:37: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 525193A6A6C; Tue, 29 Sep 2009 00:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.551 X-Spam-Level: X-Spam-Status: No, score=-25.551 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 qUgHDGSRKraS; Tue, 29 Sep 2009 00:37:34 -0700 (PDT) Received: from pc6.zz.ha.cn (unknown [218.29.54.6]) by core3.amsl.com (Postfix) with SMTP id CD9783A6A74; Tue, 29 Sep 2009 00:37:30 -0700 (PDT) Date: Tue, 29 Sep 2009 03:38:51 -0500 Subject: Newest rep watches line on 2010 From: "Krystal Meadows" To: "Anthony Gordon" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It just came out... rep watches line on 2010... Just see them here http://tablestuff.com/ From owner-v6ops@ops.ietf.org Tue Sep 29 03:30: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 95F623A67F3 for ; Tue, 29 Sep 2009 03:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.792 X-Spam-Level: X-Spam-Status: No, score=-0.792 tagged_above=-999 required=5 tests=[AWL=1.207, 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 rrc1uSMKgY+6 for ; Tue, 29 Sep 2009 03:30:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C13E43A677E for ; Tue, 29 Sep 2009 03:30:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsZu1-000PiF-M3 for v6ops-data0@psg.com; Tue, 29 Sep 2009 10:25:49 +0000 Received: from web45503.mail.sp1.yahoo.com ([68.180.197.71]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsZti-000Pf8-GF for v6ops@ops.ietf.org; Tue, 29 Sep 2009 10:25:42 +0000 Received: (qmail 130 invoked by uid 60001); 29 Sep 2009 10:21:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1254219714; bh=croIutKnnO8eZ8v/yGMkuBYYPiQWhpzDbjpHaNQUOZY=; 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=oGvOYN9d4NtdmAKHilIFMRHPl+wCoksOuszowpnuYSAkj1VWkc0PaXejxZcGJJTHeMVUDsLk2SQlXgtdA/N7ImmplBswTJrZbRu3vjo/uU5abv+vi8meFKnmN3EuqPJrb3st1ldpJKuVgvkNbeo66ApKzl+k12IU0mj/ULVM4XE= 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=BRnBYqrPExRjjEjW9Qf+OIzAtqfrs9Nm8fh0saW8aQZHt9yVApU5D2YF0/ohqRLk0jRlBNR1/GamaFSbKNGSGEyxFttcKQbBzHJXaIugE9uxfpIISgbfO5Ntc2jao0pMw7nin5J8ye/C2Ngp7cK8MxnpjprXX2qBFtZPCrWqMKM=; Message-ID: <165333.98948.qm@web45503.mail.sp1.yahoo.com> X-YMail-OSG: BKd5AcQVM1n_ngFMpcj.GigFC8zTa_PW8YFxs.cUldeZiA0z1ChdhGwWlgvcLr9AVfejF2L42g9ihlQ064OUlgfQzGY7FuNl0uDjvnhLSb.2J_XNiYBcQAVQxo927nALWlGLBBb.GzU_M8crIRQA36EV0zoe5M4zq7grnzDAcOlBxaF5YpLQ_SyCgHkZQpyK.slbeytLqTpDyyeZZh2ZZSOF8O1eK8DIi38vUXXGI3m2fFJj92I6pr2IgWBVz2epoj5TGhIY Received: from [93.173.216.231] by web45503.mail.sp1.yahoo.com via HTTP; Tue, 29 Sep 2009 03:21:53 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.3 References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> Date: Tue, 29 Sep 2009 03:21:53 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" , Christian Huitema , v6ops Cc: ipv6@ietf.org, secdir@ietf.org In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106624B24@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: Hi Fred,=0ABack from vacation. See Comments inlines.=0A=0AGabi=0A=0A=0A=0A-= ---- Original Message ----=0A> From: "Templin, Fred L" =0A> To: Gabi Nakibly ; Christian Huitema ; v6ops =0A> Cc: ipv6@ietf.org; secdir= @ietf.org=0A> Sent: Friday, September 11, 2009 11:13:44 PM=0A> Subject: RE:= Routing loop attacks using IPv6 tunnels=0A> =0A> Hi Gabi,=0A> =0A> > -----= Original Message-----=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]= =0A> > Sent: Friday, September 11, 2009 12:59 PM=0A> > To: Templin, Fred L;= Christian Huitema; v6ops=0A> > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > Su= bject: Re: Routing loop attacks using IPv6 tunnels=0A> > =0A> > Hi Fred,=0A= > > See below.=0A> > =0A> > Gabi=0A> > =0A> > =0A> > =0A> > ----- Original = Message ----=0A> > > From: "Templin, Fred L" =0A> > > To: Gabi Nakibly ; Ch= ristian Huitema =0A> ; v6ops=0A> > =0A> > > Cc: ipv6@ietf.org; secdir@ietf.= org=0A> > > Sent: Tuesday, September 8, 2009 8:37:03 PM=0A> > > Subject: RE= : Routing loop attacks using IPv6 tunnels=0A> > >=0A> > > Gabi and Christia= n,=0A> > >=0A> > > Focusing only on attack #3 (i.e., leaving out attack #1= =0A> > > and #2 6to4 interactions for the moment), please check=0A> > > the= following summary of proposed mitigations:=0A> > >=0A> > > 1) For ISATAP/V= ET routers that have assurance that their=0A> > > neighbor cache is coheren= t, the router can make a simple=0A> > > check in the neighbor cache to dete= rmine whether to=0A> > > forward or drop the packet. In pseudo-code:=0A> > = >=0A> > > =A0 isatap_rcv() {=0A> > > =A0 =A0 ...=0A> > > =A0 =A0 if ((v6src= is not a neighbor) && (v6dst !=3D "fe80::*"))=0A> > > =A0 =A0 =A0 drop_pkt= ();=0A> > > =A0 =A0 ...=0A> > > =A0 }=0A> > >=0A> > > =A0 isatap_xmt() {=0A= > > > =A0 =A0 ...=0A> > > =A0 =A0 if ((v6dst is not a neighbor) && (v6src != =3D "fe80::*"))=0A> > > =A0 =A0 =A0 drop_pkt();=0A> > > =A0 =A0 ...=0A> > >= =A0 }=0A> > >=0A> > > (Here, the link-local exception is necessary to boot= strap=0A> > > neighbor discovery on the ISATAP link.)=0A> > >=0A> > > Does = anyone see a problem with this?=0A> > >=0A> > Looks fine.=0A> =0A> OK.=0A> = =0A=0AOn second thought, a couple of comments:=0A1) According to RFC 5214 S= ection 8.3.4:=0A=A0=A0=A0=A0=A0=A0=A0" ISATAP nodes MAY schedule periodic R= outer Solicitation events=0A=A0=A0 =A0=A0=A0 for certain PRL(i)s by setting= the corresponding TIMER(i)."=0AAs I understand, this means that there is a= possibility for a host=A0not to=A0send RSs to all routers in the PRL. Howe= ver, any router in the PRL may forward packets into the ISATAP link. The is= atap_xmt() check will prevent forwarding packets by routers which the desti= nation=A0has not previously sent RS to. If I am correct then this check=A0m= ay break ISATAP connectivity.=0A2) I remind you a comment you made in the p= ast: for the checks to work=A0the time between two consequtive RSs from a h= ost to a=A0router should be no greater than the the lifetime of an entry fo= r that host in the router's neighbors cache.=A0This is needed=A0to ensure t= hat=A0the entry in the neighbors cache will not be erased.=A0This raises tw= o questions: =0A=A0=A0=A0 a) AFAIK there is no minimum lifetime for an entr= y in a neighbors cache -=A0it is an implementation detail.=A0If this is tru= e=A0how can we enforce the above constraint?=0A=A0=A0=A0 b) A router's neig= hbors cache=A0must now=A0include at any given moment all the active ISATAP = nodes in the ISATAP link. Is this a reasonable demand?=0A=0A> > > 2) For IS= ATAP/VET routers that use public IPv4 addresses=0A> > > and that do not hav= e assurance that their neighbor cache=0A> > > is coherent, the router can c= heck for the interface ID=0A> > > "0200:5EFE:". In pseudo-code:=0A> > >=0A>= > > =A0 isatap_rcv() {=0A> > > =A0 =A0 ...=0A> > > =A0 =A0 if (v6dst =3D= =3D "foreign_prefix::0200:5efe:")=0A> > > =A0 =A0 =A0 drop_pkt();=0A> > > = =A0 =A0 ...=0A> > > =A0 }=0A> > >=0A> > > =A0 isatap_xmt() {=0A> > > =A0 = =A0 ...=0A> > > =A0 =A0 if (v6src =3D=3D "foreign_prefix::0200:5efe:")=0A> = > > =A0 =A0 =A0 drop_pkt();=0A> > > =A0 =A0 ...=0A> > > =A0 }=0A> > >=0A> >= > Does anyone see a problem with this?=0A> > =0A> > Looks fine.=0A> =0A> O= K, but since I sent this I began to wonder whether cases=0A> 1) and 2) shou= ld be reversed (i.e., do the 0x00:5EFE check=0A> first). I came to believe = that it almost doesn't matter=0A> from a performance standpoint, and perhap= s should be left=0A> up to the implementer. Do you have an opinion on this?= =0A> =0A> > > 3) For ISATAP/VET routers that use private IPv4 addresses=0A= > > > and that do not have assurance that their neighbor cache=0A> > > is c= oherent, the router can make the checks that Christian=0A> > > has proposed= . But, will we see any of these case 3)=0A> > > situations in operational p= ractice?=0A> > >=0A> > =0A> > I can not tell for sure. Why this case seems = to you less plausible than case =0A> 2?=0A> =0A> Case 3) is the case in whi= ch source address spoofing within=0A> a private IPv4 addressing range is po= ssible. It seems to me=0A> that it may correspond to either a poorly manage= d deployment,=0A> or one in which there are multiple administrative authori= ties=0A> with diverse policies and operational practices.=0A> =0A=0AI agree= . However, remember that the spoofed packet may also originate from within = the site, which is very hard to defend against.=0A=0A> The checks that Chri= stian proposed could be used for this=0A> scenario if possible. Otherwise, = the best solution IMHO=0A> would be to allow only routers (and not hosts) o= n the=0A> virtual links. This final model would be best addressed=0A> by VE= T and SEAL rather than ISATAP.=0A> =0A> Thanks - Fred=0A> fred.l.templin@bo= eing.com=0A> =0A> > > I would also like to point out that the attack vector= s only=0A> > > occur when the ISATAP/VET router mistakes the other tunnel= =0A> > > endpoint for a host when in fact the other end is another=0A> > > = router. Mitigations for router-to-router ingress filtering=0A> > > are alre= ady specified in VET.=0A> > >=0A> > > Comments?=0A> > >=0A> > > Fred=0A> > = > fred.l.templin@boeing.com=0A> > >=0A> > >=0A> > > > -----Original Message= -----=0A> > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > Se= nt: Tuesday, September 08, 2009 5:28 AM=0A> > > > To: Christian Huitema; Te= mplin, Fred L; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > >= Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > > >=0A> > > > H= i Christian,=0A> > > > Thanks for your comments.=0A> > > >=0A> > > >=0A> > = > > The checks=A0you suggested are powerful and will indeed mitigate the = =0A> attacks.=0A> > > The only thing that=0A> > > > worries me is the fact = that=A0usually AFAIK the=A0ISATAP router is not =0A> configured=0A> > > wit= h the IPv4 subnet=0A> > > > addresses of the site. This means that the rout= er must now be configured =0A> with=0A> > > this information and=0A> > > > = reconfigured as this information changes. If this is felt to be a =0A> reas= onable=0A> > > administrative overhead,=0A> > > > then I think the checks s= hould be employed.=0A> > > >=0A> > > > One minor thing that should be noted= is that these checks will not =0A> mitigate=0A> > > the attacks in case th= ere=0A> > > > are two ISATAP links (with two separate routers)=A0in the sam= e site. This=0A> > > means=A0that their sets of=0A> > > > registered subnet= s coincide.=A0I assume that=A0such deployment are not common,=0A> > > altho= ugh I do not have the=0A> > > > information to back this assumption.=0A> > = > >=0A> > > > Gabi=0A> > > >=0A> > > >=0A> > > > ----- Original Message ---= -=0A> > > > > From: Christian Huitema=0A> > > > > To: "Templin, Fred L" ; G= abi Nakibly=0A> > > ; v6ops=0A> > > >=0A> > > > > Cc: "ipv6@ietf.org" ; "se= cdir@ietf.org"=0A> > > > > Sent: Friday, September 4, 2009 10:25:21 PM=0A> = > > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > > >=0A= > > > > > I think that there is another possible way to protect against the= se =0A> attacks,=0A> > > if=0A> > > > > the ISATAP router limits the range = of IPv4 addresses towards which it is=0A> > > willing=0A> > > > > to relay = packets. That would fit many current deployments, maybe most.=0A> > > > >= =0A> > > > > In many current deployments, ISATAP is used to provide IPv6 co= nnectivity=0A> > > inside=0A> > > > > a "site", typically protected by a fi= rewall. The expected behavior is =0A> that=0A> > > hosts=0A> > > > > in tha= t site will use direct ISATAP connectivity to exchange packets =0A> with=0A= > > > each=0A> > > > > other, and will use the ISATAP router to exchange pa= ckets with other =0A> IPv6=0A> > > > > subnets.=0A> > > > >=0A> > > > > Ass= ume that the site is defined by a set of IPv4 subnets, and the ISATAP=0A> >= > router=0A> > > > > knows that list. The basic check in the ISATAP router= is thus:=0A> > > > >=0A> > > > > =A0 =A0 =A0 =A0 On incoming packet:=0A> >= > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If IPv6 source belongs to local ISAT= AP subnet (matches=0A> > > /64=A0prefix):=0A> > > > > =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 If (IPv4 source does not match last 32 bits of= =0A> > > IPv6=A0source): drop;=0A> > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Else If (IPv4 source does not belong to one=0A> > > of=A0re= gistered subnets): drop;=0A> > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Else relay; // we may or may not want to add=0A> > > a=A0destin= ation check=0A> > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else=0A> > > > > = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If (IPv4 source belongs to = one of registered=0A> > > subnets):=A0drop;=0A> > > > > =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else if (IPv6 destination does not match ISATA= P=0A> > > subnet):=A0drop;=0A> > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Else if (embedded IPv4 address does not belong =0A> to=0A> > > = of=A0registered subnets):=0A> > > > drop;=0A> > > > > =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else relay;=0A> > > > >=0A> > > > > Written tha= t way, the ISATAP router cannot create a loop, because =0A> packets=0A> > >= always=0A> > > > > go either from site to elsewhere, or from elsewhere to = site.=0A> > > > >=0A> > > > >=0A> > > > >=0A> > > > > -----Original Message= -----=0A> > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org= ] On Behalf Of=0A> > > Templin,=0A> > > > > Fred L=0A> > > > > Sent: Friday= , September 04, 2009 1:01 PM=0A> > > > > To: Gabi Nakibly; v6ops=0A> > > > = > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > Subject: RE: Routing loop = attacks using IPv6 tunnels=0A> > > > >=0A> > > > > Gabi,=0A> > > > >=0A> > = > > > I'd like to make one other observation about these checks we=0A> > > = > > have been discussing. There seems to be an implication that=0A> > > > >= there needs to be a check on all of the IPv4 addresses assigned=0A> > > > = > to the node's IPv4 interfaces, and with ISATAP there could be=0A> > > > >= multiple underlying IPv4 interfaces over which the ISATAP=0A> > > > > inte= rface is configured. So, that would seem like a potential=0A> > > > > perfo= rmance issue if there were multiple IPv4 addresses to=0A> > > > > check for= every packet.=0A> > > > >=0A> > > > > But, if the ISATAP router configures= only a single IPv4 address=0A> > > > > and places it on the ISATAP interfa= ce (i.e., leaving all of the=0A> > > > > underlying IPv4 interfaces with on= ly a link-local address) then=0A> > > > > there is only one IPv4 address to= check. The technique is called:=0A> > > > > "link-layer multiplexing" and = is described for ISATAP/VET in=0A> > > > > Appendix B of 'draft-templin-int= area-vet'. But, the idea really=0A> > > > > came from Section 3.3.4 of RFC1= 122.=0A> > > > >=0A> > > > > Thanks - Fred=0A> > > > > fred.l.templin@boein= g.com=0A> > > > >=0A> > > > > > -----Original Message-----=0A> > > > > > Fr= om: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > > > Sent: Thursday, = September 03, 2009 8:00 AM=0A> > > > > > To: Templin, Fred L; v6ops=0A> > >= > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > Subject: Re: Routin= g loop attacks using IPv6 tunnels=0A> > > > > >=0A> > > > > > Hi Fred,=0A> = > > > > > see 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: Tuesday, September 1, 2009 6:49:56 = PM=0A> > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A>= > > > > > >=0A> > > > > > > Gabi,=0A> > > > > > >=0A> > > > > > > > -----O= riginal Message-----=0A> > > > > > > > From: Gabi Nakibly [mailto:gnakibly@= yahoo.com]=0A> > > > > > > > Sent: Monday, August 31, 2009 12:41 PM=0A> > >= > > > > > To: Templin, Fred L; v6ops=0A> > > > > > > > Cc: ipv6@ietf.org; = secdir@ietf.org=0A> > > > > > > > Subject: Re: Routing loop attacks using I= Pv6 tunnels=0A> > > > > > > >=0A> > > > > > > > Fred,=0A> > > > > > > >=0A>= > > > > > > > I agree that the source address check discussed below should= be =0A> made.=0A> > > I=0A> > > > > would=0A> > > > > > > also add a forth= =0A> > > > > > > > check to mitigate attack #3 as a second layer of defense= in case =0A> the=0A> > > > > opposite=0A> > > > > > > ISATAP router does n= ot=0A> > > > > > > > make the proper check on the destination address.=0A> = > > > > > > >=0A> > > > > > > > isatap_xmt() {=0A> > > > > > > >=A0 =A0 =A0= ...=0A> > > > > > > >=A0 =A0 =A0 if (src =3D=3D "::0200:5efe:")=0A> > > > = > > > >=A0 =A0 =A0 =A0 drop_pkt(); /* attack #3 mitigation */=0A> > > > > >= > >=A0 =A0 =A0 ...=0A> > > > > > > >=A0 }=0A> > > > > > >=0A> > > > > > > = Having thought about it a bit, I agree but for ISATAP I see=0A> > > > > > >= the source address check as a MAY and the destination address=0A> > > > > = > > check as a SHOULD.=0A> > > > > >=0A> > > > > > Why do you think so? As = I see it, the two checks mitigate two =0A> different=0A> > > > > attacks. T= he destination=0A> > > > > > address check defends the ISATAP router agains= t attacks of type 3 in =0A> which=0A> > > it=0A> > > > > acts as=0A> > > > = > > the decapsulator of the attack packet.=A0 While, the source address =0A= > check=0A> > > > > defends the ISATAP=0A> > > > > > router against attacks= of type 3 in which it acts as the ecapsulator =0A> of=0A> > > the=0A> > > = > > attack packet.=A0 Either of=0A> > > > > > these checks are redundant if= the other one is employed by the =0A> opposite=0A> > > router=0A> > > > > = of the attack. So I do=0A> > > > > > not see why one of them is a SHOULD an= d the other is a MAY.=0A> > > > > >=0A> > > > > > >=0A> > > > > > > In new = automatic tunneling protocol specifications that use a=0A> > > > > > > diff= erent encapsulation format than ip-proto-41, as long as=0A> > > > > > > we = make the destination address check a MUST before anything=0A> > > > > > > g= ets deployed then the source address check is unnecessary=0A> > > > > > >= =0A> > > > > >=0A> > > > > > In principle, I agree with you. However, I am = a believer of the =0A> "defense=0A> > > in=0A> > > > > depth" paradigm: two= =0A> > > > > > layers of security are (usually) better than one. Since no o= ne can be=0A> > > > > absolutely sure that the=0A> > > > > > destination ad= dress check shall always be implemented correctly at all=0A> > > other=0A> = > > > > routers then it may seem=0A> > > > > > prudent to also employ the s= ource check as a second layer of defense.=0A> > > > > >=0A> > > > > > > Fre= d=0A> > > > > > > fred.l.templin@boeing.com=0A> > > > > > >=0A> > > > > > >= >=0A> > > > > > > > Gabi=0A> > > > > > > >=0A> > > > > > > > ----- Origina= l Message ----=0A> > > > > > > > > From: "Templin, 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 attacks 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> > > > > > > > > > Sen= t: 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 sum= mary of our discussion up until now: the best=0A> > > mitigation=0A> > > > = > > > of most of=0A> > > > > > > > > these attacks is=0A> > > > > > > > > >= indeed the proto-41 and ingress filtering on the border of the=0A> > > ISA= TAP=0A> > > > > > > site. If=0A> > > > > > > > > it is indeed=0A> > > > > >= > > > > implemented. I assume that not all sites deploy such filtering =0A= > for=0A> > > > > lack of=0A> > > > > > > > > awareness or since the=0A> > = > > > > > > > > proto-41 filtering may break other tunnels the site may =0A= > employ.=0A> > > > > However, I=0A> > > > > > > do=0A> > > > > > > > > not= have hard evidence=0A> > > > > > > > > > on this. I would be happy if othe= rs on the list will refute or=0A> > > justify=0A> > > > > > > this=0A> > > = > > > > > > assumption.=0A> > > > > > > > > >=0A> > > > > > > > > > If this= assumption is (even partially) correct than I think =0A> that=0A> > > the= =0A> > > > > > > ISATAP=0A> > > > > > > > > router should defend=0A> > > > = > > > > > > itself.=0A> > > > > > > > >=0A> > > > > > > > > If there is ope= rational assurance of filtering, then I think =0A> there=0A> > > > > > > > = > is no problem. For the other cases, I am beginning to come =0A> around=0A= > > > > > > > > > to your opinion.=0A> > > > > > > > >=0A> > > > > > > > > = > Moreover, as I mention below the proo-41 filtering is not=0A> > > effecti= ve in=0A> > > > > > > case of=0A> > > > > > > > > attack=0A> > > > > > > > = > > #3 and the 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> > >= > > > > > > > that you illustrated below in pseudo-code.=0A> > > > > > > >= >=0A> > > > > > > > > OK.=0A> > > > > > > > >=0A> > > > > > > > > > See fu= rther 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, 2009 10:04:34 PM=0A> > > = > > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > = > > > > > > > > >=0A> > > > > > > > > > > Gabi,=0A> > > > > > > > > > >=0A>= > > > > > > > > > > > -----Original Message-----=0A> > > > > > > > > > > >= From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > > > > > > > > > S= ent: 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 tun= nels=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > Fred,=0A> > > > > = > > > > > > > I initially very much liked your suggestion regarding the=0A>= > > check of=0A> > > > > the=0A> > > > > > > > > > > neighbor cache before= =0A> > > > > > > > > > > > forwarding a packet into the tunnel. It truly ad= dresses =0A> the=0A> > > root=0A> > > > > cause=0A> > > > > > > of=0A> > > = > > > > > > the=0A> > > > > > > > > > > problem ans is simple=0A> > > > > >= > > > > > > enough to implement. However, I realized that an attacker =0A>= can=0A> > > send=0A> > > > > a=0A> > > > > > > > > > > spoofed RS to the I= SATAP router=0A> > > > > > > > > > > > as if it came from the 6to4 relay. T= he router would then =0A> send=0A> > > a RA=0A> > > > > to=0A> > > > > > > = > > it and=0A> > > > > > > > > > > consequently change its=0A> > > > > > > = > > > > > neighbor cache. So it seems that this defense does not add=0A> > = > > > > > much. Wouldn't=0A> > > > > > > > > you=0A> > > > > > > > > > > ag= ree?=0A> > > > > > > > > > >=0A> > > > > > > > > > > I agree that my propos= ed mitigation is only useful when =0A> there=0A> > > > > > > > > > > is ass= urance of a coherent neighbor cache in the ISATAP =0A> router.=0A> > > > > = > > > > > > That would be true in the case in which the ISATAP router is=0A= > > > > > > > > > > > located within a site protected by border routers tha= t =0A> perform=0A> > > > > > > > > > > ip-proto-41 and ingress filtering, a= nd in which there is no=0A> > > > > > > > > > > untraceable IPv4 source add= ress spoofing. So AFAICT, my =0A> proposed=0A> > > > > > > > > > > mitigati= on 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> > > > > > > > > >=0A> > > > > > > > > > This is only true when the at= tacker is outside the site and=0A> > > proto-41=0A> > > > > > > filtering= =0A> > > > > > > > > is employed. If the=0A> > > > > > > > > > attacker is = internal to the site then the proto-41 filtering =0A> will=0A> > > not=0A> = > > > > help=0A> > > > > > > and=0A> > > > > > > > > the neighbor cache 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 router, you must be=0A= > > > > > > > > > speaking here about IPv4 source address spoofing from wit= hin the=0A> > > > > > > > > site. For sites that allow intra-site source ad= dress spoofing,=0A> > > > > > > > > I think much more serious problems coul= d manifest themselves=0A> > > > > > > > > that would be completely unrelate= d to ISATAP. I believe you=0A> > > > > > > > > will also find other automat= ic tunneling protocols besides=0A> > > > > > > > > ISATAP that operate unde= r an assumption of no intra-site IPv4=0A> > > > > > > > > source address sp= oofing.=0A> > > > > > > > >=0A> > > > > > > > > > > > I completely agree wi= th your observation on the=0A> > > non-feasibility of=0A> > > > > > > > > >= > verifying that the=0A> > > > > > > > > > > > destination ISATAP address = does not include a local IPv4=0A> > > address=0A> > > > > since=0A> > > > >= > > the=0A> > > > > > > > > > > ISATAP address may include=0A> > > > > > >= > > > > > a private IPv4 address. On the other hand, a check on =0A> publi= c=0A> > > IPv4=0A> > > > > > > > > addresses is=0A> > > > > > > > > > > acc= eptable. If the=0A> > > > > > > > > > > > check would be done only on ISATA= P addresses that include=0A> > > public=0A> > > > > IPv4=0A> > > > > > > > = > > > addresses then this will=0A> > > > > > > > > > > > eliminate the atta= cks in which the two victims reside at=0A> > > different=0A> > > > > > > si= tes.=0A> > > > > > > > > Note=0A> > > > > > > > > > > that if attack #3 is= =0A> > > > > > > > > > > > launched on two ISATAP routers having private ad= dresses at =0A> two=0A> > > > > > > different=0A> > > > > > > > > sites=0A>= > > > > > > > > > > then the attack will=0A> > > > > > > > > > > > not wor= k anyway since one router can not send a direct =0A> IPv4=0A> > > packet=0A= > > > > > to=0A> > > > > > > the=0A> > > > > > > > > > > other. In addition= ,=0A> > > > > > > > > > > > to mitigate attacks in which the other victim i= s a 6to4 =0A> relay=0A> > > > > (such as=0A> > > > > > > > > attack=0A> > >= > > > > > > > > #1) then a check would=0A> > > > > > > > > > > > have to b= e done on a 6to4 address, i.e. the destination=0A> > > address=0A> > > > > = must=0A> > > > > > > not=0A> > > > > > > > > be=0A> > > > > > > > > > > "20= 02:> > the ISATAP router>::*". In this case the IPv4 =0A> address=0A> > > m= ust=0A> > > > > be=0A> > > > > > > > > public,=0A> > > > > > > > > > > acco= rding to=0A> > > > > > > > > > > >=A0 the 6to4 spec.=0A> > > > > > > > > > = > >=0A> > > > > > > > > > > > As you also noted there is another problem wi= th this check=0A> > > since=0A> > > > > the=0A> > > > > > > > > string=0A> = > > > > > > > > > > "200::5EFE" is not unique=0A> > > > > > > > > > > > to = ISATAP links. On the other hand, it seems that the=0A> > > probability=0A> = > > > > to=0A> > > > > > > > > encounter=0A> > > > > > > > > > > a non-mali= cious packet=0A> > > > > > > > > > > > with a destination address having an= IID that equals=0A> > > "200:5EFE:>=0A> > > > > IPv4=0A> > > > > > > > > a= ddress>" is=0A> > > > > > > > > > > > pretty slim.=0A> > > > > > > > > > > = >=0A> > > > > > > > > > > > This check is definitely not a perfect solution= , and I =0A> sure=0A> > > hope=0A> > > > > that=0A> > > > > > > > > someone= =0A> > > > > > > > > > > will come up with a=0A> > > > > > > > > > > > bett= er one for mitigating the routing loops. However, I =0A> would=0A> > > be= =0A> > > > > happy=0A> > > > > > > if=0A> > > > > > > > > > > there is some= kind of other=0A> > > > > > > > > > > > mitigation measures besides packet= filtering (proto-41 and=0A> > > > > ingress)=0A> > > > > > > > > by other= =0A> > > > > > > > > > > nodes (which does not=0A> > > > > > > > > > > > ne= cessarily exist).=0A> > > > > > > > > > >=0A> > > > > > > > > > > You seem = to be envisioning a scenario of ISATAP router =0A> operation=0A> > > > > > = > > > > > with public IPv4 addresses and outside of any site border=0A> > >= routers=0A> > > > > > > > > > > that perform ingress filtering and ip-prot= o-41 filtering. =0A> That=0A> > > has=0A> > > > > > > > > > > traditionally= been seen as the domain of 6to4, but I am =0A> happy to=0A> > > > > > > > = > > > discuss the possibility of what I called the "inside-out =0A> ISATAP= =0A> > > > > > > > > > > model" in a list message long ago (which AFAICT is= the =0A> scenario=0A> > > > > > > > > > > you are alluding to).=0A> > > > = > > > > > > >=0A> > > > > > > > > >=0A> > > > > > > > > > Well, I am referr= ing to any ISATAP deployment with public IPv4=0A> > > > > addresses=0A> > >= > > > > and=0A> > > > > > > > > no proto-41 filtering. I=0A> > > > > > > >= > > imagine that in practice there are such deployments which are =0A> not= =0A> > > the=0A> > > > > > > > > "inside-out ISATAP model" .=0A> > > > > > = > > > > However, I must admit that I do not rely here on hard =0A> evidence= .=0A> > > > > > > > > >=0A> > > > > > > > > > > So, if the public IPv4 Inte= rnet were considered as one =0A> gigantic=0A> > > > > > > > > > > "site" an= d we wanted to do ISATAP on that site, it would be =0A> nice=0A> > > > > > = > > > > > to divide the site into multiple logical partitions, with =0A> ea= ch=0A> > > > > > > > > > > partition identified by a PRL name and a unique = set of IPv6=0A> > > > > > > > > > > prefixes. But then, we have the scenari= o you are describing =0A> in=0A> > > > > > > > > > > which we can't trust t= he integrity of the ISATAP router's=0A> > > > > > > > > > > neighbor cache = due to the possibility for untraceable 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 support the inside-out ISATAP=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 in= terfaces=0A> > > > > > > > > > > that are not behind filtering border route= rs to advertise=0A> > > > > > > > > > > non-link-local on-link IPv6 prefixe= s and/or forward packets=0A> > > > > > > > > > > from non-link-local prefix= es in the first place.=0A> > > > > > > > > > >=0A> > > > > > > > > > > If w= e 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> > > > > > > > > > > If we took the more ambitious rou= te 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> > > > > > > > > > > suppression. As= suming this, if I read your attack scenarios=0A> > > > > > > > > > > 1 thro= ugh 3 correctly then scenarios 1 and 3 are mitigated=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 "2002:::*")= =0A> > > > > > > > > > >=A0 =A0 =A0 drop_pkt(); /* attack #1 mitigation */= =0A> > > > > > > > > > >=0A> > > > > > > > > > >=A0 =A0 if (dst =3D=3D "*::= 0200:5efe:")=0A> > > > > > > > > > >=A0 =A0 drop_pkt(); /* attack #3 mitiga= tion */=0A> > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > > > > >=A0 }=0A>= > > > > > > > > > >=0A> > > > > > > > > >=0A> > > > > > > > > > Correct (w= ith the correction you sent after this email).=0A> > > > > > > > >=0A> > > = > > > > > > OK.=0A> > > > > > > > >=0A> > > > > > > > > > >=A0 isatap_xmt()= {=0A> > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > > > > >=A0 =A0 if (ds= t =3D=3D "*::0200:5efe:192.88.99.1")=0A> > > > > > > > > > >=A0 =A0 =A0 dro= p_pkt(); /* attack #2 mitigation */=0A> > > > > > > > > > >=A0 =A0 ...=0A> = > > > > > > > > > >=A0 }=0A> > > > > > > > > >=0A> > > > > > > > > > This w= ill not necessarily work, since the 6to4 relay may have =0A> a=0A> > > > > = unicast=0A> > > > > > > > > address the ISATAP router may=0A> > > > > > > >= > > not be aware of. The best way to mitigate attack #2 is by the =0A> 6to= 4=0A> > > > > relay=0A> > > > > > > with=0A> > > > > > > > > a check simila= r to that=0A> > > > > > > > > > of attack #2 above. IMO, the second best wa= y, as Remi =0A> suggested on=0A> > > > > another=0A> > > > > > > > > thread= , is for the ISATAP=0A> > > > > > > > > > router to drop the packet if (src= =A0 =3D=3D 2002:::*"). However, =0A> this=0A> > > > > > > > > check is usef= ul only=0A> > > > > > > > > > when the 6to4 relay validates that the IPv6 s= ource address=0A> > > corresponds=0A> > > > > to=0A> > > > > > > the=0A> > = > > > > > > > IPv4 one (this is=0A> > > > > > > > > > in accordance with th= e 6to4 spec, however it does not always =0A> get=0A> > > > > > > implemente= d).=0A> > > > > > > > > If this is not true=0A> > > > > > > > > > then the = attacker does not have to send the attack packet with=0A> > > such an=0A> >= > > > > > > > address.=0A> > > > > > > > >=0A> > > > > > > > > Keeping wit= h the philosophy of the ISATAP router defending =0A> 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 to 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 w= e need to consider?=0A> > > > > > > > > > >=0A> > > > > > > > > >=0A> > > >= > > > > > >=0A> > > > > > > > > > > Thanks - 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> > > > > > > > > > > > Subje= ct: RE: Routing loop attacks using IPv6 tunnels=0A> > > > > > > > > > > >= =0A> > > > > > > > > > > > Hi Gabi,=0A> > > > > > > > > > > >=0A> > > > > >= > > > > > > I'm sorry to have to keep turning this into plaintext,=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: Wednesday, August 19, 2009 1:49 AM=0A> > > > > > > > > = > > > To: Templin, Fred L; v6ops=0A> > > > > > > > > > > > Cc: ipv6@ietf.or= g; secdir@ietf.org=0A> > > > > > > > > > > > Subject: Re: Routing loop atta= cks using IPv6 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; se= cdir@ietf.org=0A> > > > > > > > > > > > Sent: Tuesday, August 18, 2009 6:48= :45 PM=0A> > > > > > > > > > > > Subject: RE: Routing loop attacks using IP= v6 tunnels=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > Gabi,=0A> > = > > > > > > > > > >=0A> > > > > > > > > > > > _____________________________= ___________=0A> > > > > > > > > > > > From: Gabi Nakibly [mailto:gnakibly@y= ahoo.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> > > > > > > > > > > > > Subje= ct: Re: Routing loop attacks using IPv6 tunnels=0A> > > > > > > > > > > > >= =0A> > > > > > > > > > > > > Indeed the ISATAP interface of the ISATAP rout= er is =0A> meant=0A> > > > > > > > > > > > > to be an enterprise-interior (= note that it is still =0A> assumed=0A> > > > > > > > > > > > > that the ass= ociated IPv4 address is non-private). As we=0A> > > > > > > > > > > > > exp= licitly note in the paper, the first three attacks =0A> will=0A> > > > > > = > > > > > > > be mitigated if proper protocol-41 filtering is deployed =0A>= on=0A> > > > > > > > > > > > > the site's border. However, note that RFC52= 14 does not=0A> > > mandate=0A> > > > > > > > > > > > > or require this fil= tering.=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > The RFC5214 Sec= urity Considerations makes clear the=0A> > > > > > > > > > > > consequences= of not implementing IPv4 ingress filtering=0A> > > > > > > > > > > > and i= p-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 =0A> interface's=0A= > > > > > > > > > > > > locator set MUST NOT span multiple sites. This mean= s that =0A> the=0A> > > > > > > > > > > > ISATAP interface must not decapsu= late nor source =0A> ip-proto-41=0A> > > > > > > > > > > > packets within m= ultiple sites, where the enterprise =0A> interior=0A> > > > > > > > > > > >= is site #1 and the global Internet is site #2. =0A> 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 = correctly. In=0A> > > > > > > > > > > > attack #2, for example, I assume th= e ISATAP router has two=0A> > > > > > > > > > > > physical interfaces. A si= te-internal IPv4 interface with =0A> an=0A> > > > > > > > > > > > address I= Pisatap and a site-external IPv6 interface. I =0A> also=0A> > > > > > > > >= > > > assume that there is another border router which connects =0A> the= =0A> > > > > > > > > > > > site to the IPv4 Internet. The ISATAP router has= an ISATAP=0A> > > > > > > > > > > > interface with a single locator: (IPis= atap, site-internal=0A> > > > > > > > > > > > interface). When the ISATAP r= outer gets an IPv6 via its=0A> > > > > > > > > > > > external interface it = will encapsulate the packet =0A> accordingly=0A> > > > > > > > > > > > and = forward it through the internal IPv4 interface. If the=0A> > > > > > > > > = > > > encapsulated packet is destined to a node outside the site=0A> > > > = > > > > > > > > then the only thing that stops it is a proto-41 filtering= =0A> > > > > > > > > > > > at the other border router of the site. Did I ge= t this =0A> 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 leas= t one major enterprise=0A> > > > > > > > > > > > =3D=3D> network that does = this.=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > > It is only ment= ioned as a possible mitigation against=0A> > > > > > > > > > > > > incoming= spurious protocol-41 packets. In addition,=0A> > > > > > > > > > > > > Sec= tion 10 of RFC5214 only mentions ingress not egress=0A> > > > > > > > > > >= > > filtering. Hence it will not stop attack #2.=0A> > > > > > > > > > > >= =0A> > > > > > > > > > > > We are now talking about ip-proto-41 filtering; = not =0A> ingress=0A> > > > > > > > > > > > filtering. ip-proto-41 filtering= is in both directions. It=0A> > > > > > > > > > > > prevents ip-proto-41 p= ackets from entering the enterprise=0A> > > > > > > > > > > > interior ISAT= AP site from the Internet and prevents=0A> > > > > > > > > > > > ip-proto-4= 1 packets from entering the Internet ISATAP=0A> > > > > > > > > > > > site = from the enterprise interior. Else the ISATAP=0A> > > > > > > > > > > > int= erface 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 leaving the end site and going out in= to=0A> > > > > > > > > > > > the Internet. RFC2827 (BCP38) documents ingres= s 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> > > > > > > > > > > > > attac= k #3 is launched on two routers that reside in the=0A> > > > > > > > > > > = > > same site. Note that it may be possible for the attack=0A> > > > > > > = > > > > > > packet to be sourced from outside the site unless proper=0A> > = > > > > > > > > > > > filtering of incoming IPv6 packets is deployed. If th= e=0A> > > > > > > > > > > > > attacker resides in the site, usually ingress= filtering=0A> > > > > > > > > > > > > will not be helpful since it is depl= oyed 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 pr= efix.=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > Well, I do not se= e how this is correct. In attacks #1 and =0A> #3=0A> > > the=0A> > > > > > = > ISATAP=0A> > > > > > > > > router=0A> > > > > > > > > > > sources (actual= ly=0A> > > > > > > > > > > > forwards) an IPv6 packet with a source address= having the=0A> > > > > > > > > corresponding prefix=0A> > > > > > > > > > = > of the ISATAP tunnel.=0A> > > > > > > > > > > > In attacks #2 and #3 the = ISATAP router sources and IPv4 =0A> packet=0A> > > > > with=0A> > > > > > >= its=0A> > > > > > > > > own=0A> > > > > > > > > > > IPv4 address as the=0A= > > > > > > > > > > > > source address.=0A> > > > > > > > > > > >=0A> > > >= > > > > > > > >=0A> > > > > > > > > > > > =3D=3D> There were a number of e= rrors in what I said in my =0A> last=0A> > > > > > > > > > > > =3D=3D> mess= age, so let me see if I can get it right here:=0A> > > > > > > > > > > > = =3D=3D>=0A> > > > > > > > > > > > =3D=3D> In attacks #1 and #2 there are tw= o cases to consider. =0A> Case=0A> > > > > > > > > > > > =3D=3D> 1 in which= a border router separates the 6to4 relay =0A> from=0A> > > the=0A> > > > >= > > > > > > > =3D=3D> ISATAP router, and case 2 in which no border router= =0A> > > separates=0A> > > > > > > > > > > > =3D=3D> the 6to4 relay from th= e ISATAP router.=0A> > > > > > > > > > > > =3D=3D>=0A> > > > > > > > > > > = > =3D=3D> In attack #1, we have an IPv6 packet with a local =0A> source=0A>= > > > > > > > > > > > =3D=3D> address entering the site from the outside. = IPv6 =0A> ingress=0A> > > > > > > > > > > > =3D=3D> filtering at the site b= order router should prevent the=0A> > > > > > > > > > > > =3D=3D> packet fr= om entering the site in the first place. If =0A> 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 att= ack =0A> in=0A> > > > > > > > > > > > =3D=3D> the first place anyway. If th= e relay router is =0A> *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 =0A> should=0A> > > = > > > > > > > > > =3D=3D> really be positioned outside of the site's border= =0A> routers;=0A> > > > > > > > > > > > =3D=3D> otherwise, it could be spo= ofed into thinking that the=0A> > > > > > > > > > > > =3D=3D> ISATAP router= is a 6to4 router and not an ISATAP =0A> router.=0A> > > > > > > > > > > > = =3D=3D>=0A> > > > > > > > > > > > =3D=3D> In attack #2, we have an IPv6 pac= ket with a foreign =0A> source=0A> > > > > > > > > > > > =3D=3D> address be= ing forwarded by the ISATAP router to a 6to4=0A> > > > > > > > > > > > =3D= =3D> relay, but I mis-spoke when I said that this would be =0A> a=0A> > > >= > > > > > > > > =3D=3D> case of the ISATAP router forwarding a packet with= a=0A> > > foreign=0A> > > > > > > > > > > > =3D=3D> source address out of = the ISATAP link. For all the =0A> ISATAP=0A> > > > > > > > > > > > =3D=3D> = router knows, the 6to4 relay is just an ordinary host =0A> on=0A> > > > > >= > > > > > > =3D=3D> the ISATAP link, so the ISATAP router actually =0A> be= lieves it=0A> > > > > > > > > > > > =3D=3D> is forwarding the packet *into*= the ISATAP link (not =0A> out=0A> > > of=0A> > > > > > > > > > > > =3D=3D>= it). But as in attack #1, the attack is blocked by=0A> > > ip-proto-41=0A>= > > > > > > > > > > > =3D=3D> filtering at the border router between the I= SATAP =0A> router=0A> > > and=0A> > > > > > > > > > > > =3D=3D> the 6to4 re= lay. If there is no border router between =0A> the=0A> > > > > ISATAP=0A> >= > > > > > > > > > > =3D=3D> router and the 6to4 relay, then we have an ide= ntical=0A> > > instance=0A> > > > > > > > > > > > =3D=3D> to attack #3 whic= h I will discuss below. But, the best=0A> > > > > > > > > > > > =3D=3D> ope= rational practice would again be to have the 6to4 =0A> relay=0A> > > > > > = > > > > > > =3D=3D> oriented outside of a border router that filters=0A> > = > ip-proto-41.=0A> > > > > > > > > > > > =3D=3D>=0A> > > > > > > > > > > > = =3D=3D> Short summary is that in attack #1, the 6to4 relay =0A> thinks=0A> = > > it=0A> > > > > > > > > > > > =3D=3D> is talking to a 6to4 router and no= t an ISATAP router. =0A> In=0A> > > > > > > > > > > > =3D=3D> attack #2, th= e ISATAP router thinks it is talking to a=0A> > > > > > > > > > > > =3D=3D>= simple host on the link and not a 6to4 relay. In both=0A> > > 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 =0A> the=0A> > > > > > > > > > > > =3D=3D> 6to4 relay= . Oftentimes, the "border router" will be a =0A> two-=0A> > > > > > > > > >= > > =3D=3D> interface router that implements 6to4 on a =0A> site-external= =0A> > > > > > > > > > > > =3D=3D> IPv4 interface and implements ISATAP on = a =0A> site-internal=0A> > > > > > > > > > > > =3D=3D> IPv4 interface and p= erforms ip-proto-41 filtering on=0A> > > packets=0A> > > > > > > > > > > > = =3D=3D> from outside the site with an IPv4 destination=0A> > > correspondin= g=0A> > > > > > > > > > > > =3D=3D> to the ISATAP interface. I will discuss= attack #3 =0A> below:=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > = This attack is mitigated by=0A> > > > > > > > > > > > IPv6 ingress filterin= g which is an IPv6 security =0A> consideration=0A> > > > > > > > > > > > an= d not an ISATAP nor IPv4 security consideration. BCP=0A> > > > > > > > > > = > > recommendations for network ingress filtering are =0A> documented=0A> >= > > > > > > > > > > in RFC2827 and it is expected that IPv6 routers that = =0A> configure=0A> > > > > > > > > > > > ISATAP interfaces will implement I= Pv6 ingress filtering=0A> > > > > > > > > > > > according to the BCP.=0A> >= > > > > > > > > > >=0A> > > > > > > > > > > > So If my last comment is cor= rect than I do not see how =0A> ingress=0A> > > > > > > filtering=0A> > > >= > > > > > would=0A> > > > > > > > > > > help here. The only=0A> > > > > > = > > > > > > case where ingress filtering can help is in case of attack =0A>= #3=0A> > > when=0A> > > > > the=0A> > > > > > > > > routers=0A> > > > > > = > > > > > reside at the same=0A> > > > > > > > > > > > site. In that case i= f the attack packet (packet 0) is sent=0A> > > from=0A> > > > > > > outside= =0A> > > > > > > > > the=0A> > > > > > > > > > > site then ingress=0A> > > = > > > > > > > > > filtering on the border of the site will drop the packet.= =0A> > > > > > > > > > > >=0A> > > > > > > > > > > >=0A> > > > > > > > > > = > > =3D=3D> Correct about the IPv6 ingress filtering at the =0A> border,=0A= > > > > > > > > > > > > =3D=3D> but as with attack #2 my error in the previ= ous message=0A> > > > > > > > > > > > =3D=3D> was in thinking the ISATAP ro= uter A was forwarding the=0A> > > > > > > > > > > > =3D=3D> packet *out* of= the ISATAP link when in fact from the=0A> > > > > > > > > > > > =3D=3D> IS= ATAP router's perspective it is forwarding the =0A> packet=0A> > > > > > > = > > > > > =3D=3D> to a simple host *inside* of the link.=0A> > > > > > > > = > > > > =3D=3D>=0A> > > > > > > > > > > > =3D=3D> The problem here is that = the ISATAP router is blindly=0A> > > > > > > > > > > > =3D=3D> forwarding a= packet to a node that it assumes is a =0A> simple=0A> > > > > > > > > > > = > =3D=3D> host on the ISATAP link without first verifying that =0A> the=0A>= > > > > > > > > > > > =3D=3D> node has demonstrated a willingness to parti= cipate as =0A> a=0A> > > > > > > > > > > > =3D=3D> host on the link. As you= have pointed out, this can =0A> lead=0A> > > > > > > > > > > > =3D=3D> to = strange scenarios when the anonymous node is a =0A> 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 =0A> router=0A> > > > > > > > > > > > =3D=3D> to check whether t= he IPv6 destination address is an =0A> ISATAP=0A> > > > > > > > > > > > =3D= =3D> address that embeds one of its own IPv4 addresses, =0A> because=0A> > = > > > > > > > > > > =3D=3D> when IPv4 private addresses are used the same I= Pv4 =0A> address=0A> > > > > > > > > > > > =3D=3D> can (and often does) occ= ur in multiple sites. So for=0A> > > example,=0A> > > > > > > > > > > > =3D= =3D> if the ISATAP router configures an IPv4 address =0A> 10.0.0.1=0A> > > = > > > > > > > > > =3D=3D> and is asked to forward an IPv6 packet with ISATA= P=0A> > > > > > > > > > > > =3D=3D> destination address 2001:DB8::0:5EFE:10= .0.0.1 where =0A> the=0A> > > > > > > > > > > > =3D=3D> IPv6 prefix is fore= ign, the router can't very well =0A> drop=0A> > > the=0A> > > > > > > > > >= > > =3D=3D> packet as this would block legitimate communications. =0A> It= =0A> > > > > > > > > > > > =3D=3D> is also not generally possible to check = whether a =0A> foreign=0A> > > > > > > > > > > > =3D=3D> link is an ISATAP = link by looking for the magic token=0A> > > > > > > > > > > > =3D=3D> "0:5E= FE" as that token only has significance for =0A> ISATAP=0A> > > > > > > > >= > > > =3D=3D> links and not other link types.=0A> > > > > > > > > > > > = =3D=3D>=0A> > > > > > > > > > > > =3D=3D> Instead, the mitigation I think m= akes the most sense =0A> is=0A> > > > > > > > > > > > =3D=3D> for the ISATA= P router to first verify that the node =0A> which=0A> > > > > > > > > > > >= =3D=3D> it assumes to be a simple ISATAP host has demonstrated =0A> a=0A> = > > > > > > > > > > > =3D=3D> willingness to participate in the link. That = can be =0A> done=0A> > > > > > > > > > > > =3D=3D> by having the ISATAP rou= ter first check the neighbor =0A> cache=0A> > > > > > > > > > > > =3D=3D> w= hen it has a packet to send to verify that there is a=0A> > > > > > > > > >= > > =3D=3D> cached entry corresponding to the destination. For =0A> nodes= =0A> > > > > > > > > > > > =3D=3D> that are willing ISATAP hosts on the lin= k, there would=0A> > > > > > > > > > > > =3D=3D> have been a neighbor cache= entry created when the node=0A> > > > > > > > > > > > =3D=3D> sends a Rout= er Solicitation to the ISATAP router for =0A> the=0A> > > > > > > > > > > >= =3D=3D> purpose of discovering default router lifetimes and =0A> on-=0A> >= > > > > > > > > > > =3D=3D> link prefixes. So, the simple mitigations is f= or the=0A> > > ISATAP=0A> > > > > > > > > > > > =3D=3D> router to forward t= he packet only if there is a=0A> > > pre-existing=0A> > > > > > > > > > > >= =3D=3D> neighbor cache entry and drop the packet otherwise. =0A> This=0A> = > > > > > > > > > > > =3D=3D> implies that the router should keep neighbor = cache =0A> entires=0A> > > > > > > > > > > > =3D=3D> for the duration of th= e minimum lifetime of the =0A> prefixes=0A> > > > > > > > > > > > =3D=3D> i= t 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 =0A> by=0A> > > > > > > > > > > > > proper firewall rules. Howev= er, I do not believe that =0A> this=0A> > > > > > > > > > > > > should be o= ur only answer against these attacks. I =0A> believe=0A> > > > > > > > > > = > > > that since these attacks are made possible due to the=0A> > > > > > >= > > > > > > inherent characteristics of the tunnels they should be=0A> > >= > > > > > > > > > > stopped intrinsically as much as possible by the tunne= l=0A> > > > > > > > > > > > > participants and not relay on outside filteri= ng rules.=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > In RFC5214, S= ection 10 we have: "restricting access to the=0A> > > > > > > > > > > > lin= k can be achieved by restricting access to the site". =0A> The=0A> > > > > = > > > > > > > mitigations do exactly that, and in such a way that ISATAP=0A= > > > > > > > > > > > > nodes can operate with only the necessary and suffi= cient=0A> > > > > > > > > > > > checks. So on this point, I do not share yo= ur opinion.=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > What about = two ISATAP tunnels that reside on the same site=0A> > > like in=0A> > > > >= > > attack=0A> > > > > > > > > #3.=0A> > > > > > > > > > > Do you also thi= nk that=0A> > > > > > > > > > > > proto-41 filtering should barrier between= the two tunnels=0A> > > within=0A> > > > > the=0A> > > > > > > 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 whereby an ISATAP router is not mist= aken for=0A> > > > > > > > > > > > =3D=3D> a 6to4 router. This is through p= roper arrangement of=0A> > > > > > > > > > > > =3D=3D> 6to4 router/relay in= terfaces outside of the site =0A> border=0A> > > > > > > > > > > > =3D=3D> = rather than inside, and ISATAP router interfaces =0A> inside=0A> > > > > > = > > > > > > =3D=3D> of the site border rather than outside. 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 multi= ple ISATAP links within the=0A> > > > > > > > > > > > =3D=3D> same local IP= v4 routing region, an ISATAP router =0A> 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: "Temp= lin, 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 using IPv6 tunnels=0A> > > > > > > > > > > >=0A>= > > > > > > > > > > >=0A> > > > > > > > > > > > Gabi,=0A> > > > > > > > > = > > >=0A> > > > > > > > > > > > Thanks for publishing this work. In the doc= ument, attacks =0A> A, B=0A> > > and=0A> > > > > C=0A> > > > > > > > > > > = > correspond to a configuration that violates section 6.2 of=0A> > > > > RF= C5214:=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > > 6.2.=A0 ISATAP= Interface Address Configuration=0A> > > > > > > > > > > > >=0A> > > > > > = > > > > > > >=A0 Each ISATAP interface configures a set of locators=0A> > >= consisting=0A> > > > > of=0A> > > > > > > IPv4=0A> > > > > > > > > > > > >= =A0 address-to-interface mappings from a single site; i.e., =0A> an=0A> > >= > > ISATAP=0A> > > > > > > > > > > > >=A0 interface's locator set MUST NOT= span multiple sites.=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > I= n particular, in scenarios A, B and C the IPv4 locator =0A> used=0A> > > fo= r=0A> > > > > > > ISATAP=0A> > > > > > > > > > > > is seen both within the = enterprise as site #1 and within =0A> the=0A> > > > > global=0A> > > > > > = > > > Internet=0A> > > > > > > > > > > > itself as site #2. If the ISATAP i= nterface is to be used =0A> as an=0A> > > > > > > enterprise-=0A> > > > > >= > > > > > > interior interface, it should therefore not accept =0A> IP-pro= to-41=0A> > > > > packets=0A> > > > > > > > > > > > coming from an IPv4 sou= rce outside of the enterprise nor=0A> > > source=0A> > > > > > > > > > > > = IP-proto-41 packets that are destined to an IPv4 node =0A> outside=0A> > > = of=0A> > > > > the=0A> > > > > > > > > > > > enterprise. This condition sho= uld be satisfied by having =0A> the=0A> > > site=0A> > > > > > > border=0A>= > > > > > > > > > > > routers implement IPv4 ingress filtering and =0A> ip= -protocol-41=0A> > > > > filtering=0A> > > > > > > as=0A> > > > > > > > > >= > > required in Section 10 of RFC5214.=0A> > > > > > > > > > > >=0A> > > >= > > > > > > > > It is mentioned that attack C could also occur when the=0A= > > > routers=0A> > > > > reside=0A> > > > > > > > > > > > in the same site= , where their addresses may be private. =0A> This=0A> > > would=0A> > > > >= > > > > > > > correspond to a case in which an attacker within the site=0A= > > > attacks=0A> > > > > the=0A> > > > > > > > > > > > site itself, which = can easily be traced - especially when=0A> > > source=0A> > > > > > > addre= ss=0A> > > > > > > > > > > > spoofing from a node within the site is preven= ted through=0A> > > proper=0A> > > > > > > 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 attacks using IPv6 tunnels= =0A> > > > > > > > > > > >=0A> > > > > > > > > > > > Hi all,=0A> > > > > > = > > > > > > I would like to draw the attention of the list=0A> > > > > > > = to some research results=0A> > > > > > > > > which=0A> > > > > > > > > > > = my colleague and I at=0A> > > > > > > > > > > > the National EW Research & = Simulation Center have recently=0A> > > > > published.=0A> > > > > > > The= =0A> > > > > > > > > > > research presents a class=0A> > > > > > > > > > > = > of routing loop attacks that abuses 6to4, ISATAP and =0A> Teredo.=0A> > >= The=0A> > > > > paper=0A> > > > > > > can=0A> > > > > > > > > be=0A> > > >= > > > > > > > found at:=0A> > > > > > > > > > > >=0A> > > http://www.useni= x.org/events/woot09/tech/full_papers/nakibly.pdf=0A> > > > > > > > > > > >= =0A> > > > > > > > > > > > Here is the abstract:=0A> > > > > > > > > > > > = IPv6 is the future network layer protocol for the =0A> Internet.=0A> > > Si= nce=0A> > > > > it=0A> > > > > > > is=0A> > > > > > > > > not=0A> > > > > >= > > > > > compatible with its=0A> > > > > > > > > > > > predecessor, some = interoperability mechanisms were =0A> designed.=0A> > > An=0A> > > > > > > = important=0A> > > > > > > > > > > category of these=0A> > > > > > > > > > >= > mechanisms is automatic tunnels, which enable IPv6=0A> > > communication= =0A> > > > > over=0A> > > > > > > an=0A> > > > > > > > > IPv4=0A> > > > > >= > > > > > network without prior=0A> > > > > > > > > > > > configuration. T= his category includes ISATAP, 6to4 and =0A> Teredo.=0A> > > We=0A> > > > > = > > present=0A> > > > > > > > > a=0A> > > > > > > > > > > novel class of at= tacks=0A> > > > > > > > > > > > that exploit vulnerabilities in these tunne= ls. These =0A> attacks=0A> > > take=0A> > > > > > > > > advantage of=0A> > = > > > > > > > > > inconsistencies=0A> > > > > > > > > > > > between a tunne= l's overlay IPv6 routing state and the =0A> native=0A> > > IPv6=0A> > > > >= > > routing=0A> > > > > > > > > > > state. The attacks form=0A> > > > > > = > > > > > > routing loops which can be abused as a vehicle for traffic=0A> = > > > > > > amplification=0A> > > > > > > > > to=0A> > > > > > > > > > > fa= cilitate DoS attacks.=0A> > > > > > > > > > > > We exhibit five attacks of = this class. One of the =0A> presented=0A> > > > > attacks=0A> > > > > > > c= an=0A> > > > > > > > > DoS a=0A> > > > > > > > > > > Teredo server using a= =0A> > > > > > > > > > > > single packet. The exploited vulnerabilities are= embedded =0A> in=0A> > > the=0A> > > > > > > design of=0A> > > > > > > > >= the=0A> > > > > > > > > > > tunnels; hence any=0A> > > > > > > > > > > > i= mplementation of these tunnels may be vulnerable. In=0A> > > particular,=0A= > > > > > the=0A> > > > > > > > > attacks=0A> > > > > > > > > > > were test= ed=0A> > > > > > > > > > > > against the ISATAP, 6to4 and Teredo implementa= tions of =0A> Windows=0A> > > > > Vista=0A> > > > > > > and=0A> > > > > > >= > > > > Windows Server 2008 R2.=0A> > > > > > > > > > > >=0A> > > > > > > = > > > > > I think the results of the research warrant some =0A> corrective= =0A> > > > > action. If=0A> > > > > > > > > > > this indeed shall be the=0A= > > > > > > > > > > > > general sentiment of the list, I will be happy writ= e an=0A> > > > > appropriate=0A> > > > > > > I-D.=0A> > > > > > > > > The= =0A> > > > > > > > > > > mitigation measures we=0A> > > > > > > > > > > > s= uggested in the paper are the best we could think of to=0A> > > > > complet= ely=0A> > > > > > > > > eliminate=0A> > > > > > > > > > > the problem. Howe= ver=0A> > > > > > > > > > > > they are far from perfect since they would re= quire tunnel=0A> > > > > > > implementations=0A> > > > > > > > > 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> > > = > > > > > > >=0A> > > > > > > >=0A> > > > > > > >=0A> > > > > > > >=0A> > >= > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > >=0A> > > = > > --------------------------------------------------------------------=0A= > > > > > IETF IPv6 working group mailing list=0A> > > > > ipv6@ietf.org=0A= > > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ip= v6=0A> > > > > ------------------------------------------------------------= --------=0A> > > >=0A> > > >=0A> > > >=0A> > > >=0A> > =0A> > =0A> > =0A> >= =0A=0A=0A=0A From owner-v6ops@ops.ietf.org Tue Sep 29 09:04: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 1ED723A6AE8 for ; Tue, 29 Sep 2009 09:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[AWL=-0.830, 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 t3ZTK8DGtk+B for ; Tue, 29 Sep 2009 09:04:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A87C73A6AE3 for ; Tue, 29 Sep 2009 09:04:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Msf8o-000Bmq-74 for v6ops-data0@psg.com; Tue, 29 Sep 2009 16:01:26 +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 1Msf8U-000BjK-NI for v6ops@ops.ietf.org; Tue, 29 Sep 2009 16:01:14 +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 n8TG10Jr019029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 09:01:00 -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 n8TG106u000669; Tue, 29 Sep 2009 09:01:00 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n8TG0xx2000648 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 29 Sep 2009 09:01:00 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 29 Sep 2009 09:01:00 -0700 From: "Templin, Fred L" To: Gabi Nakibly , Christian Huitema , v6ops CC: "ipv6@ietf.org" , "secdir@ietf.org" Date: Tue, 29 Sep 2009 09:00:55 -0700 Subject: RE: Routing loop attacks using IPv6 tunnels Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcpA7y32SMKrSr8oQ9Se74wYt9GJGQAKrYtw Message-ID: <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> In-Reply-To: <165333.98948.qm@web45503.mail.sp1.yahoo.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gabi, Welcome back from your vacation. I trimmed quite a bit from the bottom of this message to eliminate the clutter, but see below for responses to your current comments: > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Tuesday, September 29, 2009 3:22 AM > To: Templin, Fred L; Christian Huitema; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Hi Fred, > Back from vacation. See Comments inlines. >=20 > Gabi >=20 >=20 >=20 > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; Christian Huitema ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Friday, September 11, 2009 11:13:44 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Hi Gabi, > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Friday, September 11, 2009 12:59 PM > > > To: Templin, Fred L; Christian Huitema; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Hi Fred, > > > See below. > > > > > > Gabi > > > > > > > > > > > > ----- Original Message ---- > > > > From: "Templin, Fred L" > > > > To: Gabi Nakibly ; Christian Huitema > > ; v6ops > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > Sent: Tuesday, September 8, 2009 8:37:03 PM > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > Gabi and Christian, > > > > > > > > Focusing only on attack #3 (i.e., leaving out attack #1 > > > > and #2 6to4 interactions for the moment), please check > > > > the following summary of proposed mitigations: > > > > > > > > 1) For ISATAP/VET routers that have assurance that their > > > > neighbor cache is coherent, the router can make a simple > > > > check in the neighbor cache to determine whether to > > > > forward or drop the packet. In pseudo-code: > > > > > > > > =A0 isatap_rcv() { > > > > =A0 =A0 ... > > > > =A0 =A0 if ((v6src is not a neighbor) && (v6dst !=3D "fe80::*")) > > > > =A0 =A0 =A0 drop_pkt(); > > > > =A0 =A0 ... > > > > =A0 } > > > > > > > > =A0 isatap_xmt() { > > > > =A0 =A0 ... > > > > =A0 =A0 if ((v6dst is not a neighbor) && (v6src !=3D "fe80::*")) > > > > =A0 =A0 =A0 drop_pkt(); > > > > =A0 =A0 ... > > > > =A0 } > > > > > > > > (Here, the link-local exception is necessary to bootstrap > > > > neighbor discovery on the ISATAP link.) > > > > > > > > Does anyone see a problem with this? > > > > > > > Looks fine. > > > > OK. > > >=20 > On second thought, a couple of comments: > 1) According to RFC 5214 Section 8.3.4: > =A0=A0=A0=A0=A0=A0=A0" ISATAP nodes MAY schedule periodic Router Solicita= tion events > =A0=A0 =A0=A0=A0 for certain PRL(i)s by setting the corresponding TIMER(i= )." > As I understand, this means that there is a possibility for a host=A0not = to=A0send RSs to all routers in > the PRL. However, any router in the PRL may forward packets into the ISAT= AP link. The isatap_xmt() > check will prevent forwarding packets by routers which the destination=A0= has not previously sent RS to. > If I am correct then this check=A0may break ISATAP connectivity. I don't think this is a problem. If a host has not sent an RS to a PRL router, then it should not have configured a default route nor any prefix information specific to that router. Therefore, the only packets the host and router should expect to exchange in this state are link-local. As such, the router can discard non-link-local packets if there is no neighbor cache entry.=20 =20 > 2) I remind you a comment you made in the past: for the checks to work=A0= the time between two > consequtive RSs from a host to a=A0router should be no greater than the t= he lifetime of an entry for > that host in the router's neighbors cache.=A0This is needed=A0to ensure t= hat=A0the entry in the neighbors > cache will not be erased. This raises two questions: > =A0=A0=A0 a) AFAIK there is no minimum lifetime for an entry in a neighbo= rs cache -=A0it is an implementation > detail.=A0If this is true=A0how can we enforce the above constraint? Correct that there is no minimum lifetime for neighbor cache entries specified by RFC4861. However, an ISATAP router that uses the neighbor cache checking procedures I have described can use its own discipline for managing its neighbor cache. Exactly such a discipline is now specified in Section 5.4.1 of 'draft-templin-intarea-vet'. Please be aware that ISATAP and VET are simply "IPv6-over-(foo)" specifications, and RFC4861 permits that operations of the neighbor discovery protocol that are specific to (foo) links may be specified in such documents. > =A0=A0=A0 b) A router's neighbors cache=A0must now=A0include at any given= moment all the active ISATAP nodes in > the ISATAP link. Is this a reasonable demand? Memory should be cheap enough, and ISATAP links within private addressing realms should be small enough, that I do not see this as an unreasonable demand. > > > > 2) For ISATAP/VET routers that use public IPv4 addresses > > > > and that do not have assurance that their neighbor cache > > > > is coherent, the router can check for the interface ID > > > > "0200:5EFE:". In pseudo-code: > > > > > > > > =A0 isatap_rcv() { > > > > =A0 =A0 ... > > > > =A0 =A0 if (v6dst =3D=3D "foreign_prefix::0200:5efe:") > > > > =A0 =A0 =A0 drop_pkt(); > > > > =A0 =A0 ... > > > > =A0 } > > > > > > > > =A0 isatap_xmt() { > > > > =A0 =A0 ... > > > > =A0 =A0 if (v6src =3D=3D "foreign_prefix::0200:5efe:") > > > > =A0 =A0 =A0 drop_pkt(); > > > > =A0 =A0 ... > > > > =A0 } > > > > > > > > Does anyone see a problem with this? > > > > > > Looks fine. > > > > OK, but since I sent this I began to wonder whether cases > > 1) and 2) should be reversed (i.e., do the 0x00:5EFE check > > first). I came to believe that it almost doesn't matter > > from a performance standpoint, and perhaps should be left > > up to the implementer. Do you have an opinion on this? > > > > > > 3) For ISATAP/VET routers that use private IPv4 addresses > > > > and that do not have assurance that their neighbor cache > > > > is coherent, the router can make the checks that Christian > > > > has proposed. But, will we see any of these case 3) > > > > situations in operational practice? > > > > > > > > > > I can not tell for sure. Why this case seems to you less plausible th= an case > > 2? > > > > Case 3) is the case in which source address spoofing within > > a private IPv4 addressing range is possible. It seems to me > > that it may correspond to either a poorly managed deployment, > > or one in which there are multiple administrative authorities > > with diverse policies and operational practices. > > >=20 > I agree. However, remember that the spoofed packet may also originate fro= m within the site, which is > very hard to defend against. Spoofing is not so hard to defend against if Secure Neighbor Discovery (SEND) is used to set up the neighbor relationships and if every packet carries a nonce that can be used to detect an off-path attack. That is only the case for VET and SEAL, however, so if source address spoofing within the site is seen as a problem then VET and SEAL should be used instead of ISATAP. Note that for the sake of consistency it might be helpful to consider VET as simply "ISATAP version 2 (ISATAPv2)". Fred fred.l.templin@boeing.com =20 =20 > > The checks that Christian proposed could be used for this > > scenario if possible. Otherwise, the best solution IMHO > > would be to allow only routers (and not hosts) on the > > virtual links. This final model would be best addressed > > by VET and SEAL rather than ISATAP. > > > > Thanks - Fred > > fred.l.templin@boeing.com =20 From owner-v6ops@ops.ietf.org Tue Sep 29 09:12: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 78DC128C185 for ; Tue, 29 Sep 2009 09:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.134 X-Spam-Level: X-Spam-Status: No, score=-105.134 tagged_above=-999 required=5 tests=[AWL=-0.639, 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 ZOMxuh0ib1tC for ; Tue, 29 Sep 2009 09:12:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 150A028C176 for ; Tue, 29 Sep 2009 09:12:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsfJe-000Ewh-9o for v6ops-data0@psg.com; Tue, 29 Sep 2009 16:12:38 +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 1MsfJO-000EsQ-3a for v6ops@ops.ietf.org; Tue, 29 Sep 2009 16:12:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=37140; q=dns/txt; s=sjiport01001; t=1254240742; x=1255450342; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Fred=20Baker=20|Subject:=20Fwd: =20Review=20of=20draft-ietf-v6ops-v6inixp-02.txt=20|Date: =20Tue,=2029=20Sep=202009=2009:12:20=20-0700|Message-Id: =20<7314F11F-7BB4-4D53-AC78-083635B6E953@cisco.com>|To: =20IPv6=20Operations=20|Mime-Version: =201.0=20(Apple=20Message=20framework=20v936)|References: =20<4AC20423.7080102@renater.fr>; bh=GAMjEhYKVKLQfJ+0gH0Yo46v5aA8J/K7moEFaXQ6Ynw=; b=UvfwL261uFnQrd++mRzzbFLLmVOk9/V+1LgyPCE8gt4UZWh8zrFAqarc iaM6kVrTEvgL5pUyoqORJq+M4fbovY1DV5DC8y+1q2K6An9Y+eDuT0Afl pdqLOsXpyTQqJ3ewndCjKwL9GNFo5pWMgaeO61u4OXi+dbwYV+LSopUkM k=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (partially verified [37103 bytes] [TEST]) header.i=fred@cisco.com X-Files: BTreview_draft-ietf-v6ops-v6inixp-02.doc : 21842 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcEAPHOwUqrR7MV/2dsb2JhbACZWaV3iFMBkAsFhB6BXQ X-IronPort-AV: E=Sophos;i="4.44,474,1249257600"; d="doc'?scan'208";a="248526257" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Sep 2009 16:12:21 +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 n8TGCLbu019194 for ; Tue, 29 Sep 2009 09:12:21 -0700 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8TGBQGL016796 for ; Tue, 29 Sep 2009 16:12:20 GMT Message-Id: <7314F11F-7BB4-4D53-AC78-083635B6E953@cisco.com> From: Fred Baker To: IPv6 Operations Content-Type: multipart/mixed; boundary=Apple-Mail-233-1055633263 Mime-Version: 1.0 (Apple Message framework v936) Subject: Fwd: Review of draft-ietf-v6ops-v6inixp-02.txt Date: Tue, 29 Sep 2009 09:12:20 -0700 References: <4AC20423.7080102@renater.fr> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=37103; t=1254240741; x=1255104741; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20Review=20of=20draft-ietf-v6ops-v6inixp -02.txt=20 |Sender:=20; bh=I9qCP3c9dNZ42KBBEcsHZLEt0xpXikhFv8jg1gf0i/4=; b=hvVqPQ0ww/qWd9Xg+WTj1bb2sBrNyILW2LjpU3UrSCha4pVmgCmnUGr6Q+ AnZAFEE6DcXI+1iCce1mEFbfxfh74xKjrx+qDPx0FjS7QpXTkwL+K/qGyNUX ZeUrAxfvLXTKKJXjhsOazjJdPavwh/9dkNZ3bPiVbMINXPYzhBn8c=; Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-233-1055633263 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Bernard reviewed draft-ietf-v6ops-v6inixp-02.txt for the working group. Begin forwarded message: > From: Bernard Tuy > Date: September 29, 2009 5:57:07 AM PDT > To: fred.baker@cisco.com, kurtis@kurtis.pp.se > Cc: Roque Gagliano , alain aina > Subject: Review of draft-ietf-v6ops-v6inixp-02.txt > Reply-To: tuy@renater.fr > > > ====BT: Dear Chairmen, > > As proposed at the last IETF meeting in Stockholm, I reviewed the > draft mentioned in the subject line. > > As said to the author (in Cc:), I find it useful and quite complete. > > Though, I suggest to gather information related to monitoring IPv6 > traffic and switch resources, in a dedicated paragraph. > > Couple of typos and misspellings have been corrected as well. > > I attach to this email the modified version of this draft I sent > back to the author. > > If I've something more to do for this review process, please just > let me know. > > Thanx & cheers, > > +Bernard T. > > PJ: 1 --Apple-Mail-233-1055633263 Content-Disposition: attachment; filename=BTreview_draft-ietf-v6ops-v6inixp-02.doc Content-Type: application/msword; x-unix-mode=0666; name="BTreview_draft-ietf-v6ops-v6inixp-02.doc" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0AInternet=20Engineering=20Task=20Force=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= R.=20Gagliano=0D=0AInternet-Draft=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20LACNIC=0D=0AIntended=20status:=20= Informational=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20September=2008,=202009=0D=0AExpires:=20March=2012,=202010=0D=0A= =0D=0A=0D=0A=20=20=20=20=20=20=20=20=20=20=20IPv6=20Deployment=20in=20= Internet=20Exchange=20Points=20(IXPs)=0D=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20draft-ietf-v6ops-v6inixp-02.txt=0D=0A=0D=0A= Status=20of=20this=20Memo=0D=0A=0D=0A=20=20=20This=20Internet-Draft=20is=20= submitted=20to=20IETF=20in=20full=20conformance=20with=20the=0D=0A=20=20=20= provisions=20of=20BCP=2078=20and=20BCP=2079.=0D=0A=0D=0A=20=20=20= Internet-Drafts=20are=20working=20documents=20of=20the=20Internet=20= Engineering=0D=0A=20=20=20Task=20Force=20(IETF),=20its=20areas,=20and=20= its=20working=20groups.=20=20Note=20that=0D=0A=20=20=20other=20groups=20= may=20also=20distribute=20working=20documents=20as=20Internet-=0D=0A=20=20= =20Drafts.=0D=0A=0D=0A=20=20=20Internet-Drafts=20are=20draft=20documents=20= valid=20for=20a=20maximum=20of=20six=20months=0D=0A=20=20=20and=20may=20= be=20updated,=20replaced,=20or=20obsoleted=20by=20other=20documents=20at=20= any=0D=0A=20=20=20time.=20=20It=20is=20inappropriate=20to=20use=20= Internet-Drafts=20as=20reference=0D=0A=20=20=20material=20or=20to=20cite=20= them=20other=20than=20as=20"work=20in=20progress."=0D=0A=0D=0A=20=20=20= The=20list=20of=20current=20Internet-Drafts=20can=20be=20accessed=20at=0D= =0A=20=20=20http://www.ietf.org/ietf/1id-abstracts.txt.=0D=0A=0D=0A=20=20= =20The=20list=20of=20Internet-Draft=20Shadow=20Directories=20can=20be=20= accessed=20at=0D=0A=20=20=20http://www.ietf.org/shadow.html.=0D=0A=0D=0A=20= =20=20This=20Internet-Draft=20will=20expire=20on=20March=2012,=202010.=0D= =0A=0D=0ACopyright=20Notice=0D=0A=0D=0A=20=20=20Copyright=20(c)=202009=20= IETF=20Trust=20and=20the=20persons=20identified=20as=20the=0D=0A=20=20=20= document=20authors.=20=20All=20rights=20reserved.=0D=0A=0D=0A=20=20=20= This=20document=20is=20subject=20to=20BCP=2078=20and=20the=20IETF=20= Trust's=20Legal=0D=0A=20=20=20Provisions=20Relating=20to=20IETF=20= Documents=20in=20effect=20on=20the=20date=20of=0D=0A=20=20=20publication=20= of=20this=20document=20(http://trustee.ietf.org/license-info).=0D=0A=20=20= =20Please=20review=20these=20documents=20carefully,=20as=20they=20= describe=20your=20rights=0D=0A=20=20=20and=20restrictions=20with=20= respect=20to=20this=20document.=0D=0A=0D=0AAbstract=0D=0A=0D=0A=20=20=20= This=20document=20provides=20a=20guide=20for=20IPv6=20deployment=20in=20= Internet=0D=0A=20=20=20Exchange=20Points=20(IXP).=20=20It=20includes=20= information=20regarding=20the=20switch=0D=0A=20=20=20fabric=20= configuration,=20the=20addressing=20plan=20and=20general=20= organizational=0D=0A=0D=0A=0D=0A=0D=0AGagliano=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Expires=20March=2012,=202010=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=201]=0D=0A=0D=0A=0D=0AInternet-Draft=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20IPv6=20in=20IXPs=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20September=202009=0D=0A=0D=0A=0D=0A=20= =20=20tasks=20to=20be=20performed.=20=20IXPs=20are=20mainly=20a=20layer=20= 2=20infrastructure=20and=0D=0A=20=20=20in=20many=20case=20the=20best=20= recommendations=20state=20that=20the=20IPv6=20data,=0D=0A=20=20=20= control=20and=20management=20plane=20should=20not=20be=20handled=20= differently=20than=0D=0A=20=20=20in=20IPv4.=0D=0A=0D=0A=0D=0ATable=20of=20= Contents[BT1]=0D=0A=0D=0A=20=20=201.=20=20Introduction=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20=203=0D=0A=20=20=202.=20=20Switch=20Fabric=20Configuration=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=20= 3=0D=0A=20=20=203.=20=20Addressing=20Plan=20=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=204=0D=0A= =20=20=204.=20=20Multicast=20IPv6=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=206=0D=0A=20= =20=205.=20=20Reverse=20DNS=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=207=0D=0A=20= =20=206.=20=20Route=20Server=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=207=0D=0A=20=20=20= 7.=20=20External=20and=20Internal=20support=20=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=207=0D=0A=20=20=208.=20=20IXP=20= Policies=20and=20IPv6=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=208=0D=0A=20=20=209.=20=20IANA=20= Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=208=0D=0A=20=20=2010.=20Security=20= Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20=208=0D=0A=20=20=2011.=20Acknowledgements=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20=208=0D=0A=20=20=2012.=20References=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20=208=0D=0A=20=20=20=20=2012.1.=20=20Normative=20References=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= =208=0D=0A=20=20=20=20=2012.2.=20=20Informative=20References=20=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2010=0D=0A=20=20= =20Author's=20Address=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2010=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0AGagliano=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Expires=20= March=2012,=202010=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [Page=202]=0D=0A=0D=0A=0D=0AInternet-Draft=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20IPv6=20in=20IXPs=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20September=202009=0D=0A=0D=0A=0D=0A1.=20=20Introduction=0D=0A=0D=0A=20= =20=20Most=20Internet=20Exchange=20Points=20(IXP)=20work=20on=20the=20= Layer=202=20level,=20making=0D=0A=20=20=20the=20adoption=20of=20IPv6=20= an=20easy=20task.=20=20However,=20IXPs=20normally=20implement=0D=0A=20=20= =20additional=20services=20such=20as=20statistics,=20route=20servers,=20= looking=0D=0A=20=20=20glasses=20and=20broadcast=20control=20that=20may=20= be=20impacted=20by=20the=0D=0A=20=20=20implementation=20of=20IPv6.=20=20= This=20document=20clarifies=20the=20impact=20of=20IPv6=0D=0A=20=20=20on=20= a=20new=20or=20an=20existing=20IXP=20that=20may=20or=20may=20not=20fit=20= any=20particular=0D=0A=20=20=20deployment.=20=20The=20document=20assumes=20= an=20Ethernet=20switch=20fabric,=20although=0D=0A=20=20=20other=20layer=20= 2=20configurations=20can=20be=20deployed.=0D=0A=0D=0A=0D=0A2.=20=20= Switch=20Fabric=20Configuration=0D=0A=0D=0A=20=20=20An=20Ethernet=20= based=20IXP=20switch=20fabric=20implements=20IPv6=20over=20Ethernet=20as=0D= =0A=20=20=20described=20in=20[RFC2464].=20=20Therefore,=20the=20= switching=20of=20IPv6=20traffic=0D=0A=20=20=20happens=20in=20the=20same=20= way=20as=20in=20IPv4.=20=20However,=20some=20management=0D=0A=20=20=20= functions=20require=20explicit=20IPv6=20support=20(such=20as=20switch=20= management,=0D=0A=20=20=20SNMP=20support=20and=20flow=20analysis=20= exportation)=20and=20this=20should=20be=0D=0A=20=20=20assessed=20by=20= the=20IXP=20operator.=0D=0A=0D=0A=20=20=20There=20are=20two=20common=20= configurations=20of=20IXP=20switch=20ports=20to=20support=0D=0A=20=20=20= IPv6:=0D=0A=0D=0A=20=20=201.=20=20dual=20stack=20LAN:=20both=20IPv4=20= and=20IPv6=20traffic=20share=20a=20common=20LAN.=0D=0A=20=20=20=20=20=20=20= No=20extra=20configuration=20is=20required=20in=20the=20switch.=20=20In=20= this=0D=0A=20=20=20=20=20=20=20scenario,=20participants=20will=20= typically=20configure=20dual=20stack=0D=0A=20=20=20=20=20=20=20= interfaces,=20although=20independent=20port=20can=20be=20an=20option.=0D=0A= =0D=0A=20=20=202.=20=20independent=20LAN:=20an=20exclusive=20IPv6=20LAN=20= is=20created=20for=20IPv6=0D=0A=20=20=20=20=20=20=20traffic.=20=20If=20= IXP=20participants=20are=20already=20using=20Virtual=20LAN=0D=0A=20=20=20= =20=20=20=20(VLAN)=20tagging=20on=20their=20routers=20interfaces=20that=20= are=20facing=20the=0D=0A=20=20=20=20=20=20=20IXP=20switch,=20this=20only=20= requires=20passing=20one=20additional=20VLAN=20tag=0D=0A=20=20=20=20=20=20= =20across=20the=20interconnection.=20=20If=20participants=20are=20using=20= untagged=0D=0A=20=20=20=20=20=20=20interconnections=20with=20the=20IXP=20= switch=20and=20wish=20to=20continue=20doing=0D=0A=20=20=20=20=20=20=20= so,=20they=20will=20need=20to=20facilitate=20a=20separate=20physical=20= port=20to=0D=0A=20=20=20=20=20=20=20access=20the=20IPv6-specific=20LAN.=0D= =0A=0D=0A=20=20=20The=20"independent=20LAN"=20configuration=20provides=20= a=20physical=20separation=0D=0A=20=20=20for=20IPv4=20and=20IPv6=20= traffic=20simplifying=20separate=20analysis=20for=20IPv4=20and=0D=0A=20=20= =20IPv6=20traffic.=20=20However,=20it=20can=20be=20more=20costly=20in=20= both=20capital=0D=0A=20=20=20expenses=20(if=20new=20ports=20are=20= needed)=20and=20operational=20expends.=0D=0A=20=20=20Conversely,=20the=20= dual=20stack=20implementation=20allows=20a=20quick=20and=20capital=0D=0A=20= =20=20cost-free=20start-up=20for=20IPv6=20support=20in=20the=20IXP,=20= allowing=20the=20IXP=20to=0D=0A=20=20=20avoid=20transforming=20untagged=20= ports=20into=20tagged=20ports.=20=20In=20this=0D=0A=20=20=20= implementation,=20traffic-split=20for=20statistical=20analysis=20may=20= be=20done=0D=0A=20=20=20using=20flows=20techniques=20such=20as=20IPFIX=20= [RFC5101]=20considering=20the=0D=0A=20=20=20different=20ether-types=20= (0x0800=20for=20IPv4,=200x0806=20for=20ARP=20and=200x86DD=20for=0D=0A=0D=0A= =0D=0A=0D=0AGagliano=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Expires=20March=2012,=202010=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=203]=0D=0A=0D=0A=0D=0AInternet-Draft=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20IPv6=20in=20IXPs=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20September=202009=0D=0A=0D=0A=0D=0A=20=20=20IPv6).=0D=0A=0D=0A= =20=20=20The=20only=20technical=20requirement=20for=20IPv6=20referring=20= link=20MTUs=20is=20that=0D=0A=20=20=20they=20need=20to=20be=20greater=20= than=20or=20equal=20to=201280=20octets=20[RFC2460].=0D=0A=20=20=20Common=20= MTU=20sizes=20in=20IXPs=20are=201500,=204470,=20or=209216=20bytes.=0D=0A=20= =20=20Consequently,=20no=20MTU=20changes=20are=20typically=20required.=20= =20The=20MTU=20size=0D=0A=20=20=20for=20every=20LAN=20in=20an=20IXP=20= should=20be=20well=20known=20by=20all=20its=20participants.=0D=0A=0D=0A=0D= =0A3.=20=20Addressing=20Plan=0D=0A=0D=0A=20=20=20Regional=20Internet=20= Registries=20(RIRs)=20have=20specific=20address=20policies=20to=0D=0A=20=20= =20allocate=20Provider=20Independent=20(PI)=20IPv6=20address=20to=20= IXPs.=20=20Those=0D=0A=20=20=20allocations=20are=20usually=20/48=20or=20= shorter=20prefixes=20[RIR_IXP_POLICIES].=0D=0A=20=20=20Depending=20on=20= the=20country=20and=20region=20of=20operation,=20address=20allocations=0D= =0A=20=20=20may=20be=20provided=20by=20NIRs=20(National=20Internet=20= Registries).=20=20Unique=20Local=0D=0A=20=20=20IPv6=20Unicast=20= Addresses=20([RFC4193])=20are=20normally=20not=20used=20in=20an=20IXP=0D=0A= =20=20=20LAN=20as=20global=20reverse=20DNS=20resolution=20and=20whois=20= services=20are=20required.=0D=0A=0D=0A=20=20=20=46rom=20the=20allocated=20= prefix,=20following=20the=20recommendations=20of=0D=0A=20=20=20= [RFC4291],=20a=20/64=20prefix=20should=20be=20allocated=20for=20each=20= of=20the=20exchange=0D=0A=20=20=20point=20IPv6=20enabled=20LANs.=20=20A=20= /48=20prefix=20allows=20the=20addressing=20of=2065536=0D=0A=20=20=20= LANs.=20=20As=20IXP=20will=20normally=20use=20manual=20address=20= configuration,=20longer=0D=0A=20=20=20prefixes=20(/65-/127),=20are=20= technically=20feasible=20but=20are=20normally=0D=0A=20=20=20discouraged=20= because=20of=20operational=20practices.=20=20The=20manual=0D=0A=20=20=20= configuration=20of=20IPv6=20addresses=20allows=20IXP=20participants=20to=20= replace=0D=0A=20=20=20network=20interfaces=20with=20no=20need=20to=20= reconfigure=20Border=20Gateway=0D=0A=20=20=20Protocol=20(BGP)=20sessions=20= information=20and=20it=20also=20facilitates=0D=0A=20=20=20management=20= tasks.=0D=0A=0D=0A=20=20=20When=20selecting=20the=20use=20of=20static=20= Interface=20Identifiers=20(IIDs),=20there=0D=0A=20=20=20are=20different=20= options=20on=20how=20to=20"intelligently"=20fill=20its=2064=20bits=20(or=0D= =0A=20=20=2016=20hexadecimal=20characters).=20=20A=20non-exhausted=20= list=20of=20possible=20IID=0D=0A=20=20=20selection=20mechanisms=20is=20= the=20following:=0D=0A=0D=0A=20=20=201.=20=20Some=20IXPs=20like=20to=20= include=20the=20participants'=20ASN=20number=20decimal=0D=0A=20=20=20=20=20= =20=20encoding=20inside=20each=20IPv6=20address.=20=20The=20ASN=20= decimal=20number=20is=0D=0A=20=20=20=20=20=20=20used=20as=20the=20BCD=20= (binary=20code=20decimal)=20encoding=20of=20the=20upper=20part=0D=0A=20=20= =20=20=20=20=20of=20the=20IID=20such=20as=20shown=20in=20this=20example:=0D= =0A=0D=0A=20=20=20=20=20=20=20*=20=20IXP=20LAN=20prefix:=202001:DB8::/64=0D= =0A=0D=0A=20=20=20=20=20=20=20*=20=20ASN:=2064496=0D=0A=0D=0A=20=20=20=20= =20=20=20*=20=20IPv6=20Address:=202001:DB8::0000:0006:4496:0001/64=20or=20= its=0D=0A=20=20=20=20=20=20=20=20=20=20equivalent=20representation=20= 2001:DB8::6:4496:1/64=0D=0A=0D=0A=20=20=20=20=20=20=20In=20this=20= example=20we=20are=20right=20justifying=20the=20participant'=20ASN=0D=0A=0D= =0A=0D=0A=0D=0AGagliano=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Expires=20March=2012,=202010=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=204]=0D=0A=0D=0A=0D=0AInternet-Draft=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20IPv6=20in=20IXPs=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20September=202009=0D=0A=0D=0A=0D=0A=20=20=20=20=20=20=20= number=20from=20the=20112nd=20bit.=20=20Remember=20that=2032=20bits=20= ASNs=20require=20a=0D=0A=20=20=20=20=20=20=20maximum=20of=2010=20= characters.=20=20With=20this=20example,=20up=20to=202^16[BT2]=20IPv6=0D=0A= =20=20=20=20=20=20=20addresses=20can=20be=20configured=20per=20ASN.=0D=0A= =0D=0A=20=20=202.=20=20Although=20BCD=20encoding=20is=20more=20= "human-readable",=20some=20IXPs=20prefer=0D=0A=20=20=20=20=20=20=20to=20= use=20the=20hexadecimal=20encoding=20of=20the=20ASNs=20number=20as=20the=20= upper=0D=0A=20=20=20=20=20=20=20part=20of=20the=20IID=20as=20follow:=0D=0A= =0D=0A=20=20=20=20=20=20=20*=20=20IXP=20LAN=20prefix:=202001:DB8::/64=0D=0A= =0D=0A=20=20=20=20=20=20=20*=20=20ASN:=2064496=20(DEC)=20or=20FBF0=20= (HEX)=0D=0A=0D=0A=20=20=20=20=20=20=20*=20=20IPv6=20Address:=20= 2001:DB8::0000:0000:FBF0:0001/64=20or=20its=0D=0A=20=20=20=20=20=20=20=20= =20=20equivalent=20representation=202001:DB8::FBF0:1/64=0D=0A=0D=0A=20=20= =203.=20=20A=20third=20scheme=20for=20statically=20assigning=20IPv6=20= addresses=20on=20an=20IXP=0D=0A=20=20=20=20=20=20=20LAN=20could=20be=20= to=20relate=20some=20portion=20of=20a=20participant's=20IPv6=0D=0A=20=20=20= =20=20=20=20address=20to=20its=20IPv4=20address.=20=20In=20the=20= following=20example,=20the=20last=0D=0A=20=20=20=20=20=20=20three=20= decimals=20of=20the=20IPv4=20address=20are=20copied=20to=20the=20last=0D=0A= =20=20=20=20=20=20=20hexadecimals=20of=20the=20IPv6=20address,=20using=20= the=20decimal=20number=20as=20the=0D=0A=20=20=20=20=20=20=20BCD=20= encoding=20for=20the=20last=20three=20characters=20of=20the=20IID=20such=20= as=20in=0D=0A=20=20=20=20=20=20=20the=20following=20example:=0D=0A=0D=0A=20= =20=20=20=20=20=20*=20=20IXP=20LAN=20prefix:=202001:DB8::/64=0D=0A=0D=0A=20= =20=20=20=20=20=20*=20=20IPv4=20Address:=20240.0.20.132/23=0D=0A=0D=0A=20= =20=20=20=20=20=20*=20=20IPv6=20Address:=202001:DB8::132/64=0D=0A=0D=0A=20= =20=204.=20=20A=20fourth=20approach=20might=20be=20based=20on=20the=20= IXPs=20ID=20for=20that=0D=0A=20=20=20=20=20=20=20participant.=0D=0A=0D=0A= =20=20=20The=20current=20practice=20that=20applies=20to=20IPv4=20about=20= publishing=20IXP=0D=0A=20=20=20allocations=20to=20the=20DFZ=20(Default=20= Free=20Zone)=20should=20also=20apply=20to=20the=0D=0A=20=20=20IPv6=20= allocation=20(normally=20a=20/48=20prefix).=20=20Typically=20IXPs=20LANs=20= are=20not=0D=0A=20=20=20globally=20reachable=20in=20order=20to=20avoid=20= a=20Distributed=20Denial=20of=20Service=0D=0A=20=20=20(DDoS)=20attack=20= but=20participant=20may=20route=20these=20prefixes=20inside=20their=0D=0A= =20=20=20networks=20(e.=20g.=20using=20BGP=20no-export=20communities=20= or=20routing=20the=20IXP=0D=0A=20=20=20LANs=20within=20the=20= participants'=20IGP)=20to=20perform=20fault=20management.=20=20IXP=0D=0A=20= =20=20external=20services=20(such=20as=20dns,=20web=20pages,=20ftp=20= servers)=20needs=20to=20be=0D=0A=20=20=20globally=20routed=20and=20due=20= to=20strict=20prefix=20length=20filtering=20could=20be=0D=0A=20=20=20the=20= reason=20to=20request=20more=20than=20one=20/48=20assignment=20from=20a=20= RIR=20(i.e.=0D=0A=20=20=20requesting=20one=20/48=20for=20the=20IXPs=20= LANs=20that=20is=20not=20globally=20routed=20and=0D=0A=20=20=20a=20= different=20/48=20for=20the=20IXP=20external=20services=20that=20is=20= globally=0D=0A=20=20=20routed).=20=20IPv6=20prefixes=20for=20IXP=20LAN's=20= are=20typically=20publicly=20well=0D=0A=20=20=20known.=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0AGagliano=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Expires=20March=2012,=202010=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=205]=0D=0A=0D=0A=0D=0AInternet-Draft=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20IPv6=20in=20IXPs=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20September=202009=0D=0A=0D=0A=0D=0A4.=20=20Multicast=20IPv6=0D= =0A=0D=0A=20=20=20There=20are=20two=20elements=20that=20need=20to=20be=20= evaluated=20when=20studying=20IPv6=0D=0A=20=20=20multicast=20in=20an=20= IXP:=20multicast=20support=20for=20neighbor=20discovery=20and=0D=0A=20=20= =20multicast=20peering.=0D=0A=0D=0A=20=20=20IXPs=20typically=20control=20= broadcast=20traffic=20across=20the=20switching=20fabric=0D=0A=20=20=20in=20= order=20to=20avoid=20broadcast=20storms=20by=20only=20allowing=20limited=20= ARP=0D=0A=20=20=20[RFC0826]=20traffic=20for=20address=20resolution.=20=20= In=20IPv6=20there=20is=20no=0D=0A=20=20=20broadcast=20support=20but=20= IXP=20may=20intend=20to=20control=20multicast=20traffic=20in=0D=0A=20=20=20= each=20LAN=20instead.=20=20ICMPv6=20Neighbor=20Discovery=20[RFC4861]=20= implements=20the=0D=0A=20=20=20following=20necessary=20functions=20in=20= an=20IXP=20switching=20fabric:=20Address=0D=0A=20=20=20Resolution,=20= Neighbor=20Unreachability=20Detection=20and=20Duplicate=20Address=0D=0A=20= =20=20Detection.=20=20In=20order=20to=20perform=20these=20functions,=20= Neighbor=0D=0A=20=20=20Solicitation=20and=20Neighbor=20Advertisement=20= packets=20are=20exchanged=20using=0D=0A=20=20=20the=20link-local=20= all-nodes=20multicast=20address=20(FF02::1)=20and/or=0D=0A=20=20=20= solicited-node=20multicast=20addresses=20(FF02:0:0:0:0:1:FF00:0000=20to=20= FF02:=0D=0A=20=20=200:0:0:0:1:FFFF:FFFF).=20=20As=20described=20in=20= [RFC4861]=20routers=20will=0D=0A=20=20=20initialize=20its=20interfaces=20= by=20joining=20its=20solicited-node=20multicast=0D=0A=20=20=20addresses=20= using=20either=20Multicast=20Listener=20Discovery=20(MLD)=20[RFC2710]=0D=0A= =20=20=20or=20MLDv2=20[RFC3810].=20=20MLD=20messages=20may=20be=20sent=20= to=20the=20corresponding=0D=0A=20=20=20group=20address=20FF02::2=20(MLD)=20= or=20FF02::16=20(MLDv2).=20=20Depending=20on=20the=0D=0A=20=20=20= addressing=20plan=20selected=20by=20the=20IXP,=20each=20solicited-node=20= multicast=0D=0A=20=20=20group=20may=20be=20shared=20by=20a=20sub-set=20= of=20participants'=20conditioned=20by=20how=0D=0A=20=20=20the=20last=20= three=20octects=20of=20the=20addresses=20are=20selected.=20=20In=20= Section=203=0D=0A=20=20=20example=201,=20only=20participants=20with=20= ASNs=20with=20the=20same=20two=20last=20digits=0D=0A=20=20=20are=20going=20= to=20share=20the=20same=20solicited-node=20multicast=20group[BT3].=0D=0A=0D= =0A=20=20=20Similarly=20to=20the=20ARP=20policy=20an=20IXP=20may=20limit=20= multicast=20traffic=0D=0A=20=20=20accross=20the=20switching=20fabric=20= in=20order=20to=20only=20allow=20ICMPv6=20Neighbor=0D=0A=20=20=20= Solicitation,=20Neighbor=20Advertisement=20and=20MLD=20messages.=20=20= Configuring=0D=0A=20=20=20default=20routes=20in=20an=20IXP=20LAN=20= without=20an=20agreement=20within=20the=20parties=0D=0A=20=20=20is=20= normally=20against=20IXP=20policies.=20=20ICMPv6=20Router=20= Advertisement=0D=0A=20=20=20packets=20should=20neither=20be=20issued=20= nor=20accepted=20by=20routers=20connected=20to=0D=0A=20=20=20the=20IXP.=20= =20Where=20possible,=20the=20IXP=20operator=20should=20block=20= link-local=20RA=0D=0A=20=20=20packets=20using=20IPv6=20RA-Guard.=20=20If=20= this=20is=20not=20possible,=20the=20IXP=0D=0A=20=20=20operator=20should=20= monitor=20the=20exchange=20for=20rogue=20Router=20Advertisement=0D=0A=20=20= =20packets.=0D=0A=0D=0A=20=20=20For=20IPv6=20Multicast=20traffic=20= exchange,=20an=20IXP=20may=20decide=20to=20use=20either=0D=0A=20=20=20= the=20same=20LAN=20being=20used=20for=20unicast=20IPv6=20traffic=20= exchange,=20the=20same=0D=0A=20=20=20LAN=20being=20used=20for=20IPv4=20= Multicast=20traffic=20exchange=20or=20a=20dedicated=20LAN=0D=0A=20=20=20= for=20IPv6=20Multicast=20traffic=20exchange.=20=20The=20reason=20for=20= having=20a=0D=0A=20=20=20dedicated=20LAN=20for=20multicast=20is=20to=20= prevent=20unwanted=20multicast=20traffic=0D=0A=20=20=20to=20reach=20= participants=20that=20do=20not=20have=20multicast=20support.=20=20= Protocol=0D=0A=20=20=20Independent=20Multicast=20[RFC4601]=20messages=20= will=20be=20sent=20to=20the=20=0D=0A=20=20=20link-local=20IPv6=20= 'ALL-PIM-ROUTERS'=20multicast=20group=20ff02::d=20in=20the=0D=0A=20=20=20= selected=20LAN=20and=20should=20be=20allowed.=20=20Implementing=20IPv6=20= PIM=20snooping=0D=0A=0D=0A=0D=0A=0D=0AGagliano=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Expires=20March=2012,=202010=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20[Page=206]=0D=0A=0D=0A=0D=0AInternet-Draft=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20IPv6=20in=20IXPs=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20September=202009=0D=0A=0D=0A=0D=0A=20= =20=20will=20allow=20only=20the=20participants=20associated=20to=20a=20= particular=20group=20to=0D=0A=20=20=20receive=20its=20multicast=20= traffic.=20=20BGP=20reachability=20information=20for=20IPv6=0D=0A=20=20=20= multicast=20address-family=20(SAFI=3D2)=20is=20normally=20exchanged=20= using=20MP-BGP=0D=0A=20=20=20[RFC4760]=20and=20is=20used=20for=20Reverse=20= Path=20Forwarding=20(RPF)=20lookups=0D=0A=20=20=20performed=20by=20the=20= IPv6=20PIM.=20=20If=20a=20dedicated=20LAN=20is=20configured=20for=0D=0A=20= =20=20Multicast=20IPv6=20traffic=20exchange,=20reachability=20= information=20for=20IPv6=0D=0A=20=20=20Multicast=20address=20family=20= should=20be=20carried=20in=20new=20BGP=20sessions.=0D=0A=20=20=20ICMPv6=20= Neighbor=20Discovery=20should=20be=20allowed=20in=20the=20Multicast=20= IPv6=20LAN=0D=0A=20=20=20as=20described=20in=20the=20previous=20= paragraph.=0D=0A=0D=0A=0D=0A5.=20=20Reverse=20DNS=0D=0A=0D=0A=20=20=20= PTR=20records=20for=20all=20addresses=20assigned=20to=20participants=20= should=20be=0D=0A=20=20=20included=20in=20the=20IXP=20reverse=20zone=20= under=20"ip6.arpa"=20for=20troubleshooting=0D=0A=20=20=20purposes.=20=20= DNS=20servers=20should=20be=20reachable=20over=20IPv6=20transport=20for=0D= =0A=20=20=20complete=20IPv6=20support.=0D=0A=0D=0A=0D=0A6.=20=20Route=20= Server=0D=0A=0D=0A=20=20=20IXPs=20may=20offer=20a=20Route=20Server=20= service,=20either=20for=20Multi-Lateral=0D=0A=20=20=20Peering=20= Agreements=20(MLPA)=20service,=20looking=20glass=20service=20or=20route-=0D= =0A=20=20=20collection=20service.=20=20IPv6=20support=20needs=20to=20be=20= added=20to=20the=20BGP=0D=0A=20=20=20speaking=20router.=20=20The=20= equipment=20should=20be=20able=20to=20transport=20IPv6=0D=0A=20=20=20= traffic=20and=20to=20support=20Multi-protocol=20BGP=20(MP-BGP)=20= extensions=20for=0D=0A=20=20=20IPv6=20address=20family=20([RFC2545]=20= and=20[RFC4760]).=0D=0A=0D=0A=20=20=20A=20good=20practice=20is=20that=20= all=20BGP=20sessions=20used=20to=20exchange=20IPv6=0D=0A=20=20=20network=20= information=20are=20configured=20using=20IPv6=20data=20transport.=20=20= This=0D=0A=20=20=20configuration=20style=20ensures=20that=20both=20= network=20reachability=0D=0A=20=20=20information=20and=20generic=20= packet=20data=20transport=20use=20the=20same=20transport=0D=0A=20=20=20= plane.=20In=20the=20event=20of=20IPv6=20reachability=20problems=20= between=20IPv6=20peers,=0D=0A=20=20=20the=20IPv6=20BGP=20session=20may=20= be=20terminated=20independently=20of=20any=20IPv4=0D=0A=20=20=20= sessions.=20=20The=20use=20of=20MD5=20[RFC2385]=20or=20IPSEC=20[RFC4301]=20= to=0D=0A=20=20=20authenticate=20the=20BGP=20sessions=20and=20the=20use=20= of=20GTSM=20(The=20Generalized=0D=0A=20=20=20TTL=20Security=20Mechanism)=20= [RFC3682]=20should=20be=20considered.=0D=0A=0D=0A=20=20=20The=20= Route-Server=20or=20Looking=20Glass=20external=20service=20should=20be=0D= =0A=20=20=20available=20for=20external=20IPv6=20access,=20either=20by=20= an=20IPv6=20enabled=20web=0D=0A=20=20=20page=20or=20an=20IPv6=20enabled=20= console=20interface.=0D=0A=0D=0A=0D=0A7.=20=20External=20and=20Internal=20= support=0D=0A=0D=0A=20=20=20Some=20external=20services=20that=20need=20= to=20have=20IPv6=20support=20are=20traffic=0D=0A=20=20=20graphics,=20= DNS,=20FTP,=20Web,=20Route=20Server=20and=20Looking=20Glass.=20=20Other=0D= =0A=20=20=20external=20services=20such=20as=20NTP=20servers,=20or=20SIP=20= Gateways=20need=20to=20be=0D=0A=0D=0A=0D=0A=0D=0AGagliano=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20Expires=20March=2012,=202010=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20[Page=207]=0D=0A=0D=0A=0D=0A= Internet-Draft=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20IPv6=20in=20= IXPs=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20September=202009=0D=0A= =0D=0A=0D=0A=20=20=20evaluated=20as=20well.=20=20In=20general,=20each=20= service=20that=20is=20currently=0D=0A=20=20=20accessed=20through=20IPv4=20= or=20that=20handle=20IPv4=20addresses=20should=20be=0D=0A=20=20=20= evaluated=20for=20IPv6=20support.=0D=0A=0D=0A=20=20=20Internal=20= services=20are=20also=20important=20when=20considering=20IPv6=20adoption=0D= =0A=20=20=20at=20an=20IXP.=20=20Such=20services=20may=20not=20deal=20= with=20IPv6=20traffic=20but=20may=0D=0A=20=20=20handle=20IPv6=20= addresses;=20that=20is=20the=20case=20of=20provisioning=20systems,=0D=0A=20= =20=20logging=20tools=20and=20statistics=20analysis=20tools.=20=20= Databases=20and=20tools=0D=0A=20=20=20should=20be=20evaluated=20for=20= IPv6=20support.=0D=0A=0D=0A=0D=0A8.=20=20IXP=20Policies=20and=20IPv6=0D=0A= =0D=0A=20=20=20IXP=20Policies=20and=20contracts=20should=20be=20revised=20= as=20any=20mention=20of=20IP=0D=0A=20=20=20should=20be=20clarified=20if=20= it=20refers=20to=20IPv4,=20IPv6=20or=20both.=0D=0A=0D=0A=0D=0A9.=20=20= IANA=20Considerations=0D=0A=0D=0A=20=20=20This=20memo=20includes=20no=20= request=20to=20IANA.=0D=0A=0D=0A=0D=0A10.=20=20Security=20Considerations=0D= =0A=0D=0A=20=20=20This=20memo=20includes=20information=20on=20practices=20= at=20IXPs=20for=20monitoring=0D=0A=20=20=20and/or=20avoiding=20broadcast=20= storms=20in=20IXP=20LANs=20caused=20by=20IPv6=20multicast=0D=0A=20=20=20= traffic.=20=20It=20also=20mentions=20avoiding=20IPv6=20DDoS=20attacks=20= to=20the=20IXP=0D=0A=20=20=20switching=20fabric=20by=20not=20globally=20= announce=20the=20IXP=20LANs=20prefix=20and=20recommend=20to=20filter=20= out=20RA=20messages.=0D=0A=0D=0A=0D=0A11.=20=20Acknowledgements=0D=0A=0D=0A= =20=20=20The=20author=20would=20like=20to=20thank=20the=20contributions=20= from=20Stig=20Venaas,=0D=0A=20=20=20Martin=20Levy,=20Nick=20Hilliard,=20= Martin=20Pels,=20Bill=20Woodcock,=20Carlos=20Frias,=0D=0A=20=20=20Arien=20= Vijn=20and=20Louis=20Lee.=0D=0A=0D=0A=0D=0A12.=20=20References=0D=0A=0D=0A= 12.1.=20=20Normative=20References=0D=0A=0D=0A=20=20=20[RFC0826]=20=20= Plummer,=20D.,=20"Ethernet=20Address=20Resolution=20Protocol:=20Or=0D=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20converting=20network=20protocol=20= addresses=20to=2048.bit=20Ethernet=0D=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20address=20for=20transmission=20on=20Ethernet=20hardware",=20STD=20= 37,=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20RFC=20826,=20November=20= 1982.=0D=0A=0D=0A=20=20=20[RFC2119]=20=20Bradner,=20S.,=20"Key=20words=20= for=20use=20in=20RFCs=20to=20Indicate=0D=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20Requirement=20Levels",=20BCP=2014,=20RFC=202119,=20March=20= 1997.=0D=0A=0D=0A=0D=0A=0D=0AGagliano=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20Expires=20March=2012,=202010=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20[Page=208]=0D=0A=0D=0A=0D=0AInternet-Draft=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20IPv6=20in=20IXPs=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20September=202009=0D=0A=0D=0A=0D=0A=20=20=20= [RFC2385]=20=20Heffernan,=20A.,=20"Protection=20of=20BGP=20Sessions=20= via=20the=20TCP=20MD5=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Signature=20Option",=20RFC=202385,=20August=201998.=0D=0A=0D=0A=20=20=20= [RFC2460]=20=20Deering,=20S.=20and=20R.=20Hinden,=20"Internet=20= Protocol,=20Version=206=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= (IPv6)=20Specification",=20RFC=202460,=20December=201998.=0D=0A=0D=0A=20=20= =20[RFC2464]=20=20Crawford,=20M.,=20"Transmission=20of=20IPv6=20Packets=20= over=20Ethernet=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Networks",=20RFC=202464,=20December=201998.=0D=0A=0D=0A=20=20=20= [RFC2545]=20=20Marques,=20P.=20and=20F.=20Dupont,=20"Use=20of=20BGP-4=20= Multiprotocol=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20Extensions=20= for=20IPv6=20Inter-Domain=20Routing",=20RFC=202545,=0D=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20March=201999.=0D=0A=0D=0A=20=20=20[RFC2710]=20=20= Deering,=20S.,=20Fenner,=20W.,=20and=20B.=20Haberman,=20"Multicast=0D=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20Listener=20Discovery=20(MLD)=20= for=20IPv6",=20RFC=202710,=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= October=201999.=0D=0A=0D=0A=20=20=20[RFC3682]=20=20Gill,=20V.,=20= Heasley,=20J.,=20and=20D.=20Meyer,=20"The=20Generalized=20TTL=0D=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Security=20Mechanism=20(GTSM)",=20= RFC=203682,=20February=202004.=0D=0A=0D=0A=20=20=20[RFC3810]=20=20Vida,=20= R.=20and=20L.=20Costa,=20"Multicast=20Listener=20Discovery=0D=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20Version=202=20(MLDv2)=20for=20IPv6",=20= RFC=203810,=20June=202004.=0D=0A=0D=0A=20=20=20[RFC4193]=20=20Hinden,=20= R.=20and=20B.=20Haberman,=20"Unique=20Local=20IPv6=20Unicast=0D=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20Addresses",=20RFC=204193,=20October=20= 2005.=0D=0A=0D=0A=20=20=20[RFC4291]=20=20Hinden,=20R.=20and=20S.=20= Deering,=20"IP=20Version=206=20Addressing=0D=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20Architecture",=20RFC=204291,=20February=202006.=0D=0A=0D=0A= =20=20=20[RFC4301]=20=20Kent,=20S.=20and=20K.=20Seo,=20"Security=20= Architecture=20for=20the=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Internet=20Protocol",=20RFC=204301,=20December=202005.=0D=0A=0D=0A=20=20=20= [RFC4601]=20=20Fenner,=20B.,=20Handley,=20M.,=20Holbrook,=20H.,=20and=20= I.=20Kouvelas,=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20"Protocol=20= Independent=20Multicast=20-=20Sparse=20Mode=20(PIM-SM):=0D=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Protocol=20Specification=20(Revised)",=20= RFC=204601,=20August=202006.=0D=0A=0D=0A=20=20=20[RFC4760]=20=20Bates,=20= T.,=20Chandra,=20R.,=20Katz,=20D.,=20and=20Y.=20Rekhter,=0D=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20"Multiprotocol=20Extensions=20for=20= BGP-4",=20RFC=204760,=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= January=202007.=0D=0A=0D=0A=20=20=20[RFC4861]=20=20Narten,=20T.,=20= Nordmark,=20E.,=20Simpson,=20W.,=20and=20H.=20Soliman,=0D=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20"Neighbor=20Discovery=20for=20IP=20version=20= 6=20(IPv6)",=20RFC=204861,=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= September=202007.=0D=0A=0D=0A=20=20=20[RFC5101]=20=20Claise,=20B.,=20= "Specification=20of=20the=20IP=20Flow=20Information=0D=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Export=20(IPFIX)=20Protocol=20for=20the=20= Exchange=20of=20IP=20Traffic=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Flow=20Information",=20RFC=205101,=20January=202008.=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0AGagliano=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Expires=20March=2012,=202010=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[Page=209]=0D=0A=0D=0A=0D=0AInternet-Draft=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20IPv6=20in=20IXPs=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20September=202009=0D=0A=0D=0A=0D=0A12.2.=20=20Informative=20= References=0D=0A=0D=0A=20=20=20[RIR_IXP_POLICIES]=0D=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Numbers=20Resource=20Organization=20(NRO),=20= "RIRs=20Allocations=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Policies=20for=20IXP.=20NRO=20Comparison=20matrix",=202008,=0D=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20= .=0D=0A=0D=0A=0D=0A= Author's=20Address=0D=0A=0D=0A=20=20=20Roque=20Gagliano=0D=0A=20=20=20= LACNIC=0D=0A=20=20=20Rambla=20Rep=20Mexico=206125=0D=0A=20=20=20= Montevideo,=20=20=2011400=0D=0A=20=20=20UY=0D=0A=0D=0A=20=20=20Phone:=20= +598=202=204005633=0D=0A=20=20=20Email:=20roque@lacnic.net=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AGagliano=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Expires=20March=2012,=202010=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20[Page=2010]=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= [BT1]I=D5d=20like=20to=20have=20a=20dedicated=20paragraph=20on=20= =C7=CAMonitoring=CA=C8=20that=20gathers=20information=20spread=20in=20= the=20document=0D=0A[BT2]Or=202^4=CA?=0D=0A[BT3]Not=20sure=20to=20= understand=20why=20=C9=CA;)=0D=0A=0D=0A= --Apple-Mail-233-1055633263 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-233-1055633263-- From kry.tylin@bridesregistry.com Tue Sep 29 11:54: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 42A4B28C0E0 for ; Tue, 29 Sep 2009 11:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.338 X-Spam-Level: X-Spam-Status: No, score=-19.338 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_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 uDNgubIIbYxP for ; Tue, 29 Sep 2009 11:54:13 -0700 (PDT) Received: from c-98-226-153-215.hsd1.in.comcast.net (c-98-226-153-215.hsd1.in.comcast.net [98.226.153.215]) by core3.amsl.com (Postfix) with SMTP id 5E70728C105 for ; Tue, 29 Sep 2009 11:54:05 -0700 (PDT) Date: Tue, 29 Sep 2009 14:55:16 -0500 Subject: Upgraded rep watches models from 2010 From: "Virgil Peacock" To: "Phoebe Valentin" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It just came out... rep watches line on 2010... Just see them here http://ailnqlbo.cn/ From deb.joh@limoforyou.com Tue Sep 29 14:59: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 813293A682C; Tue, 29 Sep 2009 14:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.388 X-Spam-Level: X-Spam-Status: No, score=-28.388 tagged_above=-999 required=5 tests=[BAYES_80=2, 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, 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 NmnSqTlU7Q4z; Tue, 29 Sep 2009 14:59:56 -0700 (PDT) Received: from mere.chamco-ci.org (mere.chamco-ci.org [213.136.110.51]) by core3.amsl.com (Postfix) with SMTP id 97F1B3A67FE; Tue, 29 Sep 2009 14:59:27 -0700 (PDT) Date: Tue, 29 Sep 2009 18:00:38 -0500 Subject: Upgraded rep watches models from 2010 From: "Taylor Snow" To: "Johnnie Bullock" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It just came out... rep watches line on 2010... Just see them here http://aiitgbmo.cn/ From lise.k.cacho-negrete@accenture.com Wed Sep 30 06:31: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 D09703A6977 for ; Wed, 30 Sep 2009 06:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.261 X-Spam-Level: X-Spam-Status: No, score=-12.261 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, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_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_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 z89uAUKfwOcX for ; Wed, 30 Sep 2009 06:31:16 -0700 (PDT) Received: from pool-173-52-104-251.nycmny.fios.verizon.net (pool-173-52-104-251.nycmny.fios.verizon.net [173.52.104.251]) by core3.amsl.com (Postfix) with SMTP id 4B4DC3A695A for ; Wed, 30 Sep 2009 06:31:11 -0700 (PDT) To: Subject: Order Shipped -- Order #92149 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090930133113.4B4DC3A695A@core3.amsl.com> Date: Wed, 30 Sep 2009 06:31:11 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.southrepeat.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://southrepeat.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 4, B437. 440 Clements Road. London. SE96 8DG

© 2009 AMAZON, Ltd. All Rights Reserved