From Fred.L.Templin@boeing.com  Tue Sep  1 09:50:14 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A4528C889; Tue,  1 Sep 2009 09:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.615
X-Spam-Level: 
X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=0.384,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itg8TrTu2gnR; Tue,  1 Sep 2009 09:50:09 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 4C9F73A7052; Tue,  1 Sep 2009 09:49:54 -0700 (PDT)
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
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" <Fred.L.Templin@boeing.com>
To: "Gabi Nakibly" <gnakibly@yahoo.com>, "v6ops" <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 01 Sep 2009 16:49:57.0974 (UTC) FILETIME=[3D3D8760:01CA2B24]
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 16:50:15 -0000

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 "<foreign prefix>::0200:5efe:<my IP =
address>")
> =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" <Fred.L.Templin@boeing.com>
> > To: Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>
> > 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 magnusn@gmail.com  Tue Sep  1 16:45:21 2009
Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04C5C3A70CE; Tue,  1 Sep 2009 16:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsbQD2Hgnexb; Tue,  1 Sep 2009 16:45:20 -0700 (PDT)
Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id D9B673A6995; Tue,  1 Sep 2009 16:45:19 -0700 (PDT)
Received: by ewy3 with SMTP id 3so317598ewy.42 for <multiple recipients>; Tue, 01 Sep 2009 16:45:30 -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=fhYPqmPKRljGZkTWhFX5qsw15BqA0OyD92nGb5uWVyg=; b=MOXKdEOyb0F2AGsE4NklWjQD9Q4OIEFRrt0HuLHuPro1oxXlTNoIyYktI5TkwdNyLH VPHrMeFggXG0/2S+FrmrT6Qg62TO7WLS+w8eZHGS127nFKAaVoTI7Y6zg8QctfuVtI06 dPSWRNhoSFjcfFEo3F3YiKfe783Su4ykDA41Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FVKjd55+UuOuzDaBTi2+WsmpRDV9xhStcrN+ax/wysI/X6oA7eLogyKroQhXL7zG/V hUvOuBvVf/NPD3Zg3nrPWsWFeWOLDaJjbspIMDHhfcysAR1cCv1BRWgjFy6/IFlT2X4t hfJ12hq/N3I9zyByN6C7ug/+5TPGbbC/pxZF0=
MIME-Version: 1.0
Received: by 10.211.159.19 with SMTP id l19mr7966185ebo.83.1251848730061; Tue,  01 Sep 2009 16:45:30 -0700 (PDT)
Date: Tue, 1 Sep 2009 16:45:30 -0700
Message-ID: <2f57b9e60909011645w3d23f4d9m23bdbc278d84efd0@mail.gmail.com>
From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <magnusn@gmail.com>
To: iesg@ietf.org, secdir@ietf.org, toby.moncaster@bt.com, bob.briscoe@bt.com,  menth@informatik.uni-wuerzburg.de, sob@harvard.edu, slblake@petri-meat.com
Content-Type: text/plain; charset=ISO-8859-1
Subject: [secdir] Review of draft-ietf-pcn-baseline-encoding-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 23:45:21 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Overview:

Loosely, this document describes a way of pre-congestion notification
marking of packets that builds on the Explicit Congestion Notification
(RFC 3168). The marking is only carrying meaning within a given PCN
domain.

Comments:

With the caveat of not being an expert in the field this draft is
about, I find the document relatively straightforward to understand
and the Security Considerations section reasonably complete (although
it perhaps would have been useful to describe what problems that
possibly could occur should a party inject PCN-marked packets inside a
network?).

Editorial:

Maybe useful to add a brief early section providing definitions of
abbreviations?

-- Magnus

From secdir-bounces@mit.edu  Tue Sep  1 08:10:18 2009
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F6A3A7028 for <secdir@core3.amsl.com>; Tue,  1 Sep 2009 08:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.445
X-Spam-Level: 
X-Spam-Status: No, score=-7.445 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKcN3uu+OOoT for <secdir@core3.amsl.com>; Tue,  1 Sep 2009 08:10:16 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 13EBD3A700D for <secdir@ietf.org>; Tue,  1 Sep 2009 08:06:57 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n81F6OqP003085 for <secdir@ietf.org>; Tue, 1 Sep 2009 11:06:24 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n81F6M6M003079 for <secdir@PCH.mit.edu>; Tue, 1 Sep 2009 11:06:23 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n81F5tS4017328 for <secdir@mit.edu>; Tue, 1 Sep 2009 11:05:55 -0400 (EDT)
Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id BFE741D7C47B for <secdir@mit.edu>; Tue,  1 Sep 2009 11:05:26 -0400 (EDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id SLeKupmVqBAJXp2e for <secdir@mit.edu>; Tue, 01 Sep 2009 11:05:26 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org;
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABE528C7EA; Tue,  1 Sep 2009 08:04:07 -0700 (PDT)
X-Original-To: new-work@core3.amsl.com
Delivered-To: new-work@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C9828C579 for <new-work@core3.amsl.com>; Mon, 31 Aug 2009 13:48:52 -0700 (PDT)
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPm7cxvcBCU2 for <new-work@core3.amsl.com>; Mon, 31 Aug 2009 13:48:51 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 9F8AC28C581 for <new-work@ietf.org>; Mon, 31 Aug 2009 13:48:51 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from <public-new-work-request@listhub.w3.org>) id 1MiCNo-0006Ed-Sm for public-new-work-dist@listhub.w3.org; Mon, 31 Aug 2009 19:17:40 +0000
Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from <ij@w3.org>) id 1MiCNo-0006E2-46 for public-new-work@listhub.w3.org; Mon, 31 Aug 2009 19:17:40 +0000
Received: from jay.w3.org ([128.30.52.169]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from <ij@w3.org>) id 1MiCNf-0008LR-LX; Mon, 31 Aug 2009 19:17:39 +0000
Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from <ij@w3.org>) id 1MiCNf-0007SJ-Cx; Mon, 31 Aug 2009 15:17:31 -0400
Message-Id: <AA0F215A-0229-469A-A888-8FFC64D7B1B2@w3.org>
From: Ian Jacobs <ij@w3.org>
To: public-new-work@w3.org
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Aug 2009 14:17:31 -0500
X-Mailer: Apple Mail (2.936)
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599
X-W3C-Scan-Sig: bart.w3.org 1MiCNf-0008LR-LX f45f4175f07eac69ce811caee98e2732
X-Original-To: public-new-work@w3.org
Archived-At: <http://www.w3.org/mid/AA0F215A-0229-469A-A888-8FFC64D7B1B2@w3.org>
Resent-From: public-new-work@w3.org
X-Mailing-List: <public-new-work@w3.org> archive/latest/49
X-Loop: public-new-work@w3.org
Resent-Sender: public-new-work-request@w3.org
Precedence: list
Resent-Message-Id: <E1MiCNo-0006Ed-Sm@frink.w3.org>
Resent-Date: Mon, 31 Aug 2009 19:17:40 +0000
X-Mailman-Approved-At: Tue, 01 Sep 2009 08:04:06 -0700
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
X-Scanned-By: MIMEDefang 2.42
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id n81F6M6M003079
X-BeenThere: secdir@mit.edu
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Wed, 02 Sep 2009 02:22:45 -0700
Subject: [secdir] [New-work] Subject: Proposed W3C Charter: eGovernment	Interest	Group (until 2009-09-28)
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 15:10:18 -0000

Hello,

Today W3C Advisory Committee Representatives received a Proposal to  =

revise the eGovernment Activity [0] (see the W3C Process Document  =

description of Activity Proposals [1]). This proposal includes a draft  =

charter for the eGovernment Interest Group:
   http://www.w3.org/2009/06/eGov/ig-charter

As part of ensuring that the community is aware of proposed work at  =

W3C, this draft charter is public during the Advisory Committee review  =

period.

W3C invites public comments through 2009-09-28 on the proposed  =

charter. Please send comments to public-new-work@w3.org, which has a  =

public archive:
   http://lists.w3.org/Archives/Public/public-new-work/

Other than comments sent in formal responses by W3C Advisory Committee  =

Representatives, W3C cannot guarantee a response to comments. If you  =

work for a W3C Member [2], please coordinate your comments with your  =

Advisory Committee Representative. For example, you may wish to make  =

public comments via this list and have your Advisory Committee  =

Representative refer to it from his or her formal review comments.

If you should have any questions or need further information, please
contact Jos=E9 M. Alonso, eGovernment Lead <josema@w3.org>.

Thank you,

Ian Jacobs, Head of W3C Communications

[0] http://www.w3.org/2007/eGov/
[1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation
[2] http://www.w3.org/Consortium/Member/List
--
Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447


_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir

From slblake@petri-meat.com  Tue Sep  1 18:43:47 2009
Return-Path: <slblake@petri-meat.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DAFE28C402; Tue,  1 Sep 2009 18:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.473
X-Spam-Level: 
X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=0.826,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz3MYBWNtdJ6; Tue,  1 Sep 2009 18:43:46 -0700 (PDT)
Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 573623A6DD0; Tue,  1 Sep 2009 18:43:46 -0700 (PDT)
Received: from cpe-071-065-228-209.nc.res.rr.com ([71.65.228.209]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from <slblake@petri-meat.com>) id 1MiesU-0004jU-6t; Tue, 01 Sep 2009 21:43:14 -0400
From: Steven Blake <slblake@petri-meat.com>
To: Magnus =?ISO-8859-1?Q?Nystr=F6m?= <magnusn@gmail.com>
In-Reply-To: <2f57b9e60909011645w3d23f4d9m23bdbc278d84efd0@mail.gmail.com>
References: <2f57b9e60909011645w3d23f4d9m23bdbc278d84efd0@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 01 Sep 2009 21:43:19 -0400
Message-Id: <1251855799.12516.11.camel@tachyon>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) 
Content-Transfer-Encoding: quoted-printable
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - elom.tchmachines.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - petri-meat.com
X-Mailman-Approved-At: Wed, 02 Sep 2009 02:22:45 -0700
Cc: toby.moncaster@bt.com, secdir@ietf.org, bob.briscoe@bt.com, sob@harvard.edu, menth@informatik.uni-wuerzburg.de, iesg@ietf.org
Subject: Re: [secdir] Review of draft-ietf-pcn-baseline-encoding-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2009 01:43:47 -0000

Magnus,

Thanks for taking the time to review this document.


On Tue, 2009-09-01 at 16:45 -0700, Magnus Nystr=C3=B6m wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>=20
> Overview:
>=20
> Loosely, this document describes a way of pre-congestion notification
> marking of packets that builds on the Explicit Congestion Notification
> (RFC 3168). The marking is only carrying meaning within a given PCN
> domain.
>=20
> Comments:
>=20
> With the caveat of not being an expert in the field this draft is
> about, I find the document relatively straightforward to understand
> and the Security Considerations section reasonably complete (although
> it perhaps would have been useful to describe what problems that
> possibly could occur should a party inject PCN-marked packets inside a
> network?).
>=20
> Editorial:
>=20
> Maybe useful to add a brief early section providing definitions of
> abbreviations?
>=20
> -- Magnus


Regards,

// Steve


From toby.moncaster@bt.com  Wed Sep  2 02:19:27 2009
Return-Path: <toby.moncaster@bt.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40153A6817; Wed,  2 Sep 2009 02:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Level: 
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-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 OZWgArb+-XsK; Wed,  2 Sep 2009 02:19:26 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id E33AE3A67F2; Wed,  2 Sep 2009 02:19:25 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 2 Sep 2009 10:18:12 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 2 Sep 2009 10:18:06 +0100
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC70CDCF280@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <1251855799.12516.11.camel@tachyon>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Review of draft-ietf-pcn-baseline-encoding-05
Thread-Index: AcorbsSAtSNNTUgqT9mBqK+tAyyKWAAPh+Ow
References: <2f57b9e60909011645w3d23f4d9m23bdbc278d84efd0@mail.gmail.com> <1251855799.12516.11.camel@tachyon>
From: <toby.moncaster@bt.com>
To: <slblake@petri-meat.com>, <magnusn@gmail.com>
X-OriginalArrivalTime: 02 Sep 2009 09:18:12.0474 (UTC) FILETIME=[4B8435A0:01CA2BAE]
X-Mailman-Approved-At: Wed, 02 Sep 2009 02:22:45 -0700
Cc: secdir@ietf.org, philip.eardley@bt.com, bob.briscoe@bt.com, sob@harvard.edu, menth@informatik.uni-wuerzburg.de, iesg@ietf.org
Subject: Re: [secdir] Review of draft-ietf-pcn-baseline-encoding-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2009 09:19:27 -0000

SGkgTWFnbnVzLA0KDQoNCkFzIFN0ZXZlIHNhaWQsIHRoYW5rcyBmb3IgcmV2aWV3aW5nIHRoZSBk
b2N1bWVudC4gV2UgZGlkIGNvbnNpZGVyIGhhdmluZyBhIGxpc3Qgb2YgYWJicmV2aWF0aW9ucyBh
dCB0aGUgc3RhcnQgKGFuZCBzdGlsbCBkbyBnaXZlIHRoZSBrZXkgZGVmaW5pdGlvbnMgYW5kIHRo
ZWlyIGFiYnJldmlhdGlvbnMpLiBJIHdvdWxkIGJlIGhhcHB5IHRvIGFkZCBhIHNlcGFyYXRlIGxp
c3Qgb2YgYWJicmV2aWF0aW9ucyBpZiBpdCB3YXMgZmVsdCB0aGlzIHdvdWxkIGFkZCBjbGFyaXR5
IHRvIHRoZSBkb2N1bWVudC4NCg0KQXMgdG8gaW5qZWN0aW5nIFBDTi1tYXJrZWQgd2l0aGluIHRo
ZSBuZXR3b3JrOiBQQ04gaXMgdmVyeSBjbGVhcmx5IGRlZmluZWQgYXMgd29ya2luZyBpbiBhIHRy
dXN0ZWQgZW52aXJvbm1lbnQgd2hlcmUgYWxsIG5vZGVzIGFyZSBleHBlY3RlZCB0byB3b3JrIHRv
Z2V0aGVyLiBTbyB0aGUgb25seSB3YXlzIHRoYXQgUENOLW1hcmtlZCBwYWNrZXRzIG1pZ2h0IGVu
dGVyIHRoZSBQQ04tZG9tYWluIG1pc3Rha2VubHkgYXJlIA0KDQoxKSBJZiB0aGVyZSBpcyBhIG1p
c2NvbmZpZ3VyZWQgb3Igb3RoZXJ3aXNlICJicm9rZW4iIG5vZGUgaW4gdGhlIFBDTi1kb21haW4u
IEl0IHdhcyBmZWx0IHRoYXQgdGhpcyBpcyB2ZXJ5IGZpcm1seSBhbiBpbXBsZW1lbnRhdGlvbiBh
bmQgb3BlcmF0b3IgbWFuYWdlbWVudCBpc3N1ZSBhbmQgdGh1cyBiZXlvbmQgdGhlIHNjb3BlIG9m
IHRoaXMgZG9jdW1lbnQuDQoNCjIpIElmIGEgUENOLWJvdW5kYXJ5IG5vZGUgd2FzIG1pc2NvbmZp
Z3VyZWQgYW5kIG1pc3Rha2VubHkgYWxsb3dlZCBpbiBhIFBDTi1tYXJrZWQgcGFja2V0IG9yIG1p
c3Rha2VubHkgc2V0IHRoZSBtYXJrIGl0c2VsZi4gVGhpcyBhZ2FpbiB3YXMgZmVsdCB0byBiZSBh
IG1hdHRlciBmb3IgdGhlIGltcGxlbWVudGVycyBhbmQgb3BlcmF0b3JzIG9mIHRoZSBQQ04tZG9t
YWluLg0KDQpIYXZpbmcgc2FpZCB0aGF0IEkgd291bGQgYmUgaGFwcHkgdG8gYWRkIGEgY291cGxl
IG9mIHNlbnRlbmNlIHN1Y2ggYXMgdGhlIGZvbGxvd2luZzoNCg0KIkFsdGhvdWdoIHNwdXJpb3Vz
IFBDTi1tYXJrcyBjYW4gb25seSBlbnRlciB0aGUgZG9tYWluIGFzIGEgcmVzdWx0IG9mIG1pc2Nv
bmZpZ3VyYXRpb24sIG9wZXJhdG9ycyBtaWdodCB3aXNoIHRvIGJlIGF3YXJlIG9mIHRoZSBwb3Rl
bnRpYWwgaW1wYWN0IG9mIHRoZXNlIG1hcmtzLiBUaGUgcHJlY2lzZSBpbXBhY3Qgd2lsbCBkZXBl
bmQgb24gd2hpY2ggb2YgdGhlIHZhcmlvdXMgcHJvcG9zZWQgZWRnZSBiZWhhdmlvdXIgc2NoZW1l
cyBpcyB1c2VkLCBidXQgaW4gZ2VuZXJhbCBzdWNoIHNwdXJpb3VzIG1hcmtzIHdpbGwgbGVhZCB0
byBlaXRoZXIgYWRtaXR0aW5nIGZld2VyIGZsb3dzIGludG8gdGhlIGRvbWFpbiBvciBwb3NzaWJs
eSB0ZXJtaW5hdGluZyB0b28gbWFueSBmbG93cy4gSW4gZWl0aGVyIGNhc2UgZ29vZCBtYW5hZ2Vt
ZW50IHNob3VsZCBiZSBhYmxlIHRvIHF1aWNrbHkgc3BvdCB0aGF0IHRoZXJlIGlzIGEgcHJvYmxl
bSBzaW5jZSB0aGUgdXRpbGlzYXRpb24gb2YgdGhlIGxpbmtzIGluIHRoZSBkb21haW4gd2lsbCBx
dWlja2x5IGRyb3Agb2ZmLiINCg0KVG9ieQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+IEZyb206IFN0ZXZlbiBCbGFrZSBbbWFpbHRvOnNsYmxha2VAcGV0cmktbWVhdC5jb21dDQo+
IFNlbnQ6IDAyIFNlcHRlbWJlciAyMDA5IDAyOjQzDQo+IFRvOiBNYWdudXMgTnlzdHLDtm0NCj4g
Q2M6IGllc2dAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZzsgTW9uY2FzdGVyLFQsVG9ieSxERVIz
IFI7DQo+IEJyaXNjb2UsUkosQm9iLERFUjMgUjsgbWVudGhAaW5mb3JtYXRpay51bmktd3Vlcnpi
dXJnLmRlOw0KPiBzb2JAaGFydmFyZC5lZHUNCj4gU3ViamVjdDogUmU6IFJldmlldyBvZiBkcmFm
dC1pZXRmLXBjbi1iYXNlbGluZS1lbmNvZGluZy0wNQ0KPiANCj4gTWFnbnVzLA0KPiANCj4gVGhh
bmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3IHRoaXMgZG9jdW1lbnQuDQo+IA0KPiAN
Cj4gT24gVHVlLCAyMDA5LTA5LTAxIGF0IDE2OjQ1IC0wNzAwLCBNYWdudXMgTnlzdHLDtm0gd3Jv
dGU6DQo+IA0KPiA+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhl
IHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCj4gPiBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxs
IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCj4gPiBJRVNHLiAgVGhlc2Ug
Y29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQo+
ID4gc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFp
cnMgc2hvdWxkIHRyZWF0DQo+ID4gdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBs
YXN0IGNhbGwgY29tbWVudHMuDQo+ID4NCj4gPiBPdmVydmlldzoNCj4gPg0KPiA+IExvb3NlbHks
IHRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgd2F5IG9mIHByZS1jb25nZXN0aW9uIG5vdGlmaWNh
dGlvbg0KPiA+IG1hcmtpbmcgb2YgcGFja2V0cyB0aGF0IGJ1aWxkcyBvbiB0aGUgRXhwbGljaXQg
Q29uZ2VzdGlvbg0KPiBOb3RpZmljYXRpb24NCj4gPiAoUkZDIDMxNjgpLiBUaGUgbWFya2luZyBp
cyBvbmx5IGNhcnJ5aW5nIG1lYW5pbmcgd2l0aGluIGEgZ2l2ZW4gUENODQo+ID4gZG9tYWluLg0K
PiA+DQo+ID4gQ29tbWVudHM6DQo+ID4NCj4gPiBXaXRoIHRoZSBjYXZlYXQgb2Ygbm90IGJlaW5n
IGFuIGV4cGVydCBpbiB0aGUgZmllbGQgdGhpcyBkcmFmdCBpcw0KPiA+IGFib3V0LCBJIGZpbmQg
dGhlIGRvY3VtZW50IHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3YXJkIHRvIHVuZGVyc3RhbmQNCj4g
PiBhbmQgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gcmVhc29uYWJseSBjb21w
bGV0ZSAoYWx0aG91Z2gNCj4gPiBpdCBwZXJoYXBzIHdvdWxkIGhhdmUgYmVlbiB1c2VmdWwgdG8g
ZGVzY3JpYmUgd2hhdCBwcm9ibGVtcyB0aGF0DQo+ID4gcG9zc2libHkgY291bGQgb2NjdXIgc2hv
dWxkIGEgcGFydHkgaW5qZWN0IFBDTi1tYXJrZWQgcGFja2V0cyBpbnNpZGUNCj4gYQ0KPiA+IG5l
dHdvcms/KS4NCj4gPg0KPiA+IEVkaXRvcmlhbDoNCj4gPg0KPiA+IE1heWJlIHVzZWZ1bCB0byBh
ZGQgYSBicmllZiBlYXJseSBzZWN0aW9uIHByb3ZpZGluZyBkZWZpbml0aW9ucyBvZg0KPiA+IGFi
YnJldmlhdGlvbnM/DQo+ID4NCj4gPiAtLSBNYWdudXMNCj4gDQo+IA0KPiBSZWdhcmRzLA0KPiAN
Cj4gLy8gU3RldmUNCg0K

From Pasi.Eronen@nokia.com  Wed Sep  2 03:49:49 2009
Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9BC3A69B5 for <secdir@core3.amsl.com>; Wed,  2 Sep 2009 03:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.342
X-Spam-Level: 
X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNt9N1tIxfeg for <secdir@core3.amsl.com>; Wed,  2 Sep 2009 03:49:48 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8E96A3A69A1 for <secdir@ietf.org>; Wed,  2 Sep 2009 03:49:48 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n82Amjsm026194 for <secdir@ietf.org>; Wed, 2 Sep 2009 13:48:47 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 2 Sep 2009 13:48:49 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 2 Sep 2009 13:48:48 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 2 Sep 2009 12:48:45 +0200
From: <Pasi.Eronen@nokia.com>
To: <secdir@ietf.org>
Date: Wed, 2 Sep 2009 12:48:44 +0200
Thread-Topic: Re: Nomcom 2009-2010: Call for Nominations
Thread-Index: AcoruvEu9HJSlkM6TSCan/f73p2K6Q==
Message-ID: <808FD6E27AD4884E94820BC333B2DB773C0160B753@NOK-EUMSG-01.mgdnok.nokia.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Sep 2009 10:48:48.0988 (UTC) FILETIME=[F3EE69C0:01CA2BBA]
Subject: Re: [secdir] Nomcom 2009-2010: Call for Nominations
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2009 10:49:49 -0000

My current term as Security Area Director ends in March, and several
folks asked me in Stockholm whether I intend to run for a second term.

Back in Stockholm, I answered that this depends, among other things,
on what I can arrange with my employer. Those discussions have now
concluded, and I will not be running for a second term.

Best regards,
Pasi

From RMarshall@telecomsys.com  Wed Sep  2 14:03:14 2009
Return-Path: <RMarshall@telecomsys.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D891D28C234; Wed,  2 Sep 2009 14:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Level: 
X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, MANGLED_LOAN=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZY9cyxEdZSu; Wed,  2 Sep 2009 14:03:13 -0700 (PDT)
Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id BEC9728C1EE; Wed,  2 Sep 2009 14:03:12 -0700 (PDT)
Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by  sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP  id <T90875c4da80a200c4916d0@sea-mimesweep-1.telecomsys.com>; Wed, 2  Sep 2009 13:31:03 -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
Date: Wed, 2 Sep 2009 13:30:43 -0700
Message-ID: <8C837214C95C864C9F34F3635C2A65750E311223@SEA-EXCHVS-2.telecomsys.com>
In-Reply-To: <200906090451.n594pGcD012946@localhost.localdomain>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Review of draft-ietf-geopriv-lbyr-requirements-07
Thread-Index: AcnovhlxmLq7CazJTqGcNIVi5D6NQhCdYgcg
References: <200906090451.n594pGcD012946@localhost.localdomain>
From: "Roger Marshall" <RMarshall@telecomsys.com>
To: "Hilarie Orman" <ho@alum.mit.edu>, <secdir@ietf.org>
X-Mailman-Approved-At: Wed, 02 Sep 2009 22:54:29 -0700
Cc: fluffy@cisco.com, acooper@cdt.org, iesg@ietf.org, Lisa.Dusseault@messagingarchitects.com
Subject: Re: [secdir] Review of draft-ietf-geopriv-lbyr-requirements-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2009 21:03:14 -0000

Hilarie:

Thank you for your comments.  I apologize for the long delay in getting
these processed.

Please see my responses to your comments, inline.

-roger marshall.=20

> -----Original Message-----
> From: Hilarie Orman [mailto:ho@alum.mit.edu]=20
> Sent: Monday, June 08, 2009 9:51 PM
> To: secdir@ietf.org
> Cc: iesg@ietf.org; Roger Marshall; rbarnes@bbn.com;=20
> acooper@cdt.org; fluffy@cisco.com;=20
> Lisa.Dusseault@messagingarchitects.com
> Subject: Review of draft-ietf-geopriv-lbyr-requirements-07
>=20
> Requirements for a Location-by-Reference Mechanism
> draft-ietf-geopriv-lbyr-requirements-07
>=20
> Do not be alarmed.  I have reviewed this document as part of=20
> the security directorate's ongoing effort to review all IETF=20
> documents being processed by the IESG.  These comments were=20
> written primarily for the benefit of the security area=20
> directors.  Document editors and WG chairs should treat these=20
> comments just like any other last call comments.
>=20
> The draft is about the requirements for using an indirect=20
> reference ("location by reference") for geolocation=20
> information.  The geolocation protocol can return a URI for=20
> retrieving the information that would be conveyed if=20
> "location by value" were used.  Much of the document is about=20
> ensuring privacy of location information.
>=20
> ---
>=20
> In section 2, terminology, "Location-by-Value (LbyV): Using=20
> location information in the form of a location object (LO),=20
> such as a PIDF-LO."
>=20
> This is copied from RFC3693, but it is my understanding that=20
> PIDF-LO is an absolute requirement for geopriv-lbyr, so a=20
> note to that effect would be helpful here.

[RM- it is true that requirement D3 (restated below) states the required
form that gets dereferenced, but the reference you cite above has to do
with the term "LbyV", defined more-or-less in RFC 4119, and provided
here for background in contrast to LbyR.  Therefore, I'm not sure that
it should be more closely tied to "LbyR". =20

"D3.  Dereferenced Location Form:  The value returned by the
      dereference protocol MUST contain a well-formed PIDF-LO document."

The requirement(s) that LbyV MUST be in PIDF-LO form, however it is
implied or stated elsewhere.  As a way forward, I'm hoping that changing
the following to remove the "such as...", making the RFC 3693 "LO"
reference a more explicit "PIDF-LO", and contrasting LbyV with LbyR,
will be sufficient.

Change from (Cf):
   Location-by-Value (LbyV):  Using location information in the form of
      a location object (LO), such as a PIDF-LO.
Change to (Ct):
   Location-by-Value (LbyV):  Using location information directly within
signaling, in the form of
      a location object (PIDF-LO), an alternative approach to using
LbyR.
/]

>=20
> ---
>=20
> The document would be improved by consistently using the term "target"
> for the thing to be located, instead of the occasional "user"=20
> or "device".  If it is important to distinguish them, one=20
> could say "target's user", for example.

[RM- agree with your comment.  Changed throughout, as noted below:

Introduction -
Cf:
such as whether a Target is mobile=20
and whether a mobile device needs to be located=20
Ct:
such as whether a Target is mobile=20
and whether this mobile target needs to be located=20


After Figure 1 -
Cf:
1. The Target (a Device)
Ct:
1. The Target (an end device)


Under "Location URI Authorization", under scenario 4.,
Cf:
the location URI is confidential=20
information shared between the LIS/LS, the Device=20
Ct:
the location URI is confidential=20
information shared between the LIS/LS, the Target


"Location URI Authorization"
Cf:
Construction of a location URI in such a=20
way as to not reveal any domain, user, or device specific information
Ct:
Construction of a location URI in such a=20
way as to not reveal any domain, user, or target specific information


"Requirements for a Location Configuration Protocol"
Cf:
C5. User Identity Protection:  The location URI MUST NOT=20
contain information that identifies the user or target (e.g., device).
Examples=20
include phone extensions, badge numbers, first or last names.
Ct:
C5. Target Identity Protection:  The location URI MUST NOT=20
contain information that identifies the target (e.g., domain, user,
device). Examples=20
include phone extensions, badge numbers, first or last names.


"Location URI Authorization", changing title from "user" to "Target",
Cf:
2. No user specific information: By default, a location URI=20
MUST NOT reveal any information about the Target other than location=20
information.  This is true for the URI itself, (or in the document
acquired by=20
dereferencing), unless policy explicitly permits otherwise.
Ct:
2. No Target specific information: By default, a location URI=20
MUST NOT reveal any information about the Target, (e.g., domain, user,
or device), other than location=20
information.  This is true for the URI itself, (or in the document
acquired by=20
dereferencing), unless policy explicitly permits otherwise.


"Location URI Construction"
Cf:
Construction of a location URI in such a=20
way as to not reveal any domain, user, or target specific information
Ct:
Construction of a location URI in such a=20
way as to not reveal any target specific information, (e.g., domain,
user, or device),

/]

>=20
> ---
>=20
> "Section 4, High Level Requirements, item C8, Location URI=20
> Not guessable."
>=20
>   This is a required default behavior.  I'm not sure why the=20
> URI shouldn't be guessable, given that the PIDF-LO=20
> information can be protected through mime security.  A=20
> clarifying statement should be added.

[RM - Though the wg agrees that there is no security-thru-obscurity, the

wg felt strongly that a certain level of blurring of the location URI=20
would be a generally good practice for systems to employ.  I've added=20
one example to the Motivation statement, in hopes that this does a=20
little better job in explaining and justifying this kind of default=20
requirement.

"C8. Location URI Not guessable:",
Cf:
Motivation: Location URIs should be constructed in such a way that an=20
adversary cannot guess them and dereference them without having ever=20
obtained them from the Target.
Ct:
Motivation: Location URIs should be constructed in such a way that an=20
adversary cannot guess them and dereference them without having ever=20
obtained them from the Target.  An example location URI presented as=20
"john.doe@domain.com", might make it possible for someone to also=20
easily guess the URI relating the location of a "jane.doe@domain.com".

/]

>=20
> ---
>=20
> "C6. Reuse indicator:  There SHOULD be a way to allow a client to
>     control whether a location URI can be resolved once only, or
>     multiple times."
>=20
> What is the point of one-time use?  Why not just send the=20
> information directly, instead of a URI?  One could overload=20
> the URI format and encode the encrypted location info in the=20
> URI itself.
>=20
> Is the "client" the target?


[RM - This is a good catch.  Yes, I believe it should say "Target",
since=20
This is a "C", or Configuration protocol requirement.  See the proposed
change, below:

Cf:
C6. Reuse indicator: There SHOULD be a way to allow a=20
client to control whether a location URI can be resolved once only, or
multiple=20
times.

Motivation:  The client requesting a location URI may request a location
URI=20
which has a 'one-time-use' only characteristic, as opposed to a location
URI=20
having multiple reuse capability.

Ct:
C6. Reuse indicator: There SHOULD be a way to allow a=20
TARGET to control whether a location URI can be resolved once only, or
multiple=20
times.

Motivation:  The Target requesting a location URI may request a location
URI=20
which has a 'one-time-use' only characteristic, as opposed to a location
URI=20
having multiple reuse capability.


Note: This also leads to other uses of client for Target within the
Location=20
Configuration context.  In light of the below proposed changes, the
document=20
only retains the use of "client" in reference to the Location
Dereference Protocol.

Cf:
Location Configuration Protocol: A protocol which=20
is used by a client to acquire either location or a location URI from a
location=20
configuration server, based on information unique to the client.
Ct:
Location Configuration Protocol: A protocol which=20
is used by a Target to acquire either location or a location URI from a
location=20
configuration server, based on information unique to the Target.

Cf:
C3. Location URI cancellation: The location configuration=20
protocol MUST support the ability to request a cancellation of a
specific=20
location URI.

Motivation: If the client determines that in its best interest to
destroy the=20
ability for a location URI to effectively be used to dereference a
location, then=20
there should be a way to nullify the location URI.

Ct:
C3. Location URI cancellation: The location configuration=20
protocol MUST support the ability to request a cancellation of a
specific=20
location URI.

Motivation: If the Target determines that in its best interest to
destroy the=20
ability for a location URI to effectively be used to dereference a
location, then=20
there should be a way to nullify the location URI.

/]

>=20
> Must the server return an error if a one-time URI is reused? =20
> Or can it return the old information?

[RM - My take is that the server has implementation choice as to what
can be returned:

i. an error with old location
ii. an error with no location
iii. no error msg., only the old location

This allowance, (admittedly short of defining any new requirements in
this document),=20
is adequately reflected in the following amended motivation sentence:

Cf:
C6. Reuse indicator: There SHOULD be a way to allow a=20
client to control whether a location URI can be resolved once only, or
multiple=20
times.

Motivation:  The client requesting a location URI may request a location
URI=20
which has a 'one-time-use' only characteristic, as opposed to a location
URI=20
having multiple reuse capability.

Ct:
C6. Reuse indicator: There SHOULD be a way to allow a=20
Target to control whether a location URI can be resolved once only, or
multiple=20
times.

Motivation:  The Target requesting a location URI may request a location
URI=20
which has a 'one-time-use' only characteristic, as opposed to a location
URI=20
having multiple reuse capability.  This would allow the server to return
an=20
error with or without location during the subsequent dereference
operation.

/]

>=20
> ---
>=20
> The covert channel of the protocol messages is not mentioned,=20
> but should be.  If user A subscribes to location information=20
> for user B, then every time A gets a location update an=20
> observer may know that B has moved.  There are mitigations,=20
> such as sending the information at regular time intervals,=20
> even if the target is stationary.

[RM - I can see your point, and so have added some text, not as a
requirement, but to the=20
Security section for reader consideration.  See the following:

A covert channel for protocol message exchange is an important=20
consideration, given an example scenario where user A subscribes to
location=20
information for user B, then every time A gets a location update an=20
(external) observer of the subscription notification may know that B has
moved. =20
One mitigation to this is to have periodic notification, so that user B
may appear=20
to have moved, even when static.

/]

>=20
> Hilarie
>=20
>=20

CONFIDENTIALITY NOTICE: The information contained in this message may be pr=
ivileged and/or confidential. If you are not the intended recipient, or res=
ponsible for delivering this message to the intended recipient, any review,=
 forwarding, dissemination, distribution or copying of this communication o=
r any attachment(s) is strictly prohibited. If you have received this messa=
ge in error, please notify the sender immediately, and delete it and all at=
tachments from your computer and network.

From philip.eardley@bt.com  Wed Sep  2 17:38:35 2009
Return-Path: <philip.eardley@bt.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A613A697E; Wed,  2 Sep 2009 17:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.131,  BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-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 38dLMoCHxaTC; Wed,  2 Sep 2009 17:38:34 -0700 (PDT)
Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 880443A68CC; Wed,  2 Sep 2009 17:38:34 -0700 (PDT)
Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 2 Sep 2009 11:02:21 +0100
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
Date: Wed, 2 Sep 2009 11:01:34 +0100
Message-ID: <4A916DBC72536E419A0BD955EDECEDEC063637A5@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70CDCF280@E03MVZ1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Review of draft-ietf-pcn-baseline-encoding-05
Thread-Index: AcorbsSAtSNNTUgqT9mBqK+tAyyKWAAPh+OwAAGi8ZA=
From: <philip.eardley@bt.com>
To: <toby.moncaster@bt.com>, <slblake@petri-meat.com>, <magnusn@gmail.com>
X-OriginalArrivalTime: 02 Sep 2009 10:02:21.0763 (UTC) FILETIME=[769DA130:01CA2BB4]
X-Mailman-Approved-At: Wed, 02 Sep 2009 22:54:29 -0700
Cc: bob.briscoe@bt.com, menth@informatik.uni-wuerzburg.de, iesg@ietf.org, sob@harvard.edu, secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-pcn-baseline-encoding-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2009 00:38:35 -0000

Toby
Your suggestion is fine with me. I'd keep the note about this =
misconfiguration scenario short - if things are misconfigured, then they =
can be misconfigured in all sorts of ways and different things can go =
wrong.=20

-----Original Message-----
From: Moncaster,T,Toby,DER3 R=20
Sent: 02 September 2009 10:18
To: Steven Blake; Magnus Nystr=F6m
Cc: iesg@ietf.org; secdir@ietf.org; Briscoe,RJ,Bob,DER3 R; =
menth@informatik.uni-wuerzburg.de; sob@harvard.edu; =
Eardley,PL,Philip,DER3 R
Subject: RE: Review of draft-ietf-pcn-baseline-encoding-05

Hi Magnus,


As Steve said, thanks for reviewing the document. We did consider having =
a list of abbreviations at the start (and still do give the key =
definitions and their abbreviations). I would be happy to add a separate =
list of abbreviations if it was felt this would add clarity to the =
document.

As to injecting PCN-marked within the network: PCN is very clearly =
defined as working in a trusted environment where all nodes are expected =
to work together. So the only ways that PCN-marked packets might enter =
the PCN-domain mistakenly are=20

1) If there is a misconfigured or otherwise "broken" node in the =
PCN-domain. It was felt that this is very firmly an implementation and =
operator management issue and thus beyond the scope of this document.

2) If a PCN-boundary node was misconfigured and mistakenly allowed in a =
PCN-marked packet or mistakenly set the mark itself. This again was felt =
to be a matter for the implementers and operators of the PCN-domain.

Having said that I would be happy to add a couple of sentence such as =
the following:

"Although spurious PCN-marks can only enter the domain as a result of =
misconfiguration, operators might wish to be aware of the potential =
impact of these marks. The precise impact will depend on which of the =
various proposed edge behaviour schemes is used, but in general such =
spurious marks will lead to either admitting fewer flows into the domain =
or possibly terminating too many flows. In either case good management =
should be able to quickly spot that there is a problem since the =
utilisation of the links in the domain will quickly drop off."

Toby

> -----Original Message-----
> From: Steven Blake [mailto:slblake@petri-meat.com]
> Sent: 02 September 2009 02:43
> To: Magnus Nystr=F6m
> Cc: iesg@ietf.org; secdir@ietf.org; Moncaster,T,Toby,DER3 R;
> Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de;
> sob@harvard.edu
> Subject: Re: Review of draft-ietf-pcn-baseline-encoding-05
>=20
> Magnus,
>=20
> Thanks for taking the time to review this document.
>=20
>=20
> On Tue, 2009-09-01 at 16:45 -0700, Magnus Nystr=F6m wrote:
>=20
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should =
treat
> > these comments just like any other last call comments.
> >
> > Overview:
> >
> > Loosely, this document describes a way of pre-congestion =
notification
> > marking of packets that builds on the Explicit Congestion
> Notification
> > (RFC 3168). The marking is only carrying meaning within a given PCN
> > domain.
> >
> > Comments:
> >
> > With the caveat of not being an expert in the field this draft is
> > about, I find the document relatively straightforward to understand
> > and the Security Considerations section reasonably complete =
(although
> > it perhaps would have been useful to describe what problems that
> > possibly could occur should a party inject PCN-marked packets inside
> a
> > network?).
> >
> > Editorial:
> >
> > Maybe useful to add a brief early section providing definitions of
> > abbreviations?
> >
> > -- Magnus
>=20
>=20
> Regards,
>=20
> // Steve


From gnakibly@yahoo.com  Thu Sep  3 08:07:16 2009
Return-Path: <gnakibly@yahoo.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9EEC3A6D89 for <secdir@core3.amsl.com>; Thu,  3 Sep 2009 08:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.151
X-Spam-Level: 
X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=0.848,  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 3ibuuDY5VVTF for <secdir@core3.amsl.com>; Thu,  3 Sep 2009 08:07:16 -0700 (PDT)
Received: from web45502.mail.sp1.yahoo.com (web45502.mail.sp1.yahoo.com [68.180.197.62]) by core3.amsl.com (Postfix) with SMTP id 8FF343A6D9E for <secdir@ietf.org>; Thu,  3 Sep 2009 08:07:16 -0700 (PDT)
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 <gnakibly@yahoo.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, v6ops <v6ops@ops.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
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2009 15:07:16 -0000

Hi Fred,=0Asee inline.=0A=0AGabi=0A=0A----- Original Message ----=0A> From:=
 "Templin, Fred L" <Fred.L.Templin@boeing.com>=0A> To: Gabi Nakibly <gnakib=
ly@yahoo.com>; v6ops <v6ops@ops.ietf.org>=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 "<foreign prefix>::0200:5efe:<my IP addr=
ess>")=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 magnus.westerlund@ericsson.com  Thu Sep  3 10:48:45 2009
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEEAD3A6778; Thu,  3 Sep 2009 10:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.766
X-Spam-Level: 
X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=0.483,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaov2D-6n7vy; Thu,  3 Sep 2009 10:48:44 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0633D3A6767; Thu,  3 Sep 2009 10:48:40 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b6eae000001984-0f-4a9f929d286f
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7F.1D.06532.D929F9A4; Thu,  3 Sep 2009 11:55:41 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 3 Sep 2009 11:55:40 +0200
Received: from [147.214.183.250] ([147.214.183.250]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 3 Sep 2009 11:55:40 +0200
Message-ID: <4A9F929C.9030309@ericsson.com>
Date: Thu, 03 Sep 2009 11:55:40 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Francois Le Faucheur IMAP <flefauch@cisco.com>
References: <C666D4B1.2C65%stefan@aaa-sec.com> <A70CE797-56BE-41E2-A618-22A99646681B@cisco.com>
In-Reply-To: <A70CE797-56BE-41E2-A618-22A99646681B@cisco.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 03 Sep 2009 09:55:40.0540 (UTC) FILETIME=[B1E19BC0:01CA2C7C]
X-Brightmail-Tracker: AAAAAA==
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Bruce Davie <bsd@cisco.com>, secdir@ietf.org, iesg@ietf.org, Ashok Narayanan <ashokn@cisco.com>, James Polk <jmpolk@cisco.com>
Subject: Re: [secdir] SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2009 17:48:45 -0000

Hi,

I haven't seen any follow up on this discussion. Can Stefan and Francois
please come to conlusion on what to do?

Cheers

Magnus

Francois Le Faucheur IMAP skrev:
> Hello Stefan,
> 
> Thanks for your review. Please find a response to your question embedded
> below:
> 
> On 23 Jun 2009, at 18:51, Stefan Santesson wrote:
> 
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>>
>> This specification define a set of procedures to overcome challenges
>> with deployment of Resource Reservation Protocols over BGP/MPLS VPNs.
>>
>> The BGP/MPLS VPN (RFC 4364) is a VPN technique that doesn't rely
>> encryption to ensure secrecy or message integrity. The security
>> properties are instead dependent on the security of the network
>> infrastructure.
>>
>> It appears that this draft makes a serious effort to describe and
>> analyze relevant security considerations. With my limited expertise in
>> this particular area I can't find any thing that is obviously missing.
>>
>> However, one question that comes to my mind, which might be worth
>> looking at from a security perspective, is whether the procedures
>> introduced by this document requires the communication to be
>> unencrypted and if so, whether deployment of this protocol blocks or
>> prevents legitimate use of e.g. IPsec based VPN as discussed in RFC
>> 4364 and RFC 4023. If this is the case, should it be discussed in the
>> security considerations section?
> 
> The short answer is that this document does not require that
> communication be un-encrypted.
> 
> The longer answer would be:
> 
> RFC4364 mentions use of IPsec both CE-CE and PE-PE:
> Specifically, I noticed: "Cryptographic privacy is not provided by this
> architecture, nor by Frame Relay or ATM VPNs. These architectures are
> all compatible with the use of cryptography on a CE-CE basis, if that is
> desired. The use of cryptography on a PE-PE basis is for further study."
> 
> Regarding PE-PE IPsec:
> * RSVP over VPN would work just fine (as currently specified) for PE-CE
> links
> * RSVP over VPN would not allow CAC over MPLS Core as we need TE tunnels
> to do that which I believe could not be used with MPLS over IP/IPsec in
> the core.
> 
> Regarding CE-CE IPsec (or if IPsec starts deeper inside the VPN site):
> RFC 4923 "Quality of Service (QoS) Signaling in a Nested Virtual Private
> Network" describes a model for RSVP operation through IPsec Gateways (in
> a nutshell, the idea is that there is effectively a form of hierarchical
> RSVP where an RSVP reservation is made for the IPsec tunnel and then
> individual RSVP reservations are admitted/aggregated over the tunnel
> reservation). This would apply in case to the case of CE-CE IPsec (or if
> IPsec starts deeper inside the VPN site) and the procedures defined in
> the document would simply apply "as is" to the reservation for the
> tunnel(s) (and not to the individual end to end RSVP reservation).
> 
> If this answers your question appropriately, we could add text capturing
> this in the Security Considerations (whenever we issue the next rev).
> Please let us if this works for you.
> 
> Thanks
> 
> Francois
> 
>>
>>
>> *Stefan Santesson
>> *AAA-sec.com
>>
>>
>>
>>
>>
> 


-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

From weiler+secdir@watson.org  Thu Sep  3 12:35:59 2009
Return-Path: <weiler+secdir@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA2C3A6882 for <secdir@core3.amsl.com>; Thu,  3 Sep 2009 12:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.36
X-Spam-Level: 
X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX-tVdBaa6+J for <secdir@core3.amsl.com>; Thu,  3 Sep 2009 12:35:58 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id CEF203A683D for <secdir@ietf.org>; Thu,  3 Sep 2009 12:35:57 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n83JYoaR064424 for <secdir@ietf.org>; Thu, 3 Sep 2009 15:34:50 -0400 (EDT) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n83JYosT064421 for <secdir@ietf.org>; Thu, 3 Sep 2009 15:34:50 -0400 (EDT) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 3 Sep 2009 15:34:50 -0400 (EDT)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.0909031527540.46609@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Thu, 03 Sep 2009 15:34:50 -0400 (EDT)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2009 19:35:59 -0000

Sean Turner is next in the rotation.

Please try to complete last call reviews by the end of the last call. 
For documents on telechat, note that the deadline field shown below 
reflects the telechat date, even though last call likely expires (or 
expired) before then.

Review instructions and related resources are at:
       http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam

For telechat 2009-09-10

Reviewer                 Deadline   Draft
Charlie Kaufman        T 2009-09-08 draft-ietf-mpls-3209-patherr-05
Barry Leiba            TR2009-09-08 draft-drage-sipping-service-identification-03
Russ Mundy             T 2009-09-08 draft-ietf-hip-nat-traversal-08
Hilarie Orman          T 2009-09-08 draft-ietf-pwe3-segmented-pw-13
Joe Salowey            T 2009-09-08 draft-ietf-mip4-generic-notification-message-09
Nico Williams          T 2009-09-08 draft-ietf-dime-nai-routing-03
Tom Yu                 TR2009-09-08 draft-ietf-dime-pmip6-03


For telechat 2009-09-24

Reviewer                 Deadline   Draft
Derek Atkins           TR2009-09-22 draft-ietf-roll-building-routing-reqs-06
Tero Kivinen           TR2009-09-22 draft-ietf-sipcore-presence-scaling-requirements-02

Last calls and special requests:

Reviewer                 Deadline   Draft
Alan DeKok               2009-08-17 draft-turner-deviceowner-attribute-01
Shawn Emery              2009-08-04 draft-ietf-alto-problem-statement-02
Phillip Hallam-Baker     2009-08-18 draft-ietf-pmol-sip-perf-metrics-03
Steve Hanna              2009-08-14 draft-ietf-krb-wg-cross-problem-statement-04
Love Hornquist-Astrand   2009-03-31 draft-ietf-ipfix-mib-07
Love Hornquist-Astrand   2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05
Charlie Kaufman          2009-06-29 draft-ietf-ipsecme-ikev2-redirect-13
Julien Laganier          2009-01-22 draft-ietf-sip-certs-08
Julien Laganier          2009-06-09 draft-ietf-enum-3761bis-04
Barry Leiba              2009-09-17 draft-iana-ipv4-examples-01
Chris Lonvick            2009-09-17 draft-daboo-srv-email-02
Catherine Meadows        2008-01-17 draft-ietf-speechsc-mrcpv2-20
Sandy Murphy             2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-14
Sandy Murphy             2009-09-04 draft-ietf-rtgwg-ipfrr-framework-11
Vidya Narayanan          2008-11-21 draft-ietf-sip-saml-06
Chris Newman             2009-09-04 draft-ietf-mboned-lightweight-igmpv3-mldv2-05
Eric Rescorla            2009-09-07 draft-ietf-tls-rfc4366-bis-05
Joe Salowey              2009-02-08 draft-ietf-geopriv-lis-discovery-11
Stefan Santesson         2009-09-08 draft-ietf-l3vpn-2547bis-mcast-bgp-07
Juergen Schoenwaelder    2009-09-08 draft-ietf-l3vpn-2547bis-mcast-08
Yaron Sheffer            2009-09-14 draft-ietf-calsify-2446bis-09
Hannes Tschofenig        2009-04-23 draft-ietf-pce-monitoring-05
Hannes Tschofenig        2009-07-25 draft-ietf-pkix-ta-format-03
Hannes Tschofenig        2009-09-14 draft-ietf-ipsecme-ikev2-resumption-07
Tina TSOU                2009-09-15 draft-ietf-syslog-sign-27
Sam Weiler               2008-08-13 draft-chown-v6ops-rogue-ra-03
Nico Williams            2008-08-13 draft-ietf-v6ops-ra-guard-03
Larry Zhu                2008-08-13 draft-thaler-v6ops-teredo-extensions-03
Larry Zhu                2009-05-09 draft-ietf-ecrit-location-hiding-req-02


From Fred.L.Templin@boeing.com  Thu Sep  3 14:35:14 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A143A6977; Thu,  3 Sep 2009 14:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.641
X-Spam-Level: 
X-Spam-Status: No, score=-5.641 tagged_above=-999 required=5 tests=[AWL=0.358,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh-dixD-7T68; Thu,  3 Sep 2009 14:35:10 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id C85353A6856; Thu,  3 Sep 2009 14:35:10 -0700 (PDT)
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 n83Fxcjr008828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 08:59:39 -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 n83FxcPk000296; Thu, 3 Sep 2009 08:59:38 -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 n83FxW4F000040; Thu, 3 Sep 2009 08:59:38 -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);  Thu, 3 Sep 2009 08:59:37 -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
Date: Thu, 3 Sep 2009 08:59:36 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1065D7539@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <342868.34354.qm@web45502.mail.sp1.yahoo.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Routing loop attacks using IPv6 tunnels
Thread-Index: AcospzSFve6xEKuBQDuxy4Yg4J/hIQABJYgw
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>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Gabi Nakibly" <gnakibly@yahoo.com>, "v6ops" <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 03 Sep 2009 15:59:37.0688 (UTC) FILETIME=[89D5F580:01CA2CAF]
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2009 21:35:14 -0000

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
>=20
> Hi Fred,
> see inline.
>=20
> Gabi
>=20
> ----- Original Message ----
> > From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> > To: Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>
> > Cc: ipv6@ietf.org; secdir@ietf.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=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.
> > >
> > > isatap_xmt() {
> > > =A0=A0=A0=A0 ...
> > > =A0=A0=A0=A0 if (src =3D=3D "<foreign prefix>::0200:5efe:<my IP =
address>")
> > > =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.
>=20
> Why do you think so?

I think so, because ISATAP routers are strongly advised not
to operate outside of an ip-proto-41 and ingress filtering
site in the first place. Those that do are already operating
at-risk, and the best we can do is tell them what they
SHOULD/MAY do to avoid problems.=20

> As=A0I see it, the two checks mitigate two different attacks.=A0The =
destination
> address check=A0defends the ISATAP router=A0against attacks=A0of type =
3 in which it acts as
> the=A0decapsulator of the attack packet.

Right.

> While, the=A0source address check=A0defends the ISATAP
> router=A0against attacks=A0of type 3 in which it acts as =
the=A0ecapsulator of the attack packet.

Right.

> Either of
> these checks are redundant if the other one is employed by the =
opposite router of the attack.

Right.

> So I do not see why one of them is a SHOULD and the other is a MAY.

In my view, the decapsulator is the true victim because
it is the one that receives the tunneled packet. It has
placed itself in a position to be attacked by operating
outside of a filtering site in the first place, so it
really SHOULD do something to protect itself.

The encapsulator on the other hand is neither the attacker
nor the victim, but rather is an unwitting conduit for the
attacker. So, it may want to do something extra on behalf
of decapsulators that don't observe the SHOULD but it (like
the decapsulator) is already operating at-risk outside of
a filtering site anyway. =20
 =20
> > 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
> >
>=20
> 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.=A0Since=A0no one can =
be absolutely sure that the
> destination address check shall always be implemented correctly at all =
other routers then=A0it may seem
> prudent to also employ the source check as a second layer of defense.

If the decapsulator is already required to implement the check,
then IMHO any checks at the encapsulator would at most be a
weak MAY. These checks are not cheap, and IMHO you would find
encapsulator implementations that do not honor them regardless
of the strength of the normative language.

Fred
fred.l.templin@boeing.com =20

> > 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=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 kivinen@iki.fi  Fri Sep  4 03:36:38 2009
Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AE63A6A03; Fri,  4 Sep 2009 03:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTLM-zbDNfAq; Fri,  4 Sep 2009 03:36:38 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 925A73A6A01; Fri,  4 Sep 2009 03:36:35 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n849Lfen013882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Sep 2009 12:21:41 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n849LfKN013510; Fri, 4 Sep 2009 12:21:41 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19104.56357.76790.194214@fireball.kivinen.iki.fi>
Date: Fri, 4 Sep 2009 12:21:41 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 2 min
X-Total-Time: 2 min
Cc: draft-ietf-sipcore-presence-scaling-requirements@tools.ietf.org, sipcore-chairs@tools.ietf.org
Subject: [secdir] Review of draft-ietf-sipcore-presence-scaling-requirements-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 10:36:38 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This is second review of this document, and my previous complains
(http://www.ietf.org/mail-archive/web/secdir/current/msg00948.html)
have been addressed. I do not have any further comments to this
document.
-- 
kivinen@iki.fi

From Adrian.Farrel@huawei.com  Fri Sep  4 04:06:12 2009
Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A943A67EE for <secdir@core3.amsl.com>; Fri,  4 Sep 2009 04:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.559
X-Spam-Level: 
X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_05=-1.11, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK9gICM0WPs5 for <secdir@core3.amsl.com>; Fri,  4 Sep 2009 04:06:11 -0700 (PDT)
Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id C8DD83A67E2 for <secdir@ietf.org>; Fri,  4 Sep 2009 04:06:11 -0700 (PDT)
Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPG009IU1F70Z@lhrga01-in.huawei.com> for secdir@ietf.org; Fri, 04 Sep 2009 12:04:19 +0100 (BST)
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0KPG001701EWQ3@lhrga01-in.huawei.com> for secdir@ietf.org; Fri, 04 Sep 2009 12:04:13 +0100 (BST)
Date: Fri, 04 Sep 2009 12:04:00 +0100
From: Adrian Farrel <Adrian.Farrel@huawei.com>
To: Stephen Kent <kent@bbn.com>
Message-id: <FED2184CF597405083AE68F9F2DFCE19@your029b8cecfe>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <200909040212.n842CS3M028820@harbor.orleans.occnc.com>
Cc: mpls-chairs@tools.ietf.org, secdir <secdir@ietf.org>, draft-ietf-mpls-soft-preemption@tools.ietf.org
Subject: [secdir] Security review: draft-ietf-mpls-soft-preemption-18.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <Adrian.Farrel@huawei.com>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 11:06:12 -0000

Hi Stephen,

Thanks for your review. After discussion with the authors, I have added an 
RFC Editor note as follows.

Thanks,
Adrian

Section 10
OLD
   This document does not introduce new security issues.  The security
   considerations pertaining to the original RSVP protocol [RFC3209]
   remain relevant.
NEW
   This document does not introduce new security issues.  The security
   considerations pertaining to the original RSVP protocol [RFC3209]
   remain relevant. Further details about MPLS security considerations
   can be found in [I-D.ietf-mpls-mpls-and-gmpls-security].

   As noted in Section 6.1, soft preemption may result in temporary link
   under provisioning condition while the soft preempted TE LSPs are
   rerouted by their respective head-end LSRs. Although this is a less
   serious condition than false hard preemption, and despite the
   mitigation procedures described in Section 6.1, network operators
   should be aware of the risk to their network should the soft
   preemption processes be subverted, and should apply the relevant MPLS
   control plane security techniques to protect against attacks.
---
Section 13.2
ADD
   [I-D.ietf-mpls-mpls-and-gmpls-security] Fang, L. Ed., "Security
              Framework for MPLS and GMPLS Networks", draft-ietf-mpls-
              mpls-and-gmpls-security-framework-06.txt, work in
              progress.



From remi.despres@free.fr  Fri Sep  4 10:05:48 2009
Return-Path: <remi.despres@free.fr>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC4B3A682E; Fri,  4 Sep 2009 10:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.532
X-Spam-Level: 
X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfbkAS7F67Zq; Fri,  4 Sep 2009 10:05:47 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id DE0543A67EF; Fri,  4 Sep 2009 10:05:45 -0700 (PDT)
Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id DB1C1E0808D; Fri,  4 Sep 2009 19:05:24 +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 87F19E080E5; Fri,  4 Sep 2009 19:05:20 +0200 (CEST)
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065D7539@XCH-NW-7V2.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> <39C363776A4E8C4A94691D2BD9D1C9A1065D7539@XCH-NW-7V2.nw.nos.boeing.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <021A8F28-173E-471C-98E6-1E9A313E9715@free.fr>
Content-Transfer-Encoding: quoted-printable
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
Date: Fri, 4 Sep 2009 19:05:19 +0200
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.753.1)
Cc: Gabi Nakibly <gnakibly@yahoo.com>, v6ops <v6ops@ops.ietf.org>, 6man 6man <ipv6@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 17:05:48 -0000

Comment below

Le 3 sept. 09 =E0 17:59, Templin, Fred L a =E9crit :

> 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" <Fred.L.Templin@boeing.com>
>>> To: Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>
>>> 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 =20
>>>> made. I would
>>> also add a forth
>>>> check to mitigate attack #3 as a second layer of defense in case =20=

>>>> the opposite
>>> ISATAP router does not
>>>> make the proper check on the destination address.
>>>>
>>>> isatap_xmt() {
>>>>      ...
>>>>      if (src =3D=3D "<foreign prefix>::0200:5efe:<my IP address>")
>>>>        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.


The two following scenarios show in my understanding that ISATAP =20
routers SHOULD check Source addresses of packets they receive in IPv6:

SCENARIO 1: between two ISATAP routers A and B

   ISATAP router A receives in IPv6:
   Dst6 =3D </96 prefix of ISATAP router A> . <IPv4 address of ISATAP =20=

router B>
   Src6 =3D </96 prefix of ISATAP router B> . <IPv4 address of ISATAP =20=

router A>

   If ISATAP router A doesn't discard the packet because of its =20
source address, it will encapsulate it with:
   Dst4 =3D <IPv4 address of ISATAP router B>
   Src4 =3D <IPv4 address of ISATAP router A>

   Then, ISATAP router B finds that Src6 and Src4 are consistent, and =20=

forwards the IPv6 packet to ISATAP router A.
   The routing loop is in place.

SCENARIO 2: between an ISATAP router and a 6to4 relay router

   The ISATAP router receives in IPv6:

   Dst6 =3D </96 prefix of the ISATAP router> . <IPv4 address of the =20
6to4 relay>
   Src6 =3D 2002::/16 . <IPv4 address of the ISATAP router>

   If it doesn't discard the packet because of its source address, it =20=

will encapsulate it with:
   Dst4 =3D <IPv4 address of the 6to4 relay>
   Src4 =3D <IPv4 address of the ISATAP router>

   Then, the 6to4 relay finds that Src6 and Src4 are consistent, and =20
forwards the IPv6 packet to the ISATAP router.
   The routing loop is in place.

Anything missing?

Regards,
RD



From Fred.L.Templin@boeing.com  Fri Sep  4 11:56:04 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E9B3A6926; Fri,  4 Sep 2009 11:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.515
X-Spam-Level: 
X-Spam-Status: No, score=-5.515 tagged_above=-999 required=5 tests=[AWL=0.184,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6yowFGhWYxl; Fri,  4 Sep 2009 11:56:03 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id D3B8B3A6403; Fri,  4 Sep 2009 11:56:03 -0700 (PDT)
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
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" <Fred.L.Templin@boeing.com>
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
X-OriginalArrivalTime: 04 Sep 2009 18:54:40.0674 (UTC) FILETIME=[28843020:01CA2D91]
Cc: Gabi Nakibly <gnakibly@yahoo.com>, v6ops <v6ops@ops.ietf.org>, 6man 6man <ipv6@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 18:56:04 -0000

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" <Fred.L.Templin@boeing.com>
> >>> To: Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>
> >>> 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 "<foreign prefix>::0200:5efe:<my IP =
address>")
> >>>>        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 </96 prefix of ISATAP router A> . <IPv4 address of ISATAP
> router B>
>    Src6 =3D </96 prefix of ISATAP router B> . <IPv4 address of ISATAP
> router A>
>=20
>    If ISATAP router A doesn't discard the packet because of its
> source address, it will encapsulate it with:
>    Dst4 =3D <IPv4 address of ISATAP router B>
>    Src4 =3D <IPv4 address of ISATAP router A>
>=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 </96 prefix of the ISATAP router> . <IPv4 address of the
> 6to4 relay>
>    Src6 =3D 2002::/16 . <IPv4 address of the ISATAP router>
>=20
>    If it doesn't discard the packet because of its source address, it
> will encapsulate it with:
>    Dst4 =3D <IPv4 address of the 6to4 relay>
>    Src4 =3D <IPv4 address of the ISATAP router>
>=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 Fred.L.Templin@boeing.com  Fri Sep  4 13:01:08 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251F53A68A4; Fri,  4 Sep 2009 13:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.669
X-Spam-Level: 
X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.330,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFLdTvLhhgOL; Fri,  4 Sep 2009 13:01:05 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 1195F3A68DB; Fri,  4 Sep 2009 13:01:04 -0700 (PDT)
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 n84K0tjS003813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Sep 2009 13:00:55 -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 n84K0tYM013327; Fri, 4 Sep 2009 13:00:55 -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 n84K0rrQ013172; Fri, 4 Sep 2009 13:00: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);  Fri, 4 Sep 2009 13:00: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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 4 Sep 2009 13:00:53 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <342868.34354.qm@web45502.mail.sp1.yahoo.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Routing loop attacks using IPv6 tunnels
Thread-Index: AcospzSFve6xEKuBQDuxy4Yg4J/hIQA8ZcTg
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>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Gabi Nakibly" <gnakibly@yahoo.com>, "v6ops" <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Sep 2009 20:00:54.0969 (UTC) FILETIME=[69617A90:01CA2D9A]
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 20:01:08 -0000

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
>=20
> Hi Fred,
> see inline.
>=20
> Gabi
>=20
> ----- Original Message ----
> > From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> > To: Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>
> > Cc: ipv6@ietf.org; secdir@ietf.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=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.
> > >
> > > isatap_xmt() {
> > > =A0=A0=A0=A0 ...
> > > =A0=A0=A0=A0 if (src =3D=3D "<foreign prefix>::0200:5efe:<my IP =
address>")
> > > =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.
>=20
> Why do you think so? As=A0I see it, the two checks mitigate two =
different attacks.=A0The destination
> address check=A0defends the ISATAP router=A0against attacks=A0of type =
3 in which it acts as
> the=A0decapsulator of the attack packet.=A0=A0While, the=A0source =
address check=A0defends the ISATAP
> router=A0against attacks=A0of type 3 in which it acts as =
the=A0ecapsulator of the attack packet.=A0=A0Either 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.
>=20
> >
> > 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
> >
>=20
> 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.=A0Since=A0no one can =
be absolutely sure that the
> destination address check shall always be implemented correctly at all =
other routers then=A0it may seem
> prudent to also employ the source check as a second layer of defense.
>=20
> > 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=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 charliek@microsoft.com  Fri Sep  4 13:51:09 2009
Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FFC53A68D0; Fri,  4 Sep 2009 13:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRvGFyRUexPv; Fri,  4 Sep 2009 13:51:05 -0700 (PDT)
Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id BFF0A3A69BF; Fri,  4 Sep 2009 13:51:05 -0700 (PDT)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Sep 2009 13:51:19 -0700
Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([169.254.10.174]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Fri, 4 Sep 2009 13:51:19 -0700
From: Charlie Kaufman <charliek@microsoft.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "jpv@cisco.com" <jpv@cisco.com>, "swallow@cisco.com" <swallow@cisco.com>, "ina@juniper.net" <ina@juniper.net>, "loa@pi.nu" <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Secdir review of draft-ietf-mpls-3209-patherr-05.txt
Thread-Index: AcotoXN3v+1I0FP3SHuZTBolqUexgA==
Date: Fri, 4 Sep 2009 20:51:18 +0000
Message-ID: <D80EDFF2AD83E648BD1164257B9B09121C413C@TK5EX14MBXC119.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B09121C413CTK5EX14MBXC119red_"
MIME-Version: 1.0
Subject: [secdir] Secdir review of draft-ietf-mpls-3209-patherr-05.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 20:51:09 -0000

--_000_D80EDFF2AD83E648BD1164257B9B09121C413CTK5EX14MBXC119red_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am reviewing this document as part of the security directorate's ongoing =
effort to review all IETF documents being processed by the IESG.  These com=
ments were written primarily for the benefit of the security area directors=
.  Document editors and WG chairs should treat these comments just like any=
 other last call comments. Feel free to forward to any appropriate forum.

This document specifies a relatively minor clarification to RFC 3209, and a=
s far as I can tell that clarification has no security consequences (unless=
 you call non-interoperability because of different interpretations of the =
spec a security issue).

Typos (maybe):

In sections 2.1 and 2.1, I found 2 "must"s, 2 "must not"s, 2 "should"s, and=
 one "may" that I believe should have been all caps per RFC 2119. I've neve=
r been very good at that distinction, however, so the authors MIGHT have it=
 right ;-)



--_000_D80EDFF2AD83E648BD1164257B9B09121C413CTK5EX14MBXC119red_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DSection1><p class=3DMsoPlainText><span style=3D'fo=
nt-family:"Calibri","sans-serif"'>I am reviewing this document as part of t=
he security directorate's ongoing effort to review all IETF documents being=
 processed by the IESG.&nbsp; These comments were written primarily for the=
 benefit of the security area directors.&nbsp; Document editors and WG chai=
rs should treat these comments just like any other last call comments. Feel=
 free to forward to any appropriate forum.<o:p></o:p></span></p><p class=3D=
MsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>This document specifies=
 a relatively minor clarification to RFC 3209, and as far as I can tell tha=
t clarification has no security consequences (unless you call non-interoper=
ability because of different interpretations of the spec a security issue).=
<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNorm=
al>Typos (maybe):<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><=
p class=3DMsoNormal>In sections 2.1 and 2.1, I found 2 &#8220;must&#8221;s,=
 2 &#8220;must not&#8221;s, 2 &#8220;should&#8221;s, and one &#8220;may&#82=
21; that I believe should have been all caps per RFC 2119. I&#8217;ve never=
 been very good at that distinction, however, so the authors MIGHT have it =
right ;-)<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=
=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>=

--_000_D80EDFF2AD83E648BD1164257B9B09121C413CTK5EX14MBXC119red_--

From clonvick@cisco.com  Fri Sep  4 14:33:32 2009
Return-Path: <clonvick@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32EF3A6821; Fri,  4 Sep 2009 14:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK8+0Q2knhef; Fri,  4 Sep 2009 14:33:31 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BD4B33A6873; Fri,  4 Sep 2009 14:33:31 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAOMkoUqrR7PD/2dsb2JhbADBSYhBAZA8BYI4gWOBXQ
X-IronPort-AV: E=Sophos;i="4.44,334,1249257600"; d="scan'208";a="202077007"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 04 Sep 2009 21:33:39 +0000
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n84LXdpO008071;  Fri, 4 Sep 2009 14:33:39 -0700
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n84LXcbF016914; Fri, 4 Sep 2009 21:33:38 GMT
Date: Fri, 4 Sep 2009 14:33:38 -0700 (PDT)
From: Chris Lonvick <clonvick@cisco.com>
To: iesg@ietf.org, secdir@ietf.org, cyrus@daboo.name
Message-ID: <Pine.GSO.4.63.0909041326580.18544@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3571; t=1252100019; x=1252964019; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20<clonvick@cisco.com> |Subject:=20SECDIR=20review=20of=20draft-daboo-srv-email-02 |Sender:=20; bh=tO9QjXf9/0CHKwMkWa41qNHtlvdum4n4vxuT7sid+LU=; b=JW5h6EBYepcqqau4vXJXeiqtcquqBcrCtjrdhsDLZYofCo3P0j1lYybMD3 XRsV6w0bzMDik/4S73l0ftfeVDdMRHPGFJHEPYsskC5MdZd/Y5frKIVSCp7i dDXBkdrtGf;
Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Cc: secdir-secretary@mit.edu
Subject: [secdir] SECDIR review of draft-daboo-srv-email-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 21:33:32 -0000

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security area 
directors.  Document editors and WG chairs should treat these comments 
just like any other last call comments.

Overall, this looks like a good document and I don't have any concerns 
with it.


I do have a few nits that you may want to look at.

In the Introduction, s/miniml/minimal/

I think that you're missing a comma in the last paragraph:  Perhaps it 
should be (with second comma added):
    This specification defines new SRV service types for the message
    submission, IMAP and POP3 services, to enable simple auto
    configuration of email clients.


Also, the Introduction does not seem to flow very well.  If I may suggest 
the following, which is just a rearrangement of the content:
SUGGESTED:
---
    Internet Email protocols include SMTP [RFC5321], IMAP [RFC3501] and
    POP3 [RFC1939].  Both IMAP and POP3 are mail access protocols used by
    email clients to manipulate email messages after delivery.

    [RFC2782] defines a DNS-based service discovery protocol that has
    been widely adopted as a means of locating particular services within
    a local area network and beyond, using SRV RR records.

    [RFC5321] defines the MX RR record type to locate SMTP services for a
    domain.  However, [RFC4409] defines a "profile" of the SMTP service
    that is specifically used for message submission - which is of direct
    relevance to email clients which typically don't use MX records.

    Typically email clients have required users to enter host name and
    port information for the services they need.  This is not ideal as
    the way in which server information is specified can differ from
    client to client, and can be confusing to users, leading to errors
    when inputting the details.  A better approach would be to require
    minimal information to be entered by a user which would result in
    automatic configuration of appropriate services for that user.  The
    minimal information entered would be the user's email address.

    This specification defines new SRV service types for the message
    submission, IMAP and POP3 services, to enable simple auto
    configuration of email clients.
---

The last sentence in the 4th paragraph of Section 4 is:
    When using transport layer
    security in this way, clients SHOULD use the TLS Server Name
    Indication [RFC4366] and include the service domain name used in the
    SRV record lookup as the name.
Perhaps to fully qualify this, it should be:
    When using transport layer
    security in this way, clients SHOULD use the TLS Server Name
    Indication [RFC4366] and include the service domain name used in the
    SRV record lookup as the name of the server it is contacting.

In most cases the term "server" references the email server, in much the 
same way that "client" refers to the email client.  However, there are 
some cases of "TLS Server" and "DNS Server".  It might be good to qualify 
that.  Perhaps a statement in Section 2 to say, "If not otherwise 
qualified, the term server refers to hosts offering the POP3 or IMAP 
service."

I'm curious as to why you're not asking for an IANA registry be created 
for this.  A quick search shows that there is for IM SRV labels.
   http://www.iana.org/assignments/im-srv-labels

Regards,
Chris

From charliek@microsoft.com  Fri Sep  4 18:13:06 2009
Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2D13A6803; Fri,  4 Sep 2009 18:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN1k7gqlUqzF; Fri,  4 Sep 2009 18:12:56 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A4F383A67BE; Fri,  4 Sep 2009 18:12:56 -0700 (PDT)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Sep 2009 18:13:18 -0700
Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([169.254.10.174]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Fri, 4 Sep 2009 18:13:17 -0700
From: Charlie Kaufman <charliek@microsoft.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "vijay@wichorus.com" <vijay@wichorus.com>, "kilian.weniger@googlemail.com" <kilian.weniger@googlemail.com>, "paul.hoffman@vpnc.org" <paul.hoffman@vpnc.org>, "yaronf@checkpoint.com" <yaronf@checkpoint.com>
Thread-Topic: Secdir review of draft-ietf-ipsecme-ikev2-redirect-13.txt
Thread-Index: AcotxgwTdsxHGi2mR0iwfcuQom5JTg==
Date: Sat, 5 Sep 2009 01:13:16 +0000
Message-ID: <D80EDFF2AD83E648BD1164257B9B09121C4201@TK5EX14MBXC119.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B09121C4201TK5EX14MBXC119red_"
MIME-Version: 1.0
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: [secdir] Secdir review of draft-ietf-ipsecme-ikev2-redirect-13.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Sep 2009 01:13:06 -0000

--_000_D80EDFF2AD83E648BD1164257B9B09121C4201TK5EX14MBXC119red_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am reviewing this document as part of the security directorate's ongoing =
effort to review all IETF documents being processed by the IESG.  These com=
ments were written primarily for the benefit of the security area directors=
.  Document editors and WG chairs should treat these comments just like any=
 other last call comments. Feel free to forward to any appropriate forum.

This document specifies an extension to IKEv2 supporting the case where the=
 accepting end of an IPsec Security Association wants to redirect the initi=
ating end to connect to a different address than the one it tried first. Us=
es include connections to a server or gateway that wants to balance the loa=
d among several equivalent instances, finding the closest instance with Any=
cast addresses and then redirecting the a fixed address, dealing with the o=
rderly shutdown of a replicated service or gateway, and supporting IPv6 mob=
ility. The document specifies how to do the redirection at three different =
protocol stages: during connection establishment before the client authenti=
cates to the server, during connection establishment after authentication b=
ut before an ESP or AH security association is established, or after protec=
ted traffic has already started flowing.

I found no security problems with the protocol.

There does appear to be one critical missing piece of functionality, howeve=
r. I would expect that any protocol that has clients connecting to gateways=
 should work through NATs. The protocol specified in this document does not=
 say how to do that, though the changes would be fairly simple and (I would=
 think) non-controversial. It's possible that they are considered "obvious"=
 and that this protocol is intended to be used with NATs, but I doubt it. T=
here may have been some previous discussion of this on the IPsec list that =
I missed.

Had I been involved with the design, there are some other suggestions I wou=
ld have made. It's late in the process now, so feel free to rule them out o=
f order for lateness, but I can't resist stating them:


1)      If the initiator of the connection requests and obtains an "inner" =
IP address from the gateway, then in order to switch to a different gateway=
 without tearing down existing TCP connections it would need to get that sa=
me IP address assigned by the new gateway. For a graceful transition from o=
ld to new, the initiator would want to make the new IKE connection before b=
reaking the old one. But the new gateway cannot safely allocate the same IP=
 address while the old connection is still open unless it somehow knows tha=
t it is talking to the same client and that a transition is in progress. It=
 would seem desirable to put some indicator in the protocol to signal that =
case. Otherwise, IPv6 mobility and any other gateway move is going to be ve=
ry disruptive for clients.

2)      To deal with gateways that are behind NATs, it would seem helpful f=
or redirection to be able to specify not just the new IP address but also t=
he new port. If the port were other than 500, the initiator should assume i=
t should use the UDP encapsulation protocol rather than ESP or AH directly.

3)      The cookie and alternate Diffie-Hellman group negotiations are desi=
gned to take place in parallel to avoid extra round trips. It might be desi=
rable to integrate IP redirection into the same exchange for the same reaso=
n. That way the initial message pair could do any subset of the three funct=
ions.

4)      This document creates a new IANA registry for "GW Ident Type" (gate=
way identifier type) with three values: IPv4 address, IPv6 address, and DNS=
 name. I would have instead reused the existing registry "ID type" and rest=
rict the value to one of those three values in this context. I also would h=
ave had a two byte length for the gateway identifier. There may already be =
some architectural limit of 255 octets for a DNS name, but what with intern=
ationalization and other such things, I wouldn't wire it into a new protoco=
l.

5)      The spec seems a little squishy on the question of whether redirect=
ion only changes the address at which to find the gateway or whether it als=
o affects the authenticated name (in other words, whether a redirection fro=
m gateway1.example.com to gateway27.example.com means that the client shoul=
d now accept a certificate containing the name gateway27.example.com. It is=
 pretty clear that in the first (unauthenticated) redirection type, accepti=
ng a new name would clearly be unacceptable because it would trivially allo=
w gateway spoofing. But when it occurs after the first gateway has authenti=
cated, the appropriate policy is less clear. I couldn't figure out whether =
it was disallowed in all cases or not.

Some more minor issues:


1)      First line of abstract: "IKEv2 is a protocol for setting..." -> "IK=
Ev2 is a protocol that can be used for setting..."

2)      Last two lines of page 2: "The gateway MUST keep track of those cli=
ents that indicated support..."  This statement is only true for gateways t=
hat themselves support redirection. If they don't, they can ignore such ind=
icators.

3)      Middle of page 6: "one of the VPN gateway." -> "one of the VPN gate=
ways."

4)      Section 7 (Handling Redirect Loops): This section mandates a defaul=
t maximum number of redirects and a default time limit over which that defa=
ult applies. The IKEv2 spec goes out of its way to never specify such count=
s and timeouts, because the appropriate values are scenario dependent and t=
he protocol is designed so that the values never affect interoperability. I=
n this case, the values chosen still do not affect interoperability. I woul=
d recommend that the spec recommend these values rather than mandate them a=
s defaults.

5)      This document defines some new IANA code points but calls for other=
s to be assigned by IANA. Unless there is some convention to the contrary o=
r other good reason, I'd propose values for all of the code points rather t=
han expecting the RFC editor to do it as the document is made into an RFC. =
This makes life simpler for the RFC editor and makes it possible to impleme=
nt prototypes before the spec is advanced.

6)      Middle of page 5: "cannot also" -> "also cannot"

7)      Last sentence of section 11: "and should be done" -> "and redirecti=
on should be done"

--_000_D80EDFF2AD83E648BD1164257B9B09121C4201TK5EX14MBXC119red_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
/* List Definitions */
@list l0
	{mso-list-id:1259021229;
	mso-list-type:hybrid;
	mso-list-template-ids:1009803396 67698705 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l1
	{mso-list-id:1380938103;
	mso-list-type:hybrid;
	mso-list-template-ids:513818392 67698705 67698713 67698715 67698703 676987=
13 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l1:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l1:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DSection1><p class=3DMsoPlainText><span style=3D'fo=
nt-family:"Calibri","sans-serif"'>I am reviewing this document as part of t=
he security directorate's ongoing effort to review all IETF documents being=
 processed by the IESG.&nbsp; These comments were written primarily for the=
 benefit of the security area directors.&nbsp; Document editors and WG chai=
rs should treat these comments just like any other last call comments. Feel=
 free to forward to any appropriate forum.<o:p></o:p></span></p><p class=3D=
MsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>This document specifies=
 an extension to IKEv2 supporting the case where the accepting end of an IP=
sec Security Association wants to redirect the initiating end to connect to=
 a different address than the one it tried first. Uses include connections =
to a server or gateway that wants to balance the load among several equival=
ent instances, finding the closest instance with Anycast addresses and then=
 redirecting the a fixed address, dealing with the orderly shutdown of a re=
plicated service or gateway, and supporting IPv6 mobility. The document spe=
cifies how to do the redirection at three different protocol stages: during=
 connection establishment before the client authenticates to the server, du=
ring connection establishment after authentication but before an ESP or AH =
security association is established, or after protected traffic has already=
 started flowing.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><=
p class=3DMsoNormal>I found no security problems with the protocol.<o:p></o=
:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>There=
 does appear to be one critical missing piece of functionality, however. I =
would expect that any protocol that has clients connecting to gateways shou=
ld work through NATs. The protocol specified in this document does not say =
how to do that, though the changes would be fairly simple and (I would thin=
k) non-controversial. It&#8217;s possible that they are considered &#8220;o=
bvious&#8221; and that this protocol is intended to be used with NATs, but =
I doubt it. There may have been some previous discussion of this on the IPs=
ec list that I missed.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p>=
</p><p class=3DMsoNormal>Had I been involved with the design, there are som=
e other suggestions I would have made. It&#8217;s late in the process now, =
so feel free to rule them out of order for lateness, but I can&#8217;t resi=
st stating them:<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p=
 class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lf=
o1'><![if !supportLists]><span style=3D'mso-list:Ignore'>1)<span style=3D'f=
ont:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><=
![endif]>If the initiator of the connection requests and obtains an &#8220;=
inner&#8221; IP address from the gateway, then in order to switch to a diff=
erent gateway without tearing down existing TCP connections it would need t=
o get that same IP address assigned by the new gateway. For a graceful tran=
sition from old to new, the initiator would want to make the new IKE connec=
tion before breaking the old one. But the new gateway cannot safely allocat=
e the same IP address while the old connection is still open unless it some=
how knows that it is talking to the same client and that a transition is in=
 progress. It would seem desirable to put some indicator in the protocol to=
 signal that case. Otherwise, IPv6 mobility and any other gateway move is g=
oing to be very disruptive for clients.<o:p></o:p></p><p class=3DMsoListPar=
agraph style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportL=
ists]><span style=3D'mso-list:Ignore'>2)<span style=3D'font:7.0pt "Times Ne=
w Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>To deal wi=
th gateways that are behind NATs, it would seem helpful for redirection to =
be able to specify not just the new IP address but also the new port. If th=
e port were other than 500, the initiator should assume it should use the U=
DP encapsulation protocol rather than ESP or AH directly.<o:p></o:p></p><p =
class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lfo=
1'><![if !supportLists]><span style=3D'mso-list:Ignore'>3)<span style=3D'fo=
nt:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><!=
[endif]>The cookie and alternate Diffie-Hellman group negotiations are desi=
gned to take place in parallel to avoid extra round trips. It might be desi=
rable to integrate IP redirection into the same exchange for the same reaso=
n. That way the initial message pair could do any subset of the three funct=
ions.<o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25in=
;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Igno=
re'>4)<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; </span></span><![endif]>This document creates a new IANA registry fo=
r &#8220;GW Ident Type&#8221; (gateway identifier type) with three values: =
IPv4 address, IPv6 address, and DNS name. I would have instead reused the e=
xisting registry &#8220;ID type&#8221; and restrict the value to one of tho=
se three values in this context. I also would have had a two byte length fo=
r the gateway identifier. There may already be some architectural limit of =
255 octets for a DNS name, but what with internationalization and other suc=
h things, I wouldn&#8217;t wire it into a new protocol.<o:p></o:p></p><p cl=
ass=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'=
><![if !supportLists]><span style=3D'mso-list:Ignore'>5)<span style=3D'font=
:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![e=
ndif]>The spec seems a little squishy on the question of whether redirectio=
n only changes the address at which to find the gateway or whether it also =
affects the authenticated name (in other words, whether a redirection from =
gateway1.example.com to gateway27.example.com means that the client should =
now accept a certificate containing the name gateway27.example.com. It is p=
retty clear that in the first (unauthenticated) redirection type, accepting=
 a new name would clearly be unacceptable because it would trivially allow =
gateway spoofing. But when it occurs after the first gateway has authentica=
ted, the appropriate policy is less clear. I couldn&#8217;t figure out whet=
her it was disallowed in all cases or not.<o:p></o:p></p><p class=3DMsoNorm=
al><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Some more minor issues:<o:p></=
o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoListParagra=
ph style=3D'text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists=
]><span style=3D'mso-list:Ignore'>1)<span style=3D'font:7.0pt "Times New Ro=
man"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>First line of =
abstract: &#8220;IKEv2 is a protocol for setting&#8230;&#8221; -&gt; &#8220=
;IKEv2 is a protocol that can be used for setting&#8230;&#8221;<o:p></o:p><=
/p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 leve=
l1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>2)<span style=
=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></s=
pan><![endif]>Last two lines of page 2: &#8220;The gateway MUST keep track =
of those clients that indicated support&#8230;&#8221; &nbsp;This statement =
is only true for gateways that themselves support redirection. If they don&=
#8217;t, they can ignore such indicators.<o:p></o:p></p><p class=3DMsoListP=
aragraph style=3D'text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !suppor=
tLists]><span style=3D'mso-list:Ignore'>3)<span style=3D'font:7.0pt "Times =
New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>Middle o=
f page 6: &#8220;one of the VPN gateway.&#8221; -&gt; &#8220;one of the VPN=
 gateways.&#8221;<o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-i=
ndent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style=3D'm=
so-list:Ignore'>4)<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; </span></span><![endif]>Section 7 (Handling Redirect Loo=
ps): This section mandates a default maximum number of redirects and a defa=
ult time limit over which that default applies. The IKEv2 spec goes out of =
its way to never specify such counts and timeouts, because the appropriate =
values are scenario dependent and the protocol is designed so that the valu=
es never affect interoperability. In this case, the values chosen still do =
not affect interoperability. I would recommend that the spec recommend thes=
e values rather than mandate them as defaults.<o:p></o:p></p><p class=3DMso=
ListParagraph style=3D'text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !s=
upportLists]><span style=3D'mso-list:Ignore'>5)<span style=3D'font:7.0pt "T=
imes New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>Thi=
s document defines some new IANA code points but calls for others to be ass=
igned by IANA. Unless there is some convention to the contrary or other goo=
d reason, I&#8217;d propose values for all of the code points rather than e=
xpecting the RFC editor to do it as the document is made into an RFC. This =
makes life simpler for the RFC editor and makes it possible to implement pr=
ototypes before the spec is advanced.<o:p></o:p></p><p class=3DMsoListParag=
raph style=3D'text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLis=
ts]><span style=3D'mso-list:Ignore'>6)<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>Middle of pa=
ge 5: &#8220;cannot also&#8221; -&gt; &#8220;also cannot&#8221;<o:p></o:p><=
/p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 leve=
l1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>7)<span style=
=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></s=
pan><![endif]>Last sentence of section 11: &#8220;and should be done&#8221;=
 -&gt; &#8220;and redirection should be done&#8221;<o:p></o:p></p></div></b=
ody></html>=

--_000_D80EDFF2AD83E648BD1164257B9B09121C4201TK5EX14MBXC119red_--

From alexey.melnikov@isode.com  Sun Sep  6 09:53:44 2009
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98ED3A6A04; Sun,  6 Sep 2009 09:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level: 
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Nr9y68AgtDu; Sun,  6 Sep 2009 09:53:44 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D422F3A67F0; Sun,  6 Sep 2009 09:53:43 -0700 (PDT)
Received: from [92.40.185.65] (92.40.185.65.sub.mbb.three.co.uk [92.40.185.65])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SqPpLwB9YUT0@rufus.isode.com>; Sun, 6 Sep 2009 17:54:08 +0100
Message-ID: <4AA3E912.6090503@isode.com>
Date: Sun, 06 Sep 2009 17:53:38 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Chris Lonvick <clonvick@cisco.com>
References: <Pine.GSO.4.63.0909041326580.18544@sjc-cde-011.cisco.com>
In-Reply-To: <Pine.GSO.4.63.0909041326580.18544@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: cyrus@daboo.name, secdir-secretary@mit.edu, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-daboo-srv-email-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Sep 2009 16:53:45 -0000

Chris Lonvick wrote:

> Hi,

Hi Chris,
Thank you for the review.

I largely like your editorial suggestions. I will review them with the 
author once IETF LC is over.

A quick comment on your last point:

> I'm curious as to why you're not asking for an IANA registry be 
> created for this.  A quick search shows that there is for IM SRV labels.
>   http://www.iana.org/assignments/im-srv-labels

I will be sponsoring publication of 
draft-gudmundsson-dns-srv-iana-registry which creates the new registry. 
Unfortunately draft-gudmundsson-dns-srv-iana-registry is not fully 
finished and I suspect there might be some debate about what should be 
covered by the new IANA registry. I would rather not delay 
draft-daboo-srv-email because of this.

Best Regards,
Alexey


From huitema@microsoft.com  Fri Sep  4 13:26:20 2009
Return-Path: <huitema@microsoft.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E7C3A6818; Fri,  4 Sep 2009 13:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.269
X-Spam-Level: 
X-Spam-Status: No, score=-10.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgeqZEIxvgBf; Fri,  4 Sep 2009 13:26:17 -0700 (PDT)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E81363A6839; Fri,  4 Sep 2009 13:26:16 -0700 (PDT)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Sep 2009 13:26:17 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server id 14.0.639.13; Fri, 4 Sep 2009 13:25:44 -0700
Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.236]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 4 Sep 2009 13:25:39 -0700
From: Christian Huitema <huitema@microsoft.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Gabi Nakibly <gnakibly@yahoo.com>, v6ops <v6ops@ops.ietf.org>
Thread-Topic: Routing loop attacks using IPv6 tunnels
Thread-Index: AQHKKBINum/797DxV0i7Fn5XwucC9pC8YBAAgASq/ICAAWKgAIADBeiAgAHmcYD//45QMA==
Date: Fri, 4 Sep 2009 20:25:21 +0000
Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.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>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 07 Sep 2009 00:04:59 -0700
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 20:26:20 -0000

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 in=
side a "site", typically protected by a firewall. The expected behavior is =
that hosts in that site will use direct ISATAP connectivity to exchange pac=
kets with each other, and will use the ISATAP router to exchange packets wi=
th other IPv6 subnets.

Assume that the site is defined by a set of IPv4 subnets, and the ISATAP ro=
uter knows that list. The basic check in the ISATAP router is thus:

        On incoming packet:
                If IPv6 source belongs to local ISATAP subnet (matches /64 =
prefix):
                        If (IPv4 source does not match last 32 bits of IPv6=
 source): drop;
                        Else If (IPv4 source does not belong to one of regi=
stered subnets): drop;
                        Else relay; // we may or may not want to add a dest=
ination check
                Else
                        If (IPv4 source belongs to one of registered subnet=
s): drop;
                        Else if (IPv6 destination does not match ISATAP sub=
net): drop;
                        Else if (embedded IPv4 address does not belong to o=
f registered subnets): drop;
                        Else relay;

Written that way, the ISATAP router cannot create a loop, because packets a=
lways 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 Tem=
plin, 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" <Fred.L.Templin@boeing.com>
> > To: Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>
> > 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 "<foreign prefix>::0200:5efe:<my IP address>")
> > >        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.
>
> Why do you think so? As I see it, the two checks mitigate two different a=
ttacks. The destination
> address check defends the ISATAP router against attacks of type 3 in whic=
h it acts as
> the decapsulator of the attack packet.  While, the source address check d=
efends the ISATAP
> router against attacks of type 3 in which it acts as the ecapsulator of t=
he attack packet.  Either of
> these checks are redundant if the other one is employed by the opposite r=
outer 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 abs=
olutely sure that the
> destination address check shall always be implemented correctly at all ot=
her 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 mitigati=
on
> > of most of
> > > > these attacks is
> > > > > indeed the proto-41 and ingress filtering on the border of the IS=
ATAP
> > site. If
> > > > it is indeed
> > > > > implemented. I assume that not all sites deploy such filtering fo=
r lack of
> > > > awareness or since the
> > > > > proto-41 filtering may break other tunnels the site may employ. H=
owever, I
> > do
> > > > not have hard evidence
> > > > > on this. I would be happy if others on the list will refute or ju=
stify
> > 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 effecti=
ve 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 che=
ck of the
> > > > > > neighbor cache before
> > > > > > > forwarding a packet into the tunnel. It truly addresses the r=
oot 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 propose=
d
> > > > > > 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-feasibili=
ty of
> > > > > > verifying that the
> > > > > > > destination ISATAP address does not include a local IPv4 addr=
ess 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 pub=
lic IPv4
> > > > > > addresses then this will
> > > > > > > eliminate the attacks in which the two victims reside at diff=
erent
> > sites.
> > > > Note
> > > > > > that if attack #3 is
> > > > > > > launched on two ISATAP routers having private addresses at tw=
o
> > different
> > > > sites
> > > > > > then the attack will
> > > > > > > not work anyway since one router can not send a direct IPv4 p=
acket 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 addre=
ss must
> > not
> > > > be
> > > > > > "2002:> > the ISATAP router>::*". In this case the IPv4 address=
 must be
> > > > public,
> > > > > > according to
> > > > > > >  the 6to4 spec.
> > > > > > >
> > > > > > > As you also noted there is another problem with this check si=
nce the
> > > > string
> > > > > > "200::5EFE" is not unique
> > > > > > > to ISATAP links. On the other hand, it seems that the probabi=
lity to
> > > > encounter
> > > > > > a non-malicious packet
> > > > > > > with a destination address having an IID that equals "200:5EF=
E:> IPv4
> > > > address>" is
> > > > > > > pretty slim.
> > > > > > >
> > > > > > > This check is definitely not a perfect solution, and I sure h=
ope 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 in=
gress)
> > > > by other
> > > > > > nodes (which does not
> > > > > > > necessarily exist).
> > > > > >
> > > > > > You seem to be envisioning a scenario of ISATAP router operatio=
n
> > > > > > with public IPv4 addresses and outside of any site border route=
rs
> > > > > > that perform ingress filtering and ip-proto-41 filtering. That =
has
> > > > > > traditionally been seen as the domain of 6to4, but I am happy t=
o
> > > > > > 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 ad=
dresses
> > 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 nic=
e
> > > > > > 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:
> > > > > >
> > > > > >   isatap_rcv() {
> > > > > >     ...
> > > > > >     if (dst =3D=3D "2002:::*")
> > > > > >       drop_pkt(); /* attack #1 mitigation */
> > > > > >
> > > > > >     if (dst =3D=3D "*::0200:5efe:")
> > > > > >     drop_pkt(); /* attack #3 mitigation */
> > > > > >     ...
> > > > > >   }
> > > > > >
> > > > >
> > > > > Correct (with the correction you sent after this email).
> > > >
> > > > OK.
> > > >
> > > > > >   isatap_xmt() {
> > > > > >     ...
> > > > > >     if (dst =3D=3D "*::0200:5efe:192.88.99.1")
> > > > > >       drop_pkt(); /* attack #2 mitigation */
> > > > > >     ...
> > > > > >   }
> > > > >
> > > > > This will not necessarily work, since the 6to4 relay may have a u=
nicast
> > > > address the ISATAP router may
> > > > > not be aware of. The best way to mitigate attack #2 is by the 6to=
4 relay
> > with
> > > > a check similar to that
> > > > > of attack #2 above. IMO, the second best way, as Remi suggested o=
n another
> > > > thread, is for the ISATAP
> > > > > router to drop the packet if (src  =3D=3D 2002:::*"). However, th=
is
> > > > check is useful only
> > > > > when the 6to4 relay validates that the IPv6 source address corres=
ponds 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 su=
ch 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 mand=
ate
> > > > > > > > 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 enterpris=
e
> > > > > > > =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 packe=
t with
> > its
> > > > own
> > > > > > IPv4 address as the
> > > > > > > source address.
> > > > > > >
> > > > > > >
> > > > > > > =3D=3D> There were a number of errors in what I said in my la=
st
> > > > > > > =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 f=
rom the
> > > > > > > =3D=3D> ISATAP router, and case 2 in which no border router s=
eparates
> > > > > > > =3D=3D> the 6to4 relay from the ISATAP router.
> > > > > > > =3D=3D>
> > > > > > > =3D=3D> In attack #1, we have an IPv6 packet with a local sou=
rce
> > > > > > > =3D=3D> address entering the site from the outside. IPv6 ingr=
ess
> > > > > > > =3D=3D> filtering at the site border router should prevent th=
e
> > > > > > > =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-4=
1
> > > > > > > =3D=3D> filtering at the border router will block the attack =
in
> > > > > > > =3D=3D> the first place anyway. If the relay router is *insid=
e*
> > > > > > > =3D=3D> the site, then the IPv6 ingress filtering is the lone
> > > > > > > =3D=3D> mitigation. The end result is that the 6to4 relay sho=
uld
> > > > > > > =3D=3D> really be positioned outside of the site's border rou=
ters;
> > > > > > > =3D=3D> otherwise, it could be spoofed into thinking that the
> > > > > > > =3D=3D> ISATAP router is a 6to4 router and not an ISATAP rout=
er.
> > > > > > > =3D=3D>
> > > > > > > =3D=3D> In attack #2, we have an IPv6 packet with a foreign s=
ource
> > > > > > > =3D=3D> address being forwarded by the ISATAP router to a 6to=
4
> > > > > > > =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 IS=
ATAP
> > > > > > > =3D=3D> router knows, the 6to4 relay is just an ordinary host=
 on
> > > > > > > =3D=3D> the ISATAP link, so the ISATAP router actually believ=
es 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 rou=
ter 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 bes=
t
> > > > > > > =3D=3D> operational practice would again be to have the 6to4 =
relay
> > > > > > > =3D=3D> oriented outside of a border router that filters ip-p=
roto-41.
> > > > > > > =3D=3D>
> > > > > > > =3D=3D> Short summary is that in attack #1, the 6to4 relay th=
inks 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-4=
1
> > > > > > > =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-exter=
nal
> > > > > > > =3D=3D> IPv4 interface and implements ISATAP on a site-intern=
al
> > > > > > > =3D=3D> IPv4 interface and performs ip-proto-41 filtering on =
packets
> > > > > > > =3D=3D> from outside the site with an IPv4 destination corres=
ponding
> > > > > > > =3D=3D> to the ISATAP interface. I will discuss attack #3 bel=
ow:
> > > > > > >
> > > > > > > This attack is mitigated by
> > > > > > > IPv6 ingress filtering which is an IPv6 security consideratio=
n
> > > > > > > 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 configur=
e
> > > > > > > ISATAP interfaces will implement IPv6 ingress filtering
> > > > > > > according to the BCP.
> > > > > > >
> > > > > > > So If my last comment is correct than I do not see how ingres=
s
> > 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 fr=
om
> > 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 borde=
r,
> > > > > > > =3D=3D> but as with attack #2 my error in the previous messag=
e
> > > > > > > =3D=3D> was in thinking the ISATAP router A was forwarding th=
e
> > > > > > > =3D=3D> packet *out* of the ISATAP link when in fact from the
> > > > > > > =3D=3D> ISATAP router's perspective it is forwarding the pack=
et
> > > > > > > =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 si=
mple
> > > > > > > =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 l=
ead
> > > > > > > =3D=3D> to strange scenarios when the anonymous node is a tun=
nel
> > > > > > > =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 rou=
ter
> > > > > > > =3D=3D> to check whether the IPv6 destination address is an I=
SATAP
> > > > > > > =3D=3D> address that embeds one of its own IPv4 addresses, be=
cause
> > > > > > > =3D=3D> when IPv4 private addresses are used the same IPv4 ad=
dress
> > > > > > > =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 t=
he
> > > > > > > =3D=3D> IPv6 prefix is foreign, the router can't very well dr=
op the
> > > > > > > =3D=3D> packet as this would block legitimate communications.=
 It
> > > > > > > =3D=3D> is also not generally possible to check whether a for=
eign
> > > > > > > =3D=3D> link is an ISATAP link by looking for the magic token
> > > > > > > =3D=3D> "0:5EFE" as that token only has significance for ISAT=
AP
> > > > > > > =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 w=
hich
> > > > > > > =3D=3D> it assumes to be a simple ISATAP host has demonstrate=
d a
> > > > > > > =3D=3D> willingness to participate in the link. That can be d=
one
> > > > > > > =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 no=
des
> > > > > > > =3D=3D> that are willing ISATAP hosts on the link, there woul=
d
> > > > > > > =3D=3D> have been a neighbor cache entry created when the nod=
e
> > > > > > > =3D=3D> sends a Router Solicitation to the ISATAP router for =
the
> > > > > > > =3D=3D> purpose of discovering default router lifetimes and o=
n-
> > > > > > > =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-e=
xisting
> > > > > > > =3D=3D> neighbor cache entry and drop the packet otherwise. T=
his
> > > > > > > =3D=3D> implies that the router should keep neighbor cache en=
tires
> > > > > > > =3D=3D> for the duration of the minimum lifetime of the prefi=
xes
> > > > > > > =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 li=
ke in
> > attack
> > > > #3.
> > > > > > Do you also think that
> > > > > > > proto-41 filtering should barrier between the two tunnels wit=
hin 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 bord=
er
> > > > > > > =3D=3D> rather than inside, and ISATAP router interfaces insi=
de
> > > > > > > =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 shou=
ld
> > > > > > > =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 RF=
C5214:
> > > > > > >
> > > > > > > > 6.2.  ISATAP Interface Address Configuration
> > > > > > > >
> > > > > > > >   Each ISATAP interface configures a set of locators consis=
ting of
> > IPv4
> > > > > > > >   address-to-interface mappings from a single site; i.e., a=
n ISATAP
> > > > > > > >   interface's locator set MUST NOT span multiple sites.
> > > > > > >
> > > > > > > In particular, in scenarios A, B and C the IPv4 locator used =
for
> > ISATAP
> > > > > > > is seen both within the enterprise as site #1 and within the =
global
> > > > Internet
> > > > > > > itself as site #2. If the ISATAP interface is to be used as a=
n
> > enterprise-
> > > > > > > interior interface, it should therefore not accept IP-proto-4=
1 packets
> > > > > > > coming from an IPv4 source outside of the enterprise nor sour=
ce
> > > > > > > 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 f=
iltering
> > as
> > > > > > > required in Section 10 of RFC5214.
> > > > > > >
> > > > > > > It is mentioned that attack C could also occur when the route=
rs reside
> > > > > > > in the same site, where their addresses may be private. This =
would
> > > > > > > correspond to a case in which an attacker within the site att=
acks the
> > > > > > > site itself, which can easily be traced - especially when sou=
rce
> > address
> > > > > > > spoofing from a node within the site is prevented through pro=
per
> > 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 pu=
blished.
> > 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. S=
ince it
> > is
> > > > not
> > > > > > compatible with its
> > > > > > > predecessor, some interoperability mechanisms were designed. =
An
> > important
> > > > > > category of these
> > > > > > > mechanisms is automatic tunnels, which enable IPv6 communicat=
ion 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 a=
ttacks
> > 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 particu=
lar, the
> > > > attacks
> > > > > > were tested
> > > > > > > against the ISATAP, 6to4 and Teredo implementations of Window=
s Vista
> > and
> > > > > > Windows Server 2008 R2.
> > > > > > >
> > > > > > > I think the results of the research warrant some corrective a=
ction. If
> > > > > > this indeed shall be the
> > > > > > > general sentiment of the list, I will be happy write an appro=
priate
> > I-D.
> > > > The
> > > > > > mitigation measures we
> > > > > > > suggested in the paper are the best we could think of to comp=
letely
> > > > 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
--------------------------------------------------------------------


From kent@bbn.com  Mon Sep  7 08:16:29 2009
Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03ECA3A69C9 for <secdir@core3.amsl.com>; Mon,  7 Sep 2009 08:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level: 
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9hm267rAuO8 for <secdir@core3.amsl.com>; Mon,  7 Sep 2009 08:16:28 -0700 (PDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2D8823A695A for <secdir@ietf.org>; Mon,  7 Sep 2009 08:16:28 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1Mkf1a-0007uO-Dh; Mon, 07 Sep 2009 10:16:54 -0400
Mime-Version: 1.0
Message-Id: <p06240809c6cad2cc37b4@[192.168.1.5]>
In-Reply-To: <FED2184CF597405083AE68F9F2DFCE19@your029b8cecfe>
References: <200909040212.n842CS3M028820@harbor.orleans.occnc.com> <FED2184CF597405083AE68F9F2DFCE19@your029b8cecfe>
Date: Mon, 7 Sep 2009 11:10:49 -0400
To: Adrian Farrel <Adrian.Farrel@huawei.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: mpls-chairs@tools.ietf.org, secdir <secdir@ietf.org>, draft-ietf-mpls-soft-preemption@tools.ietf.org
Subject: Re: [secdir] Security review: draft-ietf-mpls-soft-preemption-18.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Sep 2009 15:16:29 -0000

At 12:04 PM +0100 9/4/09, Adrian Farrel wrote:
>Hi Stephen,
>
>Thanks for your review. After discussion with the authors, I have 
>added an RFC Editor note as follows.
>
>Thanks,
>Adrian
>
>Section 10
>OLD
>   This document does not introduce new security issues.  The security
>   considerations pertaining to the original RSVP protocol [RFC3209]
>   remain relevant.
>NEW
>   This document does not introduce new security issues.  The security
>   considerations pertaining to the original RSVP protocol [RFC3209]
>   remain relevant. Further details about MPLS security considerations
>   can be found in [I-D.ietf-mpls-mpls-and-gmpls-security].
>
>   As noted in Section 6.1, soft preemption may result in temporary link
>   under provisioning condition while the soft preempted TE LSPs are
>   rerouted by their respective head-end LSRs. Although this is a less
>   serious condition than false hard preemption, and despite the
>   mitigation procedures described in Section 6.1, network operators
>   should be aware of the risk to their network should the soft
>   preemption processes be subverted, and should apply the relevant MPLS
>   control plane security techniques to protect against attacks.
>---
>Section 13.2
>ADD
>   [I-D.ietf-mpls-mpls-and-gmpls-security] Fang, L. Ed., "Security
>              Framework for MPLS and GMPLS Networks", draft-ietf-mpls-
>              mpls-and-gmpls-security-framework-06.txt, work in
>              progress.



Thanks for the reply. I these minor text changes address my concerns.

Steve

From hilarie@purplestreak.com  Mon Sep  7 19:11:22 2009
Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5321B3A68FF for <secdir@core3.amsl.com>; Mon,  7 Sep 2009 19:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level: 
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-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 TbfO0g2UNEOS for <secdir@core3.amsl.com>; Mon,  7 Sep 2009 19:11:21 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 019103A68E9 for <secdir@ietf.org>; Mon,  7 Sep 2009 19:11:17 -0700 (PDT)
Received: from mx01.mta.xmission.com ([166.70.13.211]) by out01.mta.xmission.com with esmtp (Exim 4.62) (envelope-from <hilarie@purplestreak.com>) id 1MkqBe-0000d9-UW; Mon, 07 Sep 2009 20:12:02 -0600
Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1MkqBM-00066r-QT; Mon, 07 Sep 2009 20:11:45 -0600
Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-6) with ESMTP id n882Bd20022974; Mon, 7 Sep 2009 20:11:39 -0600
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id n882Bbt7022971; Mon, 7 Sep 2009 20:11:37 -0600
Date: Mon, 7 Sep 2009 20:11:37 -0600
Message-Id: <200909080211.n882Bbt7022971@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: "Hilarie Orman" <ho@alum.mit.edu>
To: secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=no signature
X-SA-Exim-Connect-IP: 166.70.57.249
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: ;secdir@ietf.org
X-Spam-Relay-Country: 
X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000)
X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com)
Cc: vach.kompella@alcatel-lucent.com, Shane.Amante@Level3.com, alex.zinin@alcatel-lucent.com, rdroms@cisco.com, florin.balus@alcatel-lucent.com, jari.arkko@piuha.net, mustapha.aissaoui@alcatel-lucent.com
Subject: [secdir] Review of draft-ietf-pwe3-segmented-pw-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 02:11:22 -0000

Review of draft-ietf-pwe3-segmented-pw-13

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

This document extends the pseudo-wire (PWE3) architecture by defining
multi-segment pseudo-wires.  A pseudowire (PW) links two Terminating
Provider Edges (T-PEs).  PWs are transmitted through a tunnel between
the T-PEs.  I'll call this a bundle of PW's.  A multi-segment PW
connects two bundles and (de)multiplexes the PWs to the correct
tunnels.

At this point I need to disclose that I have never before heard of PWs
and have only a foggy notion of their purpose.  I'm sorry for being
ignorant.  There is more to PWs than I can absorb in the time
available for a review.  I can, however be slightly helpful in noting
that section 3.i. uses the term "cryptogtaphiclly (sic) sign" where
"include a cryptographic message authenticator" is more accurate.

Again, on the apology side of the ledger, I cannot follow the first
example motivating the need for multi-segment PWs.  Somehow, if
authentication is used between two AS's, and if they use a single PW,
then they would have to include an authenticator on all T-PE messages.
And that is somehow bad.

The second example involves a routing protocol that sets up a path
involving concatenated PWs.  In that case, multi-segments with
switching can dynamically (?) carry the traffic between the intended
T-PEs.  That's good because it avoids setting up PWs for all possible
paths.

The third example is even harder, and in that one, multi-segment
switching has the potential (why not guarantee?) of reducing the
number of PWE3 control channels.

The diagrams showing the evolution of the architecture from a single
tunnel with a bundle of PWs to multiple tunnels and then to switched
tunnels is very helpful, but I don't really see how the examples fit
into it.

The gist of the document is that single-segment PWs can be joined into
multi-segment PWs, with all of the security problems that attend to
any similar graph building procedure.  The document relies on several
preceding documents for exchanging control information, all of which
have security considerations, all of which apparently apply to the
multi-segment case.

I failed to get an elemental understanding of how the signalling and
control messages extend the single-segment PWs to multi-segment PWs.

In section 10.3 this sentence appears to have a missing or incorrect
word:

   However T-PE
   participating a MS-PW, SHOULD be able to process the S-PE TLV.


The looming security problem is that the only way to make sure that
connections are made correctly is to have a table of endpoints and
pre-placed shared keys between them.  Is this at all realistic, given
that multi-segment PWs are for situations in which an organization has
developed an architecture too rich for single-segement PWs? 

Because I don't fully understand PWs, and because the underlying
protocols for exchanging control information rely on pre-placed keys,
I cannot recommend anything better.  I do hope that anyone using this
kind of architecture is clueful and careful.


Hilarie

From jsalowey@cisco.com  Mon Sep  7 21:32:12 2009
Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A447328C126; Mon,  7 Sep 2009 21:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.587
X-Spam-Level: 
X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWS5MfSkXxg6; Mon,  7 Sep 2009 21:32:11 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C30A53A6A76; Mon,  7 Sep 2009 21:32:11 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAKd6pUqrR7PE/2dsb2JhbADCE4hDAY59BYQYgVk
X-IronPort-AV: E=Sophos;i="4.44,350,1249257600"; d="scan'208";a="238483432"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 04:32:38 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n884Wc0a002521;  Mon, 7 Sep 2009 21:32:38 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n884WcAu006763; Tue, 8 Sep 2009 04:32:38 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 7 Sep 2009 21:32:37 -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
Date: Mon, 7 Sep 2009 21:32:36 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE508AF8EC8@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Secdir review of draft-ietf-mip4-generic-notification-message-09
Thread-Index: AcowPWQqcdrJ6bOkQLWdQhZupDz2Lg==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <secdir@ietf.org>, <iesg@ietf.org>, <draft-ietf-mip4-generic-notification-message@tools.ietf.org>, <mip4-chairs@tools.ietf.org>
X-OriginalArrivalTime: 08 Sep 2009 04:32:37.0902 (UTC) FILETIME=[64FE82E0:01CA303D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2398; t=1252384358; x=1253248358; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci sco.com> |Subject:=20Secdir=20review=20of=20draft-ietf-mip4-generic- notification-message-09 |Sender:=20; bh=aoUhVqGsyp+Wb5gdl+Y3K28WaX86IFiSX+JXHYnMgRM=; b=fAoGZUw85GQWE9n4ykVtBHjyqzRHwa8oYo7BnXb23YGJns6A4CtsRQCQNZ k+FXDlUd8jfIKImApfYEQKZRybcIcB+SSiIamnq54WaPA4UdANGjs18wQA3b PcYKbcc387;
Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Subject: [secdir] Secdir review of draft-ietf-mip4-generic-notification-message-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 04:32:12 -0000

 have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

I have primarily focused on the security considerations section in this
document.  I also quickly reviewed the rest of the document.  Based on
my review I have the following comments:

1. In section 4.1, Identification

It states "nonces" are optional.  Nonces are not mentioned in the rest
of the document.  This option should be removed. =20

2. Section 4.1, extensions

I found this section confusing as to when the AE is required.  It seems
the document states that the AE is always required, however it also uses
optional.   For example its not clear to me what is required in the case
given is section 3.2.

3. Section 4.2, extensions

Shouldn't the AE be required for GNAM?

4. Security considerations Section 8

It also wasn't quite clear to me when the AE is optional and mandatory.


5. Section 8.1

There are several places in the document where different replay
mechanisms are alluded to, included this section.  This section states
that nodes must agree on the mechanism used.  However there appears to
be no way to signal what mechanism is in use.  Is this assumed to be
pre-configured in each node, or is there another mechanism for this?  Is
this realistic for deployments?=20

6. Section 8.1.1

NTP RFC 1305 needs to be included in the normative references.

Why is it important "those bits which are not available from a time
source SHOULD be generated from a good source of randomness" ? (it seems
that you don't really want bits to be random since you want to enforce
ordering)

This section also talks very briefly about clock synchronization.  It
seems there could be security implications here.  One node may be able
to poison a clock to an in appropriate value.  There probably should be
more discussion here. =20

7. Section 8.2=20

This section makes a statement but does not describe how impacts the
security of the system.  Since authentication is not performed can you
use the extension defined in the document in this case?  What is the
effect of the lack of authentication. =20

From jari.arkko@piuha.net  Mon Sep  7 23:11:16 2009
Return-Path: <jari.arkko@piuha.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683F23A68D4; Mon,  7 Sep 2009 23:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.672
X-Spam-Level: 
X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gbZoz1wz+cz; Mon,  7 Sep 2009 23:11:15 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A17873A67D9; Mon,  7 Sep 2009 23:11:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CEADCD6270; Tue,  8 Sep 2009 09:11:43 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLdOfHrXWGOn; Tue,  8 Sep 2009 09:11:43 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 372D5D6246; Tue,  8 Sep 2009 09:11:43 +0300 (EEST)
Message-ID: <4AA5F59E.4050907@piuha.net>
Date: Tue, 08 Sep 2009 09:11:42 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE508AF8EC8@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE508AF8EC8@xmb-sjc-225.amer.cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mip4-chairs@tools.ietf.org, draft-ietf-mip4-generic-notification-message@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-mip4-generic-notification-message-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 06:11:16 -0000

Thanks for your review! Authors, do you have suggested text edits and/or 
a new draft version to address these?

Jari

Joseph Salowey (jsalowey) wrote:
>  have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> I have primarily focused on the security considerations section in this
> document.  I also quickly reviewed the rest of the document.  Based on
> my review I have the following comments:
>
> 1. In section 4.1, Identification
>
> It states "nonces" are optional.  Nonces are not mentioned in the rest
> of the document.  This option should be removed.  
>
> 2. Section 4.1, extensions
>
> I found this section confusing as to when the AE is required.  It seems
> the document states that the AE is always required, however it also uses
> optional.   For example its not clear to me what is required in the case
> given is section 3.2.
>
> 3. Section 4.2, extensions
>
> Shouldn't the AE be required for GNAM?
>
> 4. Security considerations Section 8
>
> It also wasn't quite clear to me when the AE is optional and mandatory.
>
>
> 5. Section 8.1
>
> There are several places in the document where different replay
> mechanisms are alluded to, included this section.  This section states
> that nodes must agree on the mechanism used.  However there appears to
> be no way to signal what mechanism is in use.  Is this assumed to be
> pre-configured in each node, or is there another mechanism for this?  Is
> this realistic for deployments? 
>
> 6. Section 8.1.1
>
> NTP RFC 1305 needs to be included in the normative references.
>
> Why is it important "those bits which are not available from a time
> source SHOULD be generated from a good source of randomness" ? (it seems
> that you don't really want bits to be random since you want to enforce
> ordering)
>
> This section also talks very briefly about clock synchronization.  It
> seems there could be security implications here.  One node may be able
> to poison a clock to an in appropriate value.  There probably should be
> more discussion here.  
>
> 7. Section 8.2 
>
> This section makes a statement but does not describe how impacts the
> security of the system.  Since authentication is not performed can you
> use the extension defined in the document in this case?  What is the
> effect of the lack of authentication.  
>
>   


From gnakibly@yahoo.com  Tue Sep  8 01:22:33 2009
Return-Path: <gnakibly@yahoo.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D2128C0E4 for <secdir@core3.amsl.com>; Tue,  8 Sep 2009 01:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.575
X-Spam-Level: 
X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.424,  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 fjd06v2MqBlU for <secdir@core3.amsl.com>; Tue,  8 Sep 2009 01:22:30 -0700 (PDT)
Received: from web45503.mail.sp1.yahoo.com (web45503.mail.sp1.yahoo.com [68.180.197.71]) by core3.amsl.com (Postfix) with SMTP id 48B5E3A67FF for <secdir@ietf.org>; Tue,  8 Sep 2009 01:22:30 -0700 (PDT)
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 <gnakibly@yahoo.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, v6ops <v6ops@ops.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
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 08:22:33 -0000

Fred,=0A=0ASe below.=0A=0AGabi=0A----- Original Message ----=0A> From: "Tem=
plin, Fred L" <Fred.L.Templin@boeing.com>=0A> To: Gabi Nakibly <gnakibly@ya=
hoo.com>; v6ops <v6ops@ops.ietf.org>=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 gnakibly@yahoo.com  Tue Sep  8 02:04:56 2009
Return-Path: <gnakibly@yahoo.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D9C28C0D8 for <secdir@core3.amsl.com>; Tue,  8 Sep 2009 02:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.757
X-Spam-Level: 
X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.242,  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 pucaZaLrBsR8 for <secdir@core3.amsl.com>; Tue,  8 Sep 2009 02:04:56 -0700 (PDT)
Received: from web45511.mail.sp1.yahoo.com (web45511.mail.sp1.yahoo.com [68.180.197.143]) by core3.amsl.com (Postfix) with SMTP id 1E66D3A657C for <secdir@ietf.org>; Tue,  8 Sep 2009 02:04:56 -0700 (PDT)
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 <gnakibly@yahoo.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, v6ops <v6ops@ops.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
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 09:04:56 -0000

Fred,=0A=0A=0A=0A----- Original Message ----=0A> From: "Templin, Fred L" <F=
red.L.Templin@boeing.com>=0A> To: Gabi Nakibly <gnakibly@yahoo.com>; v6ops =
<v6ops@ops.ietf.org>=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 gnakibly@yahoo.com  Tue Sep  8 05:27:18 2009
Return-Path: <gnakibly@yahoo.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897F63A6825 for <secdir@core3.amsl.com>; Tue,  8 Sep 2009 05:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.811
X-Spam-Level: 
X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.188,  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 GinTMDXDYnLx for <secdir@core3.amsl.com>; Tue,  8 Sep 2009 05:27:15 -0700 (PDT)
Received: from web45515.mail.sp1.yahoo.com (web45515.mail.sp1.yahoo.com [68.180.197.179]) by core3.amsl.com (Postfix) with SMTP id 6C7733A6813 for <secdir@ietf.org>; Tue,  8 Sep 2009 05:27:15 -0700 (PDT)
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 <gnakibly@yahoo.com>
To: Christian Huitema <huitema@microsoft.com>, "Templin, Fred L" <Fred.L.Templin@boeing.com>, v6ops <v6ops@ops.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
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 12:27:18 -0000

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 <huitema@microsoft.com>=0A> To: "Templin, Fred L" <F=
red.L.Templin@boeing.com>; Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@=
ops.ietf.org>=0A> Cc: "ipv6@ietf.org" <ipv6@ietf.org>; "secdir@ietf.org" <s=
ecdir@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 barryleiba.mailing.lists@gmail.com  Tue Sep  8 08:30:40 2009
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD22F3A68D8; Tue,  8 Sep 2009 08:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.476
X-Spam-Level: 
X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4e8eGpm6O7y; Tue,  8 Sep 2009 08:30:40 -0700 (PDT)
Received: from mail-yx0-f201.google.com (mail-yx0-f201.google.com [209.85.210.201]) by core3.amsl.com (Postfix) with ESMTP id 763803A6767; Tue,  8 Sep 2009 08:30:39 -0700 (PDT)
Received: by yxe39 with SMTP id 39so6051642yxe.18 for <multiple recipients>; Tue, 08 Sep 2009 08:31:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:cc:content-type; bh=lHJbqltgzAMM1f93LVQm9qgWcApKmpxs76D5t8UeEIg=; b=mSURphhEPwjJ+jQmevGzJbOXXF6LNvgiIk9znzmR9wm/5NpTTq+h76pAtGgwhGyTK1 OYEuwmMAtpOIt7lUuAoMlTIqgJhgOzBmeowBPtkhfCNsOiATQZXzU65cWI3Zr0TI2Y+5 0A2Fq0nlFqqcGFUmVX8TlNZm7QfXCqSFbdskM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=EzYQeO8DtngNVPZryhtQcuWirOFz47lliFwj/GAALwvMkApOAlJFBpwhwOGO2xsBet kSVQr5bNwrreAq44jisQ9c583O5OGEKHWJBg/kGX59MDwDrYsCoxt3Ihn7AM1cBFdhMg /u2yC7NZpG3nBtCmv2hopdERyvBprEZ+uBIPs=
MIME-Version: 1.0
Received: by 10.150.107.2 with SMTP id f2mr26186153ybc.188.1252423865609; Tue,  08 Sep 2009 08:31:05 -0700 (PDT)
Date: Tue, 8 Sep 2009 11:31:05 -0400
Message-ID: <6c9fcc2a0909080831pfc1a77fy8203ee0b4ab08cb1@mail.gmail.com>
From: Barry Leiba <barryleiba.mailing.lists@gmail.com>
To: secdir@ietf.org, iesg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: sipping-chairs@tools.ietf.org, draft-ietf-sipping-service-identification@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-sipping-service-identification-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: barryleiba@computer.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 15:30:40 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I was asked to review this document because I'd reviewed
draft-drage-sipping-service-identification some time ago.  Only, this
document doesn't derive from that one, but, rather, from
draft-rosenberg-sipping-service-identification, and it has none of the
issues I had with the other document.

I find this one useful and enlightening, and a good contribution to
the informational stream about SIP.  No issues, from a secdir point of
view or otherwise.

-- Barry Leiba

From barryleiba.mailing.lists@gmail.com  Tue Sep  8 08:59:51 2009
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3684428C18A; Tue,  8 Sep 2009 08:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level: 
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUGuWlivBiFT; Tue,  8 Sep 2009 08:59:50 -0700 (PDT)
Received: from mail-yx0-f199.google.com (mail-yx0-f199.google.com [209.85.210.199]) by core3.amsl.com (Postfix) with ESMTP id 1C2EC28C179; Tue,  8 Sep 2009 08:59:50 -0700 (PDT)
Received: by yxe37 with SMTP id 37so1182868yxe.5 for <multiple recipients>; Tue, 08 Sep 2009 09:00:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:cc:content-type; bh=W8m/t32zCvi62JCFgYaK5jRB3sTn5ZMBlYlWjnLnOIo=; b=Pmt4g2AtS5NsmRuwcgEIpnKbEr2UnjYL2N4ILVDfjy8XCwq8c5mth1GzCvIf2GVWa5 3PQhOhvnwI0uOg7pkx5PM5QoGjgg8NJoIZWGtLkWAiWmLrmEmPUbXg7yxcpui7FL3G6e mP5GH4DEDuxxflnz6qNy3qIdUnqwQrDsHDNa8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=v17FzBC7dl+oQjE+eqJv7jvwamdxmxu66vsuAbp4sCdAak3aByOBMCuOSc80LjdqDc I+8gSoapLQASaQ0DkPcKXbVUryvlVKyFzqUgvSXnxIXYkAUIx/udUM0jfscRcN0tT0fJ ERxrpZIb0x51KZQKcYOL9dK3RxqKEicA8G9Gc=
MIME-Version: 1.0
Received: by 10.150.207.14 with SMTP id e14mr24957856ybg.149.1252425617647;  Tue, 08 Sep 2009 09:00:17 -0700 (PDT)
Date: Tue, 8 Sep 2009 12:00:17 -0400
Message-ID: <6c9fcc2a0909080900h7db8d58n21564c56e16bc543@mail.gmail.com>
From: Barry Leiba <barryleiba.mailing.lists@gmail.com>
To: secdir@ietf.org, iesg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: draft-iana-ipv4-examples@tools.ietf.org
Subject: [secdir] secdir review of draft-iana-ipv4-examples-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: barryleiba@computer.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 15:59:51 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This is just a short, informational document that reserved two new
address ranges for example use.  I have no significant issues with it.

I do have two minor questions:

1. The document does have normative language, telling operators what
they SHOULD and SHOULD NOT do with this addresses, and it instructs
IANA not to allocate addresses from these blocks.  Should it be BCP,
rather than Informational?  It doesn't matter terribly, so I'm just
asking the question.

2. The Security Considerations section says the document has no
security implications, but I'm not sure that's correct.  By calling
out certain addresses as examples, we might be inviting malefactors to
try to snag traffic meant for these addresses in an attempt to trick
those who use the example addresses as though they were real.  If the
advice in the Operational Implications section isn't followed, that
would result in an opportunity for fraud, for example.  I look at this
as an explanation of the importance of following the Operational
Implications advice.

Again, I consider this a minor point, and the document should
certainly go forward.

Barry

From lars.eggert@nokia.com  Tue Sep  8 09:41:46 2009
Return-Path: <lars.eggert@nokia.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4A53A69D2; Tue,  8 Sep 2009 09:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv7xEBnLmXpo; Tue,  8 Sep 2009 09:41:45 -0700 (PDT)
Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id DADE63A692A; Tue,  8 Sep 2009 09:41:44 -0700 (PDT)
Received: from lars.lan (e701.rooms.aueb.gr [195.251.233.136]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n88GfxJh094247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Sep 2009 19:42:00 +0300 (EEST) (envelope-from lars.eggert@nokia.com)
Mime-Version: 1.0 (Apple Message framework v1075.2)
Content-Type: multipart/signed; boundary=Apple-Mail-59--756987258; protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC5807CEEA50@xmb-sjc-21c.amer.cisco.com>
Date: Tue, 8 Sep 2009 19:41:59 +0300
Message-Id: <39808C30-0418-4B70-ABE3-124354C09FBE@nokia.com>
References: <Pine.WNT.4.64.0906080948290.6048@SANDYM-LT.columbia.ads.sparta.com> <03C04ACE-5773-4260-AABD-E799E614C469@nokia.com> <E63E6749-FD14-4F50-8351-0F1A48B50EB7@nokia.com> <0C53DCFB700D144284A584F54711EC5807CEEA50@xmb-sjc-21c.amer.cisco.com>
To: Anantha Ramaiah (ananth) <ananth@cisco.com>
X-Mailer: Apple Mail (2.1075.2)
Cc: "secdir@ietf.org" <secdir@ietf.org>, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, IESG IESG <iesg@ietf.org>
Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 16:41:46 -0000

--Apple-Mail-59--756987258
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes

Hi, authors,

please prepare and submit a revision based on the feedback you have  
received until now. We need to move forward with this document.

Sandy hasn't responded since June 8. Take the initial feedback you  
have gotten from her into account, but I think it is unreasonable to  
wait longer for any additional feedback.

Lars
--Apple-Mail-59--756987258
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw
ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X
uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY
Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB
6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT
VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr
ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu
ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt
I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H
5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80
QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK
MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7
n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw
QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl
ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl
TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M
Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg
T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP
6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTA5MDkwODE2NDE2MFowIwYJKoZIhvcNAQkEMRYEFHpIkUf0pz998dYm46UXqOolwpExMIGF
BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD
QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF
AASCAQBQLRsx9N3IafWnIpQhVJAOxRP7+mHFE18xxWbxn/6hkpF3n0LDrlivX1R15kYzBVqcRJeh
5hCLm3jKLuzj8HFOOTXHBd6IeFEr1/u9fp1y4J9m0MoxSSKWsNLz4dR7rEcYWOTVOsFBT/dJDi6+
KKLJzU9XvUkKwplBU5RwhfDQyLauIUfnoR7/rndUeuK7LL9qqcBWNdkikE2t5Wsd+QVVlUJjT5N7
QH3DW6IJsE4B3XcbyO6JKQnwso99oxfeuGre2Ezw2o80Tc0x2Zck1tFOxaLPBMULGKaUNEt3KUmm
qGtA634Iq3HQNpSPofSDPHb/Jd0HfngT/O+s2q+DrvQcAAAAAAAA

--Apple-Mail-59--756987258--

From denghui02@gmail.com  Tue Sep  8 09:31:38 2009
Return-Path: <denghui02@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2EB3A68B4; Tue,  8 Sep 2009 09:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.418
X-Spam-Level: 
X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1uz29b4hzbE; Tue,  8 Sep 2009 09:31:37 -0700 (PDT)
Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 2015A3A6896; Tue,  8 Sep 2009 09:31:35 -0700 (PDT)
Received: by ewy3 with SMTP id 3so3690196ewy.42 for <multiple recipients>; Tue, 08 Sep 2009 09:32:01 -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 :content-transfer-encoding; bh=9+hy8lMWiy9T8SA9B9qWAg3EnQMOrGzu6Md947SFqFY=; b=xvMiLxy9RALlSP1udfBflm/4Ny/zP6BVe/r7bTz2O1aul22e5KbHb61TxUvGxWefJD cCtGG6utR6DKsqkaXVDaNoaEHZZuN/bZ1T/a513maTmDWYBh05TlgQYJBP56GiavH2yI mBaeeQWyBZwXlp1r1ihmTYpMEwPnGhmaomlAc=
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:content-transfer-encoding; b=oOits1PRv9FdohTUiQ2DHVPWmi8u59+hLJ8xNlOhVesTdLLb5LZeOFmWOueRMNmtzX OmF8r+eLb1OTGcqd2wG1UIsM8YPVPkYnAGRgr2XhlUzOJ84JzMlf4+sI6Tq+K/MADObi o0cB1qS7k1CmfuNNo4C8TViChMAjgCSunsB9E=
MIME-Version: 1.0
Received: by 10.211.184.18 with SMTP id l18mr17795444ebp.30.1252427518381;  Tue, 08 Sep 2009 09:31:58 -0700 (PDT)
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE508AF8EC8@xmb-sjc-225.amer.cisco.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE508AF8EC8@xmb-sjc-225.amer.cisco.com>
Date: Wed, 9 Sep 2009 00:31:58 +0800
Message-ID: <1d38a3350909080931gfe1f17ao4921f6c11d33e9e4@mail.gmail.com>
From: Hui Deng <denghui02@gmail.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 08 Sep 2009 09:57:44 -0700
Cc: mip4-chairs@tools.ietf.org, draft-ietf-mip4-generic-notification-message@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-mip4-generic-notification-message-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 16:31:38 -0000

Dear Joseph Salowey

Thanks for ur kind help, the draft has been updated to version 11
based on ur major comments
reply inline.

2009/9/8 Joseph Salowey (jsalowey) <jsalowey@cisco.com>:
>
> =A0have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. =A0Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> I have primarily focused on the security considerations section in this
> document. =A0I also quickly reviewed the rest of the document. =A0Based o=
n
> my review I have the following comments:
>
> 1. In section 4.1, Identification
>
> It states "nonces" are optional. =A0Nonces are not mentioned in the rest
> of the document. =A0This option should be removed.
based on mip4's discussion, nonces section has been updated

>
> 2. Section 4.1, extensions
>
> I found this section confusing as to when the AE is required. =A0It seems
> the document states that the AE is always required, however it also uses
> optional. =A0 For example its not clear to me what is required in the cas=
e
> given is section 3.2.
clarify by indicate which AE is mandate and which AE will be optional

>
> 3. Section 4.2, extensions
>
> Shouldn't the AE be required for GNAM?
updated

>
> 4. Security considerations Section 8
>
> It also wasn't quite clear to me when the AE is optional and mandatory.
Updated in Message sections.

>
>
> 5. Section 8.1
>
> There are several places in the document where different replay
> mechanisms are alluded to, included this section. =A0This section states
> that nodes must agree on the mechanism used. =A0However there appears to
> be no way to signal what mechanism is in use. =A0Is this assumed to be
> pre-configured in each node, or is there another mechanism for this? =A0I=
s
> this realistic for deployments?
signal will be mobility security assocation as defined by the
mobility security association between them, and SPI value
in the authorization-enabling extension

>
> 6. Section 8.1.1
>
> NTP RFC 1305 needs to be included in the normative references.
yes

>
> Why is it important "those bits which are not available from a time
> source SHOULD be generated from a good source of randomness" ? (it seems
> that you don't really want bits to be random since you want to enforce
> ordering)
remove this

>
> This section also talks very briefly about clock synchronization. =A0It
> seems there could be security implications here. =A0One node may be able
> to poison a clock to an in appropriate value. =A0There probably should be
> more discussion here.
if poison, will discard it

>
> 7. Section 8.2
>
> This section makes a statement but does not describe how impacts the
> security of the system. =A0Since authentication is not performed can you
> use the extension defined in the document in this case? =A0What is the
> effect of the lack of authentication.
added.

thanks again.
Best regards,

-Hui
>

From ananth@cisco.com  Tue Sep  8 10:02:37 2009
Return-Path: <ananth@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4CF28C2A7; Tue,  8 Sep 2009 10:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaGKRm-67pvC; Tue,  8 Sep 2009 10:02:36 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C4D4A3A685C; Tue,  8 Sep 2009 10:02:36 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAJwrpkqrR7MV/2dsb2JhbADHGYhDASoIjzQFgkAIgVA
X-IronPort-AV: E=Sophos;i="4.44,353,1249257600"; d="scan'208";a="238801537"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 17:03:06 +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 n88H35jU013362;  Tue, 8 Sep 2009 10:03:05 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n88H35P3026812; Tue, 8 Sep 2009 17:03:05 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 8 Sep 2009 10:03:05 -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
Date: Tue, 8 Sep 2009 10:03:04 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5807F849AE@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <39808C30-0418-4B70-ABE3-124354C09FBE@nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-tcpm-tcpsecure
Thread-Index: Acowo1FQ+ORSKbETR9i2FLadBL9qugAAd0aQ
References: <Pine.WNT.4.64.0906080948290.6048@SANDYM-LT.columbia.ads.sparta.com> <03C04ACE-5773-4260-AABD-E799E614C469@nokia.com> <E63E6749-FD14-4F50-8351-0F1A48B50EB7@nokia.com> <0C53DCFB700D144284A584F54711EC5807CEEA50@xmb-sjc-21c.amer.cisco.com> <39808C30-0418-4B70-ABE3-124354C09FBE@nokia.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Lars Eggert" <lars.eggert@nokia.com>
X-OriginalArrivalTime: 08 Sep 2009 17:03:05.0784 (UTC) FILETIME=[3BB40B80:01CA30A6]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1089; t=1252429385; x=1253293385; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20draft-ietf-tcpm-tcpsecure |Sender:=20; bh=5oCvEGLbnA4E6I+6Br0ddWENsl++pJ3TPMqFNBOvjiw=; b=Qyxwuibv+ZUmsXLTiAHj2XXJ/BhQqYbEhgBsIwi8W2HMRDXgrRHSO5z35H vmIfvG7pi9MF+OlaC1rqrnU4esZWA6qX4yfItYLWqEzRH621bCHt1JUkrh4D I0pddVimY0ZQdyaKBciBB0sLk69dNaMIh9Ce1ZApoCIPHw9Cmahk8=;
Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: secdir@ietf.org, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, IESG IESG <iesg@ietf.org>
Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 17:02:37 -0000

Lars,

I have incorporated most of the comments and will check again to see if
I have left out anything. Actually after I am done with all the last
call comments, I'll send an email (esp copy the folks who had comments)
to see if I have addressed all of them, then will hit the submit button.

I am hoping to get this done by end of this week latest (earlier if
possible) Hope that is fine.

Thanks,
-Anantha=20

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com]=20
> Sent: Tuesday, September 08, 2009 9:42 AM
> To: Anantha Ramaiah (ananth)
> Cc: Sandra Murphy; Mitesh Dalal (mdalal); IESG IESG; secdir@ietf.org
> Subject: Re: draft-ietf-tcpm-tcpsecure
>=20
> Hi, authors,
>=20
> please prepare and submit a revision based on the feedback=20
> you have received until now. We need to move forward with=20
> this document.
>=20
> Sandy hasn't responded since June 8. Take the initial=20
> feedback you have gotten from her into account, but I think=20
> it is unreasonable to wait longer for any additional feedback.
>=20
> Lars

From Fred.L.Templin@boeing.com  Tue Sep  8 10:36:46 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED56528C0CF; Tue,  8 Sep 2009 10:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.642
X-Spam-Level: 
X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=0.357,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix+m5T30AosZ; Tue,  8 Sep 2009 10:36:41 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 07ECF3A683C; Tue,  8 Sep 2009 10:36:40 -0700 (PDT)
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
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" <Fred.L.Templin@boeing.com>
To: "Gabi Nakibly" <gnakibly@yahoo.com>, "Christian Huitema" <huitema@microsoft.com>, "v6ops" <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 08 Sep 2009 17:37:04.0108 (UTC) FILETIME=[FAA39AC0:01CA30AA]
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 17:36:47 -0000

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:<my_IPv4_address>". In pseudo-code:

  isatap_rcv() {
    ...
    if (v6dst =3D=3D "foreign_prefix::0200:5efe:<my_IPv4_addr>")
      drop_pkt();
    ...
  }

  isatap_xmt() {
    ...
    if (v6src =3D=3D "foreign_prefix::0200:5efe:<my_IPv4_addr>")
      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 <huitema@microsoft.com>
> > To: "Templin, Fred L" <Fred.L.Templin@boeing.com>; Gabi Nakibly =
<gnakibly@yahoo.com>; v6ops
> <v6ops@ops.ietf.org>
> > Cc: "ipv6@ietf.org" <ipv6@ietf.org>; "secdir@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 tlyu@MIT.EDU  Tue Sep  8 17:46:25 2009
Return-Path: <tlyu@MIT.EDU>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1F93A6B51; Tue,  8 Sep 2009 17:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.364,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBkzSwDe7bs2; Tue,  8 Sep 2009 17:46:24 -0700 (PDT)
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 3C7F53A6B4F; Tue,  8 Sep 2009 17:46:23 -0700 (PDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n890kiRj005230; Tue, 8 Sep 2009 20:46:48 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n890kgsW010460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Sep 2009 20:46:43 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n890kgGs002993; Tue, 8 Sep 2009 20:46:42 -0400 (EDT)
To: secdir@ietf.org
References: <ldvtz0cy2a8.fsf@cathode-dark-space.mit.edu>
From: Tom Yu <tlyu@MIT.EDU>
Date: Tue, 08 Sep 2009 20:46:42 -0400
In-Reply-To: <ldvtz0cy2a8.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of "Wed, 12 Aug 2009 20:40:15 -0400")
Message-ID: <ldvy6opc5cd.fsf@cathode-dark-space.mit.edu>
Lines: 54
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Cc: kchowdhury@starentnetworks.com, dime-chairs@tools.ietf.org, julien.bournelle@orange-ftgroup.com, meyer@umic.rwth-aachen.de, iesg@ietf.org, jouni@gmail.com, amuhanna@nortel.com
Subject: [secdir] secdir re-review of draft-ietf-dime-pmip6-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2009 00:46:25 -0000

This is a re-review of this document.  The document incorporates some
of my suggestions from the previous round.

Tom Yu <tlyu@MIT.EDU> writes:

> The Security Considerations section states:
>
>    The security considerations of the Diameter Base protocol [RFC3588],
>    Diameter EAP application [RFC4072], Diameter NASREQ application
>    [RFC4005] and Diameter Mobile IPv6 integrated scenario bootstrapping
>    [RFC5447] are applicable to this document.
>
> Should a reference to RFC 4832 (Security Threats to NETLMM) be
> included here?  There appear to be no obvious additional security
> considerations beyond those mentioned in the above documents. (if
> including the suggested additional citation)

There has been no change in this area.  Do the authors feel that the
additional reference to "Security Threats to NETLMM" is not necessary?

>    In general, the Diameter messages may be transported between the HA
>    and the Diameter server via one or more AAA brokers or Diameter
>    agents.  In this case the HA to the Diameter server AAA communication
>    rely on the security properties of the intermediate AAA brokers and
>    Diameter agents (such as proxies).
>
> "HA" as used above is not defined in the document, and is used nowhere
> else in the document.  Is it a Home Agent?  (which is not really
> otherwise mentioned in this document)

This is also unchanged.  It would be useful to clarify if the HA is a
Home Agent, Home AAA Server, etc.

> Editorial:
>
> "DER" and "DEA" are not defined.  I am fairly sure that "DER" does not
> mean "Distinguished Encoding Rules" in this document.

This has not been fixed.  After further investigation, it seems that
these mean "Diameter EAP Request" and "Diameter EAP Answer" as defined
in RFC 4072.  Although the acronyms are defined in a normative
reference, and may be obvious to readers already knowledgeable about
the subject, please consider expanding them in this document at least
once.

> The caption for Figure 4 crosses a page break, making it appear
> truncated.

This appears to have been fixed.

> draft-ietf-netlmm-pmip6-ipv4-support is now on revision #14, but is
> cited as "-11".

This appears to have been fixed.

From dromasca@avaya.com  Wed Sep  9 03:14:05 2009
Return-Path: <dromasca@avaya.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEBB83A67D3; Wed,  9 Sep 2009 03:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level: 
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPLTPshpiSu8; Wed,  9 Sep 2009 03:14:05 -0700 (PDT)
Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id B92803A676A; Wed,  9 Sep 2009 03:14:04 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,357,1249272000"; d="scan'208";a="172771812"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 09 Sep 2009 06:14:36 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Sep 2009 06:14:34 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 9 Sep 2009 12:14:23 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401A0BEF1@307622ANEX5.global.avaya.com>
In-Reply-To: <ldvy6opc5cd.fsf@cathode-dark-space.mit.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secdir re-review of draft-ietf-dime-pmip6-03
thread-index: Acow5wu4eCFPZDJkQNyN6AHXJqcOcQATnvPQ
References: <ldvtz0cy2a8.fsf@cathode-dark-space.mit.edu> <ldvy6opc5cd.fsf@cathode-dark-space.mit.edu>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Tom Yu" <tlyu@MIT.EDU>, <secdir@ietf.org>
Cc: kchowdhury@starentnetworks.com, dime-chairs@tools.ietf.org, julien.bournelle@orange-ftgroup.com, meyer@umic.rwth-aachen.de, iesg@ietf.org, jouni@gmail.com, amuhanna@nortel.com
Subject: Re: [secdir] secdir re-review of draft-ietf-dime-pmip6-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2009 10:14:06 -0000

Will the authors respond to the issues raised by Tom and not addressed
in the revised I-D, please.=20

Thanks and Regards,

Dan
=20

> -----Original Message-----
> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20
> Behalf Of Tom Yu
> Sent: Wednesday, September 09, 2009 3:47 AM
> To: secdir@ietf.org
> Cc: kchowdhury@starentnetworks.com;=20
> dime-chairs@tools.ietf.org;=20
> julien.bournelle@orange-ftgroup.com;=20
> meyer@umic.rwth-aachen.de; iesg@ietf.org; jouni@gmail.com;=20
> amuhanna@nortel.com
> Subject: secdir re-review of draft-ietf-dime-pmip6-03
>=20
> This is a re-review of this document.  The document=20
> incorporates some of my suggestions from the previous round.
>=20
> Tom Yu <tlyu@MIT.EDU> writes:
>=20
> > The Security Considerations section states:
> >
> >    The security considerations of the Diameter Base=20
> protocol [RFC3588],
> >    Diameter EAP application [RFC4072], Diameter NASREQ application
> >    [RFC4005] and Diameter Mobile IPv6 integrated scenario=20
> bootstrapping
> >    [RFC5447] are applicable to this document.
> >
> > Should a reference to RFC 4832 (Security Threats to NETLMM) be=20
> > included here?  There appear to be no obvious additional security=20
> > considerations beyond those mentioned in the above documents. (if=20
> > including the suggested additional citation)
>=20
> There has been no change in this area.  Do the authors feel=20
> that the additional reference to "Security Threats to NETLMM"=20
> is not necessary?
>=20
> >    In general, the Diameter messages may be transported=20
> between the HA
> >    and the Diameter server via one or more AAA brokers or Diameter
> >    agents.  In this case the HA to the Diameter server AAA=20
> communication
> >    rely on the security properties of the intermediate AAA=20
> brokers and
> >    Diameter agents (such as proxies).
> >
> > "HA" as used above is not defined in the document, and is=20
> used nowhere=20
> > else in the document.  Is it a Home Agent?  (which is not really=20
> > otherwise mentioned in this document)
>=20
> This is also unchanged.  It would be useful to clarify if the=20
> HA is a Home Agent, Home AAA Server, etc.
>=20
> > Editorial:
> >
> > "DER" and "DEA" are not defined.  I am fairly sure that=20
> "DER" does not=20
> > mean "Distinguished Encoding Rules" in this document.
>=20
> This has not been fixed.  After further investigation, it=20
> seems that these mean "Diameter EAP Request" and "Diameter=20
> EAP Answer" as defined in RFC 4072.  Although the acronyms=20
> are defined in a normative reference, and may be obvious to=20
> readers already knowledgeable about the subject, please=20
> consider expanding them in this document at least once.
>=20
> > The caption for Figure 4 crosses a page break, making it appear=20
> > truncated.
>=20
> This appears to have been fixed.
>=20
> > draft-ietf-netlmm-pmip6-ipv4-support is now on revision #14, but is=20
> > cited as "-11".
>=20
> This appears to have been fixed.
>=20

From vincent.roca@inrialpes.fr  Wed Sep  9 06:44:14 2009
Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362FF28C14F; Wed,  9 Sep 2009 06:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6j0hPYtP-6Q; Wed,  9 Sep 2009 06:44:12 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id BE87E3A69CF; Wed,  9 Sep 2009 06:44:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,358,1249250400"; d="scan'208";a="32463740"
Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Sep 2009 15:44:31 +0200
Message-ID: <4AA7B13F.1090007@inrialpes.fr>
Date: Wed, 09 Sep 2009 15:44:31 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Yaron Sheffer <yaronf@checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8012953655E08@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8012953655E08@il-ex01.ad.checkpoint.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset=windows-1255
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Thu, 10 Sep 2009 00:20:49 -0700
Cc: "msec-chairs@tools.ietf.org" <msec-chairs@tools.ietf.org>, "draft-ietf-msec-tesla-for-alc-norm@tools.ietf.org" <draft-ietf-msec-tesla-for-alc-norm@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-msec-tesla-for-alc-norm-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2009 13:44:14 -0000

Dear Yaron,

Thanks a lot for your detailed review and comments. Please, find below
our answers and explanations on how we addressed them.


> General
>
> Overall this is a good document, but I suspect that it has too many options
> and leaves too many things open as to be truly interoperable. So
> Experimental is the right designation. From a security point of view, things
> seem to be well covered, but see my two comments below.

We agree there are too many options.  This is one of our concerns
and beyond interoperability, complexity is also a source of security
concerns.

To address this, at least partially, we have removed the four
compact authentication tags, i.e. the compact formats where the
32-bit "i" interval index is not provided and is "replaced" by 1
or 3 of the least significant bytes with the i_LSB/i_NSB fields
(section 3.4.7. "Format of the Compact Authentication Tags").

Doing so significantly simplifies the proposal:
- there are only 4 different authentication tags instead of 8,
- the "i" computation logic through the i_LSB/i_NSB fields in
  section 4.3 is removed,
- the whole section 4.3.1. "Wrong Guess of the i Parameter" is
  removed too.
It does not fundamentally change the protocol, and the main drawback
is a mandatory 32-bit overhead (the "i" field) in each authentication
tag. That's an acceptable price to pay IOHO. The second drawback is
a renumbering of the "Type" field (section 5.1) but we believe it's
still acceptable given the "work in progress" status of the document.

Historically, when we proposed the compact versions, HMAC-SHA1 was
the default and we felt it was interesting to replace the 3 reserved/
padding bytes by 3 bytes of "i". Now that HMAC-SHA255 is the default
(and HMAC-SHA1 non recommended), i_NSB can no longer be used, only
i_LSB (1 byte). So it's in any case less attractive.


> Security Issues
>
> 4.2.2.2: it is far from clear that if I trust you to send me packets (a
> movie, say), I also trust you to configure my NTP client (list of servers
> and trust anchors for them). So I wonder if using one of the offered NTP
> servers should really be MUST. Or are we really expecting a separate
> application level NTP layer, on top of that maintained by the OS?

You're right, the wording is not appropriate. We clarified this section
by adding the following paragraph, at the end of 4.2.2.2:
---
Note that this scenario assumes that each client trusts the sender and accepts to
align its NTP configuration to that of the sender, using one of the NTP server(s)
suggested. If this assumption does not hold, the client MUST NOT use the NTP indirect
time synchronization method (Section 2.3.2.).
---

Section 2.3.2 specifies that some of the indirect synchronization methods
require that the clients trust the sender sufficiently:
---
It should be noted that the NTP/SNTP schemes assume that each client trusts
the sender and accepts to align its NTP/SNTP configuration to that of the
sender. If this assumption does not hold, the sender SHOULD offer an
alternative solution.
---

However, we think that "using one of the offered NTP server"
is a MUST for TESLA to remain secure. If the two NTP hierarchies
are totally disjoint, I don't see how secure time synchronization
could be achieved.


> 6. The Security Considerations have no discussion at all of the security of
> the back channel. I understand that such a channel does exist, at least for
> NORM. This channel remains unprotected (or its protection remains
> unspecified, see Sec. 1.1). Can it be used to DOS the sender? Other
> receivers? Are additional attacks possible?

You're right. We added a new section to discuss the security of the
back channel (section 6.3). We also added an informative reference to
a companion document, draft-ietf-rmt-simple-auth-for-alc-norm-01,
that expicits the use of such simple schemes as RSA/ECC digital signature
and/or group MAC in the context of ALC/NORM, using the same EXT_AUTH
header extension mechanisms.
http://tools.ietf.org/html/draft-ietf-rmt-simple-auth-for-alc-norm-01
(this document will soon enter RMT WGLC).
Section 1.1. "Scope of this Document" has also been improved in order
to better introduce these possibilities.


> Other Comments
>
> 2.2: leaving the bootstrapping step implementation-dependent means that the
> protocol is non-interoperable.

This is right. We added a sentence to say that it is RECOMMENDED that TESLA
implementations support bootstrap messages. However, we don't want to make
its support mandatory since there are use-cases where out-of-band is prefered
(see RFC4442).


> 3.1.2.2: this section implies (last paragraph) that the use of periodic
> bootstrap information is only applicable for the case where direct time
> synchronization is used. Is this required by the TESLA protocol?

Good catch, thanks. This is indeed an error and anyway it contradicts
section 3.2.1. New text is as follows:

   The only solution for this
   receiver to catch up consists in receiving an additional bootstrap
   information message.  This can happen by waiting for the next
   periodic transmission (if sent in-band) or through an external
   mechanism (Section 3.2.1).


> 3.4.3: the description of the “Disclosed Key” field says it must be 0 in the
> first d intervals, which contradicts the last paragraph of the section,
> where it is forbidden to use this tag in those intervals.

We read the whole document several times, and this error slipped through.
Of course, the "set to 0" requirement comes from the time there was no
auth tag without key disclosure. Thanks.


> 3.4.7 (and elsewhere): I wonder about the design choice of making the length
> of the NSB (and hence, the explicit part of the interval index) depend on
> the size of the truncated MAC. The considerations for selecting one are
> primarily security-related, while for the other they are primarily about
> bandwidth and reliability. Why make them dependent?

We removed i_LSB/i_NSB altogether in the new version, for the sake of
simplicity (see our answer to the "General comment"). This comment does
not apply now.


> 4.1: the text “verify the Group MAC if present” is misleading (an attacker
> might remove it from the packet). It should be “if the G bit is set in the
> Bootstrap message”.

This is right, the wording is misleading. Corrected. New text is as follows:
---
   o  first of all, if the Group MAC is present and if the session uses
      this feature (e.g., if the G bit is set in the bootstrap
      information message), then verify the Group MAC.  A packet that
      does not contain a Group MAC tag whereas the session uses this
      feature MUST be immediately dropped.  On the opposite, if a packet
      contains a Group MAC tag whereas the session does not use this
      feature, this tag MUST be ignored;
---
Similarly we updated step 3 of section 4.3.


> 4.3, step 5: when doing congestion control, isn’t there value in keeping
> key-disclosure packets, even when other packets are dropped? The effect of
> key-disclosure packets being dropped may be dozens of other packets that are
> lost.

There is a misunderstanding here. By "the receiver performs
congestion control", one must understand that the sequence number
information contained in this packet is used by the congestion control
building block to detect possible packet losses. This happen even if
the packet is not authenticated at this step.
If the packet discloses a key, this key will be eventually used once
the packet is authenticated.
The text is clarified to better reflect this (and the DoS attack example
corrected).
---
   5.  When applicable, the receiver performs any congestion control
       related action (i.e., the ALC or NORM headers are used by the
       associated congestion control building block, if any), even if
       the packet has not yet been authenticated [RMT-BB-LCT].  If this
       feature leads to a potential DoS attack (the attacker can send a
       faked packet with a wrong sequence number to simulate packet
       losses), it does not compromise the security features offered by
       TESLA and enables a rapid reaction in front of actual congestion
       problems.
---


> 4.3: I find this text self-contradictory: “In this specification, a receiver
> using TESLA MUST immediately drop unsafe packets.  But the receiver MAY also
> decide, at any time, to continue an ALC or NORM session in unsafe mode,
> ignoring TESLA extensions.” I would have felt somewhat better about it if
> the text said something like “there SHOULD be explicit user action to move
> to unsafe (insecure) mode”.

Corrected as suggested, especially as it was the idea.


Thanks a lot for your valuable comments, and sorry for this
late answer.


    Vincent and Aurelien.


nb: I'll submit the new I-D later today.

From AMUHANNA@nortel.com  Wed Sep  9 07:37:23 2009
Return-Path: <AMUHANNA@nortel.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56123A6847; Wed,  9 Sep 2009 07:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.62
X-Spam-Level: 
X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9yji7sgxiey; Wed,  9 Sep 2009 07:37:23 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9C6D53A67D3; Wed,  9 Sep 2009 07:37:22 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n89Ebl301841; Wed, 9 Sep 2009 14:37:47 GMT
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
Date: Wed, 9 Sep 2009 09:37:44 -0500
Message-ID: <C5A96676FCD00745B64AE42D5FCC9B6E202BBF02@zrc2hxm0.corp.nortel.com>
In-Reply-To: <ldvy6opc5cd.fsf@cathode-dark-space.mit.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secdir re-review of draft-ietf-dime-pmip6-03
Thread-Index: Acow5wkxkv3FWtimQJu1mr2OGcdP0AAc1IZg
References: <ldvtz0cy2a8.fsf@cathode-dark-space.mit.edu> <ldvy6opc5cd.fsf@cathode-dark-space.mit.edu>
From: "Ahmad Muhanna" <amuhanna@nortel.com>
To: "Tom Yu" <tlyu@MIT.EDU>, <secdir@ietf.org>
X-Mailman-Approved-At: Thu, 10 Sep 2009 00:20:49 -0700
Cc: kchowdhury@starentnetworks.com, dime-chairs@tools.ietf.org, jouni korhonen <jouni.nospam@gmail.com>, julien.bournelle@orange-ftgroup.com, meyer@umic.rwth-aachen.de, iesg@ietf.org
Subject: Re: [secdir] secdir re-review of draft-ietf-dime-pmip6-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2009 14:37:23 -0000

Hi Tom,
Sorry for the delay. It seems that Jouni's wrong email was copied. I
copied the correct one and he can add if necessary. Please see response
inline.

Regards,
Ahmad
=20

> -----Original Message-----
> From: Tom Yu [mailto:tlyu@MIT.EDU]=20
> Sent: Tuesday, September 08, 2009 7:47 PM
> To: secdir@ietf.org
> Cc: iesg@ietf.org; dime-chairs@tools.ietf.org;=20
> jouni@gmail.com; julien.bournelle@orange-ftgroup.com;=20
> kchowdhury@starentnetworks.com; Muhanna, Ahmad (RICH1:2H10);=20
> meyer@umic.rwth-aachen.de
> Subject: secdir re-review of draft-ietf-dime-pmip6-03
>=20
> This is a re-review of this document.  The document=20
> incorporates some of my suggestions from the previous round.
>=20
> Tom Yu <tlyu@MIT.EDU> writes:
>=20
> > The Security Considerations section states:
> >
> >    The security considerations of the Diameter Base=20
> protocol [RFC3588],
> >    Diameter EAP application [RFC4072], Diameter NASREQ application
> >    [RFC4005] and Diameter Mobile IPv6 integrated scenario=20
> bootstrapping
> >    [RFC5447] are applicable to this document.
> >
> > Should a reference to RFC 4832 (Security Threats to NETLMM) be=20
> > included here?  There appear to be no obvious additional security=20
> > considerations beyond those mentioned in the above documents. (if=20
> > including the suggested additional citation)
>=20
> There has been no change in this area.  Do the authors feel=20
> that the additional reference to "Security Threats to NETLMM"=20
> is not necessary?

[Ahmad]
This draft does not add any new functionality to the MAG-LMA interface,
i.e., Proxy MIPv6 protocol. It only defines the interfaces MAG-HAAA and
LMA-HAAA. Thus, I am not sure referencing RFC4832 is relevant here.

>=20
> >    In general, the Diameter messages may be transported=20
> between the HA
> >    and the Diameter server via one or more AAA brokers or Diameter
> >    agents.  In this case the HA to the Diameter server AAA=20
> communication
> >    rely on the security properties of the intermediate AAA=20
> brokers and
> >    Diameter agents (such as proxies).
> >
> > "HA" as used above is not defined in the document, and is=20
> used nowhere=20
> > else in the document.  Is it a Home Agent?  (which is not really=20
> > otherwise mentioned in this document)
>=20
> This is also unchanged.  It would be useful to clarify if the=20
> HA is a Home Agent, Home AAA Server, etc.
[Ahmad]
Sure, it is. Will clarify it.

>=20
> > Editorial:
> >
> > "DER" and "DEA" are not defined.  I am fairly sure that=20
> "DER" does not=20
> > mean "Distinguished Encoding Rules" in this document.
>=20
> This has not been fixed.  After further investigation, it=20
> seems that these mean "Diameter EAP Request" and "Diameter=20
> EAP Answer" as defined in RFC 4072.  Although the acronyms=20
> are defined in a normative reference, and may be obvious to=20
> readers already knowledgeable about the subject, please=20
> consider expanding them in this document at least once.
[Ahmad]
No problem here too.

>=20
> > The caption for Figure 4 crosses a page break, making it appear=20
> > truncated.
>=20
> This appears to have been fixed.
>=20
> > draft-ietf-netlmm-pmip6-ipv4-support is now on revision #14, but is=20
> > cited as "-11".
>=20
> This appears to have been fixed.
>=20

From weiler+ietf@watson.org  Fri Sep 11 06:56:24 2009
Return-Path: <weiler+ietf@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2AF53A6899 for <secdir@core3.amsl.com>; Fri, 11 Sep 2009 06:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDV7p2q90dVl for <secdir@core3.amsl.com>; Fri, 11 Sep 2009 06:56:23 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 0910B3A6A46 for <secdir@ietf.org>; Fri, 11 Sep 2009 06:56:22 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n8BDuow4031569 for <secdir@ietf.org>; Fri, 11 Sep 2009 09:56:50 -0400 (EDT) (envelope-from weiler+ietf@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n8BDuowD031566 for <secdir@ietf.org>; Fri, 11 Sep 2009 09:56:50 -0400 (EDT) (envelope-from weiler+ietf@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 11 Sep 2009 09:56:50 -0400 (EDT)
From: Samuel Weiler <weiler+ietf@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.0909101523400.54991@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Fri, 11 Sep 2009 09:56:50 -0400 (EDT)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2009 13:56:24 -0000

Richard Barnes is next in the rotation.

Please try to complete last call reviews by the end of the last call. 
For documents on telechat, note that the deadline field shown below 
reflects the telechat date, even though last call likely expires (or 
expired) before then.

Review instructions and related resources are at:
       http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam


For telechat 2009-09-24

Reviewer                 Deadline   Draft
Derek Atkins           TR2009-09-22 draft-ietf-roll-building-routing-reqs-06
Julien Laganier        T 2009-09-22 draft-ietf-sip-certs-09
Kurt Zeilenga          T 2009-09-22 draft-ietf-dnsext-dnssec-rsasha256-14

Last calls and special requests:

Reviewer                 Deadline   Draft
Derek Atkins             2009-09-17 draft-ietf-rohc-ipsec-extensions-hcoipsec-05
Rob Austein              2009-10-07 draft-reschke-rfc2731bis-02
Alan DeKok               2009-08-17 draft-turner-deviceowner-attribute-01
Shawn Emery              2009-08-04 draft-ietf-alto-problem-statement-02
Phillip Hallam-Baker     2009-08-18 draft-ietf-pmol-sip-perf-metrics-04
Steve Hanna              2009-08-14 draft-ietf-krb-wg-cross-problem-statement-04
Love Hornquist-Astrand   2009-03-31 draft-ietf-ipfix-mib-07
Love Hornquist-Astrand   2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05
Julien Laganier          2009-06-09 draft-ietf-enum-3761bis-04
Catherine Meadows        2008-01-17 draft-ietf-speechsc-mrcpv2-20
Sandy Murphy             2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-14
Sandy Murphy             2009-09-04 draft-ietf-rtgwg-ipfrr-framework-11
Vidya Narayanan          2008-11-21 draft-ietf-sip-saml-06
Chris Newman             2009-09-04 draft-ietf-mboned-lightweight-igmpv3-mldv2-05
Eric Rescorla            2009-09-07 draft-ietf-tls-rfc4366-bis-05
Joe Salowey              2009-02-08 draft-ietf-geopriv-lis-discovery-11
Stefan Santesson         2009-09-08 draft-ietf-l3vpn-2547bis-mcast-bgp-07
Juergen Schoenwaelder    2009-09-08 draft-ietf-l3vpn-2547bis-mcast-08
Yaron Sheffer            2009-09-14 draft-ietf-calsify-2446bis-09
Hannes Tschofenig        2009-04-23 draft-ietf-pce-monitoring-05
Hannes Tschofenig        2009-07-25 draft-ietf-pkix-ta-format-03
Hannes Tschofenig        2009-10-07 draft-carpenter-renum-needs-work-03
Tina TSOU                2009-09-15 draft-ietf-syslog-sign-27
Sean Turner              2009-09-14 draft-ietf-ipsecme-ikev2-resumption-07
Carl Wallace             2009-09-22 draft-ietf-dime-diameter-cmd-iana-01
Sam Weiler               2008-08-13 draft-chown-v6ops-rogue-ra-03
Sam Weiler               2009-09-23 draft-ietf-eai-downgraded-display-02
Brian Weis               2009-09-22 draft-ietf-mipshop-pfmipv6-09
Nico Williams            2008-08-13 draft-ietf-v6ops-ra-guard-03
Nico Williams            2009-09-22 draft-ietf-nfsv4-federated-fs-reqts-03
Tom Yu                   2009-09-22 draft-ietf-rmt-pi-alc-revised-08
Larry Zhu                2008-08-13 draft-thaler-v6ops-teredo-extensions-04
Larry Zhu                2009-05-09 draft-ietf-ecrit-location-hiding-req-02
Larry Zhu                2009-09-17 draft-ietf-rohc-hcoipsec-11
Glen Zorn                2009-09-17 draft-ietf-rohc-ikev2-extensions-hcoipsec-09




From gnakibly@yahoo.com  Fri Sep 11 12:58:02 2009
Return-Path: <gnakibly@yahoo.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9B428C12B for <secdir@core3.amsl.com>; Fri, 11 Sep 2009 12:58:02 -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=[AWL=0.415,  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 MWa3PYGGDXg6 for <secdir@core3.amsl.com>; Fri, 11 Sep 2009 12:57:58 -0700 (PDT)
Received: from web45513.mail.sp1.yahoo.com (web45513.mail.sp1.yahoo.com [68.180.197.161]) by core3.amsl.com (Postfix) with SMTP id C0A4528C127 for <secdir@ietf.org>; Fri, 11 Sep 2009 12:57:58 -0700 (PDT)
Received: (qmail 21799 invoked by uid 60001); 11 Sep 2009 19:58:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252699115; bh=Rp50sF8vWhlTxFfz42TXbar5Fx+5ho5W2U7wTqISTUA=; 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=yO0kv152b25d/XNN1EQA/4WZXkfgNj9Ol9AtrX+xChpNp2Y0TgwwsMSQROqyYWrrTznDlWpBsDerNUULtqqD9gpgL4/Nq40hwHjGZKUI5dCfyzStpdd0W0n/rxe9Kulj8eQ1CGHmaup7B+xi0l3cyqM6sA0Fa2dqL5k0LTm0oW0=
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=181jso2+ayHEZd0pMyJt6p2ynu8r2iPcjtdaxoiFNGgEu7VT/XtJc9rzzfj71TdnsoLhCZdRqrYam7Ncnbo7rVEeV3ZwLRKY7hSB3N2nMJXD9dhOzZfDjnXY+bTvtQL7hscOp8IikAuw5kSlWMkqvDk9Ezo5ryb8ez62T0oTZK0=;
Message-ID: <309242.20809.qm@web45513.mail.sp1.yahoo.com>
X-YMail-OSG: .LdW.OcVM1lQkCwce97nr.zdXJjI6nTB7_StXZs9x6JSEJjeR8nXoOf0O1QlWaoDvN_tPwta12vyCnPC291u1K8fSiaayki7VldlCLu1tEfiMm3H5iKIO_.jIhbx7AVVJFIwaQX0r12AvmIw7qwnPwDv60O0BsNga8y.N7pyT.8AOq6OPWFCVwDSyDr3qfk_FjdjupjshYZaM7Xm.iFGrLsY7cRTMjtDJVHowMe3VWyXJFkbpapczckNe5DyiurtQdf1sXKS
Received: from [89.138.115.145] by web45513.mail.sp1.yahoo.com via HTTP; Fri, 11 Sep 2009 12:58:35 PDT
X-Mailer: YahooMailRC/157.18 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> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com>
Date: Fri, 11 Sep 2009 12:58:35 -0700 (PDT)
From: Gabi Nakibly <gnakibly@yahoo.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Christian Huitema <huitema@microsoft.com>, v6ops <v6ops@ops.ietf.org>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2009 19:58:02 -0000

Hi Fred,=0ASee below.=0A=0AGabi=0A=0A=0A=0A----- Original Message ----=0A> =
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>=0A> To: Gabi Nakibly <g=
nakibly@yahoo.com>; Christian Huitema <huitema@microsoft.com>; v6ops <v6ops=
@ops.ietf.org>=0A> Cc: ipv6@ietf.org; secdir@ietf.org=0A> Sent: Tuesday, Se=
ptember 8, 2009 8:37:03 PM=0A> Subject: RE: Routing loop attacks using IPv6=
 tunnels=0A> =0A> Gabi and Christian,=0A> =0A> Focusing only on attack #3 (=
i.e., leaving out attack #1=0A> and #2 6to4 interactions for the moment), p=
lease check=0A> the following summary of proposed mitigations:=0A> =0A> 1) =
For ISATAP/VET routers that have assurance that their=0A> neighbor cache is=
 coherent, the router can make a simple=0A> check in the neighbor cache to =
determine 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 nei=
ghbor) && (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 ((v=
6dst 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 n=
ecessary to bootstrap=0A> neighbor discovery on the ISATAP link.)=0A> =0A> =
Does anyone see a problem with this?=0A> =0ALooks fine. =0A=0A> 2) For ISAT=
AP/VET routers that use public IPv4 addresses=0A> and that do not have assu=
rance that their neighbor cache=0A> is coherent, the router can check for t=
he 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:=
<my_IPv4_addr>")=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 "forei=
gn_prefix::0200:5efe:<my_IPv4_addr>")=0A> =A0 =A0 =A0 drop_pkt();=0A> =A0 =
=A0 ...=0A> =A0 }=0A> =0A> Does anyone see a problem with this?=0A=A0=0ALoo=
ks fine.=0A=A0=0A> =0A> 3) For ISATAP/VET routers that use private IPv4 add=
resses=0A> and that do not have assurance that their neighbor cache=0A> is =
coherent, the router can make the checks that Christian=0A> has proposed. B=
ut, will we see any of these case 3)=0A> situations in operational practice=
?=0A> =0A=A0=0AI can not tell for sure. Why this case seems to you less pla=
usible than case 2?=0A=0A> I would also like to point out that the attack v=
ectors 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 already specifie=
d in VET.=0A> =0A> Comments?=0A> =0A> Fred=0A> fred.l.templin@boeing.com=0A=
> =0A> =0A> > -----Original Message-----=0A> > From: Gabi Nakibly [mailto:g=
nakibly@yahoo.com]=0A> > Sent: Tuesday, September 08, 2009 5:28 AM=0A> > To=
: Christian Huitema; Templin, Fred L; v6ops=0A> > Cc: ipv6@ietf.org; secdir=
@ietf.org=0A> > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > =
=0A> > Hi Christian,=0A> > Thanks for your comments.=0A> > =0A> > =0A> > Th=
e checks=A0you suggested are powerful and will indeed mitigate the attacks.=
 =0A> The only thing that=0A> > worries me is the fact that=A0usually AFAIK=
 the=A0ISATAP router is not configured =0A> with the IPv4 subnet=0A> > addr=
esses of the site. This means that the router must now be configured with =
=0A> this information and=0A> > reconfigured as this information changes. I=
f this is felt to be a reasonable =0A> administrative overhead,=0A> > then =
I think the checks should be employed.=0A> > =0A> > One minor thing that sh=
ould be noted is that these checks will not mitigate =0A> the attacks in ca=
se there=0A> > are two ISATAP links (with two separate routers)=A0in the sa=
me site. This =0A> means=A0that their sets of=0A> > registered subnets coin=
cide.=A0I assume that=A0such deployment are not common, =0A> although I do =
not have the=0A> > information to back this assumption.=0A> > =0A> > Gabi=
=0A> > =0A> > =0A> > ----- Original Message ----=0A> > > From: Christian Hu=
itema =0A> > > To: "Templin, Fred L" ; Gabi Nakibly =0A> ; v6ops=0A> > =0A>=
 > > Cc: "ipv6@ietf.org" ; "secdir@ietf.org" =0A> > > Sent: Friday, Septemb=
er 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 prot=
ect against these attacks, =0A> if=0A> > > the ISATAP router limits the ran=
ge of IPv4 addresses towards which it is =0A> willing=0A> > > to relay pack=
ets. That would fit many current deployments, maybe most.=0A> > >=0A> > > I=
n many current deployments, ISATAP is used to provide IPv6 connectivity =0A=
> inside=0A> > > a "site", typically protected by a firewall. The expected =
behavior is that =0A> hosts=0A> > > in that site will use direct ISATAP con=
nectivity to exchange packets with =0A> each=0A> > > other, and will use th=
e ISATAP router to exchange packets with other IPv6=0A> > > subnets.=0A> > =
>=0A> > > Assume 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 ISATAP sub=
net (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=A0=
source): 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=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 =0A> 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 =0A> subnets):=A0drop;=
=0A> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else if (IPv6 dest=
ination does not match ISATAP =0A> subnet):=A0drop;=0A> > > =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else if (embedded IPv4 address does not be=
long 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 that wa=
y, the ISATAP router cannot create a loop, because 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 N=
akibly; v6ops=0A> > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > Subject: R=
E: 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 n=
eeds to be a check on all of the IPv4 addresses assigned=0A> > > to the nod=
e's IPv4 interfaces, and with ISATAP there could be=0A> > > multiple underl=
ying IPv4 interfaces over which the ISATAP=0A> > > interface is configured.=
 So, that would seem like a potential=0A> > > performance issue if there we=
re 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> > > und=
erlying IPv4 interfaces with only a link-local address) then=0A> > > there =
is only one IPv4 address to check. The technique is called:=0A> > > "link-l=
ayer multiplexing" and is described for ISATAP/VET in=0A> > > Appendix B of=
 'draft-templin-intarea-vet'. But, the idea really=0A> > > came from Sectio=
n 3.3.4 of RFC1122.=0A> > >=0A> > > Thanks - Fred=0A> > > fred.l.templin@bo=
eing.com=0A> > >=0A> > > > -----Original 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:=
 "Templin, Fred L"=0A> > > > > To: Gabi Nakibly ; v6ops=0A> > > > > Cc: ipv=
6@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 Mess=
age-----=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 IPv6 tunnels=0A> > > > > >=0A> > =
> > > > Fred,=0A> > > > > >=0A> > > > > > I agree that the source address c=
heck discussed below should be made. =0A> 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_p=
kt(); /* attack #3 mitigation */=0A> > > > > >=A0 =A0 =A0 ...=0A> > > > > >=
=A0 }=0A> > > > >=0A> > > > > Having thought about it a bit, I agree but fo=
r ISATAP I see=0A> > > > > the source address check as a MAY and the destin=
ation address=0A> > > > > check as a SHOULD.=0A> > > >=0A> > > > Why do you=
 think so? As I see it, the two checks mitigate two different=0A> > > attac=
ks. The destination=0A> > > > address check defends the ISATAP router again=
st attacks of type 3 in which =0A> it=0A> > > acts as=0A> > > > the decapsu=
lator of the attack packet.=A0 While, the source address check=0A> > > defe=
nds the ISATAP=0A> > > > router against attacks of type 3 in which it acts =
as the ecapsulator of =0A> the=0A> > > attack packet.=A0 Either of=0A> > > =
> these checks are redundant if the other one is employed by the opposite =
=0A> router=0A> > > of the attack. So I do=0A> > > > not see why one of the=
m is a SHOULD and 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> > > > > gets depl=
oyed then the source address check is unnecessary=0A> > > > >=0A> > > >=0A>=
 > > > In principle, I agree with you. However, I am a believer of the "def=
ense =0A> in=0A> > > depth" 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 correc=
tly at all =0A> other=0A> > > routers then it may seem=0A> > > > 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> > > > > > ----- Original Message ----=
=0A> > > > > > > From: "Templin, Fred L"=0A> > > > > > > To: Gabi Nakibly ;=
 v6ops=0A> > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > S=
ent: Friday, August 28, 2009 11:23:40 PM=0A> > > > > > > Subject: RE: Routi=
ng 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> > > > > =
> > > 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 dis=
cussion up until now: the best =0A> mitigation=0A> > > > > of most of=0A> >=
 > > > > > these attacks is=0A> > > > > > > > indeed the proto-41 and ingre=
ss filtering on the border of the =0A> ISATAP=0A> > > > > site. If=0A> > > =
> > > > it is indeed=0A> > > > > > > > implemented. I assume that not all s=
ites deploy such filtering for=0A> > > lack of=0A> > > > > > > awareness or=
 since the=0A> > > > > > > > proto-41 filtering may break other tunnels the=
 site may employ.=0A> > > However, I=0A> > > > > do=0A> > > > > > > not hav=
e hard evidence=0A> > > > > > > > on this. I would be happy if others on th=
e list will refute or =0A> justify=0A> > > > > this=0A> > > > > > > assumpt=
ion.=0A> > > > > > > >=0A> > > > > > > > If this assumption is (even partia=
lly) correct than I think that =0A> 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 arou=
nd=0A> > > > > > > to your opinion.=0A> > > > > > >=0A> > > > > > > > Moreo=
ver, as I mention below the proo-41 filtering is not =0A> effective in=0A> =
> > > > case of=0A> > > > > > > attack=0A> > > > > > > > #3 and the attacke=
r is internal to the site.=0A> > > > > > >=0A> > > > > > > I'll speak more =
on this below.=0A> > > > > > >=0A> > > > > > > > So IMHO the best way is th=
e mitigations I suggested and=0A> > > > > > > > that you illustrated below =
in pseudo-code.=0A> > > > > > >=0A> > > > > > > OK.=0A> > > > > > >=0A> > >=
 > > > > > See further 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> > > > > > > > > Subj=
ect: RE: Routing loop attacks using IPv6 tunnels=0A> > > > > > > > >=0A> > =
> > > > > > > Gabi,=0A> > > > > > > > >=0A> > > > > > > > > > -----Original=
 Message-----=0A> > > > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yah=
oo.com]=0A> > > > > > > > > > Sent: Monday, August 24, 2009 4:44 AM=0A> > >=
 > > > > > > > To: Templin, Fred L; v6ops=0A> > > > > > > > > > Cc: ipv6@ie=
tf.org; secdir@ietf.org=0A> > > > > > > > > > Subject: Re: Routing loop att=
acks using IPv6 tunnels=0A> > > > > > > > > >=0A> > > > > > > > > > Fred,=
=0A> > > > > > > > > > I initially very much liked your suggestion regardin=
g the =0A> check of=0A> > > the=0A> > > > > > > > > neighbor cache before=
=0A> > > > > > > > > > forwarding a packet into the tunnel. It truly addres=
ses the =0A> root=0A> > > cause=0A> > > > > of=0A> > > > > > > the=0A> > > =
> > > > > > problem ans is simple=0A> > > > > > > > > > enough to implement=
. However, I realized that an attacker can =0A> send=0A> > > a=0A> > > > > =
> > > > spoofed RS to the ISATAP router=0A> > > > > > > > > > as if it came=
 from the 6to4 relay. The router would then 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> > > > > > > > > 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 c=
ase in which the ISATAP router is=0A> > > > > > > > > located within a site=
 protected by border routers that perform=0A> > > > > > > > > ip-proto-41 a=
nd ingress filtering, and in which there is no=0A> > > > > > > > > untracea=
ble 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 =0A> proto-41=0A> > > > > filtering=0A> > > > > > > i=
s employed. If the=0A> > > > > > > > attacker is internal to the site then =
the proto-41 filtering 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 embe=
d the=0A> > > > > > > IPv4 source and/or the IPv4 source is a PRL router, y=
ou must be=0A> > > > > > > speaking here about IPv4 source address spoofing=
 from within the=0A> > > > > > > site. For sites that allow intra-site sour=
ce address spoofing,=0A> > > > > > > I think much more serious problems cou=
ld manifest themselves=0A> > > > > > > that would be completely unrelated t=
o ISATAP. I believe you=0A> > > > > > > will also find other automatic tunn=
eling protocols besides=0A> > > > > > > ISATAP that operate under an assump=
tion of no intra-site IPv4=0A> > > > > > > source address spoofing.=0A> > >=
 > > > >=0A> > > > > > > > > > I completely agree with 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 m=
ay include=0A> > > > > > > > > > a private IPv4 address. On the other hand,=
 a check on public =0A> IPv4=0A> > > > > > > addresses is=0A> > > > > > > >=
 > acceptable. If the=0A> > > > > > > > > > check would be done only on ISA=
TAP addresses that include =0A> public=0A> > > IPv4=0A> > > > > > > > > add=
resses then this will=0A> > > > > > > > > > eliminate the attacks in which =
the two victims reside at =0A> different=0A> > > > > sites.=0A> > > > > > >=
 Note=0A> > > > > > > > > that if attack #3 is=0A> > > > > > > > > > launch=
ed on two ISATAP routers having private addresses at two=0A> > > > > differ=
ent=0A> > > > > > > sites=0A> > > > > > > > > then the attack will=0A> > > =
> > > > > > > not work anyway since one router can not send a direct IPv4 =
=0A> packet=0A> > > to=0A> > > > > the=0A> > > > > > > > > other. In additi=
on,=0A> > > > > > > > > > to mitigate 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 addres=
s, i.e. the destination =0A> address=0A> > > must=0A> > > > > not=0A> > > >=
 > > > be=0A> > > > > > > > > "2002:> > the ISATAP router>::*". In this cas=
e the IPv4 address =0A> must=0A> > > be=0A> > > > > > > public,=0A> > > > >=
 > > > > according to=0A> > > > > > > > > >=A0 the 6to4 spec.=0A> > > > > >=
 > > > >=0A> > > > > > > > > > As you also noted there is another problem w=
ith this check =0A> since=0A> > > the=0A> > > > > > > string=0A> > > > > > =
> > > "200::5EFE" is not unique=0A> > > > > > > > > > to ISATAP links. On t=
he other hand, it seems that the =0A> probability=0A> > > to=0A> > > > > > =
> encounter=0A> > > > > > > > > a non-malicious packet=0A> > > > > > > > > =
> with a destination address having an IID that equals =0A> "200:5EFE:>=0A>=
 > > IPv4=0A> > > > > > > address>" is=0A> > > > > > > > > > pretty slim.=
=0A> > > > > > > > > >=0A> > > > > > > > > > This check is definitely not a=
 perfect solution, and I sure =0A> hope=0A> > > that=0A> > > > > > > someon=
e=0A> > > > > > > > > will come up with a=0A> > > > > > > > > > better one =
for mitigating the routing loops. However, I 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> > > > > > > > > > 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=
 =0A> routers=0A> > > > > > > > > that perform ingress filtering and ip-pro=
to-41 filtering. That =0A> has=0A> > > > > > > > > traditionally been seen =
as the domain of 6to4, but I am happy to=0A> > > > > > > > > discuss the po=
ssibility of what I called the "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, I am referring 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 =
not =0A> the=0A> > > > > > > "inside-out ISATAP model" .=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 th=
at site, it would be nice=0A> > > > > > > > > to divide the site into multi=
ple logical partitions, with each=0A> > > > > > > > > partition identified =
by a PRL name and a unique set of IPv6=0A> > > > > > > > > prefixes. But th=
en, we have the scenario you are describing in=0A> > > > > > > > > which we=
 can't trust the integrity of the ISATAP router's=0A> > > > > > > > > neigh=
bor cache due to the possibility for untraceable IPv4=0A> > > > > > > > > s=
ource address spoofing such that the neighbor cache check=0A> > > > > > > >=
 > mitigation can be subverted.=0A> > > > > > > > >=0A> > > > > > > > > Thi=
s 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-link-local prefixes in the first place.=0A> > > >=
 > > > > >=0A> > > > > > > > > If we took the easy way out and did 2), then=
 the entire=0A> > > > > > > > > IPv4 Internet would look like one gigantic =
ISATAP link that=0A> > > > > > > > > only did IPv6 link-local. So, nodes co=
uld ping6 each others'=0A> > > > > > > > > ISATAP link-local addresses but =
that's about it.=0A> > > > > > > > >=0A> > > > > > > > > If we took the mor=
e ambitious route and allowed ISATAP to=0A> > > > > > > > > flourish fully =
within the global IPv4 Internet, then we=0A> > > > > > > > > would essentia=
lly be deprecating 6to4 - so it isn't=0A> > > > > > > > > surprising that y=
our address checks mostly involve 6to4=0A> > > > > > > > > suppression. Ass=
uming this, if I read your attack scenarios=0A> > > > > > > > > 1 through 3=
 correctly then scenarios 1 and 3 are mitigated=0A> > > > > > > > > by a re=
ceive-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 d=
rop_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 "*::0=
200:5efe:192.88.99.1")=0A> > > > > > > > >=A0 =A0 =A0 drop_pkt(); /* attack=
 #2 mitigation */=0A> > > > > > > > >=A0 =A0 ...=0A> > > > > > > > >=A0 }=
=0A> > > > > > > >=0A> > > > > > > > This will not necessarily work, since =
the 6to4 relay may have a=0A> > > unicast=0A> > > > > > > address the ISATA=
P router may=0A> > > > > > > > not be aware of. The best way to mitigate at=
tack #2 is by the 6to4=0A> > > relay=0A> > > > > with=0A> > > > > > > a che=
ck 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 ISATAP=0A> > > > > > > > router to drop the packet if (src=A0 =3D=3D 2=
002:::*"). However, this=0A> > > > > > > check is useful only=0A> > > > > >=
 > > when the 6to4 relay validates that the IPv6 source address =0A> corres=
ponds=0A> > > to=0A> > > > > the=0A> > > > > > > IPv4 one (this is=0A> > > =
> > > > > in accordance with the 6to4 spec, however it does not always get=
=0A> > > > > implemented).=0A> > > > > > > If this is not true=0A> > > > > =
> > > then the attacker does not have to send the attack packet with =0A> s=
uch an=0A> > > > > > > address.=0A> > > > > > >=0A> > > > > > > Keeping wit=
h the philosophy of the ISATAP router defending itself,=0A> > > > > > > I b=
elieve 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 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=
: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > > > Sent: Wednesday, Aug=
ust 19, 2009 6:16:18 PM=0A> > > > > > > > > > Subject: RE: Routing loop att=
acks using IPv6 tunnels=0A> > > > > > > > > >=0A> > > > > > > > > > Hi Gabi=
,=0A> > > > > > > > > >=0A> > > > > > > > > > I'm sorry to have to keep tur=
ning 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.o=
rg; secdir@ietf.org=0A> > > > > > > > > > Subject: Re: Routing loop attacks=
 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; secdir@ietf.org=0A> > > > > > > > > >=
 Sent: Tuesday, August 18, 2009 6:48:45 PM=0A> > > > > > > > > > Subject: R=
E: Routing loop attacks using IPv6 tunnels=0A> > > > > > > > > >=0A> > > > =
> > > > > > Gabi,=0A> > > > > > > > > >=0A> > > > > > > > > > _____________=
___________________________=0A> > > > > > > > > > From: Gabi Nakibly [mailt=
o:gnakibly@yahoo.com]=0A> > > > > > > > > > Sent: Tuesday, August 18, 2009 =
3:29 AM=0A> > > > > > > > > > To: Templin, Fred L; v6ops=0A> > > > > > > > =
> > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > > > > Subject: R=
e: 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 it is stil=
l assumed=0A> > > > > > > > > > > that the associated IPv4 address is non-p=
rivate). As we=0A> > > > > > > > > > > explicitly note in the paper, the fi=
rst three attacks will=0A> > > > > > > > > > > be mitigated if proper proto=
col-41 filtering is deployed on=0A> > > > > > > > > > > the site's border. =
However, note that RFC5214 does not =0A> mandate=0A> > > > > > > > > > > or=
 require this filtering.=0A> > > > > > > > > >=0A> > > > > > > > > > The RF=
C5214 Security Considerations makes clear the=0A> > > > > > > > > > consequ=
ences of not implementing IPv4 ingress filtering=0A> > > > > > > > > > and =
ip-protocol-41 filtering (i.e., a possible spooing=0A> > > > > > > > > > at=
tack in which spurious ip-protocol-41 packets are=0A> > > > > > > > > > inj=
ected into an ISATAP link from outside). RFC5214=0A> > > > > > > > > > Sect=
ion 6.2 additionally requires that an ISATAP 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, where the enterprise =
interior=0A> > > > > > > > > > is site #1 and the global Internet is site #=
2. ip-protocol-41=0A> > > > > > > > > > filtering is the way in which the I=
SATAP interface is=0A> > > > > > > > > > restricted to a single site.=0A> >=
 > > > > > > > >=0A> > > > > > > > > > Now let me see that I understand Sec=
tion 6.2 correctly. In=0A> > > > > > > > > > attack #2, for example, I assu=
me the ISATAP router has two=0A> > > > > > > > > > physical interfaces. A s=
ite-internal IPv4 interface with an=0A> > > > > > > > > > address IPisatap =
and a site-external IPv6 interface. I also=0A> > > > > > > > > > assume tha=
t there is another border router which connects the=0A> > > > > > > > > > s=
ite to the IPv4 Internet. The ISATAP router has an ISATAP=0A> > > > > > > >=
 > > interface with a single locator: (IPisatap, site-internal=0A> > > > > =
> > > > > interface). When the ISATAP router gets an IPv6 via its=0A> > > >=
 > > > > > > external interface it will encapsulate the packet accordingly=
=0A> > > > > > > > > > and forward it through the internal IPv4 interface. =
If the=0A> > > > > > > > > > encapsulated packet is destined to a node outs=
ide the site=0A> > > > > > > > > > then the only thing that stops it is a p=
roto-41 filtering=0A> > > > > > > > > > at the other border router of the s=
ite. 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 ma=
jor enterprise=0A> > > > > > > > > > =3D=3D> network that does this.=0A> > =
> > > > > > > >=0A> > > > > > > > > > > It is only mentioned as a possible =
mitigation against=0A> > > > > > > > > > > incoming spurious protocol-41 pa=
ckets. In addition,=0A> > > > > > > > > > > Section 10 of RFC5214 only ment=
ions ingress not egress=0A> > > > > > > > > > > filtering. Hence it will no=
t stop attack #2.=0A> > > > > > > > > >=0A> > > > > > > > > > We are now ta=
lking about ip-proto-41 filtering; not ingress=0A> > > > > > > > > > filter=
ing. 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 interior. Else the ISATAP=0A> > > > > > > > >=
 > interface would span multiple sites.=0A> > > > > > > > > >=0A> > > > > >=
 > > > > Besides, "ingress" filtering is not about packets coming=0A> > > >=
 > > > > > > from the Internet into the end site, but rather it is=0A> > > =
> > > > > > > about packets 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, protocol-41 filtering is not helpful when=0A=
> > > > > > > > > > > attack #3 is launched on two routers that reside in t=
he=0A> > > > > > > > > > > same site. Note that it may be possible for the =
attack=0A> > > > > > > > > > > packet to be sourced from outside the site u=
nless proper=0A> > > > > > > > > > > filtering of incoming IPv6 packets is =
deployed. If the=0A> > > > > > > > > > > attacker resides in the site, usua=
lly 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 bo=
th cases sourcing a=0A> > > > > > > > > > packet from a foreign prefix.=0A>=
 > > > > > > > > >=0A> > > > > > > > > > Well, I do not see how this is cor=
rect. In attacks #1 and #3 =0A> the=0A> > > > > ISATAP=0A> > > > > > > rout=
er=0A> > > > > > > > > sources (actually=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 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 are two cases to consider. Case=0A> > =
> > > > > > > > =3D=3D> 1 in which a border router separates the 6to4 relay=
 from =0A> the=0A> > > > > > > > > > =3D=3D> ISATAP router, and case 2 in w=
hich no border router =0A> 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. IPv=
6 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 ro=
uter is outside the site then ip-proto-41=0A> > > > > > > > > > =3D=3D> fil=
tering 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 rel=
ay should=0A> > > > > > > > > > =3D=3D> really be positioned outside of the=
 site's border routers;=0A> > > > > > > > > > =3D=3D> otherwise, it could b=
e spoofed into thinking that the=0A> > > > > > > > > > =3D=3D> ISATAP route=
r is a 6to4 router and not an ISATAP router.=0A> > > > > > > > > > =3D=3D>=
=0A> > > > > > > > > > =3D=3D> In attack #2, we have an IPv6 packet with a =
foreign source=0A> > > > > > > > > > =3D=3D> address being forwarded by the=
 ISATAP router to a 6to4=0A> > > > > > > > > > =3D=3D> relay, but I mis-spo=
ke when I said that this would be a=0A> > > > > > > > > > =3D=3D> case of t=
he ISATAP router forwarding a packet with a =0A> foreign=0A> > > > > > > > =
> > =3D=3D> source address out of the ISATAP link. For all the ISATAP=0A> >=
 > > > > > > > > =3D=3D> router knows, the 6to4 relay is just an ordinary h=
ost on=0A> > > > > > > > > > =3D=3D> the ISATAP link, so the ISATAP router =
actually believes it=0A> > > > > > > > > > =3D=3D> is forwarding the packet=
 *into* the ISATAP link (not out =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 ISATAP router=
 =0A> and=0A> > > > > > > > > > =3D=3D> the 6to4 relay. If there is no bord=
er router between the=0A> > > ISATAP=0A> > > > > > > > > > =3D=3D> router a=
nd the 6to4 relay, then we have an identical =0A> 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 6to=
4 relay=0A> > > > > > > > > > =3D=3D> oriented outside of a border router t=
hat filters =0A> ip-proto-41.=0A> > > > > > > > > > =3D=3D>=0A> > > > > > >=
 > > > =3D=3D> Short summary is that in attack #1, the 6to4 relay thinks =
=0A> it=0A> > > > > > > > > > =3D=3D> is talking to a 6to4 router and not a=
n ISATAP router. In=0A> > > > > > > > > > =3D=3D> attack #2, the ISATAP rou=
ter 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 the=
=0A> > > > > > > > > > =3D=3D> 6to4 relay. Oftentimes, the "border router" =
will be a two-=0A> > > > > > > > > > =3D=3D> interface router that implemen=
ts 6to4 on a site-external=0A> > > > > > > > > > =3D=3D> IPv4 interface and=
 implements ISATAP on a site-internal=0A> > > > > > > > > > =3D=3D> IPv4 in=
terface and performs ip-proto-41 filtering on =0A> packets=0A> > > > > > > =
> > > =3D=3D> from outside the site with an IPv4 destination =0A> correspon=
ding=0A> > > > > > > > > > =3D=3D> to the ISATAP interface. I will discuss =
attack #3 below:=0A> > > > > > > > > >=0A> > > > > > > > > > This attack is=
 mitigated by=0A> > > > > > > > > > IPv6 ingress filtering which is an IPv6=
 security consideration=0A> > > > > > > > > > and not an ISATAP nor IPv4 se=
curity consideration. BCP=0A> > > > > > > > > > recommendations for network=
 ingress filtering are documented=0A> > > > > > > > > > in RFC2827 and it i=
s expected that IPv6 routers that configure=0A> > > > > > > > > > ISATAP in=
terfaces will implement IPv6 ingress filtering=0A> > > > > > > > > > accord=
ing to the BCP.=0A> > > > > > > > > >=0A> > > > > > > > > > So If my last c=
omment is correct than I do not see how ingress=0A> > > > > filtering=0A> >=
 > > > > > would=0A> > > > > > > > > help here. The only=0A> > > > > > > > =
> > case where ingress filtering can help is in case of attack #3 =0A> when=
=0A> > > the=0A> > > > > > > routers=0A> > > > > > > > > reside at the same=
=0A> > > > > > > > > > site. In that case if the attack packet (packet 0) i=
s sent =0A> from=0A> > > > > outside=0A> > > > > > > the=0A> > > > > > > > =
> site then ingress=0A> > > > > > > > > > filtering on the border of the si=
te will drop the packet.=0A> > > > > > > > > >=0A> > > > > > > > > >=0A> > =
> > > > > > > > =3D=3D> Correct about the IPv6 ingress filtering at the bor=
der,=0A> > > > > > > > > > =3D=3D> but as with attack #2 my error in the pr=
evious message=0A> > > > > > > > > > =3D=3D> was in thinking the ISATAP rou=
ter A was forwarding the=0A> > > > > > > > > > =3D=3D> packet *out* of the =
ISATAP link when in fact from the=0A> > > > > > > > > > =3D=3D> ISATAP rout=
er'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 blind=
ly=0A> > > > > > > > > > =3D=3D> forwarding a packet to a node that it assu=
mes is a simple=0A> > > > > > > > > > =3D=3D> host on the ISATAP link witho=
ut first verifying that the=0A> > > > > > > > > > =3D=3D> node has demonstr=
ated a willingness to participate as a=0A> > > > > > > > > > =3D=3D> host o=
n the link. As you have pointed out, this can lead=0A> > > > > > > > > > =
=3D=3D> to strange scenarios when the anonymous node is a tunnel=0A> > > > =
> > > > > > =3D=3D> router of some sort that does not participate in the=0A=
> > > > > > > > > > =3D=3D> ISATAP link.=0A> > > > > > > > > > =3D=3D>=0A> =
> > > > > > > > > =3D=3D> It would not generally be possible for the ISATAP=
 router=0A> > > > > > > > > > =3D=3D> to check whether the IPv6 destination=
 address is an ISATAP=0A> > > > > > > > > > =3D=3D> address that embeds one=
 of its own IPv4 addresses, 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 =0A> 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 pack=
et with ISATAP=0A> > > > > > > > > > =3D=3D> destination address 2001:DB8::=
0:5EFE:10.0.0.1 where the=0A> > > > > > > > > > =3D=3D> IPv6 prefix is fore=
ign, the router can't very well drop =0A> the=0A> > > > > > > > > > =3D=3D>=
 packet as this would block legitimate communications. It=0A> > > > > > > >=
 > > =3D=3D> is also not generally possible to check whether a foreign=0A> =
> > > > > > > > > =3D=3D> link is an ISATAP link by looking for the magic t=
oken=0A> > > > > > > > > > =3D=3D> "0:5EFE" as that token only has signific=
ance for ISATAP=0A> > > > > > > > > > =3D=3D> links and not other link type=
s.=0A> > > > > > > > > > =3D=3D>=0A> > > > > > > > > > =3D=3D> Instead, the=
 mitigation I think makes the most sense is=0A> > > > > > > > > > =3D=3D> f=
or the ISATAP router to first verify that the node which=0A> > > > > > > > =
> > =3D=3D> it assumes to be a simple ISATAP host has demonstrated a=0A> > =
> > > > > > > > =3D=3D> willingness to participate in the link. That can be=
 done=0A> > > > > > > > > > =3D=3D> by having the ISATAP router first check=
 the neighbor cache=0A> > > > > > > > > > =3D=3D> when it has a packet to s=
end to verify that there is a=0A> > > > > > > > > > =3D=3D> cached entry co=
rresponding to the destination. For nodes=0A> > > > > > > > > > =3D=3D> tha=
t 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 lifeti=
mes and on-=0A> > > > > > > > > > =3D=3D> link prefixes. So, the simple mit=
igations is for the =0A> ISATAP=0A> > > > > > > > > > =3D=3D> router to for=
ward the packet only if there is a =0A> 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 the prefixes=0A> > > > > > > > > > =3D=3D> it advertises in its Router A=
dvertisements.=0A> > > > > > > > > >=0A> > > > > > > > > > > In general, I =
would like to point out that indeed as in=0A> > > > > > > > > > > most othe=
r attacks these attacks may also be mitigated by=0A> > > > > > > > > > > pr=
oper firewall rules. However, I do not believe that this=0A> > > > > > > > =
> > > should be our only answer against these attacks. I believe=0A> > > > =
> > > > > > > that since these attacks are made possible due to the=0A> > >=
 > > > > > > > > inherent 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 filtering r=
ules.=0A> > > > > > > > > >=0A> > > > > > > > > > In RFC5214, Section 10 we=
 have: "restricting access to the=0A> > > > > > > > > > link can be achieve=
d 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> > > > > > > > > > c=
hecks. So on this point, I do not share your opinion.=0A> > > > > > > > > >=
=0A> > > > > > > > > > What about two ISATAP tunnels that reside on the sam=
e site =0A> like in=0A> > > > > attack=0A> > > > > > > #3.=0A> > > > > > > =
> > Do you also think 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 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 ro=
uter interfaces inside=0A> > > > > > > > > > =3D=3D> of the site border rat=
her than outside. Also proper=0A> > > > > > > > > > =3D=3D> ip-proto-41 fil=
tering and IPv6 ingress filtering at=0A> > > > > > > > > > =3D=3D> site bor=
ders.=0A> > > > > > > > > > =3D=3D>=0A> > > > > > > > > > =3D=3D> Also, whe=
n 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, 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 do=
cument, attacks A, B =0A> and=0A> > > C=0A> > > > > > > > > > correspond to=
 a configuration that violates section 6.2 of=0A> > > RFC5214:=0A> > > > > =
> > > > >=0A> > > > > > > > > > > 6.2.=A0 ISATAP Interface Address Configur=
ation=0A> > > > > > > > > > >=0A> > > > > > > > > > >=A0 Each ISATAP interf=
ace configures a set of locators =0A> consisting=0A> > > of=0A> > > > > IPv=
4=0A> > > > > > > > > > >=A0 address-to-interface mappings from a single si=
te; i.e., an=0A> > > ISATAP=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 =0A> for=0A=
> > > > > ISATAP=0A> > > > > > > > > > is seen both within the enterprise a=
s 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 shoul=
d therefore not accept IP-proto-41=0A> > > packets=0A> > > > > > > > > > co=
ming from an IPv4 source outside of the enterprise nor =0A> source=0A> > > =
> > > > > > > IP-proto-41 packets that are destined to an IPv4 node outside=
 =0A> of=0A> > > the=0A> > > > > > > > > > enterprise. This condition shoul=
d be satisfied by having the =0A> site=0A> > > > > border=0A> > > > > > > >=
 > > routers implement IPv4 ingress filtering and ip-protocol-41=0A> > > fi=
ltering=0A> > > > > as=0A> > > > > > > > > > required in Section 10 of RFC5=
214.=0A> > > > > > > > > >=0A> > > > > > > > > > It is mentioned that attac=
k C could also occur when the =0A> routers=0A> > > reside=0A> > > > > > > >=
 > > in the same site, where their addresses may be private. This =0A> woul=
d=0A> > > > > > > > > > correspond to a case in which an attacker within th=
e site =0A> attacks=0A> > > the=0A> > > > > > > > > > site itself, which ca=
n easily be traced - especially when =0A> source=0A> > > > > address=0A> > =
> > > > > > > > spoofing from a node within the site is prevented through =
=0A> proper=0A> > > > > ingress=0A> > > > > > > > > > filtering.=0A> > > > =
> > > > > >=0A> > > > > > > > > > Fred=0A> > > > > > > > > > fred.l.templin=
@boeing.com=0A> > > > > > > > > >=0A> > > > > > > > > > ___________________=
_____________________=0A> > > > > > > > > > From: Gabi Nakibly [mailto:gnak=
ibly@yahoo.com]=0A> > > > > > > > > > Sent: Monday, August 17, 2009 8:21 AM=
=0A> > > > > > > > > > To: v6ops=0A> > > > > > > > > > Cc: ipv6@ietf.org; s=
ecdir@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 som=
e research results=0A> > > > > > > which=0A> > > > > > > > > my colleague a=
nd I at=0A> > > > > > > > > > the National EW Research & Simulation Center =
have recently=0A> > > published.=0A> > > > > The=0A> > > > > > > > > resear=
ch presents a class=0A> > > > > > > > > > of routing loop attacks that abus=
es 6to4, ISATAP and Teredo. =0A> The=0A> > > paper=0A> > > > > can=0A> > > =
> > > > be=0A> > > > > > > > > found at:=0A> > > > > > > > > > =0A> http://=
www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf=0A> > > > > > > >=
 > >=0A> > > > > > > > > > Here is the abstract:=0A> > > > > > > > > > IPv6=
 is the future network layer protocol for the Internet. =0A> Since=0A> > > =
it=0A> > > > > is=0A> > > > > > > not=0A> > > > > > > > > compatible with i=
ts=0A> > > > > > > > > > predecessor, some interoperability mechanisms were=
 designed. =0A> An=0A> > > > > important=0A> > > > > > > > > category of th=
ese=0A> > > > > > > > > > mechanisms is automatic tunnels, which enable IPv=
6 =0A> communication=0A> > > over=0A> > > > > an=0A> > > > > > > IPv4=0A> >=
 > > > > > > > network without prior=0A> > > > > > > > > > configuration. T=
his category includes ISATAP, 6to4 and Teredo. =0A> We=0A> > > > > present=
=0A> > > > > > > a=0A> > > > > > > > > novel class of attacks=0A> > > > > >=
 > > > > that exploit vulnerabilities in these tunnels. These attacks =0A> =
take=0A> > > > > > > advantage of=0A> > > > > > > > > inconsistencies=0A> >=
 > > > > > > > > between a tunnel's overlay IPv6 routing state and the nati=
ve =0A> IPv6=0A> > > > > routing=0A> > > > > > > > > state. The attacks for=
m=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 presented=0A> > > attacks=0A> > > > > can=0A> > > > > > =
> DoS a=0A> > > > > > > > > Teredo server using a=0A> > > > > > > > > > sin=
gle packet. The exploited vulnerabilities are embedded in =0A> the=0A> > > =
> > design of=0A> > > > > > > the=0A> > > > > > > > > tunnels; hence any=0A=
> > > > > > > > > > implementation of these tunnels may be vulnerable. In =
=0A> particular,=0A> > > the=0A> > > > > > > attacks=0A> > > > > > > > > we=
re tested=0A> > > > > > > > > > against the ISATAP, 6to4 and Teredo impleme=
ntations of Windows=0A> > > Vista=0A> > > > > and=0A> > > > > > > > > Windo=
ws 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 sentimen=
t of the list, 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> > > > > > > eliminate=0A> > > > > > > > > the problem. How=
ever=0A> > > > > > > > > > they are far from perfect since they would requi=
re tunnel=0A> > > > > implementations=0A> > > > > > > to=0A> > > > > > > > =
> be updated in case new=0A> > > > > > > > > > types of automatic tunnels a=
re introduced.=0A> > > > > > > > > >=0A> > > > > > > > > > Your comments ar=
e welcome.=0A> > > > > > > > > >=0A> > > > > > > > > > Gabi=0A> > > > > > >=
 > > >=0A> > > > > > > > > >=0A> > > > > > > > > >=0A> > > > > > > >=0A> > =
> > > > > >=0A> > > > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > >=0A>=
 > > > > >=0A> > > >=0A> > > >=0A> > > >=0A> > > >=0A> > > ----------------=
----------------------------------------------------=0A> > > IETF IPv6 work=
ing group mailing list=0A> > > ipv6@ietf.org=0A> > > Administrative Request=
s: https://www.ietf.org/mailman/listinfo/ipv6=0A> > > ---------------------=
-----------------------------------------------=0A> > =0A> > =0A> > =0A> > =
=0A=0A=0A=0A      

From Fred.L.Templin@boeing.com  Fri Sep 11 14:13:20 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 029AC3A6991; Fri, 11 Sep 2009 14:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.634
X-Spam-Level: 
X-Spam-Status: No, score=-5.634 tagged_above=-999 required=5 tests=[AWL=0.365,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeSqlkL9aIrh; Fri, 11 Sep 2009 14:13:16 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id C7F223A6A46; Fri, 11 Sep 2009 14:13:15 -0700 (PDT)
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
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" <Fred.L.Templin@boeing.com>
To: "Gabi Nakibly" <gnakibly@yahoo.com>, "Christian Huitema" <huitema@microsoft.com>, "v6ops" <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 11 Sep 2009 21:13:45.0593 (UTC) FILETIME=[BF5E0690:01CA3324]
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2009 21:13:20 -0000

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" <Fred.L.Templin@boeing.com>
> > To: Gabi Nakibly <gnakibly@yahoo.com>; Christian Huitema =
<huitema@microsoft.com>; v6ops
> <v6ops@ops.ietf.org>
> > 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:<my_IPv4_addr>")
> > =A0 =A0 =A0 drop_pkt();
> > =A0 =A0 ...
> > =A0 }
> >
> > =A0 isatap_xmt() {
> > =A0 =A0 ...
> > =A0 =A0 if (v6src =3D=3D "foreign_prefix::0200:5efe:<my_IPv4_addr>")
> > =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 brian.e.carpenter@gmail.com  Fri Sep 11 16:05:10 2009
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4413828C1A1; Fri, 11 Sep 2009 16:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level: 
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.426,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETZbuyF5A4ul; Fri, 11 Sep 2009 16:05:09 -0700 (PDT)
Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id 7F8503A67AD; Fri, 11 Sep 2009 16:05:09 -0700 (PDT)
Received: by pzk33 with SMTP id 33so1208991pzk.24 for <multiple recipients>; 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 <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@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>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Gabi Nakibly <gnakibly@yahoo.com>, Christian Huitema <huitema@microsoft.com>, v6ops <v6ops@ops.ietf.org>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2009 23:05:10 -0000

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 Fred.L.Templin@boeing.com  Fri Sep 11 16:11:51 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F093A67E9; Fri, 11 Sep 2009 16:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.953
X-Spam-Level: 
X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.646,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7b4rfgZRKo8; Fri, 11 Sep 2009 16:11:50 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id BB2383A67C0; Fri, 11 Sep 2009 16:11:50 -0700 (PDT)
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
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" <Fred.L.Templin@boeing.com>
To: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
X-OriginalArrivalTime: 11 Sep 2009 23:12:24.0839 (UTC) FILETIME=[52C4C170:01CA3335]
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2009 23:11:51 -0000

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 brian.e.carpenter@gmail.com  Fri Sep 11 18:26:03 2009
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9213A6A9B; Fri, 11 Sep 2009 18:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level: 
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tB-9WCAYCo9; Fri, 11 Sep 2009 18:26:02 -0700 (PDT)
Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id 582C43A6A48; Fri, 11 Sep 2009 18:26:02 -0700 (PDT)
Received: by pzk33 with SMTP id 33so1266128pzk.24 for <multiple recipients>; 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 <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@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> <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
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Sep 2009 01:26:03 -0000

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 ananth@cisco.com  Sun Sep 13 04:37:37 2009
Return-Path: <ananth@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3983A67A1; Sun, 13 Sep 2009 04:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.479
X-Spam-Level: 
X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHo5CC5DmQZp; Sun, 13 Sep 2009 04:37:36 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id ADCF43A684A; Sun, 13 Sep 2009 04:37:36 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAP91rEqrR7MV/2dsb2JhbADBHohMAY4ZBYQY
X-IronPort-AV: E=Sophos;i="4.44,378,1249257600"; d="scan'208";a="241051473"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 13 Sep 2009 11:38:18 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8DBcI6a008538;  Sun, 13 Sep 2009 04:38:18 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8DBcI5i024910; Sun, 13 Sep 2009 11:38:18 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 13 Sep 2009 04:38:18 -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
Date: Sun, 13 Sep 2009 04:38:17 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5807FF0261@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <Pine.WNT.4.64.0906080948290.6048@SANDYM-LT.columbia.ads.sparta.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-tcpm-tcpsecure
Thread-Index: AcnoQZQAkY7GfiSvTvqgEDwTP3OoExMIAoJw
References: <Pine.WNT.4.64.0906080948290.6048@SANDYM-LT.columbia.ads.sparta.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Sandra Murphy" <sandy@sparta.com>, "Mitesh Dalal (mdalal)" <mdalal@cisco.com>
X-OriginalArrivalTime: 13 Sep 2009 11:38:18.0566 (UTC) FILETIME=[B07B4E60:01CA3466]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2905; t=1252841898; x=1253705898; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20draft-ietf-tcpm-tcpsecure |Sender:=20; bh=YPXRKq7iyfBihkkSyYCmpepiGPJCqJlQRHhZjzXkZfo=; b=GTOLIFthPJpG6k9yI4dmiGFLZ+ITU8a3nLpy7mXWUc4H/wmlndytK4ziFV W7dOk687KJp495rsAggcL1jOzJDUzC453GQp35sArsfW1JxsoUzSLuuxa2VJ gU3hhCcSgwPJIkF+pHpj3XJjsM0sGxixQKTH0rCI7jyqd7bNS5FQ4=;
Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: iesg@ietf.org, Lars Eggert <lars.eggert@nokia.com>, secdir@ietf.org
Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Sep 2009 11:37:37 -0000

I figured out the reply to this email doidn't make it ( I was editing
the draft based on the feedback received) =20

> -----Original Message-----
> From: Sandra Murphy [mailto:sandy@sparta.com]=20
> Sent: Monday, June 08, 2009 6:59 AM
> To: Anantha Ramaiah (ananth); Mitesh Dalal (mdalal)
> Cc: iesg@ietf.org; secdir@ietf.org
> Subject: draft-ietf-tcpm-tcpsecure
>=20
> I've been on the road, so this is just a quick note to say=20
> that I still have questions, with a promise of more full=20
> answer when I get back to the office tomorrow.  All the=20
> following done really from memory from a re-review yesterday.=20
>  Just  so you know I haven't forgotten you.
>=20
> About quoting text:
>=20
> The example you point to of what each mitigation says is a good case.=20
> (what is "rg"?)
>=20
> You posit a case 1 and case 2.  This is a summary of what 793=20
> says, not a quote.  793 spreads the discussion over 2 pages. =20
> your case 1 is represented in a parenthetical remark in an=20
> "otherwise" clause - hard to find.  And you have a typo in=20
> the inequality.  And the case 2 in 793 is broken out over=20
> three different groupings of states.  Do you mean the new ACK=20
> to be generated in all three state groups?

Are you talking about RST/SYN mitigations ? If so the current text is
clear. The challenge ACK will be generated, pl note that the document
quotes the processing rules of the incoming segment and talks what mods
are suggested.=20

>=20
> About the stingency.
>=20
> If UNA is 1000, Max.snd.wnd is 50, and the ack is 975, then=20
> in 793, the ack is < UNA and so "it is ignored", in your=20
> draft the ack is > UNA-max.snd.wnd so it is acceptable.

Ok, I have added more text to clarify this point. "Ignored"
 means the ACK value is ignored and the segment is processed as per the
other rules, hence ignored implies "accepted" and not dropped.

>=20
> So your draft accepts more ACKs that 793.
>=20
> Have I lost my ability to tell > from <?  Do you regard=20
> accepting more ACKS as "more stringent"?

No, I think it is a mis-interpreation of ignored.

>=20
> About the guidance to implementors.
>=20
> It still looks to me like this guidance is only useful to=20
> implementors who are implementing both the OS TCP stack *AND*=20
> the application.  I.E., freebsd won't know whether this to=20
> follow the guidance or not but cisco/juniper/etc will.

Not sure why such an inference is made.

>=20
> What is the "AS"?
Applicability statement (but I couldn't find the AS reference in the
draft, it is spelled out in full)
?=20

-Anantha
>=20
> About grammar checks:
>=20
> And you did not miss email, I lost my marked up copy, so I've=20
>  gone through for the grammar check again (don't think I=20
> found all that many
> nits) and will send to you.
>=20
> --Sandy
>=20
>=20
>=20

From zhangdong_rh@huaweisymantec.com  Sun Sep 13 18:26:13 2009
Return-Path: <zhangdong_rh@huaweisymantec.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F00C3A6972; Sun, 13 Sep 2009 18:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.065
X-Spam-Level: 
X-Spam-Status: No, score=0.065 tagged_above=-999 required=5 tests=[AWL=0.559,  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 hPpjGlpafV-G; Sun, 13 Sep 2009 18:26:12 -0700 (PDT)
Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 9F4703A67E2; Sun, 13 Sep 2009 18:26:12 -0700 (PDT)
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 <0KPX00EM4TCLRT10@hstga01-in.huaweisymantec.com>; 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>; Mon, 14 Sep 2009 09:26:45 +0800 (CST)
Date: Mon, 14 Sep 2009 09:26:44 +0800
From: Dong Zhang <zhangdong_rh@huaweisymantec.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Brian E Carpenter <brian.e.carpenter@gmail.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> <4AAAD7C1.2060709@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A106624BD7@XCH-NW-7V2.nw.nos.boeing.com>
Message-id: <200909140926442553863@huaweisymantec.com>
X-Mailer: Foxmail 6, 10, 201, 20 [cn]
X-Mailman-Approved-At: Sun, 13 Sep 2009 23:56:38 -0700
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, "ipv6@ietf.org" <ipv6@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2009 01:26:13 -0000

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 turners@ieca.com  Mon Sep 14 07:44:24 2009
Return-Path: <turners@ieca.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09CBC3A68B1 for <secdir@core3.amsl.com>; Mon, 14 Sep 2009 07:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.861
X-Spam-Level: 
X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpVluhEcw7Ls for <secdir@core3.amsl.com>; Mon, 14 Sep 2009 07:44:23 -0700 (PDT)
Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by core3.amsl.com (Postfix) with SMTP id 0907C3A688A for <secdir@ietf.org>; Mon, 14 Sep 2009 07:44:22 -0700 (PDT)
Received: (qmail 76386 invoked from network); 14 Sep 2009 14:45:04 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.241.0.209 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 14 Sep 2009 14:45:03 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: VUBnnUMVM1lGKCUqx9O_D.iG.tROzrAes2LvzQS5KZ.KvgRpqrK447eMA6KToeAx7QTllY7JYie42xXJ9PiDE11bSYTXTU5VFzOWVsQlYRtYZFnWQba6O5MPvQjcBdFRTiNuJzMplEQ4M65huTrzTBpaNSWicnijzE0sKrEv.v9vsmfe7hMrDUHd6vUcXbEaWWo3OS33sjhaYaTTQinwqY1SLM0EXB_wMET_6_PeZ2lGLHDLfvP6PryIrcvKytgSxj07mvwVLl7_ocdHgXET7K52i8lhUK1Cv7BBLmnQh8yMbnxAS1Eu3CLkBq9MpB2FpO4I
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4AAE56EF.5080002@ieca.com>
Date: Mon, 14 Sep 2009 10:45:03 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: secdir <secdir@ietf.org>, iesg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-ipsecme-ikev2-resumption-07.all@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-ipsecme-ikev2-resumption-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2009 14:44:24 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
  These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

This ID is intended for the Standards Track.  It defines an efficient 
way to resume an IKE/IPsec session using a previous established IKE SA 
without the need to re-run the key exchange protocol from the beginning. 
  The approach is similar to that used by TLS session resumption, but 
modified for IKEv2.

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.

Technical comments:

4.3.1 does not require gateways to reject reused tickets (it's a 
SHOULD).  Shouldn't there be some text in the security considerations 
about gateways accepting reused tickets or text to say it's not a 
security consideration because of x, y, and z?  It's different than the 
considerations put forth in 9.8 because it addresses why the client must 
not present reused tickets.

4.3.2 states: "The client SHOULD NOT use this exchange type unless it 
knows that the gateway supports it."  What is the mechanism to determine 
whether the gateways support these new exchanges?  What happens when the 
client sends a request and the gateway doesn't support the response? 
What error message is returned from the gateway?  This might all be 
defined elsewhere in the IKE suite of specs, but this ID should probably 
point to that text wherever it is.

Editorial comments:

4.3.2: Should the may be MAY in the following: The first message may be 
rejected in?

4.3.2:  r/value ./value.

5: Note 6 is missing a ")"

6.1: r/MUST be protected so that only unauthorized access is not 
allowed/MUST be protected so that only authorized access is allowed

9.3: r/as possible. and/as possible, and

Cheers,

spt

From Sandra.Murphy@cobham.com  Mon Sep 14 08:22:36 2009
Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD07628C18C; Mon, 14 Sep 2009 08:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level: 
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfiSq0ijFsav; Mon, 14 Sep 2009 08:22:35 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B5FE93A63C9; Mon, 14 Sep 2009 08:22:35 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n8EFMrR7009048; Mon, 14 Sep 2009 10:22:53 -0500
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n8EFMq7V001257; Mon, 14 Sep 2009 10:22:52 -0500
Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.8]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 11:22:51 -0400
Date: Mon, 14 Sep 2009 11:22:47 -0400 (Eastern Daylight Time)
From: Sandra Murphy <sandy@sparta.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC5807FF0261@xmb-sjc-21c.amer.cisco.com>
Message-ID: <Pine.WNT.4.64.0909140726580.2228@SANDYM-LT.columbia.ads.sparta.com>
References: <Pine.WNT.4.64.0906080948290.6048@SANDYM-LT.columbia.ads.sparta.com> <0C53DCFB700D144284A584F54711EC5807FF0261@xmb-sjc-21c.amer.cisco.com>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-OriginalArrivalTime: 14 Sep 2009 15:22:52.0143 (UTC) FILETIME=[39C5BFF0:01CA354F]
Cc: "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, iesg@ietf.org, Lars Eggert <lars.eggert@nokia.com>, secdir@ietf.org
Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2009 15:22:36 -0000

On Sun, 13 Sep 2009, Anantha Ramaiah (ananth) wrote:

>
> I figured out the reply to this email doidn't make it ( I was editing
> the draft based on the feedback received)

That happens to you, too, huh?  Believe me, with my record of failed 
obligations lately, I'm really happy to have a chance to say "oh, that's 
OK" to someone.

The synopsis of this is:

How much rigor is needed in expressing the changes?

The cases (1) and (2) in section 3.2 have a typo.

What does the "it" in "it is ignored" mean?  As written, it looks like the 
ACK is ignored, but what I thought I saw in implementation was that the 
*segment* is ignored/dropped.  That makes a difference in comparing the 
new technique to the existing code.

How much does an application need to know about the TCP stack (and vice 
versa) for this to work (or work well)?

--Sandy

>
>> -----Original Message-----
>> From: Sandra Murphy [mailto:sandy@sparta.com]
>> Sent: Monday, June 08, 2009 6:59 AM
>> To: Anantha Ramaiah (ananth); Mitesh Dalal (mdalal)
>> Cc: iesg@ietf.org; secdir@ietf.org
>> Subject: draft-ietf-tcpm-tcpsecure
>>
>> I've been on the road, so this is just a quick note to say
>> that I still have questions, with a promise of more full
>> answer when I get back to the office tomorrow.  All the
>> following done really from memory from a re-review yesterday.
>>  Just  so you know I haven't forgotten you.
>>
>> About quoting text:
>>
>> The example you point to of what each mitigation says is a good case.
>> (what is "rg"?)
>>
>> You posit a case 1 and case 2.  This is a summary of what 793
>> says, not a quote.  793 spreads the discussion over 2 pages.
>> your case 1 is represented in a parenthetical remark in an
>> "otherwise" clause - hard to find.  And you have a typo in
>> the inequality.  And the case 2 in 793 is broken out over
>> three different groupings of states.  Do you mean the new ACK
>> to be generated in all three state groups?
>
> Are you talking about RST/SYN mitigations ? If so the current text is
> clear. The challenge ACK will be generated, pl note that the document
> quotes the processing rules of the incoming segment and talks what mods
> are suggested.
>
>>
>> About the stingency.
>>
>> If UNA is 1000, Max.snd.wnd is 50, and the ack is 975, then
>> in 793, the ack is < UNA and so "it is ignored", in your
>> draft the ack is > UNA-max.snd.wnd so it is acceptable.
>
> Ok, I have added more text to clarify this point. "Ignored"
> means the ACK value is ignored and the segment is processed as per the
> other rules, hence ignored implies "accepted" and not dropped.
>
>>
>> So your draft accepts more ACKs that 793.
>>
>> Have I lost my ability to tell > from <?  Do you regard
>> accepting more ACKS as "more stringent"?
>
> No, I think it is a mis-interpreation of ignored.
>
>>
>> About the guidance to implementors.
>>
>> It still looks to me like this guidance is only useful to
>> implementors who are implementing both the OS TCP stack *AND*
>> the application.  I.E., freebsd won't know whether this to
>> follow the guidance or not but cisco/juniper/etc will.
>
> Not sure why such an inference is made.
>
>>
>> What is the "AS"?
> Applicability statement (but I couldn't find the AS reference in the
> draft, it is spelled out in full)
> ?
>
> -Anantha
>>
>> About grammar checks:
>>
>> And you did not miss email, I lost my marked up copy, so I've
>>  gone through for the grammar check again (don't think I
>> found all that many
>> nits) and will send to you.
>>
>> --Sandy
>>
>>
>>
>

From yaronf@checkpoint.com  Mon Sep 14 08:34:18 2009
Return-Path: <yaronf@checkpoint.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B363A680B for <secdir@core3.amsl.com>; Mon, 14 Sep 2009 08:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.916
X-Spam-Level: 
X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.683,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 U0ZGlT2nipOd for <secdir@core3.amsl.com>; Mon, 14 Sep 2009 08:34:15 -0700 (PDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 4E6993A68CF for <secdir@ietf.org>; Mon, 14 Sep 2009 08:34:15 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8EFYjSr013012; Mon, 14 Sep 2009 18:34:45 +0300 (IDT)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 14 Sep 2009 18:34:44 +0300
From: Yaron Sheffer <yaronf@checkpoint.com>
To: Sean Turner <turners@ieca.com>, secdir <secdir@ietf.org>
Date: Mon, 14 Sep 2009 18:34:42 +0300
Thread-Topic: [secdir] secdir review of draft-ietf-ipsecme-ikev2-resumption-07
Thread-Index: Aco1SnMt8alEMyA7SlmZ/REuhKipTwABSNsw
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190A978FBE2@il-ex01.ad.checkpoint.com>
References: <4AAE56EF.5080002@ieca.com>
In-Reply-To: <4AAE56EF.5080002@ieca.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-ipsecme-ikev2-resumption-07.all@tools.ietf.org" <draft-ietf-ipsecme-ikev2-resumption-07.all@tools.ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-ipsecme-ikev2-resumption-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2009 15:34:19 -0000

Hi Sean,

Thanks for your comments. We will address them in the next version of the d=
raft.

Regarding your second technical comment: the draft specifically only allows=
 resumption to the same gateway that issued the ticket. And this gateway su=
pports the new exchange, by definition, which makes our text sort of redund=
ant.

Thanks,
	Yaron

> -----Original Message-----
> From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf
> Of Sean Turner
> Sent: Monday, September 14, 2009 17:45
> To: secdir; iesg@ietf.org
> Cc: draft-ietf-ipsecme-ikev2-resumption-07.all@tools.ietf.org
> Subject: [secdir] secdir review of draft-ietf-ipsecme-ikev2-resumption-07
>=20
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
>   These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
>=20
> This ID is intended for the Standards Track.  It defines an efficient
> way to resume an IKE/IPsec session using a previous established IKE SA
> without the need to re-run the key exchange protocol from the beginning.
>   The approach is similar to that used by TLS session resumption, but
> modified for IKEv2.
>=20
> Summary: This draft is basically ready for publication, but has nits
> that should be fixed before publication.
>=20
> Technical comments:
>=20
> 4.3.1 does not require gateways to reject reused tickets (it's a
> SHOULD).  Shouldn't there be some text in the security considerations
> about gateways accepting reused tickets or text to say it's not a
> security consideration because of x, y, and z?  It's different than the
> considerations put forth in 9.8 because it addresses why the client must
> not present reused tickets.
>=20
> 4.3.2 states: "The client SHOULD NOT use this exchange type unless it
> knows that the gateway supports it."  What is the mechanism to determine
> whether the gateways support these new exchanges?  What happens when the
> client sends a request and the gateway doesn't support the response?
> What error message is returned from the gateway?  This might all be
> defined elsewhere in the IKE suite of specs, but this ID should probably
> point to that text wherever it is.
>=20
> Editorial comments:
>=20
> 4.3.2: Should the may be MAY in the following: The first message may be
> rejected in?
>=20
> 4.3.2:  r/value ./value.
>=20
> 5: Note 6 is missing a ")"
>=20
> 6.1: r/MUST be protected so that only unauthorized access is not
> allowed/MUST be protected so that only authorized access is allowed
>=20
> 9.3: r/as possible. and/as possible, and
>=20
> Cheers,
>=20
> spt
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
>=20
> Scanned by Check Point Total Security Gateway.

From ananth@cisco.com  Mon Sep 14 08:37:39 2009
Return-Path: <ananth@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D94F3A68DE; Mon, 14 Sep 2009 08:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9qJUEaYSh2l; Mon, 14 Sep 2009 08:37:38 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 024513A680B; Mon, 14 Sep 2009 08:37:38 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAPv/rUqrR7PE/2dsb2JhbADFdohMAY5FBYQY
X-IronPort-AV: E=Sophos;i="4.44,384,1249257600"; d="scan'208";a="204362817"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 14 Sep 2009 15:38:22 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8EFcMhf021268;  Mon, 14 Sep 2009 08:38:22 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8EFcMsq014988; Mon, 14 Sep 2009 15:38:22 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 14 Sep 2009 08:38:22 -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
Date: Mon, 14 Sep 2009 08:38:21 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5807FF03B3@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <Pine.WNT.4.64.0909140726580.2228@SANDYM-LT.columbia.ads.sparta.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-tcpm-tcpsecure
Thread-Index: Aco1T1HneiZWSkL7SIW96Cp4o1j9pgAAGZvw
References: <Pine.WNT.4.64.0906080948290.6048@SANDYM-LT.columbia.ads.sparta.com> <0C53DCFB700D144284A584F54711EC5807FF0261@xmb-sjc-21c.amer.cisco.com> <Pine.WNT.4.64.0909140726580.2228@SANDYM-LT.columbia.ads.sparta.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Sandra Murphy" <sandy@sparta.com>
X-OriginalArrivalTime: 14 Sep 2009 15:38:22.0600 (UTC) FILETIME=[645E3880:01CA3551]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5321; t=1252942702; x=1253806702; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20draft-ietf-tcpm-tcpsecure |Sender:=20; bh=k2v6OlP5UDkIBTHmRSl7+BGR5rCEWF3hivxh5Rn45SI=; b=tCivzREVB4wQtIYLRSHx8NlBFfwvP2JHxy4TW8L0lq4x3Wo1MMSmbx/d0r DQXxQ4h7saXy6uM64Nkbkv0Pa2VqXra7gLo3Oizk3YYcsaRdaDNKVpEVTbfM wIOzlu9FQn;
Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, iesg@ietf.org, Lars Eggert <lars.eggert@nokia.com>, secdir@ietf.org
Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2009 15:37:39 -0000

=20

> -----Original Message-----
> From: Sandra Murphy [mailto:sandy@sparta.com]=20
> Sent: Monday, September 14, 2009 8:23 AM
> To: Anantha Ramaiah (ananth)
> Cc: Mitesh Dalal (mdalal); iesg@ietf.org; secdir@ietf.org; Lars Eggert
> Subject: RE: draft-ietf-tcpm-tcpsecure
>=20
>=20
>=20
> On Sun, 13 Sep 2009, Anantha Ramaiah (ananth) wrote:
>=20
> >
> > I figured out the reply to this email doidn't make it ( I=20
> was editing=20
> > the draft based on the feedback received)
>=20
> That happens to you, too, huh?  Believe me, with my record of=20
> failed obligations lately, I'm really happy to have a chance=20
> to say "oh, that's OK" to someone.

I was waiting for your other comments and wanted to reply all together.
Anyways, I have incorporated your comments along with all the other last
call comments received and posted the new version.

>=20
> The synopsis of this is:
>=20
> How much rigor is needed in expressing the changes?
>=20
> The cases (1) and (2) in section 3.2 have a typo.

The text is quoted as per RFC 793. Which line is that are you referring
to ?

>=20
> What does the "it" in "it is ignored" mean?  As written, it=20
> looks like the ACK is ignored, but what I thought I saw in=20
> implementation was that the
> *segment* is ignored/dropped.  That makes a difference in=20
> comparing the new technique to the existing code.

Hmm.. Which implementation are you talking about?. ACK ignored !=3D ACK
dropped. (I have clarfied that in the new version) As mentioned in 793,
the segment is continued for processing, all implementations do the same
today.

>=20
> How much does an application need to know about the TCP stack=20
> (and vice
> versa) for this to work (or work well)?

It is a generic enhancement, although some applications sporting long
lived TCP connections tend to benefit when compared to short lived
applications (relatively speaking)

Well, if needed application can control this using knobs (socket options
etc.,) since these mitigations tend to look like being optional. These
are general purpose TCP mitigations and anyone can chose to turn these
on by default in their TCP stacks.=20

Thanks for your review.

-Anantha
>=20
> --Sandy
>=20
> >
> >> -----Original Message-----
> >> From: Sandra Murphy [mailto:sandy@sparta.com]
> >> Sent: Monday, June 08, 2009 6:59 AM
> >> To: Anantha Ramaiah (ananth); Mitesh Dalal (mdalal)
> >> Cc: iesg@ietf.org; secdir@ietf.org
> >> Subject: draft-ietf-tcpm-tcpsecure
> >>
> >> I've been on the road, so this is just a quick note to say that I=20
> >> still have questions, with a promise of more full answer=20
> when I get=20
> >> back to the office tomorrow.  All the following done really from=20
> >> memory from a re-review yesterday.
> >>  Just  so you know I haven't forgotten you.
> >>
> >> About quoting text:
> >>
> >> The example you point to of what each mitigation says is a=20
> good case.
> >> (what is "rg"?)
> >>
> >> You posit a case 1 and case 2.  This is a summary of what=20
> 793 says,=20
> >> not a quote.  793 spreads the discussion over 2 pages.
> >> your case 1 is represented in a parenthetical remark in an=20
> >> "otherwise" clause - hard to find.  And you have a typo in the=20
> >> inequality.  And the case 2 in 793 is broken out over=20
> three different=20
> >> groupings of states.  Do you mean the new ACK to be=20
> generated in all=20
> >> three state groups?
> >
> > Are you talking about RST/SYN mitigations ? If so the=20
> current text is=20
> > clear. The challenge ACK will be generated, pl note that=20
> the document=20
> > quotes the processing rules of the incoming segment and talks what=20
> > mods are suggested.
> >
> >>
> >> About the stingency.
> >>
> >> If UNA is 1000, Max.snd.wnd is 50, and the ack is 975,=20
> then in 793,=20
> >> the ack is < UNA and so "it is ignored", in your draft the=20
> ack is >=20
> >> UNA-max.snd.wnd so it is acceptable.
> >
> > Ok, I have added more text to clarify this point. "Ignored"
> > means the ACK value is ignored and the segment is processed=20
> as per the=20
> > other rules, hence ignored implies "accepted" and not dropped.
> >
> >>
> >> So your draft accepts more ACKs that 793.
> >>
> >> Have I lost my ability to tell > from <?  Do you regard accepting=20
> >> more ACKS as "more stringent"?
> >
> > No, I think it is a mis-interpreation of ignored.
> >
> >>
> >> About the guidance to implementors.
> >>
> >> It still looks to me like this guidance is only useful to=20
> >> implementors who are implementing both the OS TCP stack *AND* the=20
> >> application.  I.E., freebsd won't know whether this to follow the=20
> >> guidance or not but cisco/juniper/etc will.
> >
> > Not sure why such an inference is made.
> >
> >>
> >> What is the "AS"?
> > Applicability statement (but I couldn't find the AS=20
> reference in the=20
> > draft, it is spelled out in full) ?
> >
> > -Anantha
> >>
> >> About grammar checks:
> >>
> >> And you did not miss email, I lost my marked up copy, so=20
> I've  gone=20
> >> through for the grammar check again (don't think I found all that=20
> >> many
> >> nits) and will send to you.
> >>
> >> --Sandy
> >>
> >>
> >>
> >
>=20

From ananth@cisco.com  Mon Sep 14 08:39:13 2009
Return-Path: <ananth@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099003A682C; Mon, 14 Sep 2009 08:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.513
X-Spam-Level: 
X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsUO4cA79KmS; Mon, 14 Sep 2009 08:39:12 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2E61E3A68DE; Mon, 14 Sep 2009 08:39:12 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEALAArkqrR7O6/2dsb2JhbADFYYhMASsIjhIFgkAIgVA
X-IronPort-AV: E=Sophos;i="4.44,384,1249257600"; d="scan'208";a="189401771"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2009 15:39:57 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8EFdvFw006712;  Mon, 14 Sep 2009 08:39:57 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8EFdvvL016572; Mon, 14 Sep 2009 15:39:57 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 14 Sep 2009 08:39:56 -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
Date: Mon, 14 Sep 2009 08:39:55 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5807FF03B6@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <39808C30-0418-4B70-ABE3-124354C09FBE@nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-tcpm-tcpsecure
Thread-Index: Acowo1FQ+ORSKbETR9i2FLadBL9qugDwJy2Q
References: <Pine.WNT.4.64.0906080948290.6048@SANDYM-LT.columbia.ads.sparta.com> <03C04ACE-5773-4260-AABD-E799E614C469@nokia.com> <E63E6749-FD14-4F50-8351-0F1A48B50EB7@nokia.com> <0C53DCFB700D144284A584F54711EC5807CEEA50@xmb-sjc-21c.amer.cisco.com> <39808C30-0418-4B70-ABE3-124354C09FBE@nokia.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Lars Eggert" <lars.eggert@nokia.com>
X-OriginalArrivalTime: 14 Sep 2009 15:39:56.0770 (UTC) FILETIME=[9C7F6C20:01CA3551]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1258; t=1252942797; x=1253806797; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20draft-ietf-tcpm-tcpsecure |Sender:=20; bh=HDw1sZK6QbeGMVLemx35qI5c9tAGQrGTbfSAXLbsRQw=; b=g9v1XFvTgLPE0BCV2UaeE+KzfKLEw7c2UOdIy49WZi9qZljsoOKLDml7Xe UsC9iJLgpf9fce8K347cJgvJQ+XCw6v9oQLwUjF8OTe0SVsvNeghTbsaetJT 7lHiZPU8oG;
Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: secdir@ietf.org, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, IESG IESG <iesg@ietf.org>
Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2009 15:39:13 -0000

Lars,
    I have submitted the next revision incorporating all the agreed upon
comments that have been received so far.
    I have checked all the comments received and have made the ones
which are agreed upon. Briefly :
 - new template=20
- No IPR disclsoures on IETF documents, the RFC editor would do what is
needed. Brian clarified this.
- Addressed the last call comments by Brian Carpenter.
- Fernando's Last call comments agreed upon (added references to RFC
1948 and port randomization).=20
- Sandra Murphy's comments whichever has been agreed upon.

Thanks,
-Anantha

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com]=20
> Sent: Tuesday, September 08, 2009 9:42 AM
> To: Anantha Ramaiah (ananth)
> Cc: Sandra Murphy; Mitesh Dalal (mdalal); IESG IESG; secdir@ietf.org
> Subject: Re: draft-ietf-tcpm-tcpsecure
>=20
> Hi, authors,
>=20
> please prepare and submit a revision based on the feedback=20
> you have received until now. We need to move forward with=20
> this document.
>=20
> Sandy hasn't responded since June 8. Take the initial=20
> feedback you have gotten from her into account, but I think=20
> it is unreasonable to wait longer for any additional feedback.
>=20
> Lars


From Fred.L.Templin@boeing.com  Mon Sep 14 09:25:17 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C533D28C18F; Mon, 14 Sep 2009 09:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.968
X-Spam-Level: 
X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.631,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9GsyEZJ0joV; Mon, 14 Sep 2009 09:25:17 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id AF82528C18A; Mon, 14 Sep 2009 09:25:13 -0700 (PDT)
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
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" <Fred.L.Templin@boeing.com>
To: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
X-OriginalArrivalTime: 14 Sep 2009 16:25:52.0179 (UTC) FILETIME=[06D97830:01CA3558]
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2009 16:25:17 -0000

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 brian.e.carpenter@gmail.com  Mon Sep 14 21:02:13 2009
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8643A68A0; Mon, 14 Sep 2009 21:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4uE6CuCgKNY; Mon, 14 Sep 2009 21:02:12 -0700 (PDT)
Received: from mail-pz0-f172.google.com (mail-pz0-f172.google.com [209.85.222.172]) by core3.amsl.com (Postfix) with ESMTP id 5555E3A683F; Mon, 14 Sep 2009 21:02:12 -0700 (PDT)
Received: by pzk2 with SMTP id 2so3089468pzk.19 for <multiple recipients>; 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 <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@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><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
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 04:02:13 -0000

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 hesham@elevatemobile.com  Mon Sep 14 22:50:23 2009
Return-Path: <hesham@elevatemobile.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C335C28C0E4; Mon, 14 Sep 2009 22:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Level: 
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfR85tvDLX+j; Mon, 14 Sep 2009 22:50:23 -0700 (PDT)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id D902328C0DF; Mon, 14 Sep 2009 22:50:21 -0700 (PDT)
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
From: Hesham Soliman <hesham@elevatemobile.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <C6D56852.F4CD%hesham@elevatemobile.com>
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
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 05:50:23 -0000

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 Fred.L.Templin@boeing.com  Tue Sep 15 08:33:27 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEBF3A6B3B; Tue, 15 Sep 2009 08:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.972
X-Spam-Level: 
X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.627,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59G9Iwi68CZC; Tue, 15 Sep 2009 08:33:26 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 562EB3A698F; Tue, 15 Sep 2009 08:33:26 -0700 (PDT)
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
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" <Fred.L.Templin@boeing.com>
To: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
X-OriginalArrivalTime: 15 Sep 2009 15:34:02.0856 (UTC) FILETIME=[F3F62E80:01CA3619]
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 15:33:27 -0000

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 Fred.L.Templin@boeing.com  Tue Sep 15 08:37:10 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543753A6B48; Tue, 15 Sep 2009 08:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.982
X-Spam-Level: 
X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.617,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFxLvJjK+F6M; Tue, 15 Sep 2009 08:37:09 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id AF2A43A6B57; Tue, 15 Sep 2009 08:37:03 -0700 (PDT)
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
Date: Tue, 15 Sep 2009 08:37:34 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10665CEC7@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <C6D56852.F4CD%hesham@elevatemobile.com>
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> <C6D56852.F4CD%hesham@elevatemobile.com>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Hesham Soliman" <hesham@elevatemobile.com>, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
X-OriginalArrivalTime: 15 Sep 2009 15:37:35.0485 (UTC) FILETIME=[72B2CAD0:01CA361A]
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 15:37:10 -0000

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 Fred.L.Templin@boeing.com  Tue Sep 15 08:49:43 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0351A3A67FC; Tue, 15 Sep 2009 08:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.978
X-Spam-Level: 
X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=0.621,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzW9FN35G391; Tue, 15 Sep 2009 08:49:42 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 181C73A6BBE; Tue, 15 Sep 2009 08:49:42 -0700 (PDT)
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
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" <Fred.L.Templin@boeing.com>
To: "Dong Zhang" <zhangdong_rh@huaweisymantec.com>, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
X-OriginalArrivalTime: 15 Sep 2009 15:48:54.0264 (UTC) FILETIME=[07483F80:01CA361C]
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 15:49:43 -0000

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 secdir-bounces@mit.edu  Tue Sep 15 11:00:28 2009
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB99A3A6A7E for <secdir@core3.amsl.com>; Tue, 15 Sep 2009 11:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.999
X-Spam-Level: 
X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, 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 3FBnokfQ8ZCD for <secdir@core3.amsl.com>; Tue, 15 Sep 2009 11:00:27 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 9AF2D28C15A for <secdir@ietf.org>; Tue, 15 Sep 2009 11:00:25 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8FI1ARr008169 for <secdir@ietf.org>; Tue, 15 Sep 2009 14:01:10 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8FI18j1008163 for <secdir@PCH.mit.edu>; Tue, 15 Sep 2009 14:01:08 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8FI0uTC015766 for <secdir@mit.edu>; Tue, 15 Sep 2009 14:00:57 -0400 (EDT)
Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 087C41F3C9AA for <secdir@mit.edu>; Tue, 15 Sep 2009 14:00:55 -0400 (EDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id GEfFVXtAUBXQYK5H for <secdir@mit.edu>; Tue, 15 Sep 2009 14:00:55 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org;
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740A828C19C; Tue, 15 Sep 2009 11:00:05 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 88FD928C172; Tue, 15 Sep 2009 11:00:01 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20090915180001.88FD928C172@core3.amsl.com>
Date: Tue, 15 Sep 2009 11:00:01 -0700 (PDT)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Tue, 15 Sep 2009 11:01:30 -0700
Subject: [secdir] [New-work] WG Review: Recharter of IP Flow Information	Export	(ipfix)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 18:00:29 -0000

A modified charter has been submitted for the IP Flow Information Export
(ipfix) working group in the Operations and Management Area of the IETF. 
The IESG has not made any determination as yet.  The modified charter is
provided below for informational purposes only.  Please send your comments
to the IESG mailing list (iesg@ietf.org) by Tuesday, September 22, 2009

IP Flow Information Export (ipfix)
--------------------------------------------
Current Status: Active Working Group

Last Modified: 2009-09-01

Chair(s):

* Nevil Brownlee (n.brownlee@auckland.ac.nz)
* Juergen Quittek (quittek@netlab.nec.de)

Operations and Management Area Director(s):

* Dan Romascanu (dromasca@avaya.com)
* Ronald Bonica (rbonica@juniper.net)

Operations and Management Area Advisor:

* Dan Romascanu (dromasca@avaya.com)

Mailing Lists:
General Discussion: ipfix@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix
Archive: http://www.ietf.org/mail-archive/web/ipfix

Description of Working Group:

The IPFIX working group has specified the Information Model (to 
describe IP flows) and the IPFIX protocol (to transfer IP flow data 
from IPFIX exporters to collectors). Several implementers have already 
built applications using the IPFIX protocol. As a result of a series of 
IPFIX interoperability testing events the WG has produced guidelines 
for IPFIX implementation and testing as well as recommendations for 
handling special cases such as bidirectional flow reporting and 
reducing redundancy in flow records.

Practical experiences with IPFIX implementations exposed new
requirements for the IPFIX protocol that so far have not been addressed
by the WG. The major current goal of the WG is developing solutions 
that meet the new requirements without modifying the core IPFIX 
protocol specifications.

1. The IPFIX WG has developed a MIB module for monitoring IPFIX
implementations. Means for configuring these devices have not been
standardized yet. The WG will develop an XML-based configuration data
model that can be used for configuring IPFIX devices and for storing,
modifying and managing IPFIX configurations parameter sets. This work
will be performed in close collaboration with the NETCONF WG.

2. First applications of IPFIX at large operator networks showed the
need for mediation of flow information, for example, for aggregating
huge amounts of flow data and for anomymization of flow information.
The IPFIX WG will investigate this issue and produce a problem 
Statement and a framework for IPFIX flow mediation.

3. The PSAMP WG has developed a protocol for reporting observed 
packets. The PSAMP protocol is an extension of the IPFIX protocol. The 
IPFIX WG will develop a MIB module for monitoring PSAMP 
implementations. The new MIB module will be an extension of the IPFIX 
MIB module.

4. Anonymization of flow information has been identified as a
requirement for flow information export already in RFC 3917. However,
technologies for flow anonymization are still a research issue and have
so far not been considered to be mature enough for standardization.
As one step in this direction, the IPFIX WG will develop guidelines for
the implementation of anonymized data export and storage over IPFIX and
define an information model for configuring and reporting anonymization
applied at IPFIX devices.

5. The IPFIX and PSAMP WGs have defined standards for selecting 
observed IP packets and collecting information in flow records.
In order to reduce the amount of data to be processed, packet selection
methods have been defined. Another method for reducing flow data is 
flow selection. The IPFIX WG will define methods for flow selection and
provide an information model for configuring and reporting flow
selection applied at IPFIX devices.

6. Being designed for the export of flow records the IPFIX protocol
provides very limited means for structuring information elements within
IPFIX records. With the increasing number of IPFIX applications there 
is a need for exporting more complex information. The IPFIX WG will 
develop an extension of the IPFIX protocol that supports hierarchically
structured data and lists (sequences) of Information Elements in data
records.

Goals and Milestones:

Oct 2009 Submit Mediation Problem Statement I-D to IESG
for publication as Informational RFC
Oct 2009 Submit initial draft on anonymization support
Oct 2009 Submit initial draft on flow selection
Oct 2009 Submit initial draft on structuring information elements
Jan 2010 Submit Configuration Data Model draft to IESG
for publication as Standards track RFC
Jan 2010 Submit Mediation Framework I-D to IESG
for publication as Informational RFC
Jan 2010 Submit final version of PSAMP MIB module
Jun 2010 Submit anonymization support I-D to IESG
for publication as Experimental RFC
Jun 2010 Submit flow selection I-D to IESG
for publication as Standards Track RFC
Jun 2010 Submit structuring information elements I-D to IESG
for publication as Standards Track RFC
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir

From secdir-bounces@mit.edu  Tue Sep 15 11:00:30 2009
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3E63A6A82 for <secdir@core3.amsl.com>; Tue, 15 Sep 2009 11:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.299
X-Spam-Level: 
X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 yMiVDcpcPDrA for <secdir@core3.amsl.com>; Tue, 15 Sep 2009 11:00:29 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id BCCE03A6842 for <secdir@ietf.org>; Tue, 15 Sep 2009 11:00:28 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8FI1GFm008182 for <secdir@ietf.org>; Tue, 15 Sep 2009 14:01:16 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8FI1DlU008176 for <secdir@PCH.mit.edu>; Tue, 15 Sep 2009 14:01:13 -0400
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n8FI0wZ2010254 for <secdir@mit.edu>; Tue, 15 Sep 2009 14:00:59 -0400 (EDT)
Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id D6CA2258B946 for <secdir@mit.edu>; Tue, 15 Sep 2009 14:00:53 -0400 (EDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id 6oI7W3sUuS2tDhPi for <secdir@mit.edu>; Tue, 15 Sep 2009 14:00:53 -0400 (EDT)
X-Barracuda-Envelope-From: new-work-bounces@ietf.org
Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org;
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C05B28C183; Tue, 15 Sep 2009 11:00:04 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 81DDB28C15A; Tue, 15 Sep 2009 11:00:01 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20090915180001.81DDB28C15A@core3.amsl.com>
Date: Tue, 15 Sep 2009 11:00:01 -0700 (PDT)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Tue, 15 Sep 2009 11:01:30 -0700
Subject: [secdir] [New-work] WG Review: Recharter of Network Endpoint	Assessment (nea)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 18:00:30 -0000

A modified charter has been submitted for the Network Endpoint Assessment
(nea) working group in the Security Area of the IETF.  The IESG has not
made any determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list (iesg@ietf.org) by Tuesday, September 22, 2009.

Network Endpoint Assessment (nea)
------------------------------------------------------------
Last Modified: 2009-08-24

Additional information is available at tools.ietf.org/wg/nea
Chair(s):

    * Stephen Hanna (shanna@juniper.net)
    * Susan Thomson (sethomso@cisco.com)

Security Area Director(s):

    * Tim Polk (tim.polk@nist.gov)
    * Pasi Eronen (pasi.eronen@nokia.com)

Security Area Advisor:

    * Tim Polk (tim.polk@nist.gov)

Mailing Lists:
General Discussion: nea@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/nea
Archive: http://www.ietf.org/mail-archive/web/nea

Description of Working Group:

Network Endpoint Assessment (NEA) architectures have been implemented
in the industry to assess the "posture" of endpoint devices for the
purposes of monitoring compliance to an organization's posture policy
and optionally restricting access until the endpoint has been updated
to satisfy the posture requirements. An endpoint that does not comply
with posture policy may be vulnerable to a number of known threats 
that may exist on the network. The intent of NEA is to facilitate 
corrective actions to address these known vulnerabilities before a 
host is exposed to potential attack. Note that an endpoint that is 
deemed compliant may still be vulnerable to threats that may exist on 
the network. The network may thus continue to be exposed to such 
threats as well as the range of other threats not addressed by 
maintaining endpoint compliance.

Posture refers to the hardware or software configuration of an endpoint
as it pertains to an organization's security policy. Posture may
include knowledge that software installed to protect the machine (e.g.
patch management software, anti-virus software, host firewall software,
host intrusion protection software or any custom software) is enabled
and up-to-date. An endpoint supporting NEA protocols can be queried for
posture information.

An organization may make a range of policy decisions based on the
posture of an endpoint. NEA is not intended to be prescriptive in this
regard. Supported deployment scenarios will include, but are not
limited to, providing normal access regardless of compliance result
along with any recommendations for remediation ("advisory mode"), as
well as providing restricted access sufficient for remediation purposes
and any essential services until an endpoint is in compliance
("mandatory mode"). Specifying mechanisms for providing restricted
access is outside the scope of the NEA WG.

Since NEA involves many different components from different vendors,
interoperability is important. The NEA working group will
develop standard protocols at the following three  layers in the 
architecture: the Posture Attribute protocol (PA),  the Posture Broker 
protocol (PB), and the Posture Transport protocol (PT). PA and PB will 
be  designed to support a variety of PT protocols. Together,  PA, PB 
and the mandatory to implement PT protocols will allow interoperability 
between an NEA Client from one vendor and an NEA Server from another.

Since there are already several non-standard protocols at these
layers, the NEA working group will consider these existing protocols as
candidates for the standard protocols. A requirements document will be
written and used as a basis for evaluating the candidate protocols. The
working group may decide to standardize one of the candidate protocols,
use one of them as a basis for a new or revised protocol, or decide
that a new protocol is needed.

The NEA Requirements document will include a problem statement,
definition of terms, requirements for the PA and PB protocols, and an
overall security analysis. It will also include generic requirements
for the protocol transporting PA, PB: the Posture Transport protocol
(PT).

The PA (Posture Attribute) protocol consists of posture attributes that
are carried between a particular Posture Collector in a NEA client and
a particular Posture Validator in a NEA Server. The PA protocol is
carried inside the PB protocol. A base set of standard posture
attributes will be specified that are expected to address many common
posture policies. Vendor-specific attributes will also be supported;
vendor-specific attributes will be identified by a private enterprise
number and a vendor assigned value. Vendors are strongly encouraged to
document vendor-specific attributes in an RFC. The NEA WG will
investigate the use of a standard syntax for all attributes.

The PB (Posture Broker) protocol aggregates posture attributes from one
or more Posture Collectors in an NEA client and sends them to the NEA
server for assessment by one or more Posture Validators.

The PT (Posture Transport) protocol carries the PB protocol. The 
expectation is that the PT protocol is a shim protocol that defines an 
encapsulation of PB within an existing standard transport protocol. 
Existing standard transport protocols will be leveraged to the extent 
possible. The NEA WG may specify more than one PT to meet the 
requirements of different deployment scenarios. The NEA WG will specify 
at least one mandatory to implement PT protocol. PT protocol 
specifications must describe any limitations that they impose on PB and 
PA (e.g. half duplex).

One commonly discussed issue with NEA systems is how to handle
compromised endpoints, whose reports of their own posture may not be
accurate. Detecting or handling such endpoints is out of scope of the
NEA WG. Work on PA will focus on attributes useful for assessing
posture of those endpoints reporting accurate information. However, the
protocols developed by the NEA WG must be designed to accommodate
emerging technologies for identifying and dealing with lying endpoints.

Note that NEA is not chartered to develop standard protocols for
remediation. NEA is intended to be used with new or existing tools that
can be used in the absence of NEA. NEA is applicable to computing
enterprise environments, where endpoints accessing the enterprise's
network are owned and/or expected to conform to the policies set forth
by the organization that owns and operates the network. All other
cases are outside the scope of the NEA charter, since we do not know
that NEA would be useful in such cases. NEA applicability and security
considerations will be described in the appropriate NEA documents.

Further work in the NEA WG will be considered via the rechartering
process after the completion of these milestones.


Milestones

Done      At IETF 67, discuss issues with NEA Requirements I-D
Done      Submit first draft of NEA Requirements I-D
Done      At IETF 68, resolve any open issues with requirements I-D
Done      Submit revised NEA requirements I-D
Done      Discuss NEA Requirements I-D
Done      Submit revised NEA requirements I-D
Done      WGLC on NEA requirements I-D
Done      At IETF 69, resolve any remaining issues raised at Last Call
Done      Submit revised NEA requirements I-D
Done      Submit NEA Requirements I-D to the IESG for IETF Last Call as 
           Informational RFC
Done      Submit revised NEA requirements I-D
Done      Proposals for PA and PB due
Done      Review and resolve proposals at IETF 71
Done      Post first WG version of PA and PB
Done      Post second version of PA and PB
Done      Resolve issues at IETF 72
Done      Post third version of PA and PB
Done      WGLC on PA and PB
Done      Resolve WGLC comments at IETF 73
Done      Post fourth version of PA and PB
Done      IETF LC for PA and PB
Done      IESG considers PA and PB for Proposed Standard
Sep 2009  Call for proposals for the PT protocol(s)
Oct 2009  Proposals due
Nov 2009  Review PT protocol proposals at IETF 76
          Decide how to resolve differences and issues
Dec 2009  Post first WG version of PT protocol(s)
Jan 2010  Review and resolve issues
Feb 2010  Post second WG version of PT protocol(s)
Mar 2010  WG Last Call on PT protocol(s)
          Resolve issues from WG Last Call at IETF 77
Apr 2010  Post third WG version of PT protocol(s)
May 2010  Submit PT protocol(s) to IESG
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir

From secdir-bounces@mit.edu  Tue Sep 15 11:16:27 2009
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365DD3A6BF2 for <secdir@core3.amsl.com>; Tue, 15 Sep 2009 11:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.949
X-Spam-Level: 
X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 utmlTaQwoB2E for <secdir@core3.amsl.com>; Tue, 15 Sep 2009 11:16:26 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D292E3A6BEE for <secdir@ietf.org>; Tue, 15 Sep 2009 11:16:25 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8FIHDme011574 for <secdir@ietf.org>; Tue, 15 Sep 2009 14:17:13 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8FIH8aK011558 for <secdir@PCH.mit.edu>; Tue, 15 Sep 2009 14:17:08 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n8FIGsDU001763 for <secdir@mit.edu>; Tue, 15 Sep 2009 14:16:55 -0400 (EDT)
Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 82A9918832EA for <secdir@mit.edu>; Tue, 15 Sep 2009 14:15:58 -0400 (EDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id bk6SolWTypPzrBna for <secdir@mit.edu>; Tue, 15 Sep 2009 14:15:57 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org;
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED3E3A6BF1; Tue, 15 Sep 2009 11:15:08 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 311273A6A61; Tue, 15 Sep 2009 11:15:01 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20090915181502.311273A6A61@core3.amsl.com>
Date: Tue, 15 Sep 2009 11:15:02 -0700 (PDT)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Tue, 15 Sep 2009 11:23:53 -0700
Subject: [secdir] [New-work] WG Review: Virtual World Region Agent Protocol	(vwrap)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 18:16:27 -0000

A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday,
September 22, 2009

Virtual World Region Agent Protocol (vwrap)
----------------------------------------------------------
Current Status: Proposed Working Group

Last Modified: 2009-09-03

Chairs:

TBD

Area and Area Directors:

Applications Area

Lisa Dusseault <lisa.dusseault@gmail.com>
Alexey Melnikov <alexey.melnikov@isode.com>

Responsible Area Director:

TBD

Mailing List:

ogpx@ietf.org
http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Virtual World Region Agent Protocol
(VWRAP) for a collaborative 3-dimensional virtual environment. The
protocol permits users to interact as digital representations called
"avatars". An avatar exists in at most one location within a shared
virtual space. Conforming client applications use the protocol to
manipulate and move the user's avatar, create virtual objects,
interact with other users and their surroundings, consume and create
media and information from sources inside and outside their simulated
environment.

A virtual space can be partitioned into "regions" to facilitate the
computational and communication load balancing required to simulate
the virtual environment. A region provides the service environment in
which inhabitants and objects can interact. A region uniquely
represents a partition of the virtual space; they are not a mechanism
for load balancing by having multiple instances of the same space.
Different regions may be administered by different organizations. The
state of a virtual world is independent of the client applications
that access it and may persist between user sessions.

Within a VWRAP virtual environment, services may be deployed by
multiple organizations having varying policies and trust domains. The
VWRAP protocol will provide the mechanisms for these services to
interoperate, when permitted by policy. The working group may document
examples of policies applicable to a VWRAP environment.

Foundational components of the protocol include the publication of:

* an abstract type system, suitable for describing the application
protocol in an implementation neutral manner,

* a security model describing trust relationships between
participating entities,

* guidelines for the use of existing authentication and
confidentiality mechanisms,

* an application-layer protocol for establishing the user's avatar
in a region,

* an application-layer protocol for changing an avatar's position,
including moving between regions,

* format descriptions for objects and avatars, and

* an application-layer protocol for identifying entities, and
requesting information about them.

The protocol defined by this group will carry information about the
virtual environment, its contents and its inhabitants. It is an
application layer protocol, independent of transport, based partially
on these previously published internet drafts:

* http://tools.ietf.org/html/draft-hamrick-ogp-intro
* http://tools.ietf.org/html/draft-hamrick-llsd
* http://tools.ietf.org/html/draft-hamrick-ogp-auth
* http://tools.ietf.org/html/draft-hamrick-ogp-launch
* http://tools.ietf.org/html/draft-lentczner-ogp-base
* http://tools.ietf.org/html/draft-levine-ogp-clientcap
* http://tools.ietf.org/html/draft-levine-ogp-layering

The protocol should describe interaction semantics independent of
transport, leveraging existing standards where practical. It should
define interoperability expectations for server to server interactions
as well as client-server interactions. Though the protocol is
independent of transport, early interoperability trials used HTTP(S)
for non-real-time messages. The working group will define specific
features that must be replicated in other transports and will define
the use of HTTP(S) as a transport of protocol messages.

Goals and Milestones:


* February 2010 "Introduction and Goals" to the IESG as an
Informational RFC

* February 2010 "Abstract Type System for the Transmission of
Dynamic Structured Data" to the IESG as Proposed Standard

* June 2010 "Foundational Concepts and Transport Expectations" to
the IESG as Proposed Standard

* June 2010 "Client Application Launch Message" to the IESG as an
Informational RFC

* October 2010 "Trust Model and User Authentication" to the IESG as
Proposed Standard

* October 2010 "Voice and Text Communication Channel Establishment"
to the IESG as Proposed Standard

* February 2011 "Agent Presence Establishment" to the IESG as
Proposed Standard

* February 2011 "Region Description Format" to the IESG as Proposed
Standard

* June 2011 "Digital Asset Access" to the IESG as Proposed Standard

* June 2011 "Primitive Object Format" to the IESG as Proposed
Standard

* October 2011 "Avatar Format" to the IESG as Proposed Standard

* October 2011 "Entity Identifiers" to the IESG as Proposed Standard

* February 2012 "Time Sensitive Messages" to the IESG as Proposed
Standard
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir

From brian.e.carpenter@gmail.com  Tue Sep 15 14:34:26 2009
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C7F3A6ACE; Tue, 15 Sep 2009 14:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.419
X-Spam-Level: 
X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFtDmmrVLG1T; Tue, 15 Sep 2009 14:34:25 -0700 (PDT)
Received: from mail-pz0-f193.google.com (mail-pz0-f193.google.com [209.85.222.193]) by core3.amsl.com (Postfix) with ESMTP id DABE528C1F3; Tue, 15 Sep 2009 14:33:50 -0700 (PDT)
Received: by pzk31 with SMTP id 31so3757999pzk.23 for <multiple recipients>; 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 <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@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><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
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2009 21:34:26 -0000

(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 tena@huawei.com  Tue Sep 15 19:40:34 2009
Return-Path: <tena@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39EED28C11F; Tue, 15 Sep 2009 19:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.237
X-Spam-Level: 
X-Spam-Status: No, score=-98.237 tagged_above=-999 required=5 tests=[AWL=2.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 5jQXS8-QA1Er; Tue, 15 Sep 2009 19:40:32 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4E64228C118; Tue, 15 Sep 2009 19:40:32 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ1003I7M4L86@szxga01-in.huawei.com>; Wed, 16 Sep 2009 10:41:09 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ1002IHM4LA2@szxga01-in.huawei.com>; Wed, 16 Sep 2009 10:41:09 +0800 (CST)
Received: from z24109b ([10.70.39.142]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ1003Q0M4L8A@szxml04-in.huawei.com>; Wed, 16 Sep 2009 10:41:09 +0800 (CST)
Date: Wed, 16 Sep 2009 10:41:08 +0800
From: Tina TSOU <tena@huawei.com>
To: iesg@ietf.org, secdir <secdir@ietf.org>
Message-id: <006801ca3677$25943b00$8e27460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: multipart/alternative; boundary="Boundary_(ID_XWfkaXsoKfeIzi4JDxE8Mw)"
X-Priority: 3
X-MSMail-priority: Normal
References: <4AAE56EF.5080002@ieca.com>
Cc: draft-ietf-syslog-sign-27@tools.ietf.org, syslog-chairs@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-syslog-sign-27
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2009 02:40:34 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_XWfkaXsoKfeIzi4JDxE8Mw)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
  These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.
In general, from the security point of view, this draft does not specify what 
the loghost should do in case of packet loss, DoS attack, etc. Should the 
device try to retrieve the sys log information again? 
 
Section 1, third paragraph (talking about Certificate Block): not to 
over-complicate matters, but this is really talking about the content of a 
Payload Block. Rather than introduce that term, perhaps rephrase the paragraph 
slightly to make clear that multiple Certificate Blocks may be used. What's the key management information here? Is it Certificate information or public key information?

    Additionally, a signer sends Certificate Blocks to provide key
    management information between the signer and the collector.  A
    Certificate Block has a field to denote the type of key material
    which may be such things as a PKIX certificate, an OpenPGP
    certificate, or even an indication that a key had been pre-
    distributed.  In the cases of certificates being sent, the
    certificates may have to be split across multiple Certificate
    Blocks carried in separate messages.

Section 1, fifth paragraph, first sentence: not clear what "previous" refers to. 
The phrase "of the previous messages" doesn't seem to add anything and can be 
dropped. Suggest adding "syslog" after "received" and "corresponding" before 
"Signature Block", so the sentence reads:

    The collector may verify that the hash of
    each received syslog message matches the signed hash contained in the
    corresponding Signature Block.




Section 4.2.3: It is strongly suggested that the field currently identified as 
Signature Group (SG) be renamed to Signature Group Interpretation (SGI) to avoid 
confusion. The statement that SPRI identifies the actual signature group also 
comes a bit late (beginning of the fourth paragraph). It should be moved up to 
the first paragraph.

Note that changing SG to SGI affects the tables in section 4.2 and 5.3.2 and IANA considerations. Note also that the field is called SIG instead of SG in section 5.3.2.3.
In section 5.3.2, P23, what's the main difference between using Signature block and using Certificate block? It seems Certificate Block overlaps with Signature Block, e.g., Both block are digitally signed, why is only certificate block termed "certificate block", why not term certificate block as "signature block"?

In section 5.3.2.9, the point is made that the timestamp of the Certificate 
Block message is the same as that of the Payload Block. In fact, they differ 
very slightly in the example. Is that intended?

In section 6, near the bottom of the first paragraph, a couple of words are 
missing. It is suggested that the sentence be changed to read:

                                                                     The
    collector MUST ignore duplicates of Signature Blocks and Certificate
                          ^^^^^^^^^^^^^^
    Blocks it has already received and authenticated.

Section 7 is informative. Perhaps it belongs in an appendix.
 
In section 7.1, 
 4.  Set the last message number processed to the value of the
           First Message Number plus the Count of the Signature Block
           minus 1.
Why is the Last message number not defined in this document?
 
In section 8.1,
 This specification uses Public Key Cryptography technologies.  The
   proper party or parties have to control the private key portion of a
   public-private key pair.  Any party that controls a private key can
   sign anything it pleases.
 
As regarding the last sentence, Is it appropriate to use "pleases" here? How about using *favors* or *prefers* instead of *pleases*?
 
In section 8.2,
As a signer, it is advisable to avoid message lengths exceeding 2048
   octets.  Various problems might result if a signer were to send
   messages with a length greater than 2048 octets, because relays MAY
   truncate messages with lengths greater than 2048 octets which would
   make it impossible for collectors to validate a hash of the packet.
   To increase the chance of interoperability, it tends to be best to be
   conservative with what you send but liberal in what you are able to
   receive.
 
   From the above paragraph, we can see it is necessary to restrict
   the length of message, So I would like to suggest changing the last
   sentence as:
   "
   To increase the chance of interoperability, it tends to be best to 
   limit the length of what you send but loose what you are able to
   receive.
   "
   to make it more precise. Is it reasonable to do this?
 
 
In section 8.3,
Syslog does not strongly associate the message with the message
   originator.  That association is established by the collector upon
   verification of the Signature Block. 
   
What's the difference between associating the message with the message originator
and signature? If they are the same thing, I think the association should be pre-established
in collector? Is it a correct understanding?
 
 
In section 8.4,
Event messages might be recorded and replayed by an attacker.  Using
   the information contained in the Signature Blocks, a reviewer can
   determine whether the received messages are the ones originally sent
   by an originator.  The reviewer can also identify messages that have
   been replayed.

I am wondering what the information is in the signature block can be used to
prevent replaying? Count or sequence number, time stamp, if there is such thing, it is better to
point it out which field of signature block is used for anti-replaying.
 
 
 
 

B. R.
Tina
http://tinatsou.weebly.com/contact.html




--Boundary_(ID_XWfkaXsoKfeIzi4JDxE8Mw)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.3603" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>I have reviewed this document as part of the security directorate's 
<BR>ongoing effort to review all IETF documents being processed by the IESG. 
<BR>&nbsp; These comments were written primarily for the benefit of the security 
<BR>area directors.&nbsp; Document editors and WG chairs should treat these 
<BR>comments just like any other last call comments.<BR>In general, from the 
security point of view, this draft does not specify what <BR>the loghost should 
do in case of packet loss, DoS attack, etc. Should the <BR>device try to 
retrieve the sys log information again? <BR>&nbsp;<BR>Section 1, third paragraph 
(talking about Certificate Block): not to <BR>over-complicate matters, but this 
is really talking about the content of a <BR>Payload Block. Rather than 
introduce that term, perhaps rephrase the paragraph <BR>slightly to make clear 
that multiple Certificate Blocks may be used. What's the key management 
information here? Is it Certificate information or public key information?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Additionally, a signer sends Certificate Blocks to 
provide key<BR>&nbsp;&nbsp;&nbsp; management information between the signer and 
the collector.&nbsp; A<BR>&nbsp;&nbsp;&nbsp; Certificate Block has a field to 
denote the type of key material<BR>&nbsp;&nbsp;&nbsp; which may be such things 
as a PKIX certificate, an OpenPGP<BR>&nbsp;&nbsp;&nbsp; certificate, or even an 
indication that a key had been pre-<BR>&nbsp;&nbsp;&nbsp; distributed.&nbsp; In 
the cases of certificates being sent, the<BR>&nbsp;&nbsp;&nbsp; certificates may 
have to be split across multiple Certificate<BR>&nbsp;&nbsp;&nbsp; Blocks 
carried in separate messages.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Section 1, fifth paragraph, first sentence: not clear what "previous" 
refers to. <BR>The phrase "of the previous messages" doesn't seem to add 
anything and can be <BR>dropped. Suggest adding "syslog" after "received" and 
"corresponding" before <BR>"Signature Block", so the sentence reads:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; The collector may verify that the hash 
of<BR>&nbsp;&nbsp;&nbsp; each received syslog message matches the signed hash 
contained in the<BR>&nbsp;&nbsp;&nbsp; corresponding Signature Block.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>Section 4.2.3: It is strongly suggested that the field currently 
identified as <BR>Signature Group (SG) be renamed to Signature Group 
Interpretation (SGI) to avoid <BR>confusion. The statement that SPRI identifies 
the actual signature group also <BR>comes a bit late (beginning of the fourth 
paragraph). It should be moved up to <BR>the first paragraph.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Note that changing SG to SGI affects the tables in section 4.2 and 5.3.2 
and IANA considerations. Note also that the field is called SIG instead of SG in 
section 5.3.2.3.<BR>In section 5.3.2, P23, what's the main difference between 
using Signature block and using Certificate block? It seems Certificate Block 
overlaps with Signature Block, e.g., Both block are digitally signed, why is 
only certificate block termed "certificate block", why not term certificate 
block as "signature block"?</DIV>
<DIV>&nbsp;</DIV>
<DIV>In section 5.3.2.9, the point is made that the timestamp of the Certificate 
<BR>Block message is the same as that of the Payload Block. In fact, they differ 
<BR>very slightly in the example. Is that intended?</DIV>
<DIV>&nbsp;</DIV>
<DIV>In section 6, near the bottom of the first paragraph, a couple of words are 
<BR>missing. It is suggested that the sentence be changed to read:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
The<BR>&nbsp;&nbsp;&nbsp; collector MUST ignore duplicates of Signature Blocks 
and 
Certificate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
^^^^^^^^^^^^^^<BR>&nbsp;&nbsp;&nbsp; Blocks it has already received and 
authenticated.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Section 7 is informative. Perhaps it belongs in an 
appendix.<BR>&nbsp;<BR>In section 7.1, <BR>&nbsp;4.&nbsp; Set the last message 
number processed to the value of 
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First 
Message Number plus the Count of the Signature 
Block<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; minus 
1.<BR>Why is the Last message number not defined in this 
document?<BR>&nbsp;<BR>In section 8.1,<BR>&nbsp;This specification uses Public 
Key Cryptography technologies.&nbsp; The<BR>&nbsp;&nbsp; proper party or parties 
have to control the private key portion of a<BR>&nbsp;&nbsp; public-private key 
pair.&nbsp; Any party that controls a private key can<BR>&nbsp;&nbsp; sign 
anything it pleases.<BR>&nbsp;<BR>As regarding the last sentence, Is it 
appropriate to use "pleases" here? How about using *favors* or *prefers* instead 
of *pleases*?<BR>&nbsp;<BR>In section 8.2,<BR>As a signer, it is advisable to 
avoid message lengths exceeding 2048<BR>&nbsp;&nbsp; octets.&nbsp; Various 
problems might result if a signer were to send<BR>&nbsp;&nbsp; messages with a 
length greater than 2048 octets, because relays MAY<BR>&nbsp;&nbsp; truncate 
messages with lengths greater than 2048 octets which would<BR>&nbsp;&nbsp; make 
it impossible for collectors to validate a hash of the packet.<BR>&nbsp;&nbsp; 
To increase the chance of interoperability, it tends to be best to 
be<BR>&nbsp;&nbsp; conservative with what you send but liberal in what you are 
able to<BR>&nbsp;&nbsp; receive.<BR>&nbsp;<BR>&nbsp;&nbsp; From the above 
paragraph, we can see it is necessary to restrict<BR>&nbsp;&nbsp; the length of 
message, So I would like to suggest changing the last<BR>&nbsp;&nbsp; sentence 
as:<BR>&nbsp;&nbsp; "<BR>&nbsp;&nbsp; To increase the chance of 
interoperability, it tends to be best to <BR>&nbsp;&nbsp; limit the length of 
what you send but loose what you are able to<BR>&nbsp;&nbsp; 
receive.<BR>&nbsp;&nbsp; "<BR>&nbsp;&nbsp; to make it more precise. Is it 
reasonable to do this?<BR>&nbsp;<BR>&nbsp;<BR>In section 8.3,<BR>Syslog does not 
strongly associate the message with the message<BR>&nbsp;&nbsp; 
originator.&nbsp; That association is established by the collector 
upon<BR>&nbsp;&nbsp; verification of the Signature Block. <BR>&nbsp;&nbsp; 
<BR>What's the difference between associating the message with the message 
originator<BR>and signature? If they are the same thing, I think the association 
should be pre-established<BR>in collector? Is it a correct 
understanding?<BR>&nbsp;<BR>&nbsp;<BR>In section 8.4,<BR>Event messages might be 
recorded and replayed by an attacker.&nbsp; Using<BR>&nbsp;&nbsp; the 
information contained in the Signature Blocks, a reviewer can<BR>&nbsp;&nbsp; 
determine whether the received messages are the ones originally 
sent<BR>&nbsp;&nbsp; by an originator.&nbsp; The reviewer can also identify 
messages that have<BR>&nbsp;&nbsp; been replayed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am wondering what the information is in the signature block can be used 
to<BR>prevent replaying? Count or sequence number, time stamp, if there is such 
thing, it is better to<BR>point it out which field of signature block is used 
for anti-replaying.<BR>&nbsp;<BR>&nbsp;<BR>&nbsp;<BR>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>B. R.<BR>Tina<BR><A 
href="http://tinatsou.weebly.com/contact.html">http://tinatsou.weebly.com/contact.html</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_XWfkaXsoKfeIzi4JDxE8Mw)--

From tena@huawei.com  Tue Sep 15 20:02:50 2009
Return-Path: <tena@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337643A6A62; Tue, 15 Sep 2009 20:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.288
X-Spam-Level: 
X-Spam-Status: No, score=-98.288 tagged_above=-999 required=5 tests=[AWL=2.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 oxY1TDm1iiJm; Tue, 15 Sep 2009 20:02:48 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F36323A6AC2; Tue, 15 Sep 2009 20:02:47 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ1002O0N5PUL@szxga04-in.huawei.com>; Wed, 16 Sep 2009 11:03:26 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ100AQ5N5PSB@szxga04-in.huawei.com>; Wed, 16 Sep 2009 11:03:25 +0800 (CST)
Received: from z24109b ([10.70.39.142]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ100CXBN5PCE@szxml06-in.huawei.com>; Wed, 16 Sep 2009 11:03:25 +0800 (CST)
Date: Wed, 16 Sep 2009 11:03:25 +0800
From: Tina TSOU <tena@huawei.com>
To: secdir <secdir@ietf.org>, iesg@ietf.org
Message-id: <00a301ca367a$420da160$8e27460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: multipart/alternative; boundary="Boundary_(ID_I281aFgZobLkGPVdFVNNog)"
X-Priority: 3
X-MSMail-priority: Normal
References: <4AAE56EF.5080002@ieca.com> <006801ca3677$25943b00$8e27460a@china.huawei.com>
Cc: draft-ietf-syslog-sign@tools.ietf.org, syslog-chairs@tools.ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-syslog-sign-27
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2009 03:02:50 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_I281aFgZobLkGPVdFVNNog)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Sending to draft-ietf-syslog-sign@tools.ietf.org


B. R.
Tina
http://tinatsou.weebly.com/contact.html

  ----- Original Message ----- 
  From: Tina TSOU 
  To: iesg@ietf.org ; secdir 
  Cc: draft-ietf-syslog-sign-27@tools.ietf.org ; syslog-chairs@tools.ietf.org 
  Sent: Wednesday, September 16, 2009 10:41 AM
  Subject: [secdir] secdir review of draft-ietf-syslog-sign-27


  I have reviewed this document as part of the security directorate's 
  ongoing effort to review all IETF documents being processed by the IESG. 
    These comments were written primarily for the benefit of the security 
  area directors.  Document editors and WG chairs should treat these 
  comments just like any other last call comments.
  In general, from the security point of view, this draft does not specify what 
  the loghost should do in case of packet loss, DoS attack, etc. Should the 
  device try to retrieve the sys log information again? 
   
  Section 1, third paragraph (talking about Certificate Block): not to 
  over-complicate matters, but this is really talking about the content of a 
  Payload Block. Rather than introduce that term, perhaps rephrase the paragraph 
  slightly to make clear that multiple Certificate Blocks may be used. What's the key management information here? Is it Certificate information or public key information?

      Additionally, a signer sends Certificate Blocks to provide key
      management information between the signer and the collector.  A
      Certificate Block has a field to denote the type of key material
      which may be such things as a PKIX certificate, an OpenPGP
      certificate, or even an indication that a key had been pre-
      distributed.  In the cases of certificates being sent, the
      certificates may have to be split across multiple Certificate
      Blocks carried in separate messages.

  Section 1, fifth paragraph, first sentence: not clear what "previous" refers to. 
  The phrase "of the previous messages" doesn't seem to add anything and can be 
  dropped. Suggest adding "syslog" after "received" and "corresponding" before 
  "Signature Block", so the sentence reads:

      The collector may verify that the hash of
      each received syslog message matches the signed hash contained in the
      corresponding Signature Block.




  Section 4.2.3: It is strongly suggested that the field currently identified as 
  Signature Group (SG) be renamed to Signature Group Interpretation (SGI) to avoid 
  confusion. The statement that SPRI identifies the actual signature group also 
  comes a bit late (beginning of the fourth paragraph). It should be moved up to 
  the first paragraph.

  Note that changing SG to SGI affects the tables in section 4.2 and 5.3.2 and IANA considerations. Note also that the field is called SIG instead of SG in section 5.3.2.3.
  In section 5.3.2, P23, what's the main difference between using Signature block and using Certificate block? It seems Certificate Block overlaps with Signature Block, e.g., Both block are digitally signed, why is only certificate block termed "certificate block", why not term certificate block as "signature block"?

  In section 5.3.2.9, the point is made that the timestamp of the Certificate 
  Block message is the same as that of the Payload Block. In fact, they differ 
  very slightly in the example. Is that intended?

  In section 6, near the bottom of the first paragraph, a couple of words are 
  missing. It is suggested that the sentence be changed to read:

                                                                       The
      collector MUST ignore duplicates of Signature Blocks and Certificate
                            ^^^^^^^^^^^^^^
      Blocks it has already received and authenticated.

  Section 7 is informative. Perhaps it belongs in an appendix.
   
  In section 7.1, 
   4.  Set the last message number processed to the value of the
             First Message Number plus the Count of the Signature Block
             minus 1.
  Why is the Last message number not defined in this document?
   
  In section 8.1,
   This specification uses Public Key Cryptography technologies.  The
     proper party or parties have to control the private key portion of a
     public-private key pair.  Any party that controls a private key can
     sign anything it pleases.
   
  As regarding the last sentence, Is it appropriate to use "pleases" here? How about using *favors* or *prefers* instead of *pleases*?
   
  In section 8.2,
  As a signer, it is advisable to avoid message lengths exceeding 2048
     octets.  Various problems might result if a signer were to send
     messages with a length greater than 2048 octets, because relays MAY
     truncate messages with lengths greater than 2048 octets which would
     make it impossible for collectors to validate a hash of the packet.
     To increase the chance of interoperability, it tends to be best to be
     conservative with what you send but liberal in what you are able to
     receive.
   
     From the above paragraph, we can see it is necessary to restrict
     the length of message, So I would like to suggest changing the last
     sentence as:
     "
     To increase the chance of interoperability, it tends to be best to 
     limit the length of what you send but loose what you are able to
     receive.
     "
     to make it more precise. Is it reasonable to do this?
   
   
  In section 8.3,
  Syslog does not strongly associate the message with the message
     originator.  That association is established by the collector upon
     verification of the Signature Block. 
     
  What's the difference between associating the message with the message originator
  and signature? If they are the same thing, I think the association should be pre-established
  in collector? Is it a correct understanding?
   
   
  In section 8.4,
  Event messages might be recorded and replayed by an attacker.  Using
     the information contained in the Signature Blocks, a reviewer can
     determine whether the received messages are the ones originally sent
     by an originator.  The reviewer can also identify messages that have
     been replayed.

  I am wondering what the information is in the signature block can be used to
  prevent replaying? Count or sequence number, time stamp, if there is such thing, it is better to
  point it out which field of signature block is used for anti-replaying.
   
   
   
   

  B. R.
  Tina
  http://tinatsou.weebly.com/contact.html






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


  _______________________________________________
  secdir mailing list
  secdir@ietf.org
  https://www.ietf.org/mailman/listinfo/secdir

--Boundary_(ID_I281aFgZobLkGPVdFVNNog)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.3603" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Sending to <A 
href="mailto:draft-ietf-syslog-sign@tools.ietf.org">draft-ietf-syslog-sign@tools.ietf.org</A></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV>B. R.<BR>Tina</DIV>
<DIV><A 
href="http://tinatsou.weebly.com/contact.html">http://tinatsou.weebly.com/contact.html</A><BR></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=tena@huawei.com href="mailto:tena@huawei.com">Tina TSOU</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=iesg@ietf.org 
  href="mailto:iesg@ietf.org">iesg@ietf.org</A> ; <A title=secdir@ietf.org 
  href="mailto:secdir@ietf.org">secdir</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A 
  title=draft-ietf-syslog-sign-27@tools.ietf.org 
  href="mailto:draft-ietf-syslog-sign-27@tools.ietf.org">draft-ietf-syslog-sign-27@tools.ietf.org</A> 
  ; <A title=syslog-chairs@tools.ietf.org 
  href="mailto:syslog-chairs@tools.ietf.org">syslog-chairs@tools.ietf.org</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, September 16, 2009 10:41 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> [secdir] secdir review of 
  draft-ietf-syslog-sign-27</DIV>
  <DIV><BR></DIV>
  <DIV>I have reviewed this document as part of the security directorate's 
  <BR>ongoing effort to review all IETF documents being processed by the IESG. 
  <BR>&nbsp; These comments were written primarily for the benefit of the 
  security <BR>area directors.&nbsp; Document editors and WG chairs should treat 
  these <BR>comments just like any other last call comments.<BR>In general, from 
  the security point of view, this draft does not specify what <BR>the loghost 
  should do in case of packet loss, DoS attack, etc. Should the <BR>device try 
  to retrieve the sys log information again? <BR>&nbsp;<BR>Section 1, third 
  paragraph (talking about Certificate Block): not to <BR>over-complicate 
  matters, but this is really talking about the content of a <BR>Payload Block. 
  Rather than introduce that term, perhaps rephrase the paragraph <BR>slightly 
  to make clear that multiple Certificate Blocks may be used. What's the key 
  management information here? Is it Certificate information or public key 
  information?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; Additionally, a signer sends Certificate Blocks to 
  provide key<BR>&nbsp;&nbsp;&nbsp; management information between the signer 
  and the collector.&nbsp; A<BR>&nbsp;&nbsp;&nbsp; Certificate Block has a field 
  to denote the type of key material<BR>&nbsp;&nbsp;&nbsp; which may be such 
  things as a PKIX certificate, an OpenPGP<BR>&nbsp;&nbsp;&nbsp; certificate, or 
  even an indication that a key had been pre-<BR>&nbsp;&nbsp;&nbsp; 
  distributed.&nbsp; In the cases of certificates being sent, 
  the<BR>&nbsp;&nbsp;&nbsp; certificates may have to be split across multiple 
  Certificate<BR>&nbsp;&nbsp;&nbsp; Blocks carried in separate messages.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Section 1, fifth paragraph, first sentence: not clear what "previous" 
  refers to. <BR>The phrase "of the previous messages" doesn't seem to add 
  anything and can be <BR>dropped. Suggest adding "syslog" after "received" and 
  "corresponding" before <BR>"Signature Block", so the sentence reads:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; The collector may verify that the hash 
  of<BR>&nbsp;&nbsp;&nbsp; each received syslog message matches the signed hash 
  contained in the<BR>&nbsp;&nbsp;&nbsp; corresponding Signature Block.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><BR>Section 4.2.3: It is strongly suggested that the field currently 
  identified as <BR>Signature Group (SG) be renamed to Signature Group 
  Interpretation (SGI) to avoid <BR>confusion. The statement that SPRI 
  identifies the actual signature group also <BR>comes a bit late (beginning of 
  the fourth paragraph). It should be moved up to <BR>the first paragraph.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Note that changing SG to SGI affects the tables in section 4.2 and 5.3.2 
  and IANA considerations. Note also that the field is called SIG instead of SG 
  in section 5.3.2.3.<BR>In section 5.3.2, P23, what's the main difference 
  between using Signature block and using Certificate block? It seems 
  Certificate Block overlaps with Signature Block, e.g., Both block are 
  digitally signed, why is only certificate block termed "certificate block", 
  why not term certificate block as "signature block"?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>In section 5.3.2.9, the point is made that the timestamp of the 
  Certificate <BR>Block message is the same as that of the Payload Block. In 
  fact, they differ <BR>very slightly in the example. Is that intended?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>In section 6, near the bottom of the first paragraph, a couple of words 
  are <BR>missing. It is suggested that the sentence be changed to read:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  The<BR>&nbsp;&nbsp;&nbsp; collector MUST ignore duplicates of Signature Blocks 
  and 
  Certificate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  ^^^^^^^^^^^^^^<BR>&nbsp;&nbsp;&nbsp; Blocks it has already received and 
  authenticated.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Section 7 is informative. Perhaps it belongs in an 
  appendix.<BR>&nbsp;<BR>In section 7.1, <BR>&nbsp;4.&nbsp; Set the last message 
  number processed to the value of 
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First 
  Message Number plus the Count of the Signature 
  Block<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; minus 
  1.<BR>Why is the Last message number not defined in this 
  document?<BR>&nbsp;<BR>In section 8.1,<BR>&nbsp;This specification uses Public 
  Key Cryptography technologies.&nbsp; The<BR>&nbsp;&nbsp; proper party or 
  parties have to control the private key portion of a<BR>&nbsp;&nbsp; 
  public-private key pair.&nbsp; Any party that controls a private key 
  can<BR>&nbsp;&nbsp; sign anything it pleases.<BR>&nbsp;<BR>As regarding the 
  last sentence, Is it appropriate to use "pleases" here? How about using 
  *favors* or *prefers* instead of *pleases*?<BR>&nbsp;<BR>In section 8.2,<BR>As 
  a signer, it is advisable to avoid message lengths exceeding 
  2048<BR>&nbsp;&nbsp; octets.&nbsp; Various problems might result if a signer 
  were to send<BR>&nbsp;&nbsp; messages with a length greater than 2048 octets, 
  because relays MAY<BR>&nbsp;&nbsp; truncate messages with lengths greater than 
  2048 octets which would<BR>&nbsp;&nbsp; make it impossible for collectors to 
  validate a hash of the packet.<BR>&nbsp;&nbsp; To increase the chance of 
  interoperability, it tends to be best to be<BR>&nbsp;&nbsp; conservative with 
  what you send but liberal in what you are able to<BR>&nbsp;&nbsp; 
  receive.<BR>&nbsp;<BR>&nbsp;&nbsp; From the above paragraph, we can see it is 
  necessary to restrict<BR>&nbsp;&nbsp; the length of message, So I would like 
  to suggest changing the last<BR>&nbsp;&nbsp; sentence as:<BR>&nbsp;&nbsp; 
  "<BR>&nbsp;&nbsp; To increase the chance of interoperability, it tends to be 
  best to <BR>&nbsp;&nbsp; limit the length of what you send but loose what you 
  are able to<BR>&nbsp;&nbsp; receive.<BR>&nbsp;&nbsp; "<BR>&nbsp;&nbsp; to make 
  it more precise. Is it reasonable to do this?<BR>&nbsp;<BR>&nbsp;<BR>In 
  section 8.3,<BR>Syslog does not strongly associate the message with the 
  message<BR>&nbsp;&nbsp; originator.&nbsp; That association is established by 
  the collector upon<BR>&nbsp;&nbsp; verification of the Signature Block. 
  <BR>&nbsp;&nbsp; <BR>What's the difference between associating the message 
  with the message originator<BR>and signature? If they are the same thing, I 
  think the association should be pre-established<BR>in collector? Is it a 
  correct understanding?<BR>&nbsp;<BR>&nbsp;<BR>In section 8.4,<BR>Event 
  messages might be recorded and replayed by an attacker.&nbsp; 
  Using<BR>&nbsp;&nbsp; the information contained in the Signature Blocks, a 
  reviewer can<BR>&nbsp;&nbsp; determine whether the received messages are the 
  ones originally sent<BR>&nbsp;&nbsp; by an originator.&nbsp; The reviewer can 
  also identify messages that have<BR>&nbsp;&nbsp; been replayed.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I am wondering what the information is in the signature block can be used 
  to<BR>prevent replaying? Count or sequence number, time stamp, if there is 
  such thing, it is better to<BR>point it out which field of signature block is 
  used for anti-replaying.<BR>&nbsp;<BR>&nbsp;<BR>&nbsp;<BR>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>B. R.<BR>Tina<BR><A 
  href="http://tinatsou.weebly.com/contact.html">http://tinatsou.weebly.com/contact.html</A></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>secdir mailing 
  list<BR>secdir@ietf.org<BR>https://www.ietf.org/mailman/listinfo/secdir<BR></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_I281aFgZobLkGPVdFVNNog)--

From Kurt.Zeilenga@isode.com  Wed Sep 16 02:11:40 2009
Return-Path: <Kurt.Zeilenga@isode.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B983A6AC8; Wed, 16 Sep 2009 02:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx7C6LfMm0jm; Wed, 16 Sep 2009 02:11:40 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DDCE23A6ABA; Wed, 16 Sep 2009 02:11:39 -0700 (PDT)
Received: from [192.168.1.108] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SrCr-wB9YS=o@rufus.isode.com>; Wed, 16 Sep 2009 10:12:27 +0100
X-SMTP-Protocol-Errors: NORDNS
From: Kurt Zeilenga <Kurt.Zeilenga@isode.com>
In-Reply-To: <alpine.BSF.2.00.0909101523400.54991@fledge.watson.org>
Date: Wed, 16 Sep 2009 10:12:25 +0100
Message-Id: <9E513A07-3BE5-4D49-9BD9-211CBF0724CC@isode.com>
References: <alpine.BSF.2.00.0909101523400.54991@fledge.watson.org>
To: draft-ietf-dnsext-dnssec-rsasha256@tools.ietf.org, ajs@shinkuro.com
X-Mailer: Apple Mail (2.1076)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Cc: dnssec-chairs@tools.ietf.org, The IESG <iesg@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: [secdir] SECDIR review: draft-ietf-dnsext-dnssec-rsasha256
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2009 09:11:41 -0000

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG.  These comments were written primarily for the benefit of the  
security area directors.  Document editors and WG chairs should treat  
these comments just like any other last call comments.

This document details how to produce RSA/SHA-512 and RSA/SHA-256  
DNSKEY and RRSIG RRs in DNS.

I find the document more than adequately discusses and addresses  
security considerations.

I do note that the document appears to place an additional  
recommendation upon implementors of DNSSEC (in Section 5.1) yet does  
not "update" any DNSSEC specification.   It may be appropriate for  
this I-D to "update" (upon approval/publication) DNSSEC specifications.

Regards, Kurt


From vincent.roca@inrialpes.fr  Wed Sep 16 02:17:33 2009
Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5823A68DC; Wed, 16 Sep 2009 02:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG+A0Y8z0z0f; Wed, 16 Sep 2009 02:17:33 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 6DEF43A67B5; Wed, 16 Sep 2009 02:17:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,396,1249250400";  d="xml'217?txt'217?scan'217,208,217";a="34386568"
Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2009 11:18:10 +0200
Message-ID: <4AB0AD51.6020400@inrialpes.fr>
Date: Wed, 16 Sep 2009 11:18:09 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "iesg@ietf.org" <iesg@ietf.org>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8012953655E08@il-ex01.ad.checkpoint.com> <4AA7B13F.1090007@inrialpes.fr>
In-Reply-To: <4AA7B13F.1090007@inrialpes.fr>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/mixed; boundary="------------090102000001000200050109"
Cc: "msec-chairs@tools.ietf.org" <msec-chairs@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-msec-tesla-for-alc-norm@tools.ietf.org" <draft-ietf-msec-tesla-for-alc-norm@tools.ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-msec-tesla-for-alc-norm-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2009 09:17:34 -0000

This is a multi-part message in MIME format.
--------------090102000001000200050109
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Dear all,

My colleague, Aurélien, read carefully our new TESLA -08 I-D these
days and found a serious error (plus several minor corrections).

The error concerns section 3.1.2.1. "Principles", where we say:
	"[...] where f_k is the result of the k-th application of the
	PRF function f."
This is of course not the case since k is (in case of HMAC PRF) the
key! So we completely reformulated this section.


We also corrected a few minor things. For instance the keyword "Standard"
was used incorrectly (it's goal up to version 07 was to distinguish the
full authentication tags from the "Compact" ones, but the Compacts tags
have been removed in 08).


So we have prepared version 09 (attached), but did not submit it
using the IETF I-D tool since we don't know if it is appropriate at
this stage of the IESG process. We are awaiting your instructions.


Sorry for this late I-D update.
Cheers,


   Vincent and Aurélien


--------------090102000001000200050109
Content-Type: text/plain;
 name="draft-ietf-msec-tesla-for-alc-norm-09.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-ietf-msec-tesla-for-alc-norm-09.txt"

CgoKTVNFQyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBWLiBSb2NhCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4gRnJhbmNpbGxvbgpJbnRlbmRlZCBzdGF0
dXM6IEV4cGVyaW1lbnRhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFMuIEZh
dXJpdGUKRXhwaXJlczogTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIElOUklBCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAxNiwgMjAwOQoKCiAgICAgICAg
ICAgICAgIFVzZSBvZiBURVNMQSBpbiB0aGUgQUxDIGFuZCBOT1JNIFByb3RvY29scwogICAg
ICAgICAgICAgICAgIGRyYWZ0LWlldGYtbXNlYy10ZXNsYS1mb3ItYWxjLW5vcm0tMDkKClN0
YXR1cyBvZiB0aGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVk
IHRvIElFVEYgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9m
IEJDUCA3OCBhbmQgQkNQIDc5LiAgVGhpcyBkb2N1bWVudCBtYXkgY29udGFpbiBtYXRlcmlh
bAogICBmcm9tIElFVEYgRG9jdW1lbnRzIG9yIElFVEYgQ29udHJpYnV0aW9ucyBwdWJsaXNo
ZWQgb3IgbWFkZSBwdWJsaWNseQogICBhdmFpbGFibGUgYmVmb3JlIE5vdmVtYmVyIDEwLCAy
MDA4LiAgVGhlIHBlcnNvbihzKSBjb250cm9sbGluZyB0aGUKICAgY29weXJpZ2h0IGluIHNv
bWUgb2YgdGhpcyBtYXRlcmlhbCBtYXkgbm90IGhhdmUgZ3JhbnRlZCB0aGUgSUVURgogICBU
cnVzdCB0aGUgcmlnaHQgdG8gYWxsb3cgbW9kaWZpY2F0aW9ucyBvZiBzdWNoIG1hdGVyaWFs
IG91dHNpZGUgdGhlCiAgIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MuICBXaXRob3V0IG9idGFp
bmluZyBhbiBhZGVxdWF0ZSBsaWNlbnNlIGZyb20KICAgdGhlIHBlcnNvbihzKSBjb250cm9s
bGluZyB0aGUgY29weXJpZ2h0IGluIHN1Y2ggbWF0ZXJpYWxzLCB0aGlzCiAgIGRvY3VtZW50
IG1heSBub3QgYmUgbW9kaWZpZWQgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFyZHMgUHJvY2Vz
cywgYW5kCiAgIGRlcml2YXRpdmUgd29ya3Mgb2YgaXQgbWF5IG5vdCBiZSBjcmVhdGVkIG91
dHNpZGUgdGhlIElFVEYgU3RhbmRhcmRzCiAgIFByb2Nlc3MsIGV4Y2VwdCB0byBmb3JtYXQg
aXQgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJGQyBvciB0bwogICB0cmFuc2xhdGUgaXQgaW50
byBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFy
ZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFz
ayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5v
dGUgdGhhdAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRv
Y3VtZW50cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFy
ZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAg
IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBk
b2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJ
bnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl
bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1
cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3
LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgogICBUaGUgbGlzdCBvZiBJbnRl
cm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0
dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBUaGlzIEludGVybmV0LURyYWZ0
IHdpbGwgZXhwaXJlIG9uIE1hcmNoIDIwLCAyMDEwLgoKQ29weXJpZ2h0IE5vdGljZQoKICAg
Q29weXJpZ2h0IChjKSAyMDA5IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp
ZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoK
CgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAg
ICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNM
QSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgVGhpcyBk
b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh
bAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzIGluIGVmZmVjdCBv
biB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50IChodHRwOi8v
dHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pLgogICBQbGVhc2UgcmV2aWV3IHRoZXNl
IGRvY3VtZW50cyBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMKICAg
YW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QgdG8gdGhpcyBkb2N1bWVudC4KCgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClJvY2EsIGV0IGFsLiAg
ICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwLCAyMDEwICAgICAgICAgICAgICAgICBbUGFn
ZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVEVTTEEgaW4gQUxDIGFuZCBOT1JN
ICAgICAgICAgICBTZXB0ZW1iZXIgMjAwOQoKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50
IGRldGFpbHMgdGhlIFRFU0xBIHBhY2tldCBzb3VyY2UgYXV0aGVudGljYXRpb24gYW5kCiAg
IHBhY2tldCBpbnRlZ3JpdHkgdmVyaWZpY2F0aW9uIHByb3RvY29sIGFuZCBpdHMgaW50ZWdy
YXRpb24gd2l0aGluIHRoZQogICBBTEMgYW5kIE5PUk0gY29udGVudCBkZWxpdmVyeSBwcm90
b2NvbHMuICBUaGlzIGRvY3VtZW50IG9ubHkKICAgY29uc2lkZXJzIHRoZSBhdXRoZW50aWNh
dGlvbi9pbnRlZ3JpdHkgdmVyaWZpY2F0aW9uIG9mIHRoZSBwYWNrZXRzCiAgIGdlbmVyYXRl
ZCBieSB0aGUgc2Vzc2lvbidzIHNlbmRlci4gIFRoZSBhdXRoZW50aWNhdGlvbiBhbmQgaW50
ZWdyaXR5CiAgIHZlcmlmaWNhdGlvbiBvZiB0aGUgcGFja2V0cyBzZW50IGJ5IHJlY2VpdmVy
cywgaWYgYW55LCBpcyBvdXQgb2YgdGhlCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgoK
VGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDEuMS4gIFNjb3Bl
IG9mIHRoaXMgRG9jdW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
IDYKICAgICAxLjIuICBDb252ZW50aW9ucyBVc2VkIGluIHRoaXMgRG9jdW1lbnQgIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgMS4zLiAgVGVybWlub2xvZ3kgYW5kIE5vdGF0
aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgICAgMS4zLjEu
ICBOb3RhdGlvbnMgYW5kIERlZmluaXRpb25zIFJlbGF0ZWQgdG8gQ3J5cHRvZ3JhcGhpYwog
ICAgICAgICAgICAgICBGdW5jdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gIDcKICAgICAgIDEuMy4yLiAgTm90YXRpb25zIGFuZCBEZWZpbml0
aW9ucyBSZWxhdGVkIHRvIFRpbWUgIC4gLiAuIC4gLiAuICA4CiAgIDIuICBVc2luZyBURVNM
QSB3aXRoIEFMQyBhbmQgTk9STTogR2VuZXJhbCBPcGVyYXRpb25zICAuIC4gLiAuIC4gLiAx
MAogICAgIDIuMS4gIEFMQyBhbmQgTk9STSBTcGVjaWZpY2l0aWVzIHRoYXQgSW1wYWN0IFRF
U0xBIC4gLiAuIC4gLiAuIC4gMTAKICAgICAyLjIuICBCb290c3RyYXBwaW5nIFRFU0xBICAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgICAyLjIuMS4g
IEJvb3RzdHJhcHBpbmcgVEVTTEEgd2l0aCBhbiBPdXQtT2YtQmFuZCBNZWNoYW5pc20gIC4g
LiAxMQogICAgICAgMi4yLjIuICBCb290c3RyYXBwaW5nIFRFU0xBIHdpdGggYW4gSW4tQmFu
ZCBNZWNoYW5pc20gIC4gLiAuIC4gMTEKICAgICAyLjMuICBTZXR0aW5nIFVwIGEgU2VjdXJl
IFRpbWUgU3luY2hyb25pemF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIDEyCiAgICAgICAyLjMu
MS4gIERpcmVjdCBUaW1lIFN5bmNocm9uaXphdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAxMgogICAgICAgMi4zLjIuICBJbmRpcmVjdCBUaW1lIFN5bmNocm9uaXphdGlvbiAg
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgICAyLjQuICBEZXRlcm1pbmluZyB0aGUg
RGVsYXkgQm91bmRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0CiAgICAgICAy
LjQuMS4gIERlbGF5IEJvdW5kIENhbGN1bGF0aW9uIGluIERpcmVjdCBUaW1lCiAgICAgICAg
ICAgICAgIFN5bmNocm9uaXphdGlvbiBNb2RlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAxNAogICAgICAgMi40LjIuICBEZWxheSBCb3VuZCBDYWxjdWxhdGlvbiBpbiBJ
bmRpcmVjdCB0aW1lCiAgICAgICAgICAgICAgIFN5bmNocm9uaXphdGlvbiBNb2RlIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICAgIDIuNS4gIENyeXB0b2dyYXBo
aWMgcGFyYW1ldGVyIHZhbHVlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAg
My4gIFNlbmRlciBPcGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIDE3CiAgICAgMy4xLiAgVEVTTEEgUGFyYW1ldGVycyAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNwogICAgICAgMy4xLjEuICBUaW1l
IEludGVydmFscyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcK
ICAgICAgIDMuMS4yLiAgS2V5IENoYWlucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIDE3CiAgICAgICAzLjEuMy4gIFRpbWUgSW50ZXJ2YWwgU2NoZWR1
bGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMAogICAgICAgMy4xLjQuICBU
aW1pbmcgUGFyYW1ldGVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
MjEKICAgICAzLjIuICBURVNMQSBTaWduYWxpbmcgTWVzc2FnZXMgLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIDIxCiAgICAgICAzLjIuMS4gIEJvb3RzdHJhcCBJbmZvcm1h
dGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICAgICAgMy4yLjIu
ICBEaXJlY3QgVGltZSBTeW5jaHJvbml6YXRpb24gUmVzcG9uc2UgLiAuIC4gLiAuIC4gLiAu
IC4gMjIKICAgICAzLjMuICBURVNMQSBBdXRoZW50aWNhdGlvbiBJbmZvcm1hdGlvbiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzCiAgICAgICAzLjMuMS4gIEF1dGhlbnRpY2F0aW9u
IFRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMwogICAgICAgMy4z
LjIuICBEaWdpdGFsIFNpZ25hdHVyZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gMjMKICAgICAgIDMuMy4zLiAgR3JvdXAgTUFDIFRhZ3MgLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0CiAgICAgMy40LiAgRm9ybWF0IG9mIFRFU0xB
IE1lc3NhZ2VzIGFuZCBBdXRoZW50aWNhdGlvbiBUYWdzIC4gLiAuIC4gLiAyNgoKCgpSb2Nh
LCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAg
ICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFM
QyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICAgICAgMy40LjEuICBG
b3JtYXQgb2YgYSBCb290c3RyYXAgSW5mb3JtYXRpb24gTWVzc2FnZSAgLiAuIC4gLiAuIC4g
MjYKICAgICAgIDMuNC4yLiAgRm9ybWF0IG9mIGEgRGlyZWN0IFRpbWUgU3luY2hyb25pemF0
aW9uIFJlc3BvbnNlIC4gLiAuIDMyCiAgICAgICAzLjQuMy4gIEZvcm1hdCBvZiBhIFN0YW5k
YXJkIEF1dGhlbnRpY2F0aW9uIFRhZyAgLiAuIC4gLiAuIC4gLiAzMwogICAgICAgMy40LjQu
ICBGb3JtYXQgb2YgYW4gQXV0aGVudGljYXRpb24gVGFnIFdpdGhvdXQgS2V5CiAgICAgICAg
ICAgICAgIERpc2Nsb3N1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAzNAogICAgICAgMy40LjUuICBGb3JtYXQgb2YgYW4gQXV0aGVudGljYXRpb24g
VGFnIHdpdGggYSBgYE5ldyBLZXkKICAgICAgICAgICAgICAgQ2hhaW4nJyBDb21taXRtZW50
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM1CiAgICAgICAzLjQuNi4g
IEZvcm1hdCBvZiBhbiBBdXRoZW50aWNhdGlvbiBUYWcgd2l0aCBhIGBgTGFzdCBLZXkKICAg
ICAgICAgICAgICAgb2YgT2xkIENoYWluJycgRGlzY2xvc3VyZSAgLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIDM2CiAgIDQuICBSZWNlaXZlciBPcGVyYXRpb25zICAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOAogICAgIDQuMS4gIFZlcmlmaWNh
dGlvbiBvZiB0aGUgQXV0aGVudGljYXRpb24gSW5mb3JtYXRpb24gLiAuIC4gLiAuIC4gMzgK
ICAgICAgIDQuMS4xLiAgUHJvY2Vzc2luZyB0aGUgR3JvdXAgTUFDIFRhZyAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIDM4CiAgICAgICA0LjEuMi4gIFByb2Nlc3NpbmcgdGhlIERpZ2l0
YWwgU2lnbmF0dXJlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOAogICAgICAgNC4xLjMuICBQ
cm9jZXNzaW5nIHRoZSBBdXRoZW50aWNhdGlvbiBUYWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4g
MzkKICAgICA0LjIuICBJbml0aWFsaXphdGlvbiBvZiBhIFJlY2VpdmVyIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIDM5CiAgICAgICA0LjIuMS4gIFByb2Nlc3NpbmcgdGhlIEJv
b3RzdHJhcCBJbmZvcm1hdGlvbiBNZXNzYWdlIC4gLiAuIC4gLiAzOQogICAgICAgNC4yLjIu
ICBQZXJmb3JtaW5nIFRpbWUgU3luY2hyb25pemF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gNDAKICAgICA0LjMuICBBdXRoZW50aWNhdGlvbiBvZiBSZWNlaXZlZCBQYWNrZXRzIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQyCiAgICAgICA0LjMuMS4gIERpc2NhcmRpbmcgVW5u
ZWNlc3NhcnkgUGFja2V0cyBFYXJsaWVyIC4gLiAuIC4gLiAuIC4gLiA0NAogICAgIDQuNC4g
IEZsdXNoaW5nIHRoZSBOb24gQXV0aGVudGljYXRlZCBQYWNrZXRzIG9mIGEgUHJldmlvdXMK
ICAgICAgICAgICBLZXkgQ2hhaW4gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIDQ1CiAgIDUuICBJbnRlZ3JhdGlvbiBpbiB0aGUgQUxDIGFuZCBO
T1JNIFByb3RvY29scyAgLiAuIC4gLiAuIC4gLiAuIC4gLiA0NgogICAgIDUuMS4gIEF1dGhl
bnRpY2F0aW9uIEhlYWRlciBFeHRlbnNpb24gRm9ybWF0IC4gLiAuIC4gLiAuIC4gLiAuIC4g
NDYKICAgICA1LjIuICBVc2Ugb2YgQXV0aGVudGljYXRpb24gSGVhZGVyIEV4dGVuc2lvbnMg
IC4gLiAuIC4gLiAuIC4gLiAuIDQ3CiAgICAgICA1LjIuMS4gIEVYVF9BVVRIIEhlYWRlciBF
eHRlbnNpb24gb2YgVHlwZSBCb290c3RyYXAKICAgICAgICAgICAgICAgSW5mb3JtYXRpb24g
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ3CiAgICAgICA1
LjIuMi4gIEVYVF9BVVRIIEhlYWRlciBFeHRlbnNpb24gb2YgVHlwZSBBdXRoZW50aWNhdGlv
bgogICAgICAgICAgICAgICBUYWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gNTAKICAgICAgIDUuMi4zLiAgRVhUX0FVVEggSGVhZGVyIEV4
dGVuc2lvbiBvZiBUeXBlIERpcmVjdCBUaW1lCiAgICAgICAgICAgICAgIFN5bmNocm9uaXph
dGlvbiBSZXF1ZXN0ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MQogICAgICAg
NS4yLjQuICBFWFRfQVVUSCBIZWFkZXIgRXh0ZW5zaW9uIG9mIFR5cGUgRGlyZWN0IFRpbWUK
ICAgICAgICAgICAgICAgU3luY2hyb25pemF0aW9uIFJlc3BvbnNlIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIDUxCiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MwogICAgIDYuMS4gIERlYWxp
bmcgV2l0aCBEb1MgQXR0YWNrcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
NTMKICAgICA2LjIuICBEZWFsaW5nIFdpdGggUmVwbGF5IEF0dGFja3MgIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIDU0CiAgICAgICA2LjIuMS4gIEltcGFjdHMgb2YgUmVwbGF5
IEF0dGFja3Mgb24gVEVTTEEgLiAuIC4gLiAuIC4gLiAuIC4gLiA1NAogICAgICAgNi4yLjIu
ICBJbXBhY3RzIG9mIFJlcGxheSBBdHRhY2tzIG9uIE5PUk0gIC4gLiAuIC4gLiAuIC4gLiAu
IC4gNTUKICAgICAgIDYuMi4zLiAgSW1wYWN0cyBvZiBSZXBsYXkgQXR0YWNrcyBvbiBBTEMg
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU1CiAgICAgNi4zLiAgU2VjdXJpdHkgb2YgdGhlIEJh
Y2sgQ2hhbm5lbCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NgogICA3LiAgSUFO
QSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gNTcKICAgOC4gIEFja25vd2xlZGdtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU5CiAgIDkuICBSZWZlcmVuY2VzIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2MAogICAgIDku
MS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gNjAKICAgICA5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYwCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2MgoKCgoK
CgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAg
ICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xB
IGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgoxLiAgSW50cm9k
dWN0aW9uCgogICBNYW55IGFwcGxpY2F0aW9ucyB1c2luZyBtdWx0aWNhc3QgYW5kIGJyb2Fk
Y2FzdCBjb21tdW5pY2F0aW9ucwogICByZXF1aXJlIHRoYXQgZWFjaCByZWNlaXZlciBiZSBh
YmxlIHRvIGF1dGhlbnRpY2F0ZSB0aGUgc291cmNlIG9mIGFueQogICBwYWNrZXQgaXQgcmVj
ZWl2ZXMgYXMgd2VsbCBhcyB0aGUgaW50ZWdyaXR5IG9mIHRoZXNlIHBhY2tldHMuICBUaGlz
CiAgIGlzIHRoZSBjYXNlIHdpdGggQUxDIFtSTVQtUEktQUxDXSBhbmQgTk9STSBbUk1ULVBJ
LU5PUk1dLCB0d28gQ29udGVudAogICBEZWxpdmVyeSBQcm90b2NvbHMgKENEUCkgZGVzaWdu
ZWQgdG8gdHJhbnNmZXIgcmVsaWFibHkgb2JqZWN0cyAoZS5nLiwKICAgZmlsZXMpIGJldHdl
ZW4gYSBzZXNzaW9uJ3Mgc2VuZGVyIGFuZCBzZXZlcmFsIHJlY2VpdmVycy4gIFRoZSBOT1JN
CiAgIHByb3RvY29sIGlzIGJhc2VkIG9uIGJpZGlyZWN0aW9uYWwgdHJhbnNtaXNzaW9ucy4g
IEVhY2ggcmVjZWl2ZXIKICAgYWNrbm93bGVkZ2VzIGRhdGEgcmVjZWl2ZWQgb3IsIGluIGNh
c2Ugb2YgcGFja2V0IGVyYXN1cmVzLCBhc2tzIGZvcgogICByZXRyYW5zbWlzc2lvbnMuICBP
biB0aGUgb3Bwb3NpdGUsIHRoZSBBTEMgcHJvdG9jb2wgaXMgYmFzZWQgb24KICAgcHVyZWx5
IHVuaWRpcmVjdGlvbmFsIHRyYW5zbWlzc2lvbnMuICBSZWxpYWJpbGl0eSBpcyBhY2hpZXZl
ZCBieQogICBtZWFucyBvZiB0aGUgY3ljbGljIHRyYW5zbWlzc2lvbiBvZiB0aGUgY29udGVu
dCB3aXRoaW4gYSBjYXJvdXNlbAogICBhbmQvb3IgYnkgdGhlIHVzZSBvZiBwcm9hY3RpdmUg
Rm9yd2FyZCBFcnJvciBDb3JyZWN0aW9uIGNvZGVzIChGRUMpLgogICBCb3RoIHByb3RvY29s
cyBoYXZlIGluIGNvbW1vbiB0aGUgZmFjdCB0aGF0IHRoZXkgb3BlcmF0ZSBhdAogICBhcHBs
aWNhdGlvbiBsZXZlbCwgb24gdG9wIG9mIGFuIGVyYXN1cmUgY2hhbm5lbCAoZS5nLiwgdGhl
IEludGVybmV0KQogICB3aGVyZSBwYWNrZXRzIGNhbiBiZSBsb3N0IChlcmFzZWQpIGR1cmlu
ZyB0aGUgdHJhbnNtaXNzaW9uLgoKICAgVGhlIGdvYWwgb2YgdGhpcyBkb2N1bWVudCBpcyB0
byBjb3VudGVyIGF0dGFja3Mgd2hlcmUgYW4gYXR0YWNrZXIKICAgaW1wZXJzb25hdGVzIHRo
ZSBBTEMgb3IgTk9STSBzZXNzaW9uJ3Mgc2VuZGVyIGFuZCBpbmplY3RzIGZvcmdlZAogICBw
YWNrZXRzIHRvIHRoZSByZWNlaXZlcnMsIHRoZXJlYnkgY29ycnVwdGluZyB0aGUgb2JqZWN0
cwogICByZWNvbnN0cnVjdGVkIGJ5IHRoZSByZWNlaXZlcnMuCgogICBQcmV2ZW50aW5nIHRo
aXMgYXR0YWNrIGlzIG11Y2ggbW9yZSBjb21wbGV4IGluIGNhc2Ugb2YgZ3JvdXAKICAgY29t
bXVuaWNhdGlvbnMgdGhhbiBpdCBpcyB3aXRoIHVuaWNhc3QgY29tbXVuaWNhdGlvbnMuICBJ
bmRlZWQsIHdpdGgKICAgdW5pY2FzdCBjb21tdW5pY2F0aW9ucyBhIHNpbXBsZSBzb2x1dGlv
biBleGlzdHM6IHRoZSBzZW5kZXIgYW5kIHRoZQogICByZWNlaXZlciBzaGFyZSBhIHNlY3Jl
dCBrZXkgdG8gY29tcHV0ZSBhIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZQogICAoTUFD
KSBvZiBhbGwgbWVzc2FnZXMgZXhjaGFuZ2VkLiAgVGhpcyBpcyBubyBsb25nZXIgZmVhc2li
bGUgaW4gY2FzZQogICBvZiBtdWx0aWNhc3QgYW5kIGJyb2FkY2FzdCBjb21tdW5pY2F0aW9u
cyBzaW5jZSBzaGFyaW5nIGEgZ3JvdXAga2V5CiAgIGJldHdlZW4gdGhlIHNlbmRlciBhbmQg
YWxsIHJlY2VpdmVycyBpbXBsaWVzIHRoYXQgYW55IGdyb3VwIG1lbWJlcgogICBjYW4gaW1w
ZXJzb25hdGUgdGhlIHNlbmRlciBhbmQgc2VuZCBmb3JnZWQgbWVzc2FnZXMgdG8gb3RoZXIK
ICAgcmVjZWl2ZXJzLgoKICAgVGhlIHVzdWFsIHNvbHV0aW9uIHRvIHByb3ZpZGUgdGhlIHNv
dXJjZSBhdXRoZW50aWNhdGlvbiBhbmQgbWVzc2FnZQogICBpbnRlZ3JpdHkgc2VydmljZXMg
aW4gY2FzZSBvZiBtdWx0aWNhc3QgYW5kIGJyb2FkY2FzdCBjb21tdW5pY2F0aW9ucwogICBj
b25zaXN0cyBpbiByZWx5aW5nIG9uIGFzeW1tZXRyaWMgY3J5cHRvZ3JhcGh5IGFuZCB1c2lu
ZyBkaWdpdGFsCiAgIHNpZ25hdHVyZXMuICBZZXQgdGhpcyBzb2x1dGlvbiBpcyBsaW1pdGVk
IGJ5IGhpZ2ggY29tcHV0YXRpb25hbCBjb3N0cwogICBhbmQgaGlnaCB0cmFuc21pc3Npb24g
b3ZlcmhlYWRzLiAgVGhlIFRpbWVkIEVmZmljaWVudCBTdHJlYW0gTG9zcy0KICAgdG9sZXJh
bnQgQXV0aGVudGljYXRpb24gcHJvdG9jb2wgKFRFU0xBKSBpcyBhbiBhbHRlcm5hdGl2ZSBz
b2x1dGlvbgogICB0aGF0IHByb3ZpZGVzIHRoZSB0d28gcmVxdWlyZWQgc2VydmljZXMsIHdo
aWxlIGJlaW5nIGNvbXBhdGlibGUgd2l0aAogICBoaWdoIHJhdGUgdHJhbnNtaXNzaW9ucyBv
dmVyIGxvc3N5IGNoYW5uZWxzLgoKICAgVGhpcyBkb2N1bWVudCBleHBsYWlucyBob3cgdG8g
aW50ZWdyYXRlIHRoZSBURVNMQSBzb3VyY2UKICAgYXV0aGVudGljYXRpb24gYW5kIHBhY2tl
dCBpbnRlZ3JpdHkgcHJvdG9jb2wgdG8gdGhlIEFMQyBhbmQgTk9STSBDRFAuCiAgIEFueSBh
cHBsaWNhdGlvbiBidWlsdCBvbiB0b3Agb2YgQUxDIGFuZCBOT1JNIHdpbGwgZGlyZWN0bHkg
YmVuZWZpdAogICBmcm9tIHRoZSBzZXJ2aWNlcyBvZmZlcmVkIGJ5IFRFU0xBIGF0IHRoZSB0
cmFuc3BvcnQgbGF5ZXIuICBJbgogICBwYXJ0aWN1bGFyLCB0aGlzIGlzIHRoZSBjYXNlIG9m
IEZMVVRFLgoKCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAs
IDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg
ICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoK
ICAgRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gdGhlIFRFU0xBIHByb3RvY29sIGFuZCBpdHMg
cHJpbmNpcGxlcywgcGxlYXNlCiAgIHJlZmVyIHRvIFtSRkM0MDgyXVtQZXJyaWcwNF0uICBG
b3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBBTEMgYW5kIE5PUk0sCiAgIHBsZWFzZSByZWZlciB0
byBbUk1ULVBJLUFMQ10sIFtSTVQtQkItTENUXSBhbmQgW1JNVC1QSS1OT1JNXQogICByZXNw
ZWN0aXZlbHkuICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBGTFVURSwgcGxlYXNlIHJlZmVy
IHRvCiAgIFtSTVQtRkxVVEVdLgoKMS4xLiAgU2NvcGUgb2YgdGhpcyBEb2N1bWVudAoKICAg
VGhpcyBzcGVjaWZpY2F0aW9uIG9ubHkgY29uc2lkZXJzIHRoZSBhdXRoZW50aWNhdGlvbiBh
bmQgaW50ZWdyaXR5CiAgIHZlcmlmaWNhdGlvbiBvZiB0aGUgcGFja2V0cyBnZW5lcmF0ZWQg
YnkgdGhlIHNlc3Npb24ncyBzZW5kZXIuICBUaGlzCiAgIHNwZWNpZmljYXRpb24gZG9lcyBu
b3QgY29uc2lkZXIgdGhlIHBhY2tldHMgdGhhdCBtYXkgYmUgc2VudCBieQogICByZWNlaXZl
cnMsIGZvciBpbnN0YW5jZSBOT1JNJ3MgZmVlZGJhY2sgcGFja2V0cy4gIFtSTVQtU0lNUExF
LUFVVEhdCiAgIGRlc2NyaWJlcyBzZXZlcmFsIHRlY2huaXF1ZXMgdGhhdCBjYW4gYmUgdXNl
ZCB0byB0aGF0IHB1cnBvc2UuICBTaW5jZQogICB0aGlzIGlzIHVzdWFsbHkgYSBsb3ctcmF0
ZSBmbG93ICh1bmxpa2UgdGhlIGRvd25zdHJlYW0gZmxvdyksIHVzaW5nCiAgIGNvbXB1dGlu
ZyBpbnRlbnNpdmUgdGVjaG5pcXVlcyBsaWtlIGRpZ2l0YWwgc2lnbmF0dXJlcywgcG9zc2li
bHkKICAgY29tYmluZWQgd2l0aCBhIEdyb3VwIE1BQyBzY2hlbWUsIGlzIG9mdGVuIGFjY2Vw
dGFibGUuICBGaW5hbGx5LCB0aGUKICAgU2VjdGlvbiA1IGV4cGxhaW5zIGhvdyB0byB1c2Ug
c2V2ZXJhbCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGluIGEKICAgZ2l2ZW4gc2Vzc2lvbiB0
aGFua3MgdG8gdGhlIEFTSUQgKEF1dGhlbnRpY2F0aW9uIFNjaGVtZSBJRGVudGlmaWVyKQog
ICBmaWVsZC4KCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiByZWxpZXMgb24gc2V2ZXJhbCBleHRl
cm5hbCBtZWNoYW5pc21zLCBmb3IKICAgaW5zdGFuY2U6CgogICBvICB0byBjb21tdW5pY2F0
ZSBzZWN1cmVseSB0aGUgcHVibGljIGtleSBvciBhIGNlcnRpZmljYXRlIGZvciB0aGUKICAg
ICAgc2Vzc2lvbidzIHNlbmRlciAoU2VjdGlvbiAyLjIuMik7CgogICBvICB0byBjb21tdW5p
Y2F0ZSBzZWN1cmVseSBhbmQgY29uZmlkZW50aWFsbHkgdGhlIGdyb3VwIGtleSwgS19nLAog
ICAgICB1c2VkIGJ5IHRoZSBHcm91cCBNQUMgZmVhdHVyZSwgd2hlbiBhcHBsaWNhYmxlIChT
ZWN0aW9uIDMuMy4zKS4KICAgICAgSW4gc29tZSBzaXR1YXRpb25zLCB0aGlzIGdyb3VwIGtl
eSB3aWxsIGhhdmUgdG8gYmUgcGVyaW9kaWNhbGx5CiAgICAgIHJlZnJlc2hlZDsKCiAgIG8g
IHRvIHBlcmZvcm0gc2VjdXJlIHRpbWUgc3luY2hyb25pemF0aW9uIGluIGluZGlyZWN0IG1v
ZGUKICAgICAgKFNlY3Rpb24gMi4zLjIpIG9yIGluIGRpcmVjdCBtb2RlIChTZWN0aW9uIDIu
My4xKSB0byBjYXJyeSB0aGUKICAgICAgcmVxdWVzdC9yZXNwb25zZSBtZXNzYWdlcyB3aXRo
IEFMQyB3aGljaCBpcyBwdXJlbHkgdW5pZGlyZWN0aW9uYWw7CgogICBUaGVzZSBtZWNoYW5p
c21zIGFyZSByZXF1aXJlZCBpbiBvcmRlciB0byBib290c3RyYXAgVEVTTEEgYXQgYSBzZW5k
ZXIKICAgYW5kIGF0IGEgcmVjZWl2ZXIgYW5kIG11c3QgYmUgZGVwbG95ZWQgaW4gcGFyYWxs
ZWwgdG8gVEVTTEEuCiAgIEJlc2lkZXMsIHRoZSByYW5kb21uZXNzIG9mIHRoZSBQcmltYXJ5
IEtleSBvZiB0aGUga2V5IGNoYWluCiAgIChTZWN0aW9uIDMuMS4yKSBpcyB2aXRhbCB0byB0
aGUgc2VjdXJpdHkgb2YgVEVTTEEuICBUaGVyZWZvcmUgdGhlCiAgIHNlbmRlciBuZWVkcyBh
biBhcHByb3ByaWF0ZSBtZWNoYW5pc20gdG8gZ2VuZXJhdGUgdGhpcyByYW5kb20ga2V5LgoK
ICAgU2V2ZXJhbCB0ZWNobmljYWwgZGV0YWlscyBvZiBURVNMQSwgbGlrZSB0aGUgbW9zdCBh
cHByb3ByaWF0ZSB3YXkgdG8KICAgYWx0ZXJuYXRlIGJldHdlZW4gdGhlIHRyYW5zbWlzc2lv
biBvZiBhIGtleSBkaXNjbG9zdXJlIGFuZCBhCiAgIGNvbW1pdG1lbnQgdG8gYSBuZXcga2V5
IGNoYWluLCBvciB0aGUgdHJhbnNtaXNzaW9uIG9mIGEga2V5CiAgIGRpc2Nsb3N1cmUgYW5k
IHRoZSBsYXN0IGtleSBvZiB0aGUgcHJldmlvdXMga2V5IGNoYWluLCBvciB0aGUKICAgZGlz
Y2xvc3VyZSBvZiBhIGtleSBhbmQgdGhlIGNvbXBhY3QgZmxhdm9yIHRoYXQgZG9lcyBub3Qg
ZGlzY2xvc2UgYW55CiAgIGtleSwgYXJlIHNwZWNpZmljIHRvIHRoZSB0YXJnZXQgdXNlLWNh
c2UgKFNlY3Rpb24gMy4xLjIpLiAgRm9yCiAgIGluc3RhbmNlLCBpdCBkZXBlbmRzIG9uIHRo
ZSBudW1iZXIgb2YgcGFja2V0cyBzZW50IHBlciB0aW1lIGludGVydmFsLAoKCgpSb2NhLCBl
dCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAg
ICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBh
bmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICBvbiB0aGUgZGVzaXJlZCBy
b2J1c3RuZXNzIGFuZCB0aGUgYWNjZXB0YWJsZSB0cmFuc21pc3Npb24gb3ZlcmhlYWQsCiAg
IHdoaWNoIGNhbiBvbmx5IGJlIG9wdGltaXplZCBhZnRlciB0YWtpbmcgaW50byBhY2NvdW50
IHRoZSB1c2UtY2FzZQogICBzcGVjaWZpY2l0aWVzLgoKMS4yLiAgQ29udmVudGlvbnMgVXNl
ZCBpbiB0aGlzIERvY3VtZW50CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U
IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hP
VUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlz
CiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JG
QzIxMTldLgoKMS4zLiAgVGVybWlub2xvZ3kgYW5kIE5vdGF0aW9ucwoKICAgVGhlIGZvbGxv
d2luZyBub3RhdGlvbnMgYW5kIGRlZmluaXRpb25zIGFyZSB1c2VkIHRocm91Z2hvdXQgdGhp
cwogICBkb2N1bWVudC4KCjEuMy4xLiAgTm90YXRpb25zIGFuZCBEZWZpbml0aW9ucyBSZWxh
dGVkIHRvIENyeXB0b2dyYXBoaWMgRnVuY3Rpb25zCgogICBOb3RhdGlvbnMgYW5kIGRlZmlu
aXRpb25zIHJlbGF0ZWQgdG8gY3J5cHRvZ3JhcGhpYyBmdW5jdGlvbnMKICAgW1JGQzQwODJd
W1JGQzQzODNdOgoKICAgbyAgUFJGIGlzIHRoZSBQc2V1ZG8gUmFuZG9tIEZ1bmN0aW9uOwoK
ICAgbyAgTUFDIGlzIHRoZSBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGU7CgogICBvICBI
TUFDIGlzIHRoZSBrZXllZC1IYXNoIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZTsKCiAg
IG8gIEYgaXMgdGhlIG9uZS13YXkgZnVuY3Rpb24gdXNlZCB0byBjcmVhdGUgdGhlIGtleSBj
aGFpbgogICAgICAoU2VjdGlvbiAzLjEuMi4xKTsKCiAgIG8gIEYnIGlzIHRoZSBvbmUtd2F5
IGZ1bmN0aW9uIHVzZWQgdG8gZGVyaXZlIHRoZSBITUFDIGtleXMKICAgICAgKFNlY3Rpb24g
My4xLjIuMSk7CgogICBvICBuX3AgaXMgdGhlIGxlbmd0aCwgaW4gYml0cywgb2YgdGhlIEYg
ZnVuY3Rpb24ncyBvdXRwdXQuICBUaGlzIGlzCiAgICAgIHRoZXJlZm9yZSB0aGUgbGVuZ3Ro
IG9mIHRoZSBrZXlzIGluIHRoZSBrZXkgY2hhaW47CgogICBvICBuX2YgaXMgdGhlIGxlbmd0
aCwgaW4gYml0cywgb2YgdGhlIEYnIGZ1bmN0aW9uJ3Mgb3V0cHV0LiAgVGhpcyBpcwogICAg
ICB0aGVyZWZvcmUgdGhlIGxlbmd0aCBvZiB0aGUgSE1BQyBrZXlzOwoKICAgbyAgbl9tIGlz
IHRoZSBsZW5ndGgsIGluIGJpdHMsIG9mIHRoZSB0cnVuY2F0ZWQgb3V0cHV0IG9mIHRoZSBN
QUMKICAgICAgW1JGQzIxMDRdLiAgT25seSB0aGUgbl9tIG1vc3Qgc2lnbmlmaWNhbnQgYml0
cyBvZiB0aGUgTUFDIG91dHB1dAogICAgICBhcmUga2VwdDsKCiAgIG8gIE4gaXMgdGhlIGxl
bmd0aCBvZiBhIGtleSBjaGFpbi4gIFRoZXJlIGFyZSBOKzEga2V5cyBpbiBhIGtleQogICAg
ICBjaGFpbjogS18wLCBLXzEsIC4uICBLX04uIFdoZW4gc2V2ZXJhbCBjaGFpbnMgYXJlIHVz
ZWQsIGFsbCB0aGUKICAgICAgY2hhaW5zIE1VU1QgaGF2ZSB0aGUgc2FtZSBsZW5ndGggYW5k
IGtleXMgYXJlIG51bWJlcmVkCiAgICAgIGNvbnNlY3V0aXZlbHksIGZvbGxvd2luZyB0aGUg
dGltZSBpbnRlcnZhbCBudW1iZXJpbmc7CgoKCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAg
IEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50
ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAg
IFNlcHRlbWJlciAyMDA5CgoKICAgbyAgbl9jIGlzIHRoZSBudW1iZXIgb2Yga2V5cyBpbiBh
IGtleSBjaGFpbi4gIFRoZXJlZm9yZTogbl9jID0gTisxOwoKICAgbyAgbl90eF9sYXN0a2V5
IGlzIHRoZSBudW1iZXIgb2YgYWRkaXRpb25hbCBpbnRlcnZhbHMgZHVyaW5nIHdoaWNoCiAg
ICAgIHRoZSBsYXN0IGtleSBvZiB0aGUgb2xkIGtleSBjaGFpbiBTSE9VTEQgYmUgc2VudCwg
YWZ0ZXIgc3dpdGNoaW5nCiAgICAgIHRvIGEgbmV3IGtleSBjaGFpbiBhbmQgYWZ0ZXIgd2Fp
dGluZyBmb3IgdGhlIGRpc2Nsb3N1cmUgZGVsYXkgZC4KICAgICAgVGhlc2UgZXh0cmEgdHJh
bnNtaXNzaW9ucyB0YWtlIHBsYWNlIGFmdGVyIHRoZSBpbnRlcnZhbCBkdXJpbmcKICAgICAg
d2hpY2ggdGhlIGxhc3Qga2V5IGlzIG5vcm1hbGx5IGRpc2Nsb3NlZC4gIFRoZSBuX3R4X2xh
c3RrZXkgdmFsdWUKICAgICAgaXMgZWl0aGVyIDAgKG5vIGV4dHJhIGRpc2Nsb3N1cmUpIG9y
IGxhcmdlci4gIFRoaXMgcGFyYW1ldGVyIGlzCiAgICAgIHNlbmRlciBzcGVjaWZpYyBhbmQg
aXMgbm90IGNvbW11bmljYXRlZCB0byB0aGUgcmVjZWl2ZXI7CgogICBvICBuX3R4X25ld2tj
YyBpcyB0aGUgbnVtYmVyIG9mIGludGVydmFscyBkdXJpbmcgd2hpY2ggdGhlIGNvbW1pdG1l
bnQKICAgICAgdG8gYSBuZXcga2V5IGNoYWluIFNIT1VMRCBiZSBzZW50LCBiZWZvcmUgc3dp
dGNoaW5nIHRvIHRoZSBuZXcga2V5CiAgICAgIGNoYWluLiAgVGhlIG5fdHhfbmV3a2NjIHZh
bHVlIGlzIGVpdGhlciAwIChubyBjb21taXRtZW50IHNlbnQKICAgICAgd2l0aGluIGF1dGhl
bnRpY2F0aW9uIHRhZ3MpIG9yIGxhcmdlci4gIFRoaXMgcGFyYW1ldGVyIGlzIHNlbmRlcgog
ICAgICBzcGVjaWZpYyBhbmQgaXMgbm90IGNvbW11bmljYXRlZCB0byB0aGUgcmVjZWl2ZXI7
CgogICBvICBLX2cgaXMgYSBzaGFyZWQgZ3JvdXAga2V5LCBjb21tdW5pY2F0ZWQgdG8gYWxs
IGdyb3VwIG1lbWJlcnMsCiAgICAgIGNvbmZpZGVudGlhbGx5LCBkdXJpbmcgdGhlIFRFU0xB
IGJvb3RzdHJhcHBpbmcgKFNlY3Rpb24gMi4yKTsKCiAgIG8gIG5fdyBpcyB0aGUgbGVuZ3Ro
LCBpbiBiaXRzLCBvZiB0aGUgdHJ1bmNhdGVkIG91dHB1dCBvZiB0aGUgTUFDIG9mCiAgICAg
IHRoZSBvcHRpb25hbCBncm91cCBhdXRoZW50aWNhdGlvbiBzY2hlbWU6IG9ubHkgdGhlIG5f
dyBtb3N0CiAgICAgIHNpZ25pZmljYW50IGJpdHMgb2YgdGhlIE1BQyBvdXRwdXQgYXJlIGtl
cHQuIG5fdyBpcyB0eXBpY2FsbHkKICAgICAgc21hbGwsIG11bHRpcGxlIG9mIDMyIGJpdHMg
KGUuZy4sIDMyIGJpdHMpOwoKMS4zLjIuICBOb3RhdGlvbnMgYW5kIERlZmluaXRpb25zIFJl
bGF0ZWQgdG8gVGltZQoKICAgTm90YXRpb25zIGFuZCBkZWZpbml0aW9ucyByZWxhdGVkIHRv
IHRpbWU6CgogICBvICBpIGlzIHRoZSB0aW1lIGludGVydmFsIGluZGV4LiAgSW50ZXJ2YWwg
bnVtYmVyaW5nIHN0YXJ0cyBhdCAwIGFuZAogICAgICBpbmNyZWFzZXMgY29uc2VjdXRpdmVs
eS4gIFNpbmNlIHRoZSBpbnRlcnZhbCBpbmRleCBpcyBzdG9yZWQgYXMgYQogICAgICAzMiBi
aXQgdW5zaWduZWQgaW50ZWdlciwgd3JhcHBpbmcgdG8gMCBtaWdodCB0YWtlIHBsYWNlIGlu
IGxvbmcKICAgICAgc2Vzc2lvbnMuCgogICBvICB0X3MgaXMgdGhlIHNlbmRlciBsb2NhbCB0
aW1lIHZhbHVlIGF0IHNvbWUgYWJzb2x1dGUgdGltZSAoaW4gTlRQCiAgICAgIHRpbWVzdGFt
cCBmb3JtYXQpOwoKICAgbyAgdF9yIGlzIHRoZSByZWNlaXZlciBsb2NhbCB0aW1lIHZhbHVl
IGF0IHRoZSBzYW1lIGFic29sdXRlIHRpbWUgKGluCiAgICAgIE5UUCB0aW1lc3RhbXAgZm9y
bWF0KTsKCiAgIG8gIFRfMCBpcyB0aGUgc3RhcnQgdGltZSBjb3JyZXNwb25kaW5nIHRvIHRo
ZSBiZWdpbm5pbmcgb2YgdGhlCiAgICAgIHNlc3Npb24sIGkuZS4sIHRoZSBiZWdpbm5pbmcg
b2YgdGltZSBpbnRlcnZhbCAwIChpbiBOVFAgdGltZXN0YW1wCiAgICAgIGZvcm1hdCk7Cgog
ICBvICBUX2ludCBpcyB0aGUgaW50ZXJ2YWwgZHVyYXRpb24gKGluIG1pbGxpc2Vjb25kcyk7
CgogICBvICBkIGlzIHRoZSBrZXkgZGlzY2xvc3VyZSBkZWxheSAoaW4gbnVtYmVyIG9mIGlu
dGVydmFscyk7CgoKCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2gg
MjAsIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAg
ICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5
CgoKICAgbyAgRF90IGlzIHRoZSB1cHBlciBib3VuZCBvZiB0aGUgbGFnIG9mIHRoZSByZWNl
aXZlcidzIGNsb2NrIHdpdGgKICAgICAgcmVzcGVjdCB0byB0aGUgY2xvY2sgb2YgdGhlIHNl
bmRlcjsKCiAgIG8gIFNfc3IgaXMgYW4gZXN0aW1hdGVkIGJvdW5kIG9mIHRoZSBjbG9jayBk
cmlmdCBiZXR3ZWVuIHRoZSBzZW5kZXIKICAgICAgYW5kIGEgcmVjZWl2ZXIgdGhyb3VnaG91
dCB0aGUgZHVyYXRpb24gb2YgdGhlIHNlc3Npb247CgogICBvICBEXk9fdCBpcyB0aGUgdXBw
ZXIgYm91bmQgb2YgdGhlIGxhZyBvZiB0aGUgc2VuZGVyJ3MgY2xvY2sgd2l0aAogICAgICBy
ZXNwZWN0IHRvIHRoZSB0aW1lIHJlZmVyZW5jZSBpbiBpbmRpcmVjdCB0aW1lIHN5bmNocm9u
aXphdGlvbgogICAgICBtb2RlOwoKICAgbyAgRF5SX3QgaXMgdGhlIHVwcGVyIGJvdW5kIG9m
IHRoZSBsYWcgb2YgdGhlIHJlY2VpdmVyJ3MgY2xvY2sgd2l0aAogICAgICByZXNwZWN0IHRv
IHRoZSB0aW1lIHJlZmVyZW5jZSBpbiBpbmRpcmVjdCB0aW1lIHN5bmNocm9uaXphdGlvbgog
ICAgICBtb2RlOwoKICAgbyAgRF9lcnIgaXMgYW4gdXBwZXIgYm91bmQgb2YgdGhlIHRpbWUg
ZXJyb3IgYmV0d2VlbiBhbGwgdGhlIHRpbWUKICAgICAgcmVmZXJlbmNlcywgaW4gaW5kaXJl
Y3QgdGltZSBzeW5jaHJvbml6YXRpb24gbW9kZTsKCiAgIG8gIE5UUCB0aW1lc3RhbXAgZm9y
bWF0IGNvbnNpc3RzIGluIGEgNjQtYml0IHVuc2lnbmVkIGZpeGVkLXBvaW50CiAgICAgIG51
bWJlciwgaW4gc2Vjb25kcyByZWxhdGl2ZSB0byAwaCBvbiAxIEphbnVhcnkgMTkwMC4gIFRo
ZSBpbnRlZ2VyCiAgICAgIHBhcnQgaXMgaW4gdGhlIGZpcnN0IDMyIGJpdHMgYW5kIHRoZSBm
cmFjdGlvbiBwYXJ0IGluIHRoZSBsYXN0IDMyCiAgICAgIGJpdHMgW1JGQzEzMDVdOwoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhw
aXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5l
dC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2Vw
dGVtYmVyIDIwMDkKCgoyLiAgVXNpbmcgVEVTTEEgd2l0aCBBTEMgYW5kIE5PUk06IEdlbmVy
YWwgT3BlcmF0aW9ucwoKMi4xLiAgQUxDIGFuZCBOT1JNIFNwZWNpZmljaXRpZXMgdGhhdCBJ
bXBhY3QgVEVTTEEKCiAgIFRoZSBBTEMgYW5kIE5PUk0gcHJvdG9jb2xzIGhhdmUgZmVhdHVy
ZXMgYW5kIHJlcXVpcmVtZW50cyB0aGF0CiAgIGxhcmdlbHkgaW1wYWN0IHRoZSB3YXkgVEVT
TEEgY2FuIGJlIHVzZWQuCgogICBJbiBjYXNlIG9mIEFMQzoKCiAgIG8gIEFMQyBpcyBtYXNz
aXZlbHkgc2NhbGFibGU6IG5vdGhpbmcgaW4gdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24K
ICAgICAgbGltaXRzIHRoZSBudW1iZXIgb2YgcmVjZWl2ZXJzIHRoYXQgam9pbiBhIHNlc3Np
b24uICBUaGVyZWZvcmUgYW4KICAgICAgQUxDIHNlc3Npb24gcG90ZW50aWFsbHkgaW5jbHVk
ZXMgYSBodWdlIG51bWJlciAoZS5nLiwgbWlsbGlvbnMgb3IKICAgICAgbW9yZSkgb2YgcmVj
ZWl2ZXJzOwoKICAgbyAgQUxDIGNhbiB3b3JrIG9uIHRvcCBvZiBwdXJlbHkgdW5pZGlyZWN0
aW9uYWwgdHJhbnNwb3J0IGNoYW5uZWxzOgogICAgICB0aGlzIGlzIG9uZSBvZiB0aGUgYXNz
ZXRzIG9mIEFMQywgYW5kIGV4YW1wbGVzIG9mIHVuaWRpcmVjdGlvbmFsCiAgICAgIGNoYW5u
ZWxzIGluY2x1ZGUgc2F0ZWxsaXRlIChldmVuIGlmIGEgYmFjayBjaGFubmVsIG1pZ2h0IGV4
aXN0IGluCiAgICAgIHNvbWUgdXNlIGNhc2VzKSBhbmQgYnJvYWRjYXN0aW5nIG5ldHdvcmtz
IGxpa2UgRFZCLUgvU0g7CgogICBvICBBTEMgZGVmaW5lcyBhbiBvbi1kZW1hbmQgY29udGVu
dCBkZWxpdmVyeSBtb2RlbCBbUk1ULVBJLUFMQ10gd2hlcmUKICAgICAgcmVjZWl2ZXJzIGNh
biBhcnJpdmUgYXQgYW55IHRpbWUsIGF0IHRoZWlyIG93biBkaXNjcmV0aW9uLAogICAgICBk
b3dubG9hZCB0aGUgY29udGVudCBhbmQgbGVhdmUgdGhlIHNlc3Npb24uICBPdGhlciBtb2Rl
bHMgKGUuZy4sCiAgICAgIHB1c2ggb3Igc3RyZWFtaW5nKSBhcmUgYWxzbyBkZWZpbmVkOwoK
ICAgbyAgQUxDIHNlc3Npb25zIGFyZSBwb3RlbnRpYWxseSB2ZXJ5IGxvbmc6IGEgc2Vzc2lv
biBjYW4gbGFzdCBzZXZlcmFsCiAgICAgIGRheXMgb3IgbW9udGhzIGR1cmluZyB3aGljaCB0
aGUgY29udGVudCBpcyBjb250aW51b3VzbHkKICAgICAgdHJhbnNtaXR0ZWQgd2l0aGluIGEg
Y2Fyb3VzZWwuICBUaGUgY29udGVudCBjYW4gYmUgZWl0aGVyIHN0YXRpYwogICAgICAoZS5n
LiwgYSBzb2Z0d2FyZSB1cGRhdGUpIG9yIGR5bmFtaWMgKGUuZy4sIGEgd2ViIHNpdGUpLgoK
ICAgRGVwZW5kaW5nIG9uIHRoZSB1c2UgY2FzZSwgc29tZSBvZiB0aGUgYWJvdmUgZmVhdHVy
ZXMgbWF5IG5vdCBhcHBseS4KICAgRm9yIGluc3RhbmNlIEFMQyBjYW4gYWxzbyBiZSB1c2Vk
IG92ZXIgYSBiaWRpcmVjdGlvbmFsIGNoYW5uZWwgb3IKICAgd2l0aCBhIGxpbWl0ZWQgbnVt
YmVyIG9mIHJlY2VpdmVycy4KCiAgIEluIGNhc2Ugb2YgTk9STToKCiAgIG8gIE5PUk0gaGFz
IGJlZW4gZGVzaWduZWQgZm9yIG1lZGl1bSBzaXplIHNlc3Npb25zOiBpbmRlZWQsIE5PUk0K
ICAgICAgcmVsaWVzIG9uIGZlZWRiYWNrIG1lc3NhZ2VzIGFuZCB0aGUgc2VuZGVyIG1heSBj
b2xsYXBzZSBpZiB0aGUKICAgICAgZmVlZGJhY2sgbWVzc2FnZSByYXRlIGlzIHRvbyBoaWdo
OwoKICAgbyAgTk9STSByZXF1aXJlcyBhIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IGNoYW5u
ZWw6IHRoZSBiYWNrIGNoYW5uZWwKICAgICAgaXMgbm90IG5lY2Vzc2FyaWx5IGEgaGlnaCBk
YXRhIHJhdGUgY2hhbm5lbCBzaW5jZSB0aGUgY29udHJvbAogICAgICB0cmFmZmljIHNlbnQg
b3ZlciBpdCBieSBhIHNpbmdsZSByZWNlaXZlciBpcyBhbiBvcmRlciBvZiBtYWduaXR1ZGUK
ICAgICAgbG93ZXIgdGhhbiB0aGUgZG93bnN0cmVhbSB0cmFmZmljLiAgTmV0d29ya3Mgd2l0
aCBhbiBhc3ltbWV0cmljCiAgICAgIGNvbm5lY3Rpdml0eSAoZS5nLiwgYSBoaWdoIHJhdGUg
c2F0ZWxsaXRlIGRvd25saW5rIGFuZCBhIGxvdy1yYXRlCiAgICAgIFJUQyBiYXNlZCByZXR1
cm4gY2hhbm5lbCkgYXJlIGFwcHJvcHJpYXRlOwoKCgoKCgpSb2NhLCBldCBhbC4gICAgICAg
ICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAxMF0K
DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAg
ICAgICAgU2VwdGVtYmVyIDIwMDkKCgoyLjIuICBCb290c3RyYXBwaW5nIFRFU0xBCgogICBJ
biBvcmRlciB0byBpbml0aWFsaXplIHRoZSBURVNMQSBjb21wb25lbnQgYXQgYSByZWNlaXZl
ciwgdGhlIHNlbmRlcgogICBNVVNUIGNvbW11bmljYXRlIHNvbWUga2V5IGluZm9ybWF0aW9u
IGluIGEgc2VjdXJlIHdheSwgc28gdGhhdCB0aGUKICAgcmVjZWl2ZXIgY2FuIGNoZWNrIHRo
ZSBzb3VyY2Ugb2YgdGhlIGluZm9ybWF0aW9uIGFuZCBpdHMgaW50ZWdyaXR5LgogICBUd28g
Z2VuZXJhbCBtZXRob2RzIGFyZSBwb3NzaWJsZToKCiAgIG8gIGJ5IHVzaW5nIGFuIG91dC1v
Zi1iYW5kIG1lY2hhbmlzbSwgb3IKCiAgIG8gIGJ5IHVzaW5nIGFuIGluLWJhbmQgbWVjaGFu
aXNtLgoKICAgVGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCByZWNvbW1lbmQg
YW55IG1lY2hhbmlzbSB0bwogICBib290c3RyYXAgVEVTTEEuICBDaG9vc2luZyBiZXR3ZWVu
IGFuIGluLWJhbmQgYW5kIG91dC1vZi1iYW5kIHNjaGVtZQogICBpcyBsZWZ0IHRvIHRoZSBp
bXBsZW1lbnRlciwgZGVwZW5kaW5nIG9uIHRoZSB0YXJnZXQgdXNlLWNhc2UuCiAgIEhvd2V2
ZXIsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgVEVTTEEgaW1wbGVtZW50YXRpb25zIHN1cHBv
cnQgdGhlIHVzZQogICBvZiB0aGUgaW4tYmFuZCBtZWNoYW5pc20gZm9yIGludGVyb3BlcmFi
aWxpdHkgcHVycG9zZXMuCgoyLjIuMS4gIEJvb3RzdHJhcHBpbmcgVEVTTEEgd2l0aCBhbiBP
dXQtT2YtQmFuZCBNZWNoYW5pc20KCiAgIEZvciBpbnN0YW5jZSBbUkZDNDQ0Ml0gZGVzY3Jp
YmVzIHRoZSB1c2Ugb2YgdGhlIE1JS0VZIChNdWx0aW1lZGlhCiAgIEludGVybmV0IEtleWlu
ZykgcHJvdG9jb2wgdG8gYm9vdHN0cmFwIFRFU0xBLiAgQXMgYSBzaWRlIGVmZmVjdCwKICAg
TUlLRVkgYWxzbyBwcm92aWRlcyBhIGxvb3NlIHRpbWUgc3luY2hyb25pemF0aW9uIGZlYXR1
cmUsIHRoYXQgVEVTTEEKICAgY2FuIGJlbmVmaXQuICBPdGhlciBzb2x1dGlvbnMsIGZvciBp
bnN0YW5jZSBiYXNlZCBvbiBhbiBleHRlbmRlZAogICBzZXNzaW9uIGRlc2NyaXB0aW9uLCBh
cmUgcG9zc2libGUsIG9uIGNvbmRpdGlvbiB0aGVzZSBzb2x1dGlvbnMKICAgcHJvdmlkZSB0
aGUgcmVxdWlyZWQgc2VjdXJpdHkgbGV2ZWwuCgoyLjIuMi4gIEJvb3RzdHJhcHBpbmcgVEVT
TEEgd2l0aCBhbiBJbi1CYW5kIE1lY2hhbmlzbQoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRl
c2NyaWJlcyBhbiBpbi1iYW5kIG1lY2hhbmlzbS4gIEluIHNvbWUgdXNlLQogICBjYXNlcywg
aXQgbWlnaHQgYmUgZGVzaXJlZCB0aGF0IGJvb3RzdHJhcCB0YWtlIHBsYWNlIHdpdGhvdXQK
ICAgcmVxdWlyaW5nIHRoZSB1c2Ugb2YgYW4gYWRkaXRpb25hbCBleHRlcm5hbCBtZWNoYW5p
c20uICBGb3IgaW5zdGFuY2UKICAgZWFjaCBkZXZpY2UgbWF5IGZlYXR1cmUgYSBjbG9jayB3
aXRoIGEga25vd24gdGltZS1kcmlmdCB0aGF0IGlzCiAgIG5lZ2xpZ2libGUgaW4gZnJvbnQg
b2YgdGhlIHRpbWUgYWNjdXJhY3kgcmVxdWlyZWQgYnkgVEVTTEEsIGFuZCBlYWNoCiAgIGRl
dmljZSBtYXkgZW1iZWQgdGhlIHB1YmxpYyBrZXkgb2YgdGhlIHNlbmRlci4gIEl0IGlzIGFs
c28gcG9zc2libGUKICAgdGhhdCB0aGUgdXNlLWNhc2UgZG9lcyBub3QgZmVhdHVyZSBhIGJp
ZGlyZWN0aW9uYWwgY2hhbm5lbCB3aGljaAogICBwcmV2ZW50cyB0aGUgdXNlIG9mIG91dC1v
Zi1iYW5kIHByb3RvY29scyBsaWtlIE1JS0VZLiAgRm9yIHRoZXNlIHR3bwogICBleGFtcGxl
cywgdGhlIGV4Y2hhbmdlIG9mIGEgYm9vdHN0cmFwIGluZm9ybWF0aW9uIG1lc3NhZ2UgKGRl
c2NyaWJlZAogICBpbiBTZWN0aW9uIDMuNC4xKSBhbmQgdGhlIGtub3dsZWRnZSBvZiBhIGZl
dyBhZGRpdGlvbmFsIHBhcmFtZXRlcnMKICAgKGxpc3RlZCBiZWxvdykgYXJlIHN1ZmZpY2ll
bnQgdG8gYm9vdHN0cmFwIFRFU0xBIGF0IGEgcmVjZWl2ZXIuCgogICBTb21lIHBhcmFtZXRl
cnMgY2Fubm90IGJlIGNvbW11bmljYXRlZCBpbi1iYW5kLiAgSW4gcGFydGljdWxhcjoKCiAg
IG8gIHRoZSBzZW5kZXIgb3IgZ3JvdXAgY29udHJvbGxlciBNVVNUIGVpdGhlciBjb21tdW5p
Y2F0ZSB0aGUgcHVibGljCiAgICAgIGtleSBvZiB0aGUgc2VuZGVyIG9yIGEgY2VydGlmaWNh
dGUgKHdoaWNoIGFsc28gbWVhbnMgdGhhdCBhIFBLSQogICAgICBoYXMgYmVlbiBzZXR1cCkg
dG8gYWxsIHJlY2VpdmVycywgc28gdGhhdCBlYWNoIHJlY2VpdmVyIGJlIGFibGUgdG8KICAg
ICAgdmVyaWZ5IHRoZSBzaWduYXR1cmUgb2YgdGhlIGJvb3RzdHJhcCBtZXNzYWdlIGFuZCBk
aXJlY3QgdGltZQogICAgICBzeW5jaHJvbml6YXRpb24gcmVzcG9uc2UgbWVzc2FnZXMgKHdo
ZW4gYXBwbGljYWJsZSkuCgoKCgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBN
YXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFm
dCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVy
IDIwMDkKCgogICBvICB3aGVuIHRpbWUgc3luY2hyb25pemF0aW9uIGlzIHBlcmZvcm1lZCB3
aXRoIE5UUC9TTlRQLCB0aGUgc2VuZGVyCiAgICAgIG9yIGdyb3VwIGNvbnRyb2xsZXIgTVVT
VCBjb21tdW5pY2F0ZSB0aGUgbGlzdCBvZiB2YWxpZCBOVFAvU05UUAogICAgICBzZXJ2ZXJz
IHRvIGFsbCB0aGUgc2Vzc2lvbiBtZW1iZXJzIChzZW5kZXIgaW5jbHVkZWQpLCBzbyB0aGF0
IHRoZXkKICAgICAgYWxsIGJlIGFibGUgdG8gc3luY2hyb25pemUgdGhlbXNlbHZlcyBvbiB0
aGUgc2FtZSBOVFAvU05UUAogICAgICBzZXJ2ZXJzLgoKICAgbyAgd2hlbiB0aGUgR3JvdXAg
TUFDIGZlYXR1cmUgaXMgdXNlZCwgdGhlIHNlbmRlciBvciBncm91cCBjb250cm9sbGVyCiAg
ICAgIE1VU1QgY29tbXVuaWNhdGUgdGhlIEtfZyBncm91cCBrZXkgdG8gYWxsIHRoZSBzZXNz
aW9uIG1lbWJlcnMKICAgICAgKHNlbmRlciBpbmNsdWRlZCkuICBUaGlzIGdyb3VwIGtleSBt
YXkgYmUgcGVyaW9kaWNhbGx5IHJlZnJlc2hlZC4KCiAgIFRoZSB3YXkgdGhlc2UgcGFyYW1l
dGVycyBhcmUgY29tbXVuaWNhdGVkIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcwogICBk
b2N1bWVudC4KCjIuMy4gIFNldHRpbmcgVXAgYSBTZWN1cmUgVGltZSBTeW5jaHJvbml6YXRp
b24KCiAgIFRoZSBzZWN1cml0eSBvZmZlcmVkIGJ5IFRFU0xBIGhlYXZpbHkgcmVsaWVzIG9u
IHRpbWUuICBUaGVyZWZvcmUgdGhlCiAgIHNlc3Npb24ncyBzZW5kZXIgYW5kIGVhY2ggcmVj
ZWl2ZXIgbmVlZCB0byBiZSB0aW1lIHN5bmNocm9uaXplZCBpbiBhCiAgIHNlY3VyZSB3YXku
ICBUbyB0aGF0IHB1cnBvc2UsIHR3byBnZW5lcmFsIG1ldGhvZHMgZXhpc3Q6CgogICBvICBk
aXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24sIGFuZAoKICAgbyAgaW5kaXJlY3QgdGltZSBz
eW5jaHJvbml6YXRpb24uCgogICBJdCBpcyBhbHNvIHBvc3NpYmxlIHRoYXQgYSBnaXZlbiBz
ZXNzaW9uIGluY2x1ZGUgcmVjZWl2ZXJzIHRoYXQgdXNlCiAgIHRoZSBkaXJlY3QgdGltZSBz
eW5jaHJvbml6YXRpb24gbW9kZSB3aGlsZSBvdGhlcnMgdXNlIHRoZSBpbmRpcmVjdAogICB0
aW1lIHN5bmNocm9uaXphdGlvbiBtb2RlLgoKMi4zLjEuICBEaXJlY3QgVGltZSBTeW5jaHJv
bml6YXRpb24KCiAgIFdoZW4gZGlyZWN0IHRpbWUgc3luY2hyb25pemF0aW9uIGlzIHVzZWQs
IGVhY2ggcmVjZWl2ZXIgYXNrcyB0aGUKICAgc2VuZGVyIGZvciBhIHRpbWUgc3luY2hyb25p
emF0aW9uLiAgVG8gdGhhdCBwdXJwb3NlLCBhIHJlY2VpdmVyIHNlbmRzCiAgIGEgIkRpcmVj
dCBUaW1lIFN5bmNocm9uaXphdGlvbiBSZXF1ZXN0IiAoU2VjdGlvbiA0LjIuMi4xKS4gIFRo
ZQogICBzZW5kZXIgdGhlbiBkaXJlY3RseSBhbnN3ZXJzIHRvIGVhY2ggcmVxdWVzdCB3aXRo
IGEgIkRpcmVjdCBUaW1lCiAgIFN5bmNocm9uaXphdGlvbiBSZXNwb25zZSIgKFNlY3Rpb24g
My40LjIpLCBzaWduaW5nIHRoaXMgcmVwbHkuICBVcG9uCiAgIHJlY2VpdmluZyB0aGlzIHJl
c3BvbnNlLCBhIHJlY2VpdmVyIGZpcnN0IHZlcmlmaWVzIHRoZSBzaWduYXR1cmUsIGFuZAog
ICB0aGVuIGNhbGN1bGF0ZXMgYW4gdXBwZXIgYm91bmQgb2YgdGhlIGxhZyBvZiBoaXMgY2xv
Y2sgd2l0aCByZXNwZWN0CiAgIHRvIHRoZSBjbG9jayBvZiB0aGUgc2VuZGVyLCBEX3QuICBU
aGUgZGV0YWlscyBvbiBob3cgdG8gY2FsY3VsYXRlIERfdAogICBhcmUgZ2l2ZW4gaW4gU2Vj
dGlvbiAyLjQuMS4KCiAgIFRoaXMgc3luY2hyb25pemF0aW9uIG1ldGhvZCBpcyBib3RoIHNp
bXBsZSBhbmQgc2VjdXJlLiAgWWV0IHRoZXJlIGFyZQogICB0d28gcG90ZW50aWFsIGlzc3Vl
czoKCiAgIG8gIGEgYmlkaXJlY3Rpb25hbCBjaGFubmVsIG11c3QgZXhpc3QgYmV0d2VlbiB0
aGUgc2VuZGVyIGFuZCBlYWNoCiAgICAgIHJlY2VpdmVyLCBhbmQKCiAgIG8gIHRoZSBzZW5k
ZXIgbWF5IGNvbGxhcHNlIGlmIHRoZSBpbmNvbWluZyByZXF1ZXN0IHJhdGUgaXMgdG9vIGhp
Z2guCgogICBSZWx5aW5nIG9uIGRpcmVjdCB0aW1lIHN5bmNocm9uaXphdGlvbiBpcyBub3Qg
ZXhwZWN0ZWQgdG8gYmUgYW4gaXNzdWUKCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4
cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJu
ZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNl
cHRlbWJlciAyMDA5CgoKICAgd2l0aCBOT1JNIHNpbmNlICgxKSBiaWRpcmVjdGlvbmFsIGNv
bW11bmljYXRpb25zIGFscmVhZHkgdGFrZSBwbGFjZSwKICAgYW5kICgyKSBOT1JNIHNjYWxh
YmlsaXR5IGlzIGFueXdheSBsaW1pdGVkLiAgWWV0IGl0IGNhbiBiZSByZXF1aXJlZAogICB0
aGF0IGEgbWVjaGFuaXNtLCB0aGF0IGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1
bWVudCwgYmUgdXNlZAogICB0byBzcHJlYWQgdGhlIHRyYW5zbWlzc2lvbiBvZiAiRGlyZWN0
IHRpbWUgc3luY2hyb25pemF0aW9uIHJlcXVlc3QiCiAgIG1lc3NhZ2VzIG92ZXIgdGhlIHRp
bWUgaWYgdGhlcmUgaXMgYSByaXNrIHRoYXQgdGhlIHNlbmRlciBtYXkKICAgY29sbGFwc2Uu
CgogICBCdXQgZGlyZWN0IHRpbWUgc3luY2hyb25pemF0aW9uIGlzIHBvdGVudGlhbGx5IGlu
Y29tcGF0aWJsZSB3aXRoIEFMQwogICBzaW5jZSAoMSkgdGhlcmUgbWlnaHQgbm90IGJlIGEg
YmFjayBjaGFubmVsIGFuZCAoMikgdGhlcmUgYXJlCiAgIHBvdGVudGlhbGx5IGEgaHVnZSBu
dW1iZXIgb2YgcmVjZWl2ZXJzIGFuZCB0aGVyZWZvcmUgYSByaXNrIHRoYXQgdGhlCiAgIHNl
bmRlciBjb2xsYXBzZXMuCgoyLjMuMi4gIEluZGlyZWN0IFRpbWUgU3luY2hyb25pemF0aW9u
CgogICBXaGVuIGluZGlyZWN0IHRpbWUgc3luY2hyb25pemF0aW9uIGlzIHVzZWQsIHRoZSBz
ZW5kZXIgYW5kIGVhY2gKICAgcmVjZWl2ZXIgbXVzdCBzeW5jaHJvbml6ZSBzZWN1cmVseSB2
aWEgYW4gZXh0ZXJuYWwgdGltZSByZWZlcmVuY2UuCiAgIFNldmVyYWwgcG9zc2liaWxpdGll
cyBleGlzdDoKCiAgIG8gIHNlbmRlciBhbmQgcmVjZWl2ZXJzIGNhbiBzeW5jaHJvbml6ZSB0
aHJvdWdoIGEgTlRQdjMgKE5ldHdvcmsgVGltZQogICAgICBQcm90b2NvbCB2ZXJzaW9uIDMp
IFtSRkMxMzA1XSBoaWVyYXJjaHkgb2Ygc2VydmVycy4gIFRoZQogICAgICBhdXRoZW50aWNh
dGlvbiBtZWNoYW5pc20gb2YgTlRQdjMgTVVTVCBiZSB1c2VkIGluIG9yZGVyIHRvCiAgICAg
IGF1dGhlbnRpY2F0ZSBlYWNoIE5UUCBtZXNzYWdlIGluZGl2aWR1YWxseS4gIEl0IHByZXZl
bnRzIGZvcgogICAgICBpbnN0YW5jZSBhbiBhdHRhY2tlciB0byBpbXBlcnNvbmF0ZSBhIE5U
UCBzZXJ2ZXI7CgogICBvICB0aGV5IGNhbiBzeW5jaHJvbml6ZSB0aHJvdWdoIGEgTlRQdjQg
KE5ldHdvcmsgVGltZSBQcm90b2NvbAogICAgICB2ZXJzaW9uIDQpIFtOVFAtTlRQdjRdIGhp
ZXJhcmNoeSBvZiBzZXJ2ZXJzLiAgVGhlIEF1dG9rZXkgc2VjdXJpdHkKICAgICAgcHJvdG9j
b2wgb2YgTlRQdjQgTVVTVCBiZSB1c2VkIGluIG9yZGVyIHRvIGF1dGhlbnRpY2F0ZSBlYWNo
IE5UUAogICAgICBtZXNzYWdlIGluZGl2aWR1YWxseTsKCiAgIG8gIHRoZXkgY2FuIHN5bmNo
cm9uaXplIHRocm91Z2ggYSBTTlRQdjQgKFNpbXBsZSBOZXR3b3JrIFRpbWUKICAgICAgUHJv
dG9jb2wgdmVyc2lvbiA0KSBbUkZDNDMzMF0gaGllcmFyY2h5IG9mIHNlcnZlcnMuICBUaGUK
ICAgICAgYXV0aGVudGljYXRpb24gZmVhdHVyZXMgb2YgU05UUHY0IG11c3QgdGhlbiBiZSB1
c2VkLiAgTm90ZSB0aGF0CiAgICAgIFRFU0xBIG9ubHkgbmVlZHMgYSBsb29zZSAoYnV0IHNl
Y3VyZSkgdGltZSBzeW5jaHJvbml6YXRpb24sIHdoaWNoCiAgICAgIGlzIGluIGxpbmUgd2l0
aCB0aGUgdGltZSBzeW5jaHJvbml6YXRpb24gc2VydmljZSBvZmZlcmVkIGJ5IFNOVFA7Cgog
ICBvICB0aGV5IGNhbiBzeW5jaHJvbml6ZSB0aHJvdWdoIGEgR1BTIG9yIEdhbGlsZW8gKG9y
IHNpbWlsYXIpIGRldmljZQogICAgICB0aGF0IGFsc28gcHJvdmlkZXMgYSBoaWdoIHByZWNp
c2lvbiB0aW1lIHJlZmVyZW5jZS4gIFNwb29maW5nCiAgICAgIGF0dGFja3Mgb24gdGhlIEdQ
UyBzeXN0ZW0gaGF2ZSByZWNlbnRseSBiZWVuIHJlcG9ydGVkLiAgRGVwZW5kaW5nCiAgICAg
IG9uIHRoZSB1c2UgY2FzZSwgdGhlIHNlY3VyaXR5IGFjaGlldmVkIHdpbGwgYmUgb3Igbm90
IGFjY2VwdGFibGU7CgogICBvICB0aGV5IGNhbiBzeW5jaHJvbml6ZSB0aGFua3MgdG8gYSBk
ZWRpY2F0ZWQgaGFyZHdhcmUsIGVtYmVkZGVkIG9uCiAgICAgIGVhY2ggc2VuZGVyIGFuZCBy
ZWNlaXZlciwgdGhhdCBwcm92aWRlcyBhIGNsb2NrIHdpdGggYSB0aW1lLWRyaWZ0CiAgICAg
IHRoYXQgaXMgbmVnbGlnaWJsZSBpbiBmcm9udCBvZiB0aGUgVEVTTEEgdGltZSBhY2N1cmFj
eQogICAgICByZXF1aXJlbWVudHMuICBUaGlzIGZlYXR1cmUgZW5hYmxlcyBhIGRldmljZSB0
byBzeW5jaHJvbml6ZSBpdHMKICAgICAgZW1iZWRkZWQgY2xvY2sgd2l0aCB0aGUgb2ZmaWNp
YWwgdGltZSByZWZlcmVuY2UgZnJvbSB0aW1lIHRvIHRpbWUKICAgICAgKGluIGFuIGV4dHJl
bWUgY2FzZSBvbmNlLCBhdCBtYW51ZmFjdHVyaW5nIHRpbWUpLCBhbmQgdGhlbiB0bwogICAg
ICByZW1haW4gYXV0b25vbW91cyBmb3IgYSBkdXJhdGlvbiB0aGF0IGRlcGVuZHMgb24gdGhl
IGtub3duIG1heGltdW0KICAgICAgY2xvY2sgZHJpZnQuCgoKClJvY2EsIGV0IGFsLiAgICAg
ICAgICAgICBFeHBpcmVzIE1hcmNoIDIwLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDEz
XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVEVTTEEgaW4gQUxDIGFuZCBOT1JNICAg
ICAgICAgICBTZXB0ZW1iZXIgMjAwOQoKCiAgIEEgYmlkaXJlY3Rpb25hbCBjaGFubmVsIGlz
IHJlcXVpcmVkIGJ5IHRoZSBOVFAvU05UUCBzY2hlbWVzLiAgT24gdGhlCiAgIG9wcG9zaXRl
LCB3aXRoIHRoZSBHUFMvR2FsaWxlbyBhbmQgaGlnaCBwcmVjaXNpb24gY2xvY2sgc2NoZW1l
cywgbm8KICAgc3VjaCBhc3N1bXB0aW9uIGlzIG1hZGUuICBJbiBzaXR1YXRpb25zIHdoZXJl
IEFMQyBpcyB1c2VkIG9uIHB1cmVseQogICB1bmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgY2hh
bm5lbHMgKFNlY3Rpb24gMi4xKSwgdXNpbmcgdGhlIE5UUC9TTlRQCiAgIHNjaGVtZXMgaXMg
bm90IHBvc3NpYmxlLiAgQW5vdGhlciBhc3BlY3QgaXMgdGhlIHNjYWxhYmlsaXR5CiAgIHJl
cXVpcmVtZW50IG9mIEFMQywgYW5kIHRvIGEgbGVzc2VyIGV4dGVudCBvZiBOT1JNLiAgRnJv
bSB0aGlzIHBvaW50CiAgIG9mIHZpZXcsIHRoZSBhYm92ZSBtZWNoYW5pc21zIHVzdWFsbHkg
ZG8gbm90IHJhaXNlIGFueSBwcm9ibGVtLAogICB1bmxpa2UgdGhlIGRpcmVjdCB0aW1lIHN5
bmNocm9uaXphdGlvbiBzY2hlbWVzLiAgVGhlcmVmb3JlLCB1c2luZwogICBpbmRpcmVjdCB0
aW1lIHN5bmNocm9uaXphdGlvbiBjYW4gYmUgYSBnb29kIGNob2ljZS4gIEl0IHNob3VsZCBi
ZQogICBub3RlZCB0aGF0IHRoZSBOVFAvU05UUCBzY2hlbWVzIGFzc3VtZSB0aGF0IGVhY2gg
Y2xpZW50IHRydXN0cyB0aGUKICAgc2VuZGVyIGFuZCBhY2NlcHRzIHRvIGFsaWduIGl0cyBO
VFAvU05UUCBjb25maWd1cmF0aW9uIHRvIHRoYXQgb2YgdGhlCiAgIHNlbmRlci4gIElmIHRo
aXMgYXNzdW1wdGlvbiBkb2VzIG5vdCBob2xkLCB0aGUgc2VuZGVyIFNIT1VMRCBvZmZlciBh
bgogICBhbHRlcm5hdGl2ZSBzb2x1dGlvbi4KCiAgIFRoZSBkZXRhaWxzIG9uIGhvdyB0byBj
YWxjdWxhdGUgYW4gdXBwZXIgYm91bmQgb2YgdGhlIGxhZyBvZiBhCiAgIHJlY2VpdmVyJ3Mg
Y2xvY2sgd2l0aCByZXNwZWN0IHRvIHRoZSBjbG9jayBvZiB0aGUgc2VuZGVyLCBEX3QsIGFy
ZQogICBnaXZlbiBpbiBTZWN0aW9uIDIuNC4yLgoKMi40LiAgRGV0ZXJtaW5pbmcgdGhlIERl
bGF5IEJvdW5kcwoKICAgTGV0IHVzIGFzc3VtZSB0aGF0IGEgc2VjdXJlIHRpbWUgc3luY2hy
b25pemF0aW9uIGhhcyBiZWVuIHNldCB1cC4KICAgVGhpcyBzZWN0aW9uIGV4cGxhaW5zIGhv
dyB0byBkZWZpbmUgdGhlIHZhcmlvdXMgdGltaW5nIHBhcmFtZXRlcnMKICAgdGhhdCBhcmUg
dXNlZCBkdXJpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIG9mIHJlY2VpdmVkIHBhY2tldHMuCgoy
LjQuMS4gIERlbGF5IEJvdW5kIENhbGN1bGF0aW9uIGluIERpcmVjdCBUaW1lIFN5bmNocm9u
aXphdGlvbiBNb2RlCgogICBJbiBkaXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24gbW9kZSwg
c3luY2hyb25pemF0aW9uIGJldHdlZW4gYQogICByZWNlaXZlciBhbmQgdGhlIHNlbmRlciBm
b2xsb3dzIHRoZSBmb2xsb3dpbmcgcHJvdG9jb2wgW1JGQzQwODJdOgoKICAgbyAgVGhlIHJl
Y2VpdmVyIHNlbmRzIGEgIkRpcmVjdCBUaW1lIFN5bmNocm9uaXphdGlvbiBSZXF1ZXN0IiBt
ZXNzYWdlCiAgICAgIHRvIHRoZSBzZW5kZXIsIHRoYXQgaW5jbHVkZXMgdF9yLCB0aGUgcmVj
ZWl2ZXIgbG9jYWwgdGltZSBhdCB0aGUKICAgICAgbW9tZW50IG9mIHNlbmRpbmcgKFNlY3Rp
b24gNC4yLjIuMSkuCgogICBvICBVcG9uIHJlY2VpcHQgb2YgdGhpcyBtZXNzYWdlLCB0aGUg
c2VuZGVyIHJlY29yZHMgaXRzIGxvY2FsIHRpbWUsCiAgICAgIHRfcywgYW5kIHNlbmRzIHRv
IHRoZSByZWNlaXZlciBhICJEaXJlY3QgVGltZSBTeW5jaHJvbml6YXRpb24KICAgICAgUmVz
cG9uc2UiIHRoYXQgaW5jbHVkZXMgdF9yICh0YWtlbiBmcm9tIHRoZSByZXF1ZXN0KSBhbmQg
dF9zCiAgICAgIChTZWN0aW9uIDMuNC4yKSwgc2lnbmluZyB0aGlzIHJlcGx5LgoKICAgbyAg
VXBvbiByZWNlaXZpbmcgdGhpcyByZXNwb25zZSwgdGhlIHJlY2VpdmVyIGZpcnN0IHZlcmlm
aWVzIHRoYXQgaGUKICAgICAgYWN0dWFsbHkgc2VudCBhIHJlcXVlc3Qgd2l0aCB0X3IgYW5k
IHRoZW4gY2hlY2tzIHRoZSBzaWduYXR1cmUuCiAgICAgIFRoZW4gaGUgY2FsY3VsYXRlcyBE
X3QgPSB0X3MgLSB0X3IgKyBTX3NyLCB3aGVyZSBTX3NyIGlzIGFuCiAgICAgIGVzdGltYXRl
ZCBib3VuZCBvZiB0aGUgY2xvY2sgZHJpZnQgYmV0d2VlbiB0aGUgc2VuZGVyIGFuZCB0aGUK
ICAgICAgcmVjZWl2ZXIgdGhyb3VnaG91dCB0aGUgZHVyYXRpb24gb2YgdGhlIHNlc3Npb24u
ICBUaGlzIGRvY3VtZW50CiAgICAgIGRvZXMgbm90IHNwZWNpZnkgaG93IFNfc3IgaXMgZXN0
aW1hdGVkLgoKICAgQWZ0ZXIgdGhpcyBpbml0aWFsIHN5bmNocm9uaXphdGlvbiwgYXQgYW55
IHBvaW50IHRocm91Z2hvdXQgdGhlCiAgIHNlc3Npb24sIHRoZSByZWNlaXZlciBrbm93cyB0
aGF0OiBUX3MgPCBUX3IgKyBEX3QsIHdoZXJlIFRfcyBpcyB0aGUKICAgY3VycmVudCB0aW1l
IGF0IHRoZSBzZW5kZXIgYW5kIFRfciBpcyB0aGUgY3VycmVudCB0aW1lIGF0IHRoZQoKCgpS
b2NhLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAg
ICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGlu
IEFMQyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICByZWNlaXZlci4K
CjIuNC4yLiAgRGVsYXkgQm91bmQgQ2FsY3VsYXRpb24gaW4gSW5kaXJlY3QgdGltZSBTeW5j
aHJvbml6YXRpb24gTW9kZQoKICAgSW4gaW5kaXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24s
IHRoZSBzZW5kZXIgYW5kIHRoZSByZWNlaXZlcnMgbXVzdAogICBzeW5jaHJvbml6ZSBpbmRp
cmVjdGx5IHdpdGggb25lIG9yIHNldmVyYWwgdGltZSByZWZlcmVuY2VzLgoKMi40LjIuMS4g
IFNpbmdsZSB0aW1lIHJlZmVyZW5jZQoKICAgTGV0IHVzIGFzc3VtZSB0aGF0IHRoZXJlIGlz
IGEgc2luZ2xlIHRpbWUgcmVmZXJlbmNlLgoKICAgMS4gIFRoZSBzZW5kZXIgY2FsY3VsYXRl
cyBEXk9fdCwgdGhlIHVwcGVyIGJvdW5kIG9mIHRoZSBsYWcgb2YgdGhlCiAgICAgICBzZW5k
ZXIncyBjbG9jayB3aXRoIHJlc3BlY3QgdG8gdGhlIHRpbWUgcmVmZXJlbmNlLiAgVGhpcyBE
Xk9fdAogICAgICAgdmFsdWUgaXMgdGhlbiBiZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHJlY2Vp
dmVycyAoU2VjdGlvbiAzLjIuMSkuCgogICAyLiAgU2ltaWxhcmx5LCBhIHJlY2VpdmVyIFIg
Y2FsY3VsYXRlcyBEXlJfdCwgdGhlIHVwcGVyIGJvdW5kIG9mIHRoZQogICAgICAgbGFnIG9m
IHRoZSByZWNlaXZlcidzIGNsb2NrIHdpdGggcmVzcGVjdCB0byB0aGUgdGltZSByZWZlcmVu
Y2UuCgogICAzLiAgVGhlbiwgZm9yIHJlY2VpdmVyIFIsIHRoZSBvdmVyYWxsIHVwcGVyIGJv
dW5kIG9mIHRoZSBsYWcgb2YgdGhlCiAgICAgICByZWNlaXZlcidzIGNsb2NrIHdpdGggcmVz
cGVjdCB0byB0aGUgY2xvY2sgb2YgdGhlIHNlbmRlciwgRF90LCBpcwogICAgICAgdGhlIHN1
bTogRF90ID0gRF5PX3QgKyBEXlJfdC4KCiAgIFRoZSBEXk9fdCBhbmQgRF5SX3QgY2FsY3Vs
YXRpb24gZGVwZW5kcyBvbiB0aGUgdGltZSBzeW5jaHJvbml6YXRpb24KICAgbWVjaGFuaXNt
IHVzZWQgKFNlY3Rpb24gMi4zLjIpLiAgSW4gc29tZSBjYXNlcywgdGhlIHN5bmNocm9uaXph
dGlvbgogICBzY2hlbWUgc3BlY2lmaWNhdGlvbnMgcHJvdmlkZSB0aGVzZSB2YWx1ZXMuICBJ
biBvdGhlciBjYXNlcywgdGhlc2UKICAgcGFyYW1ldGVycyBjYW4gYmUgY2FsY3VsYXRlZCBi
eSBtZWFucyBvZiBhIHNjaGVtZSBzaW1pbGFyIHRvIHRoZSBvbmUKICAgc3BlY2lmaWVkIGlu
IFNlY3Rpb24gMi40LjEsIGZvciBpbnN0YW5jZSB3aGVuIHN5bmNocm9uaXphdGlvbiBpcwog
ICBhY2hpZXZlZCB2aWEgYSBncm91cCBjb250cm9sbGVyIFtSRkM0MDgyXS4KCjIuNC4yLjIu
ICBNdWx0aXBsZSB0aW1lIHJlZmVyZW5jZXMKCiAgIExldCB1cyBub3cgYXNzdW1lIHRoYXQg
dGhlcmUgYXJlIHNldmVyYWwgdGltZSByZWZlcmVuY2VzIChlLmcuLAogICBzZXZlcmFsIE5U
UC9TTlRQIHNlcnZlcnMpLiAgVGhlIHNlbmRlciBhbmQgcmVjZWl2ZXJzIHVzZSB0aGUgZGly
ZWN0CiAgIHRpbWUgc3luY2hyb25pemF0aW9uIHNjaGVtZSB0byBzeW5jaHJvbml6ZSB3aXRo
IHRoZSB2YXJpb3VzIHRpbWUKICAgcmVmZXJlbmNlcy4gIEl0IHJlc3VsdHMgaW4gRF5PX3Qg
YW5kIEReUl90LiAgTGV0IERfZXJyIGJlIGFuIHVwcGVyCiAgIGJvdW5kIG9mIHRoZSB0aW1l
IGVycm9yIGJldHdlZW4gYWxsIHRoZSB0aW1lIHJlZmVyZW5jZXMuICBUaGVuLCB0aGUKICAg
b3ZlcmFsbCB2YWx1ZSBvZiBEX3Qgd2l0aGluIHJlY2VpdmVyIFIgaXMgc2V0IHRvIHRoZSBz
dW06IERfdCA9IEReT190CiAgICsgRF5SX3QgKyBEX2Vyci4KCiAgIEluIHNvbWUgY2FzZXMs
IHRoZSBEX3QgdmFsdWUgaXMgcGFydCBvZiB0aGUgdGltZSBzeW5jaHJvbml6YXRpb24KICAg
c2NoZW1lIHNwZWNpZmljYXRpb25zLiAgRm9yIGluc3RhbmNlIE5UUHYzIFtSRkMxMzA1XSBk
ZWZpbmVzCiAgIGFsZ29yaXRobXMgdGhhdCBhcmUgImNhcGFibGUgb2YgYWNjdXJhY2llcyBp
biB0aGUgb3JkZXIgb2YgYQogICBtaWxsaXNlY29uZCwgZXZlbiBhZnRlciBleHRlbmRlZCBw
ZXJpb2RzIHdoZW4gc3luY2hyb25pemF0aW9uIHRvCiAgIHByaW1hcnkgcmVmZXJlbmNlIHNv
dXJjZXMgaGFzIGJlZW4gbG9zdCIuICBJbiBwcmFjdGljZSwgZGVwZW5kaW5nIG9uCiAgIHRo
ZSBOVFAgc2VydmVyIHN0cmF0dW0sIHRoZSBhY2N1cmFjeSBtaWdodCBiZSBhIGxpdHRsZSBi
aXQgd29yc2UuICBJbgogICB0aGF0IGNhc2UsIERfdCA9IHNlY3VyaXR5X2ZhY3RvciAqICgx
bXMgKyAxbXMpLCB3aGVyZSB0aGUKICAgc2VjdXJpdHlfZmFjdG9yIGlzIG1lYW50IHRvIGNv
bXBlbnNhdGUgc2V2ZXJhbCBzb3VyY2VzIG9mIGluYWNjdXJhY3kKICAgaW4gTlRQLiAgVGhl
IGNob2ljZSBvZiB0aGUgc2VjdXJpdHlfZmFjdG9yIHZhbHVlIGlzIGxlZnQgdG8gdGhlCgoK
ClJvY2EsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwLCAyMDEwICAgICAg
ICAgICAgICAgIFtQYWdlIDE1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVEVTTEEg
aW4gQUxDIGFuZCBOT1JNICAgICAgICAgICBTZXB0ZW1iZXIgMjAwOQoKCiAgIGltcGxlbWVu
dGVyLCBkZXBlbmRpbmcgb24gdGhlIHRhcmdldCB1c2UtY2FzZS4KCjIuNS4gIENyeXB0b2dy
YXBoaWMgcGFyYW1ldGVyIHZhbHVlcwoKICAgVGhlIEYgKHJlc3AuIEYnKSBmdW5jdGlvbiBv
dXRwdXQgbGVuZ3RoIGlzIGdpdmVuIGJ5IHRoZSBuX3AgKHJlc3AuCiAgIG5fZikgcGFyYW1l
dGVyLiAgVGhlIG5fcCBhbmQgbl9mIHZhbHVlcyBkZXBlbmQgb24gdGhlIFBSRiBmdW5jdGlv
bgogICBjaG9zZW4sIGFzIHNwZWNpZmllZCBiZWxvdzoKCiAgICAgICAgICAgICArLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAg
IHwgICAgICAgIFBSRiBuYW1lICAgICAgICB8ICAgICBuX3AgYW5kIG5fZiAgICAgfAogICAg
ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t
LS0rCiAgICAgICAgICAgICB8ICAgICAgIEhNQUMtU0hBLTEgICAgICAgfCAxNjAgYml0cyAo
MjAgYnl0ZXMpIHwKICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAg
ICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgfCAgICAgIEhNQUMtU0hBLTIyNCAg
ICAgIHwgMjI0IGJpdHMgKDI4IGJ5dGVzKSB8CiAgICAgICAgICAgICB8ICAgICAgICAgICAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgIHwgSE1B
Qy1TSEEtMjU2IChkZWZhdWx0KSB8IDI1NiBiaXRzICgzMiBieXRlcykgfAogICAgICAgICAg
ICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8CiAg
ICAgICAgICAgICB8ICAgICAgSE1BQy1TSEEtMzg0ICAgICAgfCAzODQgYml0cyAoNDggYnl0
ZXMpIHwKICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICAgICAgICAgfAogICAgICAgICAgICAgfCAgICAgIEhNQUMtU0hBLTUxMiAgICAgIHwg
NTEyIGJpdHMgKDY0IGJ5dGVzKSB8CiAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgIFRoZSBjb21wdXRpbmcgb2YgcmVn
dWxhciBNQUMgKHJlc3AuIEdyb3VwIE1BQykgbWFrZXMgdXNlIG9mIHRoZSBuX20KICAgKHJl
c3AuIG5fdykgcGFyYW1ldGVyLCBpLmUuLCB0aGUgbGVuZ3RoIG9mIHRoZSB0cnVuY2F0ZWQg
b3V0cHV0IG9mCiAgIHRoZSBmdW5jdGlvbi4gIFRoZSBuX20gYW5kIG5fdyB2YWx1ZXMgZGVw
ZW5kIG9uIHRoZSBNQUMgZnVuY3Rpb24KICAgY2hvc2VuLCBhcyBzcGVjaWZpZWQgYmVsb3c6
CgogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSst
LS0tLS0tLS0tLS0tLS0tLS0tKwogICB8ICAgICAgICBNQUMgbmFtZSAgICAgICAgfCAgbl9t
IChyZWd1bGFyIE1BQykgIHwgIG5fdyAoR3JvdXAgTUFDKSAgfAogICArLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t
KwogICB8ICAgICAgIEhNQUMtU0hBLTEgICAgICAgfCAgODAgYml0cyAoMTAgYnl0ZXMpIHwg
MzIgYml0cyAoNCBieXRlcykgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg
ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgSE1BQy1T
SEEtMjI0ICAgICAgfCAxMTIgYml0cyAoMTQgYnl0ZXMpIHwgMzIgYml0cyAoNCBieXRlcykg
fAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwg
ICAgICAgICAgICAgICAgICAgfAogICB8IEhNQUMtU0hBLTI1NiAoZGVmYXVsdCkgfCAxMjgg
Yml0cyAoMTYgYnl0ZXMpIHwgMzIgYml0cyAoNCBieXRlcykgfAogICB8ICAgICAgICAgICAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg
fAogICB8ICAgICAgSE1BQy1TSEEtMzg0ICAgICAgfCAxOTIgYml0cyAoMjQgYnl0ZXMpIHwg
MzIgYml0cyAoNCBieXRlcykgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg
ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgSE1BQy1T
SEEtNTEyICAgICAgfCAyNTYgYml0cyAoMzIgYnl0ZXMpIHwgMzIgYml0cyAoNCBieXRlcykg
fAogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSst
LS0tLS0tLS0tLS0tLS0tLS0tKwoKCgoKCgoKCgoKClJvY2EsIGV0IGFsLiAgICAgICAgICAg
ICBFeHBpcmVzIE1hcmNoIDIwLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCklu
dGVybmV0LURyYWZ0ICAgICAgICAgICAgVEVTTEEgaW4gQUxDIGFuZCBOT1JNICAgICAgICAg
ICBTZXB0ZW1iZXIgMjAwOQoKCjMuICBTZW5kZXIgT3BlcmF0aW9ucwoKICAgVGhpcyBzZWN0
aW9uIGRlc2NyaWJlcyB0aGUgVEVTTEEgb3BlcmF0aW9ucyBhdCBhIHNlbmRlci4KCjMuMS4g
IFRFU0xBIFBhcmFtZXRlcnMKCjMuMS4xLiAgVGltZSBJbnRlcnZhbHMKCiAgIFRoZSBzZW5k
ZXIgZGl2aWRlcyB0aGUgdGltZSBpbnRvIHVuaWZvcm0gaW50ZXJ2YWxzIG9mIGR1cmF0aW9u
IFRfaW50LgogICBUaW1lIGludGVydmFsIG51bWJlcmluZyBzdGFydHMgYXQgMCBhbmQgaXMg
aW5jcmVtZW50ZWQgY29uc2VjdXRpdmVseS4KICAgVGhlIGludGVydmFsIGluZGV4IE1VU1Qg
YmUgc3RvcmVkIGluIGFuIHVuc2lnbmVkIDMyIGJpdCBpbnRlZ2VyIHNvCiAgIHRoYXQgd3Jh
cHBpbmcgdG8gMCB0YWtlcyBwbGFjZSBvbmx5IGFmdGVyIDJeXjMyIGludGVydmFscy4gIEZv
cgogICBpbnN0YW5jZSwgaWYgVF9pbnQgaXMgZXF1YWwgdG8gMC41IHNlY29uZHMsIHRoZW4g
d3JhcHBpbmcgdGFrZXMgcGxhY2UKICAgYWZ0ZXIgYXBwcm94aW1hdGVseSA2OCB5ZWFycy4K
CjMuMS4yLiAgS2V5IENoYWlucwoKMy4xLjIuMS4gIFByaW5jaXBsZXMKCiAgIFRoZSBzZW5k
ZXIgY29tcHV0ZXMgYSBvbmUtd2F5IGtleSBjaGFpbiBvZiBuX2MgPSBOKzEga2V5cywgYW5k
CiAgIGFzc2lnbnMgb25lIGtleSBmcm9tIHRoZSBjaGFpbiB0byBlYWNoIGludGVydmFsLCBj
b25zZWN1dGl2ZWx5IGJ1dCBpbgogICByZXZlcnNlIG9yZGVyLiAgS2V5IG51bWJlcmluZyBz
dGFydHMgYXQgMCBhbmQgaXMgaW5jcmVtZW50ZWQKICAgY29uc2VjdXRpdmVseSwgZm9sbG93
aW5nIHRoZSB0aW1lIGludGVydmFsIG51bWJlcmluZzogS18wLCBLXzEgLi4KICAgS19OLgoK
ICAgSW4gb3JkZXIgdG8gY29tcHV0ZSB0aGlzIGNoYWluLCB0aGUgc2VuZGVyIG11c3QgZmly
c3Qgc2VsZWN0IGEKICAgUHJpbWFyeSBLZXksIEtfTiwgYW5kIGEgUFJGIGZ1bmN0aW9uLCBm
IChTZWN0aW9uIDcsIFRFU0xBLVBSRikuICBUaGUKICAgcmFuZG9tbmVzcyBvZiB0aGUgUHJp
bWFyeSBLZXksIEtfTiwgaXMgdml0YWwgdG8gdGhlIHNlY3VyaXR5IGFuZCBubwogICBvbmUg
c2hvdWxkIGJlIGFibGUgdG8gZ3Vlc3MgaXQuCgogICBUaGUgZnVuY3Rpb24gRiBpcyBhIG9u
ZS13YXkgZnVuY3Rpb24gdGhhdCBpcyBkZWZpbmVkIGFzOiBGKGspID0KICAgZl9rKDApLCB3
aGVyZSBmX2soMCkgaXMgdGhlIHJlc3VsdCBvZiB0aGUgYXBwbGljYXRpb24gb2YgdGhlIFBS
RiBmIHRvCiAgIGsgYW5kIDAuICBXaGVuIGYgaXMgYSBITUFDIChTZWN0aW9uIDcpLCBrIGlz
IHVzZWQgYXMgdGhlIGtleSwgYW5kIDAKICAgYXMgdGhlIG1lc3NhZ2UsIHVzaW5nIHRoZSBh
bGdvcml0aG0gZGVzY3JpYmVkIGluIFtSRkMyMTA0XS4KICAgU2ltaWxhcmx5LCB0aGUgZnVu
Y3Rpb24gRicgaXMgYSBvbmUtd2F5IGZ1bmN0aW9uIHRoYXQgaXMgZGVmaW5lZCBhczoKICAg
RicoaykgPSBmX2soMSksIHdoZXJlIGZfaygxKSBpcyB0aGUgcmVzdWx0IG9mIHRoZSBhcHBs
aWNhdGlvbiBvZiB0aGUKICAgc2FtZSBQUkYgZiB0byBrIGFuZCAxLgoKICAgVGhlIHNlbmRl
ciB0aGVuIGNvbXB1dGVzIGFsbCB0aGUga2V5cyBvZiB0aGUgY2hhaW4sIHJlY3Vyc2l2ZWx5
LAogICBzdGFydGluZyB3aXRoIEtfTiwgdXNpbmc6IEtfe2ktMX0gPSBGKEtfaSkuICBUaGVy
ZWZvcmU6IEtfaSA9IEZee04tCiAgIGl9KEtfTiksIHdoZXJlIEZeaSh4KSBpcyB0aGUgZXhl
Y3V0aW9uIG9mIGZ1bmN0aW9uIEYgd2l0aCB0aGUKICAgYXJndW1lbnQgeCwgaSB0aW1lcy4g
IFRoZSByZWNlaXZlciBjYW4gdGhlbiBjb21wdXRlIGFueSB2YWx1ZSBpbiB0aGUKICAga2V5
IGNoYWluIGZyb20gS19OLCBldmVuIGlmIGl0IGRvZXMgbm90IGhhdmUgaW50ZXJtZWRpYXRl
IHZhbHVlcwogICBbUkZDNDA4Ml0uICBUaGUga2V5IGZvciBNQUMgY2FsY3VsYXRpb24gY2Fu
IHRoZW4gYmUgZGVyaXZlZCBmcm9tIHRoZQogICBjb3JyZXNwb25kaW5nIEtfaSBrZXkgYnkg
SydfaSA9IEYnKEtfaSkuCgogICBUaGUga2V5IGNoYWluIGhhcyBhIGZpbml0ZSBsZW5ndGgs
IE4sIHdoaWNoIGNvcnJlc3BvbmRzIHRvIGEgbWF4aW11bQogICB0aW1lIGR1cmF0aW9uIG9m
IChOICsgMSkgKiBUX2ludC4gIFRoZSBjb250ZW50IGRlbGl2ZXJ5IHNlc3Npb24gaGFzIGEK
CgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAg
ICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNM
QSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgZHVyYXRp
b24gVF9kZWxpdmVyeSwgd2hpY2ggbWF5IGVpdGhlciBiZSBrbm93biBpbiBhZHZhbmNlLCBv
ciBub3QuICBBCiAgIGZpcnN0IHNvbHV0aW9uIGNvbnNpc3RzIGluIGhhdmluZyBhIHNpbmds
ZSBrZXkgY2hhaW4gb2YgYW4KICAgYXBwcm9wcmlhdGUgbGVuZ3RoLCBzbyB0aGF0IHRoZSBj
b250ZW50IGRlbGl2ZXJ5IHNlc3Npb24gZmluaXNoZXMKICAgYmVmb3JlIHRoZSBlbmQgb2Yg
dGhlIGtleSBjaGFpbiwgaS5lLiwgVF9kZWxpdmVyeSA8PSAoTiArIDEpICogVF9pbnQuCiAg
IEJ1dCB0aGUgbG9uZ2VyIHRoZSBrZXkgY2hhaW4sIHRoZSBoaWdoZXIgdGhlIG1lbW9yeSBh
bmQgY29tcHV0YXRpb24KICAgcmVxdWlyZWQgdG8gY29wZSB3aXRoIGl0LiAgQW5vdGhlciBz
b2x1dGlvbiBjb25zaXN0cyBpbiBzd2l0Y2hpbmcgdG8KICAgYSBuZXcga2V5IGNoYWluLCBv
ZiB0aGUgc2FtZSBsZW5ndGgsIHdoZW4gbmVjZXNzYXJ5IFtQZXJyaWcwNF0uCgozLjEuMi4y
LiAgVXNpbmcgTXVsdGlwbGUgS2V5IENoYWlucwoKICAgV2hlbiBzZXZlcmFsIGtleSBjaGFp
bnMgYXJlIG5lZWRlZCwgYWxsIG9mIHRoZW0gTVVTVCBiZSBvZiB0aGUgc2FtZQogICBsZW5n
dGguICBTd2l0Y2hpbmcgZnJvbSB0aGUgY3VycmVudCBrZXkgY2hhaW4gdG8gdGhlIG5leHQg
b25lCiAgIHJlcXVpcmVzIHRoYXQgYSBjb21taXRtZW50IHRvIHRoZSBuZXcga2V5IGNoYWlu
IGJlIGNvbW11bmljYXRlZCBpbiBhCiAgIHNlY3VyZSB3YXkgdG8gdGhlIHJlY2VpdmVyLiAg
VGhpcyBjYW4gYmUgZG9uZSBieSB1c2luZyBlaXRoZXIgYW4gb3V0LQogICBvZi1iYW5kIG1l
Y2hhbmlzbSwgb3IgYW4gaW4tYmFuZCBtZWNoYW5pc20uICBUaGlzIGRvY3VtZW50IG9ubHkK
ICAgc3BlY2lmaWVzIHRoZSBpbi1iYW5kIG1lY2hhbmlzbS4KCgogICA8IC0tLS0tLS0tIG9s
ZCBrZXkgY2hhaW4gLS0tLS0tLS0tID58fDwgLS0tLS0tLS0gbmV3IGtleSBjaGFpbiAtLS4u
LgogICArLS0tLS0rLS0tLS0rIC4uICstLS0tLSstLS0tLSstLS0tLSt8fCstLS0tLSstLS0t
LSstLS0tLSstLS0tLSstLS0tLSsKICAgICAgMCAgICAgMSAgICAuLiAgIE4tMiAgIE4tMSAg
ICBOICAgfHwgIE4rMSAgIE4rMiAgIE4rMyAgIE4rNCAgIE4rNQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8fAogICBLZXkgZGlzY2xvc3VyZXM6ICAgICAgICAg
ICAgICAgICAgICB8fAogICAgIE4vQSAgIE4vQSAgIC4uICBLX04tNCBLX04tMyBLX04tMiB8
fCBLX04tMSAgS19OICBLX04rMSBLX04rMiBLX04rMwogICAgICAgICAgICAgICAgICAgIHwg
ICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwKICAg
ICAgICAgICAgICAgICAgICB8PCAtLS0tLS0tLS0tLS0tLSA+fHwgICAgICAgICAgICB8PCAt
LS0tLS0tLS0tLS0tID58CiAgIEFkZGl0aW9uYWwga2V5ICAgICAgICBGKEtfTisxKSAgICAg
IHx8ICAgICAgICAgICAgICAgICAgIEtfTgogICBkaXNjbG9zdXJlcyAgICAgICAgKGNvbW1p
dG1lbnQgdG8gICB8fCAgICAgICAgICAgICAgKGxhc3Qga2V5IG9mIHRoZQogICAoaW4gcGFy
YWxsZWwpOiAgICAgIHRoZSBuZXcgY2hhaW4pICB8fCAgICAgICAgICAgICAgICAgb2xkIGNo
YWluKQoKICAgICAgIEZpZ3VyZSAxOiBTd2l0Y2hpbmcgdG8gdGhlIHNlY29uZCBrZXkgY2hh
aW4gd2l0aCB0aGUgaW4tYmFuZAogICAgICAgbWVjaGFuaXNtLCBhc3N1bWluZyB0aGF0IGQ9
Miwgbl90eF9uZXdrY2M9Mywgbl90eF9sYXN0a2V5PTMuCgogICBGaWd1cmUgMSBpbGx1c3Ry
YXRlcyB0aGUgc3dpdGNoIHRvIHRoZSBuZXcga2V5IGNoYWluLCB1c2luZyB0aGUgaW4tCiAg
IGJhbmQgbWVjaGFuaXNtLiAgTGV0IHVzIHNheSB0aGF0IHRoZSBvbGQga2V5IGNoYWluIHN0
b3BzIGF0IEtfTiBhbmQKICAgdGhlIG5ldyBrZXkgY2hhaW4gc3RhcnRzIGF0IEtfe04rMX0g
KGkuZS4sIEYoS197TisxfSkgYW5kIEtfTiBhcmUgdHdvCiAgIGRpZmZlcmVudCBrZXlzKS4g
IFRoZW4gdGhlIHNlbmRlciBpbmNsdWRlcyB0aGUgY29tbWl0bWVudCBGKEtfe04rMX0pCiAg
IHRvIHRoZSBuZXcga2V5IGNoYWluIGludG8gcGFja2V0cyBhdXRoZW50aWNhdGVkIHdpdGgg
dGhlIG9sZCBrZXkKICAgY2hhaW4gKHNlZSBTZWN0aW9uIDMuNC41KS4gIFRoaXMgY29tbWl0
bWVudCBTSE9VTEQgYmUgc2VudCBkdXJpbmcKICAgbl90eF9uZXdrY2MgdGltZSBpbnRlcnZh
bHMgYmVmb3JlIHRoZSBlbmQgb2YgdGhlIG9sZCBrZXkgY2hhaW4uCiAgIFNpbmNlIHNldmVy
YWwgcGFja2V0cyBhcmUgdXN1YWxseSBzZW50IGR1cmluZyBhbiBpbnRlcnZhbCwgdGhlIHNl
bmRlcgogICBTSE9VTEQgYWx0ZXJuYXRlIGJldHdlZW4gc2VuZGluZyBhIGRpc2Nsb3NlZCBr
ZXkgb2YgdGhlIG9sZCBrZXkgY2hhaW4KICAgYW5kIHRoZSBjb21taXRtZW50IHRvIHRoZSBu
ZXcga2V5IGNoYWluLiAgVGhlIGRldGFpbHMgb2YgaG93IHRvCiAgIGFsdGVybmF0ZSBiZXR3
ZWVuIHRoZSBkaXNjbG9zdXJlIGFuZCBjb21taXRtZW50IGFyZSBvdXQgb2YgdGhlIHNjb3Bl
CiAgIG9mIHRoaXMgZG9jdW1lbnQuCgogICBUaGUgcmVjZWl2ZXIgd2lsbCBrZWVwIHRoZSBj
b21taXRtZW50IHVudGlsIHRoZSBrZXkgS197TisxfSBpcwogICBkaXNjbG9zZWQsIGF0IGlu
dGVydmFsIE4rMStkLiAgVGhlbiB0aGUgcmVjZWl2ZXIgd2lsbCBiZSBhYmxlIHRvIHRlc3QK
CgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAg
ICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNM
QSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgdGhlIHZh
bGlkaXR5IG9mIHRoYXQga2V5IGJ5IGNvbXB1dGluZyBGKEtfe04rMX0pIGFuZCBjb21wYXJp
bmcgaXQgdG8KICAgdGhlIGNvbW1pdG1lbnQuCgogICBXaGVuIHRoZSBrZXkgY2hhaW4gaXMg
Y2hhbmdlZCwgaXQgYmVjb21lcyBpbXBvc3NpYmxlIHRvIHJlY292ZXIgYQogICBwcmV2aW91
cyBrZXkgZnJvbSB0aGUgb2xkIGtleSBjaGFpbi4gIFRoaXMgaXMgYSBwcm9ibGVtIGlmIHRo
ZQogICByZWNlaXZlciBsb3N0IHRoZSBwYWNrZXRzIGRpc2Nsb3NpbmcgdGhlIGxhc3Qga2V5
IG9mIHRoZSBvbGQga2V5CiAgIGNoYWluLiAgQSBzb2x1dGlvbiBjb25zaXN0cyBpbiByZS1z
ZW5kaW5nIHRoZSBsYXN0IGtleSwgS19OLCBvZiB0aGUKICAgb2xkIGtleSBjaGFpbiAoc2Vl
IFNlY3Rpb24gMy40LjYpLiAgVGhpcyBTSE9VTEQgYmUgZG9uZSBkdXJpbmcKICAgbl90eF9s
YXN0a2V5IGFkZGl0aW9uYWwgdGltZSBpbnRlcnZhbHMgYWZ0ZXIgdGhlIGVuZCBvZiB0aGUg
dGltZQogICBpbnRlcnZhbCB3aGVyZSBLX04gaXMgZGlzY2xvc2VkLiAgU2luY2Ugc2V2ZXJh
bCBwYWNrZXRzIGFyZSB1c3VhbGx5CiAgIHNlbnQgZHVyaW5nIGFuIGludGVydmFsLCB0aGUg
c2VuZGVyIFNIT1VMRCBhbHRlcm5hdGUgYmV0d2VlbiBzZW5kaW5nCiAgIGEgZGlzY2xvc2Vk
IGtleSBvZiB0aGUgbmV3IGtleSBjaGFpbiwgYW5kIHRoZSBsYXN0IGtleSBvZiB0aGUgb2xk
IGtleQogICBjaGFpbi4gIFRoZSBkZXRhaWxzIG9mIGhvdyB0byBhbHRlcm5hdGUgYmV0d2Vl
biB0aGUgdHdvIGRpc2Nsb3N1cmVzCiAgIGFyZSBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMg
ZG9jdW1lbnQuCgogICBJbiBzb21lIGNhc2VzIGEgcmVjZWl2ZXIgaGF2aW5nIGV4cGVyaWVu
Y2VkIGEgdmVyeSBsb25nIGRpc2Nvbm5lY3Rpb24KICAgbWlnaHQgaGF2ZSBsb3N0IHRoZSBj
b21taXRtZW50IG9mIHRoZSBuZXcgY2hhaW4uICBUaGVyZWZvcmUgdGhpcwogICByZWNlaXZl
ciB3aWxsIG5vdCBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZSBhbnkgcGFja2V0IHJlbGF0ZWQg
dG8gdGhlCiAgIG5ldyBjaGFpbiBhbmQgYWxsIHRoZSBmb2xsb3dpbmcgb25lcy4gIFRoZSBv
bmx5IHNvbHV0aW9uIGZvciB0aGlzCiAgIHJlY2VpdmVyIHRvIGNhdGNoIHVwIGNvbnNpc3Rz
IGluIHJlY2VpdmluZyBhbiBhZGRpdGlvbmFsIGJvb3RzdHJhcAogICBpbmZvcm1hdGlvbiBt
ZXNzYWdlLiAgVGhpcyBjYW4gaGFwcGVuIGJ5IHdhaXRpbmcgZm9yIHRoZSBuZXh0CiAgIHBl
cmlvZGljIHRyYW5zbWlzc2lvbiAoaWYgc2VudCBpbi1iYW5kKSBvciB0aHJvdWdoIGFuIGV4
dGVybmFsCiAgIG1lY2hhbmlzbSAoU2VjdGlvbiAzLjIuMSkuCgozLjEuMi4zLiAgVmFsdWVz
IG9mIHRoZSBuX3R4X2xhc3RrZXkgYW5kIG5fdHhfbmV3a2NjIFBhcmFtZXRlcnMKCiAgIFdo
ZW4gc2V2ZXJhbCBrZXkgY2hhaW5zIGFuZCB0aGUgaW4tYmFuZCBjb21taXRtZW50IG1lY2hh
bmlzbSBhcmUKICAgdXNlZCwgYSBzZW5kZXIgTVVTVCBpbml0aWFsaXplIHRoZSBuX3R4X2xh
c3RrZXkgYW5kIG5fdHhfbmV3a2NjCiAgIHBhcmFtZXRlcnMgaW4gc3VjaCBhIHdheSB0aGF0
IG5vIG92ZXJsYXBwaW5nIG9jY3VyLiAgSW4gb3RoZXIgd29yZHMsCiAgIG9uY2UgYSBzZW5k
ZXIgc3RhcnRzIHRyYW5zbWl0dGluZyBjb21taXRtZW50cyBmb3IgYSBuZXcga2V5IGNoYWlu
LCBoZQogICBNVVNUIE5PVCBzZW5kIGEgZGlzY2xvc3VyZSBmb3IgdGhlIGxhc3Qga2V5IG9m
IHRoZSBvbGQga2V5IGNoYWluIGFueQogICBtb3JlLiAgVGhlcmVmb3JlLCB0aGUgZm9sbG93
aW5nIHByb3BlcnR5IE1VU1QgYmUgdmVyaWZpZWQ6CgogICAgICBkICsgbl90eF9sYXN0a2V5
ICsgbl90eF9uZXdrY2MgPD0gTiArIDEKCiAgIEl0IGlzIFJFQ09NTUVOREVELCBmb3Igcm9i
dXN0bmVzcyBwdXJwb3NlcywgdGhhdCwgb25jZSBuX3R4X2xhc3RrZXkKICAgaGFzIGJlZW4g
Y2hvc2VuLCB0aGVuOgoKICAgICAgbl90eF9uZXdrY2MgPSBOICsgMSAtIG5fdHhfbGFzdGtl
eSAtIGQKCiAgIEluIG90aGVyIHdvcmRzLCB0aGUgc2VuZGVyIHN0YXJ0cyB0cmFuc21pdHRp
bmcgYSBjb21taXRtZW50IHRvIHRoZQogICBmb2xsb3dpbmcga2V5IGNoYWluIGltbWVkaWF0
ZWx5IGFmdGVyIGhhdmluZyBzZW50IGFsbCB0aGUgZGlzY2xvc3VyZXMKICAgb2YgdGhlIGxh
c3Qga2V5IG9mIHRoZSBwcmV2aW91cyBrZXkgY2hhaW4uICBEb2luZyBzbyBpbmNyZWFzZXMg
dGhlCiAgIHByb2JhYmlsaXR5IHRoYXQgYSByZWNlaXZlciBnZXRzIGEgY29tbWl0bWVudCBm
b3IgdGhlIGZvbGxvd2luZyBrZXkKICAgY2hhaW4uCgogICBJbiBhbnkgY2FzZSwgdGhlc2Ug
dHdvIHBhcmFtZXRlcnMgYXJlIHNlbmRlciBzcGVjaWZpYyBhbmQgbmVlZCBub3QgYmUKICAg
dHJhbnNtaXR0ZWQgdG8gdGhlIHJlY2VpdmVycy4gIE9mIGNvdXJzZSwgYXMgZXhwbGFpbmVk
IGFib3ZlLCB0aGUKCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2gg
MjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMTldCgwKSW50ZXJuZXQtRHJhZnQgICAg
ICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5
CgoKICAgc2VuZGVyIGFsdGVybmF0ZXMgYmV0d2VlbiB0aGUgZGlzY2xvc3VyZSBvZiBhIGtl
eSBvZiB0aGUgY3VycmVudCBrZXkKICAgY2hhaW4gYW5kIHRoZSBjb21taXRtZW50IHRvIHRo
ZSBuZXcga2V5IGNoYWluIChvciB0aGUgbGFzdCBrZXkgb2YgdGhlCiAgIG9sZCBrZXkgY2hh
aW4pLgoKMy4xLjIuNC4gIFRoZSBQYXJ0aWN1bGFyIENhc2Ugb2YgdGhlIFNlc3Npb24gU3Rh
cnQKCiAgIFNpbmNlIGEga2V5IGNhbm5vdCBiZSBkaXNjbG9zZWQgYmVmb3JlIHRoZSBkaXNj
bG9zdXJlIGRlbGF5LCBkLCBubwogICBrZXkgd2lsbCBiZSBkaXNjbG9zZWQgZHVyaW5nIHRo
ZSBmaXJzdCBkIHRpbWUgaW50ZXJ2YWxzIChpbnRlcnZhbHMgMAogICBhbmQgMSBpbiBGaWd1
cmUgMSkgb2YgdGhlIHNlc3Npb24uICBUbyB0aGF0IHB1cnBvc2UsIHRoZSBzZW5kZXIgdXNl
cwogICB0aGUgQXV0aGVudGljYXRpb24gVGFnIFdpdGhvdXQgS2V5IERpc2Nsb3N1cmUgU2Vj
dGlvbiAzLjQuNC4gIFRoZQogICBmb2xsb3dpbmcga2V5IGNoYWlucywgaWYgYW55LCBhcmUg
bm90IGNvbmNlcm5lZCBzaW5jZSB0aGV5IHdpbGwKICAgZGlzY2xvc2UgdGhlIGxhc3QgZCBr
ZXlzIG9mIHRoZSBwcmV2aW91cyBjaGFpbi4KCjMuMS4yLjUuICBNYW5hZ2luZyBTaWxlbnQg
UGVyaW9kcwoKICAgQW4gQUxDIG9yIE5PUk0gc2VuZGVyIG1heSBzdG9wIHRyYW5zbWl0dGlu
ZyBwYWNrZXRzIGZvciBzb21lIHRpbWUuCiAgIEZvciBpbnN0YW5jZSBpdCBjYW4gYmUgdGhl
IGVuZCBvZiB0aGUgc2Vzc2lvbiBhbmQgYWxsIHBhY2tldHMgaGF2ZQogICBhbHJlYWR5IGJl
ZW4gc2VudCwgb3IgdGhlIHVzZS1jYXNlIG1heSBjb25zaXN0IGluIGEgc3VjY2Vzc2lvbiBv
ZgogICBidXN5IHBlcmlvZHMgKHdoZW4gZnJlc2ggb2JqZWN0cyBhcmUgYXZhaWxhYmxlKSBm
b2xsb3dlZCBieSBzaWxlbnQKICAgcGVyaW9kcy4gIEluIGFueSBjYXNlLCB0aGlzIGlzIGFu
IGlzc3VlIHNpbmNlIHRoZSBhdXRoZW50aWNhdGlvbiBvZgogICB0aGUgcGFja2V0cyBzZW50
IGR1cmluZyB0aGUgbGFzdCBkIGludGVydmFscyByZXF1aXJlcyB0aGF0IHRoZQogICBhc3Nv
Y2lhdGVkIGtleXMgYmUgZGlzY2xvc2VkLCB3aGljaCB3aWxsIHRha2UgcGxhY2UgZHVyaW5n
IGQKICAgYWRkaXRpb25hbCB0aW1lIGludGVydmFscy4KCiAgIFRvIHNvbHZlIHRoaXMgcHJv
YmxlbSwgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgc2VuZGVyIHRyYW5zbWl0CiAgIGVt
cHR5IHBhY2tldHMgKGkuZS4sIHdpdGhvdXQgcGF5bG9hZCkgY29udGFpbmluZyB0aGUgVEVT
TEEgRVhUX0FVVEgKICAgaGVhZGVyIGV4dGVuc2lvbiBhbG9uZyB3aXRoIGEgU3RhbmRhcmQg
QXV0aGVudGljYXRpb24gVGFnIGR1cmluZyBhdAogICBsZWFzdCBkIHRpbWUgaW50ZXJ2YWxz
IGFmdGVyIHRoZSBlbmQgb2YgdGhlIHJlZ3VsYXIgQUxDIG9yIE5PUk0KICAgcGFja2V0IHRy
YW5zbWlzc2lvbnMuICBUaGUgbnVtYmVyIG9mIHN1Y2ggcGFja2V0cyBhbmQgdGhlIGR1cmF0
aW9uCiAgIGR1cmluZyB3aGljaCB0aGV5IGFyZSBzZW50IG11c3QgYmUgc3VmZmljaWVudCBm
b3IgYWxsIHJlY2VpdmVycyB0bwogICByZWNlaXZlLCB3aXRoIGEgaGlnaCBwcm9iYWJpbGl0
eSwgYXQgbGVhc3Qgb25lIHBhY2tldCBkaXNjbG9zaW5nIHRoZQogICBsYXN0IHVzZWZ1bCBr
ZXkgKGkuZS4sIHRoZSBrZXkgdXNlZCBmb3IgdGhlIGxhc3Qgbm9uLWVtcHR5IHBhY2tldAog
ICBzZW50KS4KCjMuMS4zLiAgVGltZSBJbnRlcnZhbCBTY2hlZHVsZQoKICAgVGhlIHNlbmRl
ciBtdXN0IGRldGVybWluZSB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6CgogICBvICBUXzAs
IHRoZSBzdGFydCB0aW1lIGNvcnJlc3BvbmRpbmcgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUg
c2Vzc2lvbiwKICAgICAgaS5lLiwgdGhlIGJlZ2lubmluZyBvZiB0aW1lIGludGVydmFsIDAg
KGluIE5UUCB0aW1lc3RhbXAgZm9ybWF0KTsKCiAgIG8gIFRfaW50LCB0aGUgaW50ZXJ2YWwg
ZHVyYXRpb24gKGluIG1pbGxpc2Vjb25kcyksIHVzdWFsbHkgcmFuZ2luZwogICAgICBmcm9t
IDEwMCBtaWxsaXNlY29uZHMgdG8gMSBzZWNvbmQ7CgogICBvICBkLCB0aGUga2V5IGRpc2Ns
b3N1cmUgZGVsYXkgKGluIG51bWJlciBvZiBpbnRlcnZhbHMpLiAgSXQgaXMgdGhlCiAgICAg
IHRpbWUgdG8gd2FpdCBiZWZvcmUgZGlzY2xvc2luZyBhIGtleTsKCgoKCgpSb2NhLCBldCBh
bC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBb
UGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQg
Tk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICBvICBOLCB0aGUgbGVuZ3RoIG9m
IGEga2V5IGNoYWluOwoKICAgVGhlIGNvcnJlY3QgY2hvaWNlIG9mIFRfaW50LCBkLCBhbmQg
TiBpcyBjcnVjaWFsIGZvciB0aGUgZWZmaWNpZW5jeQogICBvZiB0aGUgc2NoZW1lLiAgRm9y
IGluc3RhbmNlLCBhIFRfaW50ICogZCBwcm9kdWN0IHRoYXQgaXMgdG9vIGxvbmcKICAgd2ls
bCBjYXVzZSBleGNlc3NpdmUgZGVsYXkgaW4gdGhlIGF1dGhlbnRpY2F0aW9uIHByb2Nlc3Mu
ICBBIFRfaW50ICoKICAgZCBwcm9kdWN0IHRoYXQgaXMgdG9vIHNob3J0IHByZXZlbnRzIG1h
bnkgcmVjZWl2ZXJzIGZyb20gdmVyaWZ5aW5nCiAgIHBhY2tldHMuICBBIE4gKiBUX2ludCBw
cm9kdWN0IHRoYXQgaXMgdG9vIHNtYWxsIHdpbGwgY2F1c2UgdGhlIHNlbmRlcgogICB0byBz
d2l0Y2ggdG9vIG9mdGVuIHRvIG5ldyBrZXkgY2hhaW5zLiAgQSBOIHRoYXQgaXMgdG9vIGxv
bmcgd2l0aAogICByZXNwZWN0IHRvIHRoZSBleHBlY3RlZCBzZXNzaW9uIGR1cmF0aW9uIChp
ZiBrbm93bikgd2lsbCByZXF1aXJlIHRoZQogICBzZW5kZXIgdG8gY29tcHV0ZSB0b28gbWFu
eSB1c2VsZXNzIGtleXMuICBbUkZDNDA4Ml0gc2VjdGlvbnMgMy4yIGFuZAogICAzLjYgZ2l2
ZSBnZW5lcmFsIGd1aWRlbGluZXMgZm9yIGluaXRpYWxpemluZyB0aGVzZSBwYXJhbWV0ZXJz
LgoKICAgVGhlIFRfMCwgVF9pbnQsIGQgYW5kIE4gcGFyYW1ldGVycyBNVVNUIE5PVCBiZSBj
aGFuZ2VkIGR1cmluZyB0aGUKICAgbGlmZXRpbWUgb2YgdGhlIHNlc3Npb24uICBUaGlzIHJl
c3RyaWN0aW9uIGlzIG1lYW50IHRvIHByZXZlbnQKICAgaW50cm9kdWNpbmcgdnVsbmVyYWJp
bGl0aWVzLiAgRm9yIGluc3RhbmNlIGlmIGEgc2VuZGVyIHdhcyBhdXRob3JpemVkCiAgIHRv
IGNoYW5nZSB0aGUga2V5IGRpc2Nsb3N1cmUgc2NoZWR1bGUsIGEgcmVjZWl2ZXIgdGhhdCBk
aWQgbm90CiAgIHJlY2VpdmUgdGhlIGNoYW5nZSBub3RpZmljYXRpb24gd291bGQgc3RpbGwg
YmVsaWV2ZSBpbiB0aGUgb2xkIGtleQogICBkaXNjbG9zdXJlIHNjaGVkdWxlLCB0aGVyZWJ5
IGNyZWF0aW5nIHZ1bG5lcmFiaWxpdGllcyBbUkZDNDA4Ml0uCgozLjEuNC4gIFRpbWluZyBQ
YXJhbWV0ZXJzCgogICBJbiBpbmRpcmVjdCB0aW1lIHN5bmNocm9uaXphdGlvbiBtb2RlLCB0
aGUgc2VuZGVyIG11c3QgZGV0ZXJtaW5lIHRoZQogICBmb2xsb3dpbmcgcGFyYW1ldGVyOgoK
ICAgbyAgRF5PX3QsIHRoZSB1cHBlciBib3VuZCBvZiB0aGUgbGFnIG9mIHRoZSBzZW5kZXIn
cyBjbG9jayB3aXRoCiAgICAgIHJlc3BlY3QgdG8gdGhlIHRpbWUgcmVmZXJlbmNlLgoKICAg
VGhlIEReT190IHBhcmFtZXRlciBNVVNUIE5PVCBiZSBjaGFuZ2VkIGR1cmluZyB0aGUgbGlm
ZXRpbWUgb2YgdGhlCiAgIHNlc3Npb24uCgozLjIuICBURVNMQSBTaWduYWxpbmcgTWVzc2Fn
ZXMKCiAgIEF0IGEgc2VuZGVyLCBURVNMQSBwcm9kdWNlcyB0d28gdHlwZXMgb2Ygc2lnbmFs
aW5nIGluZm9ybWF0aW9uOgoKICAgbyAgVGhlIGJvb3RzdHJhcCBpbmZvcm1hdGlvbjogaXQg
Y2FuIGJlIGVpdGhlciBzZW50IG91dC1vZi1iYW5kIG9yCiAgICAgIGluLWJhbmQuICBJbiB0
aGUgbGF0dGVyIGNhc2UsIGEgZGlnaXRhbGx5IHNpZ25lZCBwYWNrZXQgY29udGFpbnMKICAg
ICAgYWxsIHRoZSBpbmZvcm1hdGlvbiByZXF1aXJlZCB0byBib290c3RyYXAgVEVTTEEgYXQg
YSByZWNlaXZlcjsKCiAgIG8gIFRoZSBkaXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24gcmVz
cG9uc2UsIHdoaWNoIGVuYWJsZXMgYSByZWNlaXZlcgogICAgICB0byBmaW5pc2ggYSBkaXJl
Y3QgdGltZSBzeW5jaHJvbml6YXRpb247CgozLjIuMS4gIEJvb3RzdHJhcCBJbmZvcm1hdGlv
bgoKICAgSW4gb3JkZXIgdG8gaW5pdGlhbGl6ZSB0aGUgVEVTTEEgY29tcG9uZW50IGF0IGEg
cmVjZWl2ZXIsIHRoZSBzZW5kZXIKICAgbXVzdCBjb21tdW5pY2F0ZSBzb21lIGtleSBpbmZv
cm1hdGlvbiBpbiBhIHNlY3VyZSB3YXkuICBUaGlzCiAgIGluZm9ybWF0aW9uIGNhbiBiZSBz
ZW50IGluLWJhbmQgb3Igb3V0LW9mLWJhbmQsIGFzIGRpc2N1c3NlZCBpbgogICBTZWN0aW9u
IDIuMi4gIEluIHRoaXMgc2VjdGlvbiB3ZSBvbmx5IGNvbnNpZGVyIHRoZSBpbi1iYW5kIHNj
aGVtZS4KCgoKClJvY2EsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwLCAy
MDEwICAgICAgICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg
ICAgVEVTTEEgaW4gQUxDIGFuZCBOT1JNICAgICAgICAgICBTZXB0ZW1iZXIgMjAwOQoKCiAg
IFRoZSBURVNMQSBib290c3RyYXAgaW5mb3JtYXRpb24gbWVzc2FnZSBNVVNUIGJlIGRpZ2l0
YWxseSBzaWduZWQKICAgKFNlY3Rpb24gMy4zLjIpLiAgVGhlIGdvYWwgaXMgdG8gZW5hYmxl
IGEgcmVjZWl2ZXIgdG8gY2hlY2sgdGhlCiAgIHBhY2tldCBzb3VyY2UgYW5kIHBhY2tldCBp
bnRlZ3JpdHkuICBUaGVuLCB0aGUgYm9vdHN0cmFwIGluZm9ybWF0aW9uCiAgIGNhbiBiZToK
CiAgIG8gIHVuaWNhc3QgdG8gYSByZWNlaXZlciBkdXJpbmcgYSBkaXJlY3QgdGltZSBzeW5j
aHJvbml6YXRpb24KICAgICAgcmVxdWVzdC9yZXNwb25zZSBleGNoYW5nZTsKCiAgIG8gIGJy
b2FkY2FzdCB0byBhbGwgcmVjZWl2ZXJzLiAgVGhpcyBpcyB0eXBpY2FsbHkgdGhlIGNhc2Ug
aW4KICAgICAgaW5kaXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24gbW9kZS4gIEl0IGNhbiBh
bHNvIGJlIHVzZWQgaW4gZGlyZWN0CiAgICAgIHRpbWUgc3luY2hyb25pemF0aW9uIG1vZGUs
IGZvciBpbnN0YW5jZSB3aGVuIGEgbGFyZ2UgbnVtYmVyIG9mCiAgICAgIGNsaWVudHMgYXJy
aXZlIGF0IHRoZSBzYW1lIHRpbWUsIGluIHdoaWNoIGNhc2UgaXQgaXMgbW9yZQogICAgICBl
ZmZpY2llbnQgdG8gYW5zd2VyIGdsb2JhbGx5LgoKICAgTGV0IHVzIGNvbnNpZGVyIHNpdHVh
dGlvbnMgd2hlcmUgdGhlIGJvb3RzdHJhcCBpbmZvcm1hdGlvbiBpcwogICBicm9hZGNhc3Qu
ICBUaGlzIG1lc3NhZ2Ugc2hvdWxkIGJlIGJyb2FkY2FzdCBhdCB0aGUgYmVnaW5uaW5nIG9m
IHRoZQogICBzZXNzaW9uLCBiZWZvcmUgZGF0YSBwYWNrZXRzIGFyZSBhY3R1YWxseSBzZW50
LiAgVGhpcyBpcyBwYXJ0aWN1bGFybHkKICAgaW1wb3J0YW50IHdpdGggQUxDIG9yIE5PUk0g
c2Vzc2lvbnMgaW4gInB1c2giIG1vZGUsIHdoZW4gYWxsIGNsaWVudHMKICAgam9pbiB0aGUg
c2Vzc2lvbiBpbiBhZHZhbmNlLiAgRm9yIGltcHJvdmVkIHJlbGlhYmlsaXR5LCBib290c3Ry
YXAKICAgaW5mb3JtYXRpb24gbWlnaHQgYmUgc2VudCBhIGNlcnRhaW4gbnVtYmVyIG9mIHRp
bWVzLgoKICAgQSBwZXJpb2RpYyBicm9hZGNhc3Qgb2YgdGhlIGJvb3RzdHJhcCBpbmZvcm1h
dGlvbiBtZXNzYWdlIGNvdWxkIGFsc28KICAgYmUgdXNlZnVsIHdoZW46CgogICBvICB0aGUg
QUxDIHNlc3Npb24gdXNlcyBhbiAib24tZGVtYW5kIiBtb2RlLCBjbGllbnRzIGFycml2aW5n
IGF0CiAgICAgIHRoZWlyIG93biBkaXNjcmV0aW9uOwoKICAgbyAgc29tZSBjbGllbnRzIGV4
cGVyaWVuY2UgYW4gaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eS4gIFRoaXMgaXMKICAgICAg
cGFydGljdWxhcmx5IGltcG9ydGFudCB3aGVuIHNldmVyYWwga2V5IGNoYWlucyBhcmUgdXNl
ZCBpbiBhbiBBTEMKICAgICAgb3IgTk9STSBzZXNzaW9uLCBzaW5jZSB0aGVyZSBpcyBhIHJp
c2sgdGhhdCBhIHJlY2VpdmVyIGxvc2VzIGFsbAogICAgICB0aGUgY29tbWl0bWVudHMgdG8g
dGhlIG5ldyBrZXkgY2hhaW4uCgogICBBIGJhbGFuY2UgbXVzdCBiZSBmb3VuZCBiZXR3ZWVu
IHRoZSBzaWduYWxpbmcgb3ZlcmhlYWQgYW5kIHRoZQogICBtYXhpbXVtIGluaXRpYWwgd2Fp
dGluZyB0aW1lIGF0IHRoZSByZWNlaXZlciBiZWZvcmUgc3RhcnRpbmcgdGhlCiAgIGRlbGF5
ZWQgYXV0aGVudGljYXRpb24gcHJvY2Vzcy4gIEEgcGVyaW9kIG9mIGEgZmV3IHNlY29uZHMg
Zm9yIHRoZQogICB0cmFuc21pc3Npb24gb2YgdGhpcyBib290c3RyYXAgaW5mb3JtYXRpb24g
aXMgb2Z0ZW4gYSByZWFzb25hYmxlCiAgIHZhbHVlLgoKMy4yLjIuICBEaXJlY3QgVGltZSBT
eW5jaHJvbml6YXRpb24gUmVzcG9uc2UKCiAgIEluIERpcmVjdCBUaW1lIFN5bmNocm9uaXph
dGlvbiwgdXBvbiByZWNlaXB0IG9mIGEgc3luY2hyb25pemF0aW9uCiAgIHJlcXVlc3QsIHRo
ZSBzZW5kZXIgcmVjb3JkcyBpdHMgbG9jYWwgdGltZSwgdF9zLCBhbmQgc2VuZHMgYSByZXNw
b25zZQogICBtZXNzYWdlIHRoYXQgY29udGFpbnMgYm90aCB0X3IgYW5kIHRfcyAoU2VjdGlv
biAyLjQuMSkuICBUaGlzIG1lc3NhZ2UKICAgaXMgdW5pY2FzdCB0byB0aGUgcmVjZWl2ZXIu
ICBUaGlzIERpcmVjdCBUaW1lIFN5bmNocm9uaXphdGlvbgogICBSZXNwb25zZSBtZXNzYWdl
IE1VU1QgYmUgZGlnaXRhbGx5IHNpZ25lZCBpbiBvcmRlciB0byBlbmFibGUgYQogICByZWNl
aXZlciB0byBjaGVjayB0aGUgcGFja2V0IHNvdXJjZSBhbmQgcGFja2V0IGludGVncml0eQog
ICAoU2VjdGlvbiAzLjMuMikuICBUaGUgcmVjZWl2ZXIgTVVTVCBhbHNvIGJlIGFibGUgdG8g
YXNzb2NpYXRlIHRoaXMKICAgcmVzcG9uc2UgYW5kIGhpcyByZXF1ZXN0LCB3aGljaCBpcyB0
aGUgcmVhc29uIHdoeSB0X3IgaXMgaW5jbHVkZWQgaW4KCgoKUm9jYSwgZXQgYWwuICAgICAg
ICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMjJd
CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAg
ICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgdGhlIHJlc3BvbnNlIG1lc3NhZ2UuCgozLjMu
ICBURVNMQSBBdXRoZW50aWNhdGlvbiBJbmZvcm1hdGlvbgoKICAgQXQgYSBzZW5kZXIsIFRF
U0xBIHByb2R1Y2VzIHRocmVlIHR5cGVzIG9mIHNlY3VyaXR5IHRhZ3M6CgogICBvICBhbiBh
dXRoZW50aWNhdGlvbiB0YWcsIGluIGNhc2Ugb2YgZGF0YSBwYWNrZXRzLCBhbmQgd2hpY2gg
Y29udGFpbnMKICAgICAgdGhlIE1BQyBvZiB0aGUgcGFja2V0OwoKICAgbyAgYSBkaWdpdGFs
IHNpZ25hdHVyZSwgaW4gY2FzZSBvZiBvbmUgb2YgdGhlIHR3byBURVNMQSBzaWduYWxpbmcK
ICAgICAgcGFja2V0cywgbmFtZWx5IGEgQm9vdHN0cmFwIEluZm9ybWF0aW9uIE1lc3NhZ2Ug
b3IgYSBEaXJlY3QgVGltZQogICAgICBTeW5jaHJvbml6YXRpb24gUmVzcG9uc2U7IGFuZAoK
ICAgbyAgYW4gb3B0aW9uYWwgZ3JvdXAgYXV0aGVudGljYXRpb24gdGFnLCB0aGF0IGNhbiBi
ZSBhZGRlZCB0byBhbGwgdGhlCiAgICAgIHBhY2tldHMgdG8gbWl0aWdhdGUgYXR0YWNrcyBj
b21pbmcgZnJvbSBvdXRzaWRlIG9mIHRoZSBncm91cC4KCiAgIEJlY2F1c2Ugb2YgaW50ZXJk
ZXBlbmRlbmNpZXMsIHRoZWlyIGNvbXB1dGF0aW9uIE1VU1QgZm9sbG93IGEgc3RyaWN0CiAg
IG9yZGVyOgoKICAgbyAgZmlyc3Qgb2YgYWxsLCBjb21wdXRlIHRoZSBhdXRoZW50aWNhdGlv
biB0YWcgKHdpdGggZGF0YSBwYWNrZXQpIG9yCiAgICAgIHRoZSBkaWdpdGFsIHNpZ25hdHVy
ZSAod2l0aCBzaWduYWxpbmcgcGFja2V0KTsKCiAgIG8gIGZpbmFsbHkgY29tcHV0ZSB0aGUg
R3JvdXAgTWFjOwoKMy4zLjEuICBBdXRoZW50aWNhdGlvbiBUYWdzCgogICBBbGwgdGhlIGRh
dGEgcGFja2V0cyBzZW50IE1VU1QgaGF2ZSBhbiBhdXRoZW50aWNhdGlvbiB0YWcgY29udGFp
bmluZzoKCiAgIG8gIHRoZSBpbnRlcnZhbCBpbmRleCwgaSwgd2hpY2ggaXMgYWxzbyB0aGUg
aW5kZXggb2YgdGhlIGtleSB1c2VkIGZvcgogICAgICBjb21wdXRpbmcgdGhlIE1BQyBvZiB0
aGlzIHBhY2tldDsKCiAgIG8gIHRoZSBNQUMgb2YgdGhlIG1lc3NhZ2U6IE1BQyhLJ19pLCBN
KSwgd2hlcmUgSydfaT1GJyhLX2kpOwoKICAgbyAgZWl0aGVyIGEgZGlzY2xvc2VkIGtleSAo
dGhhdCBiZWxvbmdzIHRvIHRoZSBjdXJyZW50IGtleSBjaGFpbiBvcgogICAgICB0aGUgcHJl
dmlvdXMga2V5IGNoYWluKSwgb3IgYSBjb21taXRtZW50IHRvIGEgbmV3IGtleSBjaGFpbiwg
b3Igbm8KICAgICAga2V5IGF0IGFsbDsKCiAgIFRoZSBjb21wdXRhdGlvbiBvZiBNQUMoSydf
aSwgTSkgTVVTVCBpbmNsdWRlIHRoZSBBTEMgb3IgTk9STSBoZWFkZXIKICAgKHdpdGggdGhl
IHZhcmlvdXMgaGVhZGVyIGV4dGVuc2lvbnMpIGFuZCB0aGUgcGF5bG9hZCAod2hlbgogICBh
cHBsaWNhYmxlKS4gIFRoZSBVRFAvSVAgaGVhZGVycyBNVVNUIE5PVCBiZSBpbmNsdWRlZC4g
IER1cmluZyB0aGlzCiAgIGNvbXB1dGF0aW9uLCB0aGUgTUFDKEsnX2ksIE0pIGZpZWxkIG9m
IHRoZSBhdXRoZW50aWNhdGlvbiB0YWcgTVVTVCBiZQogICBzZXQgdG8gMC4KCjMuMy4yLiAg
RGlnaXRhbCBTaWduYXR1cmVzCgogICBUaGUgQm9vdHN0cmFwIEluZm9ybWF0aW9uIG1lc3Nh
Z2UgKHdpdGggdGhlIGluLWJhbmQgYm9vdHN0cmFwIHNjaGVtZSkKICAgYW5kIERpcmVjdCBU
aW1lIFN5bmNocm9uaXphdGlvbiBSZXNwb25zZSBtZXNzYWdlICh3aXRoIHRoZSBpbmRpcmVj
dAogICB0aW1lIHN5bmNocm9uaXphdGlvbiBzY2hlbWUpIGJvdGggbmVlZCB0byBiZSBzaWdu
ZWQgYnkgdGhlIHNlbmRlci4KCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMg
TWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMjNdCgwKSW50ZXJuZXQtRHJh
ZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJl
ciAyMDA5CgoKICAgVGhlc2UgdHdvIG1lc3NhZ2VzIGNvbnRhaW4gYSAiU2lnbmF0dXJlIiBm
aWVsZCB0byBob2xkIHRoZSBkaWdpdGFsCiAgIHNpZ25hdHVyZS4gIFRoZSBib290c3RyYXAg
aW5mb3JtYXRpb24gbWVzc2FnZSBhbHNvIGNvbnRhaW5zIHRoZQogICAiU2lnbmF0dXJlIEVu
Y29kaW5nIEFsZ29yaXRobSIsIHRoZSAiU2lnbmF0dXJlIENyeXB0b2dyYXBoaWMKICAgRnVu
Y3Rpb24iLCBhbmQgdGhlICJTaWduYXR1cmUgTGVuZ3RoIiBmaWVsZHMgdGhhdCBlbmFibGUg
YSByZWNlaXZlcgogICB0byBwcm9jZXNzIHRoZSAiU2lnbmF0dXJlIiBmaWVsZC4gIE5vdGUg
dGhhdCB0aGVyZSBpcyBubyBzdWNoCiAgICJTaWduYXR1cmUgRW5jb2RpbmcgQWxnb3JpdGht
IiwgIlNpZ25hdHVyZSBDcnlwdG9ncmFwaGljIEZ1bmN0aW9uIgogICBhbmQgIlNpZ25hdHVy
ZSBMZW5ndGgiIGZpZWxkcyBpbiBjYXNlIG9mIGEgRGlyZWN0IFRpbWUKICAgU3luY2hyb25p
emF0aW9uIFJlc3BvbnNlIG1lc3NhZ2Ugc2luY2UgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZXNl
CiAgIHBhcmFtZXRlcnMgYXJlIGFscmVhZHkga25vd24gKGkuZS4sIHRoZSByZWNlaXZlciBl
aXRoZXIgcmVjZWl2ZWQgYQogICBib290c3RyYXAgaW5mb3JtYXRpb24gbWVzc2FnZSBiZWZv
cmUsIG9yIHRoZXNlIHZhbHVlcyBoYXZlIGJlZW4KICAgY29tbXVuaWNhdGVkIG91dC1vZi1i
YW5kKS4KCiAgIFNldmVyYWwgIlNpZ25hdHVyZSBFbmNvZGluZyBBbGdvcml0aG1zIiBjYW4g
YmUgdXNlZCwgaW5jbHVkaW5nCiAgIFJTQVNTQS1QS0NTMS12MV81LCB0aGUgZGVmYXVsdCwg
YW5kIFJTQVNTQS1QU1MgKFNlY3Rpb24gNykuICBXaXRoCiAgIHRoZXNlIGVuY29kaW5ncywg
U0hBLTI1NiBpcyB0aGUgZGVmYXVsdCAiU2lnbmF0dXJlIENyeXB0b2dyYXBoaWMKICAgRnVu
Y3Rpb24iLgoKICAgVGhlIGNvbXB1dGF0aW9uIG9mIHRoZSBzaWduYXR1cmUgTVVTVCBpbmNs
dWRlIHRoZSBBTEMgb3IgTk9STSBoZWFkZXIKICAgKHdpdGggdGhlIHZhcmlvdXMgaGVhZGVy
IGV4dGVuc2lvbnMpIGFuZCB0aGUgcGF5bG9hZCB3aGVuIGFwcGxpY2FibGUuCiAgIFRoZSBV
RFAvSVAgaGVhZGVycyBNVVNUIE5PVCBiZSBpbmNsdWRlZC4gIER1cmluZyB0aGlzIGNvbXB1
dGF0aW9uLAogICB0aGUgIlNpZ25hdHVyZSIgZmllbGQgTVVTVCBiZSBzZXQgdG8gMCBhcyB3
ZWxsIGFzIHRoZSBvcHRpb25hbCBHcm91cAogICBNQUMsIHdoZW4gcHJlc2VudCwgc2luY2Ug
dGhpcyBHcm91cCBNQUMgaXMgY2FsY3VsYXRlZCBsYXRlciBvbi4KCiAgIE1vcmUgc3BlY2lm
aWNhbGx5LCBmcm9tIFtSRkM0MzU5XTogZGlnaXRhbCBzaWduYXR1cmUgZ2VuZXJhdGlvbiBp
cwogICBwZXJmb3JtZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMzNDQ3XSwgU2VjdGlvbiA4LjIu
MSBmb3IgUlNBU1NBLVBLQ1MxLQogICB2MV81IGFuZCBTZWN0aW9uIDguMS4xIGZvciBSU0FT
U0EtUFNTLiAgVGhlIGF1dGhlbnRpY2F0ZWQgcG9ydGlvbiBvZgogICB0aGUgcGFja2V0IGlz
IHVzZWQgYXMgdGhlIG1lc3NhZ2UgTSwgd2hpY2ggaXMgcGFzc2VkIHRvIHRoZSBzaWduYXR1
cmUKICAgZ2VuZXJhdGlvbiBmdW5jdGlvbi4gIFRoZSBzaWduZXIncyBSU0EgcHJpdmF0ZSBr
ZXkgaXMgcGFzc2VkIGFzIEsuIEluCiAgIHN1bW1hcnkgKHdoZW4gU0hBLTI1NiBpcyB1c2Vk
KSwgdGhlIHNpZ25hdHVyZSBnZW5lcmF0aW9uIHByb2Nlc3MKICAgY29tcHV0ZXMgYSBTSEEt
MjU2IGhhc2ggb2YgdGhlIGF1dGhlbnRpY2F0ZWQgcGFja2V0IGJ5dGVzLCBzaWducyB0aGUK
ICAgU0hBLTI1NiBoYXNoIHVzaW5nIHRoZSBwcml2YXRlIGtleSwgYW5kIGVuY29kZXMgdGhl
IHJlc3VsdCB3aXRoIHRoZQogICBzcGVjaWZpZWQgUlNBIGVuY29kaW5nIHR5cGUuICBUaGlz
IHByb2Nlc3MgcmVzdWx0cyBpbiBhIHZhbHVlIFMsCiAgIHdoaWNoIGlzIHRoZSBkaWdpdGFs
IHNpZ25hdHVyZSB0byBiZSBpbmNsdWRlZCBpbiB0aGUgcGFja2V0LgoKICAgV2l0aCBSU0FT
U0EtUEtDUzEtdjFfNSBhbmQgUlNBU1NBLVBTUyBzaWduYXR1cmVzLCB0aGUgc2l6ZSBvZiB0
aGUKICAgc2lnbmF0dXJlIGlzIGVxdWFsIHRvIHRoZSAiUlNBIG1vZHVsdXMiLCB1bmxlc3Mg
dGhlICJSU0EgbW9kdWx1cyIgaXMKICAgbm90IGEgbXVsdGlwbGUgb2YgOCBiaXRzLiAgSW4g
dGhhdCBjYXNlLCB0aGUgc2lnbmF0dXJlIE1VU1QgYmUKICAgcHJlcGVuZGVkIHdpdGggYmV0
d2VlbiAxIGFuZCA3IGJpdHMgc2V0IHRvIHplcm8gc3VjaCB0aGF0IHRoZQogICBzaWduYXR1
cmUgaXMgYSBtdWx0aXBsZSBvZiA4IGJpdHMgW1JGQzQzNTldLiAgVGhlIGtleSBzaXplLCB3
aGljaCBpbgogICBwcmFjdGljZSBpcyBhbHNvIGVxdWFsIHRvIHRoZSAiUlNBIG1vZHVsdXMi
LCBoYXMgbWFqb3Igc2VjdXJpdHkKICAgaW1wbGljYXRpb25zLiAgW1JGQzQzNTldIGV4cGxh
aW5zIGhvdyB0byBjaG9vc2UgdGhpcyB2YWx1ZSBkZXBlbmRpbmcKICAgb24gdGhlIG1heGlt
dW0gZXhwZWN0ZWQgbGlmZXRpbWUgb2YgdGhlIHNlc3Npb24uICBUaGlzIGNob2ljZSBpcyBv
dXQKICAgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgozLjMuMy4gIEdyb3VwIE1B
QyBUYWdzCgogICBBbiBvcHRpb25hbCBHcm91cCBNQUMgY2FuIGJlIHVzZWQgdG8gbWl0aWdh
dGUgRG9TIGF0dGFja3MgY29taW5nIGZyb20KICAgYXR0YWNrZXJzIHRoYXQgYXJlIG5vdCBn
cm91cCBtZW1iZXJzIFtSRkM0MDgyXS4gIFRoaXMgZmVhdHVyZSBhc3N1bWVzCgoKClJvY2Es
IGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwLCAyMDEwICAgICAgICAgICAg
ICAgIFtQYWdlIDI0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVEVTTEEgaW4gQUxD
IGFuZCBOT1JNICAgICAgICAgICBTZXB0ZW1iZXIgMjAwOQoKCiAgIHRoYXQgYSBncm91cCBr
ZXksIEtfZywgaXMgc2hhcmVkIGJ5IHRoZSBzZW5kZXIgYW5kIGFsbCByZWNlaXZlcnMuCiAg
IFdoZW4gdGhlIGF0dGFja2VyIGlzIG5vdCBhIGdyb3VwIG1lbWJlciwgdGhlIGJlbmVmaXRz
IG9mIGFkZGluZyBhCiAgIGdyb3VwIE1BQyB0byBldmVyeSBwYWNrZXQgc2VudCBhcmUgdGhy
ZWVmb2xkOgoKICAgbyAgYSByZWNlaXZlciBjYW4gaW1tZWRpYXRlbHkgZHJvcCBmYWtlZCBw
YWNrZXRzLCB3aXRob3V0IGhhdmluZyB0bwogICAgICB3YWl0IGZvciB0aGUgZGlzY2xvc3Vy
ZSBkZWxheSwgZDsKCiAgIG8gIGEgc2VuZGVyIGNhbiBpbW1lZGlhdGVseSBkcm9wIGZha2Vk
IGRpcmVjdCB0aW1lIHN5bmNocm9uaXphdGlvbgogICAgICByZXF1ZXN0cywgYW5kIGF2b2lk
IHRvIGNoZWNrIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSwgYSBjb21wdXRhdGlvbgogICAgICBp
bnRlbnNpdmUgdGFzazsKCiAgIG8gIGEgcmVjZWl2ZXIgY2FuIGltbWVkaWF0ZWx5IGRyb3Ag
ZmFrZWQgZGlyZWN0IHRpbWUgc3luY2hyb25pemF0aW9uCiAgICAgIHJlc3BvbnNlIGFuZCBi
b290c3RyYXAgbWVzc2FnZXMsIHdpdGhvdXQgaGF2aW5nIHRvIHZlcmlmeSB0aGUKICAgICAg
ZGlnaXRhbCBzaWduYXR1cmUsIGEgY29tcHV0YXRpb24gaW50ZW5zaXZlIHRhc2s7CgogICBU
aGUgY29tcHV0YXRpb24gb2YgdGhlIGdyb3VwIE1BQywgTUFDKEtfZywgTSksIE1VU1QgaW5j
bHVkZSB0aGUgQUxDCiAgIG9yIE5PUk0gaGVhZGVyICh3aXRoIHRoZSB2YXJpb3VzIGhlYWRl
ciBleHRlbnNpb25zKSBhbmQgdGhlIHBheWxvYWQKICAgd2hlbiBhcHBsaWNhYmxlLiAgVGhl
IFVEUC9JUCBoZWFkZXJzIE1VU1QgTk9UIGJlIGluY2x1ZGVkLiAgRHVyaW5nCiAgIHRoaXMg
Y29tcHV0YXRpb24sIHRoZSBHcm91cCBNQUMgZmllbGQgTVVTVCBiZSBzZXQgdG8gMC4gIEhv
d2V2ZXIgdGhlCiAgIGRpZ2l0YWwgc2lnbmF0dXJlIChlLmcuLCBvZiBhIGJvb3RzdHJhcCBt
ZXNzYWdlKSBhbmQgdGhlIE1BQyBmaWVsZHMKICAgKGUuZy4sIG9mIGFuIGF1dGhlbnRpY2F0
aW9uIHRhZyksIHdoZW4gcHJlc2VudCwgTVVTVCBoYXZlIGJlZW4KICAgY2FsY3VsYXRlZCBz
aW5jZSB0aGV5IGFyZSBpbmNsdWRlZCBpbiB0aGUgR3JvdXAgTUFDIGNhbGN1bGF0aW9uCiAg
IGl0c2VsZi4gIFRoZW4gdGhlIHNlbmRlciB0cnVuY2F0ZXMgdGhlIE1BQyBvdXRwdXQgdG8g
a2VlcCB0aGUgbl93CiAgIG1vc3Qgc2lnbmlmaWNhbnQgYml0cyBhbmQgc3RvcmVzIHRoZSBy
ZXN1bHQgaW4gdGhlIEdyb3VwIE1BQyBmaWVsZC4KCiAgIFRoaXMgc2NoZW1lIGZlYXR1cmVz
IGEgZmV3IGxpbWl0czoKCiAgIG8gIGl0IGlzIG9mIG5vIGhlbHAgaWYgYSBncm91cCBtZW1i
ZXIgKHdobyBrbm93cyBLX2cpIGltcGVyc29uYXRlcwogICAgICB0aGUgc2VuZGVyIGFuZCBz
ZW5kcyBmb3JnZWQgbWVzc2FnZXMgdG8gb3RoZXIgcmVjZWl2ZXJzOwoKICAgbyAgaXQgcmVx
dWlyZXMgYW4gYWRkaXRpb25hbCBNQUMgY29tcHV0aW5nIGZvciBlYWNoIHBhY2tldCwgYm90
aCBhdAogICAgICB0aGUgc2VuZGVyIGFuZCByZWNlaXZlciBzaWRlczsKCiAgIG8gIGl0IGlu
Y3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUgVEVTTEEgYXV0aGVudGljYXRpb24gaGVhZGVycy4g
IEluCiAgICAgIG9yZGVyIHRvIGxpbWl0IHRoaXMgcHJvYmxlbSwgdGhlIGxlbmd0aCBvZiB0
aGUgdHJ1bmNhdGVkIG91dHB1dCBvZgogICAgICB0aGUgTUFDLCBuX3csIFNIT1VMRCBiZSBr
ZXB0IHNtYWxsIChlLmcuLCAzMiBiaXRzKSAoc2VlIFtSRkMzNzExXQogICAgICBzZWN0aW9u
IDkuNSkuICBBcyBhIHNpZGUgZWZmZWN0LCB0aGUgYXV0aGVudGljYXRpb24gc2VydmljZSBp
cwogICAgICBzaWduaWZpY2FudGx5IHdlYWtlbmVkOiB0aGUgcHJvYmFiaWxpdHkgdGhhdCBh
bnkgZm9yZ2VkIHBhY2tldCBiZQogICAgICBzdWNjZXNzZnVsbHkgYXV0aGVudGljYXRlZCBi
ZWNvbWVzIG9uZSBpbiAyXjMyLiAgU2luY2UgdGhlIGdyb3VwCiAgICAgIE1BQyBjaGVjayBp
cyBvbmx5IGEgcHJlLWNoZWNrIHRoYXQgbXVzdCBiZSBmb2xsb3dlZCBieSB0aGUKICAgICAg
c3RhbmRhcmQgVEVTTEEgYXV0aGVudGljYXRpb24gY2hlY2ssIHRoaXMgaXMgbm90IGNvbnNp
ZGVyZWQgdG8gYmUKICAgICAgYW4gaXNzdWUuCgogICBGb3IgYSBnaXZlbiB1c2UtY2FzZSwg
dGhlIGJlbmVmaXRzIGJyb3VnaHQgYnkgdGhlIGdyb3VwIE1BQyBtdXN0IGJlCiAgIGJhbGFu
Y2VkIGFnYWluc3QgdGhlc2UgbGltaXRhdGlvbnMuCgogICBOb3RlIHRoYXQgdGhlIEdyb3Vw
IE1BQyBmdW5jdGlvbiBjYW4gYmUgZGlmZmVyZW50IGZyb20gdGhlIFRFU0xBIE1BQwogICBm
dW5jdGlvbiAoZS5nLiwgaXQgY2FuIHVzZSBhIHdlYWtlciBidXQgZmFzdGVyIE1BQyBmdW5j
dGlvbikuICBOb3RlCgoKClJvY2EsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNo
IDIwLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDI1XQoMCkludGVybmV0LURyYWZ0ICAg
ICAgICAgICAgVEVTTEEgaW4gQUxDIGFuZCBOT1JNICAgICAgICAgICBTZXB0ZW1iZXIgMjAw
OQoKCiAgIGFsc28gdGhhdCB0aGUgbWVjaGFuaXNtIGJ5IHdoaWNoIHRoZSBncm91cCBrZXks
IEtfZywgaXMgY29tbXVuaWNhdGVkCiAgIHRvIGFsbCBncm91cCBtZW1iZXJzLCBhbmQgcGVy
aGFwcyBwZXJpb2RpY2FsbHkgdXBkYXRlZCwgaXMgb3V0IG9mIHRoZQogICBzY29wZSBvZiB0
aGlzIGRvY3VtZW50LgoKMy40LiAgRm9ybWF0IG9mIFRFU0xBIE1lc3NhZ2VzIGFuZCBBdXRo
ZW50aWNhdGlvbiBUYWdzCgogICBUaGlzIHNlY3Rpb24gc3BlY2lmaWVzIHRoZSBmb3JtYXQg
b2YgdGhlIHZhcmlvdXMga2luZHMgb2YgVEVTTEEKICAgbWVzc2FnZXMgYW5kIGF1dGhlbnRp
Y2F0aW9uIHRhZ3Mgc2VudCBieSB0aGUgc2Vzc2lvbidzIHNlbmRlci4KICAgQmVjYXVzZSB0
aGVzZSBURVNMQSBtZXNzYWdlcyBhcmUgY2FycmllZCBhcyBFWFRfQVVUSCBoZWFkZXIKICAg
ZXh0ZW5zaW9ucyBvZiB0aGUgQUxDIG9yIE5PUk0gcGFja2V0cyAoU2VjdGlvbiA1KSwgdGhl
IGZvbGxvd2luZwogICBmb3JtYXRzIGRvIG5vdCBzdGFydCBvbiAzMiBiaXQgd29yZCBib3Vu
ZGFyaWVzLgoKMy40LjEuICBGb3JtYXQgb2YgYSBCb290c3RyYXAgSW5mb3JtYXRpb24gTWVz
c2FnZQoKICAgV2hlbiBib290c3RyYXAgaW5mb3JtYXRpb24gaXMgc2VudCBpbi1iYW5kLCB0
aGUgZm9sbG93aW5nIG1lc3NhZ2UgaXMKICAgdXNlZDoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKCgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAy
MCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICAg
ICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkK
CgogICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAg
ICAgICAgICAgICAzCiAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg
OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rICAtLS0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IFYgfHJlc3ZkfFN8
R3xBfCAgXgogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rICB8CiAgfCAgICAgICBkICAgICAgIHwgICAgUFJGIFR5
cGUgICB8IE1BQyBGdW5jIFR5cGUgfEdyIE1BQyBGdW4gVHlwZXwgIHwgZgogICstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rICB8IGkKICB8ICAgU2lnRW5jQWxnbyAgfCBTaWdDcnlwdG9GdW5jIHwgICAgICAgU2ln
bmF0dXJlIExlbmd0aCAgICAgICAgfCAgfCB4CiAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIHwgZQogIHwgICAg
ICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgfCAgICAgICAgICAgICBUX2ludCAgICAgICAg
ICAgICB8ICB8IGQKICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgfAogIHwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICB8IGwKICArICAg
ICAgICAgICAgICAgICAgVF8wIChOVFAgdGltZXN0YW1wIGZvcm1hdCkgICAgICAgICAgICAg
ICAgICAgKyAgfCBlCiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHwgbgogICstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICB8IGcKICB8
ICAgICAgICAgICAgICAgICAgICAgIE4gKEtleSBDaGFpbiBMZW5ndGgpICAgICAgICAgICAg
ICAgICAgICAgfCAgfCB0CiAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIHwgaAogIHwgICAgICAgICAgICAgICAg
ICAgIEN1cnJlbnQgSW50ZXJ2YWwgSW5kZXggaSAgICAgICAgICAgICAgICAgICB8ICB2CiAg
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSsgIC0tLQogIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgfiAgICAgICAgICAgICAgICAgQ3Vy
cmVudCBLZXkgQ2hhaW4gQ29tbWl0bWVudCAgKy0rLSstKy0rLSstKy0rLSsKICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgUGFkZGluZyAg
ICAgfAogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rCiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKwogIH4gICAg
ICAgICAgICAgICAgICAgICAgICAgICBTaWduYXR1cmUgICAgICAgICAgICAgICAgICAgICAg
ICAgICB+CiAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKy0rLSstKy0rLSstKy0rLSsKICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8ICAgIFBhZGRpbmcgICAgfAogICstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgfFB8
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwKICArLSsgICAgICAgRF5PX3QgRXh0ZW5zaW9uIChvcHRpb25hbCwgcHJlc2Vu
dCBpZiBBPT0xKSAgICAgICAgICAgKwogIHwgICAgKE5UUCB0aW1lc3RhbXAgZGlmZiwgcG9z
aXRpdmUgaWYgUD09MSwgbmVnYXRpdmUgaWYgUD09MCkgICB8CiAgKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICB+
ICAgICAgICAgICAgICAgICAgICAgIEdyb3VwIE1BQyAob3B0aW9uYWwpICAgICAgICAgICAg
ICAgICAgICAgfgogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICAgICAgICAgICAgICAgICBGaWd1cmUgMjog
Qm9vdHN0cmFwIGluZm9ybWF0aW9uIGZvcm1hdC4KCiAgIFRoZSBmb3JtYXQgb2YgdGhlIGJv
b3RzdHJhcCBpbmZvcm1hdGlvbiBpcyBkZXBpY3RlZCBpbiBGaWd1cmUgMi4gIFRoZQogICBm
aWVsZHMgYXJlOgoKICAgIlYiIChWZXJzaW9uKSBmaWVsZCAoMiBiaXRzKToKCiAgICAgIFRo
ZSAiViIgZmllbGQgY29udGFpbnMgdGhlIHZlcnNpb24gbnVtYmVyIG9mIHRoZSBwcm90b2Nv
bC4gIEZvcgogICAgICB0aGlzIHNwZWNpZmljYXRpb24sIHRoZSB2YWx1ZSBvZiAwIE1VU1Qg
YmUgdXNlZC4KCiAgICJSZXNlcnZlZCIgZmllbGQgKDMgYml0cyk6CgoKCgpSb2NhLCBldCBh
bC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBb
UGFnZSAyN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQg
Tk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICAgICBUaGlzIGlzIGEgcmVzZXJ2
ZWQgZmllbGQgdGhhdCBNVVNUIGJlIHNldCB0byB6ZXJvIGluIHRoaXMKICAgICAgc3BlY2lm
aWNhdGlvbi4KCiAgICJTIiAoU2luZ2xlIEtleSBDaGFpbikgZmxhZyAoMSBiaXRzKToKCiAg
ICAgIFRoZSAiUyIgZmxhZyBpbmRpY2F0ZXMgd2hldGhlciB0aGlzIFRFU0xBIHNlc3Npb24g
aXMgcmVzdHJpY3RlZCB0bwogICAgICBhIHNpbmdsZSBrZXkgY2hhaW4gKFM9PTEpIG9yIHJl
bGllcyBvbiBvbmUgb3IgbXVsdGlwbGUga2V5IGNoYWlucwogICAgICAoUz09MCkuCgogICAi
RyIgKEdyb3VwIE1BQyBQcmVzZW50KSBmbGFnICgxIGJpdHMpOgoKICAgICAgVGhlICJHIiBm
bGFnIGluZGljYXRlcyB3aGV0aGVyIHRoZSBHcm91cCBNQUMgZmVhdHVyZSBpcyB1c2VkCiAg
ICAgIChHPT0xKSBvciBub3QgKEc9PTApLiAgV2hlbiBpdCBpcyB1c2VkLCBhICJHcm91cCBN
QUMiIGZpZWxkIGlzCiAgICAgIGFkZGVkIHRvIGFsbCB0aGUgcGFja2V0cyBjb250YWluaW5n
IGEgVEVTTEEgRVhUX0FVVEggSGVhZGVyCiAgICAgIEV4dGVuc2lvbiAoaW5jbHVkaW5nIHRo
aXMgYm9vdHN0cmFwIG1lc3NhZ2UpLgoKICAgIkEiIGZsYWcgKDEgYml0KToKCiAgICAgIFRo
ZSAiQSIgZmxhZyBpbmRpY2F0ZXMgd2hldGhlciB0aGUgUCBmbGFnIGFuZCBEXk9fdCBmaWVs
ZHMgYXJlCiAgICAgIHByZXNlbnQgKEE9PTEpIG9yIG5vdCAoQT09MCkuICBJbiBpbmRpcmVj
dCB0aW1lIHN5bmNocm9uaXphdGlvbgogICAgICBtb2RlLCBBIE1VU1QgYmUgZXF1YWwgdG8g
MSBzaW5jZSB0aGVzZSBmaWVsZHMgYXJlIG5lZWRlZC4KCiAgICJkIiBmaWVsZCAoOCBiaXRz
KToKCiAgICAgIGQgaXMgYW4gdW5zaWduZWQgaW50ZWdlciB0aGF0IGRlZmluZXMgdGhlIGtl
eSBkaXNjbG9zdXJlIGRlbGF5IChpbgogICAgICBudW1iZXIgb2YgaW50ZXJ2YWxzKS4gZCBN
VVNUIGJlIGdyZWF0ZXIgb3IgZXF1YWwgdG8gMi4KCiAgICJQUkYgVHlwZSIgZmllbGQgKDgg
Yml0cyk6CgogICAgICBUaGUgIlBSRiBUeXBlIiBpcyB0aGUgcmVmZXJlbmNlIG51bWJlciBv
ZiB0aGUgZiBmdW5jdGlvbiB1c2VkIHRvCiAgICAgIGRlcml2ZSB0aGUgRiAoZm9yIGtleSBj
aGFpbikgYW5kIEYnIChmb3IgTUFDIGtleXMpIGZ1bmN0aW9ucwogICAgICAoU2VjdGlvbiA3
KS4KCiAgICJNQUMgRnVuY3Rpb24gVHlwZSIgZmllbGQgKDggYml0cyk6CgogICAgICBUaGUg
Ik1BQyBGdW5jdGlvbiBUeXBlIiBpcyB0aGUgcmVmZXJlbmNlIG51bWJlciBvZiB0aGUgZnVu
Y3Rpb24KICAgICAgdXNlZCB0byBjb21wdXRlIHRoZSBNQUMgb2YgdGhlIHBhY2tldHMgKFNl
Y3Rpb24gNykuCgogICAiR3JvdXAgTUFDIEZ1bmN0aW9uIFR5cGUiIGZpZWxkICg4IGJpdHMp
OgoKICAgICAgV2hlbiBHPT0xLCB0aGlzIGZpZWxkIGNvbnRhaW5zIHRoZSByZWZlcmVuY2Ug
bnVtYmVyIG9mIHRoZQogICAgICBjcnlwdG9ncmFwaGljIE1BQyBmdW5jdGlvbiB1c2VkIHRv
IGNvbXB1dGUgdGhlIGdyb3VwIE1BQwogICAgICAoU2VjdGlvbiA3KS4gIFdoZW4gRz09MCwg
dGhpcyBmaWVsZCBNVVNUIGJlIHNldCB0byB6ZXJvLgoKICAgIlNpZ25hdHVyZSBFbmNvZGlu
ZyBBbGdvcml0aG0iIGZpZWxkICg4IGJpdHMpOgoKCgoKCgpSb2NhLCBldCBhbC4gICAgICAg
ICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAyOF0K
DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAg
ICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICAgICBUaGUgIlNpZ25hdHVyZSBFbmNvZGluZyBB
bGdvcml0aG0iIGlzIHRoZSByZWZlcmVuY2UgbnVtYmVyCiAgICAgIChTZWN0aW9uIDcpIG9m
IHRoZSBkaWdpdGFsIHNpZ25hdHVyZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGlzCiAgICAg
IGJvb3RzdHJhcCBpbmZvcm1hdGlvbiBhbmQgaW5jbHVkZWQgaW4gdGhlICJTaWduYXR1cmUi
IGZpZWxkLgoKICAgIlNpZ25hdHVyZSBDcnlwdG9ncmFwaGljIEZ1bmN0aW9uIiBmaWVsZCAo
OCBiaXRzKToKCiAgICAgIFRoZSAiU2lnbmF0dXJlIENyeXB0b2dyYXBoaWMgRnVuY3Rpb24i
IGlzIHRoZSByZWZlcmVuY2UgbnVtYmVyCiAgICAgIChTZWN0aW9uIDcpIG9mIHRoZSBjcnlw
dG9ncmFwaGljIGZ1bmN0aW9uIHVzZWQgd2l0aGluIHRoZSBkaWdpdGFsCiAgICAgIHNpZ25h
dHVyZS4KCiAgICJTaWduYXR1cmUgTGVuZ3RoIiBmaWVsZCAoMTYgYml0cyk6CgogICAgICBU
aGUgIlNpZ25hdHVyZSBMZW5ndGgiIGlzIGFuIHVuc2lnbmVkIGludGVnZXIgdGhhdCBpbmRp
Y2F0ZXMgdGhlCiAgICAgIHNpZ25hdHVyZSBmaWVsZCBzaXplIGluIGJ5dGVzIGluIHRoZSAi
U2lnbmF0dXJlIEV4dGVuc2lvbiIgZmllbGQuCiAgICAgIFRoaXMgaXMgYWxzbyB0aGUgc2ln
bmF0dXJlIGtleSBsZW5ndGgsIHNpbmNlIGJvdGggcGFyYW1ldGVycyBhcmUKICAgICAgZXF1
YWwuCgogICAiUmVzZXJ2ZWQiIGZpZWxkcyAoMTYgYml0cyk6CgogICAgICBUaGlzIGlzIGEg
cmVzZXJ2ZWQgZmllbGQgdGhhdCBNVVNUIGJlIHNldCB0byB6ZXJvIGluIHRoaXMKICAgICAg
c3BlY2lmaWNhdGlvbi4KCiAgICJUX2ludCIgZmllbGQgKDE2IGJpdHMpOgoKICAgICAgVF9p
bnQgaXMgYW4gdW5zaWduZWQgMTYgYml0IGludGVnZXIgdGhhdCBkZWZpbmVzIHRoZSBpbnRl
cnZhbAogICAgICBkdXJhdGlvbiAoaW4gbWlsbGlzZWNvbmRzKS4KCiAgICJUXzAiIGZpZWxk
ICg2NCBiaXRzKToKCiAgICAgICJUXzAiIGlzIGEgdGltZXN0YW1wIGluIE5UUCB0aW1lc3Rh
bXAgZm9ybWF0IHRoYXQgaW5kaWNhdGVzIHRoZQogICAgICBiZWdpbm5pbmcgb2YgdGhlIHNl
c3Npb24sIGkuZS4sIHRoZSBiZWdpbm5pbmcgb2YgdGltZSBpbnRlcnZhbCAwLgoKICAgIk4i
IGZpZWxkICgzMiBiaXRzKToKCiAgICAgICJOIiBpcyBhbiB1bnNpZ25lZCBpbnRlZ2VyIHRo
YXQgaW5kaWNhdGVzIHRoZSBrZXkgY2hhaW4gbGVuZ3RoLgogICAgICBUaGVyZSBhcmUgTiAr
IDEga2V5cyBwZXIgY2hhaW4uCgogICAiaSIgKEludGVydmFsIEluZGV4IG9mIEtfaSkgZmll
bGQgKDMyIGJpdHMpOgoKICAgICAgImkiIGlzIGFuIHVuc2lnbmVkIGludGVnZXIgdGhhdCBp
bmRpY2F0ZXMgdGhlIGN1cnJlbnQgaW50ZXJ2YWwKICAgICAgaW5kZXggd2hlbiB0aGlzIGJv
b3RzdHJhcCBpbmZvcm1hdGlvbiBtZXNzYWdlIGlzIHNlbnQuCgogICAiQ3VycmVudCBLZXkg
Q2hhaW4gQ29tbWl0bWVudCIgZmllbGQgKHZhcmlhYmxlIHNpemUsIHBhZGRlZCBpZgogICBu
ZWNlc3NhcnkgZm9yIDMyIGJpdCB3b3JkIGFsaWdubWVudCk6CgogICAgICAiS2V5IENoYWlu
IENvbW1pdG1lbnQiIGlzIHRoZSBjb21taXRtZW50IHRvIHRoZSBjdXJyZW50IGtleSBjaGFp
biwKICAgICAgaS5lLiwgdGhlIGtleSBjaGFpbiBjb3JyZXNwb25kaW5nIHRvIGludGVydmFs
IGkuICBGb3IgaW5zdGFuY2UsCiAgICAgIHdpdGggdGhlIGZpcnN0IGtleSBjaGFpbiwgdGhp
cyBjb21taXRtZW50IGlzIGVxdWFsIHRvIEYoS18wKSwgd2l0aAoKCgpSb2NhLCBldCBhbC4g
ICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFn
ZSAyOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9S
TSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICAgICB0aGUgc2Vjb25kIGtleSBjaGFp
biwgdGhpcyBjb21taXRtZW50IGlzIGVxdWFsIHRvIEYoS197TisxfSksCiAgICAgIGV0Yy4p
LiAgSWYgbmVlZCBiZSwgdGhpcyBmaWVsZCBpcyBwYWRkZWQgKHdpdGggMCkgdXAgdG8gYSBt
dWx0aXBsZQogICAgICBvZiAzMiBiaXRzLgoKICAgIlNpZ25hdHVyZSIgZmllbGQgKHZhcmlh
YmxlIHNpemUsIHBhZGRlZCBpZiBuZWNlc3NhcnkgZm9yIDMyIGJpdCB3b3JkCiAgIGFsaWdu
bWVudCk6CgogICAgICBUaGUgIlNpZ25hdHVyZSIgZmllbGQgaXMgbWFuZGF0b3J5LiAgSXQg
Y29udGFpbnMgYSBkaWdpdGFsCiAgICAgIHNpZ25hdHVyZSBvZiB0aGlzIG1lc3NhZ2UsIGFz
IHNwZWNpZmllZCBieSB0aGUgZW5jb2RpbmcgYWxnb3JpdGhtLAogICAgICBjcnlwdG9ncmFw
aGljIGZ1bmN0aW9uIGFuZCBrZXkgbGVuZ3RoIHBhcmFtZXRlcnMuICBJZiB0aGUKICAgICAg
c2lnbmF0dXJlIGxlbmd0aCBpcyBub3QgbXVsdGlwbGUgb2YgMzIgYml0cywgdGhpcyBmaWVs
ZCBpcyBwYWRkZWQKICAgICAgd2l0aCAwLgoKICAgIlAiIGZsYWcgKG9wdGlvbmFsLCAxIGJp
dCBpZiBwcmVzZW50KToKCiAgICAgIFRoZSAiUCIgZmxhZyBpcyBvcHRpb25hbCBhbmQgb25s
eSBwcmVzZW50IGlmIHRoZSBBIGZsYWcgaXMgZXF1YWwKICAgICAgdG8gMS4uICBJdCBpcyBv
bmx5IHVzZWQgaW4gaW5kaXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24gbW9kZS4KICAgICAg
VGhpcyBmbGFnIGluZGljYXRlcyB3aGV0aGVyIHRoZSBEXk9fdCBOVFAgdGltZXN0YW1wIGRp
ZmZlcmVuY2UgaXMKICAgICAgcG9zaXRpdmUgKFA9PTEpIG9yIG5lZ2F0aXZlIChQPT0wKS4K
CiAgICJEXk9fdCIgZmllbGQgKG9wdGlvbmFsLCA2MyBiaXRzIGlmIHByZXNlbnQpOgoKICAg
ICAgVGhlICJEXk9fdCIgZmllbGQgaXMgb3B0aW9uYWwgYW5kIG9ubHkgcHJlc2VudCBpZiB0
aGUgQSBmbGFnIGlzCiAgICAgIGVxdWFsIHRvIDEuICBJdCBpcyBvbmx5IHVzZWQgaW4gaW5k
aXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24KICAgICAgbW9kZS4gIEl0IGlzIHRoZSB1cHBl
ciBib3VuZCBvZiB0aGUgbGFnIG9mIHRoZSBzZW5kZXIncyBjbG9jayB3aXRoCiAgICAgIHJl
c3BlY3QgdG8gdGhlIHRpbWUgcmVmZXJlbmNlLiAgV2hlbiBzZXZlcmFsIHRpbWUgcmVmZXJl
bmNlcyBhcmUKICAgICAgc3BlY2lmaWVkIChlLmcuLCBzZXZlcmFsIE5UUCBzZXJ2ZXJzKSwg
dGhlbiBEXk9fdCBpcyB0aGUgbWF4aW11bQogICAgICB1cHBlciBib3VuZCBvZiB0aGUgbGFn
IHdpdGggZWFjaCB0aW1lIHJlZmVyZW5jZS4gIEReT190IGlzCiAgICAgIGNvbXBvc2VkIG9m
IHR3byB1bnNpZ25lZCBpbnRlZ2VycywgYXMgd2l0aCBOVFAgdGltZXN0YW1wczogdGhlCiAg
ICAgIGZpcnN0IDMxIGJpdHMgZ2l2ZSB0aGUgdGltZSBkaWZmZXJlbmNlIGluIHNlY29uZHMg
YW5kIHRoZQogICAgICByZW1haW5pbmcgMzIgYml0cyBnaXZlIHRoZSBzdWItc2Vjb25kIHRp
bWUgZGlmZmVyZW5jZS4KCiAgICJHcm91cCBNQUMiIGZpZWxkIChvcHRpb25hbCwgdmFyaWFi
bGUgbGVuZ3RoLCBtdWx0aXBsZSBvZiAzMiBiaXRzKToKCiAgICAgIFRoaXMgZmllbGQgY29u
dGFpbnMgdGhlIGdyb3VwIE1BQywgY2FsY3VsYXRlZCB3aXRoIHRoZSBncm91cCBrZXksCiAg
ICAgIEtfZywgc2hhcmVkIGJ5IGFsbCBncm91cCBtZW1iZXJzLiAgVGhlIGZpZWxkIGxlbmd0
aCwgaW4gYml0cywgaXMKICAgICAgZ2l2ZW4gYnkgbl93IHdoaWNoIGlzIGtub3duIG9uY2Ug
dGhlIGdyb3VwIE1BQyBmdW5jdGlvbiB0eXBlIGlzCiAgICAgIGtub3duIChTZWN0aW9uIDcp
LgoKICAgTm90ZSB0aGF0IHRoZSBmaXJzdCBieXRlIGFuZCB0aGUgZm9sbG93aW5nIHNldmVu
IDMyLWJpdCB3b3JkcyBhcmUKICAgbWFuZGF0b3J5IGZpeGVkIGxlbmd0aCBmaWVsZHMuICBU
aGUgQ3VycmVudCBLZXkgQ2hhaW4gQ29tbWl0bWVudCBhbmQKICAgU2lnbmF0dXJlIGZpZWxk
cyBhcmUgbWFuZGF0b3J5IGJ1dCB2YXJpYWJsZSBsZW5ndGggZmllbGRzLiAgVGhlCiAgIHJl
bWFpbmluZyBEXk9fdCBhbmQgR3JvdXAgTUFDIGZpZWxkcyBhcmUgb3B0aW9uYWwuCgogICBJ
biBvcmRlciB0byBwcmV2ZW50IGF0dGFja3MsIHNvbWUgcGFyYW1ldGVycyBNVVNUIE5PVCBi
ZSBjaGFuZ2VkCiAgIGR1cmluZyB0aGUgbGlmZXRpbWUgb2YgdGhlIHNlc3Npb24gKFNlY3Rp
b24gMy4xLjMsIFNlY3Rpb24gMy4xLjQpLgogICBUaGUgZm9sbG93aW5nIHRhYmxlIHN1bW1h
cml6ZXMgdGhlIHBhcmFtZXRlcnMgc3RhdHVzOgoKCgoKUm9jYSwgZXQgYWwuICAgICAgICAg
ICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMzBdCgwK
SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAg
ICAgIFNlcHRlbWJlciAyMDA5CgoKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgICAgICAgICBQ
YXJhbWV0ZXIgICAgICAgIHwgICAgICAgICAgICAgICAgIFN0YXR1cyAgICAgICAgICAgICAg
ICAgfAogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCAgICAgICAgICAgICBWICAgICAgICAgICAg
fCAgICAgc2V0IHRvIDAgaW4gdGhpcyBzcGVjaWZpY2F0aW9uICAgICB8CiAgIHwgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfAogICB8ICAgICAgICAgICAgIFMgICAgICAgICAgICB8ICAgICAgc3RhdGljIChk
dXJpbmcgd2hvbGUgc2Vzc2lvbikgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAg
ICAgICAgICAgRyAgICAgICAgICAgIHwgICAgICBzdGF0aWMgKGR1cmluZyB3aG9sZSBzZXNz
aW9uKSAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICBBICAgICAg
ICAgICAgfCAgICAgIHN0YXRpYyAoZHVyaW5nIHdob2xlIHNlc3Npb24pICAgICB8CiAgIHwg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgVF9PICAgICAgICAgICB8ICAgICAgc3Rh
dGljIChkdXJpbmcgd2hvbGUgc2Vzc2lvbikgICAgIHwKICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg
IHwgICAgICAgICAgIFRfaW50ICAgICAgICAgIHwgICAgICBzdGF0aWMgKGR1cmluZyB3aG9s
ZSBzZXNzaW9uKSAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICBk
ICAgICAgICAgICAgfCAgICAgIHN0YXRpYyAoZHVyaW5nIHdob2xlIHNlc3Npb24pICAgICB8
CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgIE4gICAgICAgICAgICB8ICAg
ICAgc3RhdGljIChkdXJpbmcgd2hvbGUgc2Vzc2lvbikgICAgIHwKICAgfCAgICAgICAgICAg
ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8CiAgIHwgICAgRF5PX3QgKGlmIHByZXNlbnQpICAgIHwgICAgICBzdGF0aWMgKGR1cmlu
ZyB3aG9sZSBzZXNzaW9uKSAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAg
IFBSRiBUeXBlICAgICAgICAgfCAgICAgIHN0YXRpYyAoZHVyaW5nIHdob2xlIHNlc3Npb24p
ICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICBNQUMgRnVuY3Rpb24gVHlwZSAg
ICB8ICAgICAgc3RhdGljIChkdXJpbmcgd2hvbGUgc2Vzc2lvbikgICAgIHwKICAgfCAgICAg
ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8CiAgIHwgICAgU2lnbmF0dXJlIEVuY29kaW5nICAgIHwgICAgICBzdGF0aWMg
KGR1cmluZyB3aG9sZSBzZXNzaW9uKSAgICAgfAogICB8ICAgICAgICAgQWxnb3JpdGhtICAg
ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8CiAgIHwgICAgU2lnbmF0dXJlIENyeXB0by4gICAgIHwgICAgICBzdGF0
aWMgKGR1cmluZyB3aG9sZSBzZXNzaW9uKSAgICAgfAogICB8ICAgICAgICAgRnVuY3Rpb24g
ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg
fCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8CiAgIHwgICAgIFNpZ25hdHVyZSBMZW5ndGggICAgIHwgICAgICBz
dGF0aWMgKGR1cmluZyB3aG9sZSBzZXNzaW9uKSAgICAgfAogICB8ICAgICAgICAgICAgICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK
ICAgfCAgIEdyb3VwIE1BQyBGdW5jLiAgVHlwZSAgfCAgICAgIHN0YXRpYyAoZHVyaW5nIHdo
b2xlIHNlc3Npb24pICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAg
IGkgICAgICAgICAgICB8IGR5bmFtaWMgKHJlbGF0ZWQgdG8gY3VycmVudCBrZXkgY2hhaW4p
IHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICBLX2kgICAgICAgICAgIHwg
ZHluYW1pYyAocmVsYXRlZCB0byBjdXJyZW50IGtleSBjaGFpbikgfAogICB8ICAgICAgICAg
ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwKICAgfCAgICAgICAgIHNpZ25hdHVyZSAgICAgICAgfCAgICAgICAgZHluYW1pYywg
cGFja2V0IGRlcGVuZGVudCAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg
IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICBHcm91
cCBNQUMgKGlmIHByZXNlbnQpICB8ICAgICAgICBkeW5hbWljLCBwYWNrZXQgZGVwZW5kZW50
ICAgICAgIHwKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgoKCgoKCgoKUm9jYSwgZXQgYWwuICAgICAg
ICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMzFd
CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAg
ICAgICAgIFNlcHRlbWJlciAyMDA5CgoKMy40LjIuICBGb3JtYXQgb2YgYSBEaXJlY3QgVGlt
ZSBTeW5jaHJvbml6YXRpb24gUmVzcG9uc2UKCgogICAgIDAgICAgICAgICAgICAgICAgICAg
MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgICAwIDEgMiAz
IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw
IDEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICstKy0rLSstKy0rLSstKy0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8ICAgIFJlc2VydmVkICAgfAogICAgKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg
IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8CiAgICArICAgICAgICAgICAgICAgICAgICAgdF9zIChOVFAgdGltZXN0
YW1wKSAgICAgICAgICAgICAgICAgICAgICAgKwogICAgfCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfAogICAgKyAgICAgICAgICAgICAgICAgICAgIHRfciAo
TlRQIHRpbWVzdGFtcCkgICAgICAgICAgICAgICAgICAgICAgICsKICAgIHwgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8
CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICB+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgU2lnbmF0dXJlICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfgogICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgUGFkZGluZyAgICB8CiAgICArLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKwogICAgfiAgICAgICAgICAgICAgICAgICAgIEdyb3VwIE1BQyAob3B0aW9uYWwpICAg
ICAgICAgICAgICAgICAgICAgIH4KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICAgICAgIEZpZ3VyZSAz
OiBGb3JtYXQgb2YgYSBEaXJlY3QgVGltZSBTeW5jaHJvbml6YXRpb24gUmVzcG9uc2UKCiAg
IFRoZSByZXNwb25zZSB0byBhIGRpcmVjdCB0aW1lIHN5bmNocm9uaXphdGlvbiByZXF1ZXN0
IGNvbnRhaW5zIHRoZQogICBmb2xsb3dpbmcgaW5mb3JtYXRpb246CgogICAiUmVzZXJ2ZWQi
IGZpZWxkcyAoOCBiaXRzKToKCiAgICAgIFRoaXMgaXMgYSByZXNlcnZlZCBmaWVsZCB0aGF0
IE1VU1QgYmUgc2V0IHRvIHplcm8gaW4gdGhpcwogICAgICBzcGVjaWZpY2F0aW9uLgoKICAg
InRfcyIgKE5UUCB0aW1lc3RhbXAsIDY0IGJpdHMpOgoKICAgICAgdF9zIGlzIGEgdGltZXN0
YW1wIGluIE5UUCB0aW1lc3RhbXAgZm9ybWF0IHRoYXQgY29ycmVzcG9uZHMgdG8gdGhlCiAg
ICAgIHNlbmRlciBsb2NhbCB0aW1lIHZhbHVlIHdoZW4gcmVjZWl2aW5nIHRoZSBkaXJlY3Qg
dGltZQogICAgICBzeW5jaHJvbml6YXRpb24gcmVxdWVzdCBtZXNzYWdlLgoKICAgInRfciIg
KE5UUCB0aW1lc3RhbXAsIDY0IGJpdHMpOgoKICAgICAgdF9yIGlzIGEgdGltZXN0YW1wIGlu
IE5UUCB0aW1lc3RhbXAgZm9ybWF0IHRoYXQgY29udGFpbnMgdGhlCiAgICAgIHJlY2VpdmVy
IGxvY2FsIHRpbWUgdmFsdWUgcmVjZWl2ZWQgaW4gdGhlIGRpcmVjdCB0aW1lCiAgICAgIHN5
bmNocm9uaXphdGlvbiByZXF1ZXN0IG1lc3NhZ2UuCgogICAiU2lnbmF0dXJlIiBmaWVsZCAo
dmFyaWFibGUgc2l6ZSwgcGFkZGVkIGlmIG5lY2Vzc2FyeSBmb3IgMzIgYml0IHdvcmQKCgoK
Um9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAg
ICAgICAgICAgW1BhZ2UgMzJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBp
biBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgYWxpZ25tZW50
KToKCiAgICAgIFRoZSAiU2lnbmF0dXJlIiBmaWVsZCBpcyBtYW5kYXRvcnkuICBJdCBjb250
YWlucyBhIGRpZ2l0YWwKICAgICAgc2lnbmF0dXJlIG9mIHRoaXMgbWVzc2FnZSwgYXMgc3Bl
Y2lmaWVkIGJ5IHRoZSBlbmNvZGluZyBhbGdvcml0aG0sCiAgICAgIGNyeXB0b2dyYXBoaWMg
ZnVuY3Rpb24gYW5kIGtleSBsZW5ndGggcGFyYW1ldGVycyBjb21tdW5pY2F0ZWQgaW4KICAg
ICAgdGhlIGJvb3RzdHJhcCBpbmZvcm1hdGlvbiBtZXNzYWdlIChpZiBhcHBsaWNhYmxlKSBv
ciBvdXQtb2YtYmFuZC4KICAgICAgSWYgdGhlIHNpZ25hdHVyZSBsZW5ndGggaXMgbm90IG11
bHRpcGxlIG9mIDMyIGJpdHMsIHRoaXMgZmllbGQgaXMKICAgICAgcGFkZGVkIHdpdGggMC4K
CiAgICJHcm91cCBNQUMiIGZpZWxkIChvcHRpb25hbCwgdmFyaWFibGUgbGVuZ3RoLCBtdWx0
aXBsZSBvZiAzMiBiaXRzKToKCiAgICAgIFRoaXMgZmllbGQgY29udGFpbnMgdGhlIEdyb3Vw
IE1BQywgY2FsY3VsYXRlZCB3aXRoIHRoZSBncm91cCBrZXksCiAgICAgIEtfZywgc2hhcmVk
IGJ5IGFsbCBncm91cCBtZW1iZXJzLiAgVGhlIGZpZWxkIGxlbmd0aCwgaW4gYml0cywgaXMK
ICAgICAgZ2l2ZW4gYnkgbl93LCB3aGljaCBpcyBrbm93biBvbmNlIHRoZSBncm91cCBNQUMg
ZnVuY3Rpb24gdHlwZSBpcwogICAgICBrbm93biAoU2VjdGlvbiA3KS4KCjMuNC4zLiAgRm9y
bWF0IG9mIGEgU3RhbmRhcmQgQXV0aGVudGljYXRpb24gVGFnCgoKICAgICAwICAgICAgICAg
ICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAg
ICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1
IDYgNyA4IDkgMCAxCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICArLSstKy0rLSstKy0rLSstKwogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIFJlc2VydmVkICAgIHwKICAgICstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rCiAgICB8ICAgICAgICAgICAgICAgIGkgKEludGVydmFsIEluZGV4IG9mIEsnX2kp
ICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8
CiAgICB+ICAgICAgICAgICAgICAgICAgICBEaXNjbG9zZWQgS2V5IEtfe2ktZH0gICAgICAg
ICAgICAgICAgICAgICAgfgogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfAogICAgfiAgICAgICAgICAgICAgICAgICAgICAgTUFDKEsnX2ksIE0pICAg
ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBQYWRkaW5nICAgICB8CiAgICArLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKwogICAgfiAgICAgICAgICAgICAgICAgICAgIEdyb3VwIE1BQyAob3B0aW9uYWwpICAg
ICAgICAgICAgICAgICAgICAgIH4KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICAgICAgICAgIEZpZ3Vy
ZSA0OiBGb3JtYXQgb2YgdGhlICBTdGFuZGFyZCBBdXRoZW50aWNhdGlvbiBUYWcKCiAgIEZp
Z3VyZSA0IHNob3dzIHRoZSBmb3JtYXQgb2YgdGhlIFN0YW5kYXJkIEF1dGhlbnRpY2F0aW9u
IFRhZzoKCiAgICJSZXNlcnZlZCIgZmllbGQgKDggYml0cyk6CgogICAgICBUaGUgIlJlc2Vy
dmVkIiBmaWVsZCBpcyBub3QgdXNlZCBpbiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIGFu
ZAogICAgICBNVVNUIGJlIHNldCB0byB6ZXJvIGJ5IHRoZSBzZW5kZXIuCgogICAiaSIgKElu
dGVydmFsIEluZGV4KSBmaWVsZCAoMzIgYml0cyk6CgoKCgpSb2NhLCBldCBhbC4gICAgICAg
ICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAzM10K
DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAg
ICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICAgICBpIGlzIHRoZSBpbnRlcnZhbCBpbmRleCBh
c3NvY2lhdGVkIHRvIHRoZSBrZXkgKEsnX2kpIHVzZWQgdG8KICAgICAgY29tcHV0ZSB0aGUg
TUFDIG9mIHRoaXMgcGFja2V0LgoKICAgIkRpc2Nsb3NlZCBLZXkiICh2YXJpYWJsZSBzaXpl
LCBub24gcGFkZGVkKToKCiAgICAgIFRoZSAiRGlzY2xvc2VkIEtleSIgaXMgdGhlIGtleSB1
c2VkIGZvciBpbnRlcnZhbCBpLWQ6IEtfe2ktZH0uCiAgICAgIFRoZXJlIGlzIG5vIHBhZGRp
bmcgYmV0d2VlbiB0aGUgIkRpc2Nsb3NlZCBLZXkiIGFuZCAiTUFDKEsnX2ksIE0pIgogICAg
ICBmaWVsZHMsIGFuZCB0aGUgbGF0dGVyIE1BWSBub3Qgc3RhcnQgb24gYSAzMiBiaXQgYm91
bmRhcnksCiAgICAgIGRlcGVuZGluZyBvbiB0aGUgbl9wIHBhcmFtZXRlci4KCiAgICJNQUMo
SydfaSwgTSkiICh2YXJpYWJsZSBzaXplLCBwYWRkZWQgaWYgbmVjZXNzYXJ5IGZvciAzMiBi
aXQgd29yZAogICBhbGlnbm1lbnQpOgoKICAgICAgTUFDKEsnX2ksIE0pIGlzIHRoZSB0cnVu
Y2F0ZWQgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlIG9mIHRoZQogICAgICBjdXJyZW50
IHBhY2tldC4gIE9ubHkgdGhlIG5fbSBtb3N0IHNpZ25pZmljYW50IGJpdHMgb2YgdGhlIE1B
QwogICAgICBvdXRwdXQgYXJlIGtlcHQgW1JGQzIxMDRdLgoKICAgIkdyb3VwIE1BQyIgZmll
bGQgKG9wdGlvbmFsLCB2YXJpYWJsZSBsZW5ndGgsIG11bHRpcGxlIG9mIDMyIGJpdHMpOgoK
ICAgICAgVGhpcyBmaWVsZCBjb250YWlucyB0aGUgR3JvdXAgTUFDLCBjYWxjdWxhdGVkIHdp
dGggYSBncm91cCBrZXksCiAgICAgIEtfZywgc2hhcmVkIGJ5IGFsbCBncm91cCBtZW1iZXJz
LiAgVGhlIGZpZWxkIGxlbmd0aCBpcyBnaXZlbiBieQogICAgICBuX3csIGluIGJpdHMuCgog
ICBOb3RlIHRoYXQgYmVjYXVzZSBhIGtleSBjYW5ub3QgYmUgZGlzY2xvc2VkIGJlZm9yZSB0
aGUgZGlzY2xvc3VyZQogICBkZWxheSwgZCwgdGhlIHNlbmRlciBNVVNUIE5PVCB1c2UgdGhp
cyB0YWcgZHVyaW5nIHRoZSBmaXJzdCBkCiAgIGludGVydmFscyBvZiB0aGUgc2Vzc2lvbjog
ezAgLi4gZC0xfSAoaW5jbHVzaXZlKS4gIEluc3RlYWQgdGhlIHNlbmRlcgogICBNVVNUIHVz
ZSBhbiBBdXRoZW50aWNhdGlvbiBUYWcgV2l0aG91dCBLZXkgRGlzY2xvc3VyZS4KCjMuNC40
LiAgRm9ybWF0IG9mIGFuIEF1dGhlbnRpY2F0aW9uIFRhZyBXaXRob3V0IEtleSBEaXNjbG9z
dXJlCgogICBUaGUgYXV0aGVudGljYXRpb24gdGFnIHdpdGhvdXQga2V5IGRpc2Nsb3N1cmUg
aXMgbWVhbnQgdG8gYmUgdXNlZCBpbgogICBzaXR1YXRpb25zIHdoZXJlIGEgaGlnaCBudW1i
ZXIgb2YgcGFja2V0cyBhcmUgc2VudCBpbiBhIGdpdmVuIHRpbWUKICAgaW50ZXJ2YWwuICBJ
biBzdWNoIGEgY2FzZSwgaXQgY2FuIGJlIGFkdmFudGFnZW91cyB0byBkaXNjbG9zZSB0aGUK
ICAgS197aS1kfSBrZXkgb25seSBpbiBhIHN1YnNldCBvZiB0aGUgcGFja2V0cyBzZW50LCB1
c2luZyBhIFN0YW5kYXJkCiAgIEF1dGhlbnRpY2F0aW9uIFRhZywgYW5kIHVzZSB0aGUgc2hv
cnRlbmVkIHZlcnNpb24gdGhhdCBkb2VzIG5vdAogICBkaXNjbG9zZSB0aGUgS197aS1kfSBr
ZXkgaW4gdGhlIHJlbWFpbmluZyBwYWNrZXRzLiAgSXQgaXMgbGVmdCB0byB0aGUKICAgaW1w
bGVtZW50ZXIgdG8gZGVjaWRlIGhvdyBtYW55IHBhY2tldHMgc2hvdWxkIGRpc2Nsb3NlIHRo
ZSBLX3tpLWR9CiAgIGtleS4gIFRoaXMgQXV0aGVudGljYXRpb24gVGFnIFdpdGhvdXQgS2V5
IERpc2Nsb3N1cmUgTVVTVCBhbHNvIGJlCiAgIHVzZWQgZHVyaW5nIHRoZSBmaXJzdCBkIGlu
dGVydmFsczogezAgLi4gZC0xfSAoaW5jbHVzaXZlKS4KCgoKCgoKCgoKCgoKUm9jYSwgZXQg
YWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAg
W1BhZ2UgMzRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5k
IE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgICAwICAgICAgICAgICAgICAg
ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAgMCAx
IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4
IDkgMCAxCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICArLSstKy0rLSstKy0rLSstKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfCAgIFJlc2VydmVkICAgIHwKICAgICstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
CiAgICB8ICAgICAgICAgICAgICAgIGkgKEludGVydmFsIEluZGV4IG9mIEsnX2kpICAgICAg
ICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB+
ICAgICAgICAgICAgICAgICAgICAgICBNQUMoSydfaSwgTSkgICAgICAgICAgICArLSstKy0r
LSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfCAgIFBhZGRpbmcgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB+ICAgICAg
ICAgICAgICAgICAgICAgR3JvdXAgTUFDIChvcHRpb25hbCkgICAgICAgICAgICAgICAgICAg
ICAgfgogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgRmlndXJlIDU6IEZvcm1hdCBvZiB0aGUgQXV0
aGVudGljYXRpb24gVGFnIFdpdGhvdXQgS2V5IERpc2Nsb3N1cmUKCjMuNC41LiAgRm9ybWF0
IG9mIGFuIEF1dGhlbnRpY2F0aW9uIFRhZyB3aXRoIGEgYGBOZXcgS2V5IENoYWluJycKICAg
ICAgICBDb21taXRtZW50CgogICBEdXJpbmcgdGhlIGxhc3Qgbl90eF9uZXdrY2MgaW50ZXJ2
YWxzIG9mIHRoZSBjdXJyZW50IGtleSBjaGFpbiwgdGhlCiAgIHNlbmRlciBTSE9VTEQgc2Vu
ZCBjb21taXRtZW50cyB0byB0aGUgbmV4dCBrZXkgY2hhaW4uICBUaGlzIGlzIGRvbmUKICAg
YnkgcmVwbGFjaW5nIHRoZSBkaXNjbG9zZWQga2V5IG9mIHRoZSBhdXRoZW50aWNhdGlvbiB0
YWcgd2l0aCB0aGUgbmV3CiAgIGtleSBjaGFpbiBjb21taXRtZW50LCBGKEtfe04rMX0pIChv
ciBGKEtfezJOKzJ9KSBpbiBjYXNlIG9mIGEgc3dpdGNoCiAgIGJldHdlZW4gdGhlIHNlY29u
ZCBhbmQgdGhpcmQga2V5IGNoYWlucywgZXRjLikuICBGaWd1cmUgNiBzaG93cyB0aGUKICAg
Y29ycmVzcG9uZGluZyBmb3JtYXQuCgogICBOb3RlIHRoYXQgc2luY2UgdGhlcmUgaXMgbm8g
cGFkZGluZyBiZXR3ZWVuIHRoZSAiRihLX3tOKzF9KSIgYW5kCiAgICJNQUMoSydfaSwgTSki
IGZpZWxkcywgdGhpcyBsYXR0ZXIgTUFZIG5vdCBzdGFydCBvbiBhIDMyIGJpdAogICBib3Vu
ZGFyeSwgZGVwZW5kaW5nIG9uIHRoZSBuX3AgcGFyYW1ldGVyLgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAg
ICAgICAgICAgICAgICAgW1BhZ2UgMzVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBU
RVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgICAw
ICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAg
ICAgICAzCiAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg
MSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKwogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIFJlc2VydmVkICAgIHwK
ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICAgIGkgKEludGVydmFsIEluZGV4
IG9mIEsnX2kpICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8CiAgICB+ICAgICAgICAgICAgICBOZXcgS2V5IENvbW1pdG1lbnQgRihLX3tO
KzF9KSAgICAgICAgICAgICAgICAgICAgfgogICAgfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfAogICAgfiAgICAgICAgICAgICAgICAgICAgICAgTUFDKEsn
X2ksIE0pICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBQYWRkaW5nICAgICB8CiAg
ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKwogICAgfiAgICAgICAgICAgICAgICAgICAgIEdyb3VwIE1BQyAob3B0
aW9uYWwpICAgICAgICAgICAgICAgICAgICAgIH4KICAgICstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICAgICBG
aWd1cmUgNjogRm9ybWF0IG9mIHRoZSBBdXRoZW50aWNhdGlvbiBUYWcgd2l0aCBhIE5ldyBL
ZXkgQ2hhaW4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDb21taXRtZW50Cgoz
LjQuNi4gIEZvcm1hdCBvZiBhbiBBdXRoZW50aWNhdGlvbiBUYWcgd2l0aCBhIGBgTGFzdCBL
ZXkgb2YgT2xkIENoYWluJycKICAgICAgICBEaXNjbG9zdXJlCgogICBEdXJpbmcgdGhlIGZp
cnN0IG5fdHhfbGFzdGtleSBpbnRlcnZhbHMgb2YgdGhlIG5ldyBrZXkgY2hhaW4gYWZ0ZXIK
ICAgdGhlIGRpc2Nsb3NpbmcgaW50ZXJ2YWwsIGQsIHRoZSBzZW5kZXIgU0hPVUxEIGRpc2Ns
b3NlIHRoZSBsYXN0IGtleQogICBvZiB0aGUgb2xkIGtleSBjaGFpbi4gIFRoaXMgaXMgZG9u
ZSBieSByZXBsYWNpbmcgdGhlIGRpc2Nsb3NlZCBrZXkgb2YKICAgdGhlIGF1dGhlbnRpY2F0
aW9uIHRhZyB3aXRoIHRoZSBsYXN0IGtleSBvZiB0aGUgb2xkIGNoYWluLCBLX04gKG9yCiAg
IEtfezJOKzF9IGluIGNhc2Ugb2YgYSBzd2l0Y2ggYmV0d2VlbiB0aGUgc2Vjb25kIGFuZCB0
aGlyZCBrZXkgY2hhaW5zLAogICBldGMuKS4gIEZpZ3VyZSA3IHNob3dzIHRoZSBjb3JyZXNw
b25kaW5nIGZvcm1hdC4KCiAgIE5vdGUgdGhhdCBzaW5jZSB0aGVyZSBpcyBubyBwYWRkaW5n
IGJldHdlZW4gdGhlICJLX04iIGFuZCAiTUFDKEsnX2ksCiAgIE0pIiBmaWVsZHMsIHRoaXMg
bGF0dGVyIE1BWSBub3Qgc3RhcnQgb24gYSAzMiBiaXQgYm91bmRhcnksIGRlcGVuZGluZwog
ICBvbiB0aGUgbl9wIHBhcmFtZXRlci4KCgoKCgoKCgoKCgoKCgoKCgpSb2NhLCBldCBhbC4g
ICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFn
ZSAzNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9S
TSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICAgIDAgICAgICAgICAgICAgICAgICAg
MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgICAwIDEgMiAz
IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw
IDEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICstKy0rLSstKy0rLSstKy0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8ICAgUmVzZXJ2ZWQgICAgfAogICAgKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg
IHwgICAgICAgICAgICAgICAgaSAoSW50ZXJ2YWwgSW5kZXggb2YgSydfaSkgICAgICAgICAg
ICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIH4gICAg
ICAgICAgICAgICAgICBMYXN0IEtleSBvZiBPbGQgQ2hhaW4sIEtfTiAgICAgICAgICAgICAg
ICAgICB+CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8
CiAgICB+ICAgICAgICAgICAgICAgICAgICAgICBNQUMoSydfaSwgTSkgICAgICAgICAgICAr
LSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfCAgIFBhZGRpbmcgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB+
ICAgICAgICAgICAgICAgICAgICAgR3JvdXAgTUFDIChvcHRpb25hbCkgICAgICAgICAgICAg
ICAgICAgICAgfgogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgIEZpZ3VyZSA3OiBGb3JtYXQgb2YgdGhl
IGF1dGhlbnRpY2F0aW9uIHRhZyB3aXRoIGFuIG9sZCBjaGFpbiBsYXN0IGtleQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGRpc2Nsb3N1cmUKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKClJvY2EsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIw
LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDM3XQoMCkludGVybmV0LURyYWZ0ICAgICAg
ICAgICAgVEVTTEEgaW4gQUxDIGFuZCBOT1JNICAgICAgICAgICBTZXB0ZW1iZXIgMjAwOQoK
CjQuICBSZWNlaXZlciBPcGVyYXRpb25zCgogICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRo
ZSBURVNMQSBvcGVyYXRpb25zIGF0IGEgcmVjZWl2ZXIuCgo0LjEuICBWZXJpZmljYXRpb24g
b2YgdGhlIEF1dGhlbnRpY2F0aW9uIEluZm9ybWF0aW9uCgogICBUaGlzIHNlY3Rpb24gZGV0
YWlscyB0aGUgY29tcHV0YXRpb24gc3RlcHMgcmVxdWlyZWQgdG8gdmVyaWZ5IGVhY2ggb2YK
ICAgdGhlIHRocmVlIHBvc3NpYmxlIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIG9mIGFu
IGluY29taW5nIHBhY2tldC4KICAgVGhlIHZlcmlmaWNhdGlvbiBNVVNUIGZvbGxvdyBhIHN0
cmljdCBvcmRlcjoKCiAgIG8gIGZpcnN0IG9mIGFsbCwgaWYgdGhlIEdyb3VwIE1BQyBpcyBw
cmVzZW50IGFuZCBpZiB0aGUgc2Vzc2lvbiB1c2VzCiAgICAgIHRoaXMgZmVhdHVyZSAoZS5n
LiwgaWYgdGhlIEcgYml0IGlzIHNldCBpbiB0aGUgYm9vdHN0cmFwCiAgICAgIGluZm9ybWF0
aW9uIG1lc3NhZ2UpLCB0aGVuIHZlcmlmeSB0aGUgR3JvdXAgTUFDLiAgQSBwYWNrZXQgdGhh
dAogICAgICBkb2VzIG5vdCBjb250YWluIGEgR3JvdXAgTUFDIHRhZyB3aGVyZWFzIHRoZSBz
ZXNzaW9uIHVzZXMgdGhpcwogICAgICBmZWF0dXJlIE1VU1QgYmUgaW1tZWRpYXRlbHkgZHJv
cHBlZC4gIE9uIHRoZSBvcHBvc2l0ZSwgaWYgYSBwYWNrZXQKICAgICAgY29udGFpbnMgYSBH
cm91cCBNQUMgdGFnIHdoZXJlYXMgdGhlIHNlc3Npb24gZG9lcyBub3QgdXNlIHRoaXMKICAg
ICAgZmVhdHVyZSwgdGhpcyB0YWcgTVVTVCBiZSBpZ25vcmVkOwoKICAgbyAgdGhlbiB2ZXJp
ZnkgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlICh3aXRoIFRFU0xBIHNpZ25hbGluZyBwYWNrZXRz
KQogICAgICBvciBlbnRlciB0aGUgVEVTTEEgYXV0aGVudGljYXRpb24gcHJvY2VzcyAod2l0
aCBkYXRhIHBhY2tldHMpCgo0LjEuMS4gIFByb2Nlc3NpbmcgdGhlIEdyb3VwIE1BQyBUYWcK
CiAgIFVwb24gcmVjZWl2aW5nIGEgcGFja2V0IGNvbnRhaW5pbmcgYSBHcm91cCBNQUMgVGFn
LCB0aGUgcmVjZWl2ZXIKICAgcmVjb21wdXRlcyB0aGUgR3JvdXAgTUFDIGFuZCBjb21wYXJl
cyBpdCB0byB0aGUgdmFsdWUgY2FycmllZCBpbiB0aGUKICAgcGFja2V0LiAgSWYgdGhlIGNo
ZWNrIGZhaWxzLCB0aGUgcGFja2V0IE1VU1QgYmUgaW1tZWRpYXRlbHkgZHJvcHBlZC4KCiAg
IE1vcmUgc3BlY2lmaWNhbGx5LCByZWNvbXB1dGluZyB0aGUgR3JvdXAgTUFDIHJlcXVpcmVz
IHRvIHNhdmUgdGhlCiAgIHZhbHVlIG9mIHRoZSBHcm91cCBNQUMgZmllbGQsIHRvIHNldCB0
aGlzIGZpZWxkIHRvIDAsIGFuZCB0byBkbyB0aGUKICAgc2FtZSBjb21wdXRhdGlvbiBhcyBh
IHNlbmRlciBkb2VzIChzZWUgU2VjdGlvbiAzLjMuMykuCgo0LjEuMi4gIFByb2Nlc3Npbmcg
dGhlIERpZ2l0YWwgU2lnbmF0dXJlCgogICBVcG9uIHJlY2VpdmluZyBhIHBhY2tldCBjb250
YWluaW5nIGEgZGlnaXRhbCBzaWduYXR1cmUsIHRoZSByZWNlaXZlcgogICB2ZXJpZmllcyB0
aGUgc2lnbmF0dXJlIGFzIGZvbGxvd3MuCgogICBUaGUgY29tcHV0YXRpb24gb2YgdGhlIHNp
Z25hdHVyZSBNVVNUIGluY2x1ZGUgdGhlIEFMQyBvciBOT1JNIGhlYWRlcgogICAod2l0aCB0
aGUgdmFyaW91cyBoZWFkZXIgZXh0ZW5zaW9ucykgYW5kIHRoZSBwYXlsb2FkIHdoZW4gYXBw
bGljYWJsZS4KICAgVGhlIFVEUC9JUCBoZWFkZXJzIE1VU1QgTk9UIGJlIGluY2x1ZGVkLiAg
RHVyaW5nIHRoaXMgY29tcHV0YXRpb24sCiAgIHRoZSAiU2lnbmF0dXJlIiBmaWVsZCBNVVNU
IGJlIHNldCB0byAwIGFzIHdlbGwgYXMgdGhlIG9wdGlvbmFsIEdyb3VwCiAgIE1BQywgd2hl
biBwcmVzZW50LgoKICAgRnJvbSBbUkZDNDM1OV06IERpZ2l0YWwgc2lnbmF0dXJlIHZlcmlm
aWNhdGlvbiBpcyBwZXJmb3JtZWQgYXMKICAgZGVzY3JpYmVkIGluIFtSRkMzNDQ3XSwgU2Vj
dGlvbiA4LjIuMiAoUlNBU1NBLVBLQ1MxLXYxXzUpIGFuZAogICBbUkZDMzQ0N10sIFNlY3Rp
b24gOC4xLjIgKFJTQVNTQS1QU1MpLiAgVXBvbiByZWNlaXB0LCB0aGUgZGlnaXRhbAogICBz
aWduYXR1cmUgaXMgcGFzc2VkIHRvIHRoZSB2ZXJpZmljYXRpb24gZnVuY3Rpb24gYXMgUy4g
VGhlCiAgIGF1dGhlbnRpY2F0ZWQgcG9ydGlvbiBvZiB0aGUgcGFja2V0IGlzIHVzZWQgYXMg
dGhlIG1lc3NhZ2UgTSwgYW5kIHRoZQogICBSU0EgcHVibGljIGtleSBpcyBwYXNzZWQgYXMg
KG4sIGUpLiAgSW4gc3VtbWFyeSAod2hlbiBTSEEtMjU2IGlzCgoKClJvY2EsIGV0IGFsLiAg
ICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdl
IDM4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVEVTTEEgaW4gQUxDIGFuZCBOT1JN
ICAgICAgICAgICBTZXB0ZW1iZXIgMjAwOQoKCiAgIHVzZWQpLCB0aGUgdmVyaWZpY2F0aW9u
IGZ1bmN0aW9uIGNvbXB1dGVzIGEgU0hBLTI1NiBoYXNoIG9mIHRoZQogICBhdXRoZW50aWNh
dGVkIHBhY2tldCBieXRlcywgZGVjcnlwdHMgdGhlIFNIQS0yNTYgaGFzaCBpbiB0aGUgcGFj
a2V0LAogICBhbmQgdmFsaWRhdGVzIHRoYXQgdGhlIGFwcHJvcHJpYXRlIGVuY29kaW5nIHdh
cyBhcHBsaWVkLiAgVGhlIHR3bwogICBTSEEtMjU2IGhhc2hlcyBhcmUgY29tcGFyZWQsIGFu
ZCBpZiB0aGV5IGFyZSBpZGVudGljYWwgdGhlIHZhbGlkYXRpb24KICAgaXMgc3VjY2Vzc2Z1
bC4KCiAgIEl0IGlzIGFzc3VtZWQgdGhhdCB0aGUgcmVjZWl2ZXJzIGhhdmUgdGhlIHBvc3Np
YmlsaXR5IHRvIHJldHJpZXZlIHRoZQogICBzZW5kZXIncyBwdWJsaWMga2V5IHJlcXVpcmVk
IHRvIGNoZWNrIHRoaXMgZGlnaXRhbCBzaWduYXR1cmUKICAgKFNlY3Rpb24gMi4yKS4gIFRo
aXMgZG9jdW1lbnQgZG9lcyBub3Qgc3BlY2lmeSBob3cgdGhlIHB1YmxpYyBrZXkgb2YKICAg
dGhlIHNlbmRlciBpcyBjb21tdW5pY2F0ZWQgcmVsaWFibHkgYW5kIGluIGEgc2VjdXJlIHdh
eSB0byBhbGwKICAgcG9zc2libGUgcmVjZWl2ZXJzLgoKNC4xLjMuICBQcm9jZXNzaW5nIHRo
ZSBBdXRoZW50aWNhdGlvbiBUYWcKCiAgIFdoZW4gYSByZWNlaXZlciB3YW50cyB0byBhdXRo
ZW50aWNhdGUgYSBwYWNrZXQgdXNpbmcgYW4KICAgQXV0aGVudGljYXRpb24gVGFnIGFuZCB3
aGVuIGhlIGhhcyB0aGUga2V5IGZvciB0aGUgYXNzb2NpYXRlZCB0aW1lCiAgIGludGVydmFs
IChpLmUuLCBhZnRlciB0aGUgZGlzY2xvc2luZyBkZWxheSwgZCksIHRoZSByZWNlaXZlcgog
ICByZWNvbXB1dGVzIHRoZSBNQUMgYW5kIGNvbXBhcmVzIGl0IHRvIHRoZSB2YWx1ZSBjYXJy
aWVkIGluIHRoZQogICBwYWNrZXQuICBJZiB0aGUgY2hlY2sgZmFpbHMsIHRoZSBwYWNrZXQg
TVVTVCBiZSBpbW1lZGlhdGVseSBkcm9wcGVkLgoKICAgTW9yZSBzcGVjaWZpY2FsbHksIHJl
Y29tcHV0aW5nIHRoZSBNQUMgcmVxdWlyZXMgdG8gc2F2ZSB0aGUgdmFsdWUgb2YKICAgdGhl
IE1BQyBmaWVsZCwgdG8gc2V0IHRoaXMgZmllbGQgdG8gMCwgYW5kIHRvIGRvIHRoZSBzYW1l
IGNvbXB1dGF0aW9uCiAgIGFzIGEgc2VuZGVyIGRvZXMgKHNlZSBTZWN0aW9uIDMuMy4xKS4K
CjQuMi4gIEluaXRpYWxpemF0aW9uIG9mIGEgUmVjZWl2ZXIKCiAgIEEgcmVjZWl2ZXIgTVVT
VCBiZSBpbml0aWFsaXplZCBiZWZvcmUgYmVpbmcgYWJsZSB0byBhdXRoZW50aWNhdGUgdGhl
CiAgIHNvdXJjZSBvZiBpbmNvbWluZyBwYWNrZXRzLiAgVGhpcyBjYW4gYmUgZG9uZSBieSBh
biBvdXQtb2YtYmFuZAogICBtZWNoYW5pc20gb3IgYW4gaW4tYmFuZCBtZWNoYW5pc20gKFNl
Y3Rpb24gMi4yKS4gIExldCB1cyBmb2N1cyBvbiB0aGUKICAgaW4tYmFuZCBtZWNoYW5pc20u
ICBUd28gYWN0aW9ucyBtdXN0IGJlIHBlcmZvcm1lZDoKCiAgIG8gIHJlY2VpdmUgYW5kIHBy
b2Nlc3MgYSBib290c3RyYXAgaW5mb3JtYXRpb24gbWVzc2FnZSwgYW5kCgogICBvICBjYWxj
dWxhdGUgYW4gdXBwZXIgYm91bmQgb2YgdGhlIHNlbmRlcidzIGxvY2FsIHRpbWUuICBUbyB0
aGF0CiAgICAgIHB1cnBvc2UsIHRoZSByZWNlaXZlciBtdXN0IHBlcmZvcm0gdGltZSBzeW5j
aHJvbml6YXRpb24uCgo0LjIuMS4gIFByb2Nlc3NpbmcgdGhlIEJvb3RzdHJhcCBJbmZvcm1h
dGlvbiBNZXNzYWdlCgogICBBIHJlY2VpdmVyIG11c3QgZmlyc3QgcmVjZWl2ZSBhIHBhY2tl
dCBjb250YWluaW5nIHRoZSBib290c3RyYXAKICAgaW5mb3JtYXRpb24sIGRpZ2l0YWxseSBz
aWduZWQgYnkgdGhlIHNlbmRlci4gIE9uY2UgdGhlIGJvb3RzdHJhcAogICBpbmZvcm1hdGlv
biBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIChzZWMgU2VjdGlvbiA0LjEpLCB0aGUgcmVjZWl2
ZXIKICAgY2FuIGluaXRpYWxpemUgaXRzIFRFU0xBIGNvbXBvbmVudC4gIFRoZSByZWNlaXZl
ciBNVVNUIHRoZW4gaWdub3JlCiAgIHRoZSBmb2xsb3dpbmcgYm9vdHN0cmFwIGluZm9ybWF0
aW9uIG1lc3NhZ2VzLCBpZiBhbnkuICBUaGVyZSBpcyBhbgogICBleGNlcHRpb24gdGhvdWdo
OiB3aGVuIGEgbmV3IGtleSBjaGFpbiBpcyB1c2VkIGFuZCBpZiBhIHJlY2VpdmVyCiAgIG1p
c3NlZCBhbGwgdGhlIGNvbW1pdG1lbnRzIGZvciB0aGlzIG5ldyBrZXkgY2hhaW4sIHRoZW4g
dGhpcyByZWNlaXZlcgogICBNVVNUIHByb2Nlc3Mgb25lIG9mIHRoZSBmdXR1cmUgQm9vdHN0
cmFwIGluZm9ybWF0aW9uIG1lc3NhZ2VzIChpZgogICBhbnkpIGluIG9yZGVyIHRvIGJlIGFi
bGUgdG8gYXV0aGVudGljYXRlIHRoZSBpbmNvbWluZyBwYWNrZXRzCiAgIGFzc29jaWF0ZWQg
dG8gdGhpcyBuZXcga2V5IGNoYWluLgoKCgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhw
aXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAzOV0KDApJbnRlcm5l
dC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2Vw
dGVtYmVyIDIwMDkKCgogICBCZWZvcmUgVEVTTEEgaGFzIGJlZW4gaW5pdGlhbGl6ZWQsIGEg
cmVjZWl2ZXIgTVVTVCBkaXNjYXJkIGluY29taW5nCiAgIHBhY2tldHMgb3RoZXIgdGhhbiB0
aGUgYm9vdHN0cmFwIGluZm9ybWF0aW9uIG1lc3NhZ2UgYW5kIGRpcmVjdCB0aW1lCiAgIHN5
bmNocm9uaXphdGlvbiByZXNwb25zZS4KCjQuMi4yLiAgUGVyZm9ybWluZyBUaW1lIFN5bmNo
cm9uaXphdGlvbgoKICAgRmlyc3Qgb2YgYWxsLCB0aGUgcmVjZWl2ZXIgbXVzdCBrbm93IHdo
ZXRoZXIgdGhlIEFMQyBvciBOT1JNIHNlc3Npb24KICAgcmVsaWVzIG9uIGRpcmVjdCBvciBp
bmRpcmVjdCB0aW1lIHN5bmNocm9uaXphdGlvbi4gIFRoaXMgaW5mb3JtYXRpb24KICAgaXMg
Y29tbXVuaWNhdGVkIGJ5IGFuIG91dC1vZi1iYW5kIG1lY2hhbmlzbSAoZm9yIGluc3RhbmNl
IHdoZW4KICAgZGVzY3JpYmluZyB0aGUgdmFyaW91cyBwYXJhbWV0ZXJzIG9mIGFuIEFMQyBv
ciBOT1JNIHNlc3Npb24uICBJbiBzb21lCiAgIGNhc2VzLCBib3RoIG1lY2hhbmlzbXMgbWln
aHQgYmUgYXZhaWxhYmxlIGFuZCB0aGUgcmVjZWl2ZXIgY2FuIGNob29zZQogICB0aGUgcHJl
ZmVycmVkIHRlY2huaXF1ZS4KCjQuMi4yLjEuICBEaXJlY3QgVGltZSBTeW5jaHJvbml6YXRp
b24KCiAgIEluIGNhc2Ugb2YgYSBkaXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24sIGEgcmVj
ZWl2ZXIgTVVTVCBzeW5jaHJvbml6ZQogICB3aXRoIHRoZSBzZW5kZXIuICBUbyB0aGF0IHB1
cnBvc2UsIHRoZSByZWNlaXZlciBzZW5kcyBhIGRpcmVjdCB0aW1lCiAgIHN5bmNocm9uaXph
dGlvbiByZXF1ZXN0IG1lc3NhZ2UuICBUaGlzIG1lc3NhZ2UgaW5jbHVkZXMgdGhlIGxvY2Fs
CiAgIHRpbWUgKGluIE5UUCB0aW1lc3RhbXAgZm9ybWF0KSBhdCB0aGUgcmVjZWl2ZXIgd2hl
biBzZW5kaW5nIHRoZQogICBtZXNzYWdlLiAgVGhpcyB0aW1lc3RhbXAgd2lsbCBiZSBjb3Bp
ZWQgaW4gdGhlIHNlbmRlcidzIHJlc3BvbnNlIGZvcgogICB0aGUgcmVjZWl2ZXIgdG8gYXNz
b2NpYXRlIHRoZSByZXNwb25zZSB0byB0aGUgcmVxdWVzdC4KCiAgIFRoZSBkaXJlY3QgdGlt
ZSBzeW5jaHJvbml6YXRpb24gcmVxdWVzdCBtZXNzYWdlIGZvcm1hdCBpcyB0aGUKICAgZm9s
bG93aW5nOgoKCiAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAg
IDIgICAgICAgICAgICAgICAgICAgMwogICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg
MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsK
ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8CiAgICArICAgICAgICAgICAgICAgICAgICAgdF9yIChOVFAgdGlt
ZXN0YW1wKSAgICAgICAgICAgICAgICAgICAgICAgKwogICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rCiAgICB+ICAgICAgICAgICAgICAgICAgICAgR3JvdXAgTUFDIChvcHRpb25h
bCkgICAgICAgICAgICAgICAgICAgICAgfgogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgIEZp
Z3VyZSA4OiBGb3JtYXQgb2YgYSBEaXJlY3QgVGltZSBTeW5jaHJvbml6YXRpb24gUmVxdWVz
dAoKICAgVGhlIGRpcmVjdCB0aW1lIHN5bmNocm9uaXphdGlvbiByZXF1ZXN0IChGaWd1cmUg
OCkgY29udGFpbnMgdGhlCiAgIGZvbGxvd2luZyBpbmZvcm1hdGlvbjoKCiAgICJ0X3IiIChO
VFAgdGltZXN0YW1wLCA2NCBiaXRzKToKCiAgICAgIHRfciBpcyBhIHRpbWVzdGFtcCBpbiBO
VFAgdGltZXN0YW1wIGZvcm1hdCB0aGF0IGNvbnRhaW5zIHRoZQogICAgICByZWNlaXZlciBs
b2NhbCB0aW1lIHZhbHVlIHdoZW4gc2VuZGluZyB0aGlzIGRpcmVjdCB0aW1lCiAgICAgIHN5
bmNocm9uaXphdGlvbiByZXF1ZXN0IG1lc3NhZ2U7CgogICAiR3JvdXAgTUFDIiBmaWVsZCAo
b3B0aW9uYWwsIHZhcmlhYmxlIGxlbmd0aCwgbXVsdGlwbGUgb2YgMzIgYml0cyk6CgoKClJv
Y2EsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwLCAyMDEwICAgICAgICAg
ICAgICAgIFtQYWdlIDQwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVEVTTEEgaW4g
QUxDIGFuZCBOT1JNICAgICAgICAgICBTZXB0ZW1iZXIgMjAwOQoKCiAgICAgIFRoaXMgZmll
bGQgY29udGFpbnMgdGhlIEdyb3VwIE1BQywgY2FsY3VsYXRlZCB3aXRoIHRoZSBncm91cCBr
ZXksCiAgICAgIEtfZywgc2hhcmVkIGJ5IGFsbCBncm91cCBtZW1iZXJzLiAgVGhlIGZpZWxk
IGxlbmd0aCwgaW4gYml0cywgaXMKICAgICAgZ2l2ZW4gYnkgbl93LCB3aGljaCBpcyBrbm93
biBvbmNlIHRoZSBHcm91cCBNQUMgZnVuY3Rpb24gdHlwZSBpcwogICAgICBrbm93biAoU2Vj
dGlvbiA3KS4KCiAgIFRoZSByZWNlaXZlciB0aGVuIGF3YWl0cyBhIHJlc3BvbnNlIG1lc3Nh
Z2UgKFNlY3Rpb24gMy40LjIpLiAgVXBvbgogICByZWNlaXZpbmcgdGhpcyBtZXNzYWdlLCB0
aGUgcmVjZWl2ZXI6CgogICAgICBjaGVja3MgdGhhdCB0aGlzIHJlc3BvbnNlIHJlbGF0ZXMg
dG8gdGhlIHJlcXVlc3QsIGJ5IGNvbXBhcmluZyB0aGUKICAgICAgdF9yIGZpZWxkczsKCiAg
ICAgIGNoZWNrcyB0aGUgR3JvdXAgTUFDIGlmIHByZXNlbnQ7CgogICAgICBjaGVja3MgdGhl
IHNpZ25hdHVyZTsKCiAgICAgIHJldHJpZXZlcyB0aGUgdF9zIHZhbHVlIGFuZCBjYWxjdWxh
dGVzIERfdCAoU2VjdGlvbiAyLjQuMSk7CgogICBOb3RlIHRoYXQgaW4gYW4gQUxDIHNlc3Np
b24sIHRoZSBkaXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24gcmVxdWVzdAogICBtZXNzYWdl
IGlzIHNlbnQgdG8gdGhlIHNlbmRlciBieSBhbiBvdXQtb2YtYmFuZCBtZWNoYW5pc20gdGhh
dCBpcyBub3QKICAgc3BlY2lmaWVkIGJ5IHRoZSBjdXJyZW50IGRvY3VtZW50LgoKNC4yLjIu
Mi4gIEluZGlyZWN0IFRpbWUgU3luY2hyb25pemF0aW9uCgogICBXaXRoIHRoZSBpbmRpcmVj
dCB0aW1lIHN5bmNocm9uaXphdGlvbiBtZXRob2QsIHRoZSBzZW5kZXIgTUFZIHByb3ZpZGUK
ICAgb3V0LW9mLWJhbmQgdGhlIFVSTCBvciBJUCBhZGRyZXNzIG9mIHRoZSBOVFAgc2VydmVy
KHMpIGhlIHRydXN0cwogICBhbG9uZyB3aXRoIGFuIE9QVElPTkFMIGNlcnRpZmljYXRlIGZv
ciBlYWNoIE5UUCBzZXJ2ZXIuICBXaGVuIHNldmVyYWwKICAgTlRQIHNlcnZlcnMgYXJlIHNw
ZWNpZmllZCwgYSByZWNlaXZlciBNVVNUIGNob29zZSBvbmUgb2YgdGhlbS4gIFRoaXMKICAg
ZG9jdW1lbnQgZG9lcyBub3Qgc3BlY2lmeSBob3cgdGhlIGNob2ljZSBpcyBtYWRlLCBidXQg
Zm9yIHRoZSBzYWtlIG9mCiAgIHNjYWxhYmlsaXR5LCB0aGUgY2xpZW50cyBTSE9VTEQgTk9U
IHVzZSB0aGUgc2FtZSBzZXJ2ZXIgaWYgc2V2ZXJhbAogICBwb3NzaWJpbGl0aWVzIGFyZSBv
ZmZlcmVkLiAgVGhlIE5UUCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiB0aGUgTlRQCiAgIHNl
cnZlciBhbmQgdGhlIHJlY2VpdmVyIE1VU1QgYmUgYXV0aGVudGljYXRlZCwgZWl0aGVyIHVz
aW5nIHRoZQogICBjZXJ0aWZpY2F0ZSBwcm92aWRlZCBieSB0aGUgc2VydmVyLCBvciBhbm90
aGVyIGNlcnRpZmljYXRlIHRoZSBjbGllbnQKICAgbWF5IG9idGFpbiBmb3IgdGhpcyBOVFAg
c2VydmVyLgoKICAgVGhlbiB0aGUgcmVjZWl2ZXIgY29tcHV0ZXMgdGhlIHRpbWUgb2Zmc2V0
IGJldHdlZW4gaXRzZWxmIGFuZCB0aGUgTlRQCiAgIHNlcnZlciBjaG9zZW4uICBOb3RlIHRo
YXQgdGhlIHJlY2VpdmVyIGRvZXMgbm90IG5lZWQgdG8gdXBkYXRlIHRoZQogICBsb2NhbCB0
aW1lLCAod2hpY2ggb2Z0ZW4gcmVxdWlyZXMgcm9vdCBwcml2aWxlZ2VzKSwgY29tcHV0aW5n
IHRoZQogICB0aW1lIG9mZnNldCBpcyBzdWZmaWNpZW50LgoKICAgU2luY2UgdGhlIG9mZnNl
dCBiZXR3ZWVuIHRoZSBzZXJ2ZXIgYW5kIHRoZSB0aW1lIHJlZmVyZW5jZSwgRF5PX3QsIGlz
CiAgIGluZGljYXRlZCBpbiB0aGUgYm9vdHN0cmFwIGluZm9ybWF0aW9uIG1lc3NhZ2UgKG9y
IGNvbW11bmljYXRlZCBvdXQtCiAgIG9mLWJhbmQpLCB0aGUgcmVjZWl2ZXIgY2FuIG5vdyBj
YWxjdWxhdGUgYW4gdXBwZXIgYm91bmQgb2YgdGhlCiAgIHNlbmRlcidzIGxvY2FsIHRpbWUg
KFNlY3Rpb24gMi40LjIpLgoKICAgTm90ZSB0aGF0IHRoaXMgc2NlbmFyaW8gYXNzdW1lcyB0
aGF0IGVhY2ggY2xpZW50IHRydXN0cyB0aGUgc2VuZGVyCiAgIGFuZCBhY2NlcHRzIHRvIGFs
aWduIGl0cyBOVFAgY29uZmlndXJhdGlvbiB0byB0aGF0IG9mIHRoZSBzZW5kZXIsCiAgIHVz
aW5nIG9uZSBvZiB0aGUgTlRQIHNlcnZlcihzKSBzdWdnZXN0ZWQuICBJZiB0aGlzIGFzc3Vt
cHRpb24gZG9lcwogICBub3QgaG9sZCwgdGhlIGNsaWVudCBNVVNUIE5PVCB1c2UgdGhlIE5U
UCBpbmRpcmVjdCB0aW1lCgoKClJvY2EsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1h
cmNoIDIwLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDQxXQoMCkludGVybmV0LURyYWZ0
ICAgICAgICAgICAgVEVTTEEgaW4gQUxDIGFuZCBOT1JNICAgICAgICAgICBTZXB0ZW1iZXIg
MjAwOQoKCiAgIHN5bmNocm9uaXphdGlvbiBtZXRob2QgKFNlY3Rpb24gMi4zLjIpLgoKNC4z
LiAgQXV0aGVudGljYXRpb24gb2YgUmVjZWl2ZWQgUGFja2V0cwoKICAgVGhlIHJlY2VpdmVy
IGNhbiBub3cgYXV0aGVudGljYXRlIGluY29taW5nIHBhY2tldHMgKG90aGVyIHRoYW4KICAg
Ym9vdHN0cmFwIGluZm9ybWF0aW9uIGFuZCBkaXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24g
cmVzcG9uc2UKICAgcGFja2V0cykuICBUbyB0aGF0IHB1cnBvc2UsIGhlIE1VU1QgZm9sbG93
IGRpZmZlcmVudCBzdGVwcyAoc2VlCiAgIFtSRkM0MDgyXSBzZWN0aW9uIDMuNSk6CgogICAx
LiAgVGhlIHJlY2VpdmVyIHBhcnNlcyB0aGUgZGlmZmVyZW50IHBhY2tldCBoZWFkZXJzLiAg
SWYgbm9uZSBvZiB0aGUKICAgICAgIGZvdXIgVEVTTEEgYXV0aGVudGljYXRpb24gdGFncyBp
cyBwcmVzZW50LCB0aGUgcmVjZWl2ZXIgTVVTVAogICAgICAgZGlzY2FyZCB0aGUgcGFja2V0
LiAgSWYgdGhlIHNlc3Npb24gaXMgaW4gIlNpbmdsZSBLZXkgQ2hhaW4iIG1vZGUKICAgICAg
IChlLmcuLCB3aGVuIHRoZSAiUyIgZmxhZyBpcyBzZXQgaW4gdGhlIGJvb3RzdHJhcCBpbmZv
cm1hdGlvbgogICAgICAgbWVzc2FnZSksIHRoZW4gdGhlIHJlY2VpdmVyIE1VU1QgZGlzY2Fy
ZCBhbnkgcGFja2V0IGNvbnRhaW5pbmcgYW4KICAgICAgIEF1dGhlbnRpY2F0aW9uIFRhZyBX
aXRoIGEgTmV3IEtleSBDaGFpbiBDb21taXRtZW50IG9yIGFuCiAgICAgICBBdXRoZW50aWNh
dGlvbiBUYWcgV2l0aCBhIExhc3QgS2V5IG9mIE9sZCBDaGFpbiBEaXNjbG9zdXJlLgoKICAg
Mi4gIFNhZmUgcGFja2V0IHRlc3Q6IFdoZW4gdGhlIHJlY2VpdmVyIHJlY2VpdmVzIHBhY2tl
dCBQX2osIGl0IGZpcnN0CiAgICAgICByZWNvcmRzIHRoZSBsb2NhbCB0aW1lIFQgYXQgd2hp
Y2ggdGhlIHBhY2tldCBhcnJpdmVkLiAgVGhlCiAgICAgICByZWNlaXZlciB0aGVuIGNvbXB1
dGVzIGFuIHVwcGVyIGJvdW5kIHRfaiBvbiB0aGUgc2VuZGVyJ3MgY2xvY2sKICAgICAgIGF0
IHRoZSB0aW1lIHdoZW4gdGhlIHBhY2tldCBhcnJpdmVkOiB0X2ogPSBUICsgRF90LiAgVGhl
IHJlY2VpdmVyCiAgICAgICB0aGVuIGNvbXB1dGVzIHRoZSBoaWdoZXN0IGludGVydmFsIHRo
ZSBzZW5kZXIgY291bGQgcG9zc2libHkgYmUKICAgICAgIGluOiBoaWdoZXN0X2kgPSBmbG9v
cigodF9qIC0gVF8wKSAvIFRfaW50KS4gIEhlIGFsc28gcmV0cmlldmVzCiAgICAgICB0aGUg
ImkiIGludGVydmFsIGluZGV4IGZyb20gdGhlIGF1dGhlbnRpY2F0aW9uIHRhZy4gIFRoZSBy
ZWNlaXZlcgogICAgICAgY2FuIG5vdyBwcm9jZWVkIHdpdGggdGhlICJzYWZlIHBhY2tldCIg
dGVzdC4gIElmIGhpZ2hlc3RfaSA8IGkgKwogICAgICAgZCwgdGhlbiB0aGUgc2VuZGVyIGlz
IG5vdCB5ZXQgaW4gdGhlIGludGVydmFsIGR1cmluZyB3aGljaCBpdAogICAgICAgZGlzY2xv
c2VzIHRoZSBrZXkgS19pLiAgVGhlIHBhY2tldCBpcyBzYWZlIChidXQgbm90IG5lY2Vzc2Fy
aWx5CiAgICAgICBhdXRoZW50aWMpLiAgSWYgdGhlIHRlc3QgZmFpbHMsIHRoZSBwYWNrZXQg
aXMgdW5zYWZlLCBhbmQgdGhlCiAgICAgICByZWNlaXZlciBNVVNUIGRpc2NhcmQgdGhlIHBh
Y2tldC4KCiAgIDMuICBHcm91cCBNQUMgdGVzdDogaWYgdGhlIG9wdGlvbmFsIEdyb3VwIE1B
QyB0YWcgaXMgcHJlc2VudCBhbmQgaWYKICAgICAgIHRoZSBzZXNzaW9uIHVzZXMgdGhpcyBm
ZWF0dXJlLCB0aGVuIHZlcmlmeSB0aGUgR3JvdXAgTUFDCiAgICAgICAoU2VjdGlvbiA0LjEu
MSkuICBJZiB0aGUgdmVyaWZpY2F0aW9uIGZhaWxzLCB0aGUgcGFja2V0IE1VU1QgYmUKICAg
ICAgIGltbWVkaWF0ZWx5IGRyb3BwZWQuICBBIHBhY2tldCB0aGF0IGRvZXMgbm90IGNvbnRh
aW4gYSBHcm91cCBNQUMKICAgICAgIHRhZyB3aGVyZWFzIHRoZSBzZXNzaW9uIHVzZXMgdGhp
cyBmZWF0dXJlIE1VU1QgYmUgaW1tZWRpYXRlbHkKICAgICAgIGRyb3BwZWQuICBPbiB0aGUg
b3Bwb3NpdGUsIGlmIGEgcGFja2V0IGNvbnRhaW5zIGEgR3JvdXAgTUFDIHRhZwogICAgICAg
d2hlcmVhcyB0aGUgc2Vzc2lvbiBkb2VzIG5vdCB1c2UgdGhpcyBmZWF0dXJlLCB0aGlzIHRh
ZyBNVVNUIGJlCiAgICAgICBpZ25vcmVkLgoKICAgNC4gIERpc2Nsb3NlZCBLZXkgcHJvY2Vz
c2luZzogV2hlbiB0aGUgcGFja2V0IGRpc2Nsb3NlcyBhIGtleSAoaS5lLiwKICAgICAgIHdp
dGggYSBTdGFuZGFyZCBBdXRoZW50aWNhdGlvbiBUYWcsIG9yIHdpdGggYW4gQXV0aGVudGlj
YXRpb24gVGFnCiAgICAgICB3aXRoIGEgYGBMYXN0IEtleSBvZiBPbGQgQ2hhaW4nJyBEaXNj
bG9zdXJlKSwgdGhlIGZvbGxvd2luZyB0ZXN0cwogICAgICAgYXJlIHBlcmZvcm1lZDoKCiAg
ICAgICAqICBOZXcga2V5IGluZGV4IHRlc3Q6IHRoZSByZWNlaXZlciBjaGVja3Mgd2hldGhl
ciBhIGxlZ2l0aW1hdGUKICAgICAgICAgIGtleSBhbHJlYWR5IGV4aXN0cyB3aXRoIHRoZSBz
YW1lIGluZGV4IChpLmUuLCBpLWQpLiAgSWYgc3VjaCBhCiAgICAgICAgICBsZWdpdGltYXRl
IGtleSBleGlzdHMsIHRoZSByZWNlaXZlciBjb21wYXJlcyBpdHMgdmFsdWUgd2l0aAogICAg
ICAgICAgdGhlIGN1cnJlbnQgZGlzY2xvc2VkIGtleSBhbmQgaWYgdGhleSBhcmUgaWRlbnRp
Y2FsLCBza2lwcyB0aGUKCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFy
Y2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNDJdCgwKSW50ZXJuZXQtRHJhZnQg
ICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAy
MDA5CgoKICAgICAgICAgICJVbnZlcmlmaWFibGUga2V5IHRlc3QiIGFuZCAiS2V5IHZlcmlm
aWNhdGlvbiB0ZXN0Ii4gIElmIHN1Y2gKICAgICAgICAgIGEgbGVnaXRpbWF0ZSBrZXkgZXhp
c3RzIGJ1dCB0aGUgdmFsdWVzIGRpZmZlciwgdGhlIHJlY2VpdmVyCiAgICAgICAgICBNVVNU
IGRpc2NhcmQgdGhlIHBhY2tldC4KCiAgICAgICAqICBVbnZlcmlmaWFibGUga2V5IHRlc3Q6
IHdoZW4gdGhlIGRpc2Nsb3NlZCBrZXkgaW5kZXggaXMgbmV3LCBpdAogICAgICAgICAgaXMg
cG9zc2libGUgdGhhdCBubyBlYXJsaWVyIGRpc2Nsb3NlZCBhbmQgbGVnaXRpbWF0ZSBrZXkK
ICAgICAgICAgIGV4aXN0cyBmb3IgdGhpcyBrZXkgY2hhaW4sIHRoZXJlYnkgcHJldmVudGlu
ZyB0aGUgdmVyaWZpY2F0aW9uCiAgICAgICAgICBvZiB0aGUgZGlzY2xvc2VkIGtleS4gIFRo
aXMgaGFwcGVucyB3aGVuIHRoZSBkaXNjbG9zZWQga2V5CiAgICAgICAgICBiZWxvbmdzIHRv
IHRoZSBvbGQga2V5IGNoYWluIGFuZCBubyBjb21taXRtZW50IHRvIHRoaXMgb2xkIGtleQog
ICAgICAgICAgY2hhaW4gaGFzIGV2ZXIgYmVlbiByZWNlaXZlZCAoZS5nLiwgYmVjYXVzZSB0
aGUgZmlyc3QKICAgICAgICAgIGJvb3RzdHJhcCBwYWNrZXQgcmVjZWl2ZWQgYnkgYSBsYXRl
Y29tZXIgaXMgZm9yIHRoZSBjdXJyZW50CiAgICAgICAgICBrZXkgY2hhaW4sIGFuZCB0aGVy
ZWZvcmUgaW5jbHVkZXMgYSBjb21taXRtZW50IHRvIHRoZSBjdXJyZW50CiAgICAgICAgICBr
ZXkgY2hhaW4sIG5vdCB0aGUgcHJldmlvdXMgb25lKS4gIFdoZW4gdGhpcyBoYXBwZW5zLCB0
aGUKICAgICAgICAgIHJlY2VpdmVyIE1VU1QgaWdub3JlIHRoZSBkaXNjbG9zZWQga2V5IChh
bnl3YXkgdXNlbGVzcykgYW5kCiAgICAgICAgICBza2lwIHRoZSAiS2V5IHZlcmlmaWNhdGlv
biB0ZXN0Ii4KCiAgICAgICAqICBLZXkgdmVyaWZpY2F0aW9uIHRlc3Q6IElmIHRoZSBkaXNj
bG9zZWQga2V5IGluZGV4IGlzIG5ldyBhbmQKICAgICAgICAgIHRoZSBrZXkgY2FuIGJlIHZl
cmlmaWVkLCB0aGUgcmVjZWl2ZXIgY2hlY2tzIHRoZSBsZWdpdGltYWN5IG9mCiAgICAgICAg
ICBLX3tpLWR9IGJ5IHZlcmlmeWluZywgZm9yIHNvbWUgZWFybGllciBkaXNjbG9zZWQgYW5k
CiAgICAgICAgICBsZWdpdGltYXRlIGtleSBLX3YgKHdpdGggdiA8IGktZCksIHRoYXQgS192
IGFuZCBGXntpLWQtCiAgICAgICAgICB2fShLX3tpLWR9KSBhcmUgaWRlbnRpY2FsLiAgSW4g
b3RoZXIgd29yZHMsIHRoZSByZWNlaXZlcgogICAgICAgICAgY2hlY2tzIHRoZSBkaXNjbG9z
ZWQga2V5IGJ5IGNvbXB1dGluZyB0aGUgbmVjZXNzYXJ5IG51bWJlciBvZgogICAgICAgICAg
UFJGIGZ1bmN0aW9ucyB0byBvYnRhaW4gYSBwcmV2aW91c2x5IGRpc2Nsb3NlZCBhbmQgbGVn
aXRpbWF0ZQogICAgICAgICAgKGkuZS4sIHZlcmlmaWVkKSBrZXkuICBJZiB0aGUga2V5IHZl
cmlmaWNhdGlvbiBmYWlscywgdGhlCiAgICAgICAgICByZWNlaXZlciBNVVNUIGRpc2NhcmQg
dGhlIHBhY2tldC4gIElmIHRoZSBrZXkgdmVyaWZpY2F0aW9uCiAgICAgICAgICBzdWNjZWVk
cywgdGhpcyBrZXkgaXMgc2FpZCBsZWdpdGltYXRlIGFuZCBpcyBzdG9yZWQgYnkgdGhlCiAg
ICAgICAgICByZWNlaXZlciwgYXMgd2VsbCBhcyBhbGwgdGhlIGtleXMgYmV0d2VlbiBpbmRl
eGVzIHYgYW5kIGktZC4KCiAgIDUuICBXaGVuIGFwcGxpY2FibGUsIHRoZSByZWNlaXZlciBw
ZXJmb3JtcyBhbnkgY29uZ2VzdGlvbiBjb250cm9sCiAgICAgICByZWxhdGVkIGFjdGlvbiAo
aS5lLiwgdGhlIEFMQyBvciBOT1JNIGhlYWRlcnMgYXJlIHVzZWQgYnkgdGhlCiAgICAgICBh
c3NvY2lhdGVkIGNvbmdlc3Rpb24gY29udHJvbCBidWlsZGluZyBibG9jaywgaWYgYW55KSwg
ZXZlbiBpZgogICAgICAgdGhlIHBhY2tldCBoYXMgbm90IHlldCBiZWVuIGF1dGhlbnRpY2F0
ZWQgW1JNVC1CQi1MQ1RdLiAgSWYgdGhpcwogICAgICAgZmVhdHVyZSBsZWFkcyB0byBhIHBv
dGVudGlhbCBEb1MgYXR0YWNrICh0aGUgYXR0YWNrZXIgY2FuIHNlbmQgYQogICAgICAgZmFr
ZWQgcGFja2V0IHdpdGggYSB3cm9uZyBzZXF1ZW5jZSBudW1iZXIgdG8gc2ltdWxhdGUgcGFj
a2V0CiAgICAgICBsb3NzZXMpLCBpdCBkb2VzIG5vdCBjb21wcm9taXNlIHRoZSBzZWN1cml0
eSBmZWF0dXJlcyBvZmZlcmVkIGJ5CiAgICAgICBURVNMQSBhbmQgZW5hYmxlcyBhIHJhcGlk
IHJlYWN0aW9uIGluIGZyb250IG9mIGFjdHVhbCBjb25nZXN0aW9uCiAgICAgICBwcm9ibGVt
cy4KCiAgIDYuICBUaGUgcmVjZWl2ZXIgdGhlbiBidWZmZXJzIHRoZSBwYWNrZXQgZm9yIGEg
bGF0ZXIgYXV0aGVudGljYXRpb24sCiAgICAgICBvbmNlIHRoZSBjb3JyZXNwb25kaW5nIGtl
eSB3aWxsIGJlIGRpc2Nsb3NlZCAoYWZ0ZXIgZCB0aW1lCiAgICAgICBpbnRlcnZhbHMpIG9y
IGRlZHVjZWQgZnJvbSBhbm90aGVyIGtleSAoaWYgYWxsIHBhY2tldHMgZGlzY2xvc2luZwog
ICAgICAgdGhpcyBrZXkgYXJlIGxvc3QpLiAgSW4gc29tZSBzaXR1YXRpb25zLCB0aGlzIHBh
Y2tldCBtaWdodCBhbHNvCiAgICAgICBiZSBkaXNjYXJkZWQgbGF0ZXIgb24sIGlmIGl0IHR1
cm5zIG91dCB0aGF0IHRoZSByZWNlaXZlciB3aWxsCiAgICAgICBuZXZlciBiZSBhYmxlIHRv
IGRlZHVjZSB0aGUgYXNzb2NpYXRlZCBrZXkuCgogICA3LiAgQXV0aGVudGljYXRpb24gdGVz
dDogTGV0IHYgYmUgdGhlIHNtYWxsZXN0IGluZGV4IG9mIHRoZQogICAgICAgbGVnaXRpbWF0
ZSBrZXlzIGtub3duIGJ5IHRoZSByZWNlaXZlciBzbyBmYXIuICBGb3IgYWxsIHRoZSBuZXcK
ICAgICAgIGtleXMgS193LCB3aXRoIHYgPCB3IDw9IGktZCwgdGhhdCBoYXZlIGJlZW4gZWl0
aGVyIGRpc2Nsb3NlZCBieQoKCgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBN
YXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA0M10KDApJbnRlcm5ldC1EcmFm
dCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVy
IDIwMDkKCgogICAgICAgdGhpcyBwYWNrZXQgKGkuZS4sIEtfe2ktZH0pIG9yIGRlcml2ZWQg
YnkgS197aS1kfSAoaS5lLiwga2V5cyBpbgogICAgICAgaW50ZXJ2YWwge3YrMSwuLiBpLWQt
MX0pLCB0aGUgcmVjZWl2ZXIgdmVyaWZpZXMgdGhlIGF1dGhlbnRpY2l0eQogICAgICAgb2Yg
dGhlIHNhZmUgcGFja2V0cyBidWZmZXJlZCBmb3IgdGhlIGNvcnJlc3BvbmRpbmcgaW50ZXJ2
YWwgdy4KICAgICAgIFRvIGF1dGhlbnRpY2F0ZSBvbmUgb2YgdGhlIGJ1ZmZlcmVkIHBhY2tl
dHMgUF9oIGNvbnRhaW5pbmcKICAgICAgIG1lc3NhZ2UgTV9oIHByb3RlY3RlZCB3aXRoIGEg
TUFDIHRoYXQgdXNlZCBrZXkgaW5kZXggdywgdGhlCiAgICAgICByZWNlaXZlciB3aWxsIGNv
bXB1dGUgSydfdyA9IEYnKEtfdykgZnJvbSB3aGljaCBpdCBjYW4gY29tcHV0ZQogICAgICAg
TUFDKCBLJ193LCBNX2gpLiAgSWYgdGhpcyBNQUMgZG9lcyBub3QgZXF1YWwgdGhlIE1BQyBz
dG9yZWQgaW4KICAgICAgIHRoZSBwYWNrZXQsIHRoZSByZWNlaXZlciBNVVNUIGRpc2NhcmQg
dGhlIHBhY2tldC4gIElmIHRoZSB0d28gTUFDCiAgICAgICBhcmUgZXF1YWwsIHRoZSBwYWNr
ZXQgaXMgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0ZWQgYW5kIHRoZQogICAgICAgcmVjZWl2
ZXIgY29udGludWVzIHByb2Nlc3NpbmcgaXQuCgogICA4LiAgQXV0aGVudGljYXRlZCBuZXcg
a2V5IGNoYWluIGNvbW1pdG1lbnQgcHJvY2Vzc2luZzogSWYgdGhlCiAgICAgICBhdXRoZW50
aWNhdGVkIHBhY2tldCBjb250YWlucyBhIG5ldyBrZXkgY2hhaW4gY29tbWl0bWVudCBhbmQg
aWYKICAgICAgIG5vIHZlcmlmaWVkIGNvbW1pdG1lbnQgYWxyZWFkeSBleGlzdHMsIHRoZW4g
dGhlIHJlY2VpdmVyIHN0b3JlcwogICAgICAgdGhlIGNvbW1pdG1lbnQgdG8gdGhlIG5ldyBr
ZXkgY2hhaW4uICBUaGVuLCBpZiB0aGVyZSBhcmUgbm9uCiAgICAgICBhdXRoZW50aWNhdGVk
IHBhY2tldHMgZm9yIGEgcHJldmlvdXMgY2hhaW4gKGkuZS4sIHRoZSBrZXkgY2hhaW4KICAg
ICAgIGJlZm9yZSB0aGUgY3VycmVudCBvbmUpLCBhbGwgdGhlc2UgcGFja2V0cyBjYW4gYmUg
ZGlzY2FyZGVkCiAgICAgICAoU2VjdGlvbiA0LjQpLgoKICAgOS4gIFRoZSByZWNlaXZlciBj
b250aW51ZXMgdGhlIEFMQyBvciBOT1JNIHByb2Nlc3Npbmcgb2YgYWxsIHRoZQogICAgICAg
cGFja2V0cyBhdXRoZW50aWNhdGVkIGR1cmluZyB0aGUgYXV0aGVudGljYXRpb24gdGVzdC4K
CiAgIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgYSByZWNlaXZlciB1c2luZyBURVNMQSBNVVNU
IGltbWVkaWF0ZWx5IGRyb3AKICAgdW5zYWZlIHBhY2tldHMuICBCdXQgdGhlIHJlY2VpdmVy
IE1BWSBhbHNvIGRlY2lkZSwgYXQgYW55IHRpbWUsIHRvCiAgIGNvbnRpbnVlIGFuIEFMQyBv
ciBOT1JNIHNlc3Npb24gaW4gdW5zYWZlIChpbnNlY3VyZSkgbW9kZSwgaWdub3JpbmcKICAg
VEVTTEEgZXh0ZW5zaW9ucy4gIFRoZXJlIFNIT1VMRCBiZSBhbiBleHBsaWNpdCB1c2VyIGFj
dGlvbiB0byB0aGF0CiAgIHB1cnBvc2UuCgo0LjMuMS4gIERpc2NhcmRpbmcgVW5uZWNlc3Nh
cnkgUGFja2V0cyBFYXJsaWVyCgogICBGb2xsb3dpbmcgc3RyaWN0bHkgdGhlIGFib3ZlIHN0
ZXBzIGNhbiBsZWFkIHRvIGV4Y2Vzc2l2ZSBwcm9jZXNzaW5nCiAgIG92ZXJoZWFkIGluIGNl
cnRhaW4gc2l0dWF0aW9ucy4gIFRoaXMgaXMgdGhlIGNhc2Ugd2hlbiBhIHJlY2VpdmVyCiAg
IHJlY2VpdmVzIHBhY2tldHMgZm9yIGFuIHVud2FudGVkIG9iamVjdCB3aXRoIHRoZSBBTEMg
b3IgTk9STQogICBwcm90b2NvbHMsIGkuZS4sIGFuIG9iamVjdCBmb3Igd2hpY2ggdGhlIGFw
cGxpY2F0aW9uIChvciB0aGUgZW5kCiAgIHVzZXIpIGV4cGxpY2l0bHkgbWVudGlvbmVkIGl0
IGlzIG5vdCBpbnRlcmVzdGVkIGluLiAgVGhpcyBpcyBhbHNvIHRoZQogICBjYXNlIHdoZW4g
YSByZWNlaXZlciByZWNlaXZlcyBwYWNrZXRzIGZvciBhbiBhbHJlYWR5IGRlY29kZWQgb2Jq
ZWN0LAogICBvciB3aGVuIHRoaXMgb2JqZWN0IGhhcyBiZWVuIHBhcnRpdGlvbmVkIGluIHNl
dmVyYWwgYmxvY2tzLCBmb3IgYW4KICAgYWxyZWFkeSBkZWNvZGVkIGJsb2NrLiAgV2hlbiBz
dWNoIGEgcGFja2V0IGlzIHJlY2VpdmVkLCB3aGljaCBpcwogICBlYXNpbHkgaWRlbnRpZmll
ZCBieSBsb29raW5nIGF0IHRoZSByZWNlaXZlcidzIHN0YXR1cyBmb3IgdGhlCiAgIGluY29t
aW5nIEFMQyBvciBOT1JNIHBhY2tldCwgdGhlIHJlY2VpdmVyIE1VU1QgYWxzbyBjaGVjayB0
aGF0IHRoZQogICBwYWNrZXQgaXMgYSBwdXJlIGRhdGEgcGFja2V0IHRoYXQgZG9lcyBub3Qg
Y29udGFpbiBhbnkgc2lnbmFsaW5nCiAgIGluZm9ybWF0aW9uIG9mIGltcG9ydGFuY2UgZm9y
IHRoZSBzZXNzaW9uLgoKICAgV2l0aCBBTEMsIGEgcGFja2V0IGNvbnRhaW5pbmcgYSAiQSIg
ZmxhZyAoIkNsb3NlIFNlc3Npb24iKSBvciBhICJCIgogICBmbGFnICgiQ2xvc2UgT2JqZWN0
IikgTVVTVCBOT1QgYmUgZGlzY2FyZGVkIGJlZm9yZSBoYXZpbmcgYmVlbgogICBhdXRoZW50
aWNhdGVkIGFuZCBwcm9jZXNzZWQgbm9ybWFsbHkuICBPdGhlcndpc2UsIHRoZSByZWNlaXZl
ciBjYW4KICAgc2FmZWx5IGRpc2NhcmQgdGhlIGluY29taW5nIHBhY2tldCBmb3IgaW5zdGFu
Y2UganVzdCBhZnRlciBzdGVwIDEgb2YKICAgU2VjdGlvbiA0LjMuICBUaGlzIG9wdGltaXph
dGlvbiBjYW4gZHJhbWF0aWNhbGx5IHJlZHVjZSB0aGUKCgoKUm9jYSwgZXQgYWwuICAgICAg
ICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNDRd
CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAg
ICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgcHJvY2Vzc2luZyBvdmVyaGVhZCwgYnkgYXZv
aWRpbmcgbWFueSB1c2VsZXNzIGF1dGhlbnRpY2F0aW9uIGNoZWNrcy4KCjQuNC4gIEZsdXNo
aW5nIHRoZSBOb24gQXV0aGVudGljYXRlZCBQYWNrZXRzIG9mIGEgUHJldmlvdXMgS2V5IENo
YWluCgogICBJbiBzb21lIGNhc2VzIGEgcmVjZWl2ZXIgaGF2aW5nIGV4cGVyaWVuY2VkIGEg
dmVyeSBsb25nIGRpc2Nvbm5lY3Rpb24KICAgbWlnaHQgaGF2ZSBsb3N0IGFsbCB0aGUgZGlz
Y2xvc3VyZXMgb2YgdGhlIGxhc3Qga2V5KHMpIG9mIGEgcHJldmlvdXMKICAga2V5IGNoYWlu
LiAgTGV0IGogYmUgdGhlIGluZGV4IG9mIHRoaXMga2V5IGNoYWluIGZvciB3aGljaCB0aGVy
ZQogICByZW1haW5zIG5vbiBhdXRoZW50aWNhdGVkIHBhY2tldHMuICBUaGlzIHJlY2VpdmVy
IGNhbiBmbHVzaCBhbGwgdGhlCiAgIHBhY2tldHMgb2YgdGhlIGtleSBjaGFpbiBqIGlmIGhl
IGRldGVybWluZXMgdGhhdDoKCiAgIG8gIGhlIGhhcyBqdXN0IHN3aXRjaGVkIHRvIGEgY2hh
aW4gb2YgaW5kZXggaisyIChpbmNsdXNpdmUpIG9yCiAgICAgIGhpZ2hlcjsKCiAgIG8gIHRo
ZSBzZW5kZXIgaGFzIHNlbnQgYSBjb21taXRtZW50IHRvIHRoZSBuZXcga2V5IGNoYWluIG9m
IGluZGV4IGorMgogICAgICAoU2VjdGlvbiAzLjEuMi4zKS4gIFRoaXMgc2l0dWF0aW9uIHJl
cXVpcmVzIHRoYXQgdGhlIHJlY2VpdmVyIGhhcwogICAgICByZWNlaXZlZCBhIHBhY2tldCBj
b250YWluaW5nIHN1Y2ggYSBjb21taXRtZW50IGFuZCB0aGF0IGhlIGhhcwogICAgICBiZWVu
IGFibGUgdG8gY2hlY2sgaXRzIGludGVncml0eS4gIEluIHNvbWUgY2FzZXMgaXQgbWlnaHQg
cmVxdWlyZQogICAgICB0byByZWNlaXZlIGEgYm9vdHN0cmFwIGluZm9ybWF0aW9uIG1lc3Nh
Z2UgZm9yIHRoZSBjdXJyZW50IGtleQogICAgICBjaGFpbi4KCiAgIElmIG9uZSBvZiB0aGUg
YWJvdmUgdHdvIHRlc3RzIHN1Y2NlZWRzLCB0aGUgc2VuZGVyIGNhbiBkaXNjYXJkIGFsbAog
ICB0aGUgYXdhaXRpbmcgcGFja2V0cyBzaW5jZSB0aGVyZSBpcyBubyB3YXkgdG8gYXV0aGVu
dGljYXRlIHRoZW0uCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUm9jYSwgZXQgYWwu
ICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1Bh
Z2UgNDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5P
Uk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoKNS4gIEludGVncmF0aW9uIGluIHRoZSBB
TEMgYW5kIE5PUk0gUHJvdG9jb2xzCgo1LjEuICBBdXRoZW50aWNhdGlvbiBIZWFkZXIgRXh0
ZW5zaW9uIEZvcm1hdAoKICAgVGhlIGludGVncmF0aW9uIG9mIFRFU0xBIGluIEFMQyBvciBO
T1JNIGlzIHNpbWlsYXIgYW5kIHJlbGllcyBvbiB0aGUKICAgaGVhZGVyIGV4dGVuc2lvbiBt
ZWNoYW5pc20gZGVmaW5lZCBpbiBib3RoIHByb3RvY29scy4gIE1vcmUgcHJlY2lzZWx5CiAg
IHRoaXMgZG9jdW1lbnQgZGV0YWlscyB0aGUgRVhUX0FVVEg9PTEgaGVhZGVyIGV4dGVuc2lv
biBkZWZpbmVkIGluCiAgIFtSTVQtQkItTENUXS4KCiAgIFNldmVyYWwgZmllbGRzIGFyZSBh
ZGRlZCBpbiBhZGRpdGlvbiB0byB0aGUgSEVUIChIZWFkZXIgRXh0ZW5zaW9uCiAgIFR5cGUp
IGFuZCBIRUwgKEhlYWRlciBFeHRlbnNpb24gTGVuZ3RoKSBmaWVsZHMgKEZpZ3VyZSA5KS4K
CgogICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAg
ICAgICAgICAgICAgIDMKICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg
NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAg
SEVUICg9MSkgICAgfCAgICAgIEhFTCAgICAgIHwgIEFTSUQgfCAgVHlwZSB8ICAgICAgICAg
ICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKyAgICAgICAgICAgICAgICsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB+ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fgogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICBDb250ZW50ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwKICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+CiAgICB8ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSsKCiAgICAgICAgIEZpZ3VyZSA5OiBGb3JtYXQgb2YgdGhlIFRFU0xBIEVY
VF9BVVRIIGhlYWRlciBleHRlbnNpb24uCgogICBUaGUgZmllbGRzIG9mIHRoZSBURVNMQSBF
WFRfQVVUSCBoZWFkZXIgZXh0ZW5zaW9uIGFyZToKCiAgICJBU0lEIiAoQXV0aGVudGljYXRp
b24gU2NoZW1lIElEZW50aWZpZXIpIGZpZWxkICg0IGJpdHMpOgoKICAgICAgVGhlICJBU0lE
IiBpZGVudGlmaWVzIHRoZSBzb3VyY2UgYXV0aGVudGljYXRpb24gc2NoZW1lIG9yIHByb3Rv
Y29sCiAgICAgIGluIHVzZS4gIFRoZSBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSAiQVNJRCIg
dmFsdWUgYW5kIHRoZSBhY3R1YWwKICAgICAgYXV0aGVudGljYXRpb24gc2NoZW1lIGlzIGRl
ZmluZWQgb3V0LW9mLWJhbmQsIGF0IHNlc3Npb24gc3RhcnR1cC4KCiAgICJUeXBlIiBmaWVs
ZCAoNCBiaXRzKToKCiAgICAgIFRoZSAiVHlwZSIgZmllbGQgaWRlbnRpZmllcyB0aGUgdHlw
ZSBvZiBURVNMQSBpbmZvcm1hdGlvbiBjYXJyaWVkCiAgICAgIGluIHRoaXMgaGVhZGVyIGV4
dGVuc2lvbi4gIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIHRoZQogICAgICBmb2xsb3dp
bmcgdHlwZXM6CgogICAgICAqICAwOiBCb290c3RyYXAgSW5mb3JtYXRpb24sIHNlbnQgYnkg
dGhlIHNlbmRlciBwZXJpb2RpY2FsbHkgb3IKICAgICAgICAgYWZ0ZXIgYSBkaXJlY3QgdGlt
ZSBzeW5jaHJvbml6YXRpb24gcmVxdWVzdDsKCiAgICAgICogIDE6IFN0YW5kYXJkIEF1dGhl
bnRpY2F0aW9uIFRhZyBmb3IgdGhlIG9uLWdvaW5nIGtleSBjaGFpbiwgc2VudAogICAgICAg
ICBieSB0aGUgc2VuZGVyIGFsb25nIHdpdGggYSBwYWNrZXQ7CgoKCgoKUm9jYSwgZXQgYWwu
ICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1Bh
Z2UgNDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5P
Uk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgICAgKiAgMjogQXV0aGVudGljYXRp
b24gVGFnIFdpdGhvdXQgS2V5IERpc2Nsb3N1cmUsIHNlbnQgYnkgdGhlCiAgICAgICAgIHNl
bmRlciBhbG9uZyB3aXRoIGEgcGFja2V0OwoKICAgICAgKiAgMzogQXV0aGVudGljYXRpb24g
VGFnIHdpdGggYSBOZXcgS2V5IENoYWluIENvbW1pdG1lbnQsIHNlbnQgYnkKICAgICAgICAg
dGhlIHNlbmRlciB3aGVuIGFwcHJvYWNoaW5nIHRoZSBlbmQgb2YgYSBrZXkgY2hhaW47Cgog
ICAgICAqICA0OiBBdXRoZW50aWNhdGlvbiBUYWcgd2l0aCBhIExhc3QgS2V5IG9mIE9sZCBD
aGFpbiBEaXNjbG9zdXJlLAogICAgICAgICBzZW50IGJ5IHRoZSBzZW5kZXIgc29tZSB0aW1l
IGFmdGVyIG1vdmluZyB0byBhIG5ldyBrZXkgY2hhaW47CgogICAgICAqICA1OiBEaXJlY3Qg
VGltZSBTeW5jaHJvbml6YXRpb24gUmVxdWVzdCwgc2VudCBieSBhIE5PUk0KICAgICAgICAg
cmVjZWl2ZXIuICBUaGlzIHR5cGUgb2YgbWVzc2FnZSBpcyBpbnZhbGlkIGluIGNhc2Ugb2Yg
YW4gQUxDCiAgICAgICAgIHNlc3Npb24gc2luY2UgQUxDIGlzIHJlc3RyaWN0ZWQgdG8gdW5p
ZGlyZWN0aW9uYWwKICAgICAgICAgdHJhbnNtaXNzaW9ucy4gIFlldCBhbiBleHRlcm5hbCBt
ZWNoYW5pc20gbWF5IHByb3ZpZGUgdGhlCiAgICAgICAgIGRpcmVjdCB0aW1lIHN5bmNocm9u
aXphdGlvbiBmdW5jdGlvbmFsaXR5OwoKICAgICAgKiAgNjogRGlyZWN0IFRpbWUgU3luY2hy
b25pemF0aW9uIFJlc3BvbnNlLCBzZW50IGJ5IGEgTk9STSBzZW5kZXIuCiAgICAgICAgIFRo
aXMgdHlwZSBvZiBtZXNzYWdlIGlzIGludmFsaWQgaW4gY2FzZSBvZiBhbiBBTEMgc2Vzc2lv
biBzaW5jZQogICAgICAgICBBTEMgaXMgcmVzdHJpY3RlZCB0byB1bmlkaXJlY3Rpb25hbCB0
cmFuc21pc3Npb25zLiAgWWV0IGFuCiAgICAgICAgIGV4dGVybmFsIG1lY2hhbmlzbSBtYXkg
cHJvdmlkZSB0aGUgZGlyZWN0IHRpbWUgc3luY2hyb25pemF0aW9uCiAgICAgICAgIGZ1bmN0
aW9uYWxpdHk7CgogICAiQ29udGVudCIgZmllbGQgKHZhcmlhYmxlIGxlbmd0aCk6CgogICAg
ICBUaGlzIGlzIHRoZSBURVNMQSBpbmZvcm1hdGlvbiBjYXJyaWVkIGluIHRoZSBoZWFkZXIg
ZXh0ZW5zaW9uLAogICAgICB3aG9zZSB0eXBlIGlzIGdpdmVuIGJ5IHRoZSAiVHlwZSIgZmll
bGQuCgo1LjIuICBVc2Ugb2YgQXV0aGVudGljYXRpb24gSGVhZGVyIEV4dGVuc2lvbnMKCiAg
IEVhY2ggcGFja2V0IHNlbnQgYnkgdGhlIHNlc3Npb24ncyBzZW5kZXIgTVVTVCBjb250YWlu
IGV4YWN0bHkgb25lCiAgIFRFU0xBIEVYVF9BVVRIIGhlYWRlciBleHRlbnNpb24uCgogICBB
bGwgcmVjZWl2ZXJzIE1VU1QgcmVjb2duaXplIEVYVF9BVVRIIGJ1dCBNQVkgbm90IGJlIGFi
bGUgdG8gcGFyc2UKICAgaXRzIGNvbnRlbnQsIGZvciBpbnN0YW5jZSBiZWNhdXNlIHRoZXkg
ZG8gbm90IHN1cHBvcnQgVEVTTEEuICBJbiB0aGF0CiAgIGNhc2UgdGhlc2UgcmVjZWl2ZXJz
IE1VU1QgaWdub3JlIHRoZSBURVNMQSBFWFRfQVVUSCBleHRlbnNpb25zLiAgSW4KICAgY2Fz
ZSBvZiBOT1JNLCB0aGUgcGFja2V0cyBzZW50IGJ5IHJlY2VpdmVycyBNQVkgY29udGFpbiBh
IGRpcmVjdAogICBzeW5jaHJvbml6YXRpb24gcmVxdWVzdCBidXQgTVVTVCBOT1QgY29udGFp
biBhbnkgb2YgdGhlIG90aGVyIGZpdmUKICAgVEVTTEEgRVhUX0FVVEggaGVhZGVyIGV4dGVu
c2lvbnMuCgo1LjIuMS4gIEVYVF9BVVRIIEhlYWRlciBFeHRlbnNpb24gb2YgVHlwZSBCb290
c3RyYXAgSW5mb3JtYXRpb24KCiAgIFRoZSAiYm9vdHN0cmFwIGluZm9ybWF0aW9uIiBURVNM
QSBFWFRfQVVUSCAoVHlwZT09MCkgTVVTVCBiZSBzZW50IGluCiAgIGEgc3RhbmQtYWxvbmUg
Y29udHJvbCBwYWNrZXQsIHJhdGhlciB0aGFuIGluIGEgcGFja2V0IGNvbnRhaW5pbmcKICAg
YXBwbGljYXRpb24gZGF0YS4gIFRoZSByZWFzb24gZm9yIHRoYXQgaXMgdGhlIGxhcmdlIHNp
emUgb2YgdGhpcwogICBib290c3RyYXAgaW5mb3JtYXRpb24uICBCeSB1c2luZyBzdGFuZC1h
bG9uZSBwYWNrZXRzLCB0aGUgbWF4aW11bQogICBwYXlsb2FkIHNpemUgb2YgZGF0YSBwYWNr
ZXRzIGlzIG9ubHkgYWZmZWN0ZWQgYnkgdGhlIChtYW5kYXRvcnkpCiAgIGF1dGhlbnRpY2F0
aW9uIGluZm9ybWF0aW9uIGhlYWRlciBleHRlbnNpb24uCgogICBXaXRoIEFMQywgdGhlICJi
b290c3RyYXAgaW5mb3JtYXRpb24iIFRFU0xBIEVYVF9BVVRIIE1VU1QgYmUgc2VudCBpbgoK
CgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAg
ICAgICAgICAgICBbUGFnZSA0N10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xB
IGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgogICBhIGNvbnRy
b2wgcGFja2V0LCBpLmUuLCBjb250YWluaW5nIG5vIGVuY29kaW5nIHN5bWJvbC4KCiAgIFdp
dGggTk9STSwgdGhlICJib290c3RyYXAgaW5mb3JtYXRpb24iIFRFU0xBIEVYVF9BVVRIIE1V
U1QgYmUgc2VudCBpbgogICBhIE5PUk1fQ01EKEFQUExJQ0FUSU9OKSBtZXNzYWdlLgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClJvY2EsIGV0IGFs
LiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwLCAyMDEwICAgICAgICAgICAgICAgIFtQ
YWdlIDQ4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVEVTTEEgaW4gQUxDIGFuZCBO
T1JNICAgICAgICAgICBTZXB0ZW1iZXIgMjAwOQoKCiAgIDAgICAgICAgICAgICAgICAgICAg
MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgMCAxIDIgMyA0
IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx
CiAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSsgIC0tLQogIHwgICBIRVQgKD0xKSAgICB8ICAgIEhFTCAoPTQ2KSAg
fCAgQVNJRCB8ICAgMCAgIHwgMCB8ICAwICB8MHwxfDB8ICBeCiAgKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIHwK
ICB8ICAgICAgIGQgICAgICAgfCAgICAgICAyICAgICAgIHwgICAgICAgMiAgICAgICB8ICAg
ICAgIDIgICAgICAgfCAgfAogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICB8CiAgfCAgICAgICAxICAgICAgIHwg
ICAgICAgMyAgICAgICB8ICAgICAgICAgICAgICAxMjggICAgICAgICAgICAgIHwgIHwKICAr
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKyAgfAogIHwgICAgICAgICAwIChyZXNlcnZlZCkgICAgICAgICAgfCAgICAg
ICAgICAgICBUX2ludCAgICAgICAgICAgICB8ICB8CiAgKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIHwKICB8ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgfAogICsgICAgICAgICAgICAgICAgICBUXzAgKE5UUCB0aW1lc3RhbXAgZm9y
bWF0KSAgICAgICAgICAgICAgICAgICArICB8IDUKICB8ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgfCAyCiAgKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSsgIHwKICB8ICAgICAgICAgICAgICAgICAgICAgIE4gKEtleSBDaGFpbiBMZW5n
dGgpICAgICAgICAgICAgICAgICAgICAgfCAgfCBiCiAgKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIHwgeQogIHwg
ICAgICAgICAgICAgICAgICAgIEN1cnJlbnQgSW50ZXJ2YWwgSW5kZXggaSAgICAgICAgICAg
ICAgICAgICB8ICB8IHQKICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgfCBlCiAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHwgcwog
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICArICB8CiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHwKICArICAgICAgICAgICAgICAgICBD
dXJyZW50IEtleSBDaGFpbiBDb21taXRtZW50ICAgICAgICAgICAgICAgICAgKyAgfAogIHwg
ICAgICAgICAgICAgICAgICAgICAgICAgICgyMCBieXRlcykgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8ICB8CiAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICsgIHwKICB8ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgfAogICsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICArICB8CiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwgIHYKICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgLS0tCiAgfCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwgIF4gMQogICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICArICB8IDIKICB8ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgfCA4CiAgLiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIC4gIHwKICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgU2lnbmF0dXJlICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLiAgfCBiCiAgLiAgICAgICAgICAgICAgICAgICAg
ICAgICAgKDEyOCBieXRlcykgICAgICAgICAgICAgICAgICAgICAgICAgIC4gIHwgeQogIHwg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8ICB8IHQKICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKyAgfCBlCiAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHYgcwog
ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rICAtLS0KICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JvdXAg
TUFDICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICBGaWd1
cmUgMTA6IEV4YW1wbGU6IEZvcm1hdCBvZiB0aGUgYm9vdHN0cmFwIGluZm9ybWF0aW9uIG1l
c3NhZ2UgKFR5cGUKICAgMCksIHVzaW5nIFNIQS0yNTYvMTAyNCBiaXQgc2lnbmF0dXJlcywg
dGhlIGRlZmF1bHQgSE1BQy1TSEEtMjU2IGFuZCBhCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgR3JvdXAgTUFDLgoKICAgRm9yIGluc3RhbmNlIEZpZ3VyZSAxMCBzaG93cyB0
aGUgYm9vdHN0cmFwIGluZm9ybWF0aW9uIG1lc3NhZ2Ugd2hlbgogICB1c2luZyB0aGUgSE1B
Qy1TSEEtMjU2IHRyYW5zZm9ybSBmb3IgdGhlIFBSRiwgTUFDLCBhbmQgR3JvdXAgTUFDCgoK
ClJvY2EsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwLCAyMDEwICAgICAg
ICAgICAgICAgIFtQYWdlIDQ5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVEVTTEEg
aW4gQUxDIGFuZCBOT1JNICAgICAgICAgICBTZXB0ZW1iZXIgMjAwOQoKCiAgIGZ1bmN0aW9u
cywgYWxvbmcgd2l0aCBTSEEtMjU2LzEyOCBieXRlICgxMDI0IGJpdCkga2V5IGRpZ2l0YWwK
ICAgc2lnbmF0dXJlcyAod2hpY2ggYWxzbyBtZWFucyB0aGF0IHRoZSBzaWduYXR1cmUgZmll
bGQgaXMgMTI4IGJ5dGUKICAgbG9uZykuICBUaGUgVEVTTEEgRVhUX0FVVEggaGVhZGVyIGV4
dGVuc2lvbiBpcyB0aGVuIDE4NCBieXRlIGxvbmcKICAgKGkuZS4sIDQ2IHdvcmRzIG9mIDMy
IGJpdHMpLgoKNS4yLjIuICBFWFRfQVVUSCBIZWFkZXIgRXh0ZW5zaW9uIG9mIFR5cGUgQXV0
aGVudGljYXRpb24gVGFnCgogICBUaGUgZm91ciAiYXV0aGVudGljYXRpb24gdGFnIiBURVNM
QSBFWFRfQVVUSCAoVHlwZSAxLCAyLCAzLCBhbmQgNCkKICAgTVVTVCBiZSBhdHRhY2hlZCB0
byB0aGUgQUxDIG9yIE5PUk0gcGFja2V0IChkYXRhIG9yIGNvbnRyb2wgcGFja2V0KQogICB0
aGF0IHRoZXkgcHJvdGVjdC4KCgogICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg
ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgICAwIDEgMiAzIDQgNSA2IDcg
OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rCiAgICB8ICAgSEVUICg9MSkgICAgfCAgIEhFTCAoPTEwKSAgIHwgIEFTSUQg
fCAgIDEgICB8ICAgUmVzZXJ2ZWQgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAg
ICAgICAgICAgaSAoSW50ZXJ2YWwgSW5kZXggb2YgSydfaSkgICAgICAgICAgICAgICAgICAg
ICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArCiAg
ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfAogICAgKyAgICAgICAgICAgICAgICAgICAgIERpc2Nsb3NlZCBLZXkg
S197aS1kfSAgICAgICAgICAgICAgICAgICAgICsKICAgIHwgICAgICAgICAgICAgICAgICAg
ICAgICAgICgyMCBieXRlcykgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICB8ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKwogICAg
fCAgICAgICAgICAgICAgICAgICAgICAgICBNQUMoSydfaSwgTSkgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwKICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICgxNiBieXRlcykg
ICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICB8ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgIEZpZ3VyZSAxMTog
RXhhbXBsZTogRm9ybWF0IG9mIHRoZSBTdGFuZGFyZCBBdXRoZW50aWNhdGlvbiBUYWcgKFR5
cGUKICAgICAgICAgICAgICAgICAgICAxKSwgdXNpbmcgdGhlIGRlZmF1bHQgSE1BQy1TSEEt
MjU2LgoKCgoKCgoKCgoKClJvY2EsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1hcmNo
IDIwLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDUwXQoMCkludGVybmV0LURyYWZ0ICAg
ICAgICAgICAgVEVTTEEgaW4gQUxDIGFuZCBOT1JNICAgICAgICAgICBTZXB0ZW1iZXIgMjAw
OQoKCiAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg
ICAgICAgICAgICAgICAgMwogICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg
NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwg
ICBIRVQgKD0xKSAgICB8ICAgSEVMICg9NSkgICAgfCAgQVNJRCB8ICAgMiAgIHwgICBSZXNl
cnZlZCAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICBpIChJbnRl
cnZhbCBJbmRleCBvZiBLJ19pKSAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfAogICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAgIHwgICAgICAgICAgICAg
ICAgICAgICAgICAgTUFDKEsnX2ksIE0pICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg
ICArICAgICAgICAgICAgICAgICAgICAgICAgICAoMTYgYnl0ZXMpICAgICAgICAgICAgICAg
ICAgICAgICAgICAgKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICB8ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgRmlndXJlIDEyOiBFeGFtcGxlOiBGb3Jt
YXQgb2YgdGhlIEF1dGhlbnRpY2F0aW9uIFRhZyBXaXRob3V0IEtleQogICAgICAgICAgIERp
c2Nsb3N1cmUgKFR5cGUgMiksIHVzaW5nIHRoZSBkZWZhdWx0IEhNQUMtU0hBLTI1Ni4KCiAg
IEZvciBpbnN0YW5jZSwgRmlndXJlIDExIGFuZCBGaWd1cmUgMTIgc2hvdyB0aGUgZm9ybWF0
IG9mIHRoZQogICBhdXRoZW50aWNhdGlvbiB0YWdzLCByZXNwZWN0aXZlbHkgd2l0aCBhbmQg
d2l0aG91dCB0aGUgS197aS1kfSBrZXkKICAgZGlzY2xvc3VyZSwgd2hlbiB1c2luZyB0aGUg
KGRlZmF1bHQpIEhNQUMtU0hBLTI1NiB0cmFuc2Zvcm0gZm9yIHRoZQogICBQUkYgYW5kIE1B
QyBmdW5jdGlvbnMuICBJbiB0aGlzIGV4YW1wbGUsIHRoZSBHcm91cCBNQUMgZmVhdHVyZSBp
cyBub3QKICAgdXNlZC4KCjUuMi4zLiAgRVhUX0FVVEggSGVhZGVyIEV4dGVuc2lvbiBvZiBU
eXBlIERpcmVjdCBUaW1lIFN5bmNocm9uaXphdGlvbgogICAgICAgIFJlcXVlc3QKCiAgIFdp
dGggTk9STSwgdGhlICJkaXJlY3QgdGltZSBzeW5jaHJvbml6YXRpb24gcmVxdWVzdCIgVEVT
TEEgRVhUX0FVVEgKICAgKFR5cGU9PTcpIE1VU1QgYmUgc2VudCBieSBhIHJlY2VpdmVyIGlu
IGEgTk9STV9DTUQoQVBQTElDQVRJT04pIE5PUk0KICAgcGFja2V0LgoKICAgV2l0aCBBTEMs
IHRoZSAiZGlyZWN0IHRpbWUgc3luY2hyb25pemF0aW9uIHJlcXVlc3QiIFRFU0xBIEVYVF9B
VVRICiAgIGNhbm5vdCBiZSBpbmNsdWRlZCBpbiBhbiBBTEMgcGFja2V0LCBzaW5jZSBBTEMg
aXMgcmVzdHJpY3RlZCB0bwogICB1bmlkaXJlY3Rpb25hbCB0cmFuc21pc3Npb25zLCBmcm9t
IHRoZSBzZXNzaW9uJ3Mgc2VuZGVyIHRvIHRoZQogICByZWNlaXZlcnMuICBBbiBleHRlcm5h
bCBtZWNoYW5pc20gbXVzdCBiZSB1c2VkIHdpdGggQUxDIGZvciBjYXJyeWluZwogICBkaXJl
Y3QgdGltZSBzeW5jaHJvbml6YXRpb24gcmVxdWVzdHMgdG8gdGhlIHNlc3Npb24ncyBzZW5k
ZXIuCgogICBJbiBjYXNlIG9mIGRpcmVjdCB0aW1lIHN5bmNocm9uaXphdGlvbiwgaXQgaXMg
UkVDT01NRU5ERUQgdGhhdCB0aGUKICAgcmVjZWl2ZXJzIHNwcmVhZCB0aGUgdHJhbnNtaXNz
aW9uIG9mIGRpcmVjdCB0aW1lIHN5bmNocm9uaXphdGlvbgogICByZXF1ZXN0cyBvdmVyIHRo
ZSB0aW1lIChTZWN0aW9uIDIuMy4xKS4KCjUuMi40LiAgRVhUX0FVVEggSGVhZGVyIEV4dGVu
c2lvbiBvZiBUeXBlIERpcmVjdCBUaW1lIFN5bmNocm9uaXphdGlvbgogICAgICAgIFJlc3Bv
bnNlCgogICBXaXRoIE5PUk0sIHRoZSAiZGlyZWN0IHRpbWUgc3luY2hyb25pemF0aW9uIHJl
c3BvbnNlIiBURVNMQSBFWFRfQVVUSAogICAoVHlwZT09OCkgTVVTVCBiZSBzZW50IGJ5IHRo
ZSBzZW5kZXIgaW4gYSBOT1JNX0NNRChBUFBMSUNBVElPTikKICAgbWVzc2FnZS4KCgoKUm9j
YSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAg
ICAgICAgW1BhZ2UgNTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBB
TEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgV2l0aCBBTEMsIHRo
ZSAiZGlyZWN0IHRpbWUgc3luY2hyb25pemF0aW9uIHJlc3BvbnNlIiBURVNMQSBFWFRfQVVU
SAogICBjYW4gYmUgc2VudCBpbiBhbiBBTEMgY29udHJvbCBwYWNrZXQgKGkuZS4sIGNvbnRh
aW5pbmcgbm8gZW5jb2RpbmcKICAgc3ltYm9sKSBvciB0aHJvdWdoIHRoZSBleHRlcm5hbCBt
ZWNoYW5pc20gdXNlIHRvIGNhcnJ5IHRoZSBkaXJlY3QKICAgdGltZSBzeW5jaHJvbml6YXRp
b24gcmVxdWVzdC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAg
ICAgICAgICAgICAgICBbUGFnZSA1Ml0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRF
U0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgo2LiAgU2Vj
dXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFtSRkM0MDgyXSBkaXNjdXNzZXMgdGhlIHNlY3Vy
aXR5IG9mIFRFU0xBIGluIGdlbmVyYWwuICBUaGVzZQogICBjb25zaWRlcmF0aW9ucyBhcHBs
eSB0byB0aGUgcHJlc2VudCBzcGVjaWZpY2F0aW9uLCBuYW1lbHk6CgogICBvICBncmVhdCBj
YXJlIG11c3QgYmUgdGFrZW4gdG8gdGhlIHRpbWluZyBhc3BlY3RzLiAgSW4gcGFydGljdWxh
ciB0aGUKICAgICAgRF90IHBhcmFtZXRlciBpcyBjcml0aWNhbCBhbmQgbXVzdCBiZSBjb3Jy
ZWN0bHkgaW5pdGlhbGl6ZWQ7CgogICBvICBpZiB0aGUgc2VuZGVyIHJlYWxpemVzIHRoYXQg
dGhlIGtleSBkaXNjbG9zdXJlIHNjaGVkdWxlIGlzIG5vdAogICAgICBhcHByb3ByaWF0ZSwg
dGhlbiB0aGUgY3VycmVudCBzZXNzaW9uIE1VU1QgYmUgY2xvc2VkIGFuZCBhIG5ldyBvbmUK
ICAgICAgY3JlYXRlZC4gIEluZGVlZCBTZWN0aW9uIDMuMS4zIHJlcXVpcmVzIHRoYXQgdGhl
c2UgcGFyYW1ldGVycyBiZQogICAgICBmaXhlZCBkdXJpbmcgdGhlIHdob2xlIHNlc3Npb24u
CgogICBvICB3aGVuIHRoZSB2ZXJpZmllciB0aGF0IGF1dGhlbnRpY2F0ZXMgdGhlIGluY29t
aW5nIHBhY2tldHMgYW5kIHRoZQogICAgICBhcHBsaWNhdGlvbiB0aGF0IHVzZXMgdGhlIGRh
dGEgYXJlIHR3byBkaWZmZXJlbnQgY29tcG9uZW50cywgdGhlcmUKICAgICAgaXMgYSByaXNr
IHRoYXQgYW4gYXR0YWNrZXIgbG9jYXRlZCBiZXR3ZWVuIHRoZXNlIGNvbXBvbmVudHMgaW5q
ZWN0CiAgICAgIGZha2VkIGRhdGEuICBTaW1pbGFybHksIHdoZW4gdGhlIHZlcmlmaWVyIGFu
ZCB0aGUgc2VjdXJlIHRpbWluZwogICAgICBzeXN0ZW0gYXJlIHR3byBkaWZmZXJlbnQgY29t
cG9uZW50cywgdGhlcmUgaXMgYSByaXNrIHRoYXQgYW4KICAgICAgYXR0YWNrZXIgbG9jYXRl
ZCBiZXR3ZWVuIHRoZXNlIGNvbXBvbmVudHMgaW5qZWN0IGZha2VkIHRpbWluZwogICAgICBp
bmZvcm1hdGlvbi4gIEZvciBpbnN0YW5jZSwgd2hlbiB0aGUgdmVyaWZpZXIgcmVhZHMgdGhl
IGxvY2FsIHRpbWUKICAgICAgYnkgbWVhbnMgb2YgYSBkZWRpY2F0ZWQgc3lzdGVtIGNhbGwg
KGUuZy4sIGdldHRpbWVvZmRheSgpKSwgaWYgYW4KICAgICAgYXR0YWNrZXIgY29udHJvbHMg
dGhlIGhvc3QsIGhlIG1heSBjYXRjaCB0aGUgc3lzdGVtIGNhbGwgYW5kCiAgICAgIHJldHVy
biBhIGZha2VkIHRpbWUgaW5mb3JtYXRpb24uCgogICBUaGUgY3VycmVudCBzcGVjaWZpY2F0
aW9uIGRpc2N1c3NlcyBhZGRpdGlvbmFsIGFzcGVjdHMgd2l0aCBtb3JlCiAgIGRldGFpbHMu
Cgo2LjEuICBEZWFsaW5nIFdpdGggRG9TIEF0dGFja3MKCiAgIFRFU0xBIGludHJvZHVjZXMg
bmV3IG9wcG9ydHVuaXRpZXMgZm9yIGFuIGF0dGFja2VyIHRvIG1vdW50IERvUwogICBhdHRh
Y2tzLiAgRm9yIGluc3RhbmNlIGFuIGF0dGFja2VyIGNhbiB0cnkgdG8gc2F0dXJhdGUgdGhl
IHByb2Nlc3NpbmcKICAgY2FwYWJpbGl0aWVzIG9mIHRoZSByZWNlaXZlciAoZmFrZWQgcGFj
a2V0cyBhcmUgZWFzeSB0byBjcmVhdGUgYnV0CiAgIGNoZWNraW5nIHRoZW0gcmVxdWlyZXMg
dG8gY29tcHV0ZSBhIE1BQyBvdmVyIHRoZSBwYWNrZXQgb3Igc29tZXRpbWVzCiAgIGNoZWNr
IGEgZGlnaXRhbCBzaWduYXR1cmUgYXMgd2l0aCB0aGUgYm9vdHN0cmFwIGFuZCBkaXJlY3Qg
dGltZQogICBzeW5jaHJvbml6YXRpb24gcmVzcG9uc2UgbWVzc2FnZXMpLiAgQW4gYXR0YWNr
ZXIgY2FuIGFsc28gdHJ5IHRvCiAgIHNhdHVyYXRlIHRoZSByZWNlaXZlcidzIG1lbW9yeSAo
c2luY2UgYXV0aGVudGljYXRpb24gaXMgZGVsYXllZCBhbmQKICAgbm9uLWF1dGhlbnRpY2F0
ZWQgcGFja2V0cyB3aWxsIGFjY3VtdWxhdGUpLCBvciB0byBtYWtlIHRoZSByZWNlaXZlcgog
ICBiZWxpZXZlIHRoYXQgYSBjb25nZXN0aW9uIGhhcyBoYXBwZW5lZCAoc2luY2UgY29uZ2Vz
dGlvbiBjb250cm9sIE1VU1QKICAgYmUgcGVyZm9ybWVkIGJlZm9yZSBhdXRoZW50aWNhdGlu
ZyBpbmNvbWluZyBwYWNrZXRzLCBTZWN0aW9uIDQuMykuCgogICBJbiBvcmRlciB0byBtaXRp
Z2F0ZSB0aGVzZSBhdHRhY2tzLCBpdCBpcyBSRUNPTU1FTkRFRCB0byB1c2UgdGhlCiAgIEdy
b3VwIE1BQyBzY2hlbWUgKFNlY3Rpb24gMy4zLjMpLiAgTm8gbWl0aWdhdGlvbiBpcyBwb3Nz
aWJsZSBpZiBhCiAgIGdyb3VwIG1lbWJlciBhY3RzIGFzIGFuIGF0dGFja2VyIHdpdGggR3Jv
dXAgTUFDLgoKICAgR2VuZXJhbGx5LCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBhbW91
bnQgb2YgbWVtb3J5IHVzZWQgdG8gc3RvcmUKICAgaW5jb21pbmcgcGFja2V0cyB3YWl0aW5n
IHRvIGJlIGF1dGhlbnRpY2F0ZWQgYmUgbGltaXRlZCB0byBhCiAgIHJlYXNvbmFibGUgdmFs
dWUuCgoKCgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAx
MCAgICAgICAgICAgICAgICBbUGFnZSA1M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg
IFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgo2LjIu
ICBEZWFsaW5nIFdpdGggUmVwbGF5IEF0dGFja3MKCiAgIFJlcGxheSBhdHRhY2tzLCB3aGVy
ZWJ5IGFuIGF0dGFja2VyIHN0b3JlcyBhIHZhbGlkIG1lc3NhZ2UgYW5kCiAgIHJlcGxheXMg
aXQgbGF0ZXIgb24sIGNhbiBoYXZlIHNpZ25pZmljYW50IGltcGFjdHMsIGRlcGVuZGluZyBv
biB0aGUKICAgbWVzc2FnZSB0eXBlLiAgVHdvIGxldmVscyBvZiBpbXBhY3RzIG11c3QgYmUg
ZGlzdGluZ3Vpc2hlZDoKCiAgIG8gIHdpdGhpbiB0aGUgVEVTTEEgcHJvdG9jb2wsIGFuZAoK
ICAgbyAgd2l0aGluIHRoZSBBTEMgb3IgTk9STSBwcm90b2NvbC4KCjYuMi4xLiAgSW1wYWN0
cyBvZiBSZXBsYXkgQXR0YWNrcyBvbiBURVNMQQoKICAgUmVwbGF5IGF0dGFja3MgY2FuIGlt
cGFjdCB0aGUgVEVTTEEgY29tcG9uZW50IGl0c2VsZi4gIFdlIHJldmlldyBoZXJlCiAgIHRo
ZSBwb3RlbnRpYWwgaW1wYWN0cyBvZiBzdWNoIGFuIGF0dGFjayBkZXBlbmRpbmcgb24gdGhl
IFRFU0xBCiAgIG1lc3NhZ2UgdHlwZToKCiAgIG8gIGJvb3RzdHJhcCBpbmZvcm1hdGlvbjog
c2luY2UgbW9zdCBwYXJhbWV0ZXJzIGNvbnRhaW5lZCBpbiBhCiAgICAgIGJvb3RzdHJhcCBp
bmZvcm1hdGlvbiBtZXNzYWdlIGFyZSBzdGF0aWMsIHJlcGxheSBhdHRhY2tzIGhhdmUgbm8K
ICAgICAgY29uc2VxdWVuY2VzLiAgVGhlIGZhY3QgdGhhdCB0aGUgImkiIGFuZCAiS19pIiBm
aWVsZHMgY2FuIGJlCiAgICAgIHVwZGF0ZWQgaW4gc3Vic2VxdWVudCBib290c3RyYXAgaW5m
b3JtYXRpb24gbWVzc2FnZXMgZG9lcyBub3QKICAgICAgY3JlYXRlIGEgcHJvYmxlbSBlaXRo
ZXIsIHNpbmNlIGFsbCAiaSIgYW5kICJLX2kiIGZpZWxkcyBzZW50CiAgICAgIHJlbWFpbiB2
YWxpZC4gIEZpbmFsbHksIGEgcmVjZWl2ZXIgdGhhdCBzdWNjZXNzZnVsbHkgaW5pdGlhbGl6
ZWQKICAgICAgaXRzIFRFU0xBIGNvbXBvbmVudCBNVVNUIGlnbm9yZSB0aGUgZm9sbG93aW5n
IG1lc3NhZ2VzIChzZWUKICAgICAgU2VjdGlvbiA0LjIuMSBmb3IgYW4gZXhjZXB0aW9uIHRv
IHRoaXMgcnVsZSksIHdoaWNoIHZvaWRzIHJlcGxheQogICAgICBhdHRhY2tzLCB1bmxlc3Mg
aGUgbWlzc2VkIGFsbCB0aGUgY29tbWl0bWVudHMgdG8gYSBuZXcga2V5IGNoYWluCiAgICAg
IChlLmcuLCBhZnRlciBhIGxvbmcgZGlzY29ubmVjdGlvbikgKFNlY3Rpb24gMy4yLjEpLgoK
ICAgbyAgZGlyZWN0IHRpbWUgc3luY2hyb25pemF0aW9uIHJlcXVlc3Q6IElmIHRoZSBHcm91
cCBNQUMgc2NoZW1lIGlzCiAgICAgIHVzZWQsIGFuIGF0dGFja2VyIHRoYXQgaXMgbm90IGEg
bWVtYmVyIG9mIHRoZSBncm91cCBjYW4gcmVwbGF5IGEKICAgICAgcGFja2V0IGFuZCBvYmxp
Z2UgdGhlIHNlbmRlciB0byByZXNwb25kLCB3aGljaCByZXF1aXJlcyB0bwogICAgICBkaWdp
dGFsbHkgc2lnbiB0aGUgcmVzcG9uc2UsIGEgdGltZS1jb25zdW1pbmcgcHJvY2Vzcy4gIElm
IHRoZQogICAgICBHcm91cCBNQUMgc2NoZW1lIGlzIG5vdCB1c2VkLCBhbiBhdHRhY2tlciBj
YW4gYW55d2F5IGVhc2lseSBmb3JnZQogICAgICBhIHJlcXVlc3QuICBJbiBib3RoIGNhc2Vz
LCB0aGUgYXR0YWNrIHdpbGwgbm90IGNvbXByb21pc2UgdGhlCiAgICAgIFRFU0xBIGNvbXBv
bmVudCwgYnV0IG1pZ2h0IGNyZWF0ZSBhIERvUy4gIElmIHRoaXMgaXMgYSBjb25jZXJuLCBp
dAogICAgICBpcyBSRUNPTU1FTkRFRCwgd2hlbiB0aGUgR3JvdXAgTUFDIHNjaGVtZSBpcyB1
c2VkLCB0aGF0IHRoZSBzZW5kZXIKICAgICAgdmVyaWZ5IHRoZSAidF9yIiBOVFAgdGltZXN0
YW1wIGNvbnRhaW5lZCBpbiB0aGUgcmVxdWVzdCBhbmQKICAgICAgcmVzcG9uZCBvbmx5IGlm
IHRoaXMgdmFsdWUgaXMgc3RyaWN0bHkgbGFyZ2VyIHRoYW4gdGhlIHByZXZpb3VzCiAgICAg
IG9uZSByZWNlaXZlZCBmcm9tIHRoaXMgcmVjZWl2ZXIuICBXaGVuIHRoZSBHcm91cCBNQUMg
c2NoZW1lIGlzIG5vdAogICAgICB1c2VkLCB0aGlzIGF0dGFjayBjYW4gYmUgbWl0aWdhdGVk
IGJ5IGxpbWl0aW5nIHRoZSBudW1iZXIgb2YKICAgICAgcmVxdWVzdHMgcGVyIHNlY29uZCB0
aGF0IHdpbGwgYmUgcHJvY2Vzc2VkLgoKICAgbyAgZGlyZWN0IHRpbWUgc3luY2hyb25pemF0
aW9uIHJlc3BvbnNlOiBVcG9uIHJlY2VpdmluZyBhIHJlc3BvbnNlLCBhCiAgICAgIHJlY2Vp
dmVyIHdobyBoYXMgbm8gcGVuZGluZyByZXF1ZXN0IE1VU1QgaW1tZWRpYXRlbHkgZHJvcCB0
aGUKICAgICAgcGFja2V0LiAgSWYgdGhpcyByZWNlaXZlciBoYXMgcHJldmlvdXNseSBpc3N1
ZWQgYSByZXF1ZXN0LCBoZQogICAgICBmaXJzdCBjaGVja3MgdGhlIEdyb3VwIE1BQyAoaWYg
YXBwbGljYWJsZSksIHRoZW4gdGhlICJ0X3IiIGZpZWxkLAogICAgICB0byBiZSBzdXJlIGl0
IGlzIGEgcmVzcG9uc2UgdG8gaGlzIHJlcXVlc3QsIGFuZCBmaW5hbGx5IHRoZQogICAgICBk
aWdpdGFsIHNpZ25hdHVyZS4gIEEgcmVwbGF5ZWQgcGFja2V0IHdpbGwgYmUgZHJvcHBlZCBk
dXJpbmcgdGhlc2UKICAgICAgdmVyaWZpY2F0aW9ucywgd2l0aG91dCBjb21wcm9taXNpbmcg
dGhlIFRFU0xBIGNvbXBvbmVudC4KCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGly
ZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNTRdCgwKSW50ZXJuZXQt
RHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRl
bWJlciAyMDA5CgoKICAgbyAgb3RoZXIgbWVzc2FnZXMsIGNvbnRhaW5pbmcgYW4gYXV0aGVu
dGljYXRpb24gdGFnOiBSZXBsYXlpbmcgYQogICAgICBwYWNrZXQgY29udGFpbmluZyBhIFRF
U0xBIGF1dGhlbnRpY2F0aW9uIHRhZyB3aWxsIG5ldmVyIGNvbXByb21pc2UKICAgICAgdGhl
IFRFU0xBIGNvbXBvbmVudCBpdHNlbGYgKGJ1dCBwZXJoYXBzIHRoZSB1bmRlcmx5aW5nIEFM
QyBvciBOT1JNCiAgICAgIGNvbXBvbmVudCwgc2VlIGJlbG93KS4KCiAgIFRvIGNvbmNsdWRl
LCBURVNMQSBpdHNlbGYgaXMgcm9idXN0IGluIGZyb250IG9mIHJlcGxheSBhdHRhY2tzLgoK
Ni4yLjIuICBJbXBhY3RzIG9mIFJlcGxheSBBdHRhY2tzIG9uIE5PUk0KCiAgIFdlIHJldmll
dyBoZXJlIHRoZSBwb3RlbnRpYWwgaW1wYWN0cyBvZiBhIHJlcGxheSBhdHRhY2sgb24gdGhl
IE5PUk0KICAgY29tcG9uZW50LiAgTm90ZSB0aGF0IHdlIGRvIG5vdCBjb25zaWRlciBoZXJl
IHRoZSBwcm90b2NvbHMgdGhhdAogICBjb3VsZCBiZSB1c2VkIGFsb25nIHdpdGggTk9STSwg
Zm9yIGluc3RhbmNlIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wKICAgcHJvdG9jb2xzLgoKICAg
Rmlyc3QsIGxldCB1cyBjb25zaWRlciByZXBsYXkgYXR0YWNrcyB3aXRoaW4gYSBnaXZlbiBO
T1JNIHNlc3Npb24uCiAgIE5PUk0gZGVmaW5lcyBhICJzZXF1ZW5jZSIgZmllbGQgdGhhdCBj
YW4gYmUgdXNlZCB0byBwcm90ZWN0IGFnYWluc3QKICAgcmVwbGF5IGF0dGFja3MgW1JNVC1Q
SS1OT1JNXSB3aXRoaW4gYSBnaXZlbiBOT1JNIHNlc3Npb24uICBUaGlzCiAgICJzZXF1ZW5j
ZSIgZmllbGQgaXMgYSAxNi1iaXQgdmFsdWUgdGhhdCBpcyBzZXQgYnkgdGhlIG1lc3NhZ2UK
ICAgb3JpZ2luYXRvciAoc2VuZGVyIG9yIHJlY2VpdmVyKSBhcyBhIG1vbm90b25pY2FsbHkg
aW5jcmVhc2luZyBudW1iZXIKICAgaW5jcmVtZW50ZWQgd2l0aCBlYWNoIE5PUk0gbWVzc2Fn
ZSB0cmFuc21pdHRlZC4gIEl0IGlzIFJFQ09NTUVOREVECiAgIHRoYXQgYSByZWNlaXZlciBj
aGVjayB0aGlzIHNlcXVlbmNlIGZpZWxkIGFuZCBkcm9wIG1lc3NhZ2VzCiAgIGNvbnNpZGVy
ZWQgYXMgcmVwbGF5ZWQuICBTaW1pbGFybHksIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYSBz
ZW5kZXIKICAgY2hlY2sgdGhpcyBzZXF1ZW5jZSwgZm9yIGVhY2gga25vd24gcmVjZWl2ZXIs
IGFuZCBkcm9wIG1lc3NhZ2VzCiAgIGNvbnNpZGVyZWQgYXMgcmVwbGF5ZWQuICBJbiBib3Ro
IGNhc2VzLCBjaGVja2luZyB0aGlzIHNlcXVlbmNlIGZpZWxkCiAgIFNIT1VMRCBiZSBkb25l
IGJlZm9yZSBURVNMQSBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQ6IGlmIHRoZSBzZXF1ZW5j
ZQogICBmaWVsZCBoYXMgbm90IGJlZW4gY29ycnVwdGVkLCB0aGUgcmVwbGF5IGF0dGFjayB3
aWxsIGltbWVkaWF0ZWx5IGJlCiAgIGlkZW50aWZpZWQsIGFuZCBvdGhlcndpc2UgdGhlIHBh
Y2tldCB3aWxsIGZhaWwgdGhlIFRFU0xBCiAgIGF1dGhlbnRpY2F0aW9uIHRlc3QuICBUaGlz
IGFuYWx5c2lzIHNob3dzIHRoYXQgTk9STSBpdHNlbGYgaXMgcm9idXN0CiAgIGluIGZyb250
IG9mIHJlcGxheSBhdHRhY2tzIHdpdGhpbiB0aGUgc2FtZSBzZXNzaW9uLgoKICAgTm93IGxl
dCB1cyBjb25zaWRlciByZXBsYXkgYXR0YWNrcyBhY3Jvc3Mgc2V2ZXJhbCBOT1JNIHNlc3Np
b25zLgogICBTaW5jZSB0aGUga2V5IGNoYWluIHVzZWQgaW4gZWFjaCBzZXNzaW9uIE1VU1Qg
ZGlmZmVyLCBhIHBhY2tldAogICByZXBsYXllZCBpbiBhIHN1YnNlcXVlbnQgc2Vzc2lvbiB3
aWxsIGJlIGlkZW50aWZpZWQgYXMgdW5hdXRoZW50aWMuCiAgIFRoZXJlZm9yZSBOT1JNIGlz
IHJvYnVzdCBpbiBmcm9udCBvZiByZXBsYXkgYXR0YWNrcyBhY3Jvc3MgZGlmZmVyZW50CiAg
IHNlc3Npb25zLgoKNi4yLjMuICBJbXBhY3RzIG9mIFJlcGxheSBBdHRhY2tzIG9uIEFMQwoK
ICAgV2UgcmV2aWV3IGhlcmUgdGhlIHBvdGVudGlhbCBpbXBhY3RzIG9mIGEgcmVwbGF5IGF0
dGFjayBvbiB0aGUgQUxDCiAgIGNvbXBvbmVudC4gIE5vdGUgdGhhdCB3ZSBkbyBub3QgY29u
c2lkZXIgaGVyZSB0aGUgcHJvdG9jb2xzIHRoYXQKICAgY291bGQgYmUgdXNlZCBhbG9uZyB3
aXRoIEFMQywgZm9yIGluc3RhbmNlIHRoZSBsYXllcmVkIG9yIHdhdmUgYmFzZWQKICAgY29u
Z2VzdGlvbiBjb250cm9sIHByb3RvY29scy4KCiAgIEZpcnN0LCBsZXQgdXMgY29uc2lkZXIg
cmVwbGF5IGF0dGFja3Mgd2l0aGluIGEgZ2l2ZW4gQUxDIHNlc3Npb246CgogICBvICBSZWd1
bGFyIHBhY2tldHMgY29udGFpbmluZyBhbiBhdXRoZW50aWNhdGlvbiB0YWc6IGEgcmVwbGF5
ZWQKICAgICAgbWVzc2FnZSBjb250YWluaW5nIGFuIGVuY29kaW5nIHN5bWJvbCB3aWxsIGJl
IGRldGVjdGVkIG9uY2UKICAgICAgYXV0aGVudGljYXRlZCwgdGhhbmtzIHRvIHRoZSBvYmpl
Y3QvYmxvY2svc3ltYm9sIGlkZW50aWZpZXJzLCBhbmQKCgoKUm9jYSwgZXQgYWwuICAgICAg
ICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNTVd
CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAg
ICAgICAgIFNlcHRlbWJlciAyMDA5CgoKICAgICAgd2lsbCBiZSBzaWxlbnRseSBkaXNjYXJk
ZWQuICBUaGlzIGtpbmQgb2YgcmVwbGF5IGF0dGFjayBpcyBvbmx5CiAgICAgIHBlbmFsaXpp
bmcgaW4gdGVybXMgb2YgbWVtb3J5IGFuZCBwcm9jZXNzaW5nIGxvYWQsIGJ1dCBkb2VzIG5v
dAogICAgICBjb21wcm9taXNlIHRoZSBBTEMgYmVoYXZpb3IuCgogICBvICBDb250cm9sIHBh
Y2tldHMgY29udGFpbmluZyBhbiBhdXRoZW50aWNhdGlvbiB0YWc6IEFMQyBjb250cm9sCiAg
ICAgIHBhY2tldHMsIGJ5IGRlZmluaXRpb24sIGRvIG5vdCBpbmNsdWRlIGFueSBlbmNvZGlu
ZyBzeW1ib2wgYW5kCiAgICAgIHRoZXJlZm9yZSBkbyBub3QgaW5jbHVkZSBhbnkgb2JqZWN0
L2Jsb2NrL3N5bWJvbCBpZGVudGlmaWVyIHRoYXQKICAgICAgd291bGQgZW5hYmxlIGEgcmVj
ZWl2ZXIgdG8gaWRlbnRpZnkgZHVwbGljYXRlcy4gIEhvd2V2ZXIsIGEgc2VuZGVyCiAgICAg
IGhhcyBhIHZlcnkgbGltaXRlZCBudW1iZXIgb2YgcmVhc29ucyB0byBzZW5kIGNvbnRyb2wg
cGFja2V0cy4KICAgICAgTW9yZSBwcmVjaXNlbHk6CgogICAgICAqICBBdCB0aGUgZW5kIG9m
IHRoZSBzZXNzaW9uLCBhICJjbG9zZSBzZXNzaW9uIiAoQSBmbGFnKSBwYWNrZXQgaXMKICAg
ICAgICAgc2VudC4gIFJlcGxheWluZyB0aGlzIHBhY2tldCBoYXMgbm8gaW1wYWN0IHNpbmNl
IHRoZSByZWNlaXZlcnMKICAgICAgICAgYWxyZWFkeSBsZWZ0LgoKICAgICAgKiAgU2ltaWxh
cmx5LCByZXBsYXlpbmcgYSBwYWNrZXQgY29udGFpbmluZyBhICJjbG9zZSBvYmplY3QiIChC
CiAgICAgICAgIGZsYWcpIGhhcyBubyBpbXBhY3Qgc2luY2UgdGhpcyBvYmplY3QgaXMgcHJv
YmFibHkgYWxyZWFkeQogICAgICAgICBtYXJrZWQgYXMgY2xvc2VkIGJ5IHRoZSByZWNlaXZl
ci4KCiAgIFRoaXMgYW5hbHlzaXMgc2hvd3MgdGhhdCBBTEMgaXRzZWxmIGlzIHJvYnVzdCBp
biBmcm9udCBvZiByZXBsYXkKICAgYXR0YWNrcyB3aXRoaW4gdGhlIHNhbWUgc2Vzc2lvbi4K
CiAgIE5vdyBsZXQgdXMgY29uc2lkZXIgcmVwbGF5IGF0dGFja3MgYWNyb3NzIHNldmVyYWwg
QUxDIHNlc3Npb25zLgogICBTaW5jZSB0aGUga2V5IGNoYWluIHVzZWQgaW4gZWFjaCBzZXNz
aW9uIE1VU1QgZGlmZmVyLCBhIHBhY2tldAogICByZXBsYXllZCBpbiBhIHN1YnNlcXVlbnQg
c2Vzc2lvbiB3aWxsIGJlIGlkZW50aWZpZWQgYXMgdW5hdXRoZW50aWMuCiAgIFRoZXJlZm9y
ZSBBTEMgaXMgcm9idXN0IGluIGZyb250IG9mIHJlcGxheSBhdHRhY2tzIGFjcm9zcyBkaWZm
ZXJlbnQKICAgc2Vzc2lvbnMuCgo2LjMuICBTZWN1cml0eSBvZiB0aGUgQmFjayBDaGFubmVs
CgogICBBcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAxLjEsIHRoaXMgc3BlY2lmaWNhdGlvbiBk
b2VzIG5vdCBjb25zaWRlciB0aGUKICAgcGFja2V0cyB0aGF0IG1heSBiZSBzZW50IGJ5IHJl
Y2VpdmVycywgZm9yIGluc3RhbmNlIE5PUk0ncyBmZWVkYmFjawogICBwYWNrZXRzLiAgV2hl
biBhIGJhY2sgY2hhbm5lbCBpcyB1c2VkLCBpdHMgc2VjdXJpdHkgaXMgY3JpdGljYWwgdG8K
ICAgdGhlIGdsb2JhbCBzZWN1cml0eSwgYW5kIGFuIGFwcHJvcHJpYXRlIHNlY3VyaXR5IG1l
Y2hhbmlzbSBNVVNUIGJlCiAgIHVzZWQuICBbUk1ULVNJTVBMRS1BVVRIXSBkZXNjcmliZXMg
c2V2ZXJhbCB0ZWNobmlxdWVzIHRoYXQgY2FuIGJlCiAgIHVzZWQgdG8gdGhhdCBwdXJwb3Nl
LiAgSG93ZXZlciwgdGhlIGF1dGhlbnRpY2F0aW9uIGFuZCBpbnRlZ3JpdHkKICAgdmVyaWZp
Y2F0aW9uIG9mIHRoZSBwYWNrZXRzIHNlbnQgYnkgcmVjZWl2ZXJzIG9uIHRoZSBiYWNrIGNo
YW5uZWwsIGlmCiAgIGFueSwgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50
LgoKCgoKCgoKCgoKCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2gg
MjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNTZdCgwKSW50ZXJuZXQtRHJhZnQgICAg
ICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5
CgoKNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgcmVxdWlyZXMg
YSBJQU5BIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIGZvbGxvd2luZwogICBhdHRyaWJ1dGVzLiAg
VGhlIHJlZ2lzdHJpZXMgYXJlIHByb3ZpZGVkIGJ5IFtSRkM0NDQyXSB1bmRlciB0aGUKICAg
IlRpbWVkIEVmZmljaWVudCBTdHJlYW0gTG9zcy10b2xlcmFudCBBdXRoZW50aWNhdGlvbiAo
VEVTTEEpCiAgIFBhcmFtZXRlcnMiIHJlZ2lzdHJ5IFtURVNMQS1SRUddLiAgRm9sbG93aW5n
IHRoZSBwb2xpY2llcyBvdXRsaW5lZCBpbgogICBbUkZDNDQ0Ml0sIHRoZSB2YWx1ZXMgaW4g
dGhlIHJhbmdlIHVwIHRvIDI0MCAoaW5jbHVkaW5nIDI0MCkgZm9yIHRoZQogICBmb2xsb3dp
bmcgYXR0cmlidXRlcyBhcmUgYXNzaWduZWQgYWZ0ZXIgZXhwZXJ0IHJldmlldyBieSB0aGUg
TVNFQwogICB3b3JraW5nIGdyb3VwIG9yIGl0cyBkZXNpZ25hdGVkIHN1Y2Nlc3Nvci4gIFRo
ZSB2YWx1ZXMgaW4gdGhlIHJhbmdlCiAgIGZyb20gMjQxIHRvIDI1NSBhcmUgcmVzZXJ2ZWQg
Zm9yIHByaXZhdGUgdXNlLgoKICAgQ3J5cHRvZ3JhcGhpYyBQc2V1ZG8tUmFuZG9tIEZ1bmN0
aW9uLCBURVNMQS1QUkY6IEFsbCBpbXBsZW1lbnRhdGlvbnMKICAgTVVTVCBzdXBwb3J0IEhN
QUMtU0hBLTI1NiAoZGVmYXVsdCkuCgogICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0rLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICB8ICAgICAgICBQ
UkYgbmFtZSAgICAgICAgfCBWYWx1ZSB8CiAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKwogICAgICAgICAgICAgICAgICAgIHwgICAgICAg
SE1BQy1TSEEtMSAgICAgICB8ICAgMCAgIHwKICAgICAgICAgICAgICAgICAgICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgfCAgICAg
IEhNQUMtU0hBLTIyNCAgICAgIHwgICAxICAgfAogICAgICAgICAgICAgICAgICAgIHwgICAg
ICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICB8IEhN
QUMtU0hBLTI1NiAoZGVmYXVsdCkgfCAgIDIgICB8CiAgICAgICAgICAgICAgICAgICAgfCAg
ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAogICAgICAgICAgICAgICAgICAgIHwg
ICAgICBITUFDLVNIQS0zODQgICAgICB8ICAgMyAgIHwKICAgICAgICAgICAgICAgICAgICB8
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiAgICAgICAgICAgICAgICAgICAg
fCAgICAgIEhNQUMtU0hBLTUxMiAgICAgIHwgICA0ICAgfAogICAgICAgICAgICAgICAgICAg
ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSsKCiAgIENyeXB0b2dyYXBoaWMg
TWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlIChNQUMpIEZ1bmN0aW9uLCBURVNMQS1NQUM6
CiAgIEFsbCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IEhNQUMtU0hBLTI1NiAoZGVm
YXVsdCkuICBUaGVzZSBNQUMKICAgc2NoZW1lcyBhcmUgdXNlZCBib3RoIGZvciB0aGUgY29t
cHV0aW5nIG9mIHJlZ3VsYXIgTUFDIGFuZCB0aGUgR3JvdXAKICAgTUFDIChpZiBhcHBsaWNh
YmxlKS4KCiAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst
LS0tLS0tKwogICAgICAgICAgICAgICAgICAgIHwgICAgICAgIE1BQyBuYW1lICAgICAgICB8
IFZhbHVlIHwKICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
Ky0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgfCAgICAgICBITUFDLVNIQS0xICAgICAg
IHwgICAwICAgfAogICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICB8ICAgICAgSE1BQy1TSEEtMjI0ICAg
ICAgfCAgIDEgICB8CiAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg
ICAgIHwgICAgICAgfAogICAgICAgICAgICAgICAgICAgIHwgSE1BQy1TSEEtMjU2IChkZWZh
dWx0KSB8ICAgMiAgIHwKICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgfCAgICAgIEhNQUMtU0hBLTM4
NCAgICAgIHwgICAzICAgfAogICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg
ICAgICAgICB8ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICB8ICAgICAgSE1BQy1TSEEt
NTEyICAgICAgfCAgIDQgICB8CiAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tKwoKICAgRnVydGhlcm1vcmUsIHRoaXMgZG9jdW1lbnQgcmVx
dWlyZXMgSUFOQSB0byBjcmVhdGUgdHdvIG5ldwoKCgpSb2NhLCBldCBhbC4gICAgICAgICAg
ICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA1N10KDApJ
bnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAg
ICAgU2VwdGVtYmVyIDIwMDkKCgogICByZWdpc3RyaWVzLiAgSGVyZSBhbHNvLCB0aGUgdmFs
dWVzIGluIHRoZSByYW5nZSB1cCB0byAyNDAgKGluY2x1ZGluZwogICAyNDApIGZvciB0aGUg
Zm9sbG93aW5nIGF0dHJpYnV0ZXMgYXJlIGFzc2lnbmVkIGFmdGVyIGV4cGVydCByZXZpZXcg
YnkKICAgdGhlIE1TRUMgd29ya2luZyBncm91cCBvciBpdHMgZGVzaWduYXRlZCBzdWNjZXNz
b3IuICBUaGUgdmFsdWVzIGluCiAgIHRoZSByYW5nZSBmcm9tIDI0MSB0byAyNTUgYXJlIHJl
c2VydmVkIGZvciBwcml2YXRlIHVzZS4KCiAgIFNpZ25hdHVyZSBFbmNvZGluZyBBbGdvcml0
aG0sIFRFU0xBLVNJRy1BTEdPOiBBbGwgaW1wbGVtZW50YXRpb25zCiAgIE1VU1Qgc3VwcG9y
dCBSU0FTU0EtUEtDUzEtdjFfNSAoZGVmYXVsdCkuCgogICAgICAgICAgICAgICAgICArLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSsKICAgICAgICAgICAgICAgICAg
fCAgIFNpZ25hdHVyZSBBbGdvcml0aG0gTmFtZSAgfCBWYWx1ZSB8CiAgICAgICAgICAgICAg
ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKwogICAgICAgICAg
ICAgICAgICB8ICAgICAgICAgICBJTlZBTElEICAgICAgICAgICB8ICAgMCAgIHwKICAgICAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiAg
ICAgICAgICAgICAgICAgIHwgUlNBU1NBLVBLQ1MxLXYxXzUgKGRlZmF1bHQpIHwgICAxICAg
fAogICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg
ICAgIHwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICBSU0FTU0EtUFNTICAgICAgICAg
fCAgIDIgICB8CiAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLSstLS0tLS0tKwoKICAgU2lnbmF0dXJlIENyeXB0b2dyYXBoaWMgRnVuY3Rpb24sIFRF
U0xBLVNJRy1DUllQVE8tRlVOQzogQWxsCiAgIGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBv
cnQgU0hBLTI1NiAoZGVmYXVsdCkuCgogICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgfCBDcnlwdG9n
cmFwaGljIEZ1bmN0aW9uIE5hbWUgfCBWYWx1ZSB8CiAgICAgICAgICAgICAgICAgICstLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKwogICAgICAgICAgICAgICAgICB8
ICAgICAgICAgICBJTlZBTElEICAgICAgICAgICB8ICAgMCAgIHwKICAgICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiAgICAgICAgICAg
ICAgICAgIHwgICAgICAgICAgICBTSEEtMSAgICAgICAgICAgIHwgICAxICAgfAogICAgICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKICAg
ICAgICAgICAgICAgICAgfCAgICAgICAgICAgU0hBLTIyNCAgICAgICAgICAgfCAgIDIgICB8
CiAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg
ICAgfAogICAgICAgICAgICAgICAgICB8ICAgICAgU0hBLTI1NiAoZGVmYXVsdCkgICAgICB8
ICAgMyAgIHwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfCAgICAgICB8CiAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIFNIQS0zODQgICAg
ICAgICAgIHwgICA0ICAgfAogICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8ICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgU0hB
LTUxMiAgICAgICAgICAgfCAgIDUgICB8CiAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKwoKCgoKCgoKCgoKCgoKCgpSb2NhLCBldCBh
bC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBb
UGFnZSA1OF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQg
Tk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgo4LiAgQWNrbm93bGVkZ21lbnRzCgog
ICBUaGUgYXV0aG9ycyBhcmUgZ3JhdGVmdWwgdG8gWWFyb24gU2hlZmZlciwgQnJpYW4gV2Vp
cywgUmFtdQogICBQYW5heWFwcGFuLCBSYW4gQ2FuZXR0aSwgRGF2aWQgTC4gTWlsbHMsIEJy
aWFuIEFkYW1zb24gYW5kIExpb25lbAogICBHaXJhdWQgZm9yIHRoZWlyIHZhbHVhYmxlIGNv
bW1lbnRzIHdoaWxlIHByZXBhcmluZyB0aGlzIGRvY3VtZW50LgogICBUaGUgYXV0aG9ycyBh
cmUgYWxzbyBncmF0ZWZ1bCB0byBCcmlhbiBXZWlzIGZvciB0aGUgZGlnaXRhbCBzaWduYXR1
cmUKICAgZGV0YWlscy4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgpSb2NhLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAg
ICAgICAgICAgICAgICBbUGFnZSA1OV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRF
U0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAgICAgU2VwdGVtYmVyIDIwMDkKCgo5LiAgUmVm
ZXJlbmNlcwoKOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJh
ZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAg
ICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgUkZDIDIxMTksIEJDUCAxNCwgTWFyY2gg
MTk5Ny4KCiAgIFtSRkM0MDgyXSAgUGVycmlnLCBBLiwgU29uZywgRC4sIENhbmV0dGksIFIu
LCBUeWdhciwgSi4sIGFuZCBCLgogICAgICAgICAgICAgIEJyaXNjb2UsICJUaW1lZCBFZmZp
Y2llbnQgU3RyZWFtIExvc3MtVG9sZXJhbnQKICAgICAgICAgICAgICBBdXRoZW50aWNhdGlv
biAoVEVTTEEpOiBNdWx0aWNhc3QgU291cmNlIEF1dGhlbnRpY2F0aW9uCiAgICAgICAgICAg
ICAgVHJhbnNmb3JtIEludHJvZHVjdGlvbiIsIFJGQyA0MDgyLCBKdW5lIDIwMDUuCgogICBb
Uk1ULUJCLUxDVF0KICAgICAgICAgICAgICBMdWJ5LCBNLiwgV2F0c29uLCBNLiwgYW5kIEwu
IFZpY2lzYW5vLCAiTGF5ZXJlZCBDb2RpbmcKICAgICAgICAgICAgICBUcmFuc3BvcnQgKExD
VCkgQnVpbGRpbmcgQmxvY2siLAogICAgICAgICAgICAgICBkcmFmdC1pZXRmLXJtdC1iYi1s
Y3QtcmV2aXNlZC0xMS50eHQgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIEF1
Z3VzdCAyMDA5LgoKICAgW1JNVC1QSS1BTENdCiAgICAgICAgICAgICAgTHVieSwgTS4sIFdh
dHNvbiwgTS4sIGFuZCBMLiBWaWNpc2FubywgIkFzeW5jaHJvbm91cwogICAgICAgICAgICAg
IExheWVyZWQgQ29kaW5nIChBTEMpIFByb3RvY29sIEluc3RhbnRpYXRpb24iLAogICAgICAg
ICAgICAgICBkcmFmdC1pZXRmLXJtdC1waS1hbGMtcmV2aXNlZC0wOC50eHQgKHdvcmsgaW4g
cHJvZ3Jlc3MpLAogICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA5LgoKICAgW1JNVC1QSS1O
T1JNXQogICAgICAgICAgICAgIEFkYW1zb24sIEIuLCBCb3JtYW5uLCBDLiwgSGFuZGxleSwg
TS4sIGFuZCBKLiBNYWNrZXIsCiAgICAgICAgICAgICAgIk5lZ2F0aXZlLWFja25vd2xlZGdt
ZW50IChOQUNLKS1PcmllbnRlZCBSZWxpYWJsZQogICAgICAgICAgICAgIE11bHRpY2FzdCAo
Tk9STSkgUHJvdG9jb2wiLAogICAgICAgICAgICAgICBkcmFmdC1pZXRmLXJtdC1waS1ub3Jt
LXJldmlzZWQtMTMudHh0ICh3b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAgICBKdW5l
IDIwMDkuCgogICBbVEVTTEEtUkVHXQogICAgICAgICAgICAgICJURVNMQSBQYXJhbWV0ZXJz
IElBTkEgUmVnaXN0cnkiLAogICAgICAgICAgICAgICBodHRwOi8vd3d3LmlhbmEub3JnL2Fz
c2lnbm1lbnRzL3Rlc2xhLXBhcmFtZXRlcnMvLgoKOS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJl
bmNlcwoKICAgW05UUC1OVFB2NF0KICAgICAgICAgICAgICBCdXJiYW5rLCBKLiwgS2FzY2gs
IFcuLCBNYXJ0aW4sIEouLCBhbmQgRC4gTWlsbHMsICJUaGUKICAgICAgICAgICAgICBOZXR3
b3JrIFRpbWUgUHJvdG9jb2wgVmVyc2lvbiA0IFByb3RvY29sIFNwZWNpZmljYXRpb24iLAog
ICAgICAgICAgICAgICBkcmFmdC1pZXRmLW50cC1udHB2NC1wcm90by0xMS50eHQgKHdvcmsg
aW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIFNlcHRlbWJlciAyMDA4LgoKICAgW1BlcnJp
ZzA0XQogICAgICAgICAgICAgIFBlcnJpZywgQS4gYW5kIEouIFR5Z2FyLCAiU2VjdXJlIEJy
b2FkY2FzdCBDb21tdW5pY2F0aW9uCiAgICAgICAgICAgICAgaW4gV2lyZWQgYW5kIFdpcmVs
ZXNzIE5ldHdvcmtzIiwgS2x1d2VyIEFjYWRlbWljCiAgICAgICAgICAgICAgUHVibGlzaGVy
cyBJU0JOIDAtNzkyMy03NjUwLTEsIDIwMDQuCgoKCgpSb2NhLCBldCBhbC4gICAgICAgICAg
ICAgRXhwaXJlcyBNYXJjaCAyMCwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSA2MF0KDApJ
bnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFRFU0xBIGluIEFMQyBhbmQgTk9STSAgICAgICAg
ICAgU2VwdGVtYmVyIDIwMDkKCgogICBbUkZDMTMwNV0gIE1pbGxzLCBELiwgIk5ldHdvcmsg
VGltZSBQcm90b2NvbCAoVmVyc2lvbiAzKQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24s
IEltcGxlbWVudGF0aW9uIiwgUkZDIDEzMDUsIE1hcmNoIDE5OTIuCgogICBbUkZDMjEwNF0g
IEtyYXdjenlrLCBILiwgQmVsbGFyZSwgTS4sIGFuZCBSLiBDYW5ldHRpLCAiSE1BQzogS2V5
ZWQtCiAgICAgICAgICAgICAgSGFzaGluZyBmb3IgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiIs
IFJGQyAyMTA0LAogICAgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTcuCgogICBbUkZDMzQ0N10g
IEpvbnNzb24sIEouIGFuZCBCLiBLYWxpc2tpLCAiUHVibGljLUtleSBDcnlwdG9ncmFwaHkK
ICAgICAgICAgICAgICBTdGFuZGFyZHMgKFBLQ1MpICMxOiBSU0EgQ3J5cHRvZ3JhcGh5IFNw
ZWNpZmljYXRpb25zCiAgICAgICAgICAgICAgVmVyc2lvbiAyLjEiLCBSRkMgMzQ0NywgRmVi
cnVhcnkgMjAwMy4KCiAgIFtSRkMzNzExXSAgQmF1Z2hlciwgTS4sIE1jR3JldywgRC4sIE5h
c2x1bmQsIE0uLCBDYXJyYXJhLCBFLiwgYW5kIEsuCiAgICAgICAgICAgICAgTm9ycm1hbiwg
IlRoZSBTZWN1cmUgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCAoU1JUUCkiLAogICAg
ICAgICAgICAgIFJGQyAzNzExLCBNYXJjaCAyMDA0LgoKICAgW1JGQzQzMzBdICBNaWxscywg
RC4sICJTaW1wbGUgTmV0d29yayBUaW1lIFByb3RvY29sIChTTlRQKSBWZXJzaW9uIDQKICAg
ICAgICAgICAgICBmb3IgSVB2NCwgSVB2NiBhbmQgT1NJIiwgUkZDIDQzMzAsIEphbnVhcnkg
MjAwNi4KCiAgIFtSRkM0MzU5XSAgV2VpcywgQi4sICJUaGUgVXNlIG9mIFJTQS9TSEEtMSBT
aWduYXR1cmVzIHdpdGhpbgogICAgICAgICAgICAgIEVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkg
UGF5bG9hZCAoRVNQKSBhbmQgQXV0aGVudGljYXRpb24KICAgICAgICAgICAgICBIZWFkZXIg
KEFIKSIsIFJGQyA0MzU5LCBKYW51YXJ5IDIwMDYuCgogICBbUkZDNDM4M10gIEJhdWdoZXIs
IE0uIGFuZCBFLiBDYXJyYXJhLCAiVGhlIFVzZSBvZiBUaW1lZCBFZmZpY2llbnQKICAgICAg
ICAgICAgICBTdHJlYW0gTG9zcy1Ub2xlcmFudCBBdXRoZW50aWNhdGlvbiAoVEVTTEEpIGlu
IHRoZSBTZWN1cmUKICAgICAgICAgICAgICBSZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29s
IChTUlRQKSIsIFJGQyA0MzgzLAogICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMDYuCgogICBb
UkZDNDQ0Ml0gIEZyaWVzLCBTLiBhbmQgSC4gVHNjaG9mZW5pZywgIkJvb3RzdHJhcHBpbmcg
VGltZWQKICAgICAgICAgICAgICBFZmZpY2llbnQgU3RyZWFtIExvc3MtVG9sZXJhbnQgQXV0
aGVudGljYXRpb24gKFRFU0xBKSIsCiAgICAgICAgICAgICAgUkZDIDQ0NDIsIE1hcmNoIDIw
MDYuCgogICBbUk1ULUZMVVRFXQogICAgICAgICAgICAgIFBhaWxhLCBULiwgV2Fsc2gsIFIu
LCBMdWJ5LCBNLiwgTGVodG9uZW4sIFIuLCBhbmQgVi4gUm9jYSwKICAgICAgICAgICAgICAi
RkxVVEUgLSBGaWxlIERlbGl2ZXJ5IG92ZXIgVW5pZGlyZWN0aW9uYWwgVHJhbnNwb3J0IiwK
ICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1ybXQtZmx1dGUtcmV2aXNlZC0wNy50eHQgKHdv
cmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIEF1Z3VzdCAyMDA5LgoKICAgW1JNVC1T
SU1QTEUtQVVUSF0KICAgICAgICAgICAgICBSb2NhLCBWLiwgIlNpbXBsZSBBdXRoZW50aWNh
dGlvbiBTY2hlbWVzIGZvciB0aGUgQUxDIGFuZAogICAgICAgICAgICAgIE5PUk0gUHJvdG9j
b2xzIiwKICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1ybXQtc2ltcGxlLWF1dGgtZm9yLWFs
Yy1ub3JtLTAxLnR4dCAod29yayBpbgogICAgICAgICAgICAgIHByb2dyZXNzKSwgTWFyY2gg
MjAwOS4KCgoKCgoKCgoKUm9jYSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2gg
MjAsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNjFdCgwKSW50ZXJuZXQtRHJhZnQgICAg
ICAgICAgICBURVNMQSBpbiBBTEMgYW5kIE5PUk0gICAgICAgICAgIFNlcHRlbWJlciAyMDA5
CgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBWaW5jZW50IFJvY2EKICAgSU5SSUEKICAgNjU1
LCBhdi4gZGUgbCdFdXJvcGUKICAgSW5vdmFsbGVlOyBNb250Ym9ubm90CiAgIFNUIElTTUlF
UiBjZWRleCAgMzgzMzQKICAgRnJhbmNlCgogICBFbWFpbDogdmluY2VudC5yb2NhQGlucmlh
LmZyCiAgIFVSSTogICBodHRwOi8vcGxhbmV0ZS5pbnJpYWxwZXMuZnIvfnJvY2EvCgoKICAg
QXVyZWxpZW4gRnJhbmNpbGxvbgogICBJTlJJQQogICA2NTUsIGF2LiBkZSBsJ0V1cm9wZQog
ICBJbm92YWxsZWU7IE1vbnRib25ub3QKICAgU1QgSVNNSUVSIGNlZGV4ICAzODMzNAogICBG
cmFuY2UKCiAgIEVtYWlsOiBhdXJlbGllbi5mcmFuY2lsbG9uQGlucmlhLmZyCiAgIFVSSTog
ICBodHRwOi8vcGxhbmV0ZS5pbnJpYWxwZXMuZnIvfmZyYW5jaWxsLwoKCiAgIFNlYmFzdGll
biBGYXVyaXRlCiAgIElOUklBCiAgIDY1NSwgYXYuIGRlIGwnRXVyb3BlCiAgIElub3ZhbGxl
ZTsgTW9udGJvbm5vdAogICBTVCBJU01JRVIgY2VkZXggIDM4MzM0CiAgIEZyYW5jZQoKICAg
RW1haWw6IGZhdXJpdGVAbGNwYy5mcgoKCgoKCgoKCgoKCgoKCgoKCgoKUm9jYSwgZXQgYWwu
ICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjAsIDIwMTAgICAgICAgICAgICAgICAgW1Bh
Z2UgNjJdCgwK
--------------090102000001000200050109
Content-Type: text/xml;
 name="draft-ietf-msec-tesla-for-alc-norm-09.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-msec-tesla-for-alc-norm-09.xml"

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<!--<rfc category="exp" ipr="full3978" docName="draft-ietf-msec-tesla-for-alc-norm-07.txt">-->
<!--<rfc category="exp" ipr="trust200811" docName="draft-ietf-msec-tesla-for-alc-norm-08.txt">-->
<rfc category="exp" ipr="pre5378Trust200902">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

    <front>
        <title abbrev='TESLA in ALC and NORM'>
            Use of TESLA in the ALC and NORM Protocols
        </title>
        <author initials='V.R.' surname="Roca" fullname='Vincent Roca'>
            <organization>INRIA</organization>
            <address>
                <postal>
                    <street>655, av. de l'Europe</street>
                    <street>Inovallee; Montbonnot</street>
                    <city>ST ISMIER cedex</city>
                    <code>38334</code>
                    <country>France</country>
                </postal>
		<!--
                <phone></phone>
		-->
                <email>vincent.roca@inria.fr</email>
                <uri>http://planete.inrialpes.fr/~roca/</uri>
            </address>
        </author>
        <author initials='A.F.' surname="Francillon" fullname='Aurelien Francillon'>
            <organization>INRIA</organization>
            <address>
                <postal>
                    <street>655, av. de l'Europe</street>
                    <street>Inovallee; Montbonnot</street>
                    <city>ST ISMIER cedex</city>
                    <code>38334</code>
                    <country>France</country>
                </postal>
		<!--
                <phone></phone>
		-->
                <email>aurelien.francillon@inria.fr</email>
                <uri>http://planete.inrialpes.fr/~francill/</uri>
            </address>
        </author>
        <author initials='S.F.' surname="Faurite" fullname='Sebastien Faurite'>
            <organization>INRIA</organization>
            <address>
                <postal>
                    <street>655, av. de l'Europe</street>
                    <street>Inovallee; Montbonnot</street>
                    <city>ST ISMIER cedex</city>
                    <code>38334</code>
                    <country>France</country>
                </postal>
                <email>faurite@lcpc.fr</email>
		<!--
                <phone></phone>
                <uri></uri>
		-->
            </address>
        </author>
        <date day="16" month="September" year="2009"/>
        <area>Transport</area>
        <workgroup>MSEC</workgroup>
        <keyword>TESLA</keyword>
        <keyword>FLUTE</keyword>
        <keyword>ALC</keyword>
        <keyword>NORM</keyword>
        <abstract>
                <t>
		This document details the TESLA packet source authentication and packet integrity
		verification protocol and its integration within the ALC and NORM content delivery
		protocols.
		This document only considers the authentication/integrity verification of the packets
		generated by the session's sender. The authentication and integrity verification of
		the packets sent by receivers, if any, is out of the scope of this document.
                </t>
        </abstract>
    </front>

    <middle>

<section anchor="intro" title="Introduction">
<!-- ==================================== -->

<t>
Many applications using multicast and broadcast communications
require that each receiver be able to authenticate the source of any
packet it receives as well as the integrity of these packets.
This is the case with ALC <xref target="RMT-PI-ALC"/> and
NORM <xref target="RMT-PI-NORM"/>,
two Content Delivery Protocols (CDP) designed to transfer reliably
objects (e.g., files) between a session's sender and several receivers.
The NORM protocol is based on bidirectional transmissions.
Each receiver acknowledges data received or, in case of packet erasures,
asks for retransmissions.
On the opposite, the ALC protocol is based on purely unidirectional transmissions.
Reliability is achieved by means of the cyclic transmission of the content
within a carousel and/or by the use of proactive Forward Error Correction
codes (FEC).
<!--
Being purely unidirectional, ALC is massively scalable, while NORM is
intrinsically limited in terms of the number of receivers that can
be handled in a session.
-->
Both protocols have in common the fact that they operate at application
level, on top of an erasure channel (e.g., the Internet) where packets
can be lost (erased) during the transmission.
</t>

<t>
The goal of this document is to counter attacks where 
an attacker impersonates the ALC or NORM session's sender and injects
forged packets to the receivers, thereby corrupting the objects reconstructed
by the receivers.
</t>

<t>
Preventing this attack is much more complex in case of group communications
than it is with unicast communications.
Indeed, with unicast communications a simple solution exists: the sender
and the receiver share a secret key to compute a Message Authentication
Code (MAC) of all messages exchanged.
This is no longer feasible in case of multicast and broadcast
communications since sharing a group key between the sender and all
receivers implies that any group member can impersonate the sender and send
forged messages to other receivers.
</t>

<t>
The usual solution to provide the source authentication and message
integrity services in case of multicast and broadcast communications
consists in relying on asymmetric cryptography and using digital signatures.
Yet this solution is limited by high computational costs and high
transmission overheads.
The Timed Efficient Stream Loss-tolerant Authentication protocol (TESLA)
is an alternative solution that provides the two required services,
while being compatible with high rate transmissions over lossy channels.
</t>

<t>
This document explains how to integrate the TESLA source authentication and
packet integrity protocol to the ALC and NORM CDP.
Any application built on top of ALC and NORM will directly benefit from the
services offered by TESLA at the transport layer.
In particular, this is the case of FLUTE.
</t>

<t>
For more information on the TESLA protocol and its principles, please refer to
<xref target="RFC4082"/><xref target="Perrig04"/>.
For more information on ALC and NORM, please refer to
<xref target="RMT-PI-ALC"/>, <xref target="RMT-BB-LCT"/>
and <xref target="RMT-PI-NORM"/> respectively.
For more information on FLUTE, please refer to <xref target="RMT-FLUTE"/>.
</t>

<section title="Scope of this Document" anchor="scope">
<!-- =================================== -->

<t>
This specification only considers the authentication and integrity verification
of the packets generated by the session's sender.
This specification does not consider the packets that may be sent by receivers,
for instance NORM's feedback packets.
<xref target="RMT-SIMPLE-AUTH"/> describes several techniques that can be used 
to that purpose.
Since this is usually a low-rate flow (unlike the downstream flow),
using computing intensive techniques like digital signatures, possibly combined
with a Group MAC scheme, is often acceptable.
Finally, the <xref target="sec:alc_norm_integration"/> explains how to use several
authentication schemes in a given session thanks to the ASID (Authentication
Scheme IDentifier) field.
</t>

<t>
This specification relies on several external mechanisms, for instance:
<list style='symbols'> 
	<t>to communicate securely the public key or a certificate for the session's sender
		(<xref target="sec:intro_to_inband_boostrap"/>);</t>
	<t>to communicate securely and confidentially the group key, K_g, used
		by the Group MAC feature, when applicable
		(<xref target="sec:group_auth_tag"/>). In some situations, this
		group key will have to be periodically refreshed;</t>
	<t>to perform secure time synchronization in indirect mode
		(<xref target="sec:intro_to_indirect_time_sync"/>)
		or in direct mode (<xref target="sec:intro_to_direct_time_sync"/>)
		to carry the request/response messages with ALC which is purely
		unidirectional;</t>
</list> 
These mechanisms are required in order to bootstrap TESLA at a sender and
at a receiver and must be deployed in parallel to TESLA.
Besides, the randomness of the Primary Key of the key chain
(<xref target="sec:key_chains"/>) is vital to the security of TESLA.
Therefore the sender needs an appropriate mechanism to generate this random key.
</t>

<t>
<!-- Aurelien: faire une liste avec bullets -->
Several technical details of TESLA, like the most appropriate way to alternate
between the transmission of a key disclosure and a commitment to a new key chain,
or the transmission of a key disclosure and the last key of the previous key chain,
or the disclosure of a key and the compact flavor that does not disclose any key,
are specific to the target use-case (<xref target="sec:key_chains"/>).
For instance, it depends on the number of packets sent per time interval, on
the desired robustness and the acceptable transmission overhead, which can only
be optimized after taking into account the use-case specificities.
</t>


</section>

<section title="Conventions Used in this Document">
<!-- =================================== -->

<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>

<section title="Terminology and Notations">
<!-- =================================== -->

<t>
The following notations and definitions are used throughout this document.
</t>

<section title="Notations and Definitions Related to Cryptographic Functions">
<!-- =================================== -->

<t>
Notations and definitions related to cryptographic functions
<xref target="RFC4082"/><xref target="RFC4383"/>:
<list style='symbols'> 
	<t>PRF is the Pseudo Random Function;</t>
	<t>MAC is the Message Authentication Code;</t>
	<t>HMAC is the keyed-Hash Message Authentication Code;</t>
	<t>F is the one-way function used to create the key chain
		(<xref target="sec:key_chains_principles"/>);</t>
	<t>F' is the one-way function used to derive the HMAC keys
		(<xref target="sec:key_chains_principles"/>);</t>
	<t>n_p is the length, in bits, of the F function's output.
		This is therefore the length of the keys in the key chain;</t>
	<t>n_f is the length, in bits, of the F' function's output.
		This is therefore the length of the HMAC keys;</t>
	<t>n_m is the length, in bits, of the truncated output of the MAC <xref target="RFC2104"/>.
		Only the n_m most significant bits of the MAC output are kept;</t>
	<t>N is the length of a key chain.
		There are N+1 keys in a key chain: K_0, K_1, .. K_N.
		When several chains are used, all the chains MUST have the same length
		and keys are numbered consecutively, following the time interval numbering;</t>
	<t>n_c is the number of keys in a key chain. Therefore: n_c = N+1;</t>
	<t>n_tx_lastkey is the number of additional intervals during which the last key of
		the old key chain SHOULD be sent, after switching to a new key
		chain and after waiting for the disclosure delay d. These extra transmissions
		take place after the interval during which the last key is normally
		disclosed. The n_tx_lastkey value is either 0 (no extra disclosure) or larger.
		This parameter is sender specific and is not communicated to the receiver;</t>
	<t>n_tx_newkcc is the number of intervals during which the commitment to
		a new key chain SHOULD be sent, before switching to the new key chain.
		The n_tx_newkcc value is either 0 (no commitment sent within authentication tags)
		or larger.
		This parameter is sender specific and is not communicated to the receiver;</t>
	<t>K_g is a shared group key, communicated to all group members, confidentially,
		during the TESLA bootstrapping (<xref target="sec:intro_to_bootstrap"/>);</t>
	<t>n_w is the length, in bits, of the truncated output of the MAC of the optional
		group authentication scheme:
		only the n_w most significant bits of the MAC output are kept.
		n_w is typically small, multiple of 32 bits (e.g., 32 bits);</t>
</list></t>
</section>

<section title="Notations and Definitions Related to Time">
<!-- =================================== -->

<t>
Notations and definitions related to time:
<list style='symbols'> 
	<t>i is the time interval index. Interval numbering starts at 0 and
		increases consecutively. Since the interval index is stored as a 32 bit
		unsigned integer, wrapping to 0 might take place in long sessions.</t>
	<t>t_s is the sender local time value at some absolute time (in NTP timestamp format);</t>
	<t>t_r is the receiver local time value at the same absolute time (in NTP timestamp format);</t>
	<t>T_0 is the start time corresponding to the beginning of the session, i.e., the
		beginning of time interval 0 (in NTP timestamp format);</t>
	<t>T_int is the interval duration (in milliseconds);</t>
	<t>d is the key disclosure delay (in number of intervals);</t>
	<t>D_t is the upper bound of the lag of the receiver's clock with respect to
		the clock of the sender;</t>
	<t>S_sr is an estimated bound of the clock drift between the sender and a receiver
		throughout the duration of the session;</t>
	<t>D^O_t is the upper bound of the lag of the sender's clock with respect to
		the time reference in indirect time synchronization mode;</t>
	<t>D^R_t is the upper bound of the lag of the receiver's clock with respect to
		the time reference in indirect time synchronization mode;</t>
	<t>D_err is an upper bound of the time error between all the time references,
		in indirect time synchronization mode;</t>
	<t>NTP timestamp format consists in a 64-bit unsigned fixed-point number,
		in seconds relative to 0h on 1 January 1900. The integer part is in
		the first 32 bits and the fraction part in the last 32 bits
		<xref target="RFC1305"/>;</t>
</list></t>
</section>

</section>

</section><!-- =Introduction= -->


<!-- ======================================================================= -->


<section title="Using TESLA with ALC and NORM: General Operations" anchor="using_tesla_with_cdp"> 
<!-- =================================== -->


<section title="ALC and NORM Specificities that Impact TESLA"
	 anchor="alc_norm_specificities"> 
<!-- =================================== -->

<t>The ALC and NORM protocols have features and requirements that largely impact
the way TESLA can be used.</t>

<t>In case of ALC:
<list style='symbols'> 
	<t>ALC is massively scalable:
	nothing in the protocol specification limits the number of receivers
	that join a session.
	Therefore an ALC session potentially includes a huge number (e.g., millions
	or more) of receivers;
	</t>
	<t>ALC can work on top of purely unidirectional transport channels:
	this is one of the assets of ALC, and examples of unidirectional channels
	include satellite (even if a back channel might exist in some use cases)
	and broadcasting networks like DVB-H/SH;
	</t>
	<t>ALC defines an on-demand content delivery model <xref target="RMT-PI-ALC"/>
	where receivers can arrive at any time, at their own discretion,
	download the content and leave the session.
	Other models (e.g., push or streaming) are also defined;
	</t>
	<t>ALC sessions are potentially very long:
	a session can last several days or months during which the
	content is continuously transmitted within a carousel.
	The content can be either static (e.g., a software update) or
	dynamic (e.g., a web site).</t>
</list>
Depending on the use case, some of the above features may not apply.
For instance ALC can also be used over a bidirectional channel or
with a limited number of receivers.
</t>

<t>In case of NORM:
<list style='symbols'>
	<t>NORM has been designed for medium size sessions:
	indeed, NORM relies on feedback messages and the sender
	may collapse if the feedback message rate is too high;
	</t>
	<t>NORM requires a bidirectional transport channel:
	the back channel is not necessarily a high data rate channel since
	the control traffic sent over it by a single receiver is an order
	of magnitude lower than the downstream traffic.
	Networks with an asymmetric connectivity (e.g., a high rate satellite
	downlink and a low-rate RTC based return channel) are appropriate;
	</t>
</list>
</t>

</section>


<section title="Bootstrapping TESLA" anchor="sec:intro_to_bootstrap">
<!-- =================================== -->

<t>
In order to initialize the TESLA component at a receiver, the sender MUST
communicate some key information in a secure way, so that the receiver can check
the source of the information and its integrity.
Two general methods are possible:
<list style='symbols'>
<t>	by using an out-of-band mechanism, or
	</t>
<t>	by using an in-band mechanism.
	</t>
</list>
The current specification does not recommend any mechanism to bootstrap
TESLA. Choosing between an in-band and out-of-band scheme is left to
the implementer, depending on the target use-case.
However, it is RECOMMENDED that TESLA implementations support the use of
the in-band mechanism for interoperability purposes.</t>

<section title="Bootstrapping TESLA with an Out-Of-Band Mechanism">
<!-- =================================== -->

<t>
For instance <xref target="RFC4442"/> describes the use of the MIKEY 
(Multimedia Internet Keying) protocol to bootstrap TESLA.
As a side effect, MIKEY also provides a loose time synchronization
feature, that TESLA can benefit.
Other solutions, for instance based on an extended session description,
are possible, on condition these solutions provide the required security
level.
</t>
</section>

<section title="Bootstrapping TESLA with an In-Band Mechanism" anchor="sec:intro_to_inband_boostrap">
<!-- =================================== -->

<t>
This specification describes an in-band mechanism.
In some use-cases, it might be desired that bootstrap take place
without requiring the use of an additional external mechanism.
For instance each device may feature a clock with a known time-drift
that is negligible in front of the time accuracy required by TESLA,
and each device may embed the public key of the sender.
It is also possible that the use-case does not feature a bidirectional
channel which prevents the use of out-of-band protocols like MIKEY.
For these two examples, the exchange of a bootstrap information message
(described in <xref target="sec:bootstrap_info_format"/>) and the knowledge
of a few additional parameters (listed below) are sufficient to bootstrap
TESLA at a receiver.
</t>

<t>
Some parameters cannot be communicated in-band.
In particular:
<list style='symbols'>
<t>	the sender or group controller MUST either communicate the public key of the sender or a certificate
	(which also means that a PKI has been setup) to all receivers, so that
	each receiver be able to verify the signature of the bootstrap message and direct time
	synchronization response messages (when applicable).
<!--
	As a side effect, the receivers also know the key length
	and the signature length, the two parameters being equal.
-->
	</t>
<t>	when time synchronization is performed with NTP/SNTP,
	the sender or group controller MUST communicate the list of valid
	NTP/SNTP servers to all the session members (sender included), so that
	they all be able to synchronize themselves on
	the same NTP/SNTP servers.</t>
<t>	when the Group MAC feature is used,
	the sender or group controller MUST communicate the K_g group key to
	all the session members (sender included).
	This group key may be periodically refreshed.</t>
</list>
The way these parameters are communicated is out of the scope of this document.
</t>
</section>

</section>


<section title="Setting Up a Secure Time Synchronization"
	anchor="sec:need_for_time_sync">
<!-- =================================== -->

<t>
The security offered by TESLA heavily relies on time.
Therefore the session's sender and each receiver need to be time synchronized
in a secure way.
To that purpose, two general methods exist:
<list style='symbols'> 
	<t>direct time synchronization, and</t>
	<t>indirect time synchronization.</t>
</list>
It is also possible that a given session include receivers that use the direct
time synchronization mode while others use the indirect time synchronization mode.
</t>


<section title="Direct Time Synchronization" anchor="sec:intro_to_direct_time_sync">
<!-- =================================== -->

<t>
When direct time synchronization is used, each receiver asks the sender for
a time synchronization. To that purpose, a receiver sends a "Direct Time Synchronization
Request" (<xref target="sec:direct_synch_request_format" />).
The sender then directly answers to each request with a "Direct Time Synchronization
Response" (<xref target="sec:direct_synch_response_format" />), signing this reply.
Upon receiving this response, a receiver first verifies the signature, and then calculates
an upper bound of the lag of his clock with respect to the clock of the sender, D_t.
The details on how to calculate D_t are given in <xref target="sec:delay_bound_calc_direct_sync"/>.
</t>

<t>
This synchronization method is both simple and secure.
Yet there are two potential issues:
<list style='symbols'>
	<t>a bidirectional channel must exist between the sender and each receiver, and</t>
	<t>the sender may collapse if the incoming request rate is too high.</t>
</list>
</t>
<t>
Relying on direct time synchronization is not expected to be an issue with NORM since
(1) bidirectional communications already take place, and (2) NORM scalability is anyway limited.
Yet it can be required that a mechanism, that is out of the scope of this document, be used
to spread the transmission of "Direct time synchronization request" messages over the
time if there is a risk that the sender may collapse.
</t>

<t>
But direct time synchronization is potentially incompatible with ALC since (1) there
might not be a back channel and (2) there are potentially
a huge number of receivers and therefore a risk that the sender collapses.
</t>
</section>


<section title="Indirect Time Synchronization"
	anchor="sec:intro_to_indirect_time_sync">
<!-- =================================== -->

<t>
When indirect time synchronization is used, the sender and each receiver must
synchronize securely via an external time reference.
Several possibilities exist:
<list style='symbols'> 
	<t>sender and receivers can synchronize through a NTPv3
	(Network Time Protocol version 3) <xref target="RFC1305"/>
	hierarchy of servers.
	The authentication mechanism of NTPv3 MUST be used in order
	to authenticate each NTP message individually. It prevents
	for instance an attacker to impersonate a NTP server;</t>
	<t>they can synchronize through a NTPv4
	(Network Time Protocol version 4) <xref target="NTP-NTPv4"/>
	hierarchy of servers.
	The Autokey security protocol of NTPv4 MUST be used in order
	to authenticate each NTP message individually;</t>
	<t>they can synchronize through a SNTPv4
	(Simple Network Time Protocol version 4) <xref target="RFC4330"/>
	hierarchy of servers.
	The authentication features of SNTPv4 must then be used.
	Note that TESLA only needs a loose (but secure) time
	synchronization, which is in line with the time synchronization
	service offered by SNTP;</t>
	<t>they can synchronize through a GPS or Galileo (or similar) device
	that also provides a high precision time reference.
	Spoofing attacks on the GPS system have recently been reported.
	Depending on the use case, the security achieved will be or not
	acceptable;</t>
	<t>they can synchronize thanks to a dedicated hardware,
	embedded on each sender and receiver, that provides a clock
	with a time-drift that is negligible in front of the TESLA time
	accuracy requirements. This feature enables a device to synchronize
	its embedded clock with the official time reference from time to
	time (in an extreme case once, at manufacturing time),
	and then to remain autonomous for a duration that depends on the
	known maximum clock drift.</t>
</list>
A bidirectional channel is required by the NTP/SNTP schemes.
On the opposite, with the GPS/Galileo and high precision clock schemes,
no such assumption is made.
In situations where ALC is used on purely unidirectional transport
channels (<xref target="alc_norm_specificities"/>), using the NTP/SNTP
schemes is not possible.
Another aspect is the scalability requirement of ALC, and to a lesser
extent of NORM. 
>From this point of view, the above mechanisms usually do not raise any
problem, unlike the direct time synchronization schemes.
Therefore, using indirect time synchronization can be a good choice.
It should be noted that the NTP/SNTP schemes assume that each client trusts
the sender and accepts to align its NTP/SNTP configuration to that of the
sender. If this assumption does not hold, the sender SHOULD offer an
alternative solution.
</t>


<t>
The details on how to calculate an upper bound of the lag of a receiver's
clock with respect to the clock of the sender, D_t, are given in
<xref target="sec:delay_bound_calc_indirect_sync"/>.
</t>

<!--
<t>
In any case, this document does not explain in details how to achieve
time synchronization, whether it follows a direct or indirect scheme.
The document only provides general guidelines.
The details are outside the scope of this document.
</t>
-->
</section>

</section><!-- -The Need for Secure Time Synchronization- -->


<section title="Determining the Delay Bounds" anchor="delay_bound"> 
<!-- =================================== -->

<t>
Let us assume that a secure time synchronization has been set up.
This section explains how to define the various timing parameters that
are used during the authentication of received packets.
</t>


<section title="Delay Bound Calculation in Direct Time Synchronization Mode"
	anchor="sec:delay_bound_calc_direct_sync">
<!-- =================================== -->

<t>
In direct time synchronization mode, synchronization between a receiver and the
sender follows the following protocol <xref target="RFC4082"/>:
<list style='symbols'>
	<t> The receiver sends a "Direct Time Synchronization Request" message to the sender,
	that includes t_r, the receiver local time at the moment of sending
	(<xref target="sec:direct_synch_request_format" />).</t>

	<t> Upon receipt of this message, the sender records its local time, t_s,
	and sends to the receiver a "Direct Time Synchronization Response" that includes
	t_r (taken from the request) and t_s (<xref target="sec:direct_synch_response_format" />),
	signing this reply.</t>

	<t> Upon receiving this response, the receiver first verifies that he actually
	sent a request with t_r and then checks the signature.
	Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an estimated bound of the
	clock drift between the sender and the receiver throughout the duration of the
	session.
	This document does not specify how S_sr is estimated.
	</t>
</list>
After this initial synchronization, at any point throughout the session, the receiver
knows that: T_s &lt; T_r + D_t, where T_s is the current time at the sender and T_r is
the current time at the receiver.
</t>
</section>


<section title="Delay Bound Calculation in Indirect time Synchronization Mode"
	anchor="sec:delay_bound_calc_indirect_sync">
<!-- =================================== -->

<t>
In indirect time synchronization, the sender and the receivers must synchronize
indirectly with one or several time references.
</t>

<section title="Single time reference">
<!-- =================================== -->

<t>
Let us assume that there is a single time reference.
<list style='numbers'>
	<t> The sender calculates D^O_t, the upper bound of the lag of the sender's clock with respect
        to the time reference.
	This D^O_t value is then be communicated to the receivers
	(<xref target="sec:bootstrap_info"/>).</t>

	<t> Similarly, a receiver R calculates D^R_t, the upper bound of the lag of
	the receiver's clock with respect to the time reference.</t>

	<t> Then, for receiver R, the overall upper bound of the lag of the receiver's clock
	with respect to the clock of the sender, D_t, is the sum:
		D_t = D^O_t + D^R_t.</t>
</list>
The D^O_t and D^R_t calculation depends on the time synchronization mechanism
used (<xref target="sec:intro_to_indirect_time_sync"/>).
In some cases, the synchronization scheme specifications provide these values.
In other cases, these parameters can be calculated by means of a scheme similar to
the one specified in <xref target="sec:delay_bound_calc_direct_sync"/>, for instance
when synchronization is achieved via a group controller <xref target="RFC4082"/>.
</t>
</section>


<section title="Multiple time references">
<!-- =================================== -->

<t>
Let us now assume that there are several time references (e.g., several NTP/SNTP servers).
The sender and receivers use the direct time synchronization scheme to synchronize
with the various time references.
It results in D^O_t and D^R_t.
Let D_err be an upper bound of the time error between all the time references.
Then, the overall value of D_t within receiver R is set to the sum:
	D_t = D^O_t + D^R_t + D_err.
</t>

<t>
In some cases, the D_t value is part of the time synchronization scheme specifications.
For instance NTPv3 <xref target="RFC1305"/> defines algorithms that are
"capable of accuracies in the order of a millisecond, even after extended
periods when synchronization to primary reference sources has been lost".
In practice, depending on the NTP server stratum, the accuracy might be a little bit
worse.
In that case, D_t = security_factor * (1ms + 1ms), where the security_factor is
meant to compensate several sources of inaccuracy in NTP.
The choice of the security_factor value is left to the implementer, depending on
the target use-case.
</t>
</section>

</section>
</section>

<section title="Cryptographic parameter values" anchor="sec:crypto_param_values">
<!-- ==================================== -->

<t>
The F (resp. F') function output length is given by the n_p (resp. n_f) parameter.
The n_p and n_f values depend on the PRF function chosen, as specified below:
</t>
<texttable>
   <preamble></preamble>
   <ttcol align='center'>PRF name</ttcol>
   <ttcol align='center'>n_p and n_f</ttcol>
   <c>HMAC-SHA-1</c>		<c>160 bits (20 bytes)</c>
   <c>HMAC-SHA-224</c>		<c>224 bits (28 bytes)</c>
   <c>HMAC-SHA-256 (default)</c><c>256 bits (32 bytes)</c>
   <c>HMAC-SHA-384</c>		<c>384 bits (48 bytes)</c>
   <c>HMAC-SHA-512</c>		<c>512 bits (64 bytes)</c>
</texttable>

<t>
The computing of regular MAC (resp. Group MAC) makes use of the n_m (resp. n_w) parameter,
i.e., the length of the truncated output of the function.
The n_m and n_w values depend on the MAC function chosen, as specified below:
</t>
<texttable>
   <preamble></preamble>
   <ttcol align='center'>MAC name</ttcol>
   <ttcol align='center'>n_m (regular MAC)</ttcol>
   <ttcol align='center'>n_w (Group MAC)</ttcol>
   <c>HMAC-SHA-1</c>		<c>80 bits (10 bytes)</c> <c>32 bits (4 bytes)</c>
   <c>HMAC-SHA-224</c>		<c>112 bits (14 bytes)</c> <c>32 bits (4 bytes)</c>
   <c>HMAC-SHA-256 (default)</c><c>128 bits (16 bytes)</c> <c>32 bits (4 bytes)</c>
   <c>HMAC-SHA-384</c>		<c>192 bits (24 bytes)</c> <c>32 bits (4 bytes)</c>
   <c>HMAC-SHA-512</c>		<c>256 bits (32 bytes)</c> <c>32 bits (4 bytes)</c>
</texttable>

</section>


</section><!-- -Time Synchronization and Delay Bound Calculations- -->


<!-- ======================================================================= -->


<section title="Sender Operations">
<!-- ==================================== -->

<t>
This section describes the TESLA operations at a sender.
</t>


<section title="TESLA Parameters">
<!-- =================================== -->

<section title="Time Intervals" anchor="sec:time_intervals">
<!-- =================================== -->

<t>
The sender divides the time into uniform intervals of duration T_int.
Time interval numbering starts at 0 and is incremented consecutively.
The interval index MUST be stored in an unsigned 32 bit integer
so that wrapping to 0 takes place only after 2^^32 intervals.
For instance, if T_int is equal to 0.5 seconds, then wrapping takes place
after approximately 68 years.
</t>

</section>


<section title="Key Chains" anchor="sec:key_chains">
<!-- =================================== -->

<section title="Principles" anchor="sec:key_chains_principles">
<!-- =================================== -->

<t>
The sender computes a one-way key chain of n_c = N+1 keys, and assigns
one key from the chain to each interval, consecutively but in reverse order.
Key numbering starts at 0 and is incremented consecutively, following the
time interval numbering: K_0, K_1 .. K_N.
</t>

<t>
In order to compute this chain, the sender must first select a Primary Key,
K_N, and a PRF function, f (<xref target="sec:iana"/>, TESLA-PRF).
The randomness of the Primary Key, K_N, is vital to the security and no one
should be able to guess it.
</t>

<t>
The function F is a one-way function that is defined as:
F(k) = f_k(0), where f_k(0) is the result of the application
of the PRF f to k and 0.
When f is a HMAC (<xref target="sec:iana"/>),
k is used as the key, and 0 as the message, using the algorithm described in
<xref target="RFC2104"/>.
Similarly, the function F' is a one-way function that is defined as:
F'(k) = f_k(1), where f_k(1) is the result of the application
of the same PRF f to k and 1.
</t>

<t>
The sender then computes all the keys of the chain, recursively, starting with K_N,
using: K_{i-1} = F(K_i).
Therefore: K_i = F^{N-i}(K_N), where F^i(x) is the execution of function F with
the argument x, i times.
The receiver can then compute any value in the key chain from K_N,
even if it does not have intermediate values <xref target="RFC4082"/>.
The key for MAC calculation can then be derived from the corresponding K_i
key by K'_i = F'(K_i).
</t>

<t>The key chain has a finite length, N, which corresponds to a maximum time
duration of (N + 1) * T_int.
The content delivery session has a duration T_delivery, which may either be
known in advance, or not.
A first solution consists in having a single key chain of an appropriate
length, so that the content delivery session finishes before the end of the key chain,
i.e., T_delivery &le; (N + 1) * T_int.
But the longer the key chain, the higher the memory and computation required
to cope with it.
Another solution consists in switching to a new key chain, of the same length,
when necessary <xref target="Perrig04"/>.
</t>

</section>


<section title="Using Multiple Key Chains">
<!-- =================================== -->

<t>
When several key chains are needed, all of them MUST be of the same length.
Switching from the current key chain to the next one requires that a commitment
to the new key chain be communicated in a secure way to the receiver.
This can be done by using either an out-of-band mechanism, or an in-band
mechanism.
This document only specifies the in-band mechanism.
</t>

<t>
<figure anchor='fig:key_chain_switch' title="Switching to the second key chain
with the in-band mechanism, assuming that d=2, n_tx_newkcc=3, n_tx_lastkey=3.">
      <preamble></preamble>
      <artwork>
< -------- old key chain --------- >||< -------- new key chain --...
+-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
   0     1    ..   N-2   N-1    N   ||  N+1   N+2   N+3   N+4   N+5  
                                    ||                               
Key disclosures:                    ||                               
  N/A   N/A   ..  K_N-4 K_N-3 K_N-2 || K_N-1  K_N  K_N+1 K_N+2 K_N+3 
                 |                  ||            |                 |
                 |< -------------- >||            |< ------------- >|
Additional key        F(K_N+1)      ||                   K_N
disclosures        (commitment to   ||              (last key of the
(in parallel):      the new chain)  ||                 old chain)
      </artwork>
</figure>
</t>

<t>
<xref target="fig:key_chain_switch"/> illustrates the switch to the
new key chain, using the in-band mechanism.
Let us say that the old key chain stops at K_N and the new key chain
starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two different keys).
Then the sender includes the commitment F(K_{N+1}) to the new key chain
into packets authenticated with the old key chain
(see <xref target='sec:auth_tag_format_new_kcc'/>).
This commitment SHOULD be sent during n_tx_newkcc time intervals before the end
of the old key chain.
Since several packets are usually sent during an interval, the sender
SHOULD alternate between sending a disclosed key of the old key chain
and the commitment to the new key chain.
The details of how to alternate between the disclosure and commitment
are out of the scope of this document.
</t>

<t>The receiver will keep the commitment until the key K_{N+1} is disclosed,
at interval N+1+d.
Then the receiver will be able to test the validity of that key by computing
F(K_{N+1}) and comparing it to the commitment.</t>

<t>When the key chain is changed, it becomes impossible to recover a previous
key from the old key chain.
This is a problem if the receiver lost the packets disclosing the last key of
the old key chain.
A solution consists in re-sending the last key, K_N, of the old key chain
(see <xref target='sec:auth_tag_format_old_kck'/>). 
This SHOULD be done during n_tx_lastkey additional time intervals after the
end of the time interval where K_N is disclosed.
Since several packets are usually sent during an interval, the sender
SHOULD alternate between sending a disclosed key of the new key chain,
and the last key of the old key chain.
The details of how to alternate between the two disclosures
are out of the scope of this document.
</t>

<t>
In some cases a receiver having experienced a very long disconnection might
have lost the commitment of the new chain.
Therefore this receiver will not be able to authenticate any packet related to
the new chain and all the following ones.
The only solution for this receiver to catch up consists in receiving an additional
bootstrap information message.
This can happen by waiting for the next periodic transmission (if sent in-band)
or through an external mechanism (<xref target="sec:bootstrap_info"/>).
</t>
</section>


<section title="Values of the n_tx_lastkey and n_tx_newkcc Parameters"
	anchor="sec:value_of_tx_lastkey_tx_newkcc">
<!-- =================================== -->

<t>
When several key chains and the in-band commitment mechanism are used,
a sender MUST initialize the n_tx_lastkey
and n_tx_newkcc parameters in such a way that no overlapping occur.
In other words, once a sender starts transmitting commitments for a new
key chain, he MUST NOT send a disclosure for the last key of the old
key chain any more.
Therefore, the following property MUST be verified:
	<list style="empty">
	<t>d + n_tx_lastkey + n_tx_newkcc &le; N + 1</t>
	</list>
</t>

<t>
It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey has
been chosen, then:
	<list style="empty">
	<t>n_tx_newkcc = N + 1 - n_tx_lastkey - d</t>
	</list>
In other words, the sender starts transmitting a commitment to the following
key chain immediately after having sent all the disclosures of the last
key of the previous key chain.
Doing so increases the probability that a receiver gets a commitment for
the following key chain.
</t>

<t>
In any case, these two parameters are sender specific and need not be
transmitted to the receivers.
Of course, as explained above, the sender alternates between the disclosure
of a key of the current key chain and the commitment to the new key chain
(or the last key of the old key chain).
</t>
</section>


<section title="The Particular Case of the Session Start">
<!-- =================================== -->

<t>
Since a key cannot be disclosed before the disclosure delay, d, no key will
be disclosed during the first d time intervals (intervals 0 and 1 in
<xref target="fig:key_chain_switch"/>) of the session.
To that purpose, the sender uses the Authentication Tag Without Key Disclosure
<xref target="sec:auth_tag_wo_key_discl_format"/>.
The following key chains, if any, are not concerned since they will
disclose the last d keys of the previous chain.
</t>
</section>


<section title="Managing Silent Periods">
<!-- =================================== -->

<t>
An ALC or NORM sender may stop transmitting packets for some time.
For instance it can be the end of the session and all packets have already been sent,
or the use-case may consist in a succession of busy periods (when fresh
objects are available) followed by silent periods.
In any case, this is an issue since the authentication of the packets
sent during the last d intervals requires that the associated keys be
disclosed, which will take place during d additional time intervals.
</t>

<t>
To solve this problem, it is recommended that the sender transmit empty
packets (i.e., without payload) containing the TESLA EXT_AUTH header
extension along with a Standard Authentication Tag during at
least d time intervals after the end of the regular ALC or NORM packet transmissions.
The number of such packets and the duration during which they are sent
must be sufficient for all receivers to receive, with a high probability,
at least one packet disclosing the last useful key (i.e., the key used for
the last non-empty packet sent).
</t>
</section>

</section>


<section title="Time Interval Schedule" anchor="sec:time_int_schedule">
<!-- =================================== -->

<t>
The sender must determine the following parameters:
<list style='symbols'>
	<t>T_0, the start time corresponding to the beginning of the session, i.e., the
		beginning of time interval 0 (in NTP timestamp format);</t>
	<t>T_int, the interval duration (in milliseconds), usually ranging from 100 milliseconds to 1 
		second;</t> 
	<t>d, the key disclosure delay (in number of intervals). It is the time to wait
		before disclosing a key;</t>
	<t>N, the length of a key chain;</t>
</list></t>

<t>
The correct choice of T_int, d, and N is crucial for the efficiency of the scheme.
For instance, a T_int * d product that is too long will cause excessive delay in the
authentication process. 
A T_int * d product that is too short prevents many receivers from verifying packets.
A N * T_int product that is too small will cause the sender to switch too often to
new key chains.
A N that is too long with respect to the expected session duration (if known)
will require the sender to compute too many useless keys.
<xref target="RFC4082"/> sections 3.2 and 3.6 give general guidelines for
initializing these parameters.
</t>

<t>
The T_0, T_int, d and N parameters MUST NOT be changed during the lifetime of the session.
This restriction is meant to prevent introducing vulnerabilities.
For instance if a sender was authorized to change the key disclosure schedule, a receiver that did
not receive the change notification would still believe in the old key disclosure schedule,
thereby creating vulnerabilities <xref target="RFC4082"/>.
</t>

</section>

<section title="Timing Parameters" anchor="sec:timing_params">
<!-- =================================== -->

<t>
In indirect time synchronization mode, 
the sender must determine the following parameter:
<list style='symbols'>
	<t> D^O_t, the upper bound of the lag of the sender's clock with respect
	to the time reference.</t>
</list>
The D^O_t parameter MUST NOT be changed during the lifetime of the session.
</t>

</section>


</section><!-- TESLA Parameters -->


<section title="TESLA Signaling Messages">
<!-- =================================== -->

<t>
At a sender, TESLA produces two types of signaling information:
<list style='symbols'> 
<t>The bootstrap information:
	it can be either sent out-of-band or in-band.
	In the latter case, a digitally signed packet contains all the 
	information required to bootstrap TESLA at a receiver;</t>
<t>The direct time synchronization response, which enables a receiver to finish a
	direct time synchronization;</t>
</list>
</t>


<section title="Bootstrap Information" anchor="sec:bootstrap_info">
<!-- =================================== -->

<t>
In order to initialize the TESLA component at a receiver, the sender must
communicate some key information in a secure way.
This information can be sent in-band or out-of-band, as discussed in
<xref target="sec:intro_to_bootstrap"/>.
In this section we only consider the in-band scheme.
</t>


<t>
The TESLA bootstrap information message MUST be digitally signed
(<xref target="sec:rsa_signatures"/>).
The goal is to enable a receiver to check the packet source and packet integrity.
Then, the bootstrap information can be:
<list style='symbols'>
<t> unicast to a receiver during a direct time synchronization request/response exchange;</t>
<t> broadcast to all receivers.
	This is typically the case in indirect time synchronization mode.
	It can also be used in direct time synchronization mode, for instance
	when a large number of clients arrive at the same time, in which case
	it is more efficient to answer globally.</t>
</list>
</t>

<t>
Let us consider situations where the bootstrap information is broadcast.
This message should be broadcast at the beginning of the session, before
data packets are actually sent.
This is particularly important with ALC or NORM sessions in "push" mode,
when all clients join the session in advance.
For improved reliability, bootstrap information might be sent a certain
number of times.
</t>

<t>
A periodic broadcast of the bootstrap information message
could also be useful when:
<list style='symbols'>
<t>the ALC session uses an "on-demand" mode, clients arriving at their own
	discretion;</t>
<t>some clients experience an intermittent connectivity.
	This is particularly important when several key chains are used in an
	ALC or NORM session, since there is a risk that a receiver
	loses all the commitments to the new key chain.</t>
</list>
A balance must be found between the signaling overhead and the maximum initial
waiting time at the receiver before starting the delayed authentication process.
A period of a few seconds for the transmission of this bootstrap information
is often a reasonable value.
</t>


</section>


<section title="Direct Time Synchronization Response" anchor="sec:direct_synch_response">
<!-- =================================== -->

<t>
In Direct Time Synchronization, upon receipt of a synchronization request, the sender
records its local time, t_s, and sends a response message that contains both t_r and t_s
(<xref target="sec:delay_bound_calc_direct_sync"/>).
This message is unicast to the receiver.
This Direct Time Synchronization Response message MUST be digitally signed in order to
enable a receiver to check the packet source and packet integrity
(<xref target="sec:rsa_signatures"/>).
The receiver MUST also be able to associate this response and his request, which
is the reason why t_r is included in the response message.
</t>

</section>


</section> <!-- TESLA Messages -->


<section title="TESLA Authentication Information">
<!-- =================================== -->

<t>
At a sender, TESLA produces three types of security tags:
<list style='symbols'> 
<t>an authentication tag, in case of data packets, and which contains
	the MAC of the packet;</t>
<t>a digital signature, in case of one of the two TESLA signaling packets,
	namely a Bootstrap Information Message or a Direct Time Synchronization
	Response; and</t>
<t>an optional group authentication tag, that can be added
	to all the packets to mitigate attacks coming from outside
	of the group.</t>
</list>
</t>

<t>
Because of interdependencies, their computation MUST follow a strict
order:
<list style='symbols'> 
<t>first of all, compute the authentication tag (with data packet) or the
	digital signature (with signaling packet);</t>
<t>finally compute the Group Mac;</t>
</list>
</t>


<section title="Authentication Tags" anchor="sec:auth_tag">
<!-- =================================== -->

<t>
All the data packets sent MUST have an authentication tag containing:
<list style='symbols'>
    <t> the interval index, i, which is also the index of the key
	used for computing the MAC of this packet;</t>
<!--
	With the compact authentication tags, a subset of i will
	be communicated.
	In that case, a receiver must guess the original i value
	from the few bits carried in the packet
	(<xref target="sec:auth_received_pkts_guidelines"/>);</t>
-->
    <t> the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);</t>
    <t> either a disclosed key (that belongs to the current key chain or the
	previous key chain), or a commitment to a new key chain,
	or no key at all;</t>
</list>
</t>

<t>
The computation of MAC(K'_i, M) MUST include the ALC or NORM header (with the
various header extensions) and the payload (when applicable).
The UDP/IP headers MUST NOT be included.
During this computation, the MAC(K'_i, M) field of the authentication tag 
MUST be set to 0.
</t>

</section>


<section title="Digital Signatures"
	anchor="sec:rsa_signatures">
<!-- =================================== -->

<t>
The Bootstrap Information message (with the in-band bootstrap scheme)
and Direct Time Synchronization Response message (with the indirect time
synchronization scheme) both need to be signed by the sender.
These two messages contain a "Signature" field to hold the digital signature.
The bootstrap information message also contains the "Signature Encoding Algorithm",
the "Signature Cryptographic Function", and the "Signature Length" fields that
enable a receiver to process the "Signature" field.
Note that there is no such "Signature Encoding Algorithm", "Signature Cryptographic Function" and
"Signature Length" fields in case of a Direct Time Synchronization Response
message since it is assumed that these parameters are already known
(i.e., the receiver either received a bootstrap information message before,
or these values have been communicated out-of-band).
</t>

<t>
Several "Signature Encoding Algorithms" can be used, including
RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (<xref target="sec:iana"/>).
With these encodings, SHA-256 is the default "Signature Cryptographic Function".
</t>

<t>
The computation of the signature MUST include the ALC or NORM header (with the
various header extensions) and the payload when applicable.
The UDP/IP headers MUST NOT be included.
During this computation, the "Signature" field MUST be set to 0 as well as
the optional Group MAC, when present, since this Group MAC is calculated later on.
</t>

<t>
More specifically, from <xref target="RFC4359"/>:
digital signature generation is performed as described in
<xref target="RFC3447"/>, Section 8.2.1 for RSASSA-PKCS1-v1_5 and
Section 8.1.1 for RSASSA-PSS.
The authenticated portion of the packet is used as the message M,
which is passed to the signature generation function.
The signer's RSA private key is passed as K.
In summary (when SHA-256 is used), the signature generation process computes
a SHA-256 hash of the authenticated packet bytes, signs the SHA-256 hash using
the private key, and encodes the result with the specified RSA encoding type.
This process results in a value S, which is the digital signature to
be included in the packet.
</t>

<t>
With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures,
the size of the signature is equal to the "RSA modulus", unless the "RSA modulus"
is not a multiple of 8 bits. In that case, the signature MUST be prepended with
between 1 and 7 bits set to zero such that the signature is a multiple of 8 bits
<xref target="RFC4359"/>.
The key size, which in practice is also equal to the "RSA modulus", has major security
implications.
<xref target="RFC4359"/> explains how to choose this value depending on the maximum
expected lifetime of the session.
This choice is out of the scope of this document.
</t>


</section>


<section title="Group MAC Tags" anchor="sec:group_auth_tag">
<!-- =================================== -->

<t>
An optional Group MAC can be used to mitigate DoS attacks coming from attackers
that are not group members <xref target="RFC4082"/>. 
This feature assumes that a group key, K_g, is shared by the sender and all receivers.
When the attacker is not a group member, the benefits of adding a group MAC to every
packet sent are threefold:
<list style='symbols'>
	<t> a receiver can immediately drop faked packets, without
	having to wait for the disclosure delay, d;
	</t>
	<t> a sender can immediately drop faked direct time synchronization requests,
	and avoid to check the digital signature, a computation intensive task;
	</t>
	<t> a receiver can immediately drop faked direct time synchronization response
	and bootstrap messages, without having to verify the digital signature, a computation
	intensive task;
	</t>
</list>
</t>

<t>
The computation of the group MAC, MAC(K_g, M), MUST include the ALC or NORM header
(with the various header extensions) and the payload when applicable.
The UDP/IP headers MUST NOT be included.
During this computation, the Group MAC field MUST be set to 0.
However the digital signature (e.g., of a bootstrap message) and the MAC fields
(e.g., of an authentication tag), when present, MUST have been calculated since 
they are included in the Group MAC calculation itself.
Then the sender truncates the MAC output to keep the n_w most significant bits
and stores the result in the Group MAC field.
</t>

<t>
This scheme features a few limits:
<list style='symbols'>
	<t>it is of no help if a group member (who knows K_g) impersonates
	the sender and sends forged messages to other receivers;</t>
	<t>it requires an additional MAC computing for each packet,
	both at the sender and receiver sides;</t>
	<t>it increases the size of the TESLA authentication headers.
	In order to limit this problem, the length of the truncated output of the
	MAC, n_w, SHOULD be kept small (e.g., 32 bits)
	(see <xref target="RFC3711"/> section 9.5).
	As a side effect, the authentication service is significantly weakened:
	the probability that any forged packet be successfully authenticated
	becomes one in 2^32.
	Since the group MAC check is only a pre-check that must be followed
	by the standard TESLA authentication check, this is not considered to
	be an issue.</t>
</list>
For a given use-case, the benefits brought by the group MAC must be balanced
against these limitations.
</t>

<t>
Note that the Group MAC function can be different from the TESLA MAC function
(e.g., it can use a weaker but faster MAC function).
Note also that the mechanism by which the group key, K_g, is communicated to all
group members, and perhaps periodically updated, is out of the scope of this document.
</t>

</section>


</section> <!-- TESLA Messages -->


<section title="Format of TESLA Messages and Authentication Tags">
<!-- =================================== -->

<t>
This section specifies the format of the various kinds of TESLA messages
and authentication tags sent by the session's sender.
Because these TESLA messages are carried as EXT_AUTH header extensions
of the ALC or NORM packets (<xref target="sec:alc_norm_integration"/>),
the following formats do not start on 32 bit word boundaries.
</t>


<section title="Format of a Bootstrap Information Message" anchor="sec:bootstrap_info_format">
<!-- =================================== -->

<t>
When bootstrap information is sent in-band, the following message is
used:
<figure anchor='fig:bootstrap_info_format' title="Bootstrap information format.">
      <preamble></preamble>
      <artwork>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                +-+-+-+-+-+-+-+-+  ---
                                                | V |resvd|S|G|A|  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|       d       |    PRF Type   | MAC Func Type |Gr MAC Fun Type|  | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | i
|   SigEncAlgo  | SigCryptoFunc |       Signature Length        |  | x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | e
|            Reserved           |             T_int             |  | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  | l
+                  T_0 (NTP timestamp format)                   +  | e
|                                                               |  | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | g
|                      N (Key Chain Length)                     |  | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | h
|                    Current Interval Index i                   |  v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
|                                                               |
~                 Current Key Chain Commitment  +-+-+-+-+-+-+-+-+
|                                               |   Padding     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
~                           Signature                           ~
+                                               +-+-+-+-+-+-+-+-+
|                                               |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|                                                             |
+-+       D^O_t Extension (optional, present if A==1)           +
|    (NTP timestamp diff, positive if P==1, negative if P==0)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      Group MAC (optional)                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
The format of the bootstrap information is depicted in
<xref target="fig:bootstrap_info_format"/>.
The fields are:</t>

<t>"V" (Version) field (2 bits):</t>
<t><list><t>
	The "V" field contains the version number of the protocol.
	For this specification, the value of 0 MUST be used.
</t></list></t>

<t>"Reserved" field (3 bits):</t>
<t><list><t>
	This is a reserved field that MUST be set to zero in this specification.
</t></list></t>

<t>"S" (Single Key Chain) flag (1 bits):</t>
<t><list><t>
	The "S" flag indicates whether this TESLA session is restricted to a single
	key chain (S==1) or relies on one or multiple key chains (S==0).
</t></list></t>

<t>"G" (Group MAC Present) flag (1 bits):</t>
<t><list><t>
	The "G" flag indicates whether the Group MAC feature is used
	(G==1) or not (G==0). When it is used, a "Group MAC" field
	is added to all the packets containing a  TESLA EXT_AUTH Header Extension
	(including this bootstrap message).
</t></list></t>

<t>"A" flag (1 bit):</t>
<t><list><t>
	The "A" flag indicates whether the P flag and D^O_t fields are present
	(A==1) or not (A==0).
	In indirect time synchronization mode, A MUST be equal to 1 since these
	fields are needed.
</t></list></t>

<!--
<t>"Sequence Number" field (8 bits):</t>
<t><list><t>
	The "Sequence Number" is incremented by the sender each time a new bootstrap
	information is sent, and reset by the sender each time a new "i" value is used.
	Since wrapping is prohibited, there can be a maximum of 256 bootstrap messages
	sent for a given "i" value.
	The Tuple (sequence number; i) is meant to protect the receiver against replay
	attacks, where the attacker stores a valid bootstrap information message and
	replays it after a certain delay.
</t></list></t>
-->

<t>"d" field (8 bits):</t>
<t><list><t>
	d is an unsigned integer that defines the key disclosure delay (in number of intervals).
	d MUST be greater or equal to 2.
</t></list></t>

<t>"PRF Type" field (8 bits):</t>
<t><list><t>
	The "PRF Type" is the reference number of the f function used to derive
        the F (for key chain) and F' (for MAC keys) functions (<xref target="sec:iana"/>).
</t></list></t>

<t>"MAC Function Type" field (8 bits):</t>
<t><list><t>
	The "MAC Function Type" is the reference number of the function used to compute
	the MAC of the packets (<xref target="sec:iana"/>).
</t></list></t>

<t>"Group MAC Function Type" field (8 bits):</t>
<t><list><t>
	When G==1, this field contains the reference number of the cryptographic MAC function
	used to compute the group MAC (<xref target="sec:iana"/>).
	When G==0, this field MUST be set to zero.
</t></list></t>

<t>"Signature Encoding Algorithm" field (8 bits):</t>
<t><list><t>
	The "Signature Encoding Algorithm" is the reference number (<xref target="sec:iana"/>) of the digital
	signature used to authenticate this bootstrap information and included in the
	"Signature" field.
</t></list></t>

<t>"Signature Cryptographic Function" field (8 bits):</t>
<t><list><t>
	The "Signature Cryptographic Function" is the reference number (<xref target="sec:iana"/>)
	of the cryptographic function used within the digital signature.
</t></list></t>

<t>"Signature Length" field (16 bits):</t>
<t><list><t>
	The "Signature Length" is an unsigned integer that indicates the signature field size in bytes
	in the "Signature Extension" field.
	This is also the signature key length, since both parameters are equal.
</t></list></t>

<t>"Reserved" fields (16 bits):</t>
<t><list><t>
	This is a reserved field that MUST be set to zero in this specification.
</t></list></t>

<t>"T_int" field (16 bits):</t>
<t><list><t>
	T_int is an unsigned 16 bit integer that defines the interval duration (in milliseconds).
</t></list></t>

<t>"T_0" field (64 bits):</t>
<t><list><t>
	"T_0" is a timestamp in NTP timestamp format that indicates the beginning of the session, i.e., the
		beginning of time interval 0.
</t></list></t>

<t>"N" field (32 bits):</t>
<t><list><t>
	"N" is an unsigned integer that indicates the key chain length.
	There are N + 1 keys per chain.
</t></list></t>

<t>"i" (Interval Index of K_i) field (32 bits):</t>
<t><list><t>
	"i" is an unsigned integer that indicates the current interval index
	when this bootstrap information message is sent.
</t></list></t>

<t>"Current Key Chain Commitment" field (variable size, padded if necessary for 32 bit word alignment):</t>
<t><list><t>
	"Key Chain Commitment" is the commitment to the current key chain,
	i.e., the key chain corresponding to interval i.
	For instance, with the first key chain, this commitment is equal to F(K_0),
	with the second key chain, this commitment is equal to F(K_{N+1}), etc.).
	If need be, this field is padded (with 0) up to a multiple of 32 bits.
</t></list></t>

<t>"Signature" field (variable size, padded if necessary for 32 bit word alignment):</t>
<t><list><t>
	The "Signature" field is mandatory.
	It contains a digital signature of this message, as specified by the
	encoding algorithm, cryptographic function and key length parameters.
	If the signature length is not multiple of 32 bits, this field is padded
	with 0.
</t></list></t>

<t>"P" flag (optional, 1 bit if present):</t>
<t><list><t>
	The "P" flag is optional and only present if the A flag is equal to 1..
	It is only used in indirect time synchronization mode.
	This flag indicates whether the D^O_t NTP timestamp difference is positive
	(P==1) or negative (P==0).
</t></list></t>

<t>"D^O_t" field (optional, 63 bits if present):</t>
<t><list><t>
	The "D^O_t" field is optional and only present if the A flag is equal to 1.
	It is only used in indirect time synchronization mode.
	It is the upper bound of the lag of the sender's clock with
	respect to the time reference.
	When several time references are specified (e.g., several NTP servers), then
	D^O_t is the maximum upper bound of the lag with each time reference.
	D^O_t is composed of two unsigned integers, as with NTP timestamps:
	the first 31 bits give the time difference in seconds and the remaining 32 bits
	give the sub-second time difference.
<!--
<list><t> Editor's note: a first alternative would be to use floating
	point arithmetic, IEEE754 for carrying D^O_t.
	NTP timestamp difference is usually performed with double floating
	point arithmetic internally (at least in TESLA and NTPv4 implementations),
	so it makes sense. But it looks a bit awkward.
	A second alternative would be to use a signed integer representing the
	difference in sub-second units (e.g., in milliseconds). This is simple
	but it requires NTP timestamp/ms conversions on both sides.
	The use of the "P" flag seems simpler...
	</t>
</list>
-->
</t></list></t>

<t>"Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
	This field contains the group MAC, calculated with the group key, K_g,
	shared by all group members.
	The field length, in bits, is given by n_w which is known once the
	group MAC function type is known (<xref target="sec:iana"/>).
</t></list></t>

<t>
Note that the first byte and the following seven 32-bit words are mandatory fixed
length fields.
The Current Key Chain Commitment and Signature fields are mandatory but variable length fields.
The remaining D^O_t and Group MAC fields are optional.
</t>

<t>
In order to prevent attacks, some parameters MUST NOT be changed during the lifetime of the session
(<xref target="sec:time_int_schedule"/>, <xref target="sec:timing_params"/>).
The following table summarizes the parameters status:
</t>
       <texttable>
           <preamble></preamble>
           <ttcol align='center' width='35%'>Parameter</ttcol>
           <ttcol align='center'>Status</ttcol>
           <c>V</c><c>set to 0 in this specification</c>
           <c>S</c><c>static (during whole session)</c>
           <c>G</c><c>static (during whole session)</c>
           <c>A</c><c>static (during whole session)</c>
           <c>T_O</c><c>static (during whole session)</c>
           <c>T_int</c><c>static (during whole session)</c>
           <c>d</c><c>static (during whole session)</c>
           <c>N</c><c>static (during whole session)</c>
           <c>D^O_t (if present)</c><c>static (during whole session)</c>
           <c>PRF Type</c><c>static (during whole session)</c>
           <c>MAC Function Type</c><c>static (during whole session)</c>
           <c>Signature Encoding Algorithm</c><c>static (during whole session)</c>
           <c>Signature Crypto. Function</c><c>static (during whole session)</c>
           <c>Signature Length</c><c>static (during whole session)</c>
           <c>Group MAC Func. Type</c><c>static (during whole session)</c>
           <c>i</c><c>dynamic (related to current key chain)</c>
           <c>K_i</c><c>dynamic (related to current key chain)</c>
           <c>signature</c><c>dynamic, packet dependent</c>
           <c>Group MAC (if present)</c><c>dynamic, packet dependent</c>
       </texttable>

</section><!-- -Bootstrap Information Format- -->


<section title="Format of a Direct Time Synchronization Response"
	anchor='sec:direct_synch_response_format'>
<!-- =================================== -->

<t>
<figure anchor='fig:direct_synch_response_format'
	title="Format of a Direct Time Synchronization Response">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |    Reserved   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                     t_s (NTP timestamp)                       +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                     t_r (NTP timestamp)                       +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 ~                           Signature                           ~
 +                                               +-+-+-+-+-+-+-+-+
 |                                               |    Padding    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>The response to a direct time synchronization request contains the following
information:</t>

<t>"Reserved" fields (8 bits):</t>
<t><list><t>
	This is a reserved field that MUST be set to zero in this specification.
</t></list></t>

<t>"t_s" (NTP timestamp, 64 bits):</t>
<t><list><t>
	t_s is a timestamp in NTP timestamp format that corresponds to the sender local time value when receiving
	the direct time synchronization request message.
</t></list></t>

<t>"t_r" (NTP timestamp, 64 bits):</t>
<t><list><t>
	t_r is a timestamp in NTP timestamp format that contains the receiver local time value received
	in the direct time synchronization request message.
</t></list></t>

<t>"Signature" field (variable size, padded if necessary for 32 bit word alignment):</t>
<t><list><t>
	The "Signature" field is mandatory.
	It contains a digital signature of this message, as specified by the
	encoding algorithm, cryptographic function and key length parameters
	communicated in the  bootstrap information message (if applicable) or out-of-band.
	If the signature length is not multiple of 32 bits, this field is padded
	with 0.
</t></list></t>

<t>"Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
	This field contains the Group MAC, calculated with the group key, K_g,
	shared by all group members.
	The field length, in bits, is given by n_w, which is known once the
	group MAC function type is known (<xref target="sec:iana"/>).
</t></list></t>

</section><!-- -Direct Time Synch Response Format- -->


<section title="Format of a Standard Authentication Tag" anchor='sec:auth_tag_format'>
<!-- =================================== -->

<t>
<figure anchor='fig:authentication_tag' title="Format of the  Standard Authentication Tag">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Disclosed Key K_{i-d}                      ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |   Padding     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
<xref target='fig:authentication_tag'/> shows the format of the Standard Authentication Tag:</t>

<t>"Reserved" field (8 bits):</t>
<t><list><t>
 	The "Reserved" field is not used in the current specification
	and MUST be set to zero by the sender.
</t></list></t>

<t>"i" (Interval Index) field (32 bits):</t>
<t><list><t>
	i is the interval index associated to the key (K'_i) used to compute
	the MAC of this packet.
</t></list></t>

<t>"Disclosed Key" (variable size, non padded):</t>
<t><list><t>
	The "Disclosed Key" is the key used for interval i-d: K_{i-d}.
	There is no padding between the "Disclosed Key" and "MAC(K'_i, M)"
	fields, and the latter MAY not start on a 32 bit boundary,
	depending on the n_p parameter.
</t></list></t>

<t>"MAC(K'_i, M)" (variable size, padded if necessary for 32 bit word alignment):</t>
<t><list><t>
	MAC(K'_i, M) is the truncated message authentication code of the current packet.
	Only the n_m most significant bits of the MAC output are kept <xref target="RFC2104"/>.
</t></list></t>

<t>"Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
	This field contains the Group MAC, calculated with a group key, K_g, shared
	by all group members.
	The field length is given by n_w, in bits.
</t></list></t>

<t>
Note that because a key cannot be disclosed before the disclosure delay, d,
the sender MUST NOT use this tag during the first d intervals of the session:
{0 .. d-1} (inclusive).
Instead the sender MUST use an Authentication Tag Without Key Disclosure.
</t>


</section>

<section title="Format of an Authentication Tag Without Key Disclosure"
	anchor='sec:auth_tag_wo_key_discl_format'>
<!-- =================================== -->

<t>
The authentication tag without key disclosure is meant to be used in situations where a
high number of packets are sent in a given time interval.
In such a case, it can be advantageous to disclose the K_{i-d} key only in a subset of the
packets sent, using a Standard Authentication Tag, and use the shortened version that
does not disclose the K_{i-d} key in the remaining packets.
It is left to the implementer to decide how many packets should disclose the K_{i-d}
key.
This Authentication Tag Without Key Disclosure MUST also be used during the first
d intervals: {0 .. d-1} (inclusive).
</t>

<t>
<figure anchor='fig:authentication_tag_wo_key_discl' title="Format of the Authentication Tag Without Key Disclosure">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |   Padding     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

</section>


<section title="Format of an Authentication Tag with a ``New Key Chain'' Commitment"
	anchor='sec:auth_tag_format_new_kcc'>
<!-- =================================== -->
<t>
During the last n_tx_newkcc intervals of the current key chain, the sender
SHOULD send commitments to the next key chain.
This is done by replacing the disclosed key of the 
authentication tag with the new key chain commitment, F(K_{N+1})
(or F(K_{2N+2}) in case of a switch between the second and third key chains, etc.).
<xref target='fig:new_comm_tag'/> shows the corresponding format.
</t>

<t>
Note that since there is no padding between the "F(K_{N+1})" and "MAC(K'_i, M)"
fields, this latter MAY not start on a 32 bit boundary,
depending on the n_p parameter.
</t>

<t>
<figure anchor='fig:new_comm_tag' title="Format of the Authentication Tag with a New
        Key Chain Commitment">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~              New Key Commitment F(K_{N+1})                    ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |   Padding     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>
</section><!-- -New key chain commitment- -->


<section title="Format of an Authentication Tag with a ``Last Key of Old Chain'' Disclosure" 
	anchor='sec:auth_tag_format_old_kck'>
<!-- =================================== -->
<t>
During the first n_tx_lastkey intervals of the new key chain after
the disclosing interval, d, the sender SHOULD disclose the last key
of the old key chain.
This is done by replacing the disclosed key of the 
authentication tag with the last key of the old chain, K_N
(or K_{2N+1} in case of a switch between the second and third key chains, etc.).
<xref target='fig:old_comm_tag'/> shows the corresponding format.
</t>

<t>
Note that since there is no padding between the "K_N" and "MAC(K'_i, M)"
fields, this latter MAY not start on a 32 bit boundary,
depending on the n_p parameter.
</t>

<t>
<figure anchor='fig:old_comm_tag' title="Format of the authentication tag with an old chain
last key disclosure">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                  Last Key of Old Chain, K_N                   ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |   Padding     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>


</section><!-- -Old key chain commitment- -->



</section><!-- -Signaling Information Format- -->


</section><!-- =Sender= -->


<!-- ======================================================================= -->


<section title="Receiver Operations">
<!-- ==================================== -->

<t>
This section describes the TESLA operations at a receiver.
</t>


<section title="Verification of the Authentication Information" anchor="sec:verif_auth_info">
<!-- =================================== -->

<t>
This section details the computation steps required to verify
each of the three possible authentication information of an
incoming packet.
The verification MUST follow a strict order:
<list style='symbols'> 
<t>first of all, if the Group MAC is present and if the session uses this feature
	(e.g., if the G bit is set in the bootstrap information message), then verify
	the Group MAC.
	A packet that does not contain a Group MAC tag whereas the session uses
	this feature MUST be immediately dropped.
	On the opposite, if a packet contains a Group MAC tag whereas the session does
	not use this feature, this tag MUST be ignored;</t>
<t>then verify the digital signature (with TESLA signaling
	packets) or enter the TESLA authentication process
	(with data packets)</t>
</list>
</t>


<section title="Processing the Group MAC Tag" anchor="sec:verif_group_mac">
<!-- =================================== -->

<t>
Upon receiving a packet containing a Group MAC Tag, the receiver
recomputes the Group MAC and compares it to the value carried in the packet.
If the check fails, the packet MUST be immediately dropped.
</t>

<t>
More specifically, recomputing the Group MAC requires to save the
value of the Group MAC field, to set this field to 0, and to do
the same computation as a sender does (see <xref target="sec:group_auth_tag"/>).
</t>


</section>


<section title="Processing the Digital Signature">
<!-- =================================== -->

<t>
Upon receiving a packet containing a digital signature, the receiver
verifies the signature as follows.
</t>

<t>
The computation of the signature MUST include the ALC or NORM header (with the
various header extensions) and the payload when applicable.
The UDP/IP headers MUST NOT be included.
During this computation, the "Signature" field MUST be set to 0 as well as
the optional Group MAC, when present.
</t>

<t>
>From <xref target="RFC4359"/>:
Digital signature verification is performed as described in
<xref target="RFC3447"/>, Section 8.2.2 (RSASSA-PKCS1-v1_5) and
<xref target="RFC3447"/>, Section 8.1.2 (RSASSA-PSS).
Upon receipt, the digital signature is passed to the
verification function as S.
The authenticated portion of the packet is used as the message M,
and the RSA public key is passed as (n, e).
In summary (when SHA-256 is used), the verification function computes a SHA-256
hash of the authenticated packet bytes, decrypts the SHA-256 hash in
the packet, and validates that the appropriate encoding was applied.
<!--and was correct.-->
The two SHA-256 hashes are compared, and if they are identical the
validation is successful.
</t>

<t>
It is assumed that the receivers have the possibility
to retrieve the sender's public key required to check this digital signature
(<xref target="sec:intro_to_bootstrap"/>).
This document does not specify how the public key of the sender is
communicated reliably and in a secure way to all possible receivers.
</t>


</section>


<section title="Processing the Authentication Tag">
<!-- =================================== -->

<t>
When a receiver wants to authenticate a packet using an Authentication Tag and
when he has the key for the associated time interval (i.e., after the disclosing
delay, d), the receiver recomputes the MAC and compares it to the value carried
in the packet.
If the check fails, the packet MUST be immediately dropped.
</t>

<t>
More specifically, recomputing the MAC requires to save the
value of the MAC field, to set this field to 0, and to do
the same computation as a sender does (see <xref target="sec:auth_tag"/>).
</t>


</section>


</section><!-- -Verification of the Authentication Information- -->


<section title="Initialization of a Receiver">
<!-- =================================== -->

<t>
A receiver MUST be initialized before being able to authenticate the source
of incoming packets.
This can be done by an out-of-band mechanism or an in-band mechanism
(<xref target="sec:intro_to_bootstrap"/>).
Let us focus on the in-band mechanism.
Two actions must be performed:
<list style='symbols'> 
<t>receive and process a bootstrap information message, and</t>
<t>calculate an  upper bound of the sender's local time. 
	To that purpose, the receiver must perform time synchronization.</t>
</list>
</t>


<section title="Processing the Bootstrap Information Message" anchor="sec:recv_process_bootstrap">
<!-- =================================== -->

<t>
A receiver must first receive a packet containing the bootstrap
information, digitally signed by the sender.
Once the bootstrap information has been authenticated (sec
<xref target="sec:verif_auth_info"/>), the receiver can initialize its TESLA
component.
The receiver MUST then ignore the following bootstrap information messages,
if any.
There is an exception though: when a new key chain is used and if a receiver
missed all the commitments for this new key chain, then this receiver
MUST process one of the future Bootstrap information messages (if any) in
order to be able to authenticate the incoming packets associated to this
new key chain.
</t>

<t>
Before TESLA has been initialized, a receiver MUST discard incoming packets
other than the bootstrap information message and direct time synchronization response.
<!--
VR: dangereux car il y aura un dephasage temporel ensuite, lorsque la synchro
NTP aura lieu, et on n'aura plus la garantie permettant de passer le test
"Safe Pkt Test"... Dangereux, donc a eviter...

Yet, a receiver MAY chose to buffer incoming packets, recording the reception time
of each packet, and proceed with delayed authentication later, once the
receiver will be fully initialized.
In that case, the buffer must be carefully sized in order to prevent memory
starvation (e.g., an attacker who sends faked packets before the session actually
starts can exhaust the memory of receivers who do not limit the maximum incoming
buffer size).
-->
</t>

</section>


<section title="Performing Time Synchronization" anchor="sec:rx_time_synchro">
<!-- =================================== -->

<t>
First of all, the receiver must know whether the ALC or NORM session
relies on direct or indirect time synchronization.
This information is communicated by an out-of-band mechanism (for instance when
describing the various parameters of an ALC or NORM session.
In some cases, both mechanisms might be available and the receiver can choose
the preferred technique.
</t>

<section title="Direct Time Synchronization" anchor="sec:direct_synch_request_format">
<!-- =================================== -->

<t>
In case of a direct time synchronization, a receiver MUST synchronize
with the sender.
To that purpose, the receiver sends a direct time synchronization request message.
This message includes the local time (in NTP timestamp format) at the receiver when sending
the message.
This timestamp will be copied in the sender's response for the receiver to
associate the response to the request.
</t>

<t>
The direct time synchronization request message format is the following:
</t>

<t>
<figure anchor='fig:direct_synch_request_format'
	title="Format of a Direct Time Synchronization Request">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                     t_r (NTP timestamp)                       +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>The direct time synchronization request (<xref target="fig:direct_synch_request_format"/>)
contains the following information:</t>

<t>"t_r" (NTP timestamp, 64 bits):</t>
<t><list><t>
	t_r is a timestamp in NTP timestamp format that contains the receiver local time value when
	sending this direct time synchronization request message;
</t></list></t>

<t>"Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
	This field contains the Group MAC, calculated with the group key, K_g, shared
	by all group members.
	The field length, in bits, is given by n_w, which is known once the Group MAC
	function type is known (Section 7).
</t></list></t>

<t>
<!--
<xref target="sec:direct_synch_response_format"/> specifies the
direct time synchronization response message format.
-->
The receiver then awaits a response message (<xref target="sec:direct_synch_response_format"/>).
Upon receiving this message, the receiver:
<list>
<t>	checks that this response relates to the request, by comparing the t_r fields;</t>
<t>	checks the Group MAC if present;</t>
<t>	checks the signature;</t>
<t>	retrieves the t_s value and calculates D_t
	(<xref target="sec:delay_bound_calc_direct_sync"/>);</t>
</list>
</t>

<t>
Note that in an ALC session, the direct time synchronization request message
is sent to the sender by an out-of-band mechanism that is not specified by
the current document.
</t>

</section>

<section title="Indirect Time Synchronization">
<!-- =================================== -->

<t>
With the indirect time synchronization method, the sender MAY provide out-of-band
the URL or IP address of the NTP server(s) he trusts along with an OPTIONAL certificate
for each NTP server.
When several NTP servers are specified, a receiver MUST choose one of them.
This document does not specify how the choice is made, but for the sake
of scalability, the clients SHOULD NOT use the same server if several
possibilities are offered.
The NTP synchronization between the NTP server and the receiver
MUST be authenticated, either using the certificate provided by the server,
or another certificate the client may obtain for this NTP server.
</t>

<t>
Then the receiver computes the time offset between itself and the NTP
server chosen. 
Note that the receiver does not need to update the local time, 
(which often requires root privileges), computing the
time offset is sufficient.
</t>

<t>
Since the offset between the server and the time reference, D^O_t, is indicated
in the bootstrap information message (or communicated out-of-band), the receiver
can now calculate an upper bound of the sender's local time
(<xref target="sec:delay_bound_calc_indirect_sync"/>).
</t>

<t>
Note that this scenario assumes that each client trusts the sender and accepts to
align its NTP configuration to that of the sender, using one of the NTP server(s)
suggested. If this assumption does not hold, the client MUST NOT use the NTP indirect
time synchronization method (<xref target="sec:intro_to_indirect_time_sync"/>).
</t>


</section>

</section>


</section><!-- -Initialization of a Receiver- -->


<section title="Authentication of Received Packets" anchor="sec:auth_received_pkts_guidelines">
<!-- =================================== -->

<t>
The receiver can now authenticate incoming packets (other than bootstrap information and
direct time synchronization response packets).
To that purpose, he MUST follow different steps (see <xref target="RFC4082"/> section 3.5):
<list style='numbers'>
<t>The receiver parses the different packet headers.
	If none of the four TESLA authentication tags is present, the receiver MUST
	discard the packet.
	If the session is in "Single Key Chain" mode (e.g., when the "S" flag is set
	in the bootstrap information message), then the receiver MUST discard
	any packet containing an Authentication Tag With a New Key Chain Commitment
	or an Authentication Tag With a Last Key of Old Chain Disclosure.
</t>

<t> Safe packet test:
	When the receiver receives packet P_j, it first records the
	local time T at which the packet arrived.
	The receiver then computes an upper bound t_j on the sender's
        clock at the time when the packet arrived: t_j = T + D_t.
	The receiver then computes the highest interval the sender
	could possibly be in: highest_i = floor((t_j - T_0) / T_int).
<!--
	Two possibilities arise then:
	<list style='symbols'>
		<t> with a non compact authentication tag, the "i" interval
		index is available. Get it from the header.
		</t>

		<t>
		When a compact authentication tag is used, the receiver must
		compute the corresponding "i" interval index from the "i_LSB"
		and perhaps "i_NSB" fields. The following algorithm is used:
<figure>
<artwork>
if (MAC(K'_i, M) is not padded) {
    // with HMAC-SHA-256 and higher, the i_LSB field is the only
    // field available to guess i.
    i_mask = 0xFFFFFF00;
    i_low = i_LSB;              // lower bits of "i"
} else {
    // with a two byte padding (i.e., HMAC-SHA-1 and HMAC-SHA-224),
    // the 2 byte i_NSB field is available in addition to i_LSB.
    i_mask = 0xFF000000;
    i_low = i_LSB + i_NSB;      // lower bits of "i"
}
i_high = highest_i & i_mask;    // (guessed) higher bits of "i", using
                                // the highest interval the sender can
                                // possibly be in.
i = i_high + i_low;             // raw guessed "i"
if (i > highest_i) {
    // cycling took place. Since "i" cannot be larger than "highest_i",
    // decrement it.
    i_cycle = (~i_mask) + 1;    // length of a cycle
    i = i - i_cycle;
}
</artwork>
</figure>
		</t>
	</list>
-->
	He also retrieves the "i" interval index from the
	authentication tag.
	The receiver can now proceed with the "safe packet" test.
	If highest_i < i + d, then the sender is not yet in the interval
	during which it discloses the key K_i. The packet is safe (but
	not necessarily authentic).
	If the test fails, the packet is unsafe, and the receiver MUST
	discard the packet.
</t>

<t> Group MAC test: if the optional Group MAC tag is present and if the
	session uses this feature, then verify the Group MAC
	(<xref target="sec:verif_group_mac"/>).
	If the verification fails, the packet MUST be immediately dropped.
	A packet that does not contain a Group MAC tag whereas the session uses
	this feature MUST be immediately dropped.
	On the opposite, if a packet contains a Group MAC tag whereas the session does
	not use this feature, this tag MUST be ignored.
</t>

<!--
<t> New key index test: Next the receiver checks whether a key K_v
	has already been disclosed with the same index v as the
	current disclosed key K_{i-d}, or with a later one; that is,
	with v >= i-d.
</t>

<t> Key verification test: If the disclosed key index is new, the
	receiver checks the legitimacy of K_{i-d} by verifying, for
	some earlier disclosed key K_v (with v < i-d), that
	K_v = F^{i-d- v}(K_{i-d}).
	In other words, the receiver checks the disclosed key by
	computing the necessary number of PRF functions to obtain a
	previously safe disclosed key.

	If the key verification fails, the receiver MUST discard the packet.
	If the key verification succeeds, this key is said legitimate.
</t>
-->
<t> Disclosed Key processing:
	When the packet discloses a key (i.e., with a Standard Authentication Tag, or
	with an Authentication Tag with a ``Last Key of Old Chain'' Disclosure),
	the following tests are performed:
	<list style='symbols'>
	<t> New key index test: the receiver checks whether a legitimate key 
		already exists with the same index (i.e., i-d).
		<!-- or with an index strictly superior (i.e., with an index > i-d).-->
		If such a legitimate key exists, the receiver compares its
		value with the current disclosed key and if they are identical,
		skips the "Unverifiable key test" and "Key verification test".
		If such a legitimate key exists but the values differ, the
		receiver MUST discard the packet.
	</t>

	<t> Unverifiable key test: when the disclosed key index is new, it is
		possible that no earlier disclosed and legitimate key exists
		for this key chain, thereby preventing the verification of the
		disclosed key.
		This happens when the disclosed key belongs to the old
		key chain and no commitment to this old key chain has
		ever been received (e.g., because the first bootstrap packet
		received by a latecomer is for the current key chain, and
		therefore includes a commitment to the current key chain, not
		the previous one).
		
		When this happens, the receiver MUST ignore the disclosed key
		(anyway useless) and skip the "Key verification test".
	</t>

	<t> Key verification test: If the disclosed key index is new and the
		key can be verified, the receiver checks the legitimacy of
		K_{i-d} by verifying, for some earlier disclosed and legitimate
		key K_v (with v < i-d), that K_v and F^{i-d-v}(K_{i-d}) are identical.
		In other words, the receiver checks the disclosed key by
		computing the necessary number of PRF functions to obtain a
		previously disclosed and legitimate (i.e., verified) key.

		If the key verification fails, the receiver MUST discard the packet.
		If the key verification succeeds, this key is said legitimate and
		is stored by the receiver, as well as all the keys between indexes
		v and i-d.
	</t>
	</list>
	</t>

<!--
<t> New Key Chain Commitment processing:
	When the packet includes a new key chain commitment (i.e., with a
	standard or compact authentication tag with a new key chain commitment),
	the receiver first checks whether a commitment has already been received
	or not for this new key chain.
	If this is a new commitment, the receiver stores it.
	If a commitment is already available, it is recommended that the receiver
	stores the new commitment. Indeed, the previously stored commitment(s)
	may fail the authentication test and therefore turn out to be useless.

	When the commitment is stored, it is marked as non-verified. This commitment
	will be validated later on, when the associated packet is authenticated.
</t>
-->

<t>When applicable, the receiver performs any congestion control related action
	(i.e., the ALC or NORM headers are used by the associated congestion control
	building block, if any), even if the packet has not yet been
	authenticated <xref target="RMT-BB-LCT"/>.
	If this feature leads to a potential DoS attack (the attacker can send
	a faked packet with a wrong sequence number to simulate packet losses),
	it does not compromise the security features offered by TESLA and enables
	a rapid reaction in front of actual congestion problems.
</t>

<t>The receiver then buffers the packet for a later authentication, once the corresponding
	key will be disclosed (after d time intervals) or deduced from another key
	(if all packets disclosing this key are lost).
	In some situations, this packet might also be discarded later on, if
	it turns out that the receiver will never be able to deduce the associated key.
</t>

<t>Authentication test:
	Let v be the smallest index of the legitimate keys known by the receiver
	so far. For all the new keys K_w, with v < w &le; i-d, that have been
	either disclosed by this packet (i.e., K_{i-d}) or derived by K_{i-d}
	(i.e., keys in interval {v+1,.. i-d-1}), the receiver verifies the
	authenticity of the safe packets buffered for the corresponding
	interval w.

	To authenticate one of the buffered packets P_h containing
	message M_h protected with a MAC that used key index w, the
	receiver will compute K'_w = F'(K_w) from which it can
	compute MAC( K'_w, M_h).

	If this MAC does not equal the MAC stored in the packet, the receiver
	MUST discard the packet.

	If the two MAC are equal, the packet is successfully authenticated and the
	receiver continues processing it.
</t>

<t>Authenticated new key chain commitment processing:
	If the authenticated packet contains a new key chain commitment and if
	no verified commitment already exists, then the receiver stores the
	commitment to the new key chain.
	Then, if there are non authenticated packets for a previous chain
	(i.e., the key chain before the current one), all these packets can be
	discarded (<xref target="sec:flushing_pkts_of_prev_key_chain"/>).
</t>

<t>The receiver continues the ALC or NORM processing of all the packets
	authenticated during the authentication test.
</t>

</list></t>

<t>
In this specification, a receiver using TESLA MUST immediately drop unsafe packets.
But the receiver MAY also decide, at any time, to continue an ALC or NORM session in
unsafe (insecure) mode, ignoring TESLA extensions. There SHOULD be an explicit
user action to that purpose.
</t>


<!-- 
<section title="Wrong Guess of the i Parameter">

<t>
When a compact authentication tag is used, the receiver computes the "i"
interval index from the "i_LSB" and perhaps "i_NSB" fields, and therefore
there is a risk of error.
Let us consider the case where only "i_LSB" is used (situation with the
highest risks of error).
An error occurs when the calculated i_high (at a receiver)
differs from the original i_high (at the sender),
where the receiver calculates i_high by: i_high = floor((t_j - T_0) / T_int) & 0xFFFFFF00).
So an error occurs if the elapsed time: t_j - T_0 >= K*(256*T_int),
where K is an integer greater or equal to 1.
So there will be an error if the packet has been delayed by at least 256*T_int milliseconds.
Since T_int is roughly equal to the RTT, the probability is low.
This is even more true when both "i_LSB" and "i_NSB" fields are used.
</t>

<t>
Of course, an attacker can also deliberately corrupt the "i_LSB"/"i_NSB"
fields, but the same remark can be done with the "i" field.
</t>

<t>
If ever an error occurs, be it intentional (attack) or not, this error will
be caught either (<xref target="sec:auth_received_pkts_guidelines"/>):
<list style='symbols'>
	<t> by the safe packet test (step 2), or</t>
	<t> by the new key index test (step 4a) or key verification test (step 4b)
	    if this packet discloses a key,</t>
	<t> or by the authentication test (step 7), when the key corresponding
	    to this wrong interval index is disclosed. This final test always
	    catches the wrong "i" parameter value.</t>
</list>
If an error is identified, the receiver MUST discard the packet.
TESLA is therefore robust to wrong "i" parameter values.
</t>

</section>
-->


<section title="Discarding Unnecessary Packets Earlier">
<!-- =================================== -->

<t>
Following strictly the above steps can lead to excessive processing overhead
in certain situations.
This is the case when a receiver receives packets for an unwanted object with
the ALC or NORM protocols, i.e., an object for which the application (or the
end user) explicitly mentioned it is not interested in.
This is also the case when a receiver receives packets for an already decoded
object, or when this object has been partitioned in several blocks, for an
already decoded block.
When such a packet is received, which is easily identified by looking at the
receiver's status for the incoming ALC or NORM packet, the receiver MUST also
check that the packet is a pure data packet that does not contain any signaling
information of importance for the session.
</t>

<t>
With ALC, a packet containing a "A" flag ("Close Session") or a "B" flag
("Close Object") MUST NOT be discarded before having been authenticated
and processed normally.
Otherwise, the receiver can safely discard the incoming packet for instance
just after step 1 of <xref target="sec:auth_received_pkts_guidelines"/>.
This optimization can dramatically reduce the processing overhead, by
avoiding many useless authentication checks.
</t>

</section>


</section><!-- -Receiving authenticated data- -->


<section title="Flushing the Non Authenticated Packets of a Previous Key Chain"
anchor="sec:flushing_pkts_of_prev_key_chain">
<!-- =================================== -->

<t>
In some cases a receiver having experienced a very long disconnection might
have lost all the disclosures of the last key(s) of a previous key chain.
Let j be the index of this key chain for which there remains non authenticated
packets.
This receiver can flush all the packets of the key chain j if he determines that:
<list style='symbols'>
	<t>he has just switched to a chain of index j+2 (inclusive) or higher; </t>
	<t>the sender has sent a commitment to the new key chain of index j+2
	(<xref target="sec:value_of_tx_lastkey_tx_newkcc"/>).
	This situation requires that the receiver has received a packet containing
	such a commitment and that he has been able to check its integrity.
	In some cases it might require to receive a bootstrap information message
	for the current key chain.</t>
</list>
If one of the above two tests succeeds, the sender can discard all the awaiting
packets since there is no way to authenticate them.
</t>


</section><!-- -Flushing non auth pkts- -->
</section><!-- =Receiver= -->


<!-- ======================================================================= -->


<section title="Integration in the ALC and NORM Protocols"
	anchor='sec:alc_norm_integration'>
<!-- =================================== -->


<section title="Authentication Header Extension Format"
	anchor='sec:auth_he_format'>
<!-- =================================== -->

<t>
The integration of TESLA in ALC or NORM is similar and relies on the 
header extension mechanism defined in both protocols.
More precisely this document details the EXT_AUTH==1 header extension defined
in <xref target="RMT-BB-LCT"/>.
</t>

<!--
<t>
<list><t> Editor's note:
	All authentication schemes using the EXT_AUTH header extension MUST
	reserve the same 4 bit "ASID" field after the HET/HEL fields.
	This way, several authentication schemes can be used in the same ALC
	or NORM session, even on the same communication path.
	</t>
</list>
</t>
-->

<t>
Several fields are added in addition to the HET (Header Extension Type) and HEL
(Header Extension Length) fields (<xref target="lct_integration"/>).
</t>

<t>
<figure title='Format of the TESLA EXT_AUTH header extension.'
	anchor='lct_integration'>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   HET (=1)    |      HEL      |  ASID |  Type |               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
 |                                                               |
 ~                                                               ~
 |                            Content                            |
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
The fields of the TESLA EXT_AUTH header extension are:</t>

<t>"ASID" (Authentication Scheme IDentifier) field (4 bits):</t>
<t><list><t>
	The "ASID" identifies the source authentication scheme or protocol
	in use.
	The association between the "ASID" value and the actual authentication
	scheme is defined out-of-band, at session startup.
</t></list></t>

<t>"Type" field (4 bits):</t>
<t><list><t>
	The "Type" field identifies the type of TESLA information carried
	in this header extension.
	This specification defines the following types:
	<list style='symbols'> 
	<t>0: Bootstrap Information, sent by the sender periodically
		or after a direct time synchronization request;</t>
	<t>1: Standard Authentication Tag for the on-going key chain, sent by
		the sender along with a packet;</t>
	<t>2: Authentication Tag Without Key Disclosure, sent by
		the sender along with a packet;</t>
	<t>3: Authentication Tag with a New Key Chain Commitment,
		sent by the sender when approaching the end of a key chain;</t>
	<t>4: Authentication Tag with a Last Key of Old Chain Disclosure,
		sent by the sender some time after moving to a new key chain;</t>
<!--
	<t>5: compact (i.e., that contains the last byte of the interval index)
		authentication tag
		for the on-going key chain, sent by the sender along with a packet;</t>
	<t>6: compact (i.e., that contains the last byte of the interval index)
		authentication tag without any key disclosure, sent by the sender
		along with a packet;</t>
	<t>7: compact (i.e., that contains the last byte of the interval index)
		authentication tag with a new key chain commitment,
		sent by the sender when approaching the end of a key chain;</t>
	<t>8: compact (i.e., that contains the last byte of the interval index)
		authentication tag with a last key of old chain disclosure,
		sent by the sender some time after moving to a new key chain;</t>
-->
	<t>5: Direct Time Synchronization Request, sent by a NORM receiver.
		This type of message is invalid in case of an ALC session
		since ALC is restricted to unidirectional transmissions.
		Yet an external mechanism may provide the direct time
		synchronization functionality;</t>
	<t>6: Direct Time Synchronization Response, sent by a NORM sender.
		This type of message is invalid in case of an ALC session
		since ALC is restricted to unidirectional transmissions.
		Yet an external mechanism may provide the direct time
		synchronization functionality;</t>
	</list>
</t></list></t>

<t>"Content" field (variable length):</t>
<t><list><t>
	This is the TESLA information carried in the header extension, whose
	type is given by the "Type" field.
</t></list></t>

</section>


<section title="Use of Authentication Header Extensions"
	anchor='sec:auth_he_use'>
<!-- =================================== -->

<t>
Each packet sent by the session's sender MUST contain exactly one
TESLA EXT_AUTH header extension.
</t>

<t>
All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content,
for instance because they do not support TESLA.
In that case these receivers MUST ignore the TESLA EXT_AUTH extensions.
In case of NORM, the packets sent by receivers MAY contain a direct
synchronization request but MUST NOT contain any of the other five
TESLA EXT_AUTH header extensions.
</t>

<section title="EXT_AUTH Header Extension of Type Bootstrap Information"
	anchor='sec:auth_he_use_bootstrap'>
<!-- =================================== -->

<t>
The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in
a stand-alone control packet, rather than in a packet containing application data.
The reason for that is the large size of this bootstrap information.
By using stand-alone packets, the maximum payload size of data packets is only
affected by the (mandatory) authentication information header extension.
</t>

<t>
With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a
control packet, i.e., containing no encoding symbol.
</t>

<t>
With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a
NORM_CMD(APPLICATION) message.
</t>

<t>
<figure anchor='fig:bootstrap_with_1024b_sig'
	title="Example: Format of the bootstrap information message (Type 0),
		using SHA-256/1024 bit signatures, the default HMAC-SHA-256 and a Group MAC.">
      <preamble></preamble>
      <artwork>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
|   HET (=1)    |    HEL (=46)  |  ASID |   0   | 0 |  0  |0|1|0|  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|       d       |       2       |       2       |       2       |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|       1       |       3       |              128              |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|         0 (reserved)          |             T_int             |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
+                  T_0 (NTP timestamp format)                   +  | 5
|                                                               |  | 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                      N (Key Chain Length)                     |  | b
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | y
|                    Current Interval Index i                   |  | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | e
|                                                               |  | s
+                                                               +  |
|                                                               |  |
+                 Current Key Chain Commitment                  +  |
|                          (20 bytes)                           |  |
+                                                               +  |
|                                                               |  |
+                                                               +  |
|                                                               |  v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
|                                                               |  ^ 1
+                                                               +  | 2
|                                                               |  | 8
.                                                               .  |
.                           Signature                           .  | b
.                          (128 bytes)                          .  | y
|                                                               |  | t
+                                                               +  | e
|                                                               |  v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
|                           Group MAC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
For instance <xref target="fig:bootstrap_with_1024b_sig"/> shows the bootstrap information
message when using the HMAC-SHA-256 transform for the PRF, MAC, and Group MAC functions,
along with SHA-256/128 byte (1024 bit) key digital signatures (which also means that the signature
field is 128 byte long).
The TESLA EXT_AUTH header extension is then 184 byte long (i.e., 46 words of 32 bits).
</t>


</section>


<section title="EXT_AUTH Header Extension of Type Authentication Tag"
	anchor='sec:auth_he_use_auth_info'>
<!-- =================================== -->

<t>
The four "authentication tag" TESLA EXT_AUTH (Type 1, 2, 3, and 4)
MUST be attached to the ALC or NORM packet (data or control packet) that
they protect.
</t>

<t>
<figure anchor='fig:example_authentication_tag'
	title="Example: Format of the Standard Authentication Tag (Type 1), using the default HMAC-SHA-256.">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   HET (=1)    |   HEL (=10)   |  ASID |   1   |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                                                               |
 +                     Disclosed Key K_{i-d}                     +
 |                          (20 bytes)                           |
 +                                                               +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                         MAC(K'_i, M)                          |
 +                          (16 bytes)                           +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
<figure anchor='fig:example_authentication_tag_wo_key_discl'
	title="Example: Format of the Authentication Tag Without Key Disclosure (Type 2),
	using the default HMAC-SHA-256.">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   HET (=1)    |   HEL (=5)    |  ASID |   2   |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                         MAC(K'_i, M)                          |
 +                          (16 bytes)                           +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
For instance, <xref target='fig:example_authentication_tag'/> and
<xref target='fig:example_authentication_tag_wo_key_discl'/>
show the format of the authentication tags, respectively with and without
the K_{i-d} key disclosure, when using the (default) HMAC-SHA-256 transform for the PRF
and MAC functions.
In this example, the Group MAC feature is not used.
</t>

</section>


<section title="EXT_AUTH Header Extension of Type Direct Time Synchronization Request"
	anchor='sec:auth_he_use_direct_synch_req'>
<!-- =================================== -->

<t>
With NORM, the "direct time synchronization request" TESLA EXT_AUTH (Type==7)
MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM packet.
</t>

<t>
With ALC, the "direct time synchronization request" TESLA EXT_AUTH cannot be
included in an ALC packet, since ALC is restricted to unidirectional
transmissions, from the session's sender to the receivers.
An external mechanism must be used with ALC for carrying direct time synchronization
requests to the session's sender.
</t>

<t>
In case of direct time synchronization, it is RECOMMENDED that the
receivers spread the transmission of direct time synchronization
requests over the time (<xref target="sec:intro_to_direct_time_sync"/>).
</t>

</section>


<section title="EXT_AUTH Header Extension of Type Direct Time Synchronization Response"
	anchor='sec:auth_he_use_direct_synch_resp'>
<!-- =================================== -->

<t>
With NORM, the "direct time synchronization response" TESLA EXT_AUTH (Type==8)
MUST be sent by the sender in a NORM_CMD(APPLICATION) message.
</t>

<t>
With ALC, the "direct time synchronization response" TESLA EXT_AUTH can be sent
in an ALC control packet (i.e., containing no encoding symbol) or through the 
external mechanism use to carry the direct time synchronization request.
</t>

</section>

</section>


</section><!-- -LCT or NORM integration- -->


<section title="Security Considerations">
<!-- ==================================== -->

<t>
<xref target="RFC4082"/> discusses the security of TESLA in general.
These considerations apply to the present specification, namely:
<list style='symbols'> 
	<t>great care must be taken to the timing aspects. In particular the D_t parameter
	is critical and must be correctly initialized;</t>

	<t>if the sender realizes that the key disclosure schedule is not
	appropriate, then the current session MUST be closed and a new one
	created. Indeed <xref target="sec:time_int_schedule"/> requires that
	these parameters be fixed during the whole session.
	</t>
<!--
	<t>if the key disclosure schedule is to be changed (e.g., because the sender
	realizes that the parameters do not meet the receiver requirements), then
	this change MUST NOT be announced in-line, within the session.
	Indeed, a receiver that missed the announcement would be vulnerable to
	attacks.
	Note that in the current specification, the parameters that define the
	key disclosure schedule MUST be fixed during the whole session
	(<xref target="sec:time_int_schedule"/>).
	</t>
-->

	<t>when the verifier that authenticates the incoming packets and the application
	that uses the data are two different components, there is a risk that an
	attacker located between these components inject faked data.
	Similarly, when the verifier and the secure timing system are two
	different components, there is a risk that an attacker located between
	these components inject faked timing information.
	For instance, when the verifier reads the local time by means of a
	dedicated system call (e.g., gettimeofday()), if an attacker controls
	the host, he may catch the system call and return a faked time information.
	</t>
</list> 
The current specification discusses additional aspects with more details.
</t>

<section title="Dealing With DoS Attacks">
<!-- =================================== -->

<t>
TESLA introduces new opportunities for an attacker to mount DoS attacks.
For instance an attacker can try to saturate the processing
capabilities of the receiver (faked packets are easy to create but checking
them requires to compute a MAC over the packet or sometimes check a digital
signature as with the bootstrap and direct time synchronization response messages).
An attacker can also try to saturate the receiver's memory (since authentication
is delayed and non-authenticated packets will accumulate), or to make the receiver
believe that a congestion has happened (since congestion control MUST be performed
before authenticating incoming packets, <xref target="sec:auth_received_pkts_guidelines"/>).
</t>

<t>
In order to mitigate these attacks, it is RECOMMENDED to use the Group MAC
scheme (<xref target="sec:group_auth_tag"/>).
No mitigation is possible if a group member acts as an attacker with Group MAC.
</t>

<t>
Generally, it is RECOMMENDED that the amount of memory used to store
incoming packets waiting to be authenticated be limited to a reasonable
value.
</t>

</section>

<section title="Dealing With Replay Attacks">
<!-- =================================== -->

<t>
Replay attacks, whereby an attacker stores a valid message and replays it later
on, can have significant impacts, depending on the message type.
Two levels of impacts must be distinguished:
<list style='symbols'> 
	<t> within the TESLA protocol, and</t>
	<t> within the ALC or NORM protocol.</t>
</list>
</t>


<section title="Impacts of Replay Attacks on TESLA">
<!-- =================================== -->

<t>
Replay attacks can impact the TESLA component itself.
We review here the potential impacts of such an attack depending on the TESLA message type:
<list style='symbols'> 
	<t> bootstrap information:
		since most parameters contained in a bootstrap information message
		are static, replay attacks have no consequences.
		The fact that the "i" and "K_i" fields can be updated in subsequent
		bootstrap information messages does not create a problem either,
		since all "i" and "K_i" fields sent remain valid.
		Finally, a receiver that successfully initialized its TESLA component
		MUST ignore the following messages (see <xref target="sec:recv_process_bootstrap"/>
		for an exception to this rule),
		which voids replay attacks, unless he missed all the commitments to a new
		key chain (e.g., after a long disconnection) (<xref target="sec:bootstrap_info"/>).
	</t>
	<t> direct time synchronization request:
		If the Group MAC scheme is used, an attacker that is not a member of
		the group can replay a packet and oblige the sender to respond, which
		requires to digitally sign the response, a time-consuming process.
		If the Group MAC scheme is not used, an attacker can anyway easily
		forge a request.
		In both cases, the attack will not compromise the TESLA component, but might
		create a DoS.
		If this is a concern, it is RECOMMENDED, when the Group MAC scheme is used,
		that the sender verify the "t_r" NTP timestamp contained in the request
		and respond only if this value is strictly larger than the previous one
		received from this receiver.
		When the Group MAC scheme is not used, this attack can be mitigated
		by limiting the number of requests per second that will be processed.
	</t>
	<t> direct time synchronization response:
		Upon receiving a response, a receiver who has no pending request
		MUST immediately drop the packet.
		If this receiver has previously issued a request, he first checks
		the Group MAC (if applicable), then the "t_r" field, to be sure
		it is a response to his request, and finally the digital signature.
		A replayed packet will be dropped during these verifications, without
		compromising the TESLA component.
	</t>
	<t> other messages, containing an authentication tag:
		Replaying a packet containing a TESLA authentication tag will never
		compromise the TESLA component itself (but perhaps the underlying
		ALC or NORM component, see below).
	</t>
</list>
To conclude, TESLA itself is robust in front of replay attacks.
</t>

</section>


<section title="Impacts of Replay Attacks on NORM">
<!-- =================================== -->

<t>
We review here the potential impacts of a replay attack on the NORM component.
Note that we do not consider here the protocols that could be used along with
NORM, for instance the congestion control protocols.
</t>

<t>
First, let us consider replay attacks within a given NORM session.
NORM defines a "sequence" field that can be used to protect against replay
attacks <xref target="RMT-PI-NORM"/> within a given NORM session.
This "sequence" field is a 16-bit value that is set by the message
originator (sender or receiver) as a monotonically increasing number
incremented with each NORM message transmitted.
It is RECOMMENDED that a receiver check this sequence field and drop messages considered
as replayed.
Similarly, it is RECOMMENDED that a sender check this sequence, for each known receiver,
and drop messages considered as replayed.
In both cases, checking this sequence field SHOULD be done before
TESLA processing of the packet: if the sequence field has not been
corrupted, the replay attack will immediately be identified, and
otherwise the packet will fail the TESLA authentication test.
This analysis shows that NORM itself is robust in front of replay attacks
within the same session.
</t>

<t>
Now let us consider replay attacks across several NORM sessions.
Since the key chain used in each session MUST differ, a packet replayed in a
subsequent session will be identified as unauthentic.
Therefore NORM is robust in front of replay attacks across different sessions.
</t>


</section>


<section title="Impacts of Replay Attacks on ALC">
<!-- =================================== -->

<t>
We review here the potential impacts of a replay attack on the ALC component.
Note that we do not consider here the protocols that could be used along with
ALC, for instance the layered or wave based congestion control protocols.
</t>
<t>
First, let us consider replay attacks within a given ALC session:
<list style='symbols'> 
	<t>Regular packets containing an authentication tag: a replayed message
	containing an encoding symbol will be detected once authenticated, thanks to
	the object/block/symbol identifiers, and will be silently discarded.
	This kind of replay attack is only penalizing in terms of memory and
	processing load, but does not compromise the ALC behavior.
	</t>
	<t>Control packets containing an authentication tag:
	ALC control packets, by definition, do not include any encoding symbol
	and therefore do not include any object/block/symbol identifier that would
	enable a receiver to identify duplicates.
	However, a sender has a very limited number of reasons to send control packets.
	More precisely:
	<list style='symbols'> 
		<t>At the end of the session, a "close session" (A flag) packet is sent.
		Replaying this packet has no impact since the receivers already left.</t>
		<t>Similarly, replaying a packet containing a "close object" (B flag)
		has no impact since this object is probably already marked as closed
		by the receiver.</t>
	</list>
	</t>
</list>
This analysis shows that ALC itself is robust in front of replay attacks
within the same session.
</t>

<t>
Now let us consider replay attacks across several ALC sessions.
Since the key chain used in each session MUST differ, a packet replayed in a
subsequent session will be identified as unauthentic.
Therefore ALC is robust in front of replay attacks across different sessions.
</t>

</section>

</section>

<section title="Security of the Back Channel">
<!-- =================================== -->

<t>
As specified in <xref target="scope"/>, this specification does not consider
the packets that may be sent by receivers, for instance NORM's feedback packets.
When a back channel is used, its security is critical to the global security,
and an appropriate security mechanism MUST be used.
<xref target="RMT-SIMPLE-AUTH"/> describes several techniques that can be used 
to that purpose.
However, the authentication and integrity verification of the packets sent by receivers
on the back channel, if any, is out of the scope of this document.
</t>


</section>

</section>


<section title="IANA Considerations" anchor="sec:iana">
<!-- ==================================== -->

<t>This document requires a IANA registration for the following attributes.
The registries are provided by <xref target="RFC4442"/> under the "Timed Efficient Stream
Loss-tolerant Authentication (TESLA) Parameters" registry <xref target="TESLA-REG"/>.
Following the policies outlined in <xref target="RFC4442"/>, the values in the range
up to 240 (including 240) for the following attributes are assigned after
expert review by the MSEC working group or its designated successor.
The values in the range from 241 to 255 are reserved for private use.
</t>

<t>Cryptographic Pseudo-Random Function, TESLA-PRF:
	All implementations MUST support HMAC-SHA-256 (default).</t>

       <texttable>
           <preamble></preamble>
           <ttcol align='center'>PRF name</ttcol>
           <ttcol align='center'>Value</ttcol>
           <c>HMAC-SHA-1</c>		<c>0</c>
           <c>HMAC-SHA-224</c>		<c>1</c>
           <c>HMAC-SHA-256 (default)</c><c>2</c>
           <c>HMAC-SHA-384</c>		<c>3</c>
           <c>HMAC-SHA-512</c>		<c>4</c>
       </texttable>

<t>Cryptographic Message Authentication Code (MAC) Function, TESLA-MAC:
	All implementations MUST support HMAC-SHA-256 (default).
	These MAC schemes are used both for the computing of regular
	MAC and the Group MAC (if applicable).</t>

       <texttable>
           <preamble></preamble>
           <ttcol align='center'>MAC name</ttcol>
           <ttcol align='center'>Value</ttcol>
           <c>HMAC-SHA-1</c>		<c>0</c>
           <c>HMAC-SHA-224</c>		<c>1</c>
           <c>HMAC-SHA-256 (default)</c><c>2</c>
           <c>HMAC-SHA-384</c>		<c>3</c>
           <c>HMAC-SHA-512</c>		<c>4</c>
       </texttable>

<t>Furthermore, this document requires IANA to create two new registries.
Here also, the values in the range up to 240 (including 240) for the following
attributes are assigned after expert review by the MSEC working group or its
designated successor.
The values in the range from 241 to 255 are reserved for private use.
</t>

<t>Signature Encoding Algorithm, TESLA-SIG-ALGO:
	All implementations MUST support RSASSA-PKCS1-v1_5 (default).</t>

       <texttable>
           <preamble></preamble>
           <ttcol align='center'>Signature Algorithm Name</ttcol>
           <ttcol align='center'>Value</ttcol>
           <c>INVALID</c>			<c>0</c>
           <c>RSASSA-PKCS1-v1_5 (default)</c>	<c>1</c>
           <c>RSASSA-PSS</c>			<c>2</c>
       </texttable>

<t>Signature Cryptographic Function, TESLA-SIG-CRYPTO-FUNC:
	All implementations MUST support SHA-256 (default).</t>

       <texttable>
           <preamble></preamble>
           <ttcol align='center'>Cryptographic Function Name</ttcol>
           <ttcol align='center'>Value</ttcol>
           <c>INVALID		</c><c>0</c>
           <c>SHA-1		</c><c>1</c>
           <c>SHA-224		</c><c>2</c>
           <c>SHA-256 (default)	</c><c>3</c>
           <c>SHA-384		</c><c>4</c>
           <c>SHA-512		</c><c>5</c>
       </texttable>

</section>


<section title="Acknowledgments">
<!-- ==================================== -->

<t>
The authors are grateful to Yaron Sheffer, Brian Weis, Ramu Panayappan, Ran Canetti,
David L. Mills, Brian Adamson and Lionel Giraud for their valuable comments while
preparing this document.
The authors are also grateful to Brian Weis for the digital signature details.
</t>
</section>

    </middle>

    <back>

<references title="Normative References">
<!-- ==================================== -->

      <reference anchor="RFC2119">
	<front>
	  <title>Key words for use in RFCs to Indicate Requirement Levels</title>
	  <author initials="S." surname="Bradner">
	    <organization />
	  </author>
	  <date month="March" year="1997" />
	</front>
	<seriesInfo name="RFC" value="2119" />
	<seriesInfo name="BCP" value="14" />
      </reference>

      <reference anchor="RFC4082">
        <front>
          <title>Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
          Multicast Source Authentication Transform Introduction
          </title>
          <author initials="A." surname="Perrig" fullname="A. Perrig">
            <organization/></author>
          <author initials="D." surname="Song" fullname="D. Song">
            <organization/></author>
          <author initials="R." surname="Canetti" fullname="R. Canetti">
            <organization/></author>
          <author initials="J.D." surname="Tygar" fullname="J.D. Tygar">
            <organization/></author>
          <author initials="B." surname="Briscoe" fullname="B. Briscoe">
            <organization/></author>
          <date year="2005" month="June"/>
        </front>
        <seriesInfo name="RFC" value="4082"/>
        <format type="TXT" octets="54316" target="ftp://ftp.isi.edu/in-notes/rfc4082.txt"/>
      </reference>

<!--
      <reference anchor='RFC3450'>
        <front>
          <title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
          <author initials='M.' surname='Luby' fullname='M. Luby'>
            <organization /></author>
          <author initials='J.' surname='Gemmell' fullname='J. Gemmell'>
            <organization /></author>
          <author initials='L.' surname='Vicisano' fullname='L. Vicisano'>
            <organization /></author>
          <author initials='L.' surname='Rizzo' fullname='L. Rizzo'>
            <organization /></author>
          <author initials='J.' surname='Crowcroft' fullname='J. Crowcroft'>
            <organization /></author>
          <date year='2002' month='December' />
        </front>
        <seriesInfo name='RFC' value='3450' />
        <format type='TXT' octets='86022' target='ftp://ftp.isi.edu/in-notes/rfc3450.txt' />
      </reference>

      <reference anchor="RFC3451">
        <front>
          <title>Layered Coding Transport (LCT) Building Block</title>
          <author initials="M." surname="Luby" fullname="M. Luby">
            <organization/></author>
          <author initials="J." surname="Gemmell" fullname="J. Gemmell">
            <organization/></author>
          <author initials="L." surname="Vicisano" fullname="L. Vicisano">
            <organization/></author>
          <author initials="L." surname="Rizzo" fullname="L. Rizzo">
            <organization/></author>
          <author initials="M." surname="Handley" fullname="M. Handley">
            <organization/></author>
          <author initials="J." surname="Crowcroft" fullname="J. Crowcroft">
            <organization/></author>
          <date year="2002" month="December"/>
        </front>
        <seriesInfo name="RFC" value="3451"/>
        <format type="TXT" octets="72594" target="ftp://ftp.isi.edu/in-notes/rfc3451.txt"/>
      </reference>
-->


<reference anchor="RMT-PI-ALC">
	<front>
		<title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
		<author initials='M.' surname='Luby'>
			<organization />
		</author>
		<author initials="M." surname="Watson">
			<organization/>
		</author>
		<author initials='L.' surname='Vicisano'>
			<organization />
		</author>
		<date month="September" year="2009"/>
	</front>
	<seriesInfo name="" value="draft-ietf-rmt-pi-alc-revised-08.txt (work in progress)"/>
</reference>


<reference anchor="RMT-BB-LCT">
	<front>
		<title>Layered Coding Transport (LCT) Building Block</title>
		<author initials='M.' surname='Luby'>
			<organization />
		</author>
		<author initials="M." surname="Watson">
			<organization/>
		</author>
		<author initials='L.' surname='Vicisano'>
			<organization />
		</author>
		<date month="August" year="2009"/>
	</front>
	<seriesInfo name="" value="draft-ietf-rmt-bb-lct-revised-11.txt (work in progress)"/>
</reference>

<!--
      <reference anchor="RFC3926">
        <front>
          <title>FLUTE - File Delivery over Unidirectional Transport</title>
          <author initials="T." surname="Paila" fullname="T. Paila">
            <organization/></author>
          <author initials="M." surname="Luby" fullname="M. Luby">
            <organization/></author>
          <author initials="R." surname="Lehtonen" fullname="R. Lehtonen">
            <organization/></author>
          <author initials="V." surname="Roca" fullname="V. Roca">
            <organization/></author>
          <author initials="R." surname="Walsh" fullname="R. Walsh">
            <organization/></author>
          <date year="2004" month="October"/>
        </front>
        <seriesInfo name="RFC" value="3926"/>
        <format type="TXT" octets="81224" target="ftp://ftp.isi.edu/in-notes/rfc3926.txt"/>
      </reference>

      <reference anchor="RFC3940">
        <front>
          <title>Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol</title>
          <author initials="B." surname="Adamson" fullname="B. Adamson">
            <organization/></author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization/></author>
          <author initials="M." surname="Handley" fullname="M. Handley">
            <organization/></author>
          <author initials="J." surname="Macker" fullname="J. Macker">
            <organization/></author>
          <date year="2004" month="November"/>
        </front>
        <seriesInfo name="RFC" value="3940"/>
        <format type="TXT" octets="220549" target="ftp://ftp.isi.edu/in-notes/rfc3940.txt"/>
      </reference>
-->

<reference anchor="RMT-PI-NORM">
	<front>
		<title>Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol</title>
		<author initials="B." surname="Adamson" fullname="B. Adamson">
			<organization/></author>
		<author initials="C." surname="Bormann" fullname="C. Bormann">
			<organization/></author>
		<author initials="M." surname="Handley" fullname="M. Handley">
			<organization/></author>
		<author initials="J." surname="Macker" fullname="J. Macker">
			<organization/></author>
		<date year="2009" month="June"/>
	</front>
	<seriesInfo name="" value="draft-ietf-rmt-pi-norm-revised-13.txt (work in progress)"/>
</reference>

<!--
      <reference anchor="RFC3941">
        <front>
          <title>Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks</title>
          <author initials="B." surname="Adamson" fullname="B. Adamson">
            <organization/></author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization/></author>
          <author initials="M." surname="Handley" fullname="M. Handley">
            <organization/></author>
          <author initials="J." surname="Macker" fullname="J. Macker">
            <organization/></author>
          <date year="2004" month="November"/>
        </front>
        <seriesInfo name="RFC" value="3941"/>
        <format type="TXT" octets="92785" target="ftp://ftp.isi.edu/in-notes/rfc3941.txt"/>
      </reference>

-->
<reference anchor="TESLA-REG">
	<front>
		<title>TESLA Parameters IANA Registry</title>
		<author><organization/></author>
		<date />
	</front>
	<seriesInfo name="" value="http://www.iana.org/assignments/tesla-parameters/"/>
</reference>

</references>


<references title="Informative References">
<!-- ==================================== -->


      <reference anchor="Perrig04">
	<front>
	  <title>Secure Broadcast Communication in Wired and Wireless Networks</title>
	  <author initials="A." surname="Perrig" fullname="A. Perrig">
	    <organization /></author>
          <author initials="J.D." surname="Tygar" fullname="J.D. Tygar">
            <organization/></author>
	  <date year="2004" />
	</front>
        <seriesInfo name="Kluwer Academic Publishers" value="ISBN 0-7923-7650-1"/>
      </reference>

      <reference anchor="RFC4442">
        <front>
          <title>Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)</title>
          <author initials="S." surname="Fries" fullname="S. Fries">
            <organization/>
          </author>
          <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
            <organization/>
          </author>
          <date month="March" year="2006"/>
        </front>
        <seriesInfo name="RFC" value="4442"/>
        <format type="TXT" octets="37345" target="ftp://ftp.isi.edu/in-notes/rfc4442.txt"/>
      </reference>

      <reference anchor="RFC4383">
        <front>
          <title>
          The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)
          </title>
          <author initials="M." surname="Baugher" fullname="M. Baugher"><organization/></author>
          <author initials="E." surname="Carrara" fullname="E. Carrara"><organization/></author>
          <date year="2006" month="February"/>
        </front>
        <seriesInfo name="RFC" value="4383"/>
        <format type="TXT" octets="41766" target="ftp://ftp.isi.edu/in-notes/rfc4383.txt"/>
      </reference>

      <reference anchor="RFC3711">
        <front>
          <title>The Secure Real-time Transport Protocol (SRTP)</title>
          <author initials="M." surname="Baugher" fullname="M. Baugher"><organization/></author>
          <author initials="D." surname="McGrew" fullname="D. McGrew"><organization/></author>
          <author initials="M." surname="Naslund" fullname="M. Naslund"><organization/></author>
          <author initials="E." surname="Carrara" fullname="E. Carrara"><organization/></author>
          <author initials="K." surname="Norrman" fullname="K. Norrman"><organization/></author>
          <date year="2004" month="March"/>
      </front>
      <seriesInfo name="RFC" value="3711"/>
      <format type="TXT" octets="134270" target="ftp://ftp.isi.edu/in-notes/rfc3711.txt"/>
      </reference>

      <reference anchor="RMT-SIMPLE-AUTH">
        <front>
          <title>Simple Authentication Schemes for the ALC and NORM Protocols</title>
          <author initials='V.' surname='Roca'> <organization /></author>
          <date month="March" year="2009"/>
        </front>
        <seriesInfo name="" value="draft-ietf-rmt-simple-auth-for-alc-norm-01.txt (work in progress)"/>
      </reference>

      <reference anchor="RMT-FLUTE">
        <front>
          <title>FLUTE - File Delivery over Unidirectional Transport</title>
          <author initials='T.' surname='Paila'> <organization /></author>
          <author initials="R." surname="Walsh"> <organization/></author>
          <author initials='M.' surname='Luby'> <organization /></author>
          <author initials='R.' surname='Lehtonen'> <organization /></author>
          <author initials='V.' surname='Roca'> <organization /></author>
          <date month="August" year="2009"/>
        </front>
        <seriesInfo name="" value="draft-ietf-rmt-flute-revised-07.txt (work in progress)"/>
      </reference>

      <reference anchor="RFC4359">
        <front>
          <title>
          The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
          </title>
          <author initials="B." surname="Weis" fullname="B. Weis"><organization/></author>
          <date year="2006" month="January"/>
        </front>
        <seriesInfo name="RFC" value="4359"/>
        <format type="TXT" octets="26989" target="ftp://ftp.isi.edu/in-notes/rfc4359.txt"/>
      </reference>

      <?rfc include='reference.RFC.3447'?>

      <reference anchor="NTP-NTPv4">
        <front>
          <title>The Network Time Protocol Version 4 Protocol Specification</title>
          <author initials="J." surname="Burbank" fullname="Jack Burbank"><organization/></author>
          <author initials="W." surname="Kasch" fullname="W. Kasch"><organization/></author>
          <author initials="J." surname="Martin" fullname="J. Martin"><organization/></author>
          <author initials="D." surname="Mills" fullname="David L. Mills"><organization/></author>
          <date month="September" year="2008"/>
        </front>
        <seriesInfo name="" value="draft-ietf-ntp-ntpv4-proto-11.txt (work in progress)"/>
      </reference>

      <reference anchor="RFC1305">
        <front>
          <title>Network Time Protocol (Version 3) Specification, Implementation</title>
          <author initials="D." surname="Mills" fullname="David L. Mills">
            <organization />
          </author>
          <date year="1992" month="March"/>
        </front>
        <seriesInfo name="RFC" value="1305"/>
        <format type="TXT" octets="307085" target="ftp://ftp.isi.edu/in-notes/rfc1305.txt"/>
        <format type="PDF" octets="442493" target="ftp://ftp.isi.edu/in-notes/rfc1305.pdf"/>
      </reference>

      <reference anchor="RFC4330">
        <front>
          <title>Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI</title>
          <author initials="D." surname="Mills" fullname="David L. Mills">
            <organization/>
          </author>
          <date year="2006" month="January"/>
        </front>
        <seriesInfo name="RFC" value="4330"/>
	<format type="TXT" octets="67930" target="ftp://ftp.isi.edu/in-notes/rfc4330.txt"/>
      </reference>

      <reference anchor="RFC2104">
        <front>
          <title abbrev="HMAC">HMAC: Keyed-Hashing for Message Authentication</title>
          <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
            <organization>IBM, T.J. Watson Research Center</organization>
          </author>
          <author initials="M." surname="Bellare" fullname="Mihir Bellare">
            <organization>University of California at San Diego, Dept of Computer Science and Engineering</organization>
          </author>
          <author initials="R." surname="Canetti" fullname="Ran Canetti">
            <organization>IBM T.J. Watson Research Center</organization>
          </author>
          <date year="1997" month="February"/>
        </front>
        <seriesInfo name="RFC" value="2104"/>
        <format type="TXT" octets="22297" target="ftp://ftp.isi.edu/in-notes/rfc2104.txt"/>
      </reference>

    </references>



    </back>

</rfc>

--------------090102000001000200050109--

From zhangdong_rh@huaweisymantec.com  Wed Sep 16 19:39:54 2009
Return-Path: <zhangdong_rh@huaweisymantec.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFCD3A65A6; Wed, 16 Sep 2009 19:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.05
X-Spam-Level: 
X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=1.549,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbkpOc9N7yVj; Wed, 16 Sep 2009 19:39:53 -0700 (PDT)
Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 419433A6830; Wed, 16 Sep 2009 19:39:53 -0700 (PDT)
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 <0KQ3000QMGR9AB60@hstga01-in.huaweisymantec.com>; 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>; Thu, 17 Sep 2009 10:40:21 +0800 (CST)
Date: Thu, 17 Sep 2009 10:40:21 +0800
From: Dong Zhang <zhangdong_rh@huaweisymantec.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Hesham Soliman <hesham@elevatemobile.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <39C363776A4E8C4A94691D2BD9D1C9A10665C90F@XCH-NW-7V2.nw.nos.boeing.com> <C6D56852.F4CD%hesham@elevatemobile.com> <39C363776A4E8C4A94691D2BD9D1C9A10665CEC7@XCH-NW-7V2.nw.nos.boeing.com>
Message-id: <200909171040210476174@huaweisymantec.com>
X-Mailer: Foxmail 6, 10, 201, 20 [cn]
X-Mailman-Approved-At: Wed, 16 Sep 2009 23:28:56 -0700
Cc: v6ops <v6ops@ops.ietf.org>, Christian Huitema <huitema@microsoft.com>, "ipv6@ietf.org" <ipv6@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2009 02:39:54 -0000

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 j.schoenwaelder@jacobs-university.de  Thu Sep 17 07:11:26 2009
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B9E3A6B3A; Thu, 17 Sep 2009 07:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level: 
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_53=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 P45FSLflA8Ro; Thu, 17 Sep 2009 07:11:25 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2EE03A6A9C; Thu, 17 Sep 2009 07:11:23 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E391EC0047; Thu, 17 Sep 2009 16:12:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id H6i77gmbySti; Thu, 17 Sep 2009 16:12:04 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D8E6C0063; Thu, 17 Sep 2009 16:11:58 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id BB7C6CB9230; Thu, 17 Sep 2009 16:11:56 +0200 (CEST)
Date: Thu, 17 Sep 2009 16:11:56 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: rahul@juniper.net, erosen@cisco.com
Message-ID: <20090917141156.GC7271@elstar.local>
Mail-Followup-To: rahul@juniper.net, erosen@cisco.com, iesg@ietf.org, secdir@ietf.org, l3vpn-chairs@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: l3vpn-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-l3vpn-2547bis-mcast-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2009 14:11:26 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

First of all, let me state that I did not do a detailed review of the
document. The ID is ~90 pages and depends on another twin ID (~60
pages)and they again depend on some other RFCs of some 30 pages each
and since I am not deeply involved in BGP/MPLS VPNs it would have
taken me days to do a detailed review. So I ended up trying to
understand what the document is about and then making sense of the
security considerations section. Here is what I found:

a) p90: I assume 2547 means RFC 2547, so

   s/of 2547 VPNs/of RFC 2547 VPNs/

   but then I checked and RFC 2547 has been obsoleted by RFC 4364
   so probably this should be

   s/of 2547 VPNs/of RFC 4364 VPNs/

b) p91: missing opening bracket

   s/BGP MVPN-BGP]/BGP [MVPN-BGP]/

c) p91: double "as"

   s/techniques as as/techniques as/

d) The paragraph talking about P-tunnel construction should probably
   be using stronger MUST language, e.g.

   [...] P or PE router receiving a control MUST ensure that the
   control message comes from another P or PE router, not from a CE
   router.

   Right now, I find the message of the paragraph somewhat unclear.

e) I am wondering why "should not allow" is used in the discussion of
   extending multicast distribution trees. Perhaps some text can be
   added under which circumstances it makes sense to configure the
   ASBR to allow this and which risks this involves. (Perhaps this
   just shows my ignorance. ;-)

/js


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From stefan@aaa-sec.com  Thu Sep 17 22:33:08 2009
Return-Path: <stefan@aaa-sec.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958203A68B3 for <secdir@core3.amsl.com>; Thu, 17 Sep 2009 22:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d64vNszKUdjt for <secdir@core3.amsl.com>; Thu, 17 Sep 2009 22:33:08 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 05ADC3A6801 for <secdir@ietf.org>; Thu, 17 Sep 2009 22:33:06 -0700 (PDT)
Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DB6F128BEA3 for <secdir@ietf.org>; Fri, 18 Sep 2009 07:25:09 +0200 (CEST)
Received: (qmail 48341 invoked from network); 18 Sep 2009 05:25:09 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <iesg@ietf.org>; 18 Sep 2009 05:25:09 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Fri, 18 Sep 2009 07:25:08 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: <iesg@ietf.org>, <secdir@ietf.org>, <rahul@juniper.net>, <erosen@cisco.com>, <thomas.morin@francetelecom.com>, <yakov@juniper.net>, Danny McPherson <danny@arbor.net>, Marshall Eubanks <tme@multicasttech.com>, Ross Callon <rcallon@juniper.net>
Message-ID: <C6D8E654.4A77%stefan@aaa-sec.com>
Thread-Topic: Secdir review of draft-ietf-l3vpn-2547bis-mcast-bgp-07
Thread-Index: Aco4IGK6TR35B5v9cUiRZN9bnck0HA==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [secdir] Secdir review of draft-ietf-l3vpn-2547bis-mcast-bgp-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2009 05:33:08 -0000

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document describes the BGP encodings and procedures for exchanging the
information elements required by Multicast in MPLS/BGP IP VPNs, as specified
in draft-ietf-l3vpn-2547bis-mcast.

I would like to draw the Security AD's attention to consider whether the
security considerations section of this draft contains adequate information.

The security considerations section of this draft list a number of security
requirements, but very few considerations. That is, the section list
requirements but says very little, if anything at all, about the security
threats that are addressed by these requirements or whether handling of
these security threats falls inside or outside the scope of this document.

It is hard to review these security requirements in absence of a discussion
of the threats they are supposed to address.

/Stefan



From blourdel@cisco.com  Fri Sep 18 02:26:19 2009
Return-Path: <blourdel@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF2B3A698A; Fri, 18 Sep 2009 02:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2QUwYrpZatn; Fri, 18 Sep 2009 02:26:17 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2E8543A696D; Fri, 18 Sep 2009 02:26:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlcAAE3vskqQ/uCLe2dsb2JhbACbIgEBFiQGnxWIUAErCI92BYJBCIFTgV0
X-IronPort-AV: E=Sophos;i="4.44,408,1249257600"; d="scan'208";a="49686832"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2009 09:27:09 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8I9R9Xj022734;  Fri, 18 Sep 2009 11:27:09 +0200
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8I9R9oQ008021; Fri, 18 Sep 2009 09:27:09 GMT
Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 18 Sep 2009 11:27:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Sep 2009 11:27:09 +0200
Message-ID: <877805C876DB9243984870AAD14107624B4E55@XMB-AMS-103.cisco.com>
In-Reply-To: <016001ca252c$25904100$70b0c300$@net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt
Thread-Index: AcolLCTTApFFO1pSRNWe+MFZxKd61gSif6mg
References: <016001ca252c$25904100$70b0c300$@net>
From: "Benoit Lourdelet (blourdel)" <blourdel@cisco.com>
To: "Glen Zorn" <gwz@net-zen.net>, <iesg@ietf.org>, <secdir@ietf.org>, <richard.gayraud@free.fr>, "Brian Haberman" <brian@innovationslab.net>,  "Karen O'Donoghue" <kodonog@pobox.com>
X-OriginalArrivalTime: 18 Sep 2009 09:27:09.0468 (UTC) FILETIME=[3232FDC0:01CA3842]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4901; t=1253266029; x=1254130029; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20<blourdel@ cisco.com> |Subject:=20RE=3A=20secdir=20review=20of=20draft-ietf-ntp-d hcpv6-ntp-opt-04.txt |Sender:=20; bh=Fz3o/IONw/68qv6r1nC2NORHKosW9fr1jHLzTNCE87M=; b=Ec8IIkdejSR8Ht8IOQwhzdbWyssS4Udm68FQS7wsOGjAByPmZkMrZXEH8f IRE8BrD80LpV+AHXDDWkBnCw01iZpq6y2iASmZXBXIi1j29ovwmrrbie2ZGW fGMB8ZjTl1;
Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 
X-Mailman-Approved-At: Fri, 18 Sep 2009 06:39:40 -0700
Subject: Re: [secdir] secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2009 09:26:19 -0000

Hello,

The comments that require discussion are signaled by BL>>

The rest of the comments are taken into account.

Benoit

-----Original Message-----
From: Glen Zorn [mailto:gwz@net-zen.net]=20
Sent: Tuesday, August 25, 2009 4:31 AM
To: iesg@ietf.org; secdir@ietf.org; Benoit Lourdelet (blourdel);
richard.gayraud@free.fr; 'Brian Haberman'; 'Karen O'Donoghue'
Subject: secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt

I have reviewed this document as part of the security directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.



EDITORIAL

Global: s/an NTP/a NTP/
        s/an FQDN/a FQDN/


In section 2., the acronym "DHCPv6" should be expanded on first usage.

The first paragraph of section 2.1 says:

   When using DHCPv6 to offer NTP Server location, and if
   there is a need to distribute a device with a hardcoded
   configuration, this configuration MUST NOT include server location
   that is not part of the organization that distribute this device.

s/distribute/distributes in the last line.
I don't understand what device is under discussion.  Is it a DHCP
server?  A
DHCP client?  Also,

   Typical usage of this option is to specify an NTP Server that is part
   of the organization that operates the DHCPv6 server.

This seems less clear than it should be to me; suggest rephrasing,
perhaps
as=20

  This option will typically be used by the organization operating the
DHCPv6=20
  server to provide data regarding the location of its own NTP server.
BL>> that is the point. The  suggested usage is to have the DHCPv6
server and the NTP server pointed to in the same organization.
This to prevent overloading public servers.


The second paragraph of section 2.1 says:

   DNS can be used to redirect misconfigured clients
   to an unexisting IPv6 address instead of having to change the address
   of the NTP server itself.

I don't know exactly what an "unexisting IPv6 address" is, nor why it
would
be a good thing to redirect misconfigured clients to one.  Also, the
acronym
"FQDN" should be expanded on first usage.
BL>> The idea is to blackhole malicious traffic.


The third paragraph of section 2.1 says: "The DHCPv6 option for NTP is
then
restricted to server location."  This construction is a little bit
clumsy, I
think; suggest changing to "The DHCPv6 option for NTP is therefore
restricted to server location."


In the first paragraph of section 3.0, the acronym "SNTP" should be
expanded
upon first usage; suggest changing "This option serves as a container
for
all the information related to one NTP server or SNTP server." to "This
option serves as a container for all the information related to one NTP
or
Simple Network Time Protocol (SNTP) [RFC4335] server."  This will also
take
care of one of the unused references mentioned below.

BL>> RFC4330 instead.

The second paragraph of section 3.0 says:

   While the FQDN option offers the most deployment
   flexibility, resiliency as well as security, the IP address options
   are defined to cover cases where a dependancy to DNS is not
   desirable.

I think that the readability of this sentence could be improved; suggest
changing to=20

   While the FQDN option offers the most deployment Flexibility and=20
   resiliency as well as security, the IP address options are defined=20
   to cover cases where a DNS dependency is not desirable.


The last paragraph of section 3.0 says:

   This document does not define any priority between the client's
   embedded configuration and the NTP servers or SNTP servers discovered
   via this option. =20

Suggest changing to=20

   This document does not define any priority relationship between the
client's
   embedded configuration (if any) and the NTP or SNTP servers
discovered
   via this option. =20


In the heading of section 4, capitalize "use" or just change the heading
from "Examples of use" to "Examples".


Section 4 seems somewhat less than useful to me, especially since the
examples are inconsistent: the FQDN example uses the exact encoding of
the
FQDN, but the unicast and multicast address examples do not.  I suggest
either making the examples consistent by putting the actual address
encoding
of the addresses in the address examples or just getting rid of section
4
altogether.

BL>> If that works for everybody I remove the example section for now.

The references to RFC 4075 and RFC 4330 are defined but never used.

BL>> RFC4330 is no in use. RFC4075 is in use in the new version of the
ID that explain its relation to RFC4075.

Hope this helps.

~gwz





From cwallace@cygnacom.com  Fri Sep 18 11:49:13 2009
Return-Path: <cwallace@cygnacom.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C113A68BE; Fri, 18 Sep 2009 11:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.03
X-Spam-Level: 
X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=-0.431,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e801kR30r1Bh; Fri, 18 Sep 2009 11:49:11 -0700 (PDT)
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by core3.amsl.com (Postfix) with ESMTP id DC57F3A6B84; Fri, 18 Sep 2009 11:49:04 -0700 (PDT)
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 856d3ba4.87493552.88500.00-010.p03c11o141.symantecmail.net (envelope-from <cwallace@cygnacom.com>);  Fri, 18 Sep 2009 12:50:00 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 18 Sep 2009 14:49:58 -0400
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D48CD7CF2@scygexch1.cygnacom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secdir review of draft-ietf-dime-diameter-cmd-iana-01.txt
Thread-Index: Aco4kNH88gnA1/o1Txubi8Bd+XmFYQ==
From: "Carl Wallace" <CWallace@cygnacom.com>
To: <secdir@ietf.org>, <iesg@ietf.org>, <dromasca@avaya.com>, <Hannes.Tschofenig@gmx.net>
X-Spam: [F=0.2000000000; S=0.200(2009090401)]
X-MAIL-FROM: <cwallace@cygnacom.com>
X-SOURCE-IP: [65.242.48.5]
Subject: [secdir] secdir review of draft-ietf-dime-diameter-cmd-iana-01.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2009 18:49:13 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document relaxes the requirements in the IANA considerations
section of RFC 3588 to allow a chunk of the possible command code space
to be vendor specific instead of requiring IETF review of all possible
command codes.  The security considerations section is probably fine
as-is but might benefit from addition of some discussion regarding
consequences of reusing command codes (interoperability problems are
mentioned in the introduction).  A few nits are below.

- The first sentence of the abstract (and introduction) is difficult to
parse. =20
- In the Introduction, change "the conditions, which" to "the conditions
that" and change "were causes" to "were caused".
- The document states that it "aligns the extensibility rules for
Diameter command codes with those defined for Diameter application
identifiers".  Since the values are not aligned and there's no mention
of "extensibility rules" elsewhere in this document nor in 3588, I
suggest something like: "This document changes the allocation rules for
Diameter command codes to support usage of vendor specific command
codes, similar to the allocation of vendor specific application
identifiers."  =20
- It might be worth noting that this draft updates RFC 3588 independent
of its pending successor (or maybe this draft should be informational if
it is really only providing a preview of 3588bis).

From weiler+secdir@watson.org  Fri Sep 18 11:57:33 2009
Return-Path: <weiler+secdir@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FDC3A68BE for <secdir@core3.amsl.com>; Fri, 18 Sep 2009 11:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.39
X-Spam-Level: 
X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZDRe7yA7G+X for <secdir@core3.amsl.com>; Fri, 18 Sep 2009 11:57:32 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 8BD593A67E3 for <secdir@ietf.org>; Fri, 18 Sep 2009 11:57:32 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n8IIwQVH019602 for <secdir@ietf.org>; Fri, 18 Sep 2009 14:58:26 -0400 (EDT) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n8IIwQC2019599 for <secdir@ietf.org>; Fri, 18 Sep 2009 14:58:26 -0400 (EDT) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 18 Sep 2009 14:58:26 -0400 (EDT)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.0909181456510.16380@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Fri, 18 Sep 2009 14:58:26 -0400 (EDT)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2009 18:57:33 -0000

Shawn Emery is next in the rotation.

Please try to complete last call reviews by the end of the last call. 
For documents on telechat, note that the deadline field shown below 
reflects the telechat date, even though last call likely expires (or 
expired) before then.

Review instructions and related resources are at:
       http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam


For telechat 2009-09-24

Reviewer                 Deadline   Draft
Derek Atkins           TR2009-09-22 draft-ietf-roll-building-routing-reqs-07
Phillip Hallam-Baker   T 2009-09-22 draft-ietf-pmol-sip-perf-metrics-04
Steve Hanna            TR2009-09-22 draft-peterson-rai-rfc3427bis-03
Sam Hartman            TR2009-09-22 draft-ietf-opsawg-operations-and-management-09
Juergen Schoenwaelder  TR2009-09-22 draft-harkins-emu-eap-pwd-06
Yaron Sheffer          T 2009-09-22 draft-ietf-calsify-2446bis-09
Hannes Tschofenig      T 2009-09-22 draft-ietf-pkix-ta-format-03


For telechat 2009-10-08

Reviewer                 Deadline   Draft
Richard Barnes         T 2009-10-06 draft-ietf-yam-rfc1652bis-pre-evaluation-00
Dave Cridland          T 2009-10-06 draft-ietf-ipsecme-ikev2-ipv6-config-02
Steve Hanna            T 2009-10-06 draft-ietf-krb-wg-cross-problem-statement-04

Last calls and special requests:

Reviewer                 Deadline   Draft
Derek Atkins             2009-09-17 draft-ietf-rohc-ipsec-extensions-hcoipsec-05
Rob Austein              2009-10-07 draft-reschke-rfc2731bis-02
Pat Cain                 2009-09-30 draft-ietf-vcarddav-carddav-09
Ran Canetti              2009-09-28 draft-ietf-sasl-scram-07
Alan DeKok               2009-08-17 draft-turner-deviceowner-attribute-01
Alan DeKok               2009-10-01 draft-ietf-enum-enumservices-transition-03
Donald Eastlake          None       draft-ietf-geopriv-held-identity-extensions-00
Shawn Emery              2009-08-04 draft-ietf-alto-problem-statement-04
Love Hornquist-Astrand   2009-03-31 draft-ietf-ipfix-mib-07
Love Hornquist-Astrand   2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05
Julien Laganier          2009-01-22 draft-ietf-sip-certs-09
Julien Laganier          2009-06-09 draft-ietf-enum-3761bis-04
Catherine Meadows        2008-01-17 draft-ietf-speechsc-mrcpv2-20
Sandy Murphy             2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-14
Sandy Murphy             2009-09-04 draft-ietf-rtgwg-ipfrr-framework-11
Vidya Narayanan          2008-11-21 draft-ietf-sip-saml-06
Chris Newman             2009-09-04 draft-ietf-mboned-lightweight-igmpv3-mldv2-05
Eric Rescorla            2009-09-07 draft-ietf-tls-rfc4366-bis-05
Joe Salowey              2009-02-08 draft-ietf-geopriv-lis-discovery-11
Hannes Tschofenig        2009-04-23 draft-ietf-pce-monitoring-05
Hannes Tschofenig        2009-10-07 draft-carpenter-renum-needs-work-03
Carl Wallace             2009-09-22 draft-ietf-dime-diameter-cmd-iana-01
Sam Weiler               2008-08-13 draft-chown-v6ops-rogue-ra-03
Sam Weiler               2009-09-23 draft-ietf-eai-downgraded-display-02
Brian Weis               2009-09-22 draft-ietf-mipshop-pfmipv6-09
Nico Williams            2008-08-13 draft-ietf-v6ops-ra-guard-03
Nico Williams            2009-09-22 draft-ietf-nfsv4-federated-fs-reqts-03
Tom Yu                   2009-09-22 draft-ietf-rmt-pi-alc-revised-08
Larry Zhu                2008-08-13 draft-thaler-v6ops-teredo-extensions-04
Larry Zhu                2009-05-09 draft-ietf-ecrit-location-hiding-req-02
Larry Zhu                2009-09-17 draft-ietf-rohc-hcoipsec-11
Glen Zorn                2009-09-17 draft-ietf-rohc-ikev2-extensions-hcoipsec-09



From derek@ihtfp.com  Sat Sep 19 16:07:01 2009
Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E373A67DD; Sat, 19 Sep 2009 16:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq7mr472WaMl; Sat, 19 Sep 2009 16:06:59 -0700 (PDT)
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id CA0DC3A6993; Sat, 19 Sep 2009 16:06:59 -0700 (PDT)
Received: from pgpdev.ihtfp.org (unknown [69.7.239.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id F37A18B4005; Sat, 19 Sep 2009 19:07:52 -0400 (EDT)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id n8JN7mZ6029939; Sat, 19 Sep 2009 19:07:48 -0400
To: iesg@ietf.org, secdir@ietf.org
From: Derek Atkins <derek@ihtfp.com>
Date: Sat, 19 Sep 2009 19:07:47 -0400
Message-ID: <sjmy6oaleik.fsf@pgpdev.ihtfp.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: rohc-chairs@tools.ietf.org, christou_chris@bah.com, cabo@tzi.org, ertekin_emre@bah.com
Subject: [secdir] sec-dir review of draft-ietf-rohc-ipsec-extensions-hcoipsec-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Sep 2009 23:07:01 -0000

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

   Integrating Robust Header Compression (ROHC) with IPsec
   (ROHCoIPsec) offers the combined benefits of IP security services
   and efficient bandwidth utilization.  However, in order to
   integrate ROHC with IPsec, extensions to the SPD and SAD are
   required.  This document describes the IPsec extensions required to
   support ROHCoIPsec.

While not a security issue, I believe that you should include the
expansion of ROHC in the Abstract.

I believe the security considerations section adequately provide
guidance for the pitfalls of poor algorithm choice and known traffic
analysis attacks.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From derek@ihtfp.com  Sat Sep 19 16:27:19 2009
Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3844E3A68C8; Sat, 19 Sep 2009 16:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.875
X-Spam-Level: 
X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUZQAb5GG0U3; Sat, 19 Sep 2009 16:27:18 -0700 (PDT)
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 1A8423A67EE; Sat, 19 Sep 2009 16:27:18 -0700 (PDT)
Received: from pgpdev.ihtfp.org (unknown [69.7.239.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 8375D8B4005; Sat, 19 Sep 2009 19:28:15 -0400 (EDT)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id n8JNSCF7030014; Sat, 19 Sep 2009 19:28:12 -0400
To: iesg@ietf.org, secdir@ietf.org
From: Derek Atkins <derek@ihtfp.com>
Date: Sat, 19 Sep 2009 19:28:12 -0400
Message-ID: <sjmtyyyldkj.fsf@pgpdev.ihtfp.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: pieter.demil@intec.ugent.be, nicolas.riou@fr.schneider-electric.com, jerald.p.martocci@jci.com, wouter@vooruit.be, roll-chairs@tools.ietf.org
Subject: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Sep 2009 23:27:19 -0000

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

   The Routing Over Low power and Lossy network (ROLL) Working Group has
   been chartered to work on routing solutions for Low Power and Lossy
   networks (LLN) in various markets: Industrial, Commercial (Building),
   Home and Urban networks. Pursuant to this effort, this document
   defines the IPv6 routing requirements for building automation.

First, this document has no section named "Security Considerations".
There is a "Security Requirements" sub-section (5.8) which looks like
it might be the "Security Considerations" section misnamed and poorly
placed in the document structure.

Second, the new "Security Requirements" sub-section matches the
contents of the "Security Considerations" section of version 05 of
this document, almost word-for-word.  Therefore my review from version
05 still applies.  Here is what I said:

> The Security Considerations appear to take into account various
> requirements for different systems.  What seems to be lacking is
> direction about how or when to apply various requirements and what
> it means to the deployment.
> 
> For example, what would it mean to a deployment if it has
> authentication versus not having authentication?  Also, it's unclear
> how these requirements would apply to an implementor.
> 
> Variable security policies is a good idea, but it requires more
> guidance because the end user will never understand the ramifications
> of choosing one policy over another.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From Adrian.Farrel@huawei.com  Sun Sep 20 02:59:45 2009
Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE05B3A682C; Sun, 20 Sep 2009 02:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.855
X-Spam-Level: 
X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyztmR3J2sth; Sun, 20 Sep 2009 02:59:45 -0700 (PDT)
Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id F08D53A6939; Sun, 20 Sep 2009 02:59:44 -0700 (PDT)
Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ900L40L4VDJ@lhrga01-in.huawei.com>; Sun, 20 Sep 2009 11:00:32 +0100 (BST)
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0KQ900H10L4MMN@lhrga01-in.huawei.com>; Sun, 20 Sep 2009 11:00:26 +0100 (BST)
Date: Sun, 20 Sep 2009 11:00:08 +0100
From: Adrian Farrel <Adrian.Farrel@huawei.com>
To: Derek Atkins <derek@ihtfp.com>, iesg@ietf.org, secdir@ietf.org
Message-id: <9C47E4DAD6D4409488F2107ADD4C964A@your029b8cecfe>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <sjmtyyyldkj.fsf@pgpdev.ihtfp.org>
Cc: nicolas.riou@fr.schneider-electric.com, jerald.p.martocci@jci.com, pieter.demil@intec.ugent.be, wouter@vooruit.be, roll-chairs@tools.ietf.org
Subject: Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <Adrian.Farrel@huawei.com>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Sep 2009 09:59:46 -0000

Hi Derek,

I very much appreciate your review.

It is important to understand that this document specifies requirements that 
must/should/etc be satisfied by a protocol designed by the working group. 
Thus, there is no question of what should be deployed or what should be 
implemented.

That is, the document specifies what must be in the protocol spec. We can 
expect the protocol spec to discuss what must be implemented. And either the 
protocol spec or an applicability statement would describe what must be 
deployed.

So, the concerns you raise would be very important in the final protocol 
spec (and I hope the chairs and authors are paying attention), but do not 
seem to me to fit in this document.

Thanks,
Adrian

>> The Security Considerations appear to take into account various
>> requirements for different systems.  What seems to be lacking is
>> direction about how or when to apply various requirements and what
>> it means to the deployment.
>>
>> For example, what would it mean to a deployment if it has
>> authentication versus not having authentication?  Also, it's unclear
>> how these requirements would apply to an implementor.
>>
>> Variable security policies is a good idea, but it requires more
>> guidance because the end user will never understand the ramifications
>> of choosing one policy over another.



From secdir-bounces@mit.edu  Sun Sep 20 13:25:47 2009
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B863A67AE for <secdir@core3.amsl.com>; Sun, 20 Sep 2009 13:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.62
X-Spam-Level: 
X-Spam-Status: No, score=-4.62 tagged_above=-999 required=5 tests=[AWL=1.979,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqRFA4zlGzis for <secdir@core3.amsl.com>; Sun, 20 Sep 2009 13:25:47 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id F3C6B3A67F5 for <secdir@ietf.org>; Sun, 20 Sep 2009 13:25:46 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8KKQkcI004191 for <secdir@ietf.org>; Sun, 20 Sep 2009 16:26:46 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8KKQfFV004182 for <secdir@PCH.mit.edu>; Sun, 20 Sep 2009 16:26:41 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8KKQWBN021632 for <secdir@mit.edu>; Sun, 20 Sep 2009 16:26:33 -0400 (EDT)
Received: from mx11.bbn.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 7EE3F2022B9D for <secdir@mit.edu>; Sun, 20 Sep 2009 16:26:32 -0400 (EDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu with ESMTP id 1FJcDdfbcGTbuzj4 for <secdir@mit.edu>; Sun, 20 Sep 2009 16:26:31 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of rbarnes@bbn.com designates 128.33.0.80 as permitted sender) receiver=mit.edu; client_ip=128.33.0.80; envelope-from=rbarnes@bbn.com; 
Received: from [128.89.252.130] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <rbarnes@bbn.com>) id 1MpS3H-0007XQ-Ep; Sun, 20 Sep 2009 15:26:28 -0400
Message-ID: <4AB68FF3.40107@bbn.com>
Date: Sun, 20 Sep 2009 16:26:27 -0400
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: IESG <iesg@ietf.org>, SECDIR <secdir@mit.edu>, IETF Discussion <ietf@ietf.org>, draft-ietf-yam-rfc1652bis-pre-evaluation@tools.ietf.org
References: <4A83616C.1030506@bbn.com>
In-Reply-To: <4A83616C.1030506@bbn.com>
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Subject: [secdir] SECDIR review of	draft-ietf-yam-rfc1652bis-pre-evaluation-00
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Sep 2009 20:25:47 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
  These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

This document provides a set of observations on whether the SMTP Service 
Extension for 8bit-MIMEtransport (RFC 1652) should be advanced from 
Draft Standard to Standard.  It matches the document against the 
criteria of RFC 2026, and poses questions to the IESG about the 
acceptability of the document for a full Standard, along three axes:
1. Proposed changes
2. Any other changes necessary (none listed)
3. Downward references

I do not believe that this document raises any security concerns beyond 
those of the underlying document (RFC 1652).  All of the proposed 
changes are simple updates to current references (e.g., adding RFC 5321 
in addition to RFC 821).  None of the proposed changes or downward 
references are related to the security of the protocol.

--Richard
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir

From yaronf@checkpoint.com  Sun Sep 20 23:01:25 2009
Return-Path: <yaronf@checkpoint.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C491A3A67A5; Sun, 20 Sep 2009 23:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level: 
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gRaYcV4ignm; Sun, 20 Sep 2009 23:01:21 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B022E3A67A4; Sun, 20 Sep 2009 23:01:20 -0700 (PDT)
X-CheckPoint: {4AB7160C-5-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9F91A29C005; Mon, 21 Sep 2009 09:02:20 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7A18829C002; Mon, 21 Sep 2009 09:02:20 +0300 (IDT)
X-CheckPoint: {4AB7160C-0-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8L62JSr026810; Mon, 21 Sep 2009 09:02:20 +0300 (IDT)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 21 Sep 2009 09:02:19 +0300
From: Yaron Sheffer <yaronf@checkpoint.com>
To: secdir <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-calsify-2446bis.all@tools.ietf.org" <draft-ietf-calsify-2446bis.all@tools.ietf.org>
Date: Mon, 21 Sep 2009 09:02:17 +0300
Thread-Topic: SecDir review of draft-ietf-calsify-2446bis-09
Thread-Index: Aco6gRMGhqy0iK79QF6p8HpEuJDpzw==
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370ilex01adche_"
MIME-Version: 1.0
Subject: [secdir] SecDir review of draft-ietf-calsify-2446bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2009 06:01:25 -0000

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370ilex01adche_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's ongoing=
 effort to review all IETF documents being processed by the IESG.  These co=
mments were written primarily for the benefit of the security area director=
s.  Document editors and WG chairs should treat these comments just like an=
y other last call comments.

This document is a refresh of the 1998 iTip, an abstract transport protocol=
 for iCalendar objects. This protocol is then instantiated for specific tra=
nsports, e.g. RFC 2447, iMip (mail transport).

General

The original RFC 2446 security considerations seem extensive enough, and th=
e proposed mitigations are reasonable. I believe the changes in -bis do not=
 require additional work in this area (but see below).

Reality Check

If basing the entire security of the protocol on S/MIME may have been reaso=
nable in 1998, today this is almost meaningless. S/MIME is too rarely used =
to protect mail in transit, and I would imagine its use to protect calendar=
ing is even less prevalent.

Security

- In Sec. 6.2, replace "encrypted" by "encrypted and authenticated".
- An attack that is never mentioned is unauthorized creation of events. In =
many enterprise situations not everyone is authorized to invite the CEO, fo=
r example. Similarly, there may be tight control over who is allowed to del=
egate to whom. This obviously calls for an access control mechanism, someth=
ing that is never mentioned in the document.

Nits

- 1.4: in table, objecy -> object
- 3.2.5 and 3.4.5: is MUST -> MUST

=0D=0A
Email secured by Check Point=0D=0A

=0D=0A
Email secured by Check Point=0D=0A

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370ilex01adche_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>I have reviewed this document as part of the security
directorate's ongoing effort to review all IETF documents being processed b=
y
the IESG.&nbsp; These comments were written primarily for the benefit of th=
e
security area directors.&nbsp; Document editors and WG chairs should treat
these comments just like any other last call comments.<o:p></o:p></span></f=
ont></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>This document is a refresh of the 1998 iTip, an abstract=
 transport
protocol for iCalendar objects. This protocol is then instantiated for spec=
ific
transports, e.g. RFC 2447, iMip (mail transport).<o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>General<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>The original RFC 2446 security considerations seem exten=
sive
enough, and the proposed mitigations are reasonable. I believe the changes =
in -bis
do not require additional work in this area (but see below).<o:p></o:p></sp=
an></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Reality Check<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>If basing the entire security of the protocol on S/MIME =
may
have been reasonable in 1998, today this is almost meaningless. S/MIME is t=
oo rarely
used to protect mail in transit, and I would imagine its use to protect
calendaring is even less prevalent.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Security<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>- In Sec. 6.2, replace &#8220;encrypted&#8221; by &#8220=
;encrypted and authenticated&#8221;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>- An attack that is never mentioned is unauthorized crea=
tion
of events. In many enterprise situations not everyone is authorized to invi=
te
the CEO, for example. Similarly, there may be tight control over who is all=
owed
to delegate to whom. This obviously calls for an access control mechanism, =
something
that is never mentioned in the document.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Nits<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>- 1.4: in table, objecy -&gt; object<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>- 3.2.5 and 3.4.5: is MUST -&gt; MUST<o:p></o:p></span><=
/font></p>

</div>


<br>=
=0D=0A
<br>Email secured by Check Point=0D=0A
<br>
<br>=

<br>=
=0D=0A
<br>Email secured by Check Point=0D=0A
<br>
<br>=
</body>

</html>

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370ilex01adche_--

From j.schoenwaelder@jacobs-university.de  Mon Sep 21 01:34:12 2009
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCF33A6A3B; Mon, 21 Sep 2009 01:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.835
X-Spam-Level: 
X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=-1.186, BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X5bE8J0wNyl; Mon, 21 Sep 2009 01:34:12 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CF8D93A6829; Mon, 21 Sep 2009 01:34:11 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15C29C000D; Mon, 21 Sep 2009 10:34:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Tt8JkldzpT2B; Mon, 21 Sep 2009 10:34:03 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36751C001A; Mon, 21 Sep 2009 10:34:03 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0D5ABCF8AAA; Mon, 21 Sep 2009 10:34:02 +0200 (CEST)
Date: Mon, 21 Sep 2009 10:34:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: dharkins@arubanetworks.com, gwz@netcube.com
Message-ID: <20090921083401.GA9138@elstar.local>
Mail-Followup-To: dharkins@arubanetworks.com, gwz@netcube.com, iesg@ietf.org, secdir@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] secdir re-review of draft-harkins-emu-eap-pwd-06.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2009 08:34:12 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

All my previous comments concerning draft-harkins-emu-eap-pwd-04.txt
have been addressed, except perhaps this one:

c) There are two places where IANA assigned values need to be filled
   into the text; perhaps add more explicit RFC editor instructions so
   the editor knows what to fill in for 'TBD1'.

I assume the authors will check carefully during auth48 that correct
updates have been made by the RFC editor once IANA has assigned a
value.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From lear@cisco.com  Mon Sep 21 03:52:27 2009
Return-Path: <lear@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36693A6849; Mon, 21 Sep 2009 03:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.2
X-Spam-Level: 
X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[AWL=0.398,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1sKz4KLZFO2; Mon, 21 Sep 2009 03:52:26 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BE90C3A67F8; Mon, 21 Sep 2009 03:52:25 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoAAALD3tkqQ/uCKe2dsb2JhbACBU1YtmCIBARYkBp1qiFABjg4FhBs
X-IronPort-AV: E=Sophos;i="4.44,424,1249257600"; d="scan'208,217";a="49847209"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Sep 2009 10:53:25 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8LArPA4008148;  Mon, 21 Sep 2009 12:53:25 +0200
Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp7872.cisco.com [10.61.94.191]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8LArOS7009554; Mon, 21 Sep 2009 10:53:24 GMT
Message-ID: <4AB75B23.60409@cisco.com>
Date: Mon, 21 Sep 2009 12:53:23 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3
MIME-Version: 1.0
To: Yaron Sheffer <yaronf@checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com>
X-Enigmail-Version: 0.97a
Content-Type: multipart/alternative; boundary="------------010108020004050506040101"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9398; t=1253530405; x=1254394405; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20<lear@cisco.com> |Subject:=20Re=3A=20SecDir=20review=20of=20draft-ietf-calsi fy-2446bis-09 |Sender:=20; bh=PSYaLKAD0XPalX5Rj4BP9DvA7xOOVn71fTl/GNkd990=; b=cP2c2rPCXmXhVGMFvLVCH+efu4/eysTGwVt+XX404XPcR6DL7EXSezHzXq LbWZHHLBgitNVcRWHF4N/Cg1DHuoeN85RfoUcgVWpu8M9DgfaMXNkSRmhY3e VtMA+3qMrA;
Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
X-Mailman-Approved-At: Mon, 21 Sep 2009 03:57:49 -0700
Cc: "draft-ietf-calsify-2446bis.all@tools.ietf.org" <draft-ietf-calsify-2446bis.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, secdir <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-calsify-2446bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2009 10:52:27 -0000

This is a multi-part message in MIME format.
--------------010108020004050506040101
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Yaron,

Thank you for taking the time to review draft-ietf-calsify-2446bis-09. 
Cyrus should respond in due course to these comments.  I will note two
things:

1.  iTIP is meant to be implemented on top of a transport, such as mail
or some other means (perhaps carrier pigeon or swallow, or other more
sophisticated DTN).  We cannot assume at this layer that there is an
interactive bidirectional negotiating path.  As such the solution space
here is quite limited.  We would value your additional thoughts on this
subject.

2.  We should separate – even in rfc2447bis – encryption and
authentication.  Since RFC-2447 was released the world HAS changed, and
we should consider new approaches and mitigations to email
authenticaiton, such as DKIM.

Warmest regards,

Eliot

On 9/21/09 8:02 AM, Yaron Sheffer wrote:
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
>  
>
> This document is a refresh of the 1998 iTip, an abstract transport
> protocol for iCalendar objects. This protocol is then instantiated for
> specific transports, e.g. RFC 2447, iMip (mail transport).
>
>  
>
> General
>
>  
>
> The original RFC 2446 security considerations seem extensive enough,
> and the proposed mitigations are reasonable. I believe the changes in
> -bis do not require additional work in this area (but see below).
>
>  
>
> Reality Check
>
>  
>
> If basing the entire security of the protocol on S/MIME may have been
> reasonable in 1998, today this is almost meaningless. S/MIME is too
> rarely used to protect mail in transit, and I would imagine its use to
> protect calendaring is even less prevalent.
>
>  
>
> Security
>
>  
>
> - In Sec. 6.2, replace “encrypted� by “encrypted and authenticated�.
>
> - An attack that is never mentioned is unauthorized creation of
> events. In many enterprise situations not everyone is authorized to
> invite the CEO, for example. Similarly, there may be tight control
> over who is allowed to delegate to whom. This obviously calls for an
> access control mechanism, something that is never mentioned in the
> document.
>
>  
>
> Nits
>
>  
>
> - 1.4: in table, objecy -> object
>
> - 3.2.5 and 3.4.5: is MUST -> MUST
>
>
>
> Email secured by Check Point
>
>
>
> Email secured by Check Point
>


--------------010108020004050506040101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Yaron,<br>
<br>
Thank you for taking the time to review draft-ietf-calsify-2446bis-09. 
Cyrus should respond in due course to these comments.  I will note two
things:<br>
<br>
1.  iTIP is meant to be implemented on top of a transport, such as mail
or some other means (perhaps carrier pigeon or swallow, or other more
sophisticated DTN).  We cannot assume at this layer that there is an
interactive bidirectional negotiating path.  As such the solution space
here is quite limited.  We would value your additional thoughts on this
subject.<br>
<br>
2.  We should separate – even in rfc2447bis – encryption and
authentication.  Since RFC-2447 was released the world HAS changed, and
we should consider new approaches and mitigations to email
authenticaiton, such as DKIM.<br>
<br>
Warmest regards,<br>
<br>
Eliot<br>
<br>
On 9/21/09 8:02 AM, Yaron Sheffer wrote:
<blockquote
 cite="mid:7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  <meta name="Generator" content="Microsoft Word 11 (filtered medium)">
  <style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
  </style>
  <div class="Section1">
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">I have reviewed this
document as part of the security
directorate's ongoing effort to review all IETF documents being
processed by
the IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p> </o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">This document is a
refresh of the 1998 iTip, an abstract transport
protocol for iCalendar objects. This protocol is then instantiated for
specific
transports, e.g. RFC 2447, iMip (mail transport).<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p> </o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">General<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p> </o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">The original RFC 2446
security considerations seem extensive
enough, and the proposed mitigations are reasonable. I believe the
changes in -bis
do not require additional work in this area (but see below).<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p> </o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Reality Check<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p> </o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">If basing the entire
security of the protocol on S/MIME may
have been reasonable in 1998, today this is almost meaningless. S/MIME
is too rarely
used to protect mail in transit, and I would imagine its use to protect
calendaring is even less prevalent.<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p> </o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Security<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p> </o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">- In Sec. 6.2, replace
“encrypted� by “encrypted and authenticated�.<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">- An attack that is never
mentioned is unauthorized creation
of events. In many enterprise situations not everyone is authorized to
invite
the CEO, for example. Similarly, there may be tight control over who is
allowed
to delegate to whom. This obviously calls for an access control
mechanism, something
that is never mentioned in the document.<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p> </o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Nits<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p> </o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">- 1.4: in table, objecy
-&gt; object<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">- 3.2.5 and 3.4.5: is
MUST -&gt; MUST<o:p></o:p></span></font></p>
  </div>
  <br>
  <br>
Email secured by Check Point
  <br>
  <br>
  <br>
  <br>
Email secured by Check Point
  <br>
  <br>
</blockquote>
<br>
</body>
</html>

--------------010108020004050506040101--

From Jerald.P.Martocci@jci.com  Mon Sep 21 09:02:19 2009
Return-Path: <Jerald.P.Martocci@jci.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401AF28C186; Mon, 21 Sep 2009 09:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.34
X-Spam-Level: 
X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvLc6AQF5Ayx; Mon, 21 Sep 2009 09:02:18 -0700 (PDT)
Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by core3.amsl.com (Postfix) with ESMTP id D313D3A6A7A; Mon, 21 Sep 2009 09:01:53 -0700 (PDT)
Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKSrejlIFa4uUyhaD4JuUd8z9d9ps03IA3@postini.com; Mon, 21 Sep 2009 09:03:19 PDT
Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009092111060413-5075836 ; Mon, 21 Sep 2009 11:06:04 -0500 
In-Reply-To: <9C47E4DAD6D4409488F2107ADD4C964A@your029b8cecfe>
MIME-Version: 1.0
To: Derek Atkins <derek@ihtfp.com>
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
From: Jerald.P.Martocci@jci.com
Message-ID: <OF3BF99F7E.D8461727-ON86257638.0055170A-86257638.0057E142@jci.com>
Date: Mon, 21 Sep 2009 10:59:52 -0500
X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 09/21/2009 11:02:22 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 09/21/2009 11:06:04 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 09/21/2009 11:06:59 AM
Content-Type: multipart/mixed; boundary="=_mixed 0057E0C186257638_="
X-Mailman-Approved-At: Mon, 21 Sep 2009 13:23:00 -0700
Cc: secdir@ietf.org, nicolas.riou@fr.schneider-electric.com, pieter.demil@intec.ugent.be, iesg@ietf.org, roll-chairs@tools.ietf.org, wouter@vooruit.be, Adrian Farrel <Adrian.Farrel@huawei.com>
Subject: Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2009 16:02:19 -0000

--=_mixed 0057E0C186257638_=
Content-Type: multipart/alternative; boundary="=_alternative 0057E0C186257638_="


--=_alternative 0057E0C186257638_=
Content-Type: text/plain; charset="US-ASCII"

Hi Derek,

As the author of the document, I am trying to describe in this 
requirements ID the flexibility of setting up the security policies (as 
Adrian notes) rather then the application specifics of picking a security 
policy for a given application.  Earlier versions of this ID included this 
information, but was dropped since it was out of scope for the routing 
protocol. 

I have recently been requested to draft an ID for the 6LowAPP that would 
deal specifically with Building Applications at the application layer 
rather than at the routing layer.  Here, I intend to reinject into this 
new ID specificity as to when different security strategies are required. 
I have attached a spreadsheet that describes 5 different security policies 
(rows) that must be configurable for many different types of commercial 
buildings with the varying requirements for each building type (columns). 
I intend to redraft this spreadsheet into a section of the ID. 

I hope this is more of what you're looking for and can accept that I will 
put is into a separate ID.  If you think any of this should be put into 
the existing requirements ID, let me know and I will add it in.

Best Regards,

Jerry Martocci












Adrian Farrel <Adrian.Farrel@huawei.com> 
09/20/2009 05:00 AM
Please respond to
Adrian Farrel <Adrian.Farrel@huawei.com>


To
Derek Atkins <derek@ihtfp.com>, iesg@ietf.org, secdir@ietf.org
cc
pieter.demil@intec.ugent.be, nicolas.riou@fr.schneider-electric.com, 
jerald.p.martocci@jci.com, wouter@vooruit.be, roll-chairs@tools.ietf.org
Subject
Re: sec-dir review of draft-ietf-roll-building-routing-reqs-07






Hi Derek,

I very much appreciate your review.

It is important to understand that this document specifies requirements 
that 
must/should/etc be satisfied by a protocol designed by the working group. 
Thus, there is no question of what should be deployed or what should be 
implemented.

That is, the document specifies what must be in the protocol spec. We can 
expect the protocol spec to discuss what must be implemented. And either 
the 
protocol spec or an applicability statement would describe what must be 
deployed.

So, the concerns you raise would be very important in the final protocol 
spec (and I hope the chairs and authors are paying attention), but do not 
seem to me to fit in this document.

Thanks,
Adrian

>> The Security Considerations appear to take into account various
>> requirements for different systems.  What seems to be lacking is
>> direction about how or when to apply various requirements and what
>> it means to the deployment.
>>
>> For example, what would it mean to a deployment if it has
>> authentication versus not having authentication?  Also, it's unclear
>> how these requirements would apply to an implementor.
>>
>> Variable security policies is a good idea, but it requires more
>> guidance because the end user will never understand the ramifications
>> of choosing one policy over another.




--=_alternative 0057E0C186257638_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Hi Derek,</font>
<br>
<br><font size=2 face="sans-serif">As the author of the document, I am
trying to describe in this requirements ID the flexibility of setting up
the security policies (as Adrian notes) rather then the application specifics
of picking a security policy for a given application. &nbsp;Earlier versions
of this ID included this information, but was dropped since it was out
of scope for the routing protocol. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">I have recently been requested to draft
an ID for the 6LowAPP that would deal specifically with Building Applications
at the application layer rather than at the routing layer. &nbsp;Here,
I intend to reinject into this new ID specificity as to when different
security strategies are required. &nbsp;I have attached a spreadsheet that
describes 5 different security policies (rows) that must be configurable
for many different types of commercial buildings with the varying requirements
for each building type (columns). &nbsp;I intend to redraft this spreadsheet
into a section of the ID. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">I hope this is more of what you're looking
for and can accept that I will put is into a separate ID. &nbsp;If you
think any of this should be put into the existing requirements ID, let
me know and I will add it in.</font>
<br>
<br><font size=2 face="sans-serif">Best Regards,</font>
<br>
<br><font size=2 face="sans-serif">Jerry Martocci</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Adrian Farrel &lt;Adrian.Farrel@huawei.com&gt;</b>
</font>
<p><font size=1 face="sans-serif">09/20/2009 05:00 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
Adrian Farrel &lt;Adrian.Farrel@huawei.com&gt;</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Derek Atkins &lt;derek@ihtfp.com&gt;,
iesg@ietf.org, secdir@ietf.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">pieter.demil@intec.ugent.be, nicolas.riou@fr.schneider-electric.com,
jerald.p.martocci@jci.com, wouter@vooruit.be, roll-chairs@tools.ietf.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: sec-dir review of draft-ietf-roll-building-routing-reqs-07</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Hi Derek,<br>
<br>
I very much appreciate your review.<br>
<br>
It is important to understand that this document specifies requirements
that <br>
must/should/etc be satisfied by a protocol designed by the working group.
<br>
Thus, there is no question of what should be deployed or what should be
<br>
implemented.<br>
<br>
That is, the document specifies what must be in the protocol spec. We can
<br>
expect the protocol spec to discuss what must be implemented. And either
the <br>
protocol spec or an applicability statement would describe what must be
<br>
deployed.<br>
<br>
So, the concerns you raise would be very important in the final protocol
<br>
spec (and I hope the chairs and authors are paying attention), but do not
<br>
seem to me to fit in this document.<br>
<br>
Thanks,<br>
Adrian<br>
<br>
&gt;&gt; The Security Considerations appear to take into account various<br>
&gt;&gt; requirements for different systems. &nbsp;What seems to be lacking
is<br>
&gt;&gt; direction about how or when to apply various requirements and
what<br>
&gt;&gt; it means to the deployment.<br>
&gt;&gt;<br>
&gt;&gt; For example, what would it mean to a deployment if it has<br>
&gt;&gt; authentication versus not having authentication? &nbsp;Also, it's
unclear<br>
&gt;&gt; how these requirements would apply to an implementor.<br>
&gt;&gt;<br>
&gt;&gt; Variable security policies is a good idea, but it requires more<br>
&gt;&gt; guidance because the end user will never understand the ramifications<br>
&gt;&gt; of choosing one policy over another.<br>
<br>
<br>
</tt></font>
<br>
--=_alternative 0057E0C186257638_=--
--=_mixed 0057E0C186257638_=
Content-Type: application/vnd.ms-excel; name="Security Models for CBA.xls"
Content-Disposition: attachment; filename="Security Models for CBA.xls"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA
EAAAOAAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////OwAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A
AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA
AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA
LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAA/v////7///86
AAAA/v////7/////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////1IA
bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAWAAUA//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAAAABbA3W10pXIAVBuJwnTOsoB
OQAAAMACAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAABIAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAACAAAApmsAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0
AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEAAAADAAAA/////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkAAAAAAAAAAUARABvAGMAdQBtAGUAbgB0
AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABwBAAAAAAAACQgQ
AAAGBQCqH80HyQABAAYEAADhAAIAsATBAAIAAADiAAAAXABwABEAAEplcmFsZCBQIE1hcnRvY2Np
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCAAIAsARhAQIAAADAAQAAPQEGAAEA
AgADAJwAAgAQABkAAgAAABIAAgAAABMAAgAAAK8BAgAAALwBAgAAAD0AEgDgAXgAWzvtMDgAAAAA
AAEAWAJAAAIAAACNAAIAAAAiAAIAAAAOAAIAAQC3AQIAAADaAAIAAAAxABoAyAAAAP9/kAEAAAAA
AAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEA
AAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAABAP9/
vAIAAAACAAAFAUEAcgBpAGEAbAAxABoAoAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAoAAB
AP9/vAIAAAAAAAAFAUEAcgBpAGEAbAAxABoAoAABAP9/vAIAAAACAAAFAUEAcgBpAGEAbAAxABoA
oAAFAP9/vAIAAAECAAAFAUEAcgBpAGEAbAAxABoAyAAEAAwAkAEAAAEAAAAFAUEAcgBpAGEAbAAx
ABoAyAAEACQAkAEAAAEAAAAFAUEAcgBpAGEAbAAxAB4AaAEBADgAvAIAAAACAFIHAUMAYQBtAGIA
cgBpAGEAMQAeACwBAQA4ALwCAAAAAgBSBwFDAGEAbABpAGIAcgBpADEAHgAEAQEAOAC8AgAAAAIA
UgcBQwBhAGwAaQBiAHIAaQAxAB4A3AABADgAvAIAAAACAFIHAUMAYQBsAGkAYgByAGkAMQAeANwA
AAARAJABAAAAAgBSBwFDAGEAbABpAGIAcgBpADEAHgDcAAAAFACQAQAAAAIAUgcBQwBhAGwAaQBi
AHIAaQAxAB4A3AAAADwAkAEAAAACAFIHAUMAYQBsAGkAYgByAGkAMQAeANwAAAA+AJABAAAAAgBS
BwFDAGEAbABpAGIAcgBpADEAHgDcAAEAPwC8AgAAAAIAUgcBQwBhAGwAaQBiAHIAaQAxAB4A3AAB
ADQAvAIAAAACAFIHAUMAYQBsAGkAYgByAGkAMQAeANwAAAA0AJABAAAAAgBSBwFDAGEAbABpAGIA
cgBpADEAHgDcAAEACQC8AgAAAAIAUgcBQwBhAGwAaQBiAHIAaQAxAB4A3AAAAAoAkAEAAAACAFIH
AUMAYQBsAGkAYgByAGkAMQAaAMgAAAD/f5ABAAAAAABSBQFBAHIAaQBhAGwAMQAeANwAAgAXAJAB
AAAAAgBSBwFDAGEAbABpAGIAcgBpADEAHgDcAAEACAC8AgAAAAIAUgcBQwBhAGwAaQBiAHIAaQAx
AB4A3AAAAAkAkAEAAAACAFIHAUMAYQBsAGkAYgByAGkAMQAeANwAAAAIAJABAAAAAgBSBwFDAGEA
bABpAGIAcgBpAB4EHAAFABcAACIkIiMsIyMwXyk7XCgiJCIjLCMjMFwpHgQhAAYAHAAAIiQiIywj
IzBfKTtbUmVkXVwoIiQiIywjIzBcKR4EIgAHAB0AACIkIiMsIyMwLjAwXyk7XCgiJCIjLCMjMC4w
MFwpHgQnAAgAIgAAIiQiIywjIzAuMDBfKTtbUmVkXVwoIiQiIywjIzAuMDBcKR4ENwAqADIAAF8o
IiQiKiAjLCMjMF8pO18oIiQiKiBcKCMsIyMwXCk7XygiJCIqICItIl8pO18oQF8pHgQuACkAKQAA
XygqICMsIyMwXyk7XygqIFwoIywjIzBcKTtfKCogIi0iXyk7XyhAXykeBD8ALAA6AABfKCIkIiog
IywjIzAuMDBfKTtfKCIkIiogXCgjLCMjMC4wMFwpO18oIiQiKiAiLSI/P18pO18oQF8pHgQ2ACsA
MQAAXygqICMsIyMwLjAwXyk7XygqIFwoIywjIzAuMDBcKTtfKCogIi0iPz9fKTtfKEBfKeAAFAAA
AAAA9f8gAAAAAAAAAAAAAADAIOAAFAABAAAA9f8gAAD0AAAAAAAAAADAIOAAFAABAAAA9f8gAAD0
AAAAAAAAAADAIOAAFAACAAAA9f8gAAD0AAAAAAAAAADAIOAAFAACAAAA9f8gAAD0AAAAAAAAAADA
IOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA
9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAA
AAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAA
FAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8g
AAD0AAAAAAAAAADAIOAAFAAAAAAAAQAgAAAAAAAAAAAAAADAIOAAFAAdAAAA9f8gAAC0AAAAAAAA
AASfIOAAFAAdAAAA9f8gAAC0AAAAAAAAAAStIOAAFAAdAAAA9f8gAAC0AAAAAAAAAASqIOAAFAAd
AAAA9f8gAAC0AAAAAAAAAASuIOAAFAAdAAAA9f8gAAC0AAAAAAAAAASbIOAAFAAdAAAA9f8gAAC0
AAAAAAAAAASvIOAAFAAdAAAA9f8gAAC0AAAAAAAAAASsIOAAFAAdAAAA9f8gAAC0AAAAAAAAAASd
IOAAFAAdAAAA9f8gAAC0AAAAAAAAAASLIOAAFAAdAAAA9f8gAAC0AAAAAAAAAASuIOAAFAAdAAAA
9f8gAAC0AAAAAAAAAASsIOAAFAAdAAAA9f8gAAC0AAAAAAAAAASzIOAAFAAcAAAA9f8gAAC0AAAA
AAAAAASeIOAAFAAcAAAA9f8gAAC0AAAAAAAAAASdIOAAFAAcAAAA9f8gAAC0AAAAAAAAAASLIOAA
FAAcAAAA9f8gAAC0AAAAAAAAAASkIOAAFAAcAAAA9f8gAAC0AAAAAAAAAASxIOAAFAAcAAAA9f8g
AAC0AAAAAAAAAAS0IOAAFAAcAAAA9f8gAAC0AAAAAAAAAAS+IOAAFAAcAAAA9f8gAAC0AAAAAAAA
AASKIOAAFAAcAAAA9f8gAAC0AAAAAAAAAAS5IOAAFAAcAAAA9f8gAAC0AAAAAAAAAASkIOAAFAAc
AAAA9f8gAAC0AAAAAAAAAASxIOAAFAAcAAAA9f8gAAC0AAAAAAAAAAS1IOAAFAARAAAA9f8gAAC0
AAAAAAAAAAStIOAAFAAVAAAA9f8gAACUERGXC5cLAASWIOAAFAAXAAAA9f8gAACUZma/H78fAAS3
IOAAFAABACsA9f8gAAD4AAAAAAAAAADAIOAAFAABACkA9f8gAAD4AAAAAAAAAADAIOAAFAABACwA
9f8gAAD4AAAAAAAAAADAIOAAFAABACoA9f8gAAD4AAAAAAAAAADAIOAAFAAaAAAA9f8gAAD0AAAA
AAAAAADAIOAAFAALAAAA9P8AAAD0AAAAAAAAAADAIOAAFAAQAAAA9f8gAAC0AAAAAAAAAASqIOAA
FAANAAAA9f8gAADUAFAAAAAfAADAIOAAFAAOAAAA9f8gAADUAFAAAAALAADAIOAAFAAPAAAA9f8g
AADUACAAAAAPAADAIOAAFAAPAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAKAAAA9P8AAAD0AAAAAAAA
AADAIOAAFAATAAAA9f8gAACUERGXC5cLAASvIOAAFAAWAAAA9f8gAADUAGAAAAAaAADAIOAAFAAS
AAAA9f8gAAC0AAAAAAAAAASrIOAAFAAZAAAA9f8gAACcEREWCxYLAASaIOAAFAAUAAAA9f8gAACU
ERG/H78fAASWIOAAFAABAAkA9f8gAAD4AAAAAAAAAADAIOAAFAAMAAAA9f8gAAD0AAAAAAAAAADA
IOAAFAAbAAAA9f8gAADUAGEAAD4fAADAIOAAFAAYAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA
AQAaAAAQAAAAAAAAAADAIOAAFAAGAAAAAQASAAAYAAAAAAAAAADAIOAAFAAGAAAAAQAgAAAIAAAA
AAAAAADAIOAAFAAGAAAAAQAaAAA4ERFAIEAgAADAIOAAFAAGAAAAAQAaAAA4ERBAIAAgAADAIOAA
FAAGAAAAAQAaAAA4IRFAIEAgAADAIOAAFAAGAAAAAQAaAAA4IRBAIAAgAADAIOAAFAAGAAAAAQAa
AAA4ESFAIEAgAADAIOAAFAAGAAAAAQAaAAA4EhBAIAAgAADAIOAAFAAIAAAAAQASAAAYAAAAAAAA
AADAIOAAFAAGAAAAAQAaAAA4ISFAIEAgAADAIOAAFAAGAAAAAQAYAAA4ERFAIEAgAADAIOAAFAAI
AAAAAQAaAAB4EiFAIEAgAAQsIOAAFAAIAAAAAQAaAAB4ESFAIEAgAAQsIOAAFAAIAAAAAQAaAAB4
ISFAIEAgAAQsIOAAFAAGAAAAAQAaAAA4ERJAIEAgAADAIOAAFAAGAAAAAQAaAAA4EiFAIEAgAADA
IOAAFAAGAAAAAQAaAAB4AhBAAAAgAAQrIOAAFAAGAAAAAQAaAAB4AhFAAEAgAAQrIOAAFAAGAAAA
AQAaAAB4AiFAAEAgAAQrIOAAFAAHAAAAAQAaAAB4EhBAIAAgAADAIOAAFAAGAAAAAQASAAB4EhFA
IEAgAADAIOAAFAAGAAAAAQASAAB4EiFAIEAgAADAIOAAFAAGAAAAAQAaAAA4ERJAIEAgAADAIOAA
FAAGAAAAAQAaAAA4ERFAIEAgAADAIOAAFAAGAAAAAQAaAAA4ESFAIEAgAADAIOAAFAAGAAAAAQAa
AAA4ISFAIEAgAADAIOAAFAAFAAAAAQAaAAB4AhJAAEAgAAQsIOAAFAAFAAAAAQAaAAB4ABIAAEAg
AAQsIOAAFAAFAAAAAQAaAAB4IBIAIEAgAAQsIOAAFAAGAAAAAQAaAAA4EhJAIEAgAADAIOAAFAAG
AAAAAQAaAAA4EhFAIEAgAADAIOAAFAAGAAAAAQAaAAA4IRFAIEAgAADAIOAAFAAGAAAAAQAaAAA4
IRJAIEAgAADAIOAAFAAGAAAAAQAaAAA4ERBAIAAgAADAIOAAFAAGAAAAAQAaAAA4EiFAIEAgAADA
IOAAFAAFAAAAAQAaAAB4AmFAAEAgAAQsIOAAFAAFAAAAAQAaAAB4ERJAIEAgAAQsIOAAFAAFAAAA
AQAaAAB4ESFAIEAgAAQsIOAAFAAFAAAAAQAaAAB4IRJAIEAgAAQsIOAAFAAFAAAAAQAaAAB4ISFA
IEAgAAQsIOAAFAAFAAAAAQAaAAB4EhJAIEAgAAQsIOAAFAAFAAAAAQAaAAB4EiFAIEAgAAQsIHwI
FAB8CAAAAAAAAAAAAAAAAGsAMXbwcX0ILQB9CAAAAAAAAAAAAAAAAD0AAAACAA0AFAADAAAAAwAA
ADAwXCk7XygqDgAFAAF9CEEAfQgAAAAAAAAAAAAAAAAyAAAAAwANABQAAwAAAAMAAAAwMFwpO18o
Kg4ABQACCAAUAAMAAAAEAAAAO18oQF8pICB9CEEAfQgAAAAAAAAAAAAAAAAzAAAAAwANABQAAwAA
AAMAAAAwMFwpO18oKg4ABQACCAAUAAMA/z8EAAAAO18oQF8pICB9CEEAfQgAAAAAAAAAAAAAAAA0
AAAAAwANABQAAwAAAAMAAAAwMFwpO18oKg4ABQACCAAUAAMAMjMEAAAAO18oQF8pICB9CC0AfQgA
AAAAAAAAAAAAAAA1AAAAAgANABQAAwAAAAMAAAAwMFwpO18oKg4ABQACfQhBAH0IAAAAAAAAAAAA
AAAAMQAAAAMADQAUAAIAAAAAYQD/MDBcKTtfKCoOAAUAAgQAFAACAAAAxu/O/ztfKEBfKSAgfQhB
AH0IAAAAAAAAAAAAAAAAKAAAAAMADQAUAAIAAACcAAb/MDBcKTtfKCoOAAUAAgQAFAACAAAA/8fO
/ztfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAOQAAAAMADQAUAAIAAACcZQD/MDBcKTtfKCoOAAUA
AgQAFAACAAAA/+uc/ztfKEBfKSAgfQiRAH0IAAAAAAAAAAAAAAAANwAAAAcADQAUAAIAAAA/P3b/
MDBcKTtfKCoOAAUAAgQAFAACAAAA/8yZ/ztfKEBfKSAgBwAUAAIAAAB/f3//ICAgICAgICAIABQA
AgAAAH9/f/8gICAgICAgIAkAFAACAAAAf39//wAAAAAAAAAACgAUAAIAAAB/f3//AAAAAAAAAAB9
CJEAfQgAAAAAAAAAAAAAAAA7AAAABwANABQAAgAAAD8/P/8wMFwpO18oKg4ABQACBAAUAAIAAADy
8vL/O18oQF8pICAHABQAAgAAAD8/P/8gICAgICAgIAgAFAACAAAAPz8//yAgICAgICAgCQAUAAIA
AAA/Pz//AAAAAAAAAAAKABQAAgAAAD8/P/8AAAAAAAAAAH0IkQB9CAAAAAAAAAAAAAAAACkAAAAH
AA0AFAACAAAA+n0A/zAwXCk7XygqDgAFAAIEABQAAgAAAPLy8v87XyhAXykgIAcAFAACAAAAf39/
/yAgICAgICAgCAAUAAIAAAB/f3//ICAgICAgICAJABQAAgAAAH9/f/8AAAAAAAAAAAoAFAACAAAA
f39//wAAAAAAAAAAfQhBAH0IAAAAAAAAAAAAAAAAOAAAAAMADQAUAAIAAAD6fQD/MDBcKTtfKCoO
AAUAAggAFAACAAAA/4AB/ztfKEBfKSAgfQiRAH0IAAAAAAAAAAAAAAAAKgAAAAcADQAUAAMAAAAA
AAAAMDBcKTtfKCoOAAUAAgQAFAACAAAApaWl/ztfKEBfKSAgBwAUAAIAAAA/Pz//ICAgICAgICAI
ABQAAgAAAD8/P/8gICAgICAgIAkAFAACAAAAPz8//wAAAAAAAAAACgAUAAIAAAA/Pz//AAAAAAAA
AAB9CC0AfQgAAAAAAAAAAAAAAAA/AAAAAgANABQAAgAAAP8AAP8wMFwpO18oKg4ABQACfQh4AH0I
AAAAAAAAAAAAAAAAOgAAAAUABAAUAAIAAAD//8z/MDBcKTtfKCoHABQAAgAAALKysv8ApaWl/ztf
KAgAFAACAAAAsrKy/wA/Pz//ICAgCQAUAAIAAACysrL/AD8/P/8gICAKABQAAgAAALKysv8APz8/
/wAAAH0ILQB9CAAAAAAAAAAAAAAAAC8AAAACAA0AFAACAAAAf39//zAwXCk7XygqDgAFAAJ9CFUA
fQgAAAAAAAAAAAAAAAA+AAAABAANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACBwAUAAMAAAAEAAAA
O18oCAAUAAIIABQAAwAAAAQAAAAgICAJABQAAn0IQQB9CAAAAAAAAAAAAAAAACIAAAADAA0AFAAD
AAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAAAAQAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAA
ABAAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwBlZgQAAAA7XygIABQAAn0IQQB9
CAAAAAAAAAAAAAAAABYAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwDMTAQAAAA7
XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAABwAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIE
ABQAAwAyMwQAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAACMAAAADAA0AFAADAAAAAAAAADAw
XCk7XygqDgAFAAIEABQAAwAAAAUAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAABEAAAADAA0A
FAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwBlZgUAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAA
AAAAABcAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwDMTAUAAAA7XygIABQAAn0I
QQB9CAAAAAAAAAAAAAAAAB0AAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAyMwUA
AAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAACQAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAF
AAIEABQAAwAAAAYAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAABIAAAADAA0AFAADAAAAAQAA
ADAwXCk7XygqDgAFAAIEABQAAwBlZgYAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAABgAAAAD
AA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwDMTAYAAAA7XygIABQAAn0IQQB9CAAAAAAA
AAAAAAAAAB4AAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAyMwYAAAA7XygIABQA
An0IQQB9CAAAAAAAAAAAAAAAACUAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAA
AAcAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAABMAAAADAA0AFAADAAAAAQAAADAwXCk7Xygq
DgAFAAIEABQAAwBlZgcAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAABkAAAADAA0AFAADAAAA
AQAAADAwXCk7XygqDgAFAAIEABQAAwDMTAcAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAAB8A
AAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAyMwcAAAA7XygIABQAAn0IQQB9CAAA
AAAAAAAAAAAAACYAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAAAAgAAAA7XygI
ABQAAn0IQQB9CAAAAAAAAAAAAAAAABQAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQA
AwBlZggAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAABoAAAADAA0AFAADAAAAAQAAADAwXCk7
XygqDgAFAAIEABQAAwDMTAgAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAACAAAAADAA0AFAAD
AAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAyMwgAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAA
ACcAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAAAAkAAAA7XygIABQAAn0IQQB9
CAAAAAAAAAAAAAAAABUAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwBlZgkAAAA7
XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAABsAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIE
ABQAAwDMTAkAAAA7XygIABQAAn0IQQB9CAAAAAAAAAAAAAAAACEAAAADAA0AFAADAAAAAAAAADAw
XCk7XygqDgAFAAIEABQAAwAyMwkAAAA7XygIABQAApMCEgAQAA0AADIwJSAtIEFjY2VudDGSCE0A
kggAAAAAAAAAAAAAAQQe/w0AMgAwACUAIAAtACAAQQBjAGMAZQBuAHQAMQAAAAMAAQAMAAcEZWbb
5fH/BQAMAAcBAAAAAAD/JQAFAAKTAhIAEQANAAAyMCUgLSBBY2NlbnQykghNAJIIAAAAAAAAAAAA
AAEEIv8NADIAMAAlACAALQAgAEEAYwBjAGUAbgB0ADIAAAADAAEADAAHBWVm8t3c/wUADAAHAQAA
AAAA/yUABQACkwISABIADQAAMjAlIC0gQWNjZW50M5IITQCSCAAAAAAAAAAAAAABBCb/DQAyADAA
JQAgAC0AIABBAGMAYwBlAG4AdAAzAAAAAwABAAwABwZlZurx3f8FAAwABwEAAAAAAP8lAAUAApMC
EgATAA0AADIwJSAtIEFjY2VudDSSCE0AkggAAAAAAAAAAAAAAQQq/w0AMgAwACUAIAAtACAAQQBj
AGMAZQBuAHQANAAAAAMAAQAMAAcHZWbl4Oz/BQAMAAcBAAAAAAD/JQAFAAKTAhIAFAANAAAyMCUg
LSBBY2NlbnQ1kghNAJIIAAAAAAAAAAAAAAEELv8NADIAMAAlACAALQAgAEEAYwBjAGUAbgB0ADUA
AAADAAEADAAHCGVm2+7z/wUADAAHAQAAAAAA/yUABQACkwISABUADQAAMjAlIC0gQWNjZW50NpII
TQCSCAAAAAAAAAAAAAABBDL/DQAyADAAJQAgAC0AIABBAGMAYwBlAG4AdAA2AAAAAwABAAwABwll
Zv3p2f8FAAwABwEAAAAAAP8lAAUAApMCEgAWAA0AADQwJSAtIEFjY2VudDGSCE0AkggAAAAAAAAA
AAAAAQQf/w0ANAAwACUAIAAtACAAQQBjAGMAZQBuAHQAMQAAAAMAAQAMAAcEzEy4zOT/BQAMAAcB
AAAAAAD/JQAFAAKTAhIAFwANAAA0MCUgLSBBY2NlbnQykghNAJIIAAAAAAAAAAAAAAEEI/8NADQA
MAAlACAALQAgAEEAYwBjAGUAbgB0ADIAAAADAAEADAAHBcxM5rm4/wUADAAHAQAAAAAA/yUABQAC
kwISABgADQAANDAlIC0gQWNjZW50M5IITQCSCAAAAAAAAAAAAAABBCf/DQA0ADAAJQAgAC0AIABB
AGMAYwBlAG4AdAAzAAAAAwABAAwABwbMTNfkvP8FAAwABwEAAAAAAP8lAAUAApMCEgAZAA0AADQw
JSAtIEFjY2VudDSSCE0AkggAAAAAAAAAAAAAAQQr/w0ANAAwACUAIAAtACAAQQBjAGMAZQBuAHQA
NAAAAAMAAQAMAAcHzEzMwNr/BQAMAAcBAAAAAAD/JQAFAAKTAhIAGgANAAA0MCUgLSBBY2NlbnQ1
kghNAJIIAAAAAAAAAAAAAAEEL/8NADQAMAAlACAALQAgAEEAYwBjAGUAbgB0ADUAAAADAAEADAAH
CMxMtt3o/wUADAAHAQAAAAAA/yUABQACkwISABsADQAANDAlIC0gQWNjZW50NpIITQCSCAAAAAAA
AAAAAAABBDP/DQA0ADAAJQAgAC0AIABBAGMAYwBlAG4AdAA2AAAAAwABAAwABwnMTPzVtP8FAAwA
BwEAAAAAAP8lAAUAApMCEgAcAA0AADYwJSAtIEFjY2VudDGSCE0AkggAAAAAAAAAAAAAAQQg/w0A
NgAwACUAIAAtACAAQQBjAGMAZQBuAHQAMQAAAAMAAQAMAAcEMjOVs9f/BQAMAAcAAAD/////JQAF
AAKTAhIAHQANAAA2MCUgLSBBY2NlbnQykghNAJIIAAAAAAAAAAAAAAEEJP8NADYAMAAlACAALQAg
AEEAYwBjAGUAbgB0ADIAAAADAAEADAAHBTIz2ZeV/wUADAAHAAAA/////yUABQACkwISAB4ADQAA
NjAlIC0gQWNjZW50M5IITQCSCAAAAAAAAAAAAAABBCj/DQA2ADAAJQAgAC0AIABBAGMAYwBlAG4A
dAAzAAAAAwABAAwABwYyM8LWmv8FAAwABwAAAP////8lAAUAApMCEgAfAA0AADYwJSAtIEFjY2Vu
dDSSCE0AkggAAAAAAAAAAAAAAQQs/w0ANgAwACUAIAAtACAAQQBjAGMAZQBuAHQANAAAAAMAAQAM
AAcHMjOyocf/BQAMAAcAAAD/////JQAFAAKTAhIAIAANAAA2MCUgLSBBY2NlbnQ1kghNAJIIAAAA
AAAAAAAAAAEEMP8NADYAMAAlACAALQAgAEEAYwBjAGUAbgB0ADUAAAADAAEADAAHCDIzk83d/wUA
DAAHAAAA/////yUABQACkwISACEADQAANjAlIC0gQWNjZW50NpIITQCSCAAAAAAAAAAAAAABBDT/
DQA2ADAAJQAgAC0AIABBAGMAYwBlAG4AdAA2AAAAAwABAAwABwkyM/rAkP8FAAwABwAAAP////8l
AAUAApMCDAAiAAcAAEFjY2VudDGSCEEAkggAAAAAAAAAAAAAAQQd/wcAQQBjAGMAZQBuAHQAMQAA
AAMAAQAMAAcEAABPgb3/BQAMAAcAAAD/////JQAFAAKTAgwAIwAHAABBY2NlbnQykghBAJIIAAAA
AAAAAAAAAAEEIf8HAEEAYwBjAGUAbgB0ADIAAAADAAEADAAHBQAAwFBN/wUADAAHAAAA/////yUA
BQACkwIMACQABwAAQWNjZW50M5IIQQCSCAAAAAAAAAAAAAABBCX/BwBBAGMAYwBlAG4AdAAzAAAA
AwABAAwABwYAAJu7Wf8FAAwABwAAAP////8lAAUAApMCDAAlAAcAAEFjY2VudDSSCEEAkggAAAAA
AAAAAAAAAQQp/wcAQQBjAGMAZQBuAHQANAAAAAMAAQAMAAcHAACAZKL/BQAMAAcAAAD/////JQAF
AAKTAgwAJgAHAABBY2NlbnQ1kghBAJIIAAAAAAAAAAAAAAEELf8HAEEAYwBjAGUAbgB0ADUAAAAD
AAEADAAHCAAAS6zG/wUADAAHAAAA/////yUABQACkwIMACcABwAAQWNjZW50NpIIQQCSCAAAAAAA
AAAAAAABBDH/BwBBAGMAYwBlAG4AdAA2AAAAAwABAAwABwkAAPeWRv8FAAwABwAAAP////8lAAUA
ApMCCAAoAAMAAEJhZJIIOQCSCAAAAAAAAAAAAAABARv/AwBCAGEAZAAAAAMAAQAMAAX/AAD/x87/
BQAMAAX/AACcAAb/JQAFAAKTAhAAKQALAABDYWxjdWxhdGlvbpIIgQCSCAAAAAAAAAAAAAABAhb/
CwBDAGEAbABjAHUAbABhAHQAaQBvAG4AAAAHAAEADAAF/wAA8vLy/wUADAAF/wAA+n0A/yUABQAC
BgAOAAX/AAB/f3//AQAHAA4ABf8AAH9/f/8BAAgADgAF/wAAf39//wEACQAOAAX/AAB/f3//AQCT
Ag8AKgAKAABDaGVjayBDZWxskgh/AJIIAAAAAAAAAAAAAAECF/8KAEMAaABlAGMAawAgAEMAZQBs
AGwAAAAHAAEADAAF/wAApaWl/wUADAAHAAAA/////yUABQACBgAOAAX/AAA/Pz//BgAHAA4ABf8A
AD8/P/8GAAgADgAF/wAAPz8//wYACQAOAAX/AAA/Pz//BgCTAgQAK4AD/5IIIACSCAAAAAAAAAAA
AAABBQP/BQBDAG8AbQBtAGEAAAAAAJMCBAAsgAb/kggoAJIIAAAAAAAAAAAAAAEFBv8JAEMAbwBt
AG0AYQAgAFsAMABdAAAAAACTAgQALYAE/5IIJgCSCAAAAAAAAAAAAAABBQT/CABDAHUAcgByAGUA
bgBjAHkAAAAAAJMCBAAugAf/kgguAJIIAAAAAAAAAAAAAAEFB/8MAEMAdQByAHIAZQBuAGMAeQAg
AFsAMABdAAAAAACTAhUALwAQAABFeHBsYW5hdG9yeSBUZXh0kghHAJIIAAAAAAAAAAAAAAECNf8Q
AEUAeABwAGwAYQBuAGEAdABvAHIAeQAgAFQAZQB4AHQAAAACAAUADAAF/wAAf39//yUABQACkwIE
ADCACf+SCDoAkggAAAAAAAAAAAAAAQIJ/xIARgBvAGwAbABvAHcAZQBkACAASAB5AHAAZQByAGwA
aQBuAGsAAAAAAJMCCQAxAAQAAEdvb2SSCDsAkggAAAAAAAAAAAAAAQEa/wQARwBvAG8AZAAAAAMA
AQAMAAX/AADG787/BQAMAAX/AAAAYQD/JQAFAAKTAg4AMgAJAABIZWFkaW5nIDGSCEcAkggAAAAA
AAAAAAAAAQMQ/wkASABlAGEAZABpAG4AZwAgADEAAAADAAUADAAHAwAAH0l9/yUABQACBwAOAAcE
AABPgb3/BQCTAg4AMwAJAABIZWFkaW5nIDKSCEcAkggAAAAAAAAAAAAAAQMR/wkASABlAGEAZABp
AG4AZwAgADIAAAADAAUADAAHAwAAH0l9/yUABQACBwAOAAcE/z+owN7/BQCTAg4ANAAJAABIZWFk
aW5nIDOSCEcAkggAAAAAAAAAAAAAAQMS/wkASABlAGEAZABpAG4AZwAgADMAAAADAAUADAAHAwAA
H0l9/yUABQACBwAOAAcEMjOVs9f/AgCTAg4ANQAJAABIZWFkaW5nIDSSCDkAkggAAAAAAAAAAAAA
AQMT/wkASABlAGEAZABpAG4AZwAgADQAAAACAAUADAAHAwAAH0l9/yUABQACkwIEADaACP+SCCgA
kggAAAAAAAAAAAAAAQII/wkASAB5AHAAZQByAGwAaQBuAGsAAAAAAJMCCgA3AAUAAElucHV0kgh1
AJIIAAAAAAAAAAAAAAECFP8FAEkAbgBwAHUAdAAAAAcAAQAMAAX/AAD/zJn/BQAMAAX/AAA/P3b/
JQAFAAIGAA4ABf8AAH9/f/8BAAcADgAF/wAAf39//wEACAAOAAX/AAB/f3//AQAJAA4ABf8AAH9/
f/8BAJMCEAA4AAsAAExpbmtlZCBDZWxskghLAJIIAAAAAAAAAAAAAAECGP8LAEwAaQBuAGsAZQBk
ACAAQwBlAGwAbAAAAAMABQAMAAX/AAD6fQD/JQAFAAIHAA4ABf8AAP+AAf8GAJMCDAA5AAcAAE5l
dXRyYWySCEEAkggAAAAAAAAAAAAAAQEc/wcATgBlAHUAdAByAGEAbAAAAAMAAQAMAAX/AAD/65z/
BQAMAAX/AACcZQD/JQAFAAKTAgQAAIAA/5IIIgCSCAAAAAAAAAAAAAABAQD/BgBOAG8AcgBtAGEA
bAAAAAAAkwIJADoABAAATm90ZZIIYgCSCAAAAAAAAAAAAAABAgr/BABOAG8AdABlAAAABQABAAwA
Bf8AAP//zP8GAA4ABf8AALKysv8BAAcADgAF/wAAsrKy/wEACAAOAAX/AACysrL/AQAJAA4ABf8A
ALKysv8BAJMCCwA7AAYAAE91dHB1dJIIdwCSCAAAAAAAAAAAAAABAhX/BgBPAHUAdABwAHUAdAAA
AAcAAQAMAAX/AADy8vL/BQAMAAX/AAA/Pz//JQAFAAIGAA4ABf8AAD8/P/8BAAcADgAF/wAAPz8/
/wEACAAOAAX/AAA/Pz//AQAJAA4ABf8AAD8/P/8BAJMCBAA8gAX/kggkAJIIAAAAAAAAAAAAAAEF
Bf8HAFAAZQByAGMAZQBuAHQAAAAAAJMCCgA9AAUAAFRpdGxlkggxAJIIAAAAAAAAAAAAAAEDD/8F
AFQAaQB0AGwAZQAAAAIABQAMAAcDAAAfSX3/JQAFAAGTAgoAPgAFAABUb3RhbJIITQCSCAAAAAAA
AAAAAAABAxn/BQBUAG8AdABhAGwAAAAEAAUADAAHAQAAAAAA/yUABQACBgAOAAcEAABPgb3/AQAH
AA4ABwQAAE+Bvf8GAJMCEQA/AAwAAFdhcm5pbmcgVGV4dJIIPwCSCAAAAAAAAAAAAAABAgv/DABX
AGEAcgBuAGkAbgBnACAAVABlAHgAdAAAAAIABQAMAAX/AAD/AAD/JQAFAAKOCFgAjggAAAAAAAAA
AAAAkAAAABEAEQBUAGEAYgBsAGUAUwB0AHkAbABlAE0AZQBkAGkAdQBtADkAUABpAHYAbwB0AFMA
dAB5AGwAZQBMAGkAZwBoAHQAMQA2AGABAgAAAIUADgCdSQAAAAAGAFNoZWV0MYUADgCGaAAAAAAG
AFNoZWV0MoUADgAWagAAAAAGAFNoZWV0M5oIGACaCAAAAAAAAAAAAAABAAAAAAAAAAIAAACjCBAA
owgAAAAAAAAAAAAAAAAAAIwABAABAAEAwQEIAMEBAAAd6wEA/ADPGU0AAABGAAAAAwAATG93BgAA
TWVkaXVtBAAASGlnaBcAAE5ldHdvcmsgU2VjdXJpdHkgVGhyZWF0FAAAQ29tbWVyY2lhbCBVc2Ug
Q2FzZXMNAABIVkFDCkxpZ2h0aW5nKQAIAQBOb25lClByZWRlZmluZWQga2V5IHVzZWQgYW5kIG5v
dCBjaGFuZ2VkKQQABgAXAABDb21tZXJjaWFsIEFwcGxpY2F0aW9ucwQAAE5vbmUsAABBbGxvd2Vk
IHRpbWUgdG8gc2V0dXAgbmV0d29yayBzZWN1cml0eSB3aGVuOhMAADEgbWludXRlIHBlciBkZXZp
Y2UjAABIaWdoIE9jY3VwYW5jeSAKSGlnaCBSaXNlIEJ1aWxkaW5ncz4AAE5vbmUgLSBCdWlsZGlu
ZyBvY2N1cGFudHMgaGF2ZSBubyByZWFzb24gdG8gYmUgYSBzZWN1cml0eSByaXNrJwAATWlzY3Jl
YW50cyAoYWthIHN0dWRlbnRzKSBjYXVzaW5nIGhhdm9jYAAAQ29tbWVyY2lhbCBSZWFsIEVzdGF0
ZQpNdWx0aS10ZW5hbnQgZmFjaWxpdGllcwpVbml2ZXJzaXRpZXMKSGVhbHRoIENhcmUKVmVuZG9y
IGludGVyb3BlcmFiaWxpdHkKBgAAVUwsVUxDhAAAUHJpdmF0ZSBPZmZpY2UgQnVpbGRpbmdzClNp
bmdsZSBCdWlsZGluZwpTaW5nbGUgVGVuYW50IEZhY2lsaXR5Ck93bmVyIE9jY3VwaWVkCk5vdCB2
ZW5kb3IgaW50ZXJvcGVyYWJsZQpObyBQdWJsaWMgYWNjZXNzIHRvIGZhY2lsaXR5CgAAR292ZXJu
YW5jZRMAADAgbWludXRlIHBlciBkZXZpY2V0AABEZXZpY2UgQXV0aGVudGljYXRpb24gb24gc3Bl
Y2lmaWMgZGV2aWNlcyBvbmx5IHRvIGFzc3VyZSBhdXRvbWF0aWMgZGV2aWNlIGNvbnRyb2wgb2Nj
dXJpbmcgb25seSB0byBzcGVjaWZpYyBkZXZpY2VzLoQAAERldmljZSBBdXRoZW50aWNhdGlvbiBv
biBzcGVjaWZpYyBkZXZpY2VzIG9ubHkgdG8gYXNzdXJlIGF1dG9tYXRpYyBkZXZpY2UgY29udHJv
bCBhbmQgdXNlciBhY2Nlc3Mgb2NjdXJpbmcgb25seSB0byBzcGVjaWZpYyBkZXZpY2VzLhMAAFRy
dXN0IENlbnRlciBmYWlsczqUAABTeXN0ZW0gb3BlcmF0ZXMgd2l0aG91dCBhZmZlY3QsICBOZXcg
ZGV2aWNlcyBjYW4gYmUgYWRkZWQgdXNpbmcgZXhpc3RpbmcgZGVmYXVsdCBrZXkgZWl0aGVyIGJ5
IG9mZi1iYW5kIG1lYW5zIG9yIGZyb20gb3BlcmF0aW9uYWwgQ29tbWlzc2lvbmluZyBUb29sjAAA
U3lzdGVtIG9wZXJhdGVzIHdpdGhvdXQgYWZmZWN0LCAgTmV3IGRldmljZXMgY2FuIGJlIGFkZGVk
IHVzaW5nIGV4aXN0aW5nIGtleSBlaXRoZXIgYnkgb2ZmLWJhbmQgbWVhbnMgb3IgZnJvbSBvcGVy
YXRpb25hbCBDb21taXNzaW9uaW5nIFRvb2xQAAA1IG1pbnV0ZXMgcGVyIGRldmljZSByZXF1aXJp
bmcgYXV0aGVudGljYXRpb24sIDEgbWludXRlIGZvciBhbGwgb3RoZXIgZGV2aWNlcy4gIJIAADEw
IG1pbnV0ZXMgcGVyIGRldmljZSByZXF1aXJpbmcgYXV0aGVudGljYXRpb24sIDEgbWludXRlIGZv
ciBhbGwgb3RoZXIgZGV2aWNlcwoKTm8gZGV2aWNlcyBjYW4gYmUgYWRkZWQgdG8gdGhlIHN5c3Rl
bSB1bmxlc3MgYXV0aG9yaXplZCBieSB0aGUgVEMuKAAAQ29tbWlzc2lvbmluZyBUb29sIG5vdCBh
dmFpbGFibGUgb24tbGluZVIAAERldmljZXMgY2FuIGJlIGFkZGVkIHRvIHRoZSBzZWN1cmUgbmV0
d29yayBieSBhY2Nlc3NpbmcgdGhlIFRydXN0IENlbnRlciBkaXJlY3RseS6MAABTeXN0ZW0gc3Rp
bGwgb3BlcmF0ZXMuICBObyBuZXcgZGV2aWNlcyBjYW4gYmUgYWRkZWQgdW50aWwgdGhlIFRDIGlz
IGFnYWluIG9wZXJhdGlvbmFsLiAgQSByZXBvcnQgb2YgdGhlIFRDIGZhaWx1cmUgaXMgZm9yd2Fy
ZGVkIHRvIHRoZSB1c2VyLiwAAEhWQUMKTGlnaHRpbmcKRG9vciBBY2Nlc3MKVmlkZW8gU3VydmVp
bGxhbmNlgwAASFZBQwpMaWdodGluZwpEb29yIEFjY2VzcwpWaWRlbyBTdXJ2ZWlsbGFuY2UKVUwg
U21va2UgQ29udHJvbApGb3JlIFNlY29uZGFyeSBSZXBvcnRpbmcKUHJpbWFyeSBGaXJlIFJlcG9y
dGluZwpDcml0aWNhbCBFbnZpcm9ubWVudHMsAABaRUQvWlIgIC0gbm8gZGlzcnVwdGlvbiBvZiBl
eGlzdGluZyBuZXR3b3JrChAAAE5ldyBEZXZpY2UgQWRkZWQWAABGYWlsZWQgRGV2aWNlIFJlcGxh
Y2VkgwAAWkVEL1pSIC0gRGV2aWNlcyBtdXN0IGJlIGFkZGVkIG9uIGEgc2NoZWR1bGUuICBUaGUg
bmV0d29yayBtYXkgYmUgZG93biB3aGlsZSB0aGV5IGFyZSBhZGRlZC4gIEJldHRlciB0aG91Z2gg
aWYgaXQgbmVlZCBub3QgYmUgZG93bi6QAABaRUQgLSBhc3NvY2lhdGVkIFpSIG1heSBiZSBhZmZl
Y3RlZCB3aGVuIFpFRCByZXBsYWNlZC4KClpSIC0gYXNzb2NpYXRlZCBaRUQocykgbWF5IGJlIGFm
ZmVjdGVkIHdoaWxlIFpSIHJlcGxhY2VkCgpSZW1haW5pbmcgbmV0d29yayBub3QgYWZmZWN0ZWQe
AABOZXcgU29mdHdhcmUgVXBkYXRlIERvd25sb2FkZWRvAABOZXR3b3JrIFNlY3VyaXR5IGZlYXR1
cmUgdW5hZmZlY3RlZCBieSBzb2Z0d2FyZSBkb3dubG9hZC4gIE9ubHkgdGhlIGRldmljZSBjdXJy
ZW50bHkgYmVpbmcgdXBncmFkZWQgYWZmZWN0ZWQuICC0AABOZXR3b3JrIFNlY3VyaXR5IGZlYXR1
cmUgdW5hZmZlY3RlZCBieSBzb2Z0d2FyZSBkb3dubG9hZC4gIE9ubHkgdGhlIGRldmljZSBjdXJy
ZW50bHkgYmVpbmcgdXBncmFkZWQgYWZmZWN0ZWQuICBEZXZpY2Ugd2lsbCBnZXQgc2VjdXJpdHkg
aW5mbyBlaXRoZXIgdGhyb3VnaCBvdXQtb2YtYmFuZCBtZWFucyBvciBUQy6LAABOZXcgc29mdHdh
cmUgY2Fubm90IGJlIGRvd25sb2FkZWQgdG8gdGhlIGRldmljZSB1bnRpbCBpdCBhdXRlbnRpY2F0
ZXMgdGhlIHNvZnR3YXJlIGFuZCBkZXZpY2UuICBUaGUgc3lzdGVtIG11c3QgY29udGludWUgdG8g
cnVuIHVuYWZmZWN0ZWQuHAAATWVyZ2luZyBDb21taXNzaW9uZWQgSXNsYW5kc5AAAERldmljZXMg
b24gaXNsYW5kIGJlaW5nIGFkZGVkIHdpbGwgbm90IGJlIGFmZmVjdGVkIGJ5IHRoZSBjb2FsZXNj
ZW5jZSBvZiB0aGUgaXNsYW5kcy4gIERldmljZXMgYmVpbmcgbW92ZWQgY2FuIGJlIGFmZmVjdGVk
IHdoaWxlIG1vdmVtZW50IG9jY3Vycz4AAEFsbG93ZWQgTmV0d29yayBkaXN0dXJiYW5jZSB3aGls
ZSBzZXR0aW5nIHVwIG5ldHdvcmsgc2VjdXJpdHk6EQAAUmVwbGFjaW5nIERldmljZXMSAABJbnN0
YWxsaW5nIERldmljZXMaAABJbmNyZWFzaW5nIFNlY3VyaXR5IFBvbGljeZoAADE1IG1pbnV0ZXMg
dG8gYWxsb3cgb25jZSBUQyB0byBhY3F1aWVzY2UgdG8gdGhlIG90aGVyIFRDLiAgQWxsIGRldmlj
ZSBzZWN1cml0eSBzaG91bGQgYmUgdGhlIHNhbWUuICBJZiBvbiBkaWZmZXJlbnQgUEFOcywgYWxs
b3cgMjAgbWludXRlcyBmb3IgUEFOIGNoYW5nZS62AABBIG5ldHdvcmsgc2hvdWxkIGJlIGFibGUg
dG8gbW9ub3RvbmljYWxseSBpbmNyZWFzZSBpdHMgc2VjdXJpdHkgcG9saWN5LiBEZXZpY2VzIGlu
IHRoZSBQQU4gbXVzdCBkZXRlY3QgdGhlIHBvbGljeSBjaGFuZ2UgYW5kIGluY3JlYXNlIGl0IHBv
bGljeSBhY3Jvc3MgdGhlIG5ldHdvcmsgd2l0aGluZyAxMCBtaW51dGVzLo4AAE5vdCBhcHBsaWNh
YmxlIHNpbmNlIGF0IHRoZSBoaWdoZXN0IHNlY3VyaXR5IGxldmVsLiAgUmVkdWNpbmcgc2VjdXJp
dHkgd291bGQgZGVmZWF0IHRoZSBhcHBsaWNhdGlvbiBhbmQgd291bGQgbmVlZCB0byBiZSBhIHNj
aGVkdWxlZCBhY3Rpdml0eS48AABOb3QgYXBwbGljYWFibGUgc2luY2UgYWxyZWFkeSBhdCB0aGUg
J291dCBvZiB0aGUgYm94JyBzdGF0ZS5AAQBBbGwgUEFOIERldmljZXMgbXVzdCBiZSBtYWRlIGF3
YXJlIG9mIHRoZSBpbXBlbmRpbmcgcG9saWN5IGNoYW5nZS4gIE5vIGltcGFjdCBjYW4gb2NjdXIg
b24gdGhlIG5ldHdvcmsgIGF0IHRoaXMgdGltZS4gIE9uY2UgdGhlIGNoYW5nZSBjb21tZW5jZXMs
IGRldmljZXMgb24gdGhlIFBBTiBtdXN0IHN1cHBvcnQgYm90aCBwb2xpY2llcyB0ZW1wb3Jhcmls
aXkgdW50aWwgdGhlIFRDIGV4cGxpY2l0bHkgdGVsbHMgdGhlIGRldmljZSB0byB1c2UgdGhlIG5l
dyBwb2xpY3kuICBBdCB0aGF0IHBvaW50LCB0aGUgb2xkIHBvbGljeSBtdXN0IGJlIGluYWN0aXZh
dGVkLswBAEEgUEFOIG11c3QgYmUgYWJsZSB0byByZXZlcnQgYmFjayB0byBpdHMgY29tbWlzaW9u
aW5nIHN0YXRlIGFuZCBpdHMgJ291dCBvZiB0aGUgYm94JyBzZWN1cml0eSBwb2xpY3kKCk9uZSBk
ZXZpY2UsIG11bHRpcGxlIGRldmljZXMgb3IgYWxsIGRldmljZXMgaW4gdGhlIFBBTiBtdXN0IGJl
IG1hZGUgYXdhcmUgb2YgdGhlIGltcGVuZGluZyBwb2xpY3kgY2hhbmdlLiAgTm8gaW1wYWN0IGNh
biBvY2N1ciBvbiB0aGUgbmV0d29yayBhdCB0aGlzIHRpbWUuICBPbmNlIHRoZSBjaGFuZ2UgY29t
bWVuY2VzLCBkZXZpY2VzIG9uIHRoZSBQQU4gbXVzdCBzdXBwb3J0IGJvdGggcG9saWNpZXMgdGVt
cG9yYXJpbGl5IHVudGlsIHRoZSBUQyBleHBsaWNpdGx5IHRlbGxzIHRoZSBkZXZpY2UgdG8gdXNl
IHRoZSBuZXcgcG9saWN5LiAgQXQgdGhhdCBwb2ludCwgdGhlIG9sZCBwb2xpY3kgbXVzdCBiZSBp
bmFjdGl2YXRlZC6lAAAxMCBtaW51dGVzIHRvIG1lcmdlIG9uY2UgVEMgdG8gYWNxdWllc2NlIHRv
IHRoZSBvdGhlciBUQyBlc3RhYmxpc2hlZC4gIFRoZSBtZXJnZSBzaGFsbCBvY2N1ciBhdXRvbWF0
aWNhbGx5IHdpdGhvdXQgcmVxdWlyaW5nIHRoZSBpbnN0YWxsZXIgdG8gdmlzaXQgZWFjaCBQQU4g
ZGV2aWNlLiBiAAgCAE5PVEU6ICBUeXBpY2FsIFBBTiBub2RlIGNvdW50IG1heSBpbmNsdWRlIHVw
d2FyZHMgdG8gMTIwIGRldmljZXMgbWFkZSB1cCBvZiBhIG1peCBvZiBaUnMgYW5kIFpFRHMuNQAJ
AEAACAAKAABVTCxVTEMsRkRBKAAAV2hpdGUgUm9vbXMKSG9zcGl0YWwgT1JzClBoYXJtZWNldXRp
Y2FscwkAAFZlcnkgSGlnaA8AAFVMLFVMQyxGREEsIENvRZUAAERldmljZXMgd2lsbCBiZSBvdXQt
b2YtYmFuZCBjb25maWd1cmVkIHdpdGggdGhlIHNlY3VyaXR5IHBvbGljeS4gIFRoZSBUQyB3aWxs
IG5lZWQgdG8gYmUgbWFudWFsbHkgY29uZmlndXJlZCB0byBhbGxvdyB0aGUgZGV2aWNlIHRvIGpv
aW4gdGhlIG5ldHdvcmsuHwAAUmV2ZXJ0aW5nIHRvIENvbW1pc3Npb25pbmcgTW9kZWIAAFN5c3Rl
bSByZW1haW5zIGluICdzZWN1cmUgam9pbicgbW9kZS4gIE5vIGRldmljZSBleGNlcHQgdGhlIGZh
aWxlZCBUQyBjYW4gYmUgYWRkZWQgdG8gdGhlIG5ldHdvcmsuRgEAVGhlIGRvd25sb2FkaW5nIGRl
dmljZSBtdXN0IGpvaW4gdGhlIG5ldHdvcmsuICBUaGUgZG93bmxvYWRpbmcgZGV2aWNlIG11c3Qg
YXV0aGVudGljYXRlIHRvIGVhY2ggZGV2aWNlIGJlaW5nIGRvd25sb2FkZWQgYmVmb3JlIHRoZSBk
b3dubG9hZCBjb21tZW5jZXMuICBBbGwgZXhpc3Rpbmcgc2VjdXJpdHkgZGF0YSBpcyBsb3N0IGFz
IHRoZSBuZXcgc29mdHdhcmUgZG93bmxvYWRzLiAgT25jZSBkb3dubG9hZGVkLCB0aGUgZGV2aWNl
IG11c3QgcmVlc3RhYmxpc2ggaXRzZWxmIG9udG8gdGhlIG5ldHdvcmsgdmlhIGEgbWFudWFsIG5l
dHdvcmsgam9pbiBvcGVyYXRpb24uICApAQBUaGUgQ29tbWlzc2lvbmluZyBkZXZpY2UgbXVzdCBi
ZSBhIHRydXN0ZWQgY29uZmlndXJlZCBub2RlIG9uIHRoZSBuZXR3b3JrIGFzIGFyZSBhbGwgb3Ro
ZXIgZGV2aWNlcy4gIE5vZGVzIGFscmVhZHkgb24gdGhlIG5ldHdvcmsgY2Fubm90IGJlIGRlbGV0
b3Jpb3VzbHkgYWZmZWN0ZWQgYnkgdGhlIGFkZGl0aW9uIG9mIHRoZSBuZXcgbm9kZXMuICBFYWNo
IGRldmljZSBiZWluZyBhZGRlZCB0byB0aGUgbmV0d29yayBtdXN0IGJlIG1hbnVhbGx5IGFkZGVk
IHRocm91Z2ggdXNlciBhdXRlbnRpY2F0aW9uIGF0IHRoZSBUQy6+AABOb3QgYXBwbGljYWJsZSwg
IHRoZSBuZXR3b3JrIHdpbGwgYWx3YXlzIGJlIGluIGl0cyBvcGVyYWJsZSBzZWN1cml0eSBzdGF0
ZS4gIFRoZSBjb21taXNzaW9uaW5nIHRvb2wgbXVzdCBiZSBhZGRlZCB0byB0aGUgbmV0d29yayBh
bmQgZXhlY3V0ZSB0aGUgc2FtZSBzZWN1cml0eSBwb2xpY2llcyBhcyBkbyBhbGwgb3RoZXIgbm9k
ZXMusAAATmV3IGRldmljZXMgbWF5IGJlIG1hbnVhbGx5IGF1dGhlbnRpY2F0ZWQgdG8gdGhlIG5l
dHdvcmsgdmlhIGEgbWFudWFsIG5ldHdvcmsgam9pbiBvcGVyYXRpb24uICBPbmNlIGpvaW5lZCwg
dGhlIGRldmljZSBtdXN0IG9idGFpbiBpdHMgc2VjdXJpdHkgaW5mb3JtYXRpb24gaW4gYSBzZWN1
cmVkIG1hbm5lci5+AABIVkFDCkxpZ2h0aW5nCkRvb3IgQWNjZXNzClZpZGVvIFN1cnZlaWxsYW5j
ZQpVTCBTbW9rZSBDb250cm9sClNlY29uZGFyeSBSZXBvcnRpbmcKUHJpbWFyeSBGaXJlIFJlcG9y
dGluZwpDcml0aWNhbCBFbnZpcm9ubWVudHMHAABUaHJlYXRzVgAASFZBQwpMaWdodGluZwpEb29y
IEFjY2VzcwpWaWRlbyBTdXJ2ZWlsbGFuY2UKVUwgU21va2UgQ29udHJvbApGaXJlIFNlY29uZGFy
eSBSZXBvcnRpbmcmAABHb3Zlcm5tZW50IApNaWxpdGFyeQpIb21lbGFuZCBTZWN1cml0eQkBAEFj
Y2VzcyBvbnRvIHRoZSBuZXR3b3JrIGF0IGFsbCB0aW1lcyBtdXN0IGJlIHByb3RlY3RlZCAoaS5l
LiBqb2luaW5nKS4gIFNlY3VyaXR5IGtleSBkZWZpbml0aW9uIG11c3QgYmUgcHJvdGVjdGVkIGZy
b20gbWFsaWNpb3VzIHN1cnZlaWxsYW5jZSBvZiB0aGUgbmV0d29yay4gIE9uY2UgYXV0aGVudGlj
YXRlZCBvbnRvIHRoZSBuZXR3b3JrLCBhbGwgZGF0YSBtZXNzYWdlcyBtdXN0IGJlIGVuY3J5cHRl
ZCB0byB3YXJkIGFnYWluc3QgbWFsaWNpb3VzIGludGVudC7/AEoACAAuLwAADAAAANEvAACvAAAA
GjEAAPgBAAD+MwAA3AQAANk2AAC3BwAA9jkAANQKAACFPAAAYw0AALZBAACUEgAAKUYAAAcXAABj
CBYAYwgAAAAAAAAAAAAAFgAAAAAAAABOAJYIEACWCAAAAAAAAAAAAABC5QEAmwgQAJsIAAAAAAAA
AAAAAAEAAACMCBAAjAgAAAAAAAAAAAAAAAAAAAoAAAAJCBAAAAYQAKofzQfJAAEABgQAAAsCFAAA
AAAAAAAAABEAAAB9XQAA+WYAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18A
AgABACoAAgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEEFAAAABUAAACD
AAIAAACEAAIAAAAmAAgAAAAAAAAA6D8nAAgAAAAAAAAA6D8oAAgAAAAAAAAA8D8pAAgAAAAAAAAA
8D9NAMYSAABcAFwAYwA3AG0AawBlAHMAMgAxADIALgBjAGcALgBuAGEALgBqAGMAaQAuAGMAbwBt
AFwAQwAyADAAMAAAAAAAAQQAAdwA6BEP/wEEAQABAOoKbwhkAAEABwBYAgEAAQBYAgQAAQBMAGUA
dAB0AGUAcgAgACgAOAAuADUAIgAgAHgAIAAxADEAIgApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABAAAAAQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAFIASQBDAE8ASAAgAEEAZgBpAGMAaQBvACAATQBQACAAMwA1ADAAMAAgAFAAQwBMACAANgAA
AAAAAAAAAAAAAABMAFAAVAAxADoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBIAAAAAAAAAAAAAAQAAAMQSAAB7GQAAAAAAAAIA
AAD2CQAA5AwAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AGQAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
GAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAGQAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB
AAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAAAAAAAIAAABvCAAA6goAAAAAAABkAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAAAAAAAAAAA
AP//AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADnAwAA5wMA
AOcDAADnAwAA5wMAAOcDAADnAwAA5wMAAOcDAADnAwAA5wMAAOcDAAAAAAAAAAAAAAAAAAACAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAEQA
ZQBmAGEAdQBsAHQAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMy
MDBQMDEwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAoQAiAAEAZAABAAEAAQACAFgCWAIAAAAAAADgPwAAAAAA
AOA/AQCcCCYAnAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAABVAAIACAB9AAwA
AAAAAJIVDwACAAAAfQAMAAEAAQDbEQ8AAgAAAH0ADAACAAIASRQPAAIAAAB9AAwAAwADACQMDwAC
AAAAfQAMAAQABgDbEg8AAgAAAH0ADAAHAAcAABIPAAIAAAB9AAwACAALAEkSDwACAAAAfQAMAAwA
DAC2Eg8AAgAAAH0ADAANAA0AbRAPAAIAAAB9AAwADgAOAG0SDwACAAAAfQAMAA8ADwAAEA8AAgAA
AH0ADAAQABAA2xEPAAIAAAB9AAwAEQARAAATDwACAAAAAAIOAAAAAAARAAAAAAAaAAAACAIQAAAA
AAAaAFcDAAAAAEABDwAIAhAAAQAAABoA7QMAAAAAQAEPIAgCEAACAAAAGgA1BwAAAABAAQ8QCAIQ
AAMAAAAaAFAKAAAAAEABDwAIAhAABAAAABoACAcAAAAAQAEPAAgCEAAFAAAAGgCOCAAAAABAAQ8g
CAIQAAYAAAAaAFsOAAAAAEABDyAIAhAABwAAABoA/wAAAAAAAAEPAAgCEAAIAAAAGgD/AAAAAAAA
AQ8ACAIQAAkAAAAaAP8AAAAAAAABDwAIAhAACgAAABoA/wAAAAAAAAEPAAgCEAALAAAAGgD/AAAA
AAAAAQ8ACAIQAAwAAAAaAP8AAAAAAAABDwAIAhAADQAAABoA/wAAAAAAAAEPAAgCEAAOAAAAGgD/
AAAAAAAAAQ8ACAIQAA8AAAAaAP8AAAAAAAABDwAIAhAAEAAAABIA/wAAAAAAAAEPAP0ACgAAAAAA
WwAEAAAA/QAKAAAAAQBpAAMAAAD9AAoAAAACAGUABwAAAP0ACgAAAAMAZQARAAAA/QAKAAAABABn
AEIAAAD9AAoAAAAFAFsACQAAAL4ADAAAAAYAXABcAF0ACAD9AAoAAAAJAFsAKgAAAL4AFAAAAAoA
XABcAFwAXABcAFwAXQAQAL4AEgAAABQAQABAAEAAQABAAEAAGQC+ABAAAQAAAGQAagBmAGYAaAAE
AP0ACgABAAUATAAoAAAA/QAKAAEABgBNAC0AAAD9AAoAAQAHAE0ALAAAAP0ACgABAAgATgArAAAA
/QAKAAEACQBMACgAAAD9AAoAAQAKAE0ALQAAAP0ACgABAAsATQA7AAAA/QAKAAEADABNABoAAAD9
AAoAAQANAE0AFQAAAP0ACgABAA4ATQAkAAAA/QAKAAEADwBNACAAAAD9AAoAAQAQAE4AIQAAAL4A
EgABABQAQABAAEAAQABAAEAAGQD9AAoAAgAAAFEAEAAAAP0ACgACAAEAVAAGAAAA/QAKAAIAAgBE
AAUAAAD9AAoAAgADAEQACAAAAP0ACgACAAQARgAMAAAA/QAKAAIABQBIAC4AAAD9AAoAAgAGAGIA
LwAAAP0ACgACAAcARAASAAAA/QAKAAIACABGABIAAAD9AAoAAgAJAF4AKQAAAP0ACgACAAoAVwAy
AAAA/QAKAAIACwBPADEAAAD9AAoAAgAMAFcAFgAAAAECBgACAA0AVwD9AAoAAgAOAE8AJQAAAP0A
CgACAA8AVwAfAAAA/QAKAAIAEABhACMAAAD9AAoAAwAAAFIADgAAAP0ACgADAAEAVQAAAAAA/QAK
AAMAAgBDAB0AAAD9AAoAAwADAEMACAAAAP0ACgADAAQARQANAAAA/QAKAAMABQBfADQAAAABAgYA
AwAGAFgA/QAKAAMABwBDAAoAAAD9AAoAAwAIAEUACgAAAL4ACgADAAkAXwBYAAoA/QAKAAMACwBY
ADMAAAD9AAoAAwAMAFgAFwAAAAECBgADAA0AWAD9AAoAAwAOAEMAJgAAAL4ADAADAA8AWABgAEEA
EQD9AAoABAAAAFIACwAAAP0ACgAEAAEAVQABAAAA/QAKAAQAAgBDAEMAAAD9AAoABAADAEMADwAA
AP0ACgAEAAQARQATAAAAvgAKAAQABQBfAFgABgD9AAoABAAHAEsAGAAAAP0ACgAEAAgAYAAZAAAA
vgAMAAQACQBfAFgAWAALAP0ACgAEAAwAWAAbAAAA/QAKAAQADQBYABwAAAD9AAoABAAOAFgAJwAA
AL4ADAAEAA8AWABgAEEAEQD9AAoABQAAAFMANwAAAP0ACgAFAAEAVQACAAAA/QAKAAUAAgBDAB4A
AAD9AAoABQADAEMANgAAAP0ACgAFAAQARQAUAAAAAQIGAAUABQBfAP0ACgAFAAYAQwAwAAAAvgAW
AAUABwBLAGAAXwBYAFgAWABYAFgADgD9AAoABQAPAEMAIgAAAL4ACgAFABAAYABBABEA/QAKAAYA
AABTAEQAAAD9AAoABgABAFYAOAAAAP0ACgAGAAIARwBBAAAA/QAKAAYAAwBHADkAAAD9AAoABgAE
AEoARQAAAAECBgAGAAUAYwD9AAoABgAGAEcAMAAAAP0ACgAGAAcAWQA6AAAAAQIGAAYACABaAP0A
CgAGAAkAUAA+AAAA/QAKAAYACgBHADAAAAD9AAoABgALAEcAPwAAAAECBgAGAAwAWQD9AAoABgAN
AEcAPAAAAP0ACgAGAA4ARwA9AAAA/QAKAAYADwBZAEAAAAC+AAoABgAQAFoAQQARAL4AKgAHAAAA
QQBBAEEAQQBBAEEAQQBBAEEAQQBBAEEAQQBBAEEAQQBBAEEAEQABAgYACAAAAEEAvgAmAAgAAgBJ
AEkASQBBAEEAQQBBAEEAQQBBAEEAQQBBAEEAQQBBABEAvgAqAAkAAABBAEEAQQBBAEEAQQBBAEEA
QQBBAEEAQQBBAEEAQQBBAEEAQQARAL4ADAAKAAAAQQBBAEEAAgD9AAoACgADAEkANQAAAL4AIgAK
AAQAQQBBAEEAQQBBAEEAQQBBAEEAQQBBAEEAQQBBABEAvgAqAAsAAABBAEEAQQBBAEEAQQBBAEEA
QQBBAEEAQQBBAEEAQQBBAEEAQQARAL4AKgAMAAAAQQBBAEEAQQBBAEEAQQBBAEEAQQBBAEEAQQBB
AEEAQQBBAEEAEQC+ACoADQAAAEIAQgBCAEIAQgBCAEIAQgBCAEIAQgBCAEIAQgBCAEIAQgBCABEA
vgAqAA4AAABCAEIAQgBCAEIAQgBCAEIAQgBCAEIAQgBCAEIAQgBCAEIAQgARAL4AKgAPAAAAQgBC
AEIAQgBCAEIAQgBCAEIAQgBCAEIAQgBCAEIAQgBCAEIAEQC+ACoAEAAAAEIAQgBCAEIAQgBCAEIA
QgBCAEIAQgBCAEIAQgBCAEIAQgBCABEA1wAmAJQIAABAAaAA0gDqAMwAugCUAOIALgA0AC4ARAAu
AC4ALgAuAC4APgISAL4HAAAAAEAAAAAAAAAAQgAAAIsIEACLCAAAAAAAAAAAAAAAAEIAQQAKAAEA
AgACAAEAAAAdAA8AAwAAAAAAAAEAAAAAAAAAHQAPAAEAAAEAAAABAAAAAAABAR0ADwACAgAAAAAA
AQACAAIAAAAdAA8AAAAAAAAAAAEAAAABAAAA5QCyABYAAAABAAAAAAAAAAEAAgACAAAAAQADAAMA
AAABAAQABAAAAAEAAQABAAAAAAAFAAgAAgAEAA8ADwACAAIADAANAAMAAwAMAA0AAgAFAAkACQAE
AAUACAAIAAQABQANAA0AAgAEAAYABgADAAYABQAFAAYABgAHAAgAAgAFAAoACgADAAUACwALAAQA
BQAOAA4ABAAGAAwADAAGAAYADwAQAAAAAAAJABAAAgAFABAAEADvAAYABgA3AAAAZwgXAGcIAAAA
AAAAAAAAAAIAAf////8DRAAACgAAAAkIEAAABhAAqh/NB8kAAQAGBAAACwIQAAAAAAAAAAAAAAAA
AJhpAAANAAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIA
AACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAD/AIEAAgDBBBQAAAAVAAAAgwACAAAAhAACAAAAJgAI
AAAAAAAAAOg/JwAIAAAAAAAAAOg/KAAIAAAAAAAAAPA/KQAIAAAAAAAAAPA/oQAiAAAA/wABAAEA
AQAEAAIAAf8AAAAAAADgPwAAAAAAAOA/BACcCCYAnAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAQAAAAAAAAAAABVAAIACAAAAg4AAAAAAAAAAAAAAAAAAAA+AhIAtgAAAAAAQAAAAAAAAAAAAAAA
iwgQAIsIAAAAAAAAAAAAAAAAAgAdAA8AAwAAAAAAAAEAAAAAAAAA7wAGAAYANwAAAGcIFwBnCAAA
AAAAAAAAAAACAAH/////A0QAAAoAAAAJCBAAAAYQAKofzQfJAAEABgQAAAsCEAAAAAAAAAAAAAAA
AAAoawAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwAC
AAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAA/wCBAAIAwQQUAAAAFQAAAIMAAgAAAIQAAgAAACYA
CAAAAAAAAADoPycACAAAAAAAAADoPygACAAAAAAAAADwPykACAAAAAAAAADwP6EAIgAAAP8AAQAB
AAEABAACAAH/AAAAAAAA4D8AAAAAAADgPwAAnAgmAJwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAEAAAAAAAAAAAAVQACAAgAAAIOAAAAAAAAAAAAAAAAAAAAPgISALYAAAAAAEAAAAAAAAAAAAAA
AIsIEACLCAAAAAAAAAAAAAAAAAIAHQAPAAMAAAAAAAABAAAAAAAAAO8ABgAGADcAAABnCBcAZwgA
AAAAAAAAAAAAAgAB/////wNEAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAAIAAAADAAAA/v///wUAAAAGAAAABwAAAAgAAAD+////CgAAAP7/////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////+
/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAC0AAAABwAAAAEA
AABAAAAABAAAAEgAAAAIAAAAYAAAABIAAAB8AAAADAAAAJQAAAANAAAAoAAAABMAAACsAAAAAgAA
AOQEAAAeAAAAEAAAAEplcnJ5IE1hcnRvY2NpAAAeAAAAFAAAAEplcmFsZCBQIE1hcnRvY2NpAAAA
HgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAAAIAC/kLIlcgBQAAAAIAlWKAr48kBAwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALV
zdWcLhsQk5cIACss+a4wAAAA7AAAAAkAAAABAAAAUAAAAA8AAABYAAAAFwAAAHgAAAALAAAAgAAA
ABAAAACIAAAAEwAAAJAAAAAWAAAAmAAAAA0AAACgAAAADAAAAMkAAAACAAAA5AQAAB4AAAAYAAAA
Sm9obnNvbiBDb250cm9scywgSW5jLgAAAwAAAAAADAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAL
AAAAAAAAAB4QAAADAAAABwAAAFNoZWV0MQAHAAAAU2hlZXQyAAcAAABTaGVldDMADBAAAAIAAAAe
AAAACwAAAFdvcmtzaGVldHMAAwAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAABAP7/AwoAAP////8gCAIAAAAAAMAAAAAAAABGJgAAAE1pY3Jvc29mdCBPZmZpY2UgRXhj
ZWwgMjAwMyBXb3Jrc2hlZXQABgAAAEJpZmY4AA4AAABFeGNlbC5TaGVldC44APQ5snEAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQBD
AG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ
AAAAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////////
//////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=


--=_mixed 0057E0C186257638_=--

From dharkins@lounge.org  Mon Sep 21 23:23:48 2009
Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065F93A6891; Mon, 21 Sep 2009 23:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.008
X-Spam-Level: 
X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE63pGgOO8oK; Mon, 21 Sep 2009 23:23:47 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 1AA303A68CC; Mon, 21 Sep 2009 23:23:47 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 14809A888108; Mon, 21 Sep 2009 23:24:50 -0700 (PDT)
Received: from 12.104.232.34 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 21 Sep 2009 23:24:50 -0700 (PDT)
Message-ID: <160488202bfbd53b4fac96847974dcd2.squirrel@www.trepanning.net>
In-Reply-To: <20090921083401.GA9138@elstar.local>
References: <20090921083401.GA9138@elstar.local>
Date: Mon, 21 Sep 2009 23:24:50 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: dharkins@arubanetworks.com, gwz@netcube.com, iesg@ietf.org, secdir@ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: Re: [secdir] secdir re-review of draft-harkins-emu-eap-pwd-06.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2009 06:23:48 -0000

  Hi Juergen,

  I really apologize for missing this. I erroneously assumed this comment
was a duplicate of one I received from IANA and it obviously was not. -07
has been submitted. Please take a look and see whether it addresses your
comment. Again, sorry for the SNAFU.

  For the telechat: please use -07 and to all of you I, again, apologize
for the screw-up.

  regards,

  Dan.

On Mon, September 21, 2009 1:34 am, Juergen Schoenwaelder wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> All my previous comments concerning draft-harkins-emu-eap-pwd-04.txt
> have been addressed, except perhaps this one:
>
> c) There are two places where IANA assigned values need to be filled
>    into the text; perhaps add more explicit RFC editor instructions so
>    the editor knows what to fill in for 'TBD1'.
>
> I assume the authors will check carefully during auth48 that correct
> updates have been made by the RFC editor once IANA has assigned a
> value.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
>



From cyrus@daboo.name  Tue Sep 22 08:34:01 2009
Return-Path: <cyrus@daboo.name>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F4628C12C; Tue, 22 Sep 2009 08:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuDx3sKnD5iQ; Tue, 22 Sep 2009 08:34:00 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 4088A28C11D; Tue, 22 Sep 2009 08:34:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 1003A1FA96D; Tue, 22 Sep 2009 11:35:04 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq+UIDgEYP7m; Tue, 22 Sep 2009 11:35:03 -0400 (EDT)
Received: from caldav.corp.apple.com (caldav.corp.apple.com [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id F3CE01FA965; Tue, 22 Sep 2009 11:35:01 -0400 (EDT)
Date: Tue, 22 Sep 2009 11:34:58 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Yaron Sheffer <yaronf@checkpoint.com>, secdir <secdir@ietf.org>, iesg@ietf.org, draft-ietf-calsify-2446bis.all@tools.ietf.org
Message-ID: <7236D8B61D923C0A53A03F7E@caldav.corp.apple.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; size=2923
X-Mailman-Approved-At: Tue, 22 Sep 2009 10:51:15 -0700
Subject: Re: [secdir] SecDir review of draft-ietf-calsify-2446bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2009 15:34:01 -0000

Hi Yaron,
Thank you for your review.

--On September 21, 2009 9:02:17 AM +0300 Yaron Sheffer=20
<yaronf@checkpoint.com> wrote:

> Reality Check
>
>
>
> If basing the entire security of the protocol on S/MIME may have been
> reasonable in 1998, today this is almost meaningless. S/MIME is too
> rarely used to protect mail in transit, and I would imagine its use to
> protect calendaring is even less prevalent.

This is a good point. In fact with CalDAV we are doing iTIP scheduling over =

HTTP with SSL and S/MIME is not involved at all. Given Eliot's comment=20
about the nature of iTIP (i.e. transport independence) at this point it may =

be best to remove the explicit MUST for S/MIME.

Proposal:

Section 6.2: remove the sentence:

   This may be accomplished using
   public key technology, specifically Security Multiparts for MIME
   [RFC1847] in the iTIP transport binding.

Section 6.2.1: change title to: "Securing iTIP transactions"

Change first sentence to:

   iTIP transport bindings MUST provide a mechanism to enable=20
authentication of the
   sender's identity, and privacy and integrity of the data being
   transmitted.

The reference to 1847 would be removed entirely.

> Security
>
>
>
> - In Sec. 6.2, replace =E2=80=9Cencrypted=E2=80=9D by =E2=80=9Cencrypted =
and
> authenticated=E2=80=9D.

Fixed in my working copy.

> - An attack that is never mentioned is unauthorized creation of events.

> In many enterprise situations not everyone is authorized to invite the
> CEO, for example. Similarly, there may be tight control over who is
> allowed to delegate to whom. This obviously calls for an access control
> mechanism, something that is never mentioned in the document.

Good point. In CalDAV scheduling=20
(<http://tools.ietf.org/html/draft-desruisseaux-caldav-sched>) we have in=20
fact used WebDAV ACL with a new set of privileges to allow just that. This=20
actually goes a little beyond just access control. For example, with iMIP=20
(email) there is no way to prevent someone from sending an iMIP message to=20
someone else. In that case email filtering needs to be used to enforce=20
restrictions. Whilst the specific details of how all that should work=20
depends on the transport, something does need to be said in this document.=20
Therefore I propose adding the following:

6.2.3 Access Controls and Filtering

    In many environments there could be restrictions on who is allowed to
    scheduled with whom, and who allowed delegates are for particular
    calendar users.

    iTIP transport bindings SHOULD provide mechanisms for implementing
    access controls or filtering to ensure iTIP transactions only take
    place between authorized calendar users. That would include preventing
    one calendar user from scheduling with another, or a calendar user
    delegating to another.



> Nits
>
>
>
> - 1.4: in table, objecy -> object
>
> - 3.2.5 and 3.4.5: is MUST -> MUST

Both fixed in my working copy.

--=20
Cyrus Daboo


From yaronf@checkpoint.com  Tue Sep 22 14:48:32 2009
Return-Path: <yaronf@checkpoint.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4159A3A69E8 for <secdir@core3.amsl.com>; Tue, 22 Sep 2009 14:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwW8OZ4UxFF6 for <secdir@core3.amsl.com>; Tue, 22 Sep 2009 14:48:06 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CB66B3A69F0 for <secdir@ietf.org>; Tue, 22 Sep 2009 14:46:57 -0700 (PDT)
X-CheckPoint: {4AB944EB-6-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CAD4D29C004; Wed, 23 Sep 2009 00:47:11 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 940A329C002; Wed, 23 Sep 2009 00:47:11 +0300 (IDT)
X-CheckPoint: {4AB944EB-0-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8MLlASr019708; Wed, 23 Sep 2009 00:47:11 +0300 (IDT)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 23 Sep 2009 00:47:10 +0300
From: Yaron Sheffer <yaronf@checkpoint.com>
To: Cyrus Daboo <cyrus@daboo.name>, secdir <secdir@ietf.org>, "draft-ietf-calsify-2446bis.all@tools.ietf.org" <draft-ietf-calsify-2446bis.all@tools.ietf.org>
Date: Wed, 23 Sep 2009 00:47:07 +0300
Thread-Topic: SecDir review of draft-ietf-calsify-2446bis-09
Thread-Index: Aco7mkYE5V6mZaekRqOgE6+oPowwrAAMkC8Q
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD3286D2@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com> <7236D8B61D923C0A53A03F7E@caldav.corp.apple.com>
In-Reply-To: <7236D8B61D923C0A53A03F7E@caldav.corp.apple.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [secdir] SecDir review of draft-ietf-calsify-2446bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2009 21:48:32 -0000

Hi Cyrus,

[removing IESG].

Thanks for accepting my review. Please see my remaining responses inline.

Thanks,
	Yaron

> -----Original Message-----
> From: Cyrus Daboo [mailto:cyrus@daboo.name]
> Sent: Tuesday, September 22, 2009 18:35
> To: Yaron Sheffer; secdir; iesg@ietf.org; draft-ietf-calsify-
> 2446bis.all@tools.ietf.org
> Subject: Re: SecDir review of draft-ietf-calsify-2446bis-09
>=20
> Hi Yaron,
> Thank you for your review.
>=20
> --On September 21, 2009 9:02:17 AM +0300 Yaron Sheffer
> <yaronf@checkpoint.com> wrote:
>=20
> > Reality Check
> >
> >
> >
> > If basing the entire security of the protocol on S/MIME may have been
> > reasonable in 1998, today this is almost meaningless. S/MIME is too
> > rarely used to protect mail in transit, and I would imagine its use to
> > protect calendaring is even less prevalent.
>=20
> This is a good point. In fact with CalDAV we are doing iTIP scheduling
> over
> HTTP with SSL and S/MIME is not involved at all. Given Eliot's comment
> about the nature of iTIP (i.e. transport independence) at this point it
> may
> be best to remove the explicit MUST for S/MIME.
>=20
[YS] Well in fact, having read the first paragraph of Sec. 15 of CalDAV, I =
would recommend that you add more depth to your use of SSL. Just saying "Se=
rvers and clients MUST use an HTTP connection protected with TLS as defined=
 in [RFC2818] for all scheduling transactions" will not give you the securi=
ty that you need. Things like how clients are authenticated, and what field=
s in the calendar objects must match which certificate fields.

> Proposal:
>=20
> Section 6.2: remove the sentence:
>=20
>    This may be accomplished using
>    public key technology, specifically Security Multiparts for MIME
>    [RFC1847] in the iTIP transport binding.
>=20
> Section 6.2.1: change title to: "Securing iTIP transactions"
>=20
> Change first sentence to:
>=20
>    iTIP transport bindings MUST provide a mechanism to enable
> authentication of the
>    sender's identity, and privacy and integrity of the data being
>    transmitted.
>=20
> The reference to 1847 would be removed entirely.


[YS] If there are still bindings that do use S/MIME, you might want to have=
 "if S/MIME is used to provide these assurances..." and the rest of the exi=
sting subsection.
>=20
> > Security
> >
> >
> >
> > - In Sec. 6.2, replace "encrypted" by "encrypted and
> > authenticated".
>=20
> Fixed in my working copy.
>=20
> > - An attack that is never mentioned is unauthorized creation of events.
>=20
> > In many enterprise situations not everyone is authorized to invite the
> > CEO, for example. Similarly, there may be tight control over who is
> > allowed to delegate to whom. This obviously calls for an access control
> > mechanism, something that is never mentioned in the document.
>=20
> Good point. In CalDAV scheduling
> (<http://tools.ietf.org/html/draft-desruisseaux-caldav-sched>) we have in
> fact used WebDAV ACL with a new set of privileges to allow just that. Thi=
s
> actually goes a little beyond just access control. For example, with iMIP
> (email) there is no way to prevent someone from sending an iMIP message t=
o
> someone else. In that case email filtering needs to be used to enforce
> restrictions. Whilst the specific details of how all that should work
> depends on the transport, something does need to be said in this document=
.
> Therefore I propose adding the following:
>=20
> 6.2.3 Access Controls and Filtering
>=20
>     In many environments there could be restrictions on who is allowed to
>     scheduled with whom, and who allowed delegates are for particular
>     calendar users.
>=20
>     iTIP transport bindings SHOULD provide mechanisms for implementing
>     access controls or filtering to ensure iTIP transactions only take
>     place between authorized calendar users. That would include preventin=
g
>     one calendar user from scheduling with another, or a calendar user
>     delegating to another.
[YS] Sounds good.
>=20
>=20
>=20
> > Nits
> >
> >
> >
> > - 1.4: in table, objecy -> object
> >
> > - 3.2.5 and 3.4.5: is MUST -> MUST
>=20
> Both fixed in my working copy.
>=20
> --
> Cyrus Daboo
>=20
>=20
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point

Email secured by Check Point

From ajs@shinkuro.com  Wed Sep 23 07:04:02 2009
Return-Path: <ajs@shinkuro.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34083A6905; Wed, 23 Sep 2009 07:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level: 
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, J_CHICKENPOX_45=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 zE0nwGrDbTQT; Wed, 23 Sep 2009 07:04:01 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D83B63A659A; Wed, 23 Sep 2009 07:04:01 -0700 (PDT)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 56B1B2FE8CE3; Wed, 23 Sep 2009 14:05:07 +0000 (UTC)
Date: Wed, 23 Sep 2009 10:05:05 -0400
From: Andrew Sullivan <ajs@shinkuro.com>
To: Kurt Zeilenga <Kurt.Zeilenga@isode.com>
Message-ID: <20090923140505.GP4450@shinkuro.com>
References: <alpine.BSF.2.00.0909101523400.54991@fledge.watson.org> <9E513A07-3BE5-4D49-9BD9-211CBF0724CC@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9E513A07-3BE5-4D49-9BD9-211CBF0724CC@isode.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: draft-ietf-dnsext-dnssec-rsasha256@tools.ietf.org, dnssec-chairs@tools.ietf.org, The IESG <iesg@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review: draft-ietf-dnsext-dnssec-rsasha256
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2009 14:04:02 -0000

Hi,

Thanks for your review.  I apologise for not having responded sooner.
I was travelling on other business last week, and it meant that I
couldn't concentrate on this topic.  One note of explanation:

On Wed, Sep 16, 2009 at 10:12:25AM +0100, Kurt Zeilenga wrote:

> I do note that the document appears to place an additional  
> recommendation upon implementors of DNSSEC (in Section 5.1) yet does not 
> "update" any DNSSEC specification.   It may be appropriate for this I-D 
> to "update" (upon approval/publication) DNSSEC specifications.

We have been loathe to make this document the mechanism by which we
update the DNSSEC specifications effectively to make NSEC3 an overall
part of the DNSSEC specification.  The reason I (especially) have been
so reluctant is that we already have, in the DNS community, a long
history of complaints about apparently minor, tangential drafts making
major conceptual changes to the DNS specifications.  The idea is to
ensure that the change making NSEC3 a basic part of DNSSEC appears in
a document that is obviously about DNSSEC as such, and not just the
identifier of an algorithm that may or may not get implemented.

We in fact have a draft in process that is to contain this change.
It's draft-ietf-dnsext-dnssec-bis-updates.  It has been moving
somewhat slowly through the WG, but I believe it is on track to be
published soon.  The current text in that document is this:

2.1.  NSEC3 Support

   [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
   records for hashed denial of existence.  Validator implementations
   are strongly encouraged to include support for NSEC3 because a number
   of highly visible zones are expected to use it.  Validators that do
   not support validation of responses using NSEC3 will likely be
   hampered in validating large portions of the DNS space.

   [RFC5155] should be considered part of the DNS Security Document
   Family as described by [RFC4033], Section 10.

All of that said, if you feel strongly that, in the absence of
publication of dnssec-bis-updates, the sha-2 draft ought to update
RFC4033, we can relucantly make the change.  In that case, we will
plan to leave the above text in dnssec-bis-updates anyway, in an
effort to make this point plain to a potentially wider audience.

Best regards,

Andrew (shepherd)

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

From derek@ihtfp.com  Wed Sep 23 07:25:48 2009
Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE7E3A682E; Wed, 23 Sep 2009 07:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Level: 
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8JMSjsAB1zR; Wed, 23 Sep 2009 07:25:47 -0700 (PDT)
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 95E743A67E7; Wed, 23 Sep 2009 07:25:47 -0700 (PDT)
Received: from pgpdev.ihtfp.org (unknown [69.7.239.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 8DE3F8B4005; Wed, 23 Sep 2009 10:26:52 -0400 (EDT)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id n8NEQWjB031346; Wed, 23 Sep 2009 10:26:32 -0400
To: Jerald.P.Martocci@jci.com
References: <OF3BF99F7E.D8461727-ON86257638.0055170A-86257638.0057E142@jci.com>
From: Derek Atkins <derek@ihtfp.com>
Date: Wed, 23 Sep 2009 10:26:32 -0400
In-Reply-To: <OF3BF99F7E.D8461727-ON86257638.0055170A-86257638.0057E142@jci.com> (Jerald P. Martocci's message of "Mon\, 21 Sep 2009 10\:59\:52 -0500")
Message-ID: <sjmbpl17n53.fsf@pgpdev.ihtfp.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: secdir@ietf.org, nicolas.riou@fr.schneider-electric.com, pieter.demil@intec.ugent.be, iesg@ietf.org, roll-chairs@tools.ietf.org, wouter@vooruit.be, Adrian Farrel <Adrian.Farrel@huawei.com>
Subject: Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2009 14:25:48 -0000

Hi,

First, I do think you need to change the structure and re-introduce the
"Security Considerations" section.

Second, I think it's important (even in a requirements document) to
explain the ramifications of different security tradeoffs.

I agree that you don't need to specify "Use AES-256 in GCM mode" in this
document.  However I do think you need to go into more detail about the
various security services that your protocols will need to define, and
the trade-offs that might happen if they choose to define it one way
versus another.  In other words, what are the security requirements for
your sub-protocols?

I don't think the current draft goes into quite enough detail in
answering these questions.  I think the questions I posed below still
apply, even in a requirements document.  Providing guidance to protocol
designers is still appropriate.

-derek

Jerald.P.Martocci@jci.com writes:

> Hi Derek,
>
> As the author of the document, I am trying to describe in this requiremen=
ts ID
> the flexibility of setting up the security policies (as Adrian notes) rat=
her
> then the application specifics of picking a security policy for a given
> application.  Earlier versions of this ID included this information, but =
was
> dropped since it was out of scope for the routing protocol.=20=20
>
> I have recently been requested to draft an ID for the 6LowAPP that would =
deal
> specifically with Building Applications at the application layer rather t=
han
> at the routing layer.  Here, I intend to reinject into this new ID specif=
icity
> as to when different security strategies are required.  I have attached a
> spreadsheet that describes 5 different security policies (rows) that must=
 be
> configurable for many different types of commercial buildings with the va=
rying
> requirements for each building type (columns).  I intend to redraft this
> spreadsheet into a section of the ID.=20=20
>
> I hope this is more of what you're looking for and can accept that I will=
 put
> is into a separate ID.  If you think any of this should be put into the
> existing requirements ID, let me know and I will add it in.
>
> Best Regards,
>
> Jerry Martocci
>
> Adrian Farrel                       To Derek Atkins <derek@ihtfp.com>,=20=
=20=20=20=20=20=20=20=20
> <Adrian.Farrel@huawei.com>             iesg@ietf.org, secdir@ietf.org=20=
=20=20=20=20=20=20=20=20=20
>                                     cc pieter.demil@intec.ugent.be,=20=20=
=20=20=20=20=20=20=20=20=20=20
> 09/20/2009 05:00 AM                    nicolas.riou@fr.schneider-electric=
.com,=20
> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90         jerald.p.martocci@=
jci.com,=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> =E2=94=82     Please respond to      =E2=94=82         wouter@vooruit.be,=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> =E2=94=82       Adrian Farrel        =E2=94=82         roll-chairs@tools.=
ietf.org=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> =E2=94=82 <Adrian.Farrel@huawei.com> =E2=94=82 Subject Re: sec-dir review=
 of=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98         draft-ietf-roll-bu=
ilding-routing-reqs-07
>
> Hi Derek,
>
> I very much appreciate your review.
>
> It is important to understand that this document specifies requirements t=
hat
> must/should/etc be satisfied by a protocol designed by the working group.
> Thus, there is no question of what should be deployed or what should be
> implemented.
>
> That is, the document specifies what must be in the protocol spec. We can
> expect the protocol spec to discuss what must be implemented. And either =
the
> protocol spec or an applicability statement would describe what must be
> deployed.
>
> So, the concerns you raise would be very important in the final protocol
> spec (and I hope the chairs and authors are paying attention), but do not
> seem to me to fit in this document.
>
> Thanks,
> Adrian
>
>>> The Security Considerations appear to take into account various
>>> requirements for different systems.  What seems to be lacking is
>>> direction about how or when to apply various requirements and what
>>> it means to the deployment.
>>>
>>> For example, what would it mean to a deployment if it has
>>> authentication versus not having authentication?  Also, it's unclear
>>> how these requirements would apply to an implementor.
>>>
>>> Variable security policies is a good idea, but it requires more
>>> guidance because the end user will never understand the ramifications
>>> of choosing one policy over another.
>
>

--=20
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From weiler+secdir@watson.org  Fri Sep 25 08:04:44 2009
Return-Path: <weiler+secdir@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218B03A688F for <secdir@core3.amsl.com>; Fri, 25 Sep 2009 08:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level: 
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUaDVaQ9qHzu for <secdir@core3.amsl.com>; Fri, 25 Sep 2009 08:04:42 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 1D0FA3A69A4 for <secdir@ietf.org>; Fri, 25 Sep 2009 08:04:41 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n8PF5qqF025140 for <secdir@ietf.org>; Fri, 25 Sep 2009 11:05:52 -0400 (EDT) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n8PF5qsT025137 for <secdir@ietf.org>; Fri, 25 Sep 2009 11:05:52 -0400 (EDT) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 25 Sep 2009 11:05:52 -0400 (EDT)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.0909251056060.18409@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Fri, 25 Sep 2009 11:05:52 -0400 (EDT)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2009 15:04:44 -0000

Dan Harkins is next in the rotation.

Please try to complete last call reviews by the end of the last call. 
For documents on telechat, note that the deadline field shown below 
reflects the telechat date, even though last call likely expires (or 
expired) before then.

Review instructions and related resources are at:
       http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam


For telechat 2009-10-08

Reviewer                 Deadline   Draft
Dave Cridland          T 2009-10-06 draft-ietf-ipsecme-ikev2-ipv6-config-02
Alan DeKok             TR2009-10-06 draft-ietf-roll-home-routing-reqs-08
Tobias Gondrom         T 2009-10-06 draft-ietf-mpls-tp-nm-req-05
Phillip Hallam-Baker   T 2009-10-06 draft-ietf-pmol-sip-perf-metrics-04
Phillip Hallam-Baker   T 2009-10-06 draft-ietf-mpls-tp-oam-requirements-03
Steve Hanna            T 2009-10-06 draft-ietf-krb-wg-cross-problem-statement-04
Chris Newman           T 2009-10-06 draft-ietf-mboned-lightweight-igmpv3-mldv2-05

Last calls and special requests:

Reviewer                 Deadline   Draft
Rob Austein              2009-10-07 draft-reschke-rfc2731bis-02
Pat Cain                 2009-09-30 draft-ietf-vcarddav-carddav-09
Ran Canetti              2009-09-28 draft-ietf-sasl-scram-07
Alan DeKok               2009-08-17 draft-turner-deviceowner-attribute-01
Alan DeKok               2009-10-01 draft-ietf-enum-enumservices-transition-03
Donald Eastlake          None       draft-ietf-geopriv-held-identity-extensions-00
Shawn Emery              2009-08-04 draft-ietf-alto-problem-statement-04
Shawn Emery              2009-10-05 draft-ietf-mpls-tp-gach-dcn-06
Stephen Farrell          2009-09-07 draft-ietf-tls-rfc4366-bis-05
Steve Hanna              2009-10-05 draft-ietf-pkix-sha2-dsa-ecdsa-08
Love Hornquist-Astrand   2009-03-31 draft-ietf-ipfix-mib-07
Love Hornquist-Astrand   2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05
Julien Laganier          2009-01-22 draft-ietf-sip-certs-09
Julien Laganier          2009-06-09 draft-ietf-enum-3761bis-04
Catherine Meadows        2008-01-17 draft-ietf-speechsc-mrcpv2-20
Sandy Murphy             2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-14
Sandy Murphy             2009-09-04 draft-ietf-rtgwg-ipfrr-framework-12
Vidya Narayanan          2008-11-21 draft-ietf-sip-saml-06
Eric Rescorla            2009-10-05 draft-ietf-ccamp-mpls-graceful-shutdown-12
Joe Salowey              2009-02-08 draft-ietf-geopriv-lis-discovery-11
Hannes Tschofenig        2009-04-23 draft-ietf-pce-monitoring-05
Hannes Tschofenig        2009-10-07 draft-carpenter-renum-needs-work-03
Sam Weiler               2008-08-13 draft-chown-v6ops-rogue-ra-03
Sam Weiler               2009-09-23 draft-ietf-eai-downgraded-display-02
Brian Weis               2009-09-22 draft-ietf-mipshop-pfmipv6-09
Nico Williams            2008-08-13 draft-ietf-v6ops-ra-guard-03
Nico Williams            2009-09-22 draft-ietf-nfsv4-federated-fs-reqts-03
Tom Yu                   2009-09-22 draft-ietf-rmt-pi-alc-revised-08
Larry Zhu                2008-08-13 draft-thaler-v6ops-teredo-extensions-04
Larry Zhu                2009-05-09 draft-ietf-ecrit-location-hiding-req-02
Larry Zhu                2009-09-17 draft-ietf-rohc-hcoipsec-11
Glen Zorn                2009-09-17 draft-ietf-rohc-ikev2-extensions-hcoipsec-09

From tlyu@MIT.EDU  Fri Sep 25 18:51:19 2009
Return-Path: <tlyu@MIT.EDU>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5265F3A6774; Fri, 25 Sep 2009 18:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.266
X-Spam-Level: 
X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7Xxgw8Onrp9; Fri, 25 Sep 2009 18:51:18 -0700 (PDT)
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 772493A659A; Fri, 25 Sep 2009 18:51:18 -0700 (PDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8Q1qPFR025266; Fri, 25 Sep 2009 21:52:25 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n8Q1qNYF015057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Sep 2009 21:52:24 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n8Q1qNbN003954; Fri, 25 Sep 2009 21:52:23 -0400 (EDT)
To: iesg@ietf.org, secdir@ietf.org, rmt-chairs@tools.ietf.org, luby@qualcomm.com, watson@qualcomm.com, vicisano@qualcomm.com
From: Tom Yu <tlyu@MIT.EDU>
Date: Fri, 25 Sep 2009 21:52:23 -0400
Message-ID: <ldvpr9ezd48.fsf@cathode-dark-space.mit.edu>
Lines: 12
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Subject: [secdir] secdir review of draft-ietf-rmt-pi-alc-revised-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Sep 2009 01:51:19 -0000

Security:

The Security Considerations section looks reasonably thorough.  It
might be a good idea for an IPsec expert to take another look at it,
as I am not very familiar with IPsec.

Editorial:

Section 1.3 indicates that the Any-Source Multicast (ASM) model of
multicast is defined in RFC 1112.  That RFC does not actually use that
terminology, even though it may define the concept.  The first RFC
that I can find that uses the term Any-Source Multicast is RFC 3569.

From gnakibly@yahoo.com  Tue Sep 29 03:39:53 2009
Return-Path: <gnakibly@yahoo.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3833A6896 for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 03:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.396
X-Spam-Level: 
X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=0.604,  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 AaCEHVAw+kzZ for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 03:39:49 -0700 (PDT)
Received: from web45503.mail.sp1.yahoo.com (web45503.mail.sp1.yahoo.com [68.180.197.71]) by core3.amsl.com (Postfix) with SMTP id 9F5C83A67F1 for <secdir@ietf.org>; Tue, 29 Sep 2009 03:39:49 -0700 (PDT)
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 <gnakibly@yahoo.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Christian Huitema <huitema@microsoft.com>, v6ops <v6ops@ops.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
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2009 10:39:53 -0000

Hi Fred,=0ABack from vacation. See Comments inlines.=0A=0AGabi=0A=0A=0A=0A-=
---- Original Message ----=0A> From: "Templin, Fred L" <Fred.L.Templin@boei=
ng.com>=0A> To: Gabi Nakibly <gnakibly@yahoo.com>; Christian Huitema <huite=
ma@microsoft.com>; v6ops <v6ops@ops.ietf.org>=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 Fred.L.Templin@boeing.com  Tue Sep 29 08:59:43 2009
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324CE3A67B2; Tue, 29 Sep 2009 08:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.774
X-Spam-Level: 
X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=0.225,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC+RP9dlYPs1; Tue, 29 Sep 2009 08:59:41 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id D3A3F3A6876; Tue, 29 Sep 2009 08:59:41 -0700 (PDT)
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" <Fred.L.Templin@boeing.com>
To: Gabi Nakibly <gnakibly@yahoo.com>, Christian Huitema <huitema@microsoft.com>, v6ops <v6ops@ops.ietf.org>
Date: Tue, 29 Sep 2009 09:00:55 -0700
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
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2009 15:59:43 -0000

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" <Fred.L.Templin@boeing.com>
> > To: Gabi Nakibly <gnakibly@yahoo.com>; Christian Huitema <huitema@micro=
soft.com>; v6ops
> <v6ops@ops.ietf.org>
> > 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 secdir-bounces@mit.edu  Tue Sep 29 09:30:43 2009
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0A83A67F8 for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 09:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.399
X-Spam-Level: 
X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 oH4gFbrWGrZ7 for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 09:30:41 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 47C0B3A6AFA for <secdir@ietf.org>; Tue, 29 Sep 2009 09:30:38 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8TGVvNV006080 for <secdir@ietf.org>; Tue, 29 Sep 2009 12:31:57 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8TGVq12006066 for <secdir@PCH.mit.edu>; Tue, 29 Sep 2009 12:31:52 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n8TGVcJq027146 for <secdir@mit.edu>; Tue, 29 Sep 2009 12:31:38 -0400 (EDT)
Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id B49E01F0D5ED for <secdir@mit.edu>; Tue, 29 Sep 2009 12:31:37 -0400 (EDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id ZDsXPzqDTvQkITPB for <secdir@mit.edu>; Tue, 29 Sep 2009 12:31:37 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org;
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1A33A67F8; Tue, 29 Sep 2009 09:30:14 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 54BC43A69B7; Tue, 29 Sep 2009 09:30:01 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20090929163002.54BC43A69B7@core3.amsl.com>
Date: Tue, 29 Sep 2009 09:30:01 -0700 (PDT)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Tue, 29 Sep 2009 09:49:07 -0700
Subject: [secdir] [New-work] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2009 16:30:43 -0000

A modified charter has been submitted for the Behavior Engineering for
Hindrance Avoidance (behave) working group in the Transport Area of the
IETF.  The IESG has not made any determination as yet.  The modified
charter is provided below for informational purposes only.  Please send
your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October
6, 2009.

Behavior Engineering for Hindrance Avoidance (behave)
-----------------------------------------------------
Current Status: Active Working Group
Last Modified: 2009-09-09

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/behave
Chair(s):

    * Dan Wing <dwing@cisco.com>
    * Dave Thaler <dthaler@microsoft.com>

Transport Area Director(s):

    * Magnus Westerlund <magnus.westerlund@ericsson.com>
    * Lars Eggert <lars.eggert@nokia.com>

Transport Area Advisor:

    * Magnus Westerlund <magnus.westerlund@ericsson.com>

Mailing Lists:
  General Discussion: behave@ietf.org
  To Subscribe: behave-request@ietf.org
  In Body: In Body: subscribe
  Archive: http://www.ietf.org/mail-archive/web/behave

Description of Working Group:

The behavior of NATs varies from one implementation to another. As a 
result it is very difficult for applications to predict or discover the 
behavior of these devices. Predicting and/or discovering the behavior 
of NATs is important for designing application protocols and NAT 
traversal techniques that work reliably in existing networks. This 
situation is especially problematic for end-to-end applications where 
one or both end-points are behind a NAT, such as multiuser games, 
interactive multimedia and P2P download.

The working group documents best current practices to enable NATs to 
function in as deterministic a fashion as possible. The NAT behavior 
practices will be application independent. This has already completed 
for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any 
additional protocol deemed necessary to handle. The WG has documented 
approaches for characterizing and testing NAT devices.

BEHAVE will develop protocol-independent toolkits usable by application 
protocols for NAT traversal. The WG has already produced an update of 
the binding discovery protocol STUN. It will now produce a relay 
protocol that focuses on security and is usable with both IPv4 and 
IPv6, and capable of relaying between the two IP versions.

Due to the WG's experience with translators and their behavior it has 
been given the following tasks to help encourage migration to IPv6. To 
support deployments where communicating hosts require using different 
address families (IPv4 or IPv6), address family translation is 
needed to establish communication. In BEHAVE's specification work on 
this topic it will coordinate with the V6ops WG on requirements and 
operational considerations.

"An IPv4 network" or "an IPv6 network" in the descriptions below refer 
to a network with a clearly identifiable administrative domain (e.g., 
an enterprise campus network, a mobile operator's cellular network, a 
residential subscriber network, etc.). It will also be that network 
that deploys the necessary equipment for translation.

The BEHAVE WG will design solutions for the following six translation
scenarios; other scenarios are out of scope:

1. An IPv6 network to IPv4 Internet, i.e. perform translation between 
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv6 host towards an IPv4 host. The translator 
function is intended to service a specific IPv6 network of arbitary 
size. Port translation is necessary on the IPv4 side for efficient IPv4 
address usage.

2. IPv6 Internet to an IPv4 network, i.e. perform translation between 
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv6 host towards an IPv4 host. The translator 
function is intended to service a specific IPv4 network using either 
private or public IPv4 addresses. This scenario has different 
constraints compared to (1), e.g. the IPv4 hosts that are to be 
reachable over IPv6 can be enumerated. Therefore, the WG should attempt 
to design a simpler solution with less impact on applications.

3. An IPv4 network to IPv6 Internet, i.e. perform translation between 
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv4 host towards an IPv6 host. The translator 
function is intended to service a specific IPv4 network using either 
public or private IPv4 address space.

4. IPv4 Internet to an IPv6 network, i.e. perform translation between 
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv4 host towards an IPv6 host. The translator 
function is intended to service a specific IPv6 network where selected 
IPv6 hosts and services are to be reachable.

5. An IPv6 network to an IPv4 network, i.e., perform translation between
IPv6 and IPv4 for packets in uni- or bi-directional flows that are 
initiated from an IPv6 host towards an IPv4 host.  The translation 
function is intended to service a specific IPv6 network of arbitrary 
size and a specific IPv4 network of arbitrary size (neither of which are 
the Internet).

6. An IPv4 network to an IPv6 network, i.e., perform translation between
IPv4 and IPv6 for packets in uni- or bi-directional flows that are 
initiated from an IPv4 host towards an IPv6 host.  The translation 
function is intended to service a specific IPv6 network of arbitrary 
size and a specific IPv4 network of arbitrary size (neither of which are 
the Internet).

All translation solutions shall be capable of handling flows using TCP, 
UDP, DCCP, and SCTP, unless they prevent a timely completion of the 
work item. The parts of ICMP that can be translated are also required 
to work across a translation solution.  Additional protocols directly 
on top of IP may be supported. Translation mechanisms must handle IP 
fragmentation.

The translators should support multicast traffic and its control 
traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) 
and Any Source Multicast (ASM). However, the WG may determine that it 
becomes too complex or too difficult to realize with maintained 
functionality, for some or all cases of multicast functionality.

Translation mechanisms cannot transparently support protocols that 
embed network addresses within their protocol messages without 
application level gateways (ALGs). Because ALGs have security issues 
(like blocking usage of TLS), are error prone and brittle, and hinder 
application development, the usage of ALGs in the defined translators 
should be avoided. Instead application developers will need to be aware 
and use mechanisms that handle the address family translation. ALGs may 
be considered only for the most crucial of legacy applications.

DNS is a crucial part in making a large number of applications work 
across a translator. Thus the solution to the above translation cases 
shall include recommendations for DNS. If additional DNS functionality 
is needed, it may be developed. Any DNS extensions must be developed 
together with the DNSEXT WG, including issuing a joint WG last call for 
any documents.

The WG needs to determine the best method for providing address space 
to a translator in the different deployment cases and documenting the 
pros and cons of the suggested approaches. The WG is to seek input from 
the Routing, Operations and Internet areas.

Solutions may solve more than one of the cases, however timely delivery
is more important than a unified solution.

Goals and Milestones:

Done	  Submit BCP that defines unicast UDP behavioral requirements 
for NATs to IESG
Done	  Submit a BCP that defines TCP behavioral requireents for NATs 
to IESG
Done	  Submit a BCP that defines ICMP behavioral requirements for 
NATs to IESG
Done	  Submit informational that discusses current NAT traversal 
techniques used by applications
Done	  Submit BCP that defines multicast UDP
Done	  Submit revision of RFC 3489 to IESG behavioral requirements for 
NATs to IESG
Done	  Submit informational document for rfc3489bis test vectors
Done	  Submit experimental document that describes how an application 
can determine the type of NAT it is behind
Done	  Submit BCP document for DCCP NAT behavior
Dec 2009  Submit to IESG: SCTP NAT behavior (BCP)
Done      Submit to IESG: relay protocol (std)
Done      Determine relative prioritization of the four translation 
cases. Documented in IETF74 minutes.
Sep 2009  Submit to IESG: relaying of a TCP bytestream (std)
Dec 2009  Submit to IESG: IPv6 relay protocol (std)
Done      Determine what solutions(s) and components are needed to solve 
each of the four cases. Create new milestones for the solution(s) and 
the components. Documented in IETF74 minutes.
Done      Submit to IESG:  TURN-URI document (std)
Dec 2009  Submit to IESG:  framework for IPv6/IPv4 translation (info)
Dec 2009  Submit to IESG:  stateless IPv6/IPv4 translation (std)
Dec 2009  Submit to IESG:  stateful IPv6/IPv4 translation (std)
Dec 2009  Submit to IESG:  DNS rewriting for IPv6/IPv4 translation (std)
Jan 2010  Submit to IESG:  FTP ALG for IPv6/IPv4 translation (std)
Jan 2010  Submit to IESG:  IPv6 prefix for IPv6/IPv4 translator (std)
Mar 2010  Submit to IESG:  large scale NAT requirements (BCP)
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir

From secdir-bounces@mit.edu  Tue Sep 29 09:45:32 2009
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBC428C170 for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 09:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.999
X-Spam-Level: 
X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 CFEhTSK5hQtF for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 09:45:30 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id BDD3128C173 for <secdir@ietf.org>; Tue, 29 Sep 2009 09:45:28 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8TGknHW009800 for <secdir@ietf.org>; Tue, 29 Sep 2009 12:46:49 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8TGkkoK009788 for <secdir@PCH.mit.edu>; Tue, 29 Sep 2009 12:46:48 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n8TGkZQ8020110 for <secdir@mit.edu>; Tue, 29 Sep 2009 12:46:36 -0400 (EDT)
Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id E9DE81F0F8F2 for <secdir@mit.edu>; Tue, 29 Sep 2009 12:46:34 -0400 (EDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id TyEb6bKdjxXyfuxw for <secdir@mit.edu>; Tue, 29 Sep 2009 12:46:34 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org;
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6DA28C19D; Tue, 29 Sep 2009 09:45:12 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id D9AE528C174; Tue, 29 Sep 2009 09:45:01 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20090929164501.D9AE528C174@core3.amsl.com>
Date: Tue, 29 Sep 2009 09:45:01 -0700 (PDT)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Tue, 29 Sep 2009 09:49:10 -0700
Subject: [secdir] [New-work] WG Review: Recharter of Access Node Control	Protocol	(ancp)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2009 16:45:32 -0000

A modified charter has been submitted for the Access Node Control Protocol
(ancp) working group in the Internet Area of the IETF.  The IESG has not
made any determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list (iesg@ietf.org) by Tuesday, October 6, 2009.

Access Node Control Protocol (ancp)
-----------------------------------
Current Status: Active Working Group

 Chair(s):
   Wojciech Dec  <wdec@cisco.com>
   Matthew Bocci  <matthew.bocci@alcatel-lucent.com>

 Internet Area Director(s):
   Ralph Droms  <rdroms@cisco.com>
   Jari Arkko  <jari.arkko@piuha.net>

 Internet Area Advisor:
   Ralph Droms  <rdroms@cisco.com>

 Technical Advisor(s):
   Dan Romascanu  <dromasca@avaya.com>

 Mailing Lists:
   General Discussion: ancp@ietf.org
   To Subscribe:       ancp-request@ietf.org
      In Body:         In Body: subscribe your_email_address
   Archive:           
http://www.ietf.org/mail-archive/web/ancp/current/maillist.html


Description of Working Group: 
Purpose: 

The purpose of the ANCP WG is to standardize an IP-based Access Node
Control Protocol (ANCP) for use in service provider Digital Subscriber
Line (DSL) and Passive Optical Network (PON) access and aggregation
networks.  ANCP operates between an Access Node (AN) and Network
Access Server (NAS).

Necessary Terminology: 

Access Node (AN) - Network device, usually located at a service
provider central office or street cabinet, that terminates access loop
connections from Subscribers. In DSL, this is often referred to as a
Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is
usually comprised of an Optical Network Termination (ONT) / Optical
Network Unit (ONU) and an Optical Line Termination (OLT).

Network Access Server (NAS) - Network device which aggregates
multiplexed Subscriber traffic from a number of Access Nodes. The NAS
plays a central role in per-subscriber policy enforcement and QoS.
This is often referred to as a Broadband Network Gateway (BNG) or
Broadband Remote Access Server (BRAS). A detailed definition of the
NAS is given in RFC2881.

Goals: 

ANCP is intended to address the requirement for a bidirectional, IP-
based, control protocol that operates across multiple types (i.e.,
Ethernet, ATM) of DSL and PON access and aggregation networks. The
goal of an ANCP message exchange is to convey status and control
information between one or more ANs and one or more NASs without going
through intermediate element managers.

The ANCP WG will address the following four use-cases: 

1. Dynamic Access Loop Attributes
Various queuing and scheduling mechanisms are used in access networks
to avoid congestion while dealing with multiple flows and distinct QoS
profiles. Communicating the access-loop status, attributes and current
DSL synchronization rate between the AN and Subscriber up to the NAS
is desirable, particularly when the NAS is providing QoS for
individual flows and subscribers. ANCP will provide a mechanism to
communicate dynamic access-loop attributes from the AN to the NAS.

2. Access Loop Configuration
In additional to reporting Access Loop characteristics from the AN to
the NAS, ANCP will allow a NAS to send loop-specific configuration
information to an AN based on the results of subscriber authentication
and authorization (e.g., after AAA responses have been received at the
NAS).

3. Remote Connectivity Test
Traditional DSL access and aggregation networks employ point-to-point
ATM circuits between the AN and NAS for each subscriber, allowing
troubleshooting of the local loop from the NAS via ATM OAM tools. With
the increasing deployment of Ethernet in the access and aggregation
network, operators require consistent methods to test and troubleshoot
connectivity for mixed Ethernet and ATM access networks (including the
local loop). ANCP will allow a remote procedure for a local loop
connectivity test to be triggered from the NAS with results
communicated back to the NAS.

4. Multicast
When multicast replication for subscriber-bound traffic is performed
at the AN, it offloads the network between the AN and NAS. However, a
subscriber's policy and configuration for multicast traffic may only
be known at the NAS. ANCP will provide a mechanism to communicate the
necessary information exchange between the AN and NAS so as to allow
the AN to perform subscriber bound multicast group replication in line
with the subscriber's policy and configuration, and also allow the NAS
to follow each subscriber's multicast group membership.

Non-Goals: 

ANCP is an IP-based protocol that operates between the AN and NAS. It
will not address setup or configuration of circuits or connections in
the access and aggregation network itself.

The focus of this WG is on one very specific application space. While
the design of the protocol must be general as to not preclude other
uses in the future should a need arise, it is not a goal of this WG to
address specific requirements outside of service provider broadband
(such as xDSL, xPON) access and aggregation networks.


Security: 

The ANCP working group will provide a threat analysis and address the
associated security aspects of the control protocol.

Resiliency and Scalability: 

A graceful restart mechanism will be defined to enable the protocol to
be resilient to network failures between the AN and NAS.

Scalability at the NAS is of primary concern, as it may be aggregating
traffic from a large number of ANs, which in turn may be serving a
large number of Subscribers. ANCP traffic should not become a denial
of service attack on the NAS control plane. Format of messages,
pacing, transport over UDP or TCP, etc. will be considered with this
in mind.

For reasons of aggregation network scalability, some use cases require
that aspects of NAS or AN functionality may be distributed in nodes in
the aggregation network. In these cases, ANCP can run between these
nodes.

Deliverables: 

The working group will define a basic framework and requirements
document intended for Informational publication, focusing on the four
use-cases outlined in this charter. This document will include a
security threat analysis and associated requirements. The WG will then
investigate and define a solution for an IP based control protocol
meeting these requirements.

There are early interoperable implementations of an ANCP-like protocol
which are based on an extended subset of the GSMPv3 protocol. This
running code will be the the starting point for the working group
solution, and will be abandoned only if the WG determines it is not
adequate to meet requirements going forward.

Coordination with other Working Groups or Organizations: 

The working group will coordinate with the ADSL MIB working group so
the management framework and MIB modules are consistent for DSL access
environments. The working group will re-use, as far as possible,
standard MIB modules that have already been defined.

The remote connectivity test use case may require coordination with
ITU-T Ethernet OAM and PON work and with IEEE 802.1ag.

Goals and Milestones: 

Done            Accept WG I-D for ANCP Framework and Requirements 
Done            Accept WG I-D for Access Node Control Protocol (ANCP) 
Done            Accept WG ID for Security Threats analysis 
Done            Accept WG I-D for ANCP MIB 
Done            Security Threats Analysis last call 
Done            Framework and Requirements last call 
Done            Accept WG I-D for ANCP Multicast Extensions
Nov 2009        Accept WG I-D for ANCP applicability to PON 
Jan 2010        Access Node Control Protocol (ANCP) Last Call 
Jan 2010        ANCP Multicast Extensions last call
Jan 2010        ANCP MIB Last Call 
Apr 2010        ANCP applicability to PON last call
Jul 2010        Re-charter or conclude Working Group
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir

From secdir-bounces@mit.edu  Tue Sep 29 10:00:30 2009
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131FB3A6AF2 for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 10:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.799
X-Spam-Level: 
X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Pcmab-tmKMpR for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 10:00:28 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5C0383A6B07 for <secdir@ietf.org>; Tue, 29 Sep 2009 10:00:26 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8TH1lRU013892 for <secdir@ietf.org>; Tue, 29 Sep 2009 13:01:47 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8TH1ibq013880 for <secdir@PCH.mit.edu>; Tue, 29 Sep 2009 13:01:46 -0400
Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8TH1VL1016192 for <secdir@mit.edu>; Tue, 29 Sep 2009 13:01:31 -0400 (EDT)
Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 64075122A63E for <secdir@mit.edu>; Tue, 29 Sep 2009 13:01:29 -0400 (EDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id DFEDop05RfyJpvs1 for <secdir@mit.edu>; Tue, 29 Sep 2009 13:01:29 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org;
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C77B3A6B07; Tue, 29 Sep 2009 10:00:06 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 983703A698E; Tue, 29 Sep 2009 10:00:01 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20090929170001.983703A698E@core3.amsl.com>
Date: Tue, 29 Sep 2009 10:00:01 -0700 (PDT)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Tue, 29 Sep 2009 10:03:41 -0700
Subject: [secdir]  [New-work] WG Review: Multipath TCP (mptcp)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2009 17:00:30 -0000

A new IETF working group has been proposed in the Transport Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday,
October 6, 2009.

Multipath TCP (mptcp)
===========================================
Current Status: Proposed Working Group
Last updated: 2009-09-28

Chair(s):
 
    * To be decided

Transport Area Director(s):

    * Magnus Westerlund <magnus.westerlund@ericsson.com>
    * Lars Eggert <lars.eggert@nokia.com>

Transport Area Advisor:

    * Magnus Westerlund <magnus.westerlund@ericsson.com>

Mailing List:
To subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp
Archive:      http://www.ietf.org/mail-archive/web/multipathtcp/

Description of Working Group:

The Multipath TCP (MPTCP) working group develops mechanisms that add 
the capability of simultaneously using multiple paths to a regular TCP 
session. The primary output of the group will be the protocol 
extensions needed to deploy MPTCP, and adaptations to congestion 
control to safely support multipath resource sharing. Initially the WG 
will only produce documents that are experimental or informational. 

Key goals for MPTCP are: to be deployable and usable without 
significant changes to existing Internet infrastructure; to be usable 
by unmodified applications; and to be stable and congestion-safe over 
the wide range of existing Internet paths. That will include handling 
MTU discovery on a per path basis and NAT interactions. The design's 
success in meeting the goals should be determined through experiments. 
However, it is expected that some results from large scale experiments 
can only be achievable after the publication of the initial design. 

The working group will provide a modular architecture that is designed 
to be easily extensible and adaptable. In particular, the congestion 
control mechanism is separated from the mechanisms for identifying and 
using multiple paths. The working group will focus on a solution 
requiring modification of both peers. One or both peers are expected to 
have multiple addresses, which often results in different network paths 
that are at least partially divergent. However, multiple addresses, 
even on different network interfaces, are no guarantee that the paths 
are divergent at all. The design needs to address the issues associated 
with fully or partially joint paths and shared bottlenecks. The design 
should allow for future extensions to handle cases where path diversity 
is attempted through other means than using different addresses. The 
design must also consider what happens when end-point pairs become 
unavailable during an ongoing session, especially pairs used to 
establish connections between additional end-point pairs. 

Whilst MPTCP will require modifications to the TCP stack at both the 
peers, all existing applications should be able to use the new MPTCP 
stack without modification and gain benefits from multipath usage. The 
impact on different classes of applications will be considered and 
documented. An extended API will be defined to allow applications to 
express particular preferences for how MPTCP operates, and to get 
additional information about MPTCP-specific run-time events. 

The WG will carefully analyze and address in the appropriate protocol 
documents all new security threats introduced by MPTCP.

The following items will be worked on:

a. An architectural framework for congestion-dependent multipath 
transport protocols. This is an overview document which tracks the 
technical documents, describing how the modular components fit 
together, and will describe the motivations and the general approach 
that should be followed to enable congestion-dependent multipath 
transport. It will also analyze how MPTCP interacts with existing 
infrastructure elements and other address agility mechanisms, such as 
Mobile IP, HIP and SHIM6. The results of any experiment performed 
during the development should also be included or referenced in this 
document. 

b. A security threat analysis for multipath TCP. The ability to change 
the addresses used during a TCP session opens up new types of 
vulnerabilities and attacks. These and their mitigations will be 
documented. 

c. A coupled multipath-aware congestion control algorithm. This 
algorithm is the multipath equivalent of SACK/NewReno congestion 
control. As experience is gathered from implementations of various 
congestion control algorithms, it is expected that the working group 
will be rechartered to pursue additional work in these areas. 

d. Extensions to current TCP to support multi-addressed multipath TCP. 
This covers all on-the-wire changes required to create a two-ended 
MPTCP solution using multiple addresses at one or both ends. It will be 
designed in a modular fashion to allow alternative address management 
schemes to be explored in future. This document will also include a 
basic security model.

e. An application considerations document, presenting the impacts that 
MPTCP may have on applications, such as performance changes, and 
including an extended API describing how applications can exploit 
additional features of multipath transport. While MPTCP needs to be 
usable without any application changes, this API should be an optional 
extension that provides access to multipath information and enables 
control over the usage of multipath. 

Where appropriate, this group is expected to coordinate with, and will 
use input from, the MIF working group to support the use of multiple 
interfaces.

Goals and Milestones:

Mar 2010 - Established WG consensus on the Architecture
Aug 2010 - Submit to IESG architectural guidelines and security threat
           analysis as informational RFC(s)
Mar 2011 - Submit to IESG basic coupled congestion control as an 
           experimental RFC
Mar 2011 - Submit to IESG protocol specification for MPTCP extensions 
           as an experimental RFC
Mar 2011 - Submit to IESG application considerations and API as an 
           informational RFC
Mar 2011 - Recharter or close WG
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir

From Nicolas.Williams@sun.com  Wed Sep 30 13:01:10 2009
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184DE3A69DA; Wed, 30 Sep 2009 13:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.872
X-Spam-Level: 
X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAh5m7Bzwphh; Wed, 30 Sep 2009 13:01:09 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id E285F3A69E5; Wed, 30 Sep 2009 13:01:08 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8UK2WVZ002658; Wed, 30 Sep 2009 20:02:32 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8UK2Wtu041009; Wed, 30 Sep 2009 14:02:32 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8UJaLFO002019; Wed, 30 Sep 2009 14:36:21 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8UJaKRQ002018;  Wed, 30 Sep 2009 14:36:20 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 30 Sep 2009 14:36:20 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: iesg@ietf.org, secdir@ietf.org
Message-ID: <20090930193620.GA902@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Cc: Craig Everhart <everhart@netapp.com>, Daniel Ellard <dellard@bbn.com>, nfsv4@ietf.org, Manoj Naik <manoj@almaden.ibm.com>, Renu Tewari <tewarir@us.ibm.com>, James Lentini <jlentini@netapp.com>
Subject: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2009 20:01:10 -0000

I have reviewed this document as part of the security directorate's                                                                 
ongoing effort to review all IETF documents being processed by the                                                                  
IESG.  These comments were written primarily for the benefit of the                                                                 
security area directors.  Document editors and WG chairs should treat                                                               
these comments just like any other last call comments.                                                                              

This document describes the notion of "federated filesystem namespace"
and requirements for specifications of an actual set of federated
filesystem namespace components and even some requirements of actual
implementations.

A federated namespace is one where multiple filesystems (or, rather,
"filesets") are put together into a larger filesystem-like namespace,
but where the various filesystems involved can be owned and administered
by widely varying entities.

Authorization issues arise when filesystems migrate, and these are
neatly resolved in the federated namespace concept by separating the
location of references to filesystems from the location of fileset
location information.  References to filesets ("junctions") live in
actual filesystem (think of a magic symlink or "shortcut").  Fileset
location information lives in a directory whose name is part of the
fileset's name as referenced by any junction that refers to it.

Authorization of junction administration is a matter local to the
filesystems where the junctions live.  Authorization of fileset location
administration is a matter local to the directory where the fileset
location information is published.

There is one more level of separation as well, to allow for filesets
with replicas owned and administered by different entities.  "Fileset
names" (FSNs) refer to directory objects which in turn refer to "fileset
location" objects (FSLs); both, FSNs and FSLs include the name of the
containing directory in their canonical name forms.

The document does not describe the authorization separation involved.
And though it isn't strictly necessary, I believe that it would be
beneficial to have such a description.

The document also does not clearly explain that junctions are not
published in any directory, which confused me greatly at first, as in my
opinion publishing FSN and FSL objects does not make the directories in
which they are published "namespace databases" (NSDBs).  This is not a
security concern, of course.

The document also does not explain that FSNs are intended to be small,
even fixed sized, or with highly compressible variable size portions[*].
But a moment's thought about filesystem designs quickly reveals that
such a requirement is important.  In my opinion such a requirement
should be documented.  This too is not a security concern.

The Security Considerations section is a bit skimpy.  Its claims are
correct in my opinion.  I would, however, add to it the following:

 - A note that the federated namespace concept helps distribute
   responsibility for authorization (a very good thing).

 - A note that orphaned FSNs and FSLs cannot be easily distinguished
   from ones referenced by junctions and FSNs, respectively.  Therefore
   objects will tend to pile up.  This is a resource consumption
   consideration.  Resource control issues are, IMO, a security
   consideration.

Finally, I'm not sure if it's worth saying anything about the fact that
with the NSDB choice being up to the FSN and FSL publishers, there can
be a plethora of NSDBs in a federation, which brings scalability of
distributed authentication and trust into the picture.  For example,
consider an NSDB that uses TLS and a self-signed server certificate to
authenticate itself, then a fingerprint of the certificate will have to
be part and parcel of the FSN/FSL names stored by junctions/FSNs
(respectively).  A PKI would help, of course, but in a sufficiently
large federation it may be necessary to have multiple trust anchors,
rather than a single PKI root, which brings TA administration issues
into the picture.  This is really nothing new, and so perhaps not worth
noting, but the potential for having to store, and the consequences
thereof, FSN NSDB authentication information in junctions, and FSL NSDB
authentication information in FSNs, does seem to me to be worth noting.

[*] For example, assuming many FSNs but relatively few NSDBs, filesystem
    implementors could choose store FSNs as {reference to NSDB name, FSN
    object name relative to NSDB}.  If the second item of the tuple is
    itself fixed-sized then the whole tuple can be fixed sized.  A table
    of {NSDB name, reference} would be needed too, but it may be
    critical to keep "inodes" fixed-sized, with little wastage, in which
    case "interning" NSDB names as described above is a sufficient
    compression technique.

    In fact, draft-ietf-nfsv4-federated-fs-protocol-03 does use UUIDs
    for naming FSNs and FSLs, so that the above technique is certainly a
    feasible way to keep inodes fixed-sized in spite of the fact that
    FSNs are actually variable sized (the NSDB name where the FSN
    resides is part of the FSN's name).

Nico
-- 

From Nicolas.Williams@sun.com  Wed Sep 30 15:54:16 2009
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B093A68F9; Wed, 30 Sep 2009 15:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.873
X-Spam-Level: 
X-Spam-Status: No, score=-5.873 tagged_above=-999 required=5 tests=[AWL=0.173,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKsRioGNJU55; Wed, 30 Sep 2009 15:54:16 -0700 (PDT)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id A662B3A6781; Wed, 30 Sep 2009 15:54:15 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8UMtdoJ023065; Wed, 30 Sep 2009 22:55:39 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8UMtdP4020679; Wed, 30 Sep 2009 16:55:39 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8UMawlh002084; Wed, 30 Sep 2009 17:36:58 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8UMawuH002083;  Wed, 30 Sep 2009 17:36:58 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 30 Sep 2009 17:36:57 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: James Lentini <jlentini@netapp.com>
Message-ID: <20090930223657.GP887@Sun.COM>
References: <20090930193620.GA902@Sun.COM> <alpine.LFD.2.00.0909301707010.3163@jlentini-linux.nane.netapp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.00.0909301707010.3163@jlentini-linux.nane.netapp.com>
User-Agent: Mutt/1.5.7i
Cc: Daniel Ellard <dellard@bbn.com>, iesg@ietf.org, Renu Tewari <tewarir@us.ibm.com>, nfsv4@ietf.org, secdir@ietf.org
Subject: Re: [secdir] [nfsv4] draft-ietf-nfsv4-federated-fs-reqts-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2009 22:54:16 -0000

On Wed, Sep 30, 2009 at 06:17:31PM -0400, James Lentini wrote:
> Thank you for your feedback. We will update the document to include 
> the improvements you have suggested both to the security 
> considerations (noting the authorization separation inherent in the 
> design, the resource consumption considerations for NSDB objects, and 
> the implications regarding NSDB authentication) and general 
> description (regarding the absence of junctions in the NSDB and the 
> benefits of using fixed size FSNs).

You're welcome, and thanks for making those changes.

Don't forget to add an explicit requirement for small/compressible FSNs.
It helps the reader of draft-ietf-nfsv4-federated-fs-protocol understand
the choice of UUIDs for fileset naming.

Nico
-- 

From jhutz@cmu.edu  Wed Sep 30 19:30:07 2009
Return-Path: <jhutz@cmu.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231423A69A3; Wed, 30 Sep 2009 19:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.975
X-Spam-Level: 
X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nb-eTMfLu5UT; Wed, 30 Sep 2009 19:30:05 -0700 (PDT)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id AC08F3A6802; Wed, 30 Sep 2009 19:30:05 -0700 (PDT)
Received: from [10.0.0.3] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n912VBp3028965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Sep 2009 22:31:12 -0400 (EDT)
Date: Wed, 30 Sep 2009 22:31:11 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@sun.com>, iesg@ietf.org, secdir@ietf.org
Message-ID: <65075E890F4E784CD4416173@atlantis.pc.cs.cmu.edu>
In-Reply-To: <1372_1254340959_n8UK2bOg025386_20090930193620.GA902@Sun.COM>
References: <1372_1254340959_n8UK2bOg025386_20090930193620.GA902@Sun.COM>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.196
Cc: Craig Everhart <everhart@netapp.com>, Daniel Ellard <dellard@bbn.com>, nfsv4@ietf.org, Manoj Naik <manoj@almaden.ibm.com>, Renu Tewari <tewarir@us.ibm.com>, James Lentini <jlentini@netapp.com>
Subject: Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2009 02:30:07 -0000

--On Wednesday, September 30, 2009 02:36:20 PM -0500 Nicolas Williams 
<Nicolas.Williams@sun.com> wrote:

>  - A note that orphaned FSNs and FSLs cannot be easily distinguished
>    from ones referenced by junctions and FSNs, respectively.  Therefore
>    objects will tend to pile up.  This is a resource consumption
>    consideration.  Resource control issues are, IMO, a security
>    consideration.

I don't think this is a significant problem, or a security problem at all. 
The fact that, once I have allocated my resources for an object, you might 
decide to stop having any references to it, does not create a security 
problem for me.  This is analogous to my publishing a web page, and then 
you later deciding not to link to it any more.

I've lacked the time to pay any more than fleeting attention to the NFSv4 
work, but not surprisingly, the concepts mentioned here have analogues in 
AFS.  What NFS calls a "fileset" we call a "volume".  Volumes have names, 
and each AFS "cell" (collection of servers and volumes under common 
administrative control) has a database which maps volume names to 
locations.  What NFS calls a "junction" we call a "mount point", which is a 
special object in the filesystem which refers to another volume, possibly 
in another cell.

My observation over the years has been while it is possible to create mount 
points anywhere in the filesystem, referring to any volume in any cell, it 
is relatively uncommon to do so.  Most sites apply some structure to their 
filesystem namespace, such that a volume used for a particular purpose will 
have a fairly predictable name, and be referred to by a "canonical" mount 
point in a fairly predictable location.  Volume and mount point are 
typically created at the same time by the same administrator (or, more 
likely, by a set of tools designed to automate this process), and are also 
removed at the same time when no longer needed.  Others may create 
additional mount points, but this is fairly uncommon and most sites make 
few or no provision for keeping track of them.

In AFS, cross-cell mount points are even less common; the most common usage 
involves a single mount point to a canonical volume in each foreign cell 
(by convention, named "root.cell"), with other cross-cell mount points 
being extremely rare in most deployments.  I suspect actual deployment of 
NFSv4 will be somewhat different in this respect, but one aspect I would 
expect to remain similar is that the looser the organizational relationship 
between the location of a junction and that of its target, the more likely 
the target will be one of a small number of well-publicized entry points.


The upshot is that this model is unlikely to create the sort of problems 
you imagine, because in practice there will always be at least one 
"canonical" junction leading (eventually) to any given fileset.  Note that 
this point also extends to the intermediate objects, but more so; I'd 
expect management of FSN's and FSL's in practice to be fairly closely tied 
to management of the filesets themselves.

-- Jeff