From vishwas.ietf@gmail.com Mon Jun 3 08:45:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2311E80DE for ; Mon, 3 Jun 2013 08:45:12 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxq6LoV1uSRJ for ; Mon, 3 Jun 2013 08:45:11 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D7D0911E80D5 for ; Mon, 3 Jun 2013 08:45:10 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id tp5so10547247ieb.6 for ; Mon, 03 Jun 2013 08:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6wHuJnpX2MYVnH2PasTMRx/rd0qnys/+Tnheq3X2OP0=; b=QxdUDXrt5rmP1qtDVz9ymY0fRDuPRuN3QXkchC4S4kzrRTsFd/UnX2pKkuIp4x94Q/ PF/SfEN8uL98LDv8Wi74s0SuYG2STq4VvM/Kh93XRWcLEcZpQ0k8emADyoEMp4wilosD /RQjauinzcGIN0yurEIGip9wpdBP9dszZVugu2HBthxwm//HFVsvkE/QiF9x6Jv3VsnE ZFXeW5L0YuUMPGj3GoCx17Prz5ZINyR1FVpkwFg2x3NfKhOEwZpvCeWhRrTyu6wNjdDH Xx1D2w9pbQKCD1iJQS1ze17Z8joHJeWUSi3cF5ziABAOuneVFDgT36kLNLOEQSfh2bcC REOw== MIME-Version: 1.0 X-Received: by 10.42.250.202 with SMTP id mp10mr10721216icb.21.1370274310435; Mon, 03 Jun 2013 08:45:10 -0700 (PDT) Received: by 10.50.56.107 with HTTP; Mon, 3 Jun 2013 08:45:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Jun 2013 08:45:10 -0700 Message-ID: From: Vishwas Manral To: Praveen Sathyanarayan Content-Type: multipart/alternative; boundary=20cf3010e6c984ced404de41d97d Cc: IPsecme WG , "maoyu@h3c.com" , Yoav Nir , Paul Hoffman , Toby Mao Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 15:45:12 -0000 --20cf3010e6c984ced404de41d97d Content-Type: text/plain; charset=ISO-8859-1 Hi Praveen, I think the idea is to be able to have QoS in a way that the traffic from one spoke cannot overwhelm the Hub and lead to issues there. We need to maintain QoS policies per spoke (or spoke type) on the Hub, as well as to be able to push some QoS policies to the spokes from the Hub. Do I make sense? Thanks, Vishwas On Mon, May 6, 2013 at 9:30 AM, Praveen Sathyanarayan wrote: > Hi Toby, > > When you say QoS policy, could you elaborate what it really means? I > mean what kind of information does it need to have or exchanged? > > -- Praveen > > From: Toby Mao > Date: Sunday, May 5, 2013 8:49 AM > To: Yoav Nir > Cc: IPsecme WG , "maoyu@h3c.com" , Paul > Hoffman > Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: > draft-ietf-ipsecme-ad-vpn-problem-06.txt > > Hi Yoav. > > The QoS implementations in ADVPN are : > > 1. In the star topology, the QoS policy is implemented > individually for each spoke in the hub, all the traffic through the Hub can > be regulated by QoS policy in the hub. > > 2. In the full mesh topology, when the two spokes establish the > direct connection, each spoke should also have the QoS policy for each > other. The QoS policy can be obtained from the Hub, or other control device > , which has the individual QoS policy for each spoke. > > I think your understanding is the same as the QoS implementation in the > full mesh topology. > > Toby > > > On Fri, May 3, 2013 at 4:11 AM, Yoav Nir wrote: > >> Hi Toby. >> >> Let's see if I understand the issue. I'll describe this with an >> example. Please let me know if I got it. >> >> Suppose we have satellite gateways A, B, C, D, and E. A through D each >> have a bandwidth of 10 Mb/s, while E has 20 Mb/s. >> >> The center gateway, Z, has plenty of bandwidth and the appropriate QoS >> policy. So if A, B, and C are simultaneously sending traffic to E through >> Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP >> ACKs) to make sure the QoS goals are met. >> >> Now add ADVPN to the mix. A and E discover each other, and are able to >> bypass Z. Initially A had no IPsec policy about E. There's no reason to >> think it had a QoS policy about E, and the same is true in the other >> direction. Unless the QoS policy from Z somehow gets transmitted to the >> satellites, they may reach congestion and have the QoS targets miss. >> >> So whereas before ADVPN the center gateway could be counted on to >> handle the QoS (because everything goes through it), as soon as you add >> ADVPN, that policy has to be enforced on the spokes, or not at all. >> >> I'm not sure whether we can or should solve this issue as part of >> AD-VPN, but I want to make sure that we understand the issue. >> >> Yoav >> >> On May 2, 2013, at 6:02 PM, Toby Mao wrote: >> >> >> On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman wrote: >> >>> These requirements might be useful to add in the next draft, but they >>> need to be refined. >>> >>> On Apr 26, 2013, at 8:10 PM, Toby Mao wrote: >>> >>> > The ADVPN solution SHOULD be able to implement Quality of Service >>> (QoS) to regulate the traffic in the ADVPN topology. >>> >>> Why is this statement needed? Do you see situations where an ADVPN >>> solution would be *prevented* from implementing some sort of QoS because it >>> was an ADVPN? >>> >> >> [Toby]: There is no situation that ADVPN solution could be prevented >> from implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing >> network bandwidth, meeting the application latency requirement. Especially >> in the Hub, for each spoke, the Qos policy should be implemented >> individually , because different spoke has different link speed and data >> processing capability. Thus, in the ADVPN solution, the small spoke can not >> be overrun by hub by sending too much traffic, also the spoke which has >> large bandwidth cannot hog the hub's resources and starve other spokes. In >> addition, a unique Qos policy for each spoke in the hub could be cumbersome >> for administrator, some improvement could be implemented, such as the >> spokes with the same bandwidth can belong to the same group, the Qos policy >> can be implemented on a basis of group. >> >>> >>> > ADVPN peer SHOULD NOT send excessive traffic to the other members of >>> ADVPN. >>> >>> How would you define "excessive"? Where would that measurement be done? >> >> >> [Toby] The traffic to the ADVPN peer exceeding the actual peer bandwidth >> can be defined as "excessive". To solve this problem, the other ADVPN peer >> should apply Qos policy for this ADVPN peer. >> >> > The traffic for each ADVPN peer CAN be measured individually for >>> shaping and policing. >>> >>> Why is this statement needed? Do you see situations where an ADVPN >>> solution would be *prevented* from measuring individually? >> >> >> [Toby] The reason is explained in the first answer. >> >>> >>> --Paul Hoffman >> >> >> >> >> Email secured by Check Point >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --20cf3010e6c984ced404de41d97d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Praveen,
=A0
I think the idea = is to be able to have QoS in a way that the traffic from one spoke cannot o= verwhelm the Hub and lead to issues there. We need to maintain QoS policies= per spoke (or spoke type)=A0on the Hub, as well as to be able to push some= QoS policies to the spokes from the Hub.
=A0
Do I make sense?
=A0
Thanks,
Vishwas


On Mon, May 6, 2013 at 9:30 AM, Praveen Sathyanarayan <pravee= nys@juniper.net> wrote:
Hi Toby,

When you say QoS policy, could you elaborate what it really means? I m= ean what kind of information does it need to have or exchanged?=A0

-- Praveen

From: Toby Mao <yumao9@gmail.com>
Date: Sunday, May 5, 2013 8:49 AM To: Yoav Nir <ynir@checkpoint.com>
Cc: IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3c.com>, Paul= Hoffman <pau= l.hoffman@vpnc.org>
Subject: Re: [IPsec] One comment to= this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

Hi Yoav.

=A0=A0=A0=A0=A0=A0=A0 =A0The QoS implementatio= ns in ADVPN are :

= 1.=A0=A0=A0=A0=A0=A0=A0=A0In the star topology, =A0the QoS policy is implemented individually for each spoke in the hub, all the traffic through the Hub ca= n be regulated by QoS policy in the hub.

= 2.=A0=A0=A0=A0=A0=A0=A0In the full mesh topology,=A0 when the two spokes establish the direct connection, each spoke should also have the QoS policy for each= other. The QoS policy can be obtained from the Hub, or other control devic= e , =A0which has the individual QoS policy for each spoke.

I think your understanding is= the same as the QoS implementation in the full mesh topology.

Toby<= /p>



On Fri, May 3, 2013 at 4:11 AM, Yoav Nir <ynir@checkpoin= t.com> wrote:
Hi Toby.

Let's see if I understand the issue. I'll describe this with a= n example. Please let me know if I got it.

Suppose we have satellite gateways A, B, C, D, and E. A through D each= have a bandwidth of 10 Mb/s, while E has 20 Mb/s.

The center gateway, Z, has plenty of bandwidth and the appropriate QoS= policy. So if A, B, and C are simultaneously sending traffic to E through = Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP A= CKs) to make sure the QoS goals are met.

Now add ADVPN to the mix. A and E discover each other, and are able to= bypass Z. Initially A had no IPsec policy about E. There's no reason t= o think it had a QoS policy about E, and the same is true in the other dire= ction. Unless the QoS policy from Z somehow gets transmitted to the satellites, they may reach congestion and = have the QoS targets miss.=A0

So whereas before ADVPN the center gateway could be counted on to hand= le the QoS (because everything goes through it), as soon as you add ADVPN, = that policy has to be enforced on the spokes, or not at all.

I'm not sure whether we can or should solve this issue as part of = AD-VPN, but I want to make sure that we understand the issue.

Yoav
=A0
On May 2, 2013, at 6:02 PM, Toby Mao <yumao9@gmail.com> wrote:


On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <= span dir=3D"ltr"> <paul.hoffman= @vpnc.org> wrote:
These requirements might be useful to add in the next draft, but they need = to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN?

=A0[Toby]:=A0There is no situation that ADVPN solution could be prevented from implem= enting Qos. Actually, Qos is crucial on ADVPN, such as sharing network band= width, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy should = be implemented individually , because different spoke has different link sp= eed and data processing capability. Thus, in the ADVPN solution, the small = spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwidth cann= ot hog the hub's resources and starve other spokes. In addition, a uniq= ue Qos policy for each spoke in the hub could be cumbersome for administrat= or, some improvement could be implemented, such as the spokes with the same bandwidth can belong to the same group, t= he Qos policy can be implemented on a basis of group.

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurement be= done?
=A0
[Toby] =A0= The traffic to the ADVPN peer exceeding the actual peer bandwidth can be de= fined as "excessive". To solve this problem, the other ADVPN peer= should apply Qos policy for this ADVPN peer.=A0

> The traffic for each ADVPN peer CAN be measured individually for = shaping and policing.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually?
=A0
[Toby] =A0= The reason is explained in the first answer.=A0

--Paul Hoffman



Email secured by Check Point

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


--20cf3010e6c984ced404de41d97d-- From vishwas.ietf@gmail.com Mon Jun 3 08:56:49 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C9A21F9798 for ; Mon, 3 Jun 2013 08:56:49 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fB8MQkTkufs for ; Mon, 3 Jun 2013 08:56:48 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3D69D21F973A for ; Mon, 3 Jun 2013 08:56:48 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id at20so10366627iec.7 for ; Mon, 03 Jun 2013 08:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q+ubG1n1U1LasWtaCC5gMx0NQFCMf2WnVZujv+JwICA=; b=C+hvVjmbHHSKnHk5MeZB/pX1TYMiNIlx1empX+m8yKWmhiSiScxVqtSbpsj7GBoCFn u+r3LMhXOQcxkwRLANIzT8hb+Ejc6HuYczHeS6PaC2mxldPZYI+PlkLkuEVniJ6csk+C R6eidHNitwY4+9+ryO31Bif902gvHQTX4foPns/QlGGmHBj+sV1KS9wAmthYQ3OON0Lh xuE7e4yQibpIoU6ufZe3OPmE6TQTB9QyQIAH+Dhn4N/KiLh1BAvOYoQ4lBxm5k7LDmaQ FAqBiADtF5lBk7TyPXUCikMR/FmRKZOqSGwR1mWAh9RFgmxKpjrnX5htLifwOKZKKG49 iCgg== MIME-Version: 1.0 X-Received: by 10.50.78.129 with SMTP id b1mr8412102igx.59.1370275007872; Mon, 03 Jun 2013 08:56:47 -0700 (PDT) Received: by 10.50.56.107 with HTTP; Mon, 3 Jun 2013 08:56:47 -0700 (PDT) In-Reply-To: <33E02A33-0EA1-4D48-BCA4-F436C6023423@checkpoint.com> References: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> <33E02A33-0EA1-4D48-BCA4-F436C6023423@checkpoint.com> Date: Mon, 3 Jun 2013 08:56:47 -0700 Message-ID: From: Vishwas Manral To: Yoav Nir Content-Type: multipart/alternative; boundary=089e0111e07016ca1904de4203b1 Cc: IPsecme WG , "maoyu@h3c.com" , Paul Hoffman , Toby Mao Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 15:56:49 -0000 --089e0111e07016ca1904de4203b1 Content-Type: text/plain; charset=ISO-8859-1 Hi Yoav, Do we see a conclusion on the QoS requirement and if we want to include it as part of the ADVPN solution or keep it seperate? Thanks, Vishwas On Thu, May 2, 2013 at 1:11 PM, Yoav Nir wrote: > Hi Toby. > > Let's see if I understand the issue. I'll describe this with an example. > Please let me know if I got it. > > Suppose we have satellite gateways A, B, C, D, and E. A through D each > have a bandwidth of 10 Mb/s, while E has 20 Mb/s. > > The center gateway, Z, has plenty of bandwidth and the appropriate QoS > policy. So if A, B, and C are simultaneously sending traffic to E through > Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP > ACKs) to make sure the QoS goals are met. > > Now add ADVPN to the mix. A and E discover each other, and are able to > bypass Z. Initially A had no IPsec policy about E. There's no reason to > think it had a QoS policy about E, and the same is true in the other > direction. Unless the QoS policy from Z somehow gets transmitted to the > satellites, they may reach congestion and have the QoS targets miss. > > So whereas before ADVPN the center gateway could be counted on to handle > the QoS (because everything goes through it), as soon as you add ADVPN, > that policy has to be enforced on the spokes, or not at all. > > I'm not sure whether we can or should solve this issue as part of > AD-VPN, but I want to make sure that we understand the issue. > > Yoav > > On May 2, 2013, at 6:02 PM, Toby Mao wrote: > > > On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman wrote: > >> These requirements might be useful to add in the next draft, but they >> need to be refined. >> >> On Apr 26, 2013, at 8:10 PM, Toby Mao wrote: >> >> > The ADVPN solution SHOULD be able to implement Quality of Service (QoS) >> to regulate the traffic in the ADVPN topology. >> >> Why is this statement needed? Do you see situations where an ADVPN >> solution would be *prevented* from implementing some sort of QoS because it >> was an ADVPN? >> > > [Toby]: There is no situation that ADVPN solution could be prevented > from implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing > network bandwidth, meeting the application latency requirement. Especially > in the Hub, for each spoke, the Qos policy should be implemented > individually , because different spoke has different link speed and data > processing capability. Thus, in the ADVPN solution, the small spoke can not > be overrun by hub by sending too much traffic, also the spoke which has > large bandwidth cannot hog the hub's resources and starve other spokes. In > addition, a unique Qos policy for each spoke in the hub could be cumbersome > for administrator, some improvement could be implemented, such as the > spokes with the same bandwidth can belong to the same group, the Qos policy > can be implemented on a basis of group. > >> >> > ADVPN peer SHOULD NOT send excessive traffic to the other members of >> ADVPN. >> >> How would you define "excessive"? Where would that measurement be done? > > > [Toby] The traffic to the ADVPN peer exceeding the actual peer bandwidth > can be defined as "excessive". To solve this problem, the other ADVPN peer > should apply Qos policy for this ADVPN peer. > > > The traffic for each ADVPN peer CAN be measured individually for >> shaping and policing. >> >> Why is this statement needed? Do you see situations where an ADVPN >> solution would be *prevented* from measuring individually? > > > [Toby] The reason is explained in the first answer. > >> >> --Paul Hoffman > > > > > Email secured by Check Point > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --089e0111e07016ca1904de4203b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Yoav,
=A0
Do we see a conclusi= on on the QoS requirement and if we want to include it as part of the ADVPN= solution or keep it seperate?
=A0
Thanks,
Vi= shwas


On Thu,= May 2, 2013 at 1:11 PM, Yoav Nir <ynir@checkpoint.com> wr= ote:
Hi Toby.

Let's see if I understand the issue. I'll describe this with a= n example. Please let me know if I got it.

Suppose we have satellite gateways A, B, C, D, and E. A through D each= have a bandwidth of 10 Mb/s, while E has 20 Mb/s.

The center gateway, Z, has plenty of bandwidth and the appropriate QoS= policy. So if A, B, and C are simultaneously sending traffic to E through = Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP A= CKs) to make sure the QoS goals are met.

Now add ADVPN to the mix. A and E discover each other, and are able to= bypass Z. Initially A had no IPsec policy about E. There's no reason t= o think it had a QoS policy about E, and the same is true in the other dire= ction. Unless the QoS policy from Z somehow gets transmitted to the satellites, they may reach congestion and = have the QoS targets miss.=A0

So whereas before ADVPN the center gateway could be counted on to hand= le the QoS (because everything goes through it), as soon as you add ADVPN, = that policy has to be enforced on the spokes, or not at all.

I'm not sure whether we can or should solve this issue as part of = AD-VPN, but I want to make sure that we understand the issue.

Yoav
=A0
On May 2, 2013, at 6:02 PM, Toby Mao <yumao9@gmail.com> wrote:


On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <= span dir=3D"ltr"> <paul.hoffman= @vpnc.org> wrote:
These requirements might be useful to add in the next draft, but they need = to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN?

=A0[Toby]:=A0There is no situation that ADVPN solution could be prevented from implem= enting Qos. Actually, Qos is crucial on ADVPN, such as sharing network band= width, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy= should be implemented individually , because different spoke has different= link speed and data processing capability. Thus, in the ADVPN solution, th= e small spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwid= th cannot hog the hub's resources and starve other spokes. In addition,= a unique Qos policy for each spoke in the hub could be cumbersome for admi= nistrator, some improvement could be implemented, such as the spokes with the same bandwidth can belong to the = same group, the Qos policy can be implemented on a basis of group.

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurement be= done?
=A0
[Toby] =A0= The traffic to the ADVPN peer exceeding the actual peer bandwidth can be de= fined as "excessive". To solve this problem, the other ADVPN peer= should apply Qos policy for this ADVPN peer.=A0

> The traffic for each ADVPN peer CAN be measured individually for = shaping and policing.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually?
=A0
[Toby] =A0= The reason is explained in the first answer.=A0

--Paul Hoffman



Email secured by Check Point

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


--089e0111e07016ca1904de4203b1-- From vishwas.ietf@gmail.com Mon Jun 3 10:02:46 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992A421F8FAF for ; Mon, 3 Jun 2013 10:02: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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VX4KLI6kzQq for ; Mon, 3 Jun 2013 10:02:46 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D128F21F8F0E for ; Mon, 3 Jun 2013 10:02:45 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 17so11298150iea.31 for ; Mon, 03 Jun 2013 10:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LvSxqD0pnkIff7Wzvze/GuNoyMINReYq1WDP2VvMxIU=; b=FsQkfKpCR2wo6t0QLPTygmmGMNNb3GIGsfsOQfgrkUeT6ksAecb2QA5Fnn5TTInbl3 fbuizN0cC2ju1V9vGh3LXpFcBArSQXg2tXEimtjcvwumc+5wypNcjNSEtvS6NY3p1/5N xm3BW+td/4lSTj0MYGtaYHSSFvrLa9Bxz0tfURYHrWLnLnU5qfDGtJbUM4KXQhxcc/RN 9vI4q0k9+4B+PsrVvMGsaji+uDLiNeQAQcPgrK7prazTGjCz4+fCWh3AB6rjn2eM+yIm IiEcKBwulR5oe2piKpx6n492qtaC/3mVRpaMJlv9LJ+bBNW+26VXv1VGpSgizd2EwBX9 Kb/g== MIME-Version: 1.0 X-Received: by 10.42.191.82 with SMTP id dl18mr6156487icb.9.1370278965443; Mon, 03 Jun 2013 10:02:45 -0700 (PDT) Received: by 10.50.56.107 with HTTP; Mon, 3 Jun 2013 10:02:45 -0700 (PDT) Date: Mon, 3 Jun 2013 10:02:45 -0700 Message-ID: From: Vishwas Manral To: Sean Turner , IPsecme WG , "draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org" Content-Type: multipart/alternative; boundary=20cf3043496efa84fd04de42ee9d Subject: Re: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:02:46 -0000 --20cf3043496efa84fd04de42ee9d Content-Type: text/plain; charset=ISO-8859-1 Hi Sean, My comments are inline: Please incorporate the QoS issue brought up by Toby. I'd like to make sure we have everything in the draft that the WG wants before issuing the WGLC. I also think the TSV/RTG directorates/ADs will be interested in that. VM> I can incorporate it if the Working Group thinks the QoS parts should be part of the aDVPN solution. Can you explain the rationale for the following the changes to requirement #5; I'm just not following it: OLD: 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN peer. NEW: 5. Any of the ADVPN Peers MUST NOT have a way to get the long term authentication credentials for any other ADVPN Peers. The compromise of an Endpoint MUST NOT affect the security of communications between other ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the security of the communications between ADVPN Peers not associated with that Gateway. Is the first sentence still saying basically: "peers can't impersonate peers"? VM> Yes thats the idea in my view. Steve Hanna may have more omments on this. Steve? Nits: - sec 1.1: Need to add what an ADVPN is and expand the acronym VM> Should something like the below suffice: VM> ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN solution that enables a large number of systems to communicate directly, with minimal configuration and operator intervention using IPsec to protect communication between them. - sec 4/1.1: The terms allied and federated environment kind of come out of nowhere. Please add them to s1.1. I just to make sure it's clear what the difference is between the two. VM> Here is what I will add to 1.1. VM> Allied and Federated Environments - Environments where we have multiple different organizations that have close association and need to connect to each other. --20cf3043496efa84fd04de42ee9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sean,
=A0
My comments are inli= ne:

=A0

Please incorporate the QoS issue brought up = by Toby.=A0 I'd like to make

sure we have everything in the draft that the = WG wants before issuing

the WGLC.=A0 I also think the TSV/RTG directorates/ADs will be interested =

in that.

VM> I can incorporate it if the Working Group thinks th= e QoS parts should be part of the aDVPN solution.

=A0

Can you explain the rationale for the followin= g the changes to

requirement #5; I'm just not following it:=

=A0

OLD:

=A0

5. One ADVPN peer MUST NOT be able to impers= onate another ADVPN=A0=A0 peer.

=A0

NEW:

=A0

5. Any of the ADVPN Peers MUST NOT have a way = to get the long term

authentication credentials for any other ADVPN= Peers. The compromise of

an Endpoint MUST NOT affect the security of communications between other

ADVPN Peers. The compromise of a Gateway SHOUL= D NOT affect the security

of the communications between ADVPN Peers not = associated with that Gateway.

=A0

Is the first sentence still saying basically: = "peers can't impersonate

peers"?

=A0

VM> Yes t= hats the idea in my view. Steve Hanna may have more omments on this. Steve?=

=A0

Nits:

=A0

- sec 1.1: Need to add what an ADVPN is and ex= pand the acronym

VM>=A0Should something like the b= elow suffice:

=A0

VM> ADVPN - Auto Discovery Virtual Private Network (ADVPN) = is VPN solution that enables a large number of systems to communicate direc= tly, with minimal configuration and operator intervention=A0using IPsec to = protect communication between them.

=A0

- sec 4/1.1: The terms allied and federated en= vironment kind of come out

of nowhere.=A0 Please add them to s1.1.=A0 I just to make sure it's clear

what the difference is between the two.=

VM> Here is what I will add to 1= .1.

=A0

VM&= gt; Allied and Federated Environments - Environments where we=A0have multip= le different organizations that have close association and need to connect = to each other.

--20cf3043496efa84fd04de42ee9d-- From turners@ieca.com Mon Jun 3 10:28:25 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D1121F8FEB for ; Mon, 3 Jun 2013 10:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7mOPBdnNuGG for ; Mon, 3 Jun 2013 10:28:10 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.62.19]) by ietfa.amsl.com (Postfix) with ESMTP id BDD9221F8F0E for ; Mon, 3 Jun 2013 10:24:05 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 4F1FED954A07; Mon, 3 Jun 2013 12:24:05 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 4277ED9549CF for ; Mon, 3 Jun 2013 12:24:05 -0500 (CDT) Received: from [173.73.135.101] (port=50011 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UjYUG-00065E-1h; Mon, 03 Jun 2013 12:24:04 -0500 Message-ID: <51ACD133.3040903@ieca.com> Date: Mon, 03 Jun 2013 13:24:03 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vishwas Manral References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:50011 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: IPsecme WG , "draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org" Subject: Re: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:28:25 -0000 On 6/3/13 1:02 PM, Vishwas Manral wrote: > Hi Sean, > My comments are inline: > > Please incorporate the QoS issue brought up by Toby.I'd like to make > > sure we have everything in the draft that the WG wants before issuing > > the WGLC.I also think the TSV/RTG directorates/ADs will be interested > > in that. > > VM> I can incorporate it if the Working Group thinks the QoS parts > should be part of the aDVPN solution. Yeah it wasn't clear to me whether it should be part of the aDVPN solution. Maybe the chairs can chime in on this one. > Can you explain the rationale for the following the changes to > > requirement #5; I'm just not following it: > > OLD: > > 5. One ADVPN peer MUST NOT be able to impersonate another ADVPNpeer. > > NEW: > > 5. Any of the ADVPN Peers MUST NOT have a way to get the long term > > authentication credentials for any other ADVPN Peers. The compromise of > > an Endpoint MUST NOT affect the security of communications between other > > ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the security > > of the communications between ADVPN Peers not associated with that Gateway. > > Is the first sentence still saying basically: "peers can't impersonate > > peers"? > > VM> Yes thats the idea in my view. Steve Hanna may have more omments on > this. Steve? Okay I guess that makes sense it just seems a little wordy but not worth holding the draft up for. > Nits: > > - sec 1.1: Need to add what an ADVPN is and expand the acronym > > VM> Should something like the below suffice: > > VM> ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN > solution that enables a large number of systems to communicate directly, > with minimal configuration and operator intervention using IPsec to > protect communication between them. yes > - sec 4/1.1: The terms allied and federated environment kind of come out > > of nowhere.Please add them to s1.1.I just to make sure it's clear > > what the difference is between the two. > > VM> Here is what I will add to 1.1. > > VM> Allied and Federated Environments - Environments where we have > multiple different organizations that have close association and need to > connect to each other. that'll work. From vishwas.ietf@gmail.com Mon Jun 3 10:33:31 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F41121F91A3 for ; Mon, 3 Jun 2013 10:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B31UINa8k8Yu for ; Mon, 3 Jun 2013 10:33:20 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 89A6021F8F41 for ; Mon, 3 Jun 2013 10:29:24 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id b11so11141304iee.39 for ; Mon, 03 Jun 2013 10:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y8WPQHvzrEsJXmokO+aBRb4c1O6yUKqutLfc+WBWP3Y=; b=C5VG2UTiFRiCJJmHMSkQTnyhntWxb4AM4wJsT/PmyaBiF2oe6pDb3mzBJXijvfIku+ l8Jx6KJbxZyMf3l9GtPZ2DEgO3H02YAATfirDgUm0xFhF2lBKWfTmPIps9Yogvy5mWRo ui917KEfSe+CH3EZcwE6iF/j3nHspar0MXeJ5F6c5f1BhprcXiat6SFpa1JHyASOVUHn Fpbdy488WnCtrIyu7NgOnrappLC74fM18P3h8vsclvh1tLGSA9bHcu2+ISF4Lk/Gcg5P 9l5ZcJbtSmEuaZA56dvjyX/FzTBgnQoYgvNU40VZG1j1fdahrj55fWSY/uzvnVGf7ORU bkfw== MIME-Version: 1.0 X-Received: by 10.50.128.44 with SMTP id nl12mr8805995igb.0.1370280564159; Mon, 03 Jun 2013 10:29:24 -0700 (PDT) Received: by 10.50.56.107 with HTTP; Mon, 3 Jun 2013 10:29:24 -0700 (PDT) In-Reply-To: <51ACD133.3040903@ieca.com> References: <51ACD133.3040903@ieca.com> Date: Mon, 3 Jun 2013 10:29:24 -0700 Message-ID: From: Vishwas Manral To: Sean Turner Content-Type: multipart/mixed; boundary=089e013a011c44f97604de434e3d Cc: IPsecme WG , "draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org" Subject: Re: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:33:31 -0000 --089e013a011c44f97604de434e3d Content-Type: multipart/alternative; boundary=089e013a011c44f97404de434e3b --089e013a011c44f97404de434e3b Content-Type: text/plain; charset=ISO-8859-1 Hi Sean, Here is the latest draft with your comments incorporated. WG/ Toby, I have added one last requirement number 15 into the document for QoS. Based on inputs from the WG, we can add/ remove/ or update the requirement. Thanks, Vishwas On Mon, Jun 3, 2013 at 10:24 AM, Sean Turner wrote: > On 6/3/13 1:02 PM, Vishwas Manral wrote: > >> Hi Sean, >> My comments are inline: >> >> Please incorporate the QoS issue brought up by Toby.I'd like to make >> >> >> sure we have everything in the draft that the WG wants before issuing >> >> the WGLC.I also think the TSV/RTG directorates/ADs will be interested >> >> >> in that. >> >> VM> I can incorporate it if the Working Group thinks the QoS parts >> should be part of the aDVPN solution. >> > > Yeah it wasn't clear to me whether it should be part of the aDVPN > solution. Maybe the chairs can chime in on this one. > > > Can you explain the rationale for the following the changes to >> >> requirement #5; I'm just not following it: >> >> OLD: >> >> 5. One ADVPN peer MUST NOT be able to impersonate another ADVPNpeer. >> >> NEW: >> >> 5. Any of the ADVPN Peers MUST NOT have a way to get the long term >> >> authentication credentials for any other ADVPN Peers. The compromise of >> >> an Endpoint MUST NOT affect the security of communications between other >> >> ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the security >> >> of the communications between ADVPN Peers not associated with that >> Gateway. >> >> Is the first sentence still saying basically: "peers can't impersonate >> >> peers"? >> >> VM> Yes thats the idea in my view. Steve Hanna may have more omments on >> this. Steve? >> > > Okay I guess that makes sense it just seems a little wordy but not worth > holding the draft up for. > > > Nits: >> >> - sec 1.1: Need to add what an ADVPN is and expand the acronym >> >> VM> Should something like the below suffice: >> >> VM> ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN >> solution that enables a large number of systems to communicate directly, >> with minimal configuration and operator intervention using IPsec to >> protect communication between them. >> > > yes > > - sec 4/1.1: The terms allied and federated environment kind of come out >> >> of nowhere.Please add them to s1.1.I just to make sure it's clear >> >> >> what the difference is between the two. >> >> VM> Here is what I will add to 1.1. >> >> VM> Allied and Federated Environments - Environments where we have >> multiple different organizations that have close association and need to >> connect to each other. >> > > that'll work. > --089e013a011c44f97404de434e3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sean,
=A0
Here is the latest d= raft with your comments incorporated.
=A0
WG/ Toby,
=A0
I have added one last requirement number 15 into the d= ocument for QoS. Based on inputs from the WG, we can add/ remove/ or update= the requirement.
=A0
Thanks,
Vishwas


On Mon, Jun 3, 2013 at 10:24 AM,= Sean Turner <turners@ieca.com> wrote:
On 6/3/13 1:02 PM, Vishwas= Manral wrote:
Hi Sean,
My comments are inline:

Please incorporate the QoS issue brought up by Toby.I'd like to make

sure we have everything in the draft that the WG wants before issuing

the WGLC.I also think the TSV/RTG directorates/ADs will be interested


in that.

VM> I can incorporate it if the Working Group thinks the QoS parts
should be part of the aDVPN solution.

Yeah it wasn't clear to me whether it should be part of the aDVPN solut= ion. =A0Maybe the chairs can chime in on this one.


Can you explain the rationale for the following the changes to

requirement #5; I'm just not following it:

OLD:

5. One ADVPN peer MUST NOT be able to impersonate another ADVPNpeer.

NEW:

5. Any of the ADVPN Peers MUST NOT have a way to get the long term

authentication credentials for any other ADVPN Peers. The compromise of

an Endpoint MUST NOT affect the security of communications between other
ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the security

of the communications between ADVPN Peers not associated with that Gateway.=

Is the first sentence still saying basically: "peers can't imperso= nate

peers"?

VM> Yes thats the idea in my view. Steve Hanna may have more omments on<= br> this. Steve?

Okay I guess that makes sense it just seems a little wordy but not worth ho= lding the draft up for.


Nits:

- sec 1.1: Need to add what an ADVPN is and expand the acronym

VM> Should something like the below suffice:

VM> ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN
solution that enables a large number of systems to communicate directly, with minimal configuration and operator intervention using IPsec to
protect communication between them.

yes

- sec 4/1.1: The terms allied and federated environment kind of come out
of nowhere.Please add them to s1.1.I just to make sure it's clear


what the difference is between the two.

VM> Here is what I will add to 1.1.

VM> Allied and Federated Environments - Environments where we have
multiple different organizations that have close association and need to connect to each other.

that'll work.

--089e013a011c44f97404de434e3b-- --089e013a011c44f97604de434e3d Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipsecme-ad-vpn-problem-07.txt" Content-Disposition: attachment; filename="draft-ietf-ipsecme-ad-vpn-problem-07.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hhhxl0ar0 DQpJUHNlY01FIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUy4gSGFubmENCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuaXBlcg0KSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVi4gTWFucmFsDQpFeHBp cmVzOiBEZWNlbWJlciAwNSwgMjAxMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSFANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSnVuZSAwMywgMjAxMw0KDQoNCiAgICAgICAgIEF1dG8gRGlzY292ZXJ5 IFZQTiBQcm9ibGVtIFN0YXRlbWVudCBhbmQgUmVxdWlyZW1lbnRzDQogICAgICAgICAgICAgICAg ICBkcmFmdC1pZXRmLWlwc2VjbWUtYWQtdnBuLXByb2JsZW0tMDcNCg0KQWJzdHJhY3QNCg0KICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHByb2JsZW0gb2YgZW5hYmxpbmcgYSBsYXJnZSBu dW1iZXIgb2YNCiAgIHN5c3RlbXMgdG8gY29tbXVuaWNhdGUgZGlyZWN0bHkgdXNpbmcgSVBzZWMg dG8gcHJvdGVjdCB0aGUgdHJhZmZpYw0KICAgYmV0d2VlbiB0aGVtLiAgSXQgdGhlbiBleHBhbmRz IG9uIHRoZSByZXF1aXJlbWVudHMsIGZvciBzdWNoIGENCiAgIHNvbHV0aW9uLg0KDQogICBNYW51 YWwgY29uZmlndXJhdGlvbiBvZiBhbGwgcG9zc2libGUgdHVubmVscyBpcyB0b28gY3VtYmVyc29t ZSBpbg0KICAgbWFueSBzdWNoIGNhc2VzLiAgSW4gb3RoZXIgY2FzZXMgdGhlIElQIGFkZHJlc3Mg b2YgZW5kcG9pbnRzIGNoYW5nZQ0KICAgb3IgdGhlIGVuZHBvaW50cyBtYXkgYmUgYmVoaW5kIE5B VCBnYXRld2F5cywgbWFraW5nIHN0YXRpYw0KICAgY29uZmlndXJhdGlvbiBpbXBvc3NpYmxlLiAg VGhlIEF1dG8gRGlzY292ZXJ5IFZQTiBzb2x1dGlvbiB3aWxsDQogICBhZGRyZXNzIHRoZXNlIHJl cXVpcmVtZW50cy4NCg0KU3RhdHVzIG9mIFRoaXMgTWVtbw0KDQogICBUaGlzIEludGVybmV0LURy YWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNp b25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtp bmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAo SUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUNCiAgIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtDQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Ry YWZ0cy9jdXJyZW50Ly4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQs IHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGlt ZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVu Y2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHBy b2dyZXNzLiINCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBEZWNlbWJl ciAwNSwgMjAxMy4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMpIDIwMTMg SUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRvY3VtZW50 IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQogICBQcm92aXNpb25z IFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzDQogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcv bGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCg0KDQoNCkhhbm5hICYgTWFu cmFsICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAwNSwgMjAxMyAgICAgICAgICAgICAgICBbUGFn ZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0byBEaXNjb3ZlcnkgVlBOICAg ICAgICAgICAgICAgICAgSnVuZSAyMDEzDQoNCg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1 bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBjYXJlZnVsbHksIGFzIHRo ZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAg IHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBk b2N1bWVudCBtdXN0DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25z IGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGluIHRo ZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAg SW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDINCiAgICAgMS4xLiAgVGVybWlub2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgICAxLjIuICBDb252ZW50aW9ucyBVc2VkIGlu IFRoaXMgRG9jdW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0DQogICAyLiAgVXNlIENh c2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDQNCiAgICAgMi4xLiAgRW5kcG9pbnQtdG8tRW5kcG9pbnQgQURWUE4gVXNlIENhc2UgLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAyLjIuICBHYXRld2F5LXRvLUdhdGV3YXkgQURWUE4g VXNlIENhc2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1DQogICAgIDIuMy4gIEVuZHBvaW50 LXRvLUdhdGV3YXkgQURWUE4gVXNlIENhc2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUNCiAg IDMuICBJbmFkZXF1YWN5IG9mIEV4aXN0aW5nIFNvbHV0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgNg0KICAgICAzLjEuICBFeGhhdXN0aXZlIENvbmZpZ3VyYXRpb24gIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2DQogICAgIDMuMi4gIFN0YXIgVG9wb2xvZ3kg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYNCiAgICAgMy4z LiAgUHJvcHJpZXRhcnkgQXBwcm9hY2hlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNw0KICAgNC4gIFJlcXVpcmVtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3DQogICAgIDQuMS4gIEdhdGV3YXkgYW5kIEVuZHBvaW50 IFJlcXVpcmVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcNCiAgIDUuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MA0KICAgNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDExDQogICA3LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTENCiAgIDguICBOb3JtYXRpdmUgUmVm ZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQ0KICAg QXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDExDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgSVBzZWMgW1JGQzQzMDFdIGlz IHVzZWQgaW4gc2V2ZXJhbCBkaWZmZXJlbnQgY2FzZXMsIGluY2x1ZGluZyB0dW5uZWwtDQogICBt b2RlIHNpdGUtdG8tc2l0ZSBWUE5zIGFuZCBSZW1vdGUgQWNjZXNzIFZQTnMuICBIb3N0IHRvIGhv c3QNCiAgIGNvbW11bmljYXRpb24gZW1wbG95aW5nIHRyYW5zcG9ydCBtb2RlIGFsc28gZXhpc3Rz LCBidXQgaXMgZmFyIGxlc3MNCiAgIGNvbW1vbmx5IGRlcGxveWVkLg0KDQogICBUaGUgc3ViamVj dCBvZiB0aGlzIGRvY3VtZW50IGlzIHRoZSBwcm9ibGVtIHByZXNlbnRlZCBieSBsYXJnZSBzY2Fs ZQ0KICAgZGVwbG95bWVudHMgb2YgSVBzZWMgYW5kIHRoZSByZXF1aXJlbWVudHMgb24gYSBzb2x1 dGlvbiB0byBhZGRyZXNzDQogICB0aGUgcHJvYmxlbS4gIFRoZXNlIG1heSBiZSBhIGxhcmdlIGNv bGxlY3Rpb24gb2YgVlBOIGdhdGV3YXlzDQogICBjb25uZWN0aW5nIHZhcmlvdXMgc2l0ZXMsIGEg bGFyZ2UgbnVtYmVyIG9mIHJlbW90ZSBlbmRwb2ludHMNCiAgIGNvbm5lY3RpbmcgdG8gYSBudW1i ZXIgb2YgZ2F0ZXdheXMgb3IgdG8gZWFjaCBvdGhlciwgb3IgYSBtaXggb2YgdGhlDQogICB0d28u ICBUaGUgZ2F0ZXdheXMgYW5kIGVuZHBvaW50cyBtYXkgYmVsb25nIHRvIGEgc2luZ2xlDQogICBh ZG1pbmlzdHJhdGl2ZSBkb21haW4gb3Igc2V2ZXJhbCBkb21haW5zIHdpdGggYSB0cnVzdCByZWxh dGlvbnNoaXAuDQoNCiAgIFNlY3Rpb24gNC40IG9mIFJGQyA0MzAxIGRlc2NyaWJlcyB0aGUgbWFq b3IgSVBzZWMgZGF0YWJhc2VzIG5lZWRlZA0KICAgZm9yIElQc2VjIHByb2Nlc3NpbmcuICBJdCBy ZXF1aXJlcyBhbiBleHRlbnNpdmUgY29uZmlndXJhdGlvbiBmb3INCiAgIGVhY2ggdHVubmVsLCBz byBtYW51YWxseSBjb25maWd1cmluZyBhIHN5c3RlbSBvZiBtYW55IGdhdGV3YXlzIGFuZA0KICAg ZW5kcG9pbnRzIGJlY29tZXMgaW5mZWFzaWJsZSBhbmQgaW5mbGV4aWJsZS4NCg0KDQoNCg0KSGFu bmEgJiBNYW5yYWwgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDA1LCAyMDEzICAgICAgICAgICAg ICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVy eSBWUE4gICAgICAgICAgICAgICAgICBKdW5lIDIwMTMNCg0KDQogICBUaGUgZGlmZmljdWx0eSBp cyB0aGF0IGFsbCB0aGUgY29uZmlndXJhdGlvbiBtZW50aW9uZWQgaW4gUkZDIDQzMDEgaXMNCiAg IG5vdCBzdXBlcmZsdW91cy4gIElLRSBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBrbm93IHRoZSBp ZGVudGl0eSBhbmQNCiAgIGNyZWRlbnRpYWxzIG9mIGFsbCBwb3NzaWJsZSBwZWVyIHN5c3RlbXMs IGFzIHdlbGwgYXMgdGhlIGFkZHJlc3NlcyBvZg0KICAgaG9zdHMgYW5kL29yIG5ldHdvcmtzIGJl aGluZCB0aGVtLiAgQSBzaW1wbGlmaWVkIG1lY2hhbmlzbSBmb3INCiAgIGR5bmFtaWNhbGx5IGVz dGFibGlzaGluZyBwb2ludC10by1wb2ludCB0dW5uZWxzIGlzIG5lZWRlZC4gIFNlY3Rpb24gMg0K ICAgY29udGFpbnMgc2V2ZXJhbCB1c2UgY2FzZXMgdGhhdCBtb3RpdmF0ZSB0aGlzIGVmZm9ydC4N Cg0KMS4xLiAgVGVybWlub2xvZ3kNCg0KICAgQURWUE4gLSBBdXRvIERpc2NvdmVyeSBWaXJ0dWFs IFByaXZhdGUgTmV0d29yayAoQURWUE4pIGlzIFZQTg0KICAgc29sdXRpb24gdGhhdCBlbmFibGVz IGEgbGFyZ2UgbnVtYmVyIG9mIHN5c3RlbXMgdG8gY29tbXVuaWNhdGUNCiAgIGRpcmVjdGx5LCB3 aXRoIG1pbmltYWwgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0b3IgaW50ZXJ2ZW50aW9uIHVzaW5n DQogICBJUHNlYyB0byBwcm90ZWN0IGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGVtLg0KDQogICBF bmRwb2ludCAtIEEgZGV2aWNlIHRoYXQgaW1wbGVtZW50cyBJUHNlYyBmb3IgaXRzIG93biB0cmFm ZmljIGJ1dA0KICAgZG9lcyBub3QgYWN0IGFzIGEgZ2F0ZXdheS4NCg0KICAgR2F0ZXdheSAtIEEg bmV0d29yayBkZXZpY2UgdGhhdCBpbXBsZW1lbnRzIElQc2VjIHRvIHByb3RlY3QgdHJhZmZpYw0K ICAgZmxvd2luZyB0aHJvdWdoIHRoZSBkZXZpY2UuDQoNCiAgIFBvaW50LXRvLVBvaW50IC0gQ29t bXVuaWNhdGlvbiBiZXR3ZWVuIHR3byBwYXJ0aWVzIHdpdGhvdXQgYWN0aXZlDQogICBwYXJ0aWNp cGF0aW9uIChlLmcuICBlbmNyeXB0aW9uIG9yIGRlY3J5cHRpb24pIGJ5IGFueSBvdGhlciBwYXJ0 aWVzLg0KDQogICBIdWIgLSBUaGUgY2VudHJhbCBwb2ludCBpbiBhIHN0YXIgdG9wb2xvZ3kvIGR5 bmFtaWMgZnVsbCBtZXNoDQogICB0b3BvbG9neSwgb3Igb25lIG9mIHRoZSBjZW50cmFsIHBvaW50 cyBpbiB0aGUgZnVsbCBtZXNoIHN0eWxlIFZQTiwNCiAgIGkuZS4gIGdhdGV3YXkgd2hlcmUgbXVs dGlwbGUgb3RoZXIgaHVicyBvciBzcG9rZXMgY29ubmVjdCB0by4gIFRoZQ0KICAgaHVicyB1c3Vh bGx5IGZvcndhcmQgdHJhZmZpYyBjb21pbmcgZnJvbSBlbmNyeXB0ZWQgbGlua3MgdG8gb3RoZXIN CiAgIGVuY3J5cHRlZCBsaW5rcywgaS5lLiAgdGhlcmUgYXJlIG5vIGRldmljZXMgY29ubmVjdGVk IHRvIGl0IGluIGNsZWFyLg0KDQogICBTcG9rZSAtIFRoZSBlbmRwb2ludCBpbiBhIHN0YXIgdG9w b2xvZ3kvIGR5bmFtaWMgZnVsbCBtZXNoIHRvcG9sb2d5LA0KICAgb3IgZ2F0ZXdheSB3aGljaCBm b3J3YXJkcyB0cmFmZmljIGZyb20gbXVsdGlwbGUgY2xlYXJ0ZXh0IGRldmljZXMgdG8NCiAgIG90 aGVyIGh1YnMgb3Igc3Bva2VzLCBhbmQgc29tZSBvZiB0aG9zZSBvdGhlciBkZXZpY2VzIGFyZSBj b25uZWN0ZWQNCiAgIHRvIGl0IGluIGNsZWFyIChpLmUuICBpdCBlbmNyeXB0cyBkYXRhIGNvbWlu ZyBmcm9tIGNsZWFydGV4dCBkZXZpY2VzDQogICBhbmQgZm9yd2FyZHMgaXQgdG8gdGhlIEFEVlBO KS4NCg0KICAgQURWUE4gUGVlciAtIGFueSBtZW1iZXIgb2YgYW4gQURWUE4gaW5jbHVkaW5nIGdh dGV3YXlzLCBlbmRwb2ludHMsDQogICBodWIgb3Igc3Bva2UuDQoNCiAgIFN0YXIgdG9wb2xvZ3kg LSBUaGlzIGlzIHRoZSB0b3BvbG9neSB3aGVyZSB0aGVyZSBpcyBkaXJlY3QNCiAgIGNvbm5lY3Rp dml0eSBvbmx5IGJldHdlZW4gdGhlIGh1YiBhbmQgc3Bva2UgYW5kIGNvbW11bmljYXRpb24gYmV0 d2Vlbg0KICAgdGhlIDIgc3Bva2VzIGhhcHBlbnMgdGhyb3VnaCB0aGUgaHViLg0KDQogICBBbGxp ZWQgYW5kIEZlZGVyYXRlZCBFbnZpcm9ubWVudHMgLSBFbnZpcm9ubWVudHMgd2hlcmUgd2UgaGF2 ZQ0KICAgbXVsdGlwbGUgZGlmZmVyZW50IG9yZ2FuaXphdGlvbnMgdGhhdCBoYXZlIGNsb3NlIGFz c29jaWF0aW9uIGFuZCBuZWVkDQogICB0byBjb25uZWN0IHRvIGVhY2ggb3RoZXIuDQoNCiAgIEZ1 bGwgTWVzaCB0b3BvbG9neSAtIFRoaXMgaXMgdGhlIHRvcG9sb2d5IHdoZXJlIHRoZXJlIGlzIGEg ZGlyZWN0DQogICBjb25uZWN0aXZpdHkgYmV0d2VlbiBldmVyeSBTcG9rZSB0byBldmVyeSBvdGhl ciBTcG9rZSBkaXJlY3RseSwNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAgRXhwaXJlcyBE ZWNlbWJlciAwNSwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgQXV0byBEaXNjb3ZlcnkgVlBOICAgICAgICAgICAgICAgICAgSnVuZSAy MDEzDQoNCg0KICAgd2l0aG91dCB0aGUgdHJhZmZpYyBiZXR3ZWVuIHRoZSBzcG9rZXMgaGF2aW5n IHRvIGJlIHJlZGlyZWN0ZWQNCiAgIHRocm91Z2ggYW4gaW50ZXJtZWRpYXRlIGh1YiBkZXZpY2Uu DQoNCiAgIER5bmFtaWMgRnVsbCBNZXNoIHRvcG9sb2d5IC0gVGhpcyBpcyB0aGUgdG9wb2xvZ3kg d2hlcmUgZGlyZWN0DQogICBjb25uZWN0aW9ucyBleGlzdCBpbiBhIGh1YiBhbmQgc3Bva2UgbWFu bmVyLCBidXQgZHluYW1pYyBjb25uZWN0aW9ucw0KICAgYXJlIGNyZWF0ZWQvIHJlbW92ZWQgYmV0 d2VlbiB0aGUgc3Bva2VzIG9uIGEgbmVlZCBiYXNpcy4NCg0KICAgU2VjdXJpdHkgQXNzb2NpYXRp b24gKFNBKSAtIERlZmluZWQgaW4gW1JGQzQzMDFdLg0KDQoxLjIuICBDb252ZW50aW9ucyBVc2Vk IGluIFRoaXMgRG9jdW1lbnQNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs ICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQg Tk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRv Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0K DQoyLiAgVXNlIENhc2VzDQoNCiAgIFRoaXMgc2VjdGlvbiBwcmVzZW50cyB0aGUga2V5IHVzZSBj YXNlcyBmb3IgbGFyZ2Utc2NhbGUgcG9pbnQtdG8tDQogICBwb2ludCBWUE4uDQoNCiAgIEluIGFs bCBvZiB0aGVzZSB1c2UgY2FzZXMsIHRoZSBwYXJ0aWNpcGFudHMgKGVuZHBvaW50cyBhbmQgZ2F0 ZXdheXMpDQogICBtYXkgYmUgZnJvbSBhIHNpbmdsZSBvcmdhbml6YXRpb24gKGFkbWluaXN0cmF0 aXZlIGRvbWFpbikgb3IgZnJvbQ0KICAgbXVsdGlwbGUgb3JnYW5pemF0aW9ucyB3aXRoIGFuIGVz dGFibGlzaGVkIHRydXN0IHJlbGF0aW9uc2hpcC4gIFdoZW4NCiAgIG11bHRpcGxlIG9yZ2FuaXph dGlvbnMgYXJlIGludm9sdmVkLCBwcm9kdWN0cyBmcm9tIG11bHRpcGxlIHZlbmRvcnMNCiAgIGFy ZSBlbXBsb3llZCBzbyBvcGVuIHN0YW5kYXJkcyBhcmUgbmVlZGVkIHRvIHByb3ZpZGUNCiAgIGlu dGVyb3BlcmFiaWxpdHkuICBFc3RhYmxpc2hpbmcgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBwYXJ0 aWNpcGFudHMNCiAgIHdpdGggbm8gZXN0YWJsaXNoZWQgdHJ1c3QgcmVsYXRpb25zaGlwIGlzIG91 dCBvZiBzY29wZSBmb3IgdGhpcw0KICAgZWZmb3J0Lg0KDQoyLjEuICBFbmRwb2ludC10by1FbmRw b2ludCBBRFZQTiBVc2UgQ2FzZQ0KDQogICBUd28gZW5kcG9pbnRzIHdpc2ggdG8gY29tbXVuaWNh dGUgc2VjdXJlbHkgdmlhIGEgcG9pbnQtdG8tcG9pbnQNCiAgIFNlY3VyaXR5IEFzc29jaWF0aW9u IChTQSkuDQoNCiAgIFRoZSBuZWVkIGZvciBzZWN1cmUgZW5kcG9pbnQgdG8gZW5kcG9pbnQgY29t bXVuaWNhdGlvbnMgaXMgb2Z0ZW4NCiAgIGRyaXZlbiBieSBhIG5lZWQgdG8gZW1wbG95IGhpZ2gt YmFuZHdpZHRoLCBsb3cgbGF0ZW5jeSBsb2NhbA0KICAgY29ubmVjdGl2aXR5IGluc3RlYWQgb2Yg dXNpbmcgc2xvdywgZXhwZW5zaXZlIGxpbmtzIHRvIHJlbW90ZQ0KICAgZ2F0ZXdheXMuICBGb3Ig ZXhhbXBsZSwgdHdvIHVzZXJzIGluIGNsb3NlIHByb3hpbWl0eSBtYXkgd2lzaCB0bw0KICAgcGxh Y2UgYSBkaXJlY3QsIHNlY3VyZSB2aWRlbyBvciB2b2ljZSBjYWxsIHdpdGhvdXQgbmVlZGluZyB0 byBzZW5kDQogICB0aGUgY2FsbCB0aHJvdWdoIHJlbW90ZSBnYXRld2F5cywgd2hpY2ggd291bGQg YWRkIGxhdGVuY3kgdG8gdGhlDQogICBjYWxsLCBjb25zdW1lIHByZWNpb3VzIHJlbW90ZSBiYW5k d2lkdGgsIGFuZCBpbmNyZWFzZSBvdmVyYWxsIGNvc3RzLg0KICAgU3VjaCBhIHVzZSBjYXNlIGFs c28gZW5hYmxlcyBjb25uZWN0aXZpdHkgd2hlbiBib3RoIGJlaGluZCBOQVQNCiAgIGdhdGV3YXlz LiAgU3VjaCBhIHVzZSBjYXNlIG91Z2h0IHRvIGFsbG93IGZvciBzZWFtbGVzcyBjb25uZWN0aXZp dHkNCiAgIGV2ZW4gYXMgZW5kcG9pbnRzIHJvYW0sIGV2ZW4gaWYgdGhleSBhcmUgbW92aW5nIG91 dCBmcm9tIGJlaGluZCBhIE5BVA0KICAgZ2F0ZXdheSwgZnJvbSBiZWhpbmQgb25lIE5BVCBnYXRl d2F5IHRvIGJlaGluZCBhbm90aGVyLCBvciBmcm9tIGENCiAgIHN0YW5kYWxvbmUgcG9zaXRpb24g dG8gYmVoaW5kIGEgTkFUIGdhdGV3YXkuDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAg ICBFeHBpcmVzIERlY2VtYmVyIDA1LCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAg ICAgICBKdW5lIDIwMTMNCg0KDQogICBJbiBhIHN0YXIgdG9wb2xvZ3kgd2hlbiB0d28gZW5kcG9p bnRzIGNvbW11bmljYXRlLCB0aGV5IG5lZWQgYQ0KICAgbWVjaGFuaXNtIGZvciBhdXRoZW50aWNh dGlvbiwgc3VjaCB0aGF0IHRoZXkgZG8gbm90IGV4cG9zZSB0aGVtc2VsdmVzDQogICB0byBpbXBl cnNvbmF0aW9uIGJ5IHRoZSBvdGhlciBzcG9rZSBlbmRwb2ludC4NCg0KMi4yLiAgR2F0ZXdheS10 by1HYXRld2F5IEFEVlBOIFVzZSBDYXNlDQoNCiAgIEEgdHlwaWNhbCBFbnRlcnByaXNlIHRyYWZm aWMgbW9kZWwgZm9sbG93cyBhIHN0YXIgdG9wb2xvZ3ksIHdpdGggdGhlDQogICBnYXRld2F5cyBj b25uZWN0aW5nIHRvIGVhY2ggb3RoZXIgdXNpbmcgSVBzZWMgdHVubmVscy4NCg0KICAgSG93ZXZl ciBmb3Igdm9pY2UgYW5kIG90aGVyIHJpY2ggbWVkaWEgdHJhZmZpYyB0aGF0IHJlcXVpcmVzIGEg bG90IG9mDQogICBiYW5kd2lkdGggb3IgaXMgcGVyZm9ybWFuY2Ugc2Vuc2l0aXZlLCB0aGUgdHJh ZmZpYyB0cm9tYm9uaW5nIHRvIHRoZQ0KICAgaHViIGNhbiBjcmVhdGUgdHJhZmZpYyBib3R0bGVu ZWNrcyBvbiB0aGUgaHViIGFuZCBjYW4gbGVhZCB0byBhbg0KICAgaW5jcmVhc2UgaW4gY29zdC4g IEEgZnVsbHkgbWVzaGVkIHNvbHV0aW9uIHdvdWxkIG1ha2UgYmVzdCB1c2Ugb2YgdGhlDQogICBh dmFpbGFibGUgbmV0d29yayBjYXBhY2l0eSBhbmQgcGVyZm9ybWFuY2UgYnV0IHRoZSBkZXBsb3lt ZW50IG9mIGENCiAgIGZ1bGx5IG1lc2hlZCBzb2x1dGlvbiBpbnZvbHZlcyBjb25zaWRlcmFibGUg Y29uZmlndXJhdGlvbiwgZXNwZWNpYWxseQ0KICAgd2hlbiBhIGxhcmdlIG51bWJlciBvZiBub2Rl cyBhcmUgaW52b2x2ZWQuICBJdCBpcyBmb3IgdGhpcyBwdXJwb3NlDQogICBzcG9rZS10by1zcG9r ZSB0dW5uZWxzIGFyZSBkeW5hbWljYWxseSBjcmVhdGVkIGFuZCB0b3JuLWRvd24uICBGb3INCiAg IHRoZSByZWFzb25zIG9mIGNvc3QgYW5kIG1hbnVhbCBlcnJvciByZWR1Y3Rpb24sIGl0IGlzIGRl c2lyZWQgdGhhdA0KICAgdGhlcmUgYmUgbWluaW1hbCBjb25maWd1cmF0aW9uIG9uIGVhY2ggZ2F0 ZXdheS4NCg0KICAgVGhlIHNvbHV0aW9uIG91Z2h0IHRvIHdvcmsgaW4gY2FzZXMgd2hlcmUgdGhl IGVuZHBvaW50cyBhcmUgaW4NCiAgIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW5zLCBh bGJlaXQsIG9uZXMgdGhhdCBoYXZlIGFuIGV4aXN0aW5nDQogICB0cnVzdCByZWxhdGlvbnNoaXAg KGZvciBleGFtcGxlIHR3byBvcmdhbmlzYXRpb25zIHdobyBhcmUNCiAgIGNvbGxhYm9yYXRpbmcg b24gYSBwcm9qZWN0LCB0aGV5IG1heSB3aXNoIHRvIGpvaW4gdGhlaXIgbmV0d29ya3MsDQogICB3 aGlsc3QgcmV0YWluaW5nIGluZGVwZW5kZW50IGNvbnRyb2wgb3ZlciBjb25maWd1cmF0aW9uKS4g IEl0IGlzDQogICBoaWdobHkgZGVzaXJhYmxlIHRoYXQgdGhlIHNvbHV0aW9uIHdvcmtzIGZvciB0 aGUgc3RhciwgZnVsbCBtZXNoIGFzDQogICB3ZWxsIGFzIGR5bmFtaWMgZnVsbCBtZXNoIHRvcG9s b2d5Lg0KDQogICBUaGUgc29sdXRpb24gb3VnaHQgdG8gYWxzbyBhZGRyZXNzIHRoZSBjYXNlIHdo ZXJlIGdhdGV3YXlzIHVzZQ0KICAgZHluYW1pYyBJUCBhZGRyZXNzZXMuDQoNCiAgIEFkZGl0aW9u YWxseSwgdGhlIHJvdXRpbmcgaW1wbGljYXRpb25zIG9mIGdhdGV3YXktdG8tZ2F0ZXdheQ0KICAg Y29tbXVuaWNhdGlvbiBuZWVkIHRvIGJlIGFkZHJlc3NlZC4gIEluIHRoZSBzaW1wbGUgY2FzZSwg c2VsZWN0b3JzDQogICBwcm92aWRlIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gZm9yIGEgZ2F0ZXdh eSB0byBmb3J3YXJkIHRyYWZmaWMNCiAgIGFwcHJvcHJpYXRlbHkuICBJbiBvdGhlciBjYXNlcywg YWRkaXRpb25hbCB0dW5uZWxpbmcgKGUuZy4sIEdlbmVyaWMNCiAgIFJvdXRpbmcgRW5jYXBzdWxh dGlvbiAtIEdSRSkgYW5kIHJvdXRpbmcgKGUuZy4sIE9wZW4gU2hvcnRlc3QgUGF0aA0KICAgRmly c3QgLSBPU1BGKSBwcm90b2NvbHMgYXJlIHJ1biBvdmVyIElQc2VjIHR1bm5lbHMsIGFuZCB0aGUN CiAgIGNvbmZpZ3VyYXRpb24gaW1wYWN0IG9uIHRob3NlIHByb3RvY29scyBuZWVkcyB0byBiZSBj b25zaWRlcmVkLg0KICAgVGhlcmUgaXMgYWxzbyB0aGUgY2FzZSB3aGVuIExheWVyLTMgVmlydHVh bCBQcml2YXRlIE5ldHdvcmtzIChMM1ZQTnMpDQogICBvcGVyYXRlIG92ZXIgSVBzZWMgVHVubmVs cy4NCg0KICAgV2hlbiB0d28gZ2F0ZXdheXMgY29tbXVuaWNhdGUsIHRoZXkgbmVlZCB0byB1c2Ug YSBtZWNoYW5pc20gZm9yDQogICBhdXRoZW50aWNhdGlvbiwgc3VjaCB0aGF0IHRoZXkgZG8gbm90 IGV4cG9zZSB0aGVtc2VsdmVzIHRvIHRoZSByaXNrDQogICBvZiBpbXBlcnNvbmF0aW9uIGJ5IHRo ZSBvdGhlciBlbnRpdGllcy4NCg0KMi4zLiAgRW5kcG9pbnQtdG8tR2F0ZXdheSBBRFZQTiBVc2Ug Q2FzZQ0KDQoNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAw NSwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgQXV0byBEaXNjb3ZlcnkgVlBOICAgICAgICAgICAgICAgICAgSnVuZSAyMDEzDQoNCg0K ICAgQW4gZW5kcG9pbnQgb3VnaHQgdG8gYmUgYWJsZSB0byB1c2UgdGhlIG1vc3QgZWZmaWNpZW50 IGdhdGV3YXkgYXMgaXQNCiAgIHJvYW1zIGluIHRoZSBpbnRlcm5ldC4NCg0KICAgQSBtb2JpbGUg dXNlciByb2FtaW5nIG9uIHRoZSBJbnRlcm5ldCBtYXkgY29ubmVjdCB0byBhIGdhdGV3YXksIHdo aWNoDQogICBiZWNhdXNlIG9mIHJvYW1pbmcgaXMgbm8gbG9uZ2VyIHRoZSBtb3N0IGVmZmljaWVu dCBnYXRld2F5IHRvIHVzZQ0KICAgKHJlYXNvbnMgY291bGQgYmUgY29zdC8gZWZmaWNpZW5jeS8g bGF0ZW5jeSBvciBzb21lIG90aGVyIGZhY3RvcikuDQogICBUaGUgbW9iaWxlIHVzZXIgb3VnaHQg dG8gYmUgYWJsZSB0byBkaXNjb3ZlciBhbmQgdGhlbiBjb25uZWN0IHRvIHRoZQ0KICAgY3VycmVu dCBtb3N0IGVmZmljaWVudCBnYXRld2F5IHdpdGhvdXQgaGF2aW5nIHRvIHJlaW5pdGlhdGUgdGhl DQogICBjb25uZWN0aW9uLg0KDQozLiAgSW5hZGVxdWFjeSBvZiBFeGlzdGluZyBTb2x1dGlvbnMN Cg0KICAgU2V2ZXJhbCBzb2x1dGlvbnMgZXhpc3QgZm9yIHRoZSBwcm9ibGVtcyBkZXNjcmliZWQg YWJvdmUuICBIb3dldmVyLA0KICAgbm9uZSBvZiB0aGVzZSBzb2x1dGlvbnMgaXMgYWRlcXVhdGUs IGFzIGRlc2NyaWJlZCBoZXJlLg0KDQozLjEuICBFeGhhdXN0aXZlIENvbmZpZ3VyYXRpb24NCg0K ICAgT25lIHNpbXBsZSBzb2x1dGlvbiBpcyB0byBjb25maWd1cmUgYWxsIGdhdGV3YXlzIGFuZCBl bmRwb2ludHMgaW4NCiAgIGFkdmFuY2Ugd2l0aCBhbGwgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0 byBkZXRlcm1pbmUgd2hpY2ggZ2F0ZXdheSBvcg0KICAgZW5kcG9pbnQgaXMgb3B0aW1hbCBhbmQg dG8gZXN0YWJsaXNoIGFuIFNBIHdpdGggdGhhdCBnYXRld2F5IG9yDQogICBlbmRwb2ludC4gIEhv d2V2ZXIsIHRoaXMgc29sdXRpb24gZG9lcyBub3Qgc2NhbGUgaW4gYSBsYXJnZSBuZXR3b3JrDQog ICB3aXRoIGh1bmRyZWRzIG9mIHRob3VzYW5kcyBvZiBnYXRld2F5cyBhbmQgZW5kcG9pbnRzLCBl c3BlY2lhbGx5IHdoZW4NCiAgIG11bHRpcGxlIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMgYXJlIGlu dm9sdmVkIGFuZCB0aGluZ3MgYXJlIHJhcGlkbHkNCiAgIGNoYW5naW5nIChlLmcuICBtb2JpbGUg ZW5kcG9pbnRzKS4gIFN1Y2ggYSBzb2x1dGlvbiBpcyBhbHNvIGxpbWl0ZWQNCiAgIGJ5IHRoZSBz bWFsbGVzdCBlbmRwb2ludC8gZ2F0ZXdheSwgYXMgdGhlIHNhbWUgZXhoYXVzdGl2ZQ0KICAgY29u ZmlndXJhdGlvbiBpcyB0byBiZSBhcHBsaWVkIG9uIGFsbCBlbmRwb2ludHMvIGdhdGV3YXlzLiAg QSBtb3JlDQogICBkeW5hbWljLCBzZWN1cmUgYW5kIHNjYWxhYmxlIHN5c3RlbSBmb3IgZXN0YWJs aXNoaW5nIFNBcyBiZXR3ZWVuDQogICBnYXRld2F5cyBpcyBuZWVkZWQuDQoNCjMuMi4gIFN0YXIg VG9wb2xvZ3kNCg0KICAgVGhlIG1vc3QgY29tbW9uIHdheSB0byBhZGRyZXNzIGEgcGFydCBvZiB0 aGlzIHRoaXMgcHJvYmxlbSB0b2RheSBpcw0KICAgdG8gdXNlIHdoYXQgaGFzIGJlZW4gdGVybWVk IGEgInN0YXIgdG9wb2xvZ3kiLiAgSW4gdGhpcyBjYXNlIG9uZSBvciBhDQogICBmZXcgZ2F0ZXdh eXMgYXJlIGRlZmluZWQgYXMgImh1YiBnYXRld2F5cyIsIHdoaWxlIHRoZSByZXN0IG9mIHRoZQ0K ICAgc3lzdGVtcyAod2hldGhlciBlbmRwb2ludHMgb3IgZ2F0ZXdheXMpIGFyZSBkZWZpbmVkIGFz ICJzcG9rZXMiLiAgVGhlDQogICBzcG9rZXMgbmV2ZXIgY29ubmVjdCB0byBvdGhlciBzcG9rZXMu ICBUaGV5IG9ubHkgb3BlbiB0dW5uZWxzIHdpdGgNCiAgIHRoZSBodWIgZ2F0ZXdheXMuICBBbHNv IGZvciBhIGxhcmdlIG51bWJlciBvZiBnYXRld2F5cyBpbiBvbmUNCiAgIGFkbWluaXN0cmF0aXZl IGRvbWFpbiwgb25lIGdhdGV3YXkgbWF5IGJlIGRlZmluZWQgYXMgdGhlIGh1YiwgYW5kIHRoZQ0K ICAgcmVzdCBvZiB0aGUgZ2F0ZXdheXMgYW5kIHJlbW90ZSBhY2Nlc3MgY2xpZW50cyBjb25uZWN0 IG9ubHkgdG8gdGhhdA0KICAgZ2F0ZXdheS4NCg0KICAgVGhpcyBzb2x1dGlvbiBob3dldmVyIGlz IGNvbXBsaWNhdGVkIGJ5IHRoZSBjYXNlIHdoZW4gdGhlIHNwb2tlcyB1c2UNCiAgIGR5bmFtaWMg SVAgYWRkcmVzc2VzIGFuZCBETlMgd2l0aCBkeW5hbWljIHVwZGF0ZXMgbmVlZHMgdG8gYmUgdXNl ZC4NCiAgIEl0IGlzIGFsc28gZGVzaXJlZCB0aGF0IHRoZXJlIGlzIG1pbmltYWwgdG8gbm8gY29u ZmlndXJhdGlvbiBvbiB0aGUNCiAgIGh1YiBhcyB0aGUgbnVtYmVyIG9mIHNwb2tlcyBpbmNyZWFz ZXMgYW5kIG5ldyBzcG9rZXMgYXJlIGFkZGVkIGFuZA0KICAgZGVsZXRlZCByYW5kb21seS4NCg0K DQoNCg0KDQpIYW5uYSAmIE1hbnJhbCAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMDUsIDIwMTMg ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1 dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMw0KDQoNCiAgIEFub3Ro ZXIgcHJvYmxlbSB3aXRoIHRoZSBzdGFyIHRvcG9sb2d5IGlzIHRoYXQgaXQgY3JlYXRlcyBhIGhp Z2ggbG9hZA0KICAgb24gdGhlIGh1YiBnYXRld2F5cyBhcyB3ZWxsIGFzIG9uIHRoZSBjb25uZWN0 aW9uIGJldHdlZW4gdGhlIHNwb2tlcw0KICAgYW5kIHRoZSBodWIuICBUaGlzIGxvYWQgaXMgYm90 aCBpbiBwcm9jZXNzaW5nIHBvd2VyIGFuZCBpbiBuZXR3b3JrDQogICBiYW5kd2lkdGguICBBIHNp bmdsZSBwYWNrZXQgaW4gdGhlIGh1Yi1hbmQtc3Bva2Ugc2NlbmFyaW8gY2FuIGJlDQogICBlbmNy eXB0ZWQgYW5kIGRlY3J5cHRlZCBtdWx0aXBsZSB0aW1lcy4gIEl0IHdvdWxkIGJlIG11Y2ggcHJl ZmVyYWJsZQ0KICAgaWYgdGhlc2UgZ2F0ZXdheXMgYW5kIGNsaWVudHMgY291bGQgaW5pdGlhdGUg dHVubmVscyBiZXR3ZWVuIHRoZW0sDQogICBieXBhc3NpbmcgdGhlIGh1YiBnYXRld2F5cy4gIEFk ZGl0aW9uYWxseSwgdGhlIHBhdGggYmFuZHdpZHRoIHRvDQogICB0aGVzZSBodWIgZ2F0ZXdheXMg bWF5IGJlIGxvd2VyIHRoYW4gdGhhdCBvZiB0aGUgcGF0aCBiZXR3ZWVuIHRoZQ0KICAgc3Bva2Vz LiAgRm9yIGV4YW1wbGUsIHR3byByZW1vdGUgYWNjZXNzIHVzZXJzIG1heSBiZSBpbiB0aGUgc2Ft ZQ0KICAgYnVpbGRpbmcgd2l0aCBoaWdoLXNwZWVkIHdpZmkgKGZvciBleGFtcGxlLCBhdCBhbiBJ RVRGIG1lZXRpbmcpLg0KICAgQ2hhbm5lbGluZyB0aGVpciBjb252ZXJzYXRpb24gdGhyb3VnaCB0 aGUgaHViIGdhdGV3YXlzIG9mIHRoZWlyDQogICByZXNwZWN0aXZlIGVtcGxveWVycyBzZWVtcyBl eHRyZW1lbHkgd2FzdGVmdWwsIGFzIHdlbGwgYXMgaGF2aW5nDQogICBsb3dlciBiYW5kd2lkdGgu DQoNCiAgIFRoZSBjaGFsbGVuZ2UgaXMgdG8gYnVpbGQgYSBsYXJnZSBzY2FsZSwgSVBzZWMgcHJv dGVjdGVkIG5ldHdvcmtzDQogICB0aGF0IGNhbiBkeW5hbWljYWxseSBjaGFuZ2Ugd2l0aCBtaW5p bXVtIGFkbWluaXN0cmF0aXZlIG92ZXJoZWFkLg0KDQozLjMuICBQcm9wcmlldGFyeSBBcHByb2Fj aGVzDQoNCiAgIFNldmVyYWwgdmVuZG9ycyBvZmZlciBwcm9wcmlldGFyeSBzb2x1dGlvbnMgdG8g dGhlc2UgcHJvYmxlbXMuDQogICBIb3dldmVyLCB0aGVzZSBzb2x1dGlvbnMgb2ZmZXIgbm8gaW50 ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGVxdWlwbWVudA0KICAgZnJvbSBvbmUgdmVuZG9yIGFuZCBh bm90aGVyLiAgVGhpcyBtZWFucyB0aGF0IHRoZXkgYXJlIGdlbmVyYWxseQ0KICAgcmVzdHJpY3Rl ZCB0byB1c2Ugd2l0aGluIG9uZSBvcmdhbml6YXRpb24sIGFuZCBpdCBpcyBoYXJkZXIgdG8gbW92 ZQ0KICAgb2ZmIHN1Y2ggc29sdXRpb25zIGFzIHRoZSBmZWF0dXJlcyBhcmUgbm90IHN0YW5kYXJk aXplZC4gIEJlc2lkZXMNCiAgIG11bHRpcGxlIG9yZ2FuaXphdGlvbnMgY2Fubm90IGJlIGV4cGVj dGVkIHRvIGFsbCBjaG9vc2UgdGhlIHNhbWUNCiAgIGVxdWlwbWVudCB2ZW5kb3IuDQoNCjQuICBS ZXF1aXJlbWVudHMNCg0KICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHJlcXVpcmVtZW50cywg b24gd2hpY2ggdGhlIHNvbHV0aW9uIHdpbGwgYmUNCiAgIGJhc2VkLg0KDQo0LjEuICBHYXRld2F5 IGFuZCBFbmRwb2ludCBSZXF1aXJlbWVudHMNCg0KICAgMS4gIEZvciBhbnkgbmV0d29yayB0b3Bv bG9neSAoc3RhciwgZnVsbCBtZXNoIGFuZCBkeW5hbWljIGZ1bGwgbWVzaCkNCiAgIGdhdGV3YXlz IGFuZCBlbmRwb2ludHMgU0hPVUxEIG1pbmltaXplIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyB3aGVu IGENCiAgIG5ldyBnYXRld2F5IG9yIGVuZHBvaW50IGlzIGFkZGVkLCByZW1vdmVkIG9yIGNoYW5n ZWQuICBBZGRpbmcgb3INCiAgIHJlbW92aW5nIGEgc3Bva2UgaW4gdGhlIHRvcG9sb2d5IE1VU1Qg Tk9UIHJlcXVpcmUgY29uZmlndXJhdGlvbg0KICAgY2hhbmdlcyB0byB0aGUgaHVicyBvdGhlciB0 aGFuIHdoZXJlIHRoZSBzcG9rZSB3YXMgY29ubmVjdGVkIHRvIGFuZA0KICAgU0hPVUxEIE5PVCBy ZXF1aXJlIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyB0byB0aGUgaHViIHRoZSBzcG9rZSB3YXMNCiAg IGNvbm5lY3RlZCB0by4gIFRoZSBjaGFuZ2VzIGFsc28gTVVTVCBOT1QgcmVxdWlyZSBjb25maWd1 cmF0aW9uDQogICBjaGFuZ2VzIGluIG90aGVyIHNwb2tlcy4NCg0KICAgU3BlY2lmaWNhbGx5LCB3 aGVuIGV2YWx1YXRpbmcgcG90ZW50aWFsIHByb3Bvc2Fscywgd2Ugd2lsbCBjb21wYXJlDQogICB0 aGVtIGJ5IGxvb2tpbmcgYXQgaG93IG1hbnkgZW5kcG9pbnRzIG9yIGdhdGV3YXlzIG11c3QgYmUN CiAgIHJlY29uZmlndXJlZCB3aGVuIGEgbmV3IGdhdGV3YXkgb3IgZW5kcG9pbnQgaXMgYWRkZWQs IHJlbW92ZWQsIG9yDQogICBjaGFuZ2VkIGFuZCBob3cgc3Vic3RhbnRpYWwgdGhpcyByZWNvbmZp Z3VyYXRpb24gaXMsIGJlc2lkZXMgdGhlDQogICBhbW91bnQgb2Ygc3RhdGljIGNvbmZpZ3VyYXRp b24gcmVxdWlyZWQuDQoNCg0KDQpIYW5uYSAmIE1hbnJhbCAgICAgICAgIEV4cGlyZXMgRGVjZW1i ZXIgMDUsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMw0K DQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5IHVzZSBjYXNlcyAyLjEgYW5kIDIu MiBhbmQgYnkgdGhlDQogICBzY2FsaW5nIGxpbWl0YXRpb25zIHBvaW50ZWQgb3V0IGluIHNlY3Rp b24gMy4xLg0KDQogICAyLiAgQURWUE4gcGVlcnMgTVVTVCBhbGxvdyBJUHNlYyBUdW5uZWxzIHRv IGJlIHNldHVwIHdpdGggb3RoZXINCiAgIG1lbWJlcnMgb2YgdGhlIEFEVlBOIHdpdGhvdXQgYW55 IGNvbmZpZ3VyYXRpb24gY2hhbmdlcywgZXZlbiB3aGVuDQogICBwZWVyIGFkZHJlc3NlcyBnZXQg dXBkYXRlZCBldmVyeSB0aW1lIHRoZSBkZXZpY2UgY29tZXMgdXAuICBUaGlzDQogICBpbXBsaWVz IHRoYXQgU1BEIGVudHJpZXMgb3Igb3RoZXIgY29uZmlndXJhdGlvbiBiYXNlZCBvbiBwZWVyIElQ DQogICBhZGRyZXNzIHdpbGwgbmVlZCB0byBiZSBhdXRvbWF0aWNhbGx5IHVwZGF0ZWQsIGF2b2lk ZWQsIG9yIGhhbmRsZWQgaW4NCiAgIHNvbWUgbWFubmVyIHRvIGF2b2lkIGEgbmVlZCB0byBtYW51 YWxseSB1cGRhdGUgcG9saWN5IHdoZW5ldmVyIGFuDQogICBhZGRyZXNzIGNoYW5nZXMuDQoNCiAg IDMuICBJbiBtYW55IGNhc2VzIGFkZGl0aW9uYWwgdHVubmVsaW5nIHByb3RvY29scyAoZS5nLiAg R1JFKSBvcg0KICAgUm91dGluZyBwcm90b2NvbHMgKGUuZy4gIE9TUEYpIGFyZSBydW4gb3ZlciB0 aGUgSVBzZWMgdHVubmVscy4NCiAgIEdhdGV3YXlzIE1VU1QgYWxsb3cgZm9yIHRoZSBvcGVyYXRp b24gb2YgdHVubmVsaW5nIGFuZCBSb3V0aW5nDQogICBwcm90b2NvbHMgb3BlcmF0aW5nIG92ZXIg c3Bva2UtdG8tc3Bva2UgSVBzZWMgVHVubmVscyB3aXRoIG1pbmltYWwgb3INCiAgIG5vLCBjb25m aWd1cmF0aW9uIGltcGFjdC4gIFRoZSBBRFZQTiBzb2x1dGlvbiBTSE9VTEQgTk9UIGluY3JlYXNl IHRoZQ0KICAgYW1vdW50IG9mIGluZm9ybWF0aW9uIHJlcXVpcmVkIHRvIGNvbmZpZ3VyZSBwcm90 b2NvbHMgcnVubmluZyBvdmVyDQogICBJUHNlYyB0dW5uZWxzLg0KDQogICA0LiAgSW4gdGhlIGZ1 bGwgbWVzaCBhbmQgZHluYW1pYyBmdWxsIG1lc2ggdG9wb2xvZ3ksIFNwb2tlcyBNVVNUDQogICBh bGxvdyBmb3IgZGlyZWN0IGNvbW11bmljYXRpb24gd2l0aCBvdGhlciBzcG9rZSBnYXRld2F5cyBh bmQNCiAgIGVuZHBvaW50cy4gIEluIHRoZSBzdGFyIHRvcG9sb2d5IG1vZGUsIGRpcmVjdCBjb21t dW5pY2F0aW9uIGJldHdlZW4NCiAgIHNwb2tlcyBNVVNUIGJlIGRpc2FsbG93ZWQuDQoNCiAgIFRo aXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5IHVzZSBjYXNlcyAyLjEgYW5kIDIuMiBhbmQgYnkg dGhlDQogICBsaW1pdGF0aW9ucyBvZiBhIHN0YXIgdG9wb2xvZ3kgcG9pbnRlZCBvdXQgaW4gc2Vj dGlvbiAzLjIuDQoNCiAgIDUuICBBbnkgb2YgdGhlIEFEVlBOIFBlZXJzIE1VU1QgTk9UIGhhdmUg YSB3YXkgdG8gZ2V0IHRoZSBsb25nIHRlcm0NCiAgIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxz IGZvciBhbnkgb3RoZXIgQURWUE4gUGVlcnMuICBUaGUgY29tcHJvbWlzZQ0KICAgb2YgYW4gRW5k cG9pbnQgTVVTVCBOT1QgYWZmZWN0IHRoZSBzZWN1cml0eSBvZiBjb21tdW5pY2F0aW9ucyBiZXR3 ZWVuDQogICBvdGhlciBBRFZQTiBQZWVycy4gIFRoZSBjb21wcm9taXNlIG9mIGEgR2F0ZXdheSBT SE9VTEQgTk9UIGFmZmVjdCB0aGUNCiAgIHNlY3VyaXR5IG9mIHRoZSBjb21tdW5pY2F0aW9ucyBi ZXR3ZWVuIEFEVlBOIFBlZXJzIG5vdCBhc3NvY2lhdGVkDQogICB3aXRoIHRoYXQgR2F0ZXdheS4N Cg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkgdXNlIGNhc2UgMi4xLiAgQURWUE4g UGVlcnMgKGVzcGVjaWFsbHkNCiAgIFNwb2tlcykgYmVjb21lIGNvbXByb21pc2VkIGZhaXJseSBv ZnRlbi4gIFRoZSBjb21wcm9taXNlIG9mIG9uZSBBRFZQTg0KICAgUGVlciBTSE9VTEQgTk9UIGFm ZmVjdCB0aGUgc2VjdXJpdHkgb2Ygb3RoZXIgdW5yZWxhdGVkIEFEVlBOIFBlZXJzLg0KDQogICA2 LiAgR2F0ZXdheXMgU0hPVUxEIGFsbG93IGZvciBzZWFtbGVzcyBoYW5kb2ZmIG9mIHNlc3Npb25z IGluIGNhc2UNCiAgIGVuZHBvaW50cyBhcmUgcm9hbWluZywgZXZlbiBpZiB0aGV5IGNyb3NzIHBv bGljeSBib3VuZGFyaWVzLiAgVGhpcw0KICAgd291bGQgbWVhbiB0aGUgZGF0YSB0cmFmZmljIGlz IG1pbmltYWxseSBhZmZlY3RlZCBldmVuIGFzIHRoZSBoYW5kb2ZmDQogICBoYXBwZW5zLiAgRXh0 ZXJuYWwgZmFjdG9ycyBsaWtlIGZpcmV3YWxsLCBOQVQgYm94ZXMgd2lsbCBub3QgYmUNCiAgIGNv bnNpZGVyZWQgcGFydCBvZiB0aGlzIHNvbHV0aW9uLg0KDQogICBTdWNoIGVuZHBvaW50IHJvYW1p bmcgbWF5IGFmZmVjdCBub3Qgb25seSB0aGUgZW5kcG9pbnQtdG8tZW5kcG9pbnQgU0ENCiAgIGJ1 dCBhbHNvIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgZW5kcG9pbnRzIGFuZCBnYXRld2F5 cyAoc3VjaCBhcw0KICAgd2hlbiBhbiBlbmRwb2ludCByb2FtcyB0byBhIG5ldyBuZXR3b3JrIHRo YXQgaXMgaGFuZGxlZCBieSBhDQogICBkaWZmZXJlbnQgZ2F0ZXdheSkuDQoNCg0KDQpIYW5uYSAm IE1hbnJhbCAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMDUsIDIwMTMgICAgICAgICAgICAgICAg W1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQ TiAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMw0KDQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMg ZHJpdmVuIGJ5IHVzZSBjYXNlIDIuMS4gIFRvZGF5J3MgZW5kcG9pbnRzIGFyZQ0KICAgbW9iaWxl IGFuZCB0cmFuc2l0aW9uIG9mdGVuIGJldHdlZW4gZGlmZmVyZW50IG5ldHdvcmtzIChmcm9tIDRH IHRvDQogICBXaUZpIGFuZCBhbW9uZyB2YXJpb3VzIFdpRmkgbmV0d29ya3MpLg0KDQogICA3LiAg R2F0ZXdheXMgU0hPVUxEIGFsbG93IGZvciBlYXN5IGhhbmRvZmYgb2YgYSBzZXNzaW9uIHRvIGFu b3RoZXINCiAgIGdhdGV3YXksIHRvIG9wdGltaXplIGxhdGVuY3ksIGJhbmR3aWR0aCwgbG9hZCBi YWxhbmNpbmcsDQogICBhdmFpbGFiaWxpdHksIG9yIG90aGVyIGZhY3RvcnMsIGJhc2VkIG9uIHBv bGljeS4NCg0KICAgVGhpcyBhYmlsaXR5IHRvIG1pZ3JhdGUgdHJhZmZpYyBmcm9tIG9uZSBnYXRl d2F5IHRvIGFub3RoZXIgYXBwbGllcw0KICAgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBnYXRl d2F5cyBpbiBxdWVzdGlvbiBhcmUgaHVicyBvciBzcG9rZXMuDQogICBJdCBldmVuIGFwcGxpZXMg aW4gdGhlIGNhc2Ugd2hlcmUgYSBnYXRld2F5IChodWIgb3Igc3Bva2UpIG1vdmVzIGluDQogICB0 aGUgbmV0d29yaywgYXMgbWF5IGhhcHBlbiB3aXRoIGEgdmVoaWNsZS1iYXNlZCBuZXR3b3JrLg0K DQogICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZlbiBieSB1c2UgY2FzZSAyLjMuDQoNCiAgIDgu ICBHYXRld2F5cyBhbmQgZW5kcG9pbnRzIE1VU1QgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBwYXJ0 aWNpcGF0ZSBpbg0KICAgYW4gQURWUE4gZXZlbiB3aGVuIHRoZXkgYXJlIGxvY2F0ZWQgYmVoaW5k IE5BVCBib3hlcy4gIEhvd2V2ZXIsIGluDQogICBzb21lIGNhc2VzIHRoZXkgbWF5IGJlIGRlcGxv eWVkIGluIHN1Y2ggYSB3YXkgdGhhdCB0aGV5IHdpbGwgbm90IGJlDQogICBmdWxseSByZWFjaGFi bGUgYmVoaW5kIGEgTkFUIGJveC4gIEl0IGlzIGVzcGVjaWFsbHkgZGlmZmljdWx0IHRvDQogICBo YW5kbGUgY2FzZXMgd2hlcmUgdGhlIEh1YiBpcyBiZWhpbmQgYSBOQVQgYm94LiAgV2hlcmUgdGhl IHR3bw0KICAgZW5kcG9pbnRzIGFyZSBib3RoIGJlaGluZCBzZXBhcmF0ZSBOQVRzLCBjb21tdW5p Y2F0aW9uIGJldHdlZW4gdGhlc2UNCiAgIHNwb2tlcyBTSE9VTEQgYmUgc3VwcG9ydGVkIHVzaW5n IHdvcmthcm91bmRzIHN1Y2ggYXMgcG9ydCBmb3J3YXJkaW5nDQogICBieSB0aGUgTkFUIG9yIGRl dGVjdGluZyB3aGVuIHR3byBzcG9rZXMgYXJlIGJlaGluZCB1bmNvb3BlcmF0aXZlIE5BVHMNCiAg IGFuZCB1c2luZyBhIGh1YiBpbiB0aGF0IGNhc2UuDQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMg ZHJpdmVuIGJ5IHVzZSBjYXNlcyAyLjEgYW5kIDIuMi4gIEVuZHBvaW50cyBhcmUNCiAgIG9mdGVu IGJlaGluZCBOQVRzIGFuZCBnYXRld2F5cyBzb21ldGltZXMgYXJlLiAgSVBzZWMgU0hPVUxEIGNv bnRpbnVlDQogICB0byB3b3JrIHNlYW1sZXNzbHkgcmVnYXJkbGVzcywgdXNpbmcgQURWUE4gdGVj aG5pcXVlcyB3aGVuZXZlcg0KICAgcG9zc2libGUgYW5kIHByb3ZpZGluZyBncmFjZWZ1bCBmYWxs YmFjayB0byBodWIgYW5kIHNwb2tlIHRlY2huaXF1ZXMNCiAgIGFzIG5lZWRlZC4NCg0KICAgOS4g IENoYW5nZXMgc3VjaCBhcyBlc3RhYmxpc2hpbmcgYSBuZXcgSVBzZWMgU0EgU0hPVUxEIGJlIHJl cG9ydGFibGUNCiAgIGFuZCBtYW5hZ2VhYmxlLiAgSG93ZXZlciwgY3JlYXRpbmcgYSBNSUIgb3Ig b3RoZXIgbWFuYWdlbWVudA0KICAgdGVjaG5pcXVlIGlzIG5vdCB3aXRoaW4gc2NvcGUgZm9yIHRo aXMgZWZmb3J0Lg0KDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZlbiBieSBtYW5hZ2VhYmls aXR5IGNvbmNlcm5zIGZvciBhbGwgdGhlIHVzZQ0KICAgY2FzZXMsIGVzcGVjaWFsbHkgdXNlIGNh c2UgMi4yLiAgQXMgSVBzZWMgbmV0d29ya3MgYmVjb21lIG1vcmUNCiAgIGR5bmFtaWMsIG1hbmFn ZW1lbnQgdG9vbHMgYmVjb21lIG1vcmUgZXNzZW50aWFsLg0KDQogICAxMC4gIFRvIHN1cHBvcnQg YWxsaWVkIGFuZCBmZWRlcmF0ZWQgZW52aXJvbm1lbnRzLCBlbmRwb2ludHMgYW5kDQogICBnYXRl d2F5cyBmcm9tIGRpZmZlcmVudCBvcmdhbml6YXRpb25zIFNIT1VMRCBiZSBhYmxlIHRvIGNvbm5l Y3QgdG8NCiAgIGVhY2ggb3RoZXIuDQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5 IGRlbWFuZCBmb3IgYWxsIHRoZSB1c2UgY2FzZXMgaW4NCiAgIGZlZGVyYXRlZCBhbmQgYWxsaWVk IGVudmlyb25tZW50cy4NCg0KDQoNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAgRXhwaXJl cyBEZWNlbWJlciAwNSwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgQXV0byBEaXNjb3ZlcnkgVlBOICAgICAgICAgICAgICAgICAgSnVu ZSAyMDEzDQoNCg0KICAgMTEuICBUaGUgYWRtaW5pc3RyYXRvciBvZiB0aGUgQURWUE4gU0hPVUxE IGFsbG93IGZvciB0aGUNCiAgIGNvbmZpZ3VyYXRpb24gb2YgYSBTdGFyLCBGdWxsIG1lc2ggb3Ig YSBwYXJ0aWFsIGZ1bGwgbWVzaCB0b3BvbG9neSwNCiAgIGJhc2VkIG9uIHdoaWNoIHR1bm5lbHMg YXJlIGFsbG93ZWQgdG8gYmUgc2V0dXAuDQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVu IGJ5IGRlbWFuZCBmb3IgYWxsIHRoZSB1c2UgY2FzZXMgaW4NCiAgIGZlZGVyYXRlZCBhbmQgYWxs aWVkIGVudmlyb25tZW50cy4NCg0KICAgMTIuICBUaGUgQURWUE4gc29sdXRpb24gU0hPVUxEIGJl IGFibGUgdG8gc2NhbGUgZm9yIG11bHRpY2FzdA0KICAgdHJhZmZpYy4NCg0KICAgVGhpcyByZXF1 aXJlbWVudCBpcyBkcml2ZW4gYnkgdGhlIHVzZSBjYXNlIDIuMiwgd2hlcmUgdGhlIGFtb3VudCBv Zg0KICAgcmljaCBtZWRpYSBtdWx0aWNhc3QgdHJhZmZpYyBpcyBpbmNyZWFzaW5nLg0KDQogICAx My4gIFRoZSBBRFZQTiBzb2x1dGlvbiBTSE9VTEQgYWxsb3cgZm9yIGVhc3kgbW9uaXRvcmluZywg bG9nZ2luZyBhbmQNCiAgIHJlcG9ydGluZyBvZiB0aGUgZHluYW1pYyBjaGFuZ2VzLCB0byBoZWxw IGZvciB0cm91YmxlIHNob290aW5nIHN1Y2gNCiAgIGVudmlyb25tZW50cy4NCg0KICAgVGhpcyBy ZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkgZGVtYW5kIGZvciBhbGwgdGhlIHVzZSBjYXNlcyBpbg0K ICAgZmVkZXJhdGVkIGFuZCBhbGxpZWQgZW52aXJvbm1lbnRzLg0KDQogICAxNC4gIFRoZXJlIGlz IGFsc28gdGhlIGNhc2Ugd2hlbiBMM1ZQTnMgb3BlcmF0ZSBvdmVyIElQc2VjIFR1bm5lbHMsDQog ICBmb3IgZXhhbXBsZSBQcm92aWRlciBFZGdlIChQRSkgYmFzZWQgVlBOJ3MuICBBbiBBRFZQTiBN VVNUIHN1cHBvcnQNCiAgIEwzVlBOIGFzIGFuIGFwcGxpY2F0aW9uIHByb3RlY3RlZCBieSB0aGUg SVBzZWMgVHVubmVscy4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkgZGVtYW5k IGZvciBhbGwgdGhlIHVzZSBjYXNlcyBpbg0KICAgZmVkZXJhdGVkIGFuZCBhbGxpZWQgZW52aXJv bm1lbnRzLg0KDQogICAxNS4gIFRoZXJlIEFEVlBOIHNvbHV0aW9uIFNIT1VMRCBhbGxvdyB0aGUg ZW5mb3JjZW1lbnQgb2YgcGVyIHBlZXINCiAgIFFvUyBpbiBib3RoIHRoZSBTdGFyIGFzIHdlbGwg YXMgdGhlIEZ1bGwgTWVzaCB0b3BvbG9neS4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2 ZW4gYnkgZGVtYW5kIGZvciBhbGwgdGhlIHVzZSBjYXNlcyBpbg0KICAgZmVkZXJhdGVkIGFuZCBh bGxpZWQgZW52aXJvbm1lbnRzLg0KDQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAg VGhpcyBpcyBhIFByb2JsZW0gc3RhdGVtZW50IGFuZCByZXF1aXJlbWVudCBkb2N1bWVudCBmb3Ig dGhlIEFEVlBODQogICBzb2x1dGlvbiwgYW5kIGluIGl0c2VsZiBkb2VzIG5vdCBpbnRyb2R1Y2Ug YW55IG5ldyBzZWN1cml0eSBjb25jZXJucy4NCiAgIFRoZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxl bXMgcHJlc2VudGVkIGluIHRoaXMgZHJhZnQgbWF5IGludm9sdmUNCiAgIGR5bmFtaWMgdXBkYXRl cyB0byBkYXRhYmFzZXMgZGVmaW5lZCBieSBSRkMgNDMwMSwgc3VjaCBhcyB0aGUNCiAgIFNlY3Vy aXR5IFBvbGljeSBEYXRhYmFzZSAoU1BEKSBvciB0aGUgUGVlciBBdXRob3JpemF0aW9uIERhdGFi YXNlDQogICAoUEFEKS4NCg0KICAgUkZDIDQzMDEgaXMgc2lsZW50IGFib3V0IHRoZSB3YXkgdGhl c2UgZGF0YWJhc2VzIGFyZSBwb3B1bGF0ZWQsIGFuZA0KICAgaXQgaXMgaW1wbGllZCB0aGF0IHRo ZXNlIGRhdGFiYXNlcyBhcmUgc3RhdGljIGFuZCBwcmUtY29uZmlndXJlZCBieSBhDQogICBodW1h bi4gIEFsbG93aW5nIGR5bmFtaWMgdXBkYXRlcyB0byB0aGVzZSBkYXRhYmFzZXMgbXVzdCBiZSB0 aG91Z2h0DQogICBvdXQgY2FyZWZ1bGx5LCBiZWNhdXNlIGl0IGFsbG93cyB0aGUgcHJvdG9jb2wg dG8gYWx0ZXIgdGhlIHNlY3VyaXR5DQogICBwb2xpY3kgdGhhdCB0aGUgSVBzZWMgZW5kcG9pbnRz IGltcGxlbWVudC4NCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICBFeHBpcmVzIERlY2Vt YmVyIDA1LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAgICAgICBKdW5lIDIwMTMN Cg0KDQogICBPbmUgb2J2aW91cyBhdHRhY2sgdG8gd2F0Y2ggb3V0IGZvciBpcyBzdGVhbGluZyB0 cmFmZmljIHRvIGENCiAgIHBhcnRpY3VsYXIgc2l0ZS4gIFRoZSBJUCBhZGRyZXNzIGZvciB3d3cu ZXhhbXBsZS5jb20gaXMgMTkyLjAuMi4xMC4NCiAgIElmIHdlIGFkZCBhbiBlbnRyeSB0byBhbiBJ UHNlYyBlbmRwb2ludCdzIFNQRCB0aGF0IHNheXMgdGhhdCB0cmFmZmljDQogICB0byAxOTIuMC4y LjEwIGlzIHByb3RlY3RlZCB0aHJvdWdoIHBlZXIgR3ctTWFsbG9yeSwgdGhlbiB0aGlzIGFsbG93 cw0KICAgR3ctTWFsbG9yeSB0byBlaXRoZXIgcHJldGVuZCB0byBiZSB3d3cuZXhhbXBsZS5jb20g b3IgdG8gcHJveHkgYW5kDQogICByZWFkIGFsbCB0cmFmZmljIHRvIHRoYXQgc2l0ZS4gIFVwZGF0 ZXMgdG8gdGhpcyBkYXRhYmFzZSByZXF1aXJlcyBhDQogICBjbGVhciB0cnVzdCBtb2RlbC4NCg0K Ni4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgTm8gYWN0aW9ucyBhcmUgcmVxdWlyZWQgZnJv bSBJQU5BIGZvciB0aGlzIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQuDQoNCjcuICBBY2tub3dsZWRn ZW1lbnRzDQoNCiAgIE1hbnkgcGVvcGxlIGhhdmUgY29udHJpYnV0ZWQgdG8gdGhlIGRldmVsb3Bt ZW50IG9mIHRoaXMgcHJvYmxlbQ0KICAgc3RhdGVtZW50IGFuZCBtYW55IG1vcmUgd2lsbCBwcm9i YWJseSBkbyBzbyBiZWZvcmUgd2UgYXJlIGRvbmUgd2l0aA0KICAgaXQuICBXaGlsZSB3ZSBjYW5u b3QgdGhhbmsgYWxsIGNvbnRyaWJ1dG9ycywgc29tZSBoYXZlIHBsYXllZCBhbg0KICAgZXNwZWNp YWxseSBwcm9taW5lbnQgcm9sZS4gIFlvYXYgTmlyLCBZYXJvbiBTaGVmZmVyLCBKb3JnZSBDb3Jv bmVsDQogICBNZW5kb3phLCBDaHJpcyBVbGxpb3R0LCBhbmQgSm9obiBWZWl6YWRlcyB3cm90ZSB0 aGUgZG9jdW1lbnQgdXBvbg0KICAgd2hpY2ggdGhpcyBkcmFmdCB3YXMgYmFzZWQuICBHZW9mZnJl eSBIdWFuZywgU3VyZXNoIE1lbGFtLCBQcmF2ZWVuDQogICBTYXRoeWFuYXJheWFuLCBBbmRyZWFz IFN0ZWZmZW4sIEJyaWFuIFdlaXMsIGFuZCBMb3UgQmVyZ2VyIHByb3ZpZGVkDQogICBlc3NlbnRp YWwgaW5wdXQuDQoNCjguICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJy YWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAg ICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3 Lg0KDQogICBbUkZDNDMwMV0gIEtlbnQsIFMuIGFuZCBLLiBTZW8sICJTZWN1cml0eSBBcmNoaXRl Y3R1cmUgZm9yIHRoZQ0KICAgICAgICAgICAgICBJbnRlcm5ldCBQcm90b2NvbCIsIFJGQyA0MzAx LCBEZWNlbWJlciAyMDA1Lg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgU3RldmUgSGFubmEN CiAgIEp1bmlwZXIgTmV0d29ya3MsIEluYy4NCiAgIDExOTQgTi4gTWF0aGlsZGEgQXZlLg0KICAg U3Vubnl2YWxlLCBDQSAgOTQwODkNCiAgIFVTQQ0KDQogICBFbWFpbDogc2hhbm5hQGp1bmlwZXIu bmV0DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDA1LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAgICAgICBKdW5l IDIwMTMNCg0KDQogICBWaXNod2FzIE1hbnJhbA0KICAgSGV3bGV0dC1QYWNrYXJkIENvLg0KICAg MTkxMTEgUHJ1bmVyaWRnZSBBdmUuDQogICBDdXBlcnRpbm8sIENBICA5NTExMw0KICAgVVNBDQoN CiAgIEVtYWlsOiB2aXNod2FzLm1hbnJhbEBocC5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDA1LCAyMDEzICAg ICAgICAgICAgICAgW1BhZ2UgMTJd --089e013a011c44f97604de434e3d-- From praveenys@juniper.net Mon Jun 3 17:56:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4521F8CB5 for ; Mon, 3 Jun 2013 17:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc2CVfTHYur3 for ; Mon, 3 Jun 2013 17:55:54 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6B64E21E80E7 for ; Mon, 3 Jun 2013 17:23:14 -0700 (PDT) Received: from mail13-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE013.bigfish.com (10.3.207.135) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Jun 2013 00:23:13 +0000 Received: from mail13-am1 (localhost [127.0.0.1]) by mail13-am1-R.bigfish.com (Postfix) with ESMTP id 022641600D0 for ; Tue, 4 Jun 2013 00:23:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zf7Iz98dI9371Ic85fh1dbaI4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL18c673h8275bh8275dhz31h2a8h683h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1155h) Received-SPF: softfail (mail13-am1: transitioning domain of juniper.net does not designate 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=praveenys@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1 (MessageSwitch) id 137030539091594_3352; Tue, 4 Jun 2013 00:23:10 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.243]) by mail13-am1.bigfish.com (Postfix) with ESMTP id 1461EA008E for ; Tue, 4 Jun 2013 00:23:10 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Jun 2013 00:23:09 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 3 Jun 2013 17:23:07 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 3 Jun 2013 17:23:07 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 3 Jun 2013 17:34:44 -0700 Received: from mail208-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Jun 2013 00:23:06 +0000 Received: from mail208-va3 (localhost [127.0.0.1]) by mail208-va3-R.bigfish.com (Postfix) with ESMTP id 10480720988 for ; Tue, 4 Jun 2013 00:23:06 +0000 (UTC) Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3 (MessageSwitch) id 1370305383167877_13655; Tue, 4 Jun 2013 00:23:03 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.225]) by mail208-va3.bigfish.com (Postfix) with ESMTP id 25EB5D4007F; Tue, 4 Jun 2013 00:23:03 +0000 (UTC) Received: from BLUPRD0511HT005.namprd05.prod.outlook.com (157.56.232.213) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Jun 2013 00:23:02 +0000 Received: from BLUPRD0511MB413.namprd05.prod.outlook.com ([169.254.6.30]) by BLUPRD0511HT005.namprd05.prod.outlook.com ([10.255.135.168]) with mapi id 14.16.0311.000; Tue, 4 Jun 2013 00:23:02 +0000 From: Praveen Sathyanarayan To: Vishwas Manral Thread-Topic: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt Thread-Index: AQHOSncSTL2I0J2F6E6l8VJM+XdQ2ZkkTboAgAAbUQA= Date: Tue, 4 Jun 2013 00:23:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.255.135.132] Content-Type: multipart/alternative; boundary="_000_CDD27E3050B78praveenysjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CHECKPOINT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%H3C.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%VPNC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: IPsecme WG , "maoyu@h3c.com" , Yoav Nir , Paul Hoffman , Toby Mao Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 00:56:12 -0000 --_000_CDD27E3050B78praveenysjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Vishwas, I understand the use of QOS and I do think it would be a nice feature. But = I am trying to see how this is specific to AD-VPN. I feel this is applicabl= e for regular VPN as well (in Hub and Spoke topology or any type of topolog= y). AD-VPN is about auto-discovering spokes/gateway/entity and establishin= g a direct connectivity. To me AD-VPN is, an extension to existing IPSec so= lution. So, IMO, QoS requirement should be solved out side of AD-VPN. What do you think? -- Praveen From: Vishwas Manral = > Date: Monday, June 3, 2013 8:45 AM To: Praveen Sathyanarayan > Cc: Toby Mao >, Yoav Nir >, IPsecme WG >, "maoyu@h3c.com" >, Paul Hoffman > Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf= -ipsecme-ad-vpn-problem-06.txt Hi Praveen, I think the idea is to be able to have QoS in a way that the traffic from o= ne spoke cannot overwhelm the Hub and lead to issues there. We need to main= tain QoS policies per spoke (or spoke type) on the Hub, as well as to be ab= le to push some QoS policies to the spokes from the Hub. Do I make sense? Thanks, Vishwas On Mon, May 6, 2013 at 9:30 AM, Praveen Sathyanarayan > wrote: Hi Toby, When you say QoS policy, could you elaborate what it really means? I mean w= hat kind of information does it need to have or exchanged? -- Praveen From: Toby Mao > Date: Sunday, May 5, 2013 8:49 AM To: Yoav Nir > Cc: IPsecme WG >, "maoyu@h3c.com" >, Paul Hoffman > Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf= -ipsecme-ad-vpn-problem-06.txt Hi Yoav. The QoS implementations in ADVPN are : 1. In the star topology, the QoS policy is implemented individually= for each spoke in the hub, all the traffic through the Hub can be regulate= d by QoS policy in the hub. 2. In the full mesh topology, when the two spokes establish the dire= ct connection, each spoke should also have the QoS policy for each other. T= he QoS policy can be obtained from the Hub, or other control device , whic= h has the individual QoS policy for each spoke. I think your understanding is the same as the QoS implementation in the ful= l mesh topology. Toby On Fri, May 3, 2013 at 4:11 AM, Yoav Nir > wrote: Hi Toby. Let's see if I understand the issue. I'll describe this with an example. Pl= ease let me know if I got it. Suppose we have satellite gateways A, B, C, D, and E. A through D each have= a bandwidth of 10 Mb/s, while E has 20 Mb/s. The center gateway, Z, has plenty of bandwidth and the appropriate QoS poli= cy. So if A, B, and C are simultaneously sending traffic to E through Z, Z = will do the QoS magic (maybe by dropping packets or playing with TCP ACKs) = to make sure the QoS goals are met. Now add ADVPN to the mix. A and E discover each other, and are able to bypa= ss Z. Initially A had no IPsec policy about E. There's no reason to think i= t had a QoS policy about E, and the same is true in the other direction. Un= less the QoS policy from Z somehow gets transmitted to the satellites, they= may reach congestion and have the QoS targets miss. So whereas before ADVPN the center gateway could be counted on to handle th= e QoS (because everything goes through it), as soon as you add ADVPN, that = policy has to be enforced on the spokes, or not at all. I'm not sure whether we can or should solve this issue as part of AD-VPN, b= ut I want to make sure that we understand the issue. Yoav On May 2, 2013, at 6:02 PM, Toby Mao > wrote: On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman > wrote: These requirements might be useful to add in the next draft, but they need = to be refined. On Apr 26, 2013, at 8:10 PM, Toby Mao > wrote: > The ADVPN solution SHOULD be able to implement Quality of Service (QoS) t= o regulate the traffic in the ADVPN topology. Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN? [Toby]: There is no situation that ADVPN solution could be prevented from = implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing networ= k bandwidth, meeting the application latency requirement. Especially in the= Hub, for each spoke, the Qos policy should be implemented individually , b= ecause different spoke has different link speed and data processing capabil= ity. Thus, in the ADVPN solution, the small spoke can not be overrun by hub= by sending too much traffic, also the spoke which has large bandwidth cann= ot hog the hub's resources and starve other spokes. In addition, a unique Q= os policy for each spoke in the hub could be cumbersome for administrator, = some improvement could be implemented, such as the spokes with the same ban= dwidth can belong to the same group, the Qos policy can be implemented on a= basis of group. > ADVPN peer SHOULD NOT send excessive traffic to the other members of ADVP= N. How would you define "excessive"? Where would that measurement be done? [Toby] The traffic to the ADVPN peer exceeding the actual peer bandwidth c= an be defined as "excessive". To solve this problem, the other ADVPN peer s= hould apply Qos policy for this ADVPN peer. > The traffic for each ADVPN peer CAN be measured individually for shaping = and policing. Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually? [Toby] The reason is explained in the first answer. --Paul Hoffman Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_CDD27E3050B78praveenysjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <0AE6BA4AE537B740A62D9931B83BFC7F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
HI Vishwas,

I understand the use of QOS and I do think it would be a nice feature.= But I am trying to see how this is specific to AD-VPN. I feel this is appl= icable for regular VPN as well (in Hub and Spoke topology or any type of to= pology).  AD-VPN is about auto-discovering spokes/gateway/entity and establishing a direct connectivity. To me AD-VPN= is, an extension to existing IPSec solution.  So, IMO, QoS requiremen= t should be solved out side of AD-VPN. 

What do you think?

-- Praveen

From: Vishwas Manral <vishwas.ietf@gmail.com>
Date: Monday, June 3, 2013 8:45 AM<= br> To: Praveen Sathyanarayan <praveenys@juniper.net>
Cc: Toby Mao <yumao9@gmail.com>, Yoav Nir <ynir@checkpoint.com>, IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3c.com>, Paul Hoffman &= lt;paul.hoffman@vpnc.org> Subject: Re: [IPsec] One comment to= this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

Hi Praveen,
 
I think the idea is to be able to have QoS in a way that the traffic f= rom one spoke cannot overwhelm the Hub and lead to issues there. We need to= maintain QoS policies per spoke (or spoke type) on the Hub, as well a= s to be able to push some QoS policies to the spokes from the Hub.
 
Do I make sense?
 
Thanks,
Vishwas


On Mon, May 6, 2013 at 9:30 AM, Praveen Sathyana= rayan <praveenys@ju= niper.net> wrote:
Hi Toby,

When you say QoS policy, could you elaborate what it really means? I m= ean what kind of information does it need to have or exchanged? 

-- Praveen

From: Toby Mao <yumao9@gmail.com>
Date: Sunday, May 5, 2013 8:49 AM To: Yoav Nir <ynir@checkpoint.com>
Cc: IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3c.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [IPsec] One comment to= this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

Hi Yoav.

        &nb= sp;The QoS implementations in ADVPN are :

= 1.       <= /span> In the star topology,  the QoS= policy is implemented individually for each spoke in the hub, all the traffic through the Hub ca= n be regulated by QoS policy in the hub.

= 2.       <= /span>In the full mesh topology,  when the= two spokes establish the direct connection, each spoke should also have the QoS policy for each= other. The QoS policy can be obtained from the Hub, or other control devic= e ,  which has the individual QoS policy for each spoke.=

I think your understanding is= the same as the QoS implementation in the full mesh topology.

Toby<= /p>



On Fri, May 3, 2013 at 4:11 AM, Yoav Nir <ynir@checkpoin= t.com> wrote:
Hi Toby.

Let's see if I understand the issue. I'll describe this with an exampl= e. Please let me know if I got it.

Suppose we have satellite gateways A, B, C, D, and E. A through D each= have a bandwidth of 10 Mb/s, while E has 20 Mb/s.

The center gateway, Z, has plenty of bandwidth and the appropriate QoS= policy. So if A, B, and C are simultaneously sending traffic to E through = Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP A= CKs) to make sure the QoS goals are met.

Now add ADVPN to the mix. A and E discover each other, and are able to= bypass Z. Initially A had no IPsec policy about E. There's no reason to th= ink it had a QoS policy about E, and the same is true in the other directio= n. Unless the QoS policy from Z somehow gets transmitted to the satellites, they may reach congestion and = have the QoS targets miss. 

So whereas before ADVPN the center gateway could be counted on to hand= le the QoS (because everything goes through it), as soon as you add ADVPN, = that policy has to be enforced on the spokes, or not at all.

I'm not sure whether we can or should solve this issue as part of AD-V= PN, but I want to make sure that we understand the issue.

Yoav
 
On May 2, 2013, at 6:02 PM, Toby Mao <yumao9@gmail.com> wrote:


On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <= span dir=3D"ltr"> <paul.hoffman= @vpnc.org> wrote:
These requirements might be useful to add in the next draft, but they need = to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN?

 [Toby]: There is no situation that ADVPN solution could be prevented= from implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing = network bandwidth, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy should = be implemented individually , because different spoke has different link sp= eed and data processing capability. Thus, in the ADVPN solution, the small = spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwidth cann= ot hog the hub's resources and starve other spokes. In addition, a unique Q= os policy for each spoke in the hub could be cumbersome for administrator, = some improvement could be implemented, such as the spokes with the same bandwidth can belong to the same group, t= he Qos policy can be implemented on a basis of group.

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurement be= done?
 
[Tob= y]  The traffic to the ADVPN peer exceeding the actual peer bandwidth = can be defined as "excessive". To solve this problem, the other A= DVPN peer should apply Qos policy for this ADVPN peer. 

> The traffic for each ADVPN peer CAN be measured individually for = shaping and policing.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually?
 
[Tob= y]  The reason is explained in the first answer. 

--Paul Hoffman



Email secured by Check Point

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


 --_000_CDD27E3050B78praveenysjunipernet_-- From internet-drafts@ietf.org Tue Jun 4 15:17:36 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8DF21F99B6; Tue, 4 Jun 2013 15:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzje6lm51KsD; Tue, 4 Jun 2013 15:17:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1E521F99B1; Tue, 4 Jun 2013 15:17:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130604221735.30683.21016.idtracker@ietfa.amsl.com> Date: Tue, 04 Jun 2013 15:17:35 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 22:17:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Additional Diffie-Hellman Tests for IKEv2 Author(s) : Yaron Sheffer Scott Fluhrer Filename : draft-ietf-ipsecme-dh-checks-05.txt Pages : 11 Date : 2013-06-04 Abstract: This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-dh-checks-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Tue Jun 4 15:56:58 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E06621F99E6 for ; Tue, 4 Jun 2013 15:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXDnrsop84ra for ; Tue, 4 Jun 2013 15:56:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 52D5621F99BF for ; Tue, 4 Jun 2013 15:56:51 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r54MunO4039959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Jun 2013 15:56:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jun 2013 15:56:48 -0700 References: To: IPsecme WG Message-Id: <8FA5978D-5E6D-4111-B687-FA00D8EBDF90@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [IPsec] Fwd: Hugh Daniel has passed away X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 22:56:58 -0000 This is off-topic, but important historically. Hugh participated in the = IETF's early standardization of IPsec both as an active implementer and = as an agitator. Begin forwarded message: > From: Paul Wouters > Subject: Hugh Daniel has passed away > Date: June 4, 2013 3:32:56 PM PDT > To: ietf@ietf.org >=20 >=20 > Hugh Daniel passed away on June 3rd after what appears to have been a = heart attack. >=20 > https://nohats.ca/hugh-of-borg.jpg >=20 >=20 > Those who met him, know him. Principled to the core, and very present = in > any room, he compelled people to listen to him - both by what he said, > and how loud he said it. >=20 > He has made many contributions during the early days of IPsec and > DNSSEC. He was a manager of the FreeS/WAN Project for many years and > co-founder of The Openswan Project and recently The Libreswan Project, > although his health prevented him from being as active and he wanted = to > be in the last two years. >=20 > I met him for the first time at the CCC summer conference in 1999. Our > car had broken down, and everyone around me suggested to find Hugh = Daniel > for help. He shone his freeswan photon light under the car, diagnosed > the problem, and put in a quick fix we could carefully drive to a = repair > shop at 5km/h where we could tell the mechanic what to fix. We started > talking about Linux, crypto and he recruited me for the FreeS/WAN and > the goal to make the default mode of the internet encrypted. It is = what > started me on IPsec, Opportunistic Encryption and DNS(SEC). In 2003, > he brought me to my first IETF in Vienna. >=20 > Hugh, you are still causing a difference and we will raise a = non-aloholic > drink in your honour when we have reached the universal deployment > of encrypted communication for everything. >=20 >=20 >=20 > "When you're NAT on the net, you're NOT on the net" -- Hugh = Daniel >=20 From cmadson@cisco.com Tue Jun 4 17:27:34 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9355921F9A10 for ; Tue, 4 Jun 2013 17:27:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqLVBz-DC39k for ; Tue, 4 Jun 2013 17:27:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4F17221F9798 for ; Tue, 4 Jun 2013 17:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2952; q=dns/txt; s=iport; t=1370392048; x=1371601648; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jfgVDCvUKvSdSiuaX1JtlHJUA0GhaZip+bpQ0yyD7kE=; b=SPQYjTxjmNbg6vV/WtJCgZLKqowuw067ZdyIU6j/rja3mTAHJWKGIXf+ +9EmTyytWf0hzN/W3ltGhXhpk7iE/2lhBDndPKn9/d2qte0GIynfNGA1S n76Idg4GB6KSpIFhzSzBJD93ViRNaxbGqXX8f82ffBED3OY+OFa6nWNtp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAMOErlGtJV2Z/2dsb2JhbABagwkwvyp+FnSCIwEBAQMBAQEBNy4GCwULAgEIEQMBAgsUECcLHQgCBA4FCId/Bgy9dQSOcQIxBwaCdGEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="scan'208";a="218831098" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jun 2013 00:27:24 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r550ROjK015931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 00:27:24 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.14]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 19:27:24 -0500 From: "Cheryl Madson (cmadson)" To: Paul Hoffman Thread-Topic: [IPsec] Hugh Daniel has passed away Thread-Index: AQHOYYNzukBonyz3QEOoLY0aTb8YqA== Date: Wed, 5 Jun 2013 00:27:24 +0000 Message-ID: <0FDA7A60733CE34F898D186F0DDAAEF91375F3D9@xmb-rcd-x08.cisco.com> References: <8FA5978D-5E6D-4111-B687-FA00D8EBDF90@vpnc.org> In-Reply-To: <8FA5978D-5E6D-4111-B687-FA00D8EBDF90@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <8E2D82A2DDF16646BF24F543A2CFC3EE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cheryl Madson \(cmadson\)" , IPsecme WG Subject: Re: [IPsec] Hugh Daniel has passed away X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 00:27:34 -0000 Wow... I'm shocked.=20 Hugh had a big impact on the early IPsec standards. We didn't always agree,= to say the least,=20 but he did help to make IPsec a better protocol. He also contributed to sev= eral other WGs.=20 =20 You couldn't help but appreciate how he stuck to his principles, even when = it was very=20 inconvenient for him.=20 He tried hard to contribute towards organizations that could make a differe= nce. I know he worked=20 with EFF, and I recall him talking about working with human rights groups i= n Guatemala.=20 I hadn't heard from him in years, but I did run into him a year ago at a fo= lk festival. He sounded pretty much the same old Hugh at that time. =20 RIP, Hugh. thx - C On Jun 4, 2013, at 3:56 PM, Paul Hoffman wrote: > This is off-topic, but important historically. Hugh participated in the I= ETF's early standardization of IPsec both as an active implementer and as a= n agitator. >=20 > Begin forwarded message: >=20 >> From: Paul Wouters >> Subject: Hugh Daniel has passed away >> Date: June 4, 2013 3:32:56 PM PDT >> To: ietf@ietf.org >>=20 >>=20 >> Hugh Daniel passed away on June 3rd after what appears to have been a he= art attack. >>=20 >> https://nohats.ca/hugh-of-borg.jpg >>=20 >>=20 >> Those who met him, know him. Principled to the core, and very present in >> any room, he compelled people to listen to him - both by what he said, >> and how loud he said it. >>=20 >> He has made many contributions during the early days of IPsec and >> DNSSEC. He was a manager of the FreeS/WAN Project for many years and >> co-founder of The Openswan Project and recently The Libreswan Project, >> although his health prevented him from being as active and he wanted to >> be in the last two years. >>=20 >> I met him for the first time at the CCC summer conference in 1999. Our >> car had broken down, and everyone around me suggested to find Hugh Danie= l >> for help. He shone his freeswan photon light under the car, diagnosed >> the problem, and put in a quick fix we could carefully drive to a repair >> shop at 5km/h where we could tell the mechanic what to fix. We started >> talking about Linux, crypto and he recruited me for the FreeS/WAN and >> the goal to make the default mode of the internet encrypted. It is what >> started me on IPsec, Opportunistic Encryption and DNS(SEC). In 2003, >> he brought me to my first IETF in Vienna. >>=20 >> Hugh, you are still causing a difference and we will raise a non-aloholi= c >> drink in your honour when we have reached the universal deployment >> of encrypted communication for everything. >>=20 >>=20 >>=20 >> "When you're NAT on the net, you're NOT on the net" -- Hugh Daniel >>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From iesg-secretary@ietf.org Wed Jun 5 07:46:34 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3246721F9B11; Wed, 5 Jun 2013 07:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN8gvTsIKtGo; Wed, 5 Jun 2013 07:46:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E985F21F9B13; Wed, 5 Jun 2013 07:46:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130605144632.18949.78362.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2013 07:46:32 -0700 Cc: ipsecme mailing list , ipsecme chair , RFC Editor Subject: [IPsec] Protocol Action: 'Additional Diffie-Hellman Tests for IKEv2' to Proposed Standard (draft-ietf-ipsecme-dh-checks-05.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:46:34 -0000 The IESG has approved the following document: - 'Additional Diffie-Hellman Tests for IKEv2' (draft-ietf-ipsecme-dh-checks-05.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks/ Technical Summary The document corrects a problem found well after RFC 5996 was published. Implementations that support elliptic curves and DSA, and also reuse private keys, are vulnerable to some attacks that can be prevented by some simple checking. This document specifies the circumstances where the attack might happen and how to prevent them. Working Group Summary The document was reviewed by enough active developers and cryptographically-inclined participants to be sufficient for Standards Track. There is definite consensus to publish. Document Quality This document is appropriate for Standards Track because, if the attack had been known and understood when RFC 5996 was written, it would certainly have been part of that document. Personnel Paul Hoffman is the shepherd. Sean Turner is the AD. From david.black@emc.com Wed Jun 5 13:30:49 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFED21F9A95 for ; Wed, 5 Jun 2013 13:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+Gq0arj8KnN for ; Wed, 5 Jun 2013 13:30:44 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BD3E521F9A69 for ; Wed, 5 Jun 2013 13:30:44 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r55KUio8011176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Jun 2013 16:30:44 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 5 Jun 2013 16:30:33 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r55KUXmj023222 for ; Wed, 5 Jun 2013 16:30:33 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Wed, 5 Jun 2013 16:30:33 -0400 From: "Black, David" To: IPsecme WG Date: Wed, 5 Jun 2013 16:30:32 -0400 Thread-Topic: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt Thread-Index: Ac5iJnGtVfuFKI0HT/ehgqMorrQ4NgABFdaQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712980C9E82@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_8D3D17ACE214DC429325B2B98F3AE712980C9E82MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:30:49 -0000 --_003_8D3D17ACE214DC429325B2B98F3AE712980C9E82MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - this draft is likely to move fairly quickly, with both WG Last Call and the publication request that hands off draft from the WG to the AD happening before the Berlin IETF meetings. WG Last Call in the storm WG is expected to start next week. Thanks, --David -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, June 05, 2013 3:51 PM To: i-d-announce@ietf.org Cc: storm@ietf.org Subject: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt A new Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the I= ETF. Title : IP Storage: IPsec Requirements Update for IPsec v3 Author(s) : D. Black, et al Filename : draft-ietf-storm-ipsec-ips-update Pages : 13=20 Date : June 5, 2013=20 =20 RFC 3723 includes requirements for IPsec usage with IP Storage protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs). This document updates those requirements to IPsec v3 (RFC 4301 and related RFCs) and updates implementation requirements to reflect developments in cryptography since RFC 3723 was published. [RFC Editor: The "Updates:" list above has been truncated by x= ml2rfc. The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if approved) ] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-00.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --_003_8D3D17ACE214DC429325B2B98F3AE712980C9E82MX15Acorpemccom_ Content-Type: message/external-body; name="draft-ietf-storm-ipsec-ips-update.url" Content-Description: draft-ietf-storm-ipsec-ips-update.url Content-Disposition: attachment; filename="draft-ietf-storm-ipsec-ips-update.url"; size=94; creation-date="Wed, 05 Jun 2013 19:54:09 GMT"; modification-date="Wed, 05 Jun 2013 19:54:09 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXN0b3JtLWlwc2VjLWlwcy11cGRhdGUNCg== --_003_8D3D17ACE214DC429325B2B98F3AE712980C9E82MX15Acorpemccom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=258; creation-date="Wed, 05 Jun 2013 19:54:09 GMT"; modification-date="Wed, 05 Jun 2013 19:54:09 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_8D3D17ACE214DC429325B2B98F3AE712980C9E82MX15Acorpemccom_-- From dharkins@lounge.org Wed Jun 5 15:54:23 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E643821F9927 for ; Wed, 5 Jun 2013 15:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFgQk6h5fR77 for ; Wed, 5 Jun 2013 15:54:18 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D5C6A21F9798 for ; Wed, 5 Jun 2013 15:54:18 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7CD0CA888008; Wed, 5 Jun 2013 15:54:16 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Jun 2013 15:54:16 -0700 (PDT) Message-ID: <363c95eefb25891779c519d724e56ee8.squirrel@www.trepanning.net> In-Reply-To: <8FA5978D-5E6D-4111-B687-FA00D8EBDF90@vpnc.org> References: <8FA5978D-5E6D-4111-B687-FA00D8EBDF90@vpnc.org> Date: Wed, 5 Jun 2013 15:54:16 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" 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 Cc: IPsecme WG Subject: Re: [IPsec] Fwd: Hugh Daniel has passed away X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:54:23 -0000 That is certainly sad news. He brought a unique insight as well as a unique sense of humor to the process. RIP Hugh. Dan. On Tue, June 4, 2013 3:56 pm, Paul Hoffman wrote: > This is off-topic, but important historically. Hugh participated in the > IETF's early standardization of IPsec both as an active implementer and as > an agitator. > > Begin forwarded message: > >> From: Paul Wouters >> Subject: Hugh Daniel has passed away >> Date: June 4, 2013 3:32:56 PM PDT >> To: ietf@ietf.org >> >> >> Hugh Daniel passed away on June 3rd after what appears to have been a >> heart attack. >> >> https://nohats.ca/hugh-of-borg.jpg >> >> >> Those who met him, know him. Principled to the core, and very present in >> any room, he compelled people to listen to him - both by what he said, >> and how loud he said it. >> >> He has made many contributions during the early days of IPsec and >> DNSSEC. He was a manager of the FreeS/WAN Project for many years and >> co-founder of The Openswan Project and recently The Libreswan Project, >> although his health prevented him from being as active and he wanted to >> be in the last two years. >> >> I met him for the first time at the CCC summer conference in 1999. Our >> car had broken down, and everyone around me suggested to find Hugh >> Daniel >> for help. He shone his freeswan photon light under the car, diagnosed >> the problem, and put in a quick fix we could carefully drive to a repair >> shop at 5km/h where we could tell the mechanic what to fix. We started >> talking about Linux, crypto and he recruited me for the FreeS/WAN and >> the goal to make the default mode of the internet encrypted. It is what >> started me on IPsec, Opportunistic Encryption and DNS(SEC). In 2003, >> he brought me to my first IETF in Vienna. >> >> Hugh, you are still causing a difference and we will raise a >> non-aloholic >> drink in your honour when we have reached the universal deployment >> of encrypted communication for everything. >> >> >> >> "When you're NAT on the net, you're NOT on the net" -- Hugh Daniel >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf.ietf@gmail.com Wed Jun 5 23:50:05 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788C421F9744 for ; Wed, 5 Jun 2013 23:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4gOKNUvGfJW for ; Wed, 5 Jun 2013 23:50:04 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 36A1021F8E12 for ; Wed, 5 Jun 2013 23:50:04 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id c4so1023760eek.15 for ; Wed, 05 Jun 2013 23:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sKSOS1aLVdJIvvhRIGQ7As8DLaSAfigrj8zd5tQ20QE=; b=t9D6WrEIQHXia8JtHs1urcwkEmKIiDD05aer0EfprwnpHASTiR++0+JhmhwDh0o19s bNk9O0+h5TL2uRFFv5Qpjr1ADT3p0JkCRmLM+Cd1MgCEwXWlS/AZsBvm2KEsf37RJoCD 2KhwsfrRYufEcEx3YZmYOBYI4JzLYk7hUqc+GwCh6qYPy3AHmuCaV+/rwdH6UG3nhez1 zh889otd5X6zSjWc51tVRsld09OGAaQFAi8u38kQt6GjIwUtkTq+9wP6+ODCKbPibGvv x/0Wx4K1Orx9S52bAmqjs8Fb0LJFmdtloY3NMX5o+gSocr3YqbIoFBRqbjfilh6bkSiF 6vOQ== X-Received: by 10.15.53.196 with SMTP id r44mr14030981eew.136.1370501403283; Wed, 05 Jun 2013 23:50:03 -0700 (PDT) Received: from [10.0.0.14] (93-173-148-105.bb.netvision.net.il. [93.173.148.105]) by mx.google.com with ESMTPSA id s8sm103925959eeo.4.2013.06.05.23.50.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 23:50:02 -0700 (PDT) Message-ID: <51B021E1.102@gmail.com> Date: Thu, 06 Jun 2013 08:45:05 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE712980C9E82@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980C9E82@MX15A.corp.emc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IPsecme WG Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 06:50:05 -0000 Hi David, • The ref for AES-GMAC is RFC 3543, should be 4543. • 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption? • The separation of GMAC and CTR, when we really want the combined-mode GCM, is very confusing. • 3: why no must-implement DH group? Also, "when DH groups are used" - are there any cases when they're not? • 3.1: I would expect a discussion here about correlation between IKE identity and the application protocol. E.g. are target names used as IKEv2 ID values? This probably makes more sense when iSCSI discovery is being used. • 3.1: (shameless plug...) instead of certs, PACE with an automatically generated PSK would be so much more convenient... See RFC 6631, Sec. 3.5+3.6. But of course it is only experimental, sigh. Thanks, Yaron On 2013-06-05 23:30, Black, David wrote: > FYI - this draft is likely to move fairly quickly, with both > WG Last Call and the publication request that hands off draft from > the WG to the AD happening before the Berlin IETF meetings. > > WG Last Call in the storm WG is expected to start next week. > > Thanks, > --David > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, June 05, 2013 3:51 PM > To: i-d-announce@ietf.org > Cc: storm@ietf.org > Subject: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt > > A new Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the STORage Maintenance Working Group of the IETF. > > Title : IP Storage: IPsec Requirements Update for IPsec v3 > Author(s) : D. Black, et al > Filename : draft-ietf-storm-ipsec-ips-update > Pages : 13 > Date : June 5, 2013 > > RFC 3723 includes requirements for IPsec usage with IP Storage > protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related > RFCs). This document updates those requirements to IPsec v3 (RFC > 4301 and related RFCs) and updates implementation requirements to > reflect developments in cryptography since RFC 3723 was published. > > [RFC Editor: The "Updates:" list above has been truncated by xml2rfc. > The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, > 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if > approved) ] > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From david.black@emc.com Thu Jun 6 05:33:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C1121F947C for ; Thu, 6 Jun 2013 05:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8t826MF8gK2 for ; Thu, 6 Jun 2013 05:33:32 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8E56F21F94DC for ; Thu, 6 Jun 2013 05:33:31 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r56CXPcA020984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 08:33:28 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 6 Jun 2013 08:33:02 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r56CX2Su008837; Thu, 6 Jun 2013 08:33:02 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Thu, 6 Jun 2013 08:33:01 -0400 From: "Black, David" To: Yaron Sheffer Date: Thu, 6 Jun 2013 08:33:03 -0400 Thread-Topic: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt Thread-Index: Ac5ighxG/Zo5PCTcQnC9hSaqBAPKuAALgihQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712980C9F2C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712980C9E82@MX15A.corp.emc.com> <51B021E1.102@gmail.com> In-Reply-To: <51B021E1.102@gmail.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-EMM-MHVC: 1 Cc: IPsecme WG , "Black, David" Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 12:33:37 -0000 Hi Yaron, Thank you for the quick review. > * The ref for AES-GMAC is RFC 3543, should be 4543. That's embarrassing - not just off-by-1, but off-by-1000 :-). I will definitely fix that in the -01. > * 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption? > * The separation of GMAC and CTR, when we really want the combined-mode > GCM, is very confusing. See the end of 2.2. AES CTR changes from MAY to SHOULD, and there's a SHOU= LD for AES GCM. I'll add a sentence after the two bullets at the start of 2.2 to make it clear that both requirements are being changed. > * 3: why no must-implement DH group? Also, "when DH groups are used" - > are there any cases when they're not? I left the must-implement DH groups to the underlying IPsec specs; is it important to repeat that here? For no DH group, see IKEv1 Quick Mode without perfect forward secrecy, and I need to add a sentence requiring PFS to be implemented for that case. Text suggestions are welcome. > * 3.1: I would expect a discussion here about correlation between IKE > identity and the application protocol. E.g. are target names used as > IKEv2 ID values? This probably makes more sense when iSCSI discovery is > being used. That belongs in an iSCSI-specific doc; this draft is generic to a number of IP Storage protocols - e.g., iSCSI, FCIP, iFCP. > * 3.1: (shameless plug...) instead of certs, PACE with an automatically > generated PSK would be so much more convenient... See RFC 6631, Sec. > 3.5+3.6. But of course it is only experimental, sigh. Plug noted ;-). Independently, FWIW, if there had not been IPR complicatio= ns at the time, SRP would have been the mandatory-to-implement inband authentication mechanism for iSCSI (in the main iSCSI doc, not here). Thanks, --David > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Thursday, June 06, 2013 1:45 AM > To: Black, David > Cc: IPsecme WG > Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.= txt >=20 > Hi David, >=20 > * The ref for AES-GMAC is RFC 3543, should be 4543. > * 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption? > * The separation of GMAC and CTR, when we really want the combined-mode > GCM, is very confusing. > * 3: why no must-implement DH group? Also, "when DH groups are used" - > are there any cases when they're not? > * 3.1: I would expect a discussion here about correlation between IKE > identity and the application protocol. E.g. are target names used as > IKEv2 ID values? This probably makes more sense when iSCSI discovery is > being used. > * 3.1: (shameless plug...) instead of certs, PACE with an automatically > generated PSK would be so much more convenient... See RFC 6631, Sec. > 3.5+3.6. But of course it is only experimental, sigh. >=20 > Thanks, > Yaron >=20 > On 2013-06-05 23:30, Black, David wrote: > > FYI - this draft is likely to move fairly quickly, with both > > WG Last Call and the publication request that hands off draft from > > the WG to the AD happening before the Berlin IETF meetings. > > > > WG Last Call in the storm WG is expected to start next week. > > > > Thanks, > > --David > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.o= rg] > On Behalf Of Internet-Drafts@ietf.org > > Sent: Wednesday, June 05, 2013 3:51 PM > > To: i-d-announce@ietf.org > > Cc: storm@ietf.org > > Subject: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt > > > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the STORage Maintenance Working Group of t= he > IETF. > > > > Title : IP Storage: IPsec Requirements Update for IPsec v3 > > Author(s) : D. Black, et al > > Filename : draft-ietf-storm-ipsec-ips-update > > Pages : 13 > > Date : June 5, 2013 > > > > RFC 3723 includes requirements for IPsec usage with IP Storage > > protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related > > RFCs). This document updates those requirements to IPsec v3 (RFC > > 4301 and related RFCs) and updates implementation requirements to > > reflect developments in cryptography since RFC 3723 was published. > > > > [RFC Editor: The "Updates:" list above has been truncated= by > xml2rfc. > > The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, > > 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (i= f > > approved) ] > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-0= 0.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > From yumao9@gmail.com Thu Jun 6 08:31:30 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E70021F99AF for ; Thu, 6 Jun 2013 08:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrfPqy2Kh85N for ; Thu, 6 Jun 2013 08:31:28 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED4221F999E for ; Thu, 6 Jun 2013 08:31:28 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id 9so7585571iec.27 for ; Thu, 06 Jun 2013 08:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=65puN6F+D3lYWM9DxNzjrgN5savfmwamYyLwViixPDU=; b=tO8XpjNdBYgkK9F3f9tlXK8NgCRTQ8ULeIoUYCtx9qGfvObfquFw5HyQZNd7m6YyL1 W9GAGFszAS+cflGXiXA1P65XbI+55utCfC8oSLyw0DE5/LouI3dsqJKDAHieUkMC9XKj dB4UZhkIETAreCOqrXR9dMHzCufeFO41v/aYN4FKhhj2AX9OjwJdiVUHKr56NatIDlqg ozK8ie15kGHCtbyO1h0dPIDCvKfEFWCJ3Ai97PIxg56oM8OPvJgn+DcEpTkS/r+56qfM NPqLzo3SWjTl+BGyyFlfsY/ZgaBVsm92J/Uy5+qEiW3pBx1PQ48yVLqP7fOIGFEEvjvN 3S0A== MIME-Version: 1.0 X-Received: by 10.50.61.141 with SMTP id p13mr6036000igr.9.1370532687757; Thu, 06 Jun 2013 08:31:27 -0700 (PDT) Received: by 10.43.168.4 with HTTP; Thu, 6 Jun 2013 08:31:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 23:31:27 +0800 Message-ID: From: Toby Mao To: Praveen Sathyanarayan Content-Type: multipart/alternative; boundary=047d7bd6bfee01c8a704de7e0283 Cc: IPsecme WG , Yoav Nir , Paul Hoffman , "maoyu@h3c.com" Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 15:31:30 -0000 --047d7bd6bfee01c8a704de7e0283 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Praveen: I agree the primary goal of ADVPN solution is to establish the direct connectivity in the full mesh topology. However, in the draft-ietf-ipsecme-ad-vpn-problem, there are some requirements such as multicast, L3VPN, etc. which seems to =93not so important=94 in the ADVPN, = but also need to be defined . The use of QoS is this case. In the current IPsec VPN solution for Hub-Spoke topology and full-mesh topology, we need to maintain QoS policy per peer. This QoS policy usually defines the traffic policing, general traffic shaping or rate limit control. In the Hub-Spoke topology, the QoS policy for the spoke can be effective because all the traffic go through the hub. In the ADVPN, if spoke A obtains the spoke B=92s information, such as peer address, route information etc. to establish the direct connectivity, the QoS policy for this spoke should also be included if needed. Thus, after the connection is setup, the traffic from Spoke A to Spoke B can not be overrun. The new requirement 15 added in the updated draft is ok for me. Regard, Toby On Tue, Jun 4, 2013 at 8:23 AM, Praveen Sathyanarayan wrote: > HI Vishwas, > > I understand the use of QOS and I do think it would be a nice feature. > But I am trying to see how this is specific to AD-VPN. I feel this is > applicable for regular VPN as well (in Hub and Spoke topology or any type > of topology). AD-VPN is about auto-discovering spokes/gateway/entity and > establishing a direct connectivity. To me AD-VPN is, an extension to > existing IPSec solution. So, IMO, QoS requirement should be solved out > side of AD-VPN. > > What do you think? > > -- Praveen > > From: Vishwas Manral > Date: Monday, June 3, 2013 8:45 AM > To: Praveen Sathyanarayan > Cc: Toby Mao , Yoav Nir , IPsecme > WG , "maoyu@h3c.com" , Paul Hoffman < > paul.hoffman@vpnc.org> > > Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: > draft-ietf-ipsecme-ad-vpn-problem-06.txt > > Hi Praveen, > > I think the idea is to be able to have QoS in a way that the traffic from > one spoke cannot overwhelm the Hub and lead to issues there. We need to > maintain QoS policies per spoke (or spoke type) on the Hub, as well as to > be able to push some QoS policies to the spokes from the Hub. > > Do I make sense? > > Thanks, > Vishwas > > > On Mon, May 6, 2013 at 9:30 AM, Praveen Sathyanarayan < > praveenys@juniper.net> wrote: > >> Hi Toby, >> >> When you say QoS policy, could you elaborate what it really means? I >> mean what kind of information does it need to have or exchanged? >> >> -- Praveen >> >> From: Toby Mao >> Date: Sunday, May 5, 2013 8:49 AM >> To: Yoav Nir >> Cc: IPsecme WG , "maoyu@h3c.com" , Paul >> Hoffman >> Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: >> draft-ietf-ipsecme-ad-vpn-problem-06.txt >> >> Hi Yoav. >> >> The QoS implementations in ADVPN are : >> >> 1. In the star topology, the QoS policy is implemented >> individually for each spoke in the hub, all the traffic through the Hub = can >> be regulated by QoS policy in the hub. >> >> 2. In the full mesh topology, when the two spokes establish the >> direct connection, each spoke should also have the QoS policy for each >> other. The QoS policy can be obtained from the Hub, or other control dev= ice >> , which has the individual QoS policy for each spoke. >> >> I think your understanding is the same as the QoS implementation in the >> full mesh topology. >> >> Toby >> >> >> On Fri, May 3, 2013 at 4:11 AM, Yoav Nir wrote: >> >>> Hi Toby. >>> >>> Let's see if I understand the issue. I'll describe this with an >>> example. Please let me know if I got it. >>> >>> Suppose we have satellite gateways A, B, C, D, and E. A through D each >>> have a bandwidth of 10 Mb/s, while E has 20 Mb/s. >>> >>> The center gateway, Z, has plenty of bandwidth and the appropriate QoS >>> policy. So if A, B, and C are simultaneously sending traffic to E throu= gh >>> Z, Z will do the QoS magic (maybe by dropping packets or playing with T= CP >>> ACKs) to make sure the QoS goals are met. >>> >>> Now add ADVPN to the mix. A and E discover each other, and are able to >>> bypass Z. Initially A had no IPsec policy about E. There's no reason to >>> think it had a QoS policy about E, and the same is true in the other >>> direction. Unless the QoS policy from Z somehow gets transmitted to the >>> satellites, they may reach congestion and have the QoS targets miss. >>> >>> So whereas before ADVPN the center gateway could be counted on to >>> handle the QoS (because everything goes through it), as soon as you add >>> ADVPN, that policy has to be enforced on the spokes, or not at all. >>> >>> I'm not sure whether we can or should solve this issue as part of >>> AD-VPN, but I want to make sure that we understand the issue. >>> >>> Yoav >>> >>> On May 2, 2013, at 6:02 PM, Toby Mao wrote: >>> >>> >>> On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman = wrote: >>> >>>> These requirements might be useful to add in the next draft, but they >>>> need to be refined. >>>> >>>> On Apr 26, 2013, at 8:10 PM, Toby Mao wrote: >>>> >>>> > The ADVPN solution SHOULD be able to implement Quality of Service >>>> (QoS) to regulate the traffic in the ADVPN topology. >>>> >>>> Why is this statement needed? Do you see situations where an ADVPN >>>> solution would be *prevented* from implementing some sort of QoS becau= se it >>>> was an ADVPN? >>>> >>> >>> [Toby]: There is no situation that ADVPN solution could be prevented >>> from implementing Qos. Actually, Qos is crucial on ADVPN, such as shari= ng >>> network bandwidth, meeting the application latency requirement. Especia= lly >>> in the Hub, for each spoke, the Qos policy should be implemented >>> individually , because different spoke has different link speed and dat= a >>> processing capability. Thus, in the ADVPN solution, the small spoke can= not >>> be overrun by hub by sending too much traffic, also the spoke which has >>> large bandwidth cannot hog the hub's resources and starve other spokes.= In >>> addition, a unique Qos policy for each spoke in the hub could be cumber= some >>> for administrator, some improvement could be implemented, such as the >>> spokes with the same bandwidth can belong to the same group, the Qos po= licy >>> can be implemented on a basis of group. >>> >>>> >>>> > ADVPN peer SHOULD NOT send excessive traffic to the other members of >>>> ADVPN. >>>> >>>> How would you define "excessive"? Where would that measurement be don= e? >>> >>> >>> [Toby] The traffic to the ADVPN peer exceeding the actual peer >>> bandwidth can be defined as "excessive". To solve this problem, the oth= er >>> ADVPN peer should apply Qos policy for this ADVPN peer. >>> >>> > The traffic for each ADVPN peer CAN be measured individually for >>>> shaping and policing. >>>> >>>> Why is this statement needed? Do you see situations where an ADVPN >>>> solution would be *prevented* from measuring individually? >>> >>> >>> [Toby] The reason is explained in the first answer. >>> >>>> >>>> --Paul Hoffman >>> >>> >>> >>> >>> Email secured by Check Point >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --047d7bd6bfee01c8a704de7e0283 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Praveen:

=A0=A0=A0=A0=A0 I agree the primary goal of ADVPN soluti= on is to establish the direct connectivity in the full mesh topology. Howev= er, =A0in the =A0draft-ietf-ipsecme-ad-vpn-problem, =A0there are some requi= rements such as multicast, L3VPN, etc. which seems to =93not so important= =94 in the ADVPN, but also need to be defined . The use of QoS is this case= .

=A0=A0=A0 In the current IPsec VPN sol= ution for Hub-Spoke topology and full-mesh topology, we need to maintain Qo= S policy per peer. This QoS policy usually defines the traffic policing, ge= neral traffic shaping or rate limit control. In the Hub-Spoke topology, the= QoS policy for the spoke can be effective because all the traffic go throu= gh the hub.

In the ADVPN, if spoke A obtains the = spoke B=92s information, such as peer address, route information etc. to es= tablish the direct connectivity, the QoS policy for this spoke should also = =A0be included if needed. Thus, after the connection is setup, the traffic = from Spoke A to Spoke B can not be overrun.

The new requirement 15 added in the u= pdated draft is ok for me.

Regard,

Toby


On T= ue, Jun 4, 2013 at 8:23 AM, Praveen Sathyanarayan <praveenys@juniper.n= et> wrote:
HI Vishwas,

I understand the use of QOS and I do think it would be a nice feature.= But I am trying to see how this is specific to AD-VPN. I feel this is appl= icable for regular VPN as well (in Hub and Spoke topology or any type of to= pology). =A0AD-VPN is about auto-discovering spokes/gateway/entity and establishing a direct connectivity. To me AD-VPN= is, an extension to existing IPSec solution. =A0So, IMO, QoS requirement s= hould be solved out side of AD-VPN.=A0

What do you think?

-- Praveen

From: Vishwas Manral <vishwas.ietf@gmail.com>
Date: Monday, June 3, 2013 8:45 AM<= br> To: Praveen Sathyanarayan <praveenys@juniper.net= >
Cc: Toby Mao <yumao9@gmail.com>, Yoav Nir <= ynir@checkpoint.co= m>, IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3c.com&g= t;, Paul Hoffman <paul.hoffman@vpnc.org>

Subject: Re: [IPsec] One comment to= this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

Hi Praveen,
=A0
I think the idea is to be able to have QoS in a way that the traffic f= rom one spoke cannot overwhelm the Hub and lead to issues there. We need to= maintain QoS policies per spoke (or spoke type)=A0on the Hub, as well as t= o be able to push some QoS policies to the spokes from the Hub.
=A0
Do I make sense?
=A0
Thanks,
Vishwas


On Mon, May 6, 2013 at 9:30 AM, Praveen Sathyana= rayan <praveenys@ju= niper.net> wrote:
Hi Toby,

When you say QoS policy, could you elaborate what it really means? I m= ean what kind of information does it need to have or exchanged?=A0

-- Praveen

From: Toby Mao <yumao9@gmail.com>
Date: Sunday, May 5, 2013 8:49 AM To: Yoav Nir <ynir@checkpoint.com>
Cc: IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3c.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [IPsec] One comment to= this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

Hi Yoav.

=A0=A0=A0=A0=A0=A0=A0 =A0The QoS implementatio= ns in ADVPN are :

= 1.=A0=A0=A0=A0=A0=A0=A0=A0In the star topology, =A0the QoS policy is implemented individually for each spoke in the hub, all the traffic through the Hub ca= n be regulated by QoS policy in the hub.

= 2.=A0=A0=A0=A0=A0=A0=A0In the full mesh topology,=A0 when the two spokes establish the direct connection, each spoke should also have the QoS policy for each= other. The QoS policy can be obtained from the Hub, or other control devic= e , =A0which has the individual QoS policy for each spoke.

I think your understanding is= the same as the QoS implementation in the full mesh topology.

Toby<= /p>



On Fri, May 3, 2013 at 4:11 AM, Yoav Nir <ynir@checkpoin= t.com> wrote:
Hi Toby.

Let's see if I understand the issue. I'll describe this with a= n example. Please let me know if I got it.

Suppose we have satellite gateways A, B, C, D, and E. A through D each= have a bandwidth of 10 Mb/s, while E has 20 Mb/s.

The center gateway, Z, has plenty of bandwidth and the appropriate QoS= policy. So if A, B, and C are simultaneously sending traffic to E through = Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP A= CKs) to make sure the QoS goals are met.

Now add ADVPN to the mix. A and E discover each other, and are able to= bypass Z. Initially A had no IPsec policy about E. There's no reason t= o think it had a QoS policy about E, and the same is true in the other dire= ction. Unless the QoS policy from Z somehow gets transmitted to the satellites, they may reach congestion and = have the QoS targets miss.=A0

So whereas before ADVPN the center gateway could be counted on to hand= le the QoS (because everything goes through it), as soon as you add ADVPN, = that policy has to be enforced on the spokes, or not at all.

I'm not sure whether we can or should solve this issue as part of = AD-VPN, but I want to make sure that we understand the issue.

Yoav
=A0
On May 2, 2013, at 6:02 PM, Toby Mao <yumao9@gmail.com> wrote:


On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <= span dir=3D"ltr"> <paul.hoffman= @vpnc.org> wrote:
These requirements might be useful to add in the next draft, but they need = to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN?

=A0[Toby]:=A0There is no situation that ADVPN solution could be prevented from implem= enting Qos. Actually, Qos is crucial on ADVPN, such as sharing network band= width, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy should = be implemented individually , because different spoke has different link sp= eed and data processing capability. Thus, in the ADVPN solution, the small = spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwidth cann= ot hog the hub's resources and starve other spokes. In addition, a uniq= ue Qos policy for each spoke in the hub could be cumbersome for administrat= or, some improvement could be implemented, such as the spokes with the same bandwidth can belong to the same group, t= he Qos policy can be implemented on a basis of group.

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurement be= done?
=A0
[Toby] =A0= The traffic to the ADVPN peer exceeding the actual peer bandwidth can be de= fined as "excessive". To solve this problem, the other ADVPN peer= should apply Qos policy for this ADVPN peer.=A0

> The traffic for each ADVPN peer CAN be measured individually for = shaping and policing.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually?
=A0
[Toby] =A0= The reason is explained in the first answer.=A0

--Paul Hoffman



Email secured by Check Point

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--047d7bd6bfee01c8a704de7e0283-- From internet-drafts@ietf.org Thu Jun 6 10:56:23 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA59621F9B44; Thu, 6 Jun 2013 10:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsQUN0q7DyJY; Thu, 6 Jun 2013 10:56:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 049FD21F9B45; Thu, 6 Jun 2013 10:56:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130606175613.12352.13070.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 10:56:13 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:56:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-ad-vpn-problem-07.txt Pages : 12 Date : 2013-06-06 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution will address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ad-vpn-problem-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Thu Jun 6 11:12:18 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E85221F8FEC for ; Thu, 6 Jun 2013 11:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaMqk-3LSgSA for ; Thu, 6 Jun 2013 11:12:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B02E921F8470 for ; Thu, 6 Jun 2013 11:12:17 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56ICFj0035812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Jun 2013 11:12:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jun 2013 11:12:15 -0700 References: <20130606175933.11690.12046.idtracker@ietfa.amsl.com> To: IPsecme WG Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [IPsec] Fwd: Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:12:18 -0000 (See ) Begin forwarded message: > From: IETF Secretariat > Subject: Milestones changed for ipsecme WG > Date: June 6, 2013 10:59:33 AM PDT > To: "Sean Turner" , "Paul Hoffman" = , "Yaron Sheffer" >=20 > Changed milestone "WG last call on IPv6 configuration payloads", set > due date to December 2008 from December 2008. >=20 > Changed milestone "WG last call on IPsec roadmap", set due date to > December 2008 from December 2008. >=20 > Changed milestone "WG last call on session resumption", set due date > to January 2009 from January 2009. >=20 > Changed milestone "WG last call on IKEv2bis", set due date to March > 2009 from March 2009. >=20 > Changed milestone "WG last call on HA requirements", set due date to > August 2010 from August 2010. >=20 > Changed milestone "WG last call on quick crash discovery", set due > date to December 2010 from December 2010. >=20 > Changed milestone "WG last call on EAP-only authentication", set due > date to January 2011 from January 2011. >=20 > Deleted milestone "IETF Last Call on IKE over TCP". >=20 > Deleted milestone "IETF LC new mandatory-to-implement algorithms". >=20 > Deleted milestone "IETF LC out-of-band public key draft". >=20 > Changed milestone "IETF Last Call on large scale VPN use cases and > requirements", set due date to June 2013 from November 2012. >=20 > Added milestone "IETF last call on IKE fragmentation solution", due > December 2013. >=20 > Added milestone "IETF last call on new mandatory-to-implement > algorithms", due February 2014. >=20 > Changed milestone "IETF Last Call on large scale VPN protocol", set > due date to June 2014 from June 2013. >=20 > URL: http://datatracker.ietf.org/wg/ipsecme/charter/ >=20 From yaronf.ietf@gmail.com Thu Jun 6 13:59:22 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F141A11E8111 for ; Thu, 6 Jun 2013 13:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP07zHkIugHH for ; Thu, 6 Jun 2013 13:59:21 -0700 (PDT) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A585221E80E2 for ; Thu, 6 Jun 2013 13:59:00 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id jc3so1884550bkc.28 for ; Thu, 06 Jun 2013 13:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+K7THsXEJFrzqgFaMyetHq4Lg7yXTUk8LAUOajB0XOw=; b=hlPk/HX/ZR4Hwtwva10vIjjLYPs4CbS90ER4YD/aPW+q1spC31DktndaZJG+1AAMnq iJ95yfIlVfBacqAxYwFDYZOwDXC1RKWe01AHp2oERdSgT0LC5QSsBZnCPrcxHYZMmM50 ewN65d+zLNGEq7pGUOo6a54bjDpq3FP0I9PKxHMjBqM7ZQy3LaqMaCgubscdpo6sq+j9 SwDiURcr1BKJQpyABwU0G4BRbQofxoJujyku5dl92ulCmEJlJMqUcMR1Sc7SBkeufmzN SKMCz71yeGeMPjh9ySK40drxGH293pG/x+easwaesJVcFAGxqRz+EW2Ac0qGpAfB4RQ5 zuiQ== X-Received: by 10.205.46.131 with SMTP id uo3mr11470286bkb.43.1370552339168; Thu, 06 Jun 2013 13:58:59 -0700 (PDT) Received: from [10.0.0.7] ([109.65.134.210]) by mx.google.com with ESMTPSA id uh4sm28764960bkb.14.2013.06.06.13.58.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 13:58:58 -0700 (PDT) Message-ID: <51B0F811.1010602@gmail.com> Date: Thu, 06 Jun 2013 23:58:57 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE712980C9E82@MX15A.corp.emc.com> <51B021E1.102@gmail.com> <8D3D17ACE214DC429325B2B98F3AE712980C9F2C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980C9F2C@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:59:22 -0000 Hi David, please see follow up comments below. Thanks, Yaron On 2013-06-06 15:33, Black, David wrote: > Hi Yaron, > > Thank you for the quick review. > >> * The ref for AES-GMAC is RFC 3543, should be 4543. > > That's embarrassing - not just off-by-1, but off-by-1000 :-). > I will definitely fix that in the -01. > >> * 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption? >> * The separation of GMAC and CTR, when we really want the combined-mode >> GCM, is very confusing. > > See the end of 2.2. AES CTR changes from MAY to SHOULD, and there's a SHOULD > for AES GCM. I'll add a sentence after the two bullets at the start of 2.2 > to make it clear that both requirements are being changed. > >> * 3: why no must-implement DH group? Also, "when DH groups are used" - >> are there any cases when they're not? > > I left the must-implement DH groups to the underlying IPsec specs; is it > important to repeat that here? I suggest that you add something like: Requirements for DH groups and PRF are as specified in RFC 4109 (for IKEv1), RFC 4307 (for IKEv2) or any documents updating them. (That's assuming your implementers can navigate our must-minuses and should-pluses :-) > > For no DH group, see IKEv1 Quick Mode without perfect forward secrecy, > and I need to add a sentence requiring PFS to be implemented for that case. > Text suggestions are welcome. Now I'm confused: we're using DH in Quick Mode (and IKEv2 CCSA) if we want PFS. So what do you mean? > >> * 3.1: I would expect a discussion here about correlation between IKE >> identity and the application protocol. E.g. are target names used as >> IKEv2 ID values? This probably makes more sense when iSCSI discovery is >> being used. > > That belongs in an iSCSI-specific doc; this draft is generic to a number > of IP Storage protocols - e.g., iSCSI, FCIP, iFCP. > >> * 3.1: (shameless plug...) instead of certs, PACE with an automatically >> generated PSK would be so much more convenient... See RFC 6631, Sec. >> 3.5+3.6. But of course it is only experimental, sigh. > > Plug noted ;-). Independently, FWIW, if there had not been IPR complications > at the time, SRP would have been the mandatory-to-implement inband > authentication mechanism for iSCSI (in the main iSCSI doc, not here). I'm really tempted to go into a lengthy discussion of PAKE and IPR, but I'd rather not spam this list. > > Thanks, > --David > > >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Thursday, June 06, 2013 1:45 AM >> To: Black, David >> Cc: IPsecme WG >> Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt >> >> Hi David, >> >> * The ref for AES-GMAC is RFC 3543, should be 4543. >> * 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption? >> * The separation of GMAC and CTR, when we really want the combined-mode >> GCM, is very confusing. >> * 3: why no must-implement DH group? Also, "when DH groups are used" - >> are there any cases when they're not? >> * 3.1: I would expect a discussion here about correlation between IKE >> identity and the application protocol. E.g. are target names used as >> IKEv2 ID values? This probably makes more sense when iSCSI discovery is >> being used. >> * 3.1: (shameless plug...) instead of certs, PACE with an automatically >> generated PSK would be so much more convenient... See RFC 6631, Sec. >> 3.5+3.6. But of course it is only experimental, sigh. >> >> Thanks, >> Yaron >> >> On 2013-06-05 23:30, Black, David wrote: >>> FYI - this draft is likely to move fairly quickly, with both >>> WG Last Call and the publication request that hands off draft from >>> the WG to the AD happening before the Berlin IETF meetings. >>> >>> WG Last Call in the storm WG is expected to start next week. >>> >>> Thanks, >>> --David >>> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >> On Behalf Of Internet-Drafts@ietf.org >>> Sent: Wednesday, June 05, 2013 3:51 PM >>> To: i-d-announce@ietf.org >>> Cc: storm@ietf.org >>> Subject: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt >>> >>> A new Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the STORage Maintenance Working Group of the >> IETF. >>> >>> Title : IP Storage: IPsec Requirements Update for IPsec v3 >>> Author(s) : D. Black, et al >>> Filename : draft-ietf-storm-ipsec-ips-update >>> Pages : 13 >>> Date : June 5, 2013 >>> >>> RFC 3723 includes requirements for IPsec usage with IP Storage >>> protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related >>> RFCs). This document updates those requirements to IPsec v3 (RFC >>> 4301 and related RFCs) and updates implementation requirements to >>> reflect developments in cryptography since RFC 3723 was published. >>> >>> [RFC Editor: The "Updates:" list above has been truncated by >> xml2rfc. >>> The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, >>> 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if >>> approved) ] >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> > From david.black@emc.com Thu Jun 6 14:07:47 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A75D11E8121 for ; Thu, 6 Jun 2013 14:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS8mtuSM3Ax8 for ; Thu, 6 Jun 2013 14:07:42 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 308D611E8120 for ; Thu, 6 Jun 2013 14:07:41 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r56L7V2q020856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 17:07:38 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 6 Jun 2013 17:07:15 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r56L7FYD021111; Thu, 6 Jun 2013 17:07:15 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 6 Jun 2013 17:07:14 -0400 From: "Black, David" To: Yaron Sheffer Date: Thu, 6 Jun 2013 17:07:13 -0400 Thread-Topic: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt Thread-Index: Ac5i+L8IHdC5MI9GQIqqdfI73esrMQAAHueQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712980CA062@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712980C9E82@MX15A.corp.emc.com> <51B021E1.102@gmail.com> <8D3D17ACE214DC429325B2B98F3AE712980C9F2C@MX15A.corp.emc.com> <51B0F811.1010602@gmail.com> In-Reply-To: <51B0F811.1010602@gmail.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-EMM-MHVC: 1 Cc: IPsecme WG Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:07:47 -0000 Hi Yaron, > > I left the must-implement DH groups to the underlying IPsec specs; is i= t > > important to repeat that here? >=20 > I suggest that you add something like: Requirements for DH groups and > PRF are as specified in RFC 4109 (for IKEv1), RFC 4307 (for IKEv2) or > any documents updating them. (That's assuming your implementers can > navigate our must-minuses and should-pluses :-) Sure, I'll do that. > > For no DH group, see IKEv1 Quick Mode without perfect forward secrecy, > > and I need to add a sentence requiring PFS to be implemented for that c= ase. > > Text suggestions are welcome. >=20 > Now I'm confused: we're using DH in Quick Mode (and IKEv2 CCSA) if we > want PFS. So what do you mean? Sorry, I mixed two separate concepts in one sentence: - Quick mode can be used without DH when there's no key exchange and hence no PFS. That's the case in which there may be no DH involved in an IKEv1-based SA setup. - Independent of that observation, RFC 3723 contains a "MUST implement" requirement for IKEv1 PFS that ought to be repeated in this draft. I'll add that, but note that it's not a "MUST use" requirement. Thanks, --David > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Thursday, June 06, 2013 4:59 PM > To: Black, David > Cc: IPsecme WG > Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.= txt >=20 > Hi David, >=20 > please see follow up comments below. >=20 > Thanks, > Yaron >=20 > On 2013-06-06 15:33, Black, David wrote: > > Hi Yaron, > > > > Thank you for the quick review. > > > >> * The ref for AES-GMAC is RFC 3543, should be 4543. > > > > That's embarrassing - not just off-by-1, but off-by-1000 :-). > > I will definitely fix that in the -01. > > > >> * 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption? > >> * The separation of GMAC and CTR, when we really want the combined-mod= e > >> GCM, is very confusing. > > > > See the end of 2.2. AES CTR changes from MAY to SHOULD, and there's a > SHOULD > > for AES GCM. I'll add a sentence after the two bullets at the start of= 2.2 > > to make it clear that both requirements are being changed. > > > >> * 3: why no must-implement DH group? Also, "when DH groups are used" - > >> are there any cases when they're not? > > > > I left the must-implement DH groups to the underlying IPsec specs; is i= t > > important to repeat that here? >=20 > I suggest that you add something like: Requirements for DH groups and > PRF are as specified in RFC 4109 (for IKEv1), RFC 4307 (for IKEv2) or > any documents updating them. (That's assuming your implementers can > navigate our must-minuses and should-pluses :-) >=20 > > > > For no DH group, see IKEv1 Quick Mode without perfect forward secrecy, > > and I need to add a sentence requiring PFS to be implemented for that c= ase. > > Text suggestions are welcome. >=20 > Now I'm confused: we're using DH in Quick Mode (and IKEv2 CCSA) if we > want PFS. So what do you mean? >=20 > > > >> * 3.1: I would expect a discussion here about correlation between IKE > >> identity and the application protocol. E.g. are target names used as > >> IKEv2 ID values? This probably makes more sense when iSCSI discovery i= s > >> being used. > > > > That belongs in an iSCSI-specific doc; this draft is generic to a numbe= r > > of IP Storage protocols - e.g., iSCSI, FCIP, iFCP. > > > >> * 3.1: (shameless plug...) instead of certs, PACE with an automaticall= y > >> generated PSK would be so much more convenient... See RFC 6631, Sec. > >> 3.5+3.6. But of course it is only experimental, sigh. > > > > Plug noted ;-). Independently, FWIW, if there had not been IPR > complications > > at the time, SRP would have been the mandatory-to-implement inband > > authentication mechanism for iSCSI (in the main iSCSI doc, not here). >=20 > I'm really tempted to go into a lengthy discussion of PAKE and IPR, but > I'd rather not spam this list. >=20 > > > > Thanks, > > --David > > > > > >> -----Original Message----- > >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > >> Sent: Thursday, June 06, 2013 1:45 AM > >> To: Black, David > >> Cc: IPsecme WG > >> Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update- > 00.txt > >> > >> Hi David, > >> > >> * The ref for AES-GMAC is RFC 3543, should be 4543. > >> * 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption? > >> * The separation of GMAC and CTR, when we really want the combined-mod= e > >> GCM, is very confusing. > >> * 3: why no must-implement DH group? Also, "when DH groups are used" - > >> are there any cases when they're not? > >> * 3.1: I would expect a discussion here about correlation between IKE > >> identity and the application protocol. E.g. are target names used as > >> IKEv2 ID values? This probably makes more sense when iSCSI discovery i= s > >> being used. > >> * 3.1: (shameless plug...) instead of certs, PACE with an automaticall= y > >> generated PSK would be so much more convenient... See RFC 6631, Sec. > >> 3.5+3.6. But of course it is only experimental, sigh. > >> > >> Thanks, > >> Yaron > >> > >> On 2013-06-05 23:30, Black, David wrote: > >>> FYI - this draft is likely to move fairly quickly, with both > >>> WG Last Call and the publication request that hands off draft from > >>> the WG to the AD happening before the Berlin IETF meetings. > >>> > >>> WG Last Call in the storm WG is expected to start next week. > >>> > >>> Thanks, > >>> --David > >>> > >>> -----Original Message----- > >>> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf= .org] > >> On Behalf Of Internet-Drafts@ietf.org > >>> Sent: Wednesday, June 05, 2013 3:51 PM > >>> To: i-d-announce@ietf.org > >>> Cc: storm@ietf.org > >>> Subject: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt > >>> > >>> A new Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the STORage Maintenance Working Group of= the > >> IETF. > >>> > >>> Title : IP Storage: IPsec Requirements Update for IPsec= v3 > >>> Author(s) : D. Black, et al > >>> Filename : draft-ietf-storm-ipsec-ips-update > >>> Pages : 13 > >>> Date : June 5, 2013 > >>> > >>> RFC 3723 includes requirements for IPsec usage with IP Storage > >>> protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related > >>> RFCs). This document updates those requirements to IPsec v3 (RF= C > >>> 4301 and related RFCs) and updates implementation requirements t= o > >>> reflect developments in cryptography since RFC 3723 was publishe= d. > >>> > >>> [RFC Editor: The "Updates:" list above has been trunca= ted > by > >> xml2rfc. > >>> The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 41= 72, > >>> 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048= (if > >>> approved) ] > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update= - > 00.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of the > >>> Internet-Draft. > >>> > >>> > >>> > >>> _______________________________________________ > >>> IPsec mailing list > >>> IPsec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipsec > >>> > > From iesg-secretary@ietf.org Fri Jun 7 07:00:28 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4C621F949D; Fri, 7 Jun 2013 07:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9ZDpeH14Yee; Fri, 7 Jun 2013 07:00:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4B321F9385; Fri, 7 Jun 2013 07:00:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Sender: Message-ID: <20130607140023.19235.60126.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2013 07:00:23 -0700 Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (Auto Discovery VPN Problem Statement and Requirements) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:00:28 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Auto Discovery VPN Problem Statement and Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution will address these requirements. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ballot/ No IPR declarations have been submitted directly on this I-D. From paul.hoffman@vpnc.org Fri Jun 7 08:12:03 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9645721F85EF for ; Fri, 7 Jun 2013 08:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.276 X-Spam-Level: X-Spam-Status: No, score=-103.276 tagged_above=-999 required=5 tests=[AWL=1.323, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InDsSAY9UCLV for ; Fri, 7 Jun 2013 08:12:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 705AD21F85BF for ; Fri, 7 Jun 2013 08:12:02 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r57FC1kr080336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 7 Jun 2013 08:12:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jun 2013 08:12:00 -0700 References: To: IPsecme WG Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [IPsec] Fwd: Liaison Statement From the IESG and IAB to ISO/IEC JTC1/SC6 on TISec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:12:03 -0000 Of likely interest to many people in this group. Begin forwarded message: > From: IAB Chair > Subject: Liaison Statement =46rom the IESG and IAB to ISO/IEC JTC1/SC6 = on TISec > Date: June 6, 2013 1:50:44 PM PDT > To: IETF >=20 > The Liaison statement can be found here: = https://datatracker.ietf.org/liaison/1258/ >=20 > The Internet Society will forward this liaison statement to ISO/IEC = JTC1/SC6 on their letterhead. This will carry more weight than a = statement just from the IESG and IAB because the Internet Society holds = a Class A liaison with SC6 on behalf of the IETF. >=20 > This liaison is provided to ISO/IEC JTC1/SC6 because they are = entertaining adopting the TISec. The IESG and the IAB believe TISec = provides the same services as IPsec. The IESG rejected a request for a = protocol number assignment for TISec in August of last year for that = reason, but the IESG offered an experimental code point while TISec was = under review in ISO. A liaison was sent to ISO informing them of this = decision in December (see ). >=20 > The TISec proponents have indicated that they believe that TISec is = different than IPsec. This liaison is a response this statement. It = points out how IPsec supports the same functionality, and it encourages > the TISec proponents to engage in the IETF process to specify the use = of their national algorithms in IPsec, as has been done for other = national algorithms. >=20 > On behalf of the IAB, > Russ Housley >=20 > On behalf of the IESG, > Jari Arkko >=20 >=20 From ietf-secretariat-reply@ietf.org Thu Jun 6 10:59:34 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A53911E80EC for ; Thu, 6 Jun 2013 10:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owVTQfJfkYFu for ; Thu, 6 Jun 2013 10:59:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B1A11E80ED for ; Thu, 6 Jun 2013 10:59:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130606175933.11690.47238.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 10:59:33 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 07 Jun 2013 08:31:07 -0700 Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:59:34 -0000 Changed milestone "WG last call on IPv6 configuration payloads", set due date to December 2008 from December 2008. Changed milestone "WG last call on IPsec roadmap", set due date to December 2008 from December 2008. Changed milestone "WG last call on session resumption", set due date to January 2009 from January 2009. Changed milestone "WG last call on IKEv2bis", set due date to March 2009 from March 2009. Changed milestone "WG last call on HA requirements", set due date to August 2010 from August 2010. Changed milestone "WG last call on quick crash discovery", set due date to December 2010 from December 2010. Changed milestone "WG last call on EAP-only authentication", set due date to January 2011 from January 2011. Deleted milestone "IETF Last Call on IKE over TCP". Deleted milestone "IETF LC new mandatory-to-implement algorithms". Deleted milestone "IETF LC out-of-band public key draft". Changed milestone "IETF Last Call on large scale VPN use cases and requirements", set due date to June 2013 from November 2012. Added milestone "IETF last call on IKE fragmentation solution", due December 2013. Added milestone "IETF last call on new mandatory-to-implement algorithms", due February 2014. Changed milestone "IETF Last Call on large scale VPN protocol", set due date to June 2014 from June 2013. URL: http://datatracker.ietf.org/wg/ipsecme/charter/ From ietf-ipr@ietf.org Fri Jun 7 09:23:54 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B9321F9927; Fri, 7 Jun 2013 09:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkLb1Td2Ftm4; Fri, 7 Jun 2013 09:23:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0962F21F9485; Fri, 7 Jun 2013 09:23:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: vvolpe@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130607162351.3984.67887.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2013 09:23:51 -0700 Cc: byfraser@cisco.com, ipsec@ietf.org, tytso@mit.edu, turners@ieca.com, ipr-announce@ietf.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] IPR Disclosure: SSH Communications Security Corp's Statement about IPR related to RFC 3947 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:23:54 -0000 Dear Victor Volpe: An IPR disclosure that pertains to your RFC entitled "Negotiation of NAT- Traversal in the IKE" (RFC3947) was submitted to the IETF Secretariat on 2013-06-06 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/2096/). The title of the IPR disclosure is "SSH Communications Security Corp's Statement about IPR relat= ed to RFC 3947.""); The IETF Secretariat From paul.hoffman@vpnc.org Tue Jun 11 09:32:50 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6146A21F9648 for ; Tue, 11 Jun 2013 09:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rAJ-iuwqo8x for ; Tue, 11 Jun 2013 09:32:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DC91621F9638 for ; Tue, 11 Jun 2013 09:32:49 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5BGWmRF089525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Jun 2013 09:32:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4CF82068-0FD8-45EE-8143-7127069992D5@vpnc.org> Date: Tue, 11 Jun 2013 09:32:48 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [IPsec] Call for ADVPN protocol documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 16:32:50 -0000 Dear IPsec folks: The Auto-discovery VPN problem statement draft is now in IETF Last Call, = and it's time to move into the real beef: a protocol definition. If you = have, or you're working on, an ADVPN protocol, we would like to have it = presented in Berlin. This means an initial draft needs to be submitted = by July 8! Please let us know (on the list or privately) if you're planning a draft = before Berlin so we can plan the meeting. Thanks, Paul and Yaron From david.black@emc.com Tue Jun 18 16:44:07 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB27121E80B6 for ; Tue, 18 Jun 2013 16:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8A8s7aw34YU for ; Tue, 18 Jun 2013 16:44:03 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id ECAF721E8096 for ; Tue, 18 Jun 2013 16:44:02 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5INi0U0001061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jun 2013 19:44:01 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 18 Jun 2013 19:43:52 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5INhmgi020967 for ; Tue, 18 Jun 2013 19:43:48 -0400 Received: from mxhub38.corp.emc.com (128.222.70.105) by mxhub20.corp.emc.com (10.254.93.49) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 18 Jun 2013 19:43:47 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Tue, 18 Jun 2013 19:43:47 -0400 From: "Black, David" To: IPsecme WG Importance: high X-Priority: 1 Date: Tue, 18 Jun 2013 19:43:46 -0400 Thread-Topic: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 Thread-Index: Ac5seEbW6YTVKeIwQ4e5vN67Pyl/4AABMxvA Message-ID: <8D3D17ACE214DC429325B2B98F3AE71298265374@MX15A.corp.emc.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-EMM-MHVC: 1 Subject: [IPsec] FW: [storm] Working Group Last Call - IP Storage: IPsec Requirements Update for IPsec v3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:44:07 -0000 FYI, Yaron Sheffer's already looked at this and found a couple of typos that will be fixed in the inevitable -02 version - if you also=20 find them, it's proof that you read this draft carefully :-). Thanks, --David -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of T= om Talpey Sent: Tuesday, June 18, 2013 7:30 PM To: storm@ietf.org Subject: [storm] Working Group Last Call - IP Storage: IPsec Requirements U= pdate for IPsec v3 Importance: High This message is to announce the STORM working group Last Call on the follow= ing document: IP Storage: IPsec Requirements Update for IPsec v3 http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-01.tx= t This new document is created to align IP Storage IPsec profiles with IPsec-= v3 requirements. The iSCSI consolidated draft and also the iSER draft will = make normative references to this new document, therefore it is desirable t= o move it into the publication pipeline promptly, to unblock these other dr= afts. Last Call comments are due by Wednesday, July 3 at midnight Eastern time (t= wo weeks from today). Please send all technical comments to the storm mailing list: storm@ietf.or= g . Editorial comments may be sent directly to the draft authors: draft-ietf-st= orm-ipsec-ips-update@tools.ietf.org . Tom Talpey STORM WG co-chair _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From martin.vigoureux@alcatel-lucent.com Fri Jun 21 06:11:56 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4A11E817D; Fri, 21 Jun 2013 06:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlyhnteDIaud; Fri, 21 Jun 2013 06:11:50 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2A821F9C47; Fri, 21 Jun 2013 06:11:49 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r5LDBmg5006172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Jun 2013 08:11:48 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r5LDBfCs029105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jun 2013 09:11:48 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 21 Jun 2013 09:11:44 -0400 Received: from [172.27.205.220] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 21 Jun 2013 15:11:18 +0200 Message-ID: <51C450F5.10506@alcatel-lucent.com> Date: Fri, 21 Jun 2013 15:11:17 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.41] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Mailman-Approved-At: Fri, 21 Jun 2013 08:02:41 -0700 Cc: draft-ietf-ipsecme-ad-vpn-problem.all@tools.ietf.org, rtg-dir@ietf.org, ipsec@ietf.org Subject: [IPsec] RtgDir review: draft-ietf-ipsecme-ad-vpn-problem-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 13:11:56 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ipsecme-ad-vpn-problem-07 Reviewer: Martin Vigoureux Review Date: June the 21st, 2013 IETF LC End Date: June the 21st, 2013 Intended Status: Informational Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: The document is well written, well scoped and clear. The "nits" are more questions for clarifications rather than identified bugs. Major Issues: No major issues found. Minor Issues: The draft defines and uses the term "endpoint" and "gateway" while RFC 4301 apparently employs the terms "host" and "gateway" (although there are few occurrences of "endpoint"). While I doubt that this difference be misleading, it might be wise to seek for consistency in terminology between the documents, or alternatively state the differences and similarities between the functions these terms refer to. Nowhere is a requirement for (backward) compatibility with regards to existing specifications. Is this intentional? Requirement 1 is unclear with regards to the type of configuration changes that must be minimized. It should be clarified if these changes are manual configuration changes or simply configuration changes. If not, out of this requirement both the solutions of having no/few change or having as many changes as today but all/most of them done without human intervention, are possible. I can not state if any of these makes sense or is feasible but they are surely substantially different from a design and engineering perspective. As an illustration, Requirement 2 has the same ambiguity but resolves it by means of the second sentence where the configurations are explicitly qualified as "manual". Isn't requirement 8 too strong? The keyword "MUST" is used, while "SHOULD" would seem more appropriate. Indeed, follows the requirement a description of situations in which it might not be possible to meet the requirement, or where it might be but by means of external factors. While requirement 12 is not an unusual one, its presence in a document that focuses on point-to-point can be discussed. As a general comment it is difficult to estimate how much some of these requirements scope/guide the design of a solution. Nits: Section 2.2: "It is for this purpose spoke-to-spoke tunnels are dynamically created and torn-down." This sentence seems difficult to read. Regards, Martin