From dkogan@cs.stanford.edu Fri Aug 3 22:10:54 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA2C1292AD for ; Fri, 3 Aug 2018 22:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkkxywhiwODY for ; Fri, 3 Aug 2018 22:10:52 -0700 (PDT) Received: from smtp3.cs.Stanford.EDU (smtp3.cs.stanford.edu [171.64.64.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4FF127598 for ; Fri, 3 Aug 2018 22:10:52 -0700 (PDT) Received: from mail-lj1-f170.google.com ([209.85.208.170]:35821) by smtp3.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1floq3-0005z9-OC for ice@ietf.org; Fri, 03 Aug 2018 22:10:52 -0700 Received: by mail-lj1-f170.google.com with SMTP id p10-v6so6562936ljg.2 for ; Fri, 03 Aug 2018 22:10:51 -0700 (PDT) X-Gm-Message-State: AOUpUlEU/ChkiODLmC68q4VO6s38BvJ15vRDqD99XRFBOWi8+HZYL4Tc 4QGi37kuuT/my9Dq12vnsL6RYZuvv6t32qDlDg0= X-Google-Smtp-Source: AAOMgpePg4TspIN90sQSVi/MusuDfyLNZfuruete6vY/EU+ywQRCkgfPrP8WxhcSuZA3o/DjZvrooEnTXvNO/XiTlNA= X-Received: by 2002:a2e:2bd7:: with SMTP id r84-v6mr7436074ljr.40.1533359450078; Fri, 03 Aug 2018 22:10:50 -0700 (PDT) MIME-Version: 1.0 References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> In-Reply-To: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> From: Dima Kogan Date: Fri, 3 Aug 2018 22:10:35 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary="00000000000055c7ae0572951104" X-Scan-Signature: fba5d1bf4e2735531ca2f657cf1136db Archived-At: Subject: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 05:12:53 -0000 --00000000000055c7ae0572951104 Content-Type: text/plain; charset="UTF-8" While experimenting with ICE NAT traversal, I came across a class of network configurations that currently does not result in a direct P2P connection (but rather falls back to TURN), yet I believe it could be in principle. I wanted to ask whether the limitation for this kind of configurations is ''known to the ICE community'', and how do you view the trade-off of supporting it. Specifically, the configuration is where both peers are behind a NAT which implements * endpoint-independent mappings, * endpoint-dependent filtering, and * does not drop all unsolicited incoming packets, but rather generated ICMP unreachable replies. An example for such a configuration is Linux Iptables with a MASQUERADE rule on the FORWARD chain, yet without a DROP rule on the INPUT chain. In this configuration the following scenario can happen: 1. Both peers learn their external IP address and port from a STUN server. Assume that Peer1 binds local address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the hole punching), and this packet reaches NAT2 *before* Peer 2 sends an outgoing packet to (Y1,y1). In this case, since NAT2 implements endpoint-dependent filtering, NAT2 does not forward the packet to Peer2 (this is expected). However, if NAT2 does not drop the incoming packet, but rather generates an ICMP packet in reply, the flow (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a Null Binding in Netfilter terminology). 3. Subsequently, when Peer2 sends its UDP packet (as part of the hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the external port of this packet to y3, since y2 is already allocated due to the previous unsolicited packet. When this packet reaches NAT1, it cannot traverse it since the source port y3, is different than the port for which the hole in NAT1 has been punched. Note that had the unsolicited packet not be previously received, the external port would not be modified, since the NAT implements endpoint-independent mappings. This prevents direct P2P connectivity. I believe one semi-standard solution to this approach is to begin the hole punching by sending packets with short TTL numbers, which would guarantee that a hole in each peer's NAT is punched before any incoming packets arrive. This would prevent the above scenario of unsolicited packets creating erroneous bindings in the NAT that prevent succesful hole punching. Obviously there are a lot of details that need to be fleshed out (e.g., which TTL to use, double NAT etc.) but hopefully some additional cases could result in a P2P connection. --00000000000055c7ae0572951104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Whil= e experimenting with ICE NAT traversal, I came across a class
of = network configurations that currently does not result in a
direct= P2P connection (but rather falls back to TURN), yet I
believe it= could be in principle. I wanted to ask whether the
limitation fo= r this kind of configurations is ''known to the ICE
commu= nity'', and how do you view the trade-off of supporting it.

Specifically, the configuration is where both peers= are behind a
NAT which implements
* endpoint-independe= nt mappings,
* endpoint-dependent filtering, and
* does= not drop all unsolicited incoming packets, but rather generated
= =C2=A0 ICMP unreachable replies.

An example for su= ch a configuration is Linux Iptables with a MASQUERADE
rule on th= e FORWARD chain, yet without a DROP rule on the INPUT chain.

=
In this configuration the following scenario can happen:

1. Both peers learn their external IP address and port fr= om a
STUN server.=C2=A0 Assume that Peer1 binds local
a= ddress/port (X1,x1), which gets mapped by NAT1 to (Y1,y1),
and fo= r Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2).

=
2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of th= e
hole punching), and this packet reaches NAT2 *before* Peer 2
sends an outgoing packet to (Y1,y1). In this case, since NAT2
=
implements endpoint-dependent filtering, NAT2 does not forward
the packet to Peer2 (this is expected). However, if NAT2 does not
<= div>drop the incoming packet, but rather generates an ICMP packet in
<= div>reply, the flow
(Y1,y1)<-->(Y2,y2) gets allocated (I be= lieve this is called a
Null Binding in Netfilter terminology).

3. Subsequently, when Peer2 sends its UDP packet (as= part of the
hole punching) from (X2,x2) to (Y1,y1), NAT2 modifie= s the
external port of this packet to y3, since y2 is already all= ocated
due to the previous unsolicited packet. When this packet r= eaches
NAT1, it cannot traverse it since the source port y3, is
different than the port for which the hole in NAT1 has been
<= div>punched.=C2=A0 Note that had the unsolicited packet not be previously
received, the external port would not be modified, since the NAT
implements endpoint-independent mappings.

This prevents direct P2P connectivity.

I believe = one semi-standard solution to this approach is to begin
the hole = punching by sending packets with short TTL numbers,
which would g= uarantee that a hole in each peer's NAT is punched
before any= incoming packets arrive. This would prevent the above
scenario o= f unsolicited packets creating erroneous bindings in
the NAT that= prevent succesful hole punching.
Obviously there are a lot = of details that need to be fleshed out (e.g.,=C2=A0
which TTL to = use, double NAT etc.) but hopefully some additional=C2=A0
cases c= ould result in a P2P connection.

--00000000000055c7ae0572951104-- From nobody Sun Aug 5 18:12:34 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A29B1286E3 for ; Sun, 5 Aug 2018 18:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwn72lr29aaU for ; Sun, 5 Aug 2018 18:12:30 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB5B127B92 for ; Sun, 5 Aug 2018 18:12:30 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id d9-v6so15312399itf.2 for ; Sun, 05 Aug 2018 18:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RKUwOCSQJ8LW/EXZUcSN3yI4JiRlVg4W2c6BjWLVc3c=; b=O87icxx2OsRs+qCniAGQ7TBgq/d34B3QJyugZPe/tT8bBKM/DngHF1qrvckRrEYrnE pnz8pDs0fKv8Hv2/6ABwZPWXP6tElTaVR20kES8n3PZuMDlURuf4uZiIMWMKOnCudngE vP7+ja9HLWmJ79UT0m+4SK4Q2U6U4Cxl0vUceeMgFRC1yZUV32LEGoflZFd0Tj2UpmRs pA4j/sI1Mz7MCw876IvnYQdE8+58DhI5Uk/zFwt0pmDBI9gOlH08NdhGja9l+o57pR7x xqz/ZWqiWaIUKXJEpzkmG1XejPzTV1CJP6Pin3A11jsnhLTkvYfw7AfvwkeRVXGEEjc1 PA3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RKUwOCSQJ8LW/EXZUcSN3yI4JiRlVg4W2c6BjWLVc3c=; b=nvKgUQo1Il0NifQa/ddVJJUPDe1G2zWL/6K5uWgIA9WOrsr96DKD6c/KOO5BywvC26 +Ne7eCVaUU6CfW6FVFYH0g15s18Q8i8J5XNomamrk47Vcie0QbdK+rCRjHnsq7qJkT+m k61D1Wa3RBhVKnnIAjun2kncLYic0ttHc3+FkmF7LCsduDSwNRf2+25ZQ3Mjg7agNpM5 Rxx4DDxuHipMA4QCvFJFBGxtD9bpCn/ci0hYJUciquTCvBOOqDtI6DgoJL5KkyKB1WQl eWqvFVX5wPKKvgjj5JB/LAUPhBhEk+Bp5Mc0Vgqalo4KtTy6m0h1kYCz0vOMPpM6Loyb qJ8w== X-Gm-Message-State: AOUpUlH4bNSsvxoRKgoia5BgNkgcsRNhPpl+w+Z8e2BFUFMDFCygfK0B kSkLBcsrAR+9ck8we6GZ5HSnMeGd9R/pgHPa+tc4XA== X-Google-Smtp-Source: AAOMgpdAgPOVd6bx+48bgnO3T8FW7tmK/JlTgZx43iabV9UZbpvjpUCM35CgfC9tnLKnMbwlQMahq9MKuXQBur5HovI= X-Received: by 2002:a02:b804:: with SMTP id o4-v6mr11526546jam.12.1533517949557; Sun, 05 Aug 2018 18:12:29 -0700 (PDT) MIME-Version: 1.0 References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> In-Reply-To: From: Justin Uberti Date: Sun, 5 Aug 2018 18:12:17 -0700 Message-ID: To: dkogan@cs.stanford.edu Cc: ice@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4990c0572b9f866" Archived-At: Subject: Re: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 01:12:33 -0000 --000000000000a4990c0572b9f866 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 3, 2018 at 10:12 PM Dima Kogan wrote: > While experimenting with ICE NAT traversal, I came across a class > of network configurations that currently does not result in a > direct P2P connection (but rather falls back to TURN), yet I > believe it could be in principle. I wanted to ask whether the > limitation for this kind of configurations is ''known to the ICE > community'', and how do you view the trade-off of supporting it. > > Specifically, the configuration is where both peers are behind a > NAT which implements > * endpoint-independent mappings, > * endpoint-dependent filtering, and > * does not drop all unsolicited incoming packets, but rather generated > ICMP unreachable replies. > > An example for such a configuration is Linux Iptables with a MASQUERADE > rule on the FORWARD chain, yet without a DROP rule on the INPUT chain. > > In this configuration the following scenario can happen: > > 1. Both peers learn their external IP address and port from a > STUN server. Assume that Peer1 binds local > address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), > and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). > > 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the > hole punching), and this packet reaches NAT2 *before* Peer 2 > sends an outgoing packet to (Y1,y1). In this case, since NAT2 > implements endpoint-dependent filtering, NAT2 does not forward > the packet to Peer2 (this is expected). However, if NAT2 does not > drop the incoming packet, but rather generates an ICMP packet in > reply, the flow > (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a > Null Binding in Netfilter terminology). > OK. Since Y2:y2 has already been allocated as the endpoint-independent mapping for X2:x2 (by virtue of sending a packet from X2:x2 to a STUN server), this is simply an application of endpoint-dependent filtering (rejecting the packet from Y1:y1). > 3. Subsequently, when Peer2 sends its UDP packet (as part of the > hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the > external port of this packet to y3, since y2 is already allocated > due to the previous unsolicited packet. > This is surprising. If the mapping is truly endpoint-independent, it shouldn't matter if X2:x2 is sending to Y1:y1, it should use the existing (endpoint-independent) Y2:y2 mapping. How prevalent is this situation? > When this packet reaches > NAT1, it cannot traverse it since the source port y3, is > different than the port for which the hole in NAT1 has been > punched. Note that had the unsolicited packet not be previously > received, the external port would not be modified, since the NAT > implements endpoint-independent mappings. > > This prevents direct P2P connectivity. > > I believe one semi-standard solution to this approach is to begin > the hole punching by sending packets with short TTL numbers, > which would guarantee that a hole in each peer's NAT is punched > before any incoming packets arrive. This would prevent the above > scenario of unsolicited packets creating erroneous bindings in > the NAT that prevent succesful hole punching. > Obviously there are a lot of details that need to be fleshed out (e.g., > which TTL to use, double NAT etc.) but hopefully some additional > cases could result in a P2P connection. > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --000000000000a4990c0572b9f866 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Aug 3, 2018 at 10:12 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:
While experimenting with ICE NAT traversal, I came across a class
of network configurations that currently does not result in a
=
direct P2P connection (but rather falls back to TURN), yet I
believe it could be in principle. I wanted to ask whether the
li= mitation for this kind of configurations is ''known to the ICE
community'', and how do you view the trade-off of supporting = it.

Specifically, the configuration is where= both peers are behind a
NAT which implements
* endpoin= t-independent mappings,
* endpoint-dependent filtering, and
=
* does not drop all unsolicited incoming packets, but rather generated=
=C2=A0 ICMP unreachable replies.

An exa= mple for such a configuration is Linux Iptables with a MASQUERADE
rule on the FORWARD chain, yet without a DROP rule on the INPUT chain.

In this configuration the following scenario can happ= en:

1. Both peers learn their external IP address = and port from a
STUN server.=C2=A0 Assume that Peer1 binds local<= /div>
address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1),
=
and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2).

2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as= part of the
hole punching), and this packet reaches NAT2 *before= * Peer 2
sends an outgoing packet to (Y1,y1). In this case, since= NAT2
implements endpoint-dependent filtering, NAT2 does not forw= ard
the packet to Peer2 (this is expected). However, if NAT2 does= not
drop the incoming packet, but rather generates an ICMP packe= t in
reply, the flow
(Y1,y1)<-->(Y2,y2) gets allo= cated (I believe this is called a
Null Binding in Netfilter termi= nology).

OK. Since = Y2:y2 has already been allocated as the endpoint-independent mapping for X2= :x2 (by virtue of sending a packet from X2:x2 to a STUN server), this is si= mply an application of endpoint-dependent filtering (rejecting the packet f= rom Y1:y1).


3. Sub= sequently, when Peer2 sends its UDP packet (as part of the
hole p= unching) from (X2,x2) to (Y1,y1), NAT2 modifies the
external port= of this packet to y3, since y2 is already allocated
due to the p= revious unsolicited packet.

<= /div>
This is surprising. If the mapping is truly endpoint-independent,= it shouldn't matter if X2:x2 is sending to Y1:y1, it should use the ex= isting (endpoint-independent) Y2:y2 mapping.

How p= revalent is this situation?
=C2=A0
Whe= n this packet reaches
NAT1, it cannot traverse it since the sourc= e port y3, is
different than the port for which the hole in NAT1 = has been
punched.=C2=A0 Note that had the unsolicited packet not = be previously
received, the external port would not be modified, = since the NAT
implements endpoint-independent mappings.

This prevents direct P2P connectivity.

=
I believe one semi-standard solution to this approach is to begin
the hole punching by sending packets with short TTL numbers,
which would guarantee that a hole in each peer's NAT is punched
=
before any incoming packets arrive. This would prevent the above
=
scenario of unsolicited packets creating erroneous bindings in
the NAT that prevent succesful hole punching.
Obviously t= here are a lot of details that need to be fleshed out (e.g.,=C2=A0
which TTL to use, double NAT etc.) but hopefully some additional=C2=A0
cases could result in a P2P connection.

<= /div>
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--000000000000a4990c0572b9f866-- From nobody Sun Aug 5 19:48:31 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC471130E29 for ; Sun, 5 Aug 2018 19:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqyAHojDRP5J for ; Sun, 5 Aug 2018 19:48:27 -0700 (PDT) Received: from smtp3.cs.Stanford.EDU (smtp3.cs.stanford.edu [171.64.64.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535611286E3 for ; Sun, 5 Aug 2018 19:48:27 -0700 (PDT) Received: from mail-lf1-f54.google.com ([209.85.167.54]:41014) by smtp3.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fmVZH-0002Mx-Jq for ice@ietf.org; Sun, 05 Aug 2018 19:48:27 -0700 Received: by mail-lf1-f54.google.com with SMTP id v22-v6so7918178lfe.8 for ; Sun, 05 Aug 2018 19:48:23 -0700 (PDT) X-Gm-Message-State: AOUpUlHNGcBzAjjZZpt/ARl/yurG15AorH84Bbetq515F1LZhCESeO8Q iD6G3aGf1kcfODUxf4/BdSLqBTg23FtT0wwsKt4= X-Google-Smtp-Source: AAOMgpdrYRcZCmxaM9A0jAkYALu+5iNGc7XM0BLdoOqZ0OEeDj8ObwO6/bginQQfjOXY/B8Orr8tBxDC8Kyp3daz50g= X-Received: by 2002:a19:1366:: with SMTP id j99-v6mr9684728lfi.21.1533523702001; Sun, 05 Aug 2018 19:48:22 -0700 (PDT) MIME-Version: 1.0 References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> In-Reply-To: From: Dima Kogan Date: Sun, 5 Aug 2018 19:48:10 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: ice@ietf.org Content-Type: multipart/alternative; boundary="00000000000083367e0572bb4fc5" X-Scan-Signature: e2fb03075b2557fb7882065b4eb34aa8 Archived-At: Subject: Re: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 02:48:30 -0000 --00000000000083367e0572bb4fc5 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 5, 2018 at 6:12 PM Justin Uberti wrote: > On Fri, Aug 3, 2018 at 10:12 PM Dima Kogan wrote: > >> While experimenting with ICE NAT traversal, I came across a class >> of network configurations that currently does not result in a >> direct P2P connection (but rather falls back to TURN), yet I >> believe it could be in principle. I wanted to ask whether the >> limitation for this kind of configurations is ''known to the ICE >> community'', and how do you view the trade-off of supporting it. >> >> Specifically, the configuration is where both peers are behind a >> NAT which implements >> * endpoint-independent mappings, >> * endpoint-dependent filtering, and >> * does not drop all unsolicited incoming packets, but rather generated >> ICMP unreachable replies. >> >> An example for such a configuration is Linux Iptables with a MASQUERADE >> rule on the FORWARD chain, yet without a DROP rule on the INPUT chain. >> >> In this configuration the following scenario can happen: >> >> 1. Both peers learn their external IP address and port from a >> STUN server. Assume that Peer1 binds local >> address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), >> and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). >> >> 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the >> hole punching), and this packet reaches NAT2 *before* Peer 2 >> sends an outgoing packet to (Y1,y1). In this case, since NAT2 >> implements endpoint-dependent filtering, NAT2 does not forward >> the packet to Peer2 (this is expected). However, if NAT2 does not >> drop the incoming packet, but rather generates an ICMP packet in >> reply, the flow >> (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a >> Null Binding in Netfilter terminology). >> > > OK. Since Y2:y2 has already been allocated as the endpoint-independent > mapping for X2:x2 (by virtue of sending a packet from X2:x2 to a STUN > server), this is simply an application of endpoint-dependent filtering > (rejecting the packet from Y1:y1). > > >> 3. Subsequently, when Peer2 sends its UDP packet (as part of the >> hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the >> external port of this packet to y3, since y2 is already allocated >> due to the previous unsolicited packet. >> > > This is surprising. If the mapping is truly endpoint-independent, it > shouldn't matter if X2:x2 is sending to Y1:y1, it should use the existing > (endpoint-independent) Y2:y2 mapping. > > How prevalent is this situation? > I think the reason is that Linux IPTables/Netfilter implements endpoing-independent mapping that conforms with the following descriptions from RFC7857: If destination addresses and ports are different for outgoing connections started by local clients, a NAT MAY assign the same external port as the source ports for the connections. The port overlapping mechanism manages mappings between external packets and internal packets by looking at and storing their 5-tuple (protocol, source address, source port, destination address, and destination port). > > >> When this packet reaches >> NAT1, it cannot traverse it since the source port y3, is >> different than the port for which the hole in NAT1 has been >> punched. Note that had the unsolicited packet not be previously >> received, the external port would not be modified, since the NAT >> implements endpoint-independent mappings. >> >> This prevents direct P2P connectivity. >> >> I believe one semi-standard solution to this approach is to begin >> the hole punching by sending packets with short TTL numbers, >> which would guarantee that a hole in each peer's NAT is punched >> before any incoming packets arrive. This would prevent the above >> scenario of unsolicited packets creating erroneous bindings in >> the NAT that prevent succesful hole punching. >> Obviously there are a lot of details that need to be fleshed out (e.g., >> which TTL to use, double NAT etc.) but hopefully some additional >> cases could result in a P2P connection. >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > --00000000000083367e0572bb4fc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 5,= 2018 at 6:12 PM Justin Uberti <ju= berti@google.com> wrote:
On Fri, Aug 3, 20= 18 at 10:12 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:
While experimenting with ICE NAT traversal, I came across a c= lass
of network configurations that currently does not result in = a
direct P2P connection (but rather falls back to TURN), yet I
believe it could be in principle. I wanted to ask whether the
=
limitation for this kind of configurations is ''known to the I= CE
community'', and how do you view the trade-off of supp= orting it.

Specifically, the configuration i= s where both peers are behind a
NAT which implements
* = endpoint-independent mappings,
* endpoint-dependent filtering, an= d
* does not drop all unsolicited incoming packets, but rather ge= nerated
=C2=A0 ICMP unreachable replies.

An example for such a configuration is Linux Iptables with a MASQUERADE
rule on the FORWARD chain, yet without a DROP rule on the INPUT cha= in.

In this configuration the following scenario c= an happen:

1. Both peers learn their external IP a= ddress and port from a
STUN server.=C2=A0 Assume that Peer1 binds= local
address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1)= ,
and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y= 2).

2. Peer 1 sends an outgoing UDP packet to (Y2,= y2) (as part of the
hole punching), and this packet reaches NAT2 = *before* Peer 2
sends an outgoing packet to (Y1,y1). In this case= , since NAT2
implements endpoint-dependent filtering, NAT2 does n= ot forward
the packet to Peer2 (this is expected). However, if NA= T2 does not
drop the incoming packet, but rather generates an ICM= P packet in
reply, the flow
(Y1,y1)<-->(Y2,y2) ge= ts allocated (I believe this is called a
Null Binding in Netfilte= r terminology).

OK. Since Y2:y2 has al= ready been allocated as the endpoint-independent mapping for X2:x2 (by virt= ue of sending a packet from X2:x2 to a STUN server), this is simply an appl= ication of endpoint-dependent filtering (rejecting the packet from Y1:y1).<= /div>


3. Subsequently, when Peer2 sends its= UDP packet (as part of the
hole punching) from (X2,x2) to (Y1,y1= ), NAT2 modifies the
external port of this packet to y3, since y2= is already allocated
due to the previous unsolicited packet.

This is surprising. If the mapping is tr= uly endpoint-independent, it shouldn't matter if X2:x2 is sending to Y1= :y1, it should use the existing (endpoint-independent) Y2:y2 mapping.
=

How prevalent is this situation?

I think the reason is that Linux IPTables/Netfi= lter implements endpoing-independent mapping=C2=A0
that conforms = with the following descriptions from RFC7857:

If destination addresses and ports are= different for outgoing connections started by local clients, a NAT MAY assign the same external port as the source ports for the connections. The port overlapping mechanism manages mappings between external packets and internal packets by looking at and storing their 5-tuple (protocol, source address, source port, destination address, and destination port).

=C2=A0
=C2=A0
When this packet reaches
NAT1, it cannot traverse it si= nce the source port y3, is
different than the port for which the = hole in NAT1 has been
punched.=C2=A0 Note that had the unsolicite= d packet not be previously
received, the external port would not = be modified, since the NAT
implements endpoint-independent mappin= gs.

This prevents direct P2P connectivity.

I believe one semi-standard solution to this approach is = to begin
the hole punching by sending packets with short TTL numb= ers,
which would guarantee that a hole in each peer's NAT is = punched
before any incoming packets arrive. This would prevent th= e above
scenario of unsolicited packets creating erroneous bindin= gs in
the NAT that prevent succesful hole punching.
Obviously there are a lot of details that need to be fleshed out (e.g.,= =C2=A0
which TTL to use, double NAT etc.) but hopefully some addi= tional=C2=A0
cases could result in a P2P connection.
<= div>
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--00000000000083367e0572bb4fc5-- From nobody Sun Aug 5 19:55:48 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62624130E2B for ; Sun, 5 Aug 2018 19:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLdqjF9vqQk0 for ; Sun, 5 Aug 2018 19:55:43 -0700 (PDT) Received: from smtp3.cs.Stanford.EDU (smtp3.cs.stanford.edu [171.64.64.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EB41286E3 for ; Sun, 5 Aug 2018 19:55:43 -0700 (PDT) Received: from mail-lf1-f43.google.com ([209.85.167.43]:43399) by smtp3.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fmVgL-0006tv-Vw for ice@ietf.org; Sun, 05 Aug 2018 19:55:43 -0700 Received: by mail-lf1-f43.google.com with SMTP id f135-v6so7905842lfg.10 for ; Sun, 05 Aug 2018 19:55:41 -0700 (PDT) X-Gm-Message-State: AOUpUlGOfT67pUasmKTW9KMpQ7QItFBpkAOCqz505jHZUVoh60atPUWd YIVIDNf3KOFW5g6Kk4LZafbhGrxLqlPRbBGd50Y= X-Google-Smtp-Source: AAOMgpeVbyb6YID1XAL2DSUwsdfWIx9q2RXRKry1VnoWRRPOhvT6UR7FTrJoJXxHtIJ1djzq3m2FVWrgjyXv6DpbaWw= X-Received: by 2002:a19:6b03:: with SMTP id d3-v6mr9458356lfa.81.1533524140339; Sun, 05 Aug 2018 19:55:40 -0700 (PDT) MIME-Version: 1.0 References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> In-Reply-To: From: Dima Kogan Date: Sun, 5 Aug 2018 19:55:29 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a3ba770572bb6925" X-Scan-Signature: 08f07bc5394299a69f1fbfe2bf0cc046 Archived-At: Subject: Re: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 02:55:46 -0000 --000000000000a3ba770572bb6925 Content-Type: text/plain; charset="UTF-8" Sorry, hit send prematurely. On Sun, Aug 5, 2018 at 7:48 PM Dima Kogan wrote: > On Sun, Aug 5, 2018 at 6:12 PM Justin Uberti wrote: > >> On Fri, Aug 3, 2018 at 10:12 PM Dima Kogan >> wrote: >> >>> While experimenting with ICE NAT traversal, I came across a class >>> of network configurations that currently does not result in a >>> direct P2P connection (but rather falls back to TURN), yet I >>> believe it could be in principle. I wanted to ask whether the >>> limitation for this kind of configurations is ''known to the ICE >>> community'', and how do you view the trade-off of supporting it. >>> >>> Specifically, the configuration is where both peers are behind a >>> NAT which implements >>> * endpoint-independent mappings, >>> * endpoint-dependent filtering, and >>> * does not drop all unsolicited incoming packets, but rather generated >>> ICMP unreachable replies. >>> >>> An example for such a configuration is Linux Iptables with a MASQUERADE >>> rule on the FORWARD chain, yet without a DROP rule on the INPUT chain. >>> >>> In this configuration the following scenario can happen: >>> >>> 1. Both peers learn their external IP address and port from a >>> STUN server. Assume that Peer1 binds local >>> address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), >>> and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). >>> >>> 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the >>> hole punching), and this packet reaches NAT2 *before* Peer 2 >>> sends an outgoing packet to (Y1,y1). In this case, since NAT2 >>> implements endpoint-dependent filtering, NAT2 does not forward >>> the packet to Peer2 (this is expected). However, if NAT2 does not >>> drop the incoming packet, but rather generates an ICMP packet in >>> reply, the flow >>> (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a >>> Null Binding in Netfilter terminology). >>> >> >> OK. Since Y2:y2 has already been allocated as the endpoint-independent >> mapping for X2:x2 (by virtue of sending a packet from X2:x2 to a STUN >> server), this is simply an application of endpoint-dependent filtering >> (rejecting the packet from Y1:y1). >> >> >>> 3. Subsequently, when Peer2 sends its UDP packet (as part of the >>> hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the >>> external port of this packet to y3, since y2 is already allocated >>> due to the previous unsolicited packet. >>> >> >> This is surprising. If the mapping is truly endpoint-independent, it >> shouldn't matter if X2:x2 is sending to Y1:y1, it should use the existing >> (endpoint-independent) Y2:y2 mapping. >> >> How prevalent is this situation? >> > > I think the reason is that Linux IPTables/Netfilter implements endpoing-independent mapping that conforms with the following descriptions from RFC7857: If destination addresses and ports are different for outgoing connections started by local clients, a NAT MAY assign the same external port as the source ports for the connections. The port overlapping mechanism manages mappings between external packets and internal packets by looking at and storing their 5-tuple (protocol, source address, source port, destination address, and destination port). As a result, when the packet from (Y1,y1) reaches NAT2, even though (Y2,y2) is allocated for (X2,x2), it can still be shared at this point since the remote addresses differ (STUN for the first flow, (Y1,y1) for the second one). However, when (X2,x2) subsequently sends a packet to (Y1,y1), it no longer can be shared as there's a collision on the entire tuple. It's hard for me to know how prevalent this is, but to me the fact that is (a) described in the RFC, and (b) is sort of the default behavior on Linux, suggest this might be not too rare. > >> >> >>> When this packet reaches >>> NAT1, it cannot traverse it since the source port y3, is >>> different than the port for which the hole in NAT1 has been >>> punched. Note that had the unsolicited packet not be previously >>> received, the external port would not be modified, since the NAT >>> implements endpoint-independent mappings. >>> >>> This prevents direct P2P connectivity. >>> >>> I believe one semi-standard solution to this approach is to begin >>> the hole punching by sending packets with short TTL numbers, >>> which would guarantee that a hole in each peer's NAT is punched >>> before any incoming packets arrive. This would prevent the above >>> scenario of unsolicited packets creating erroneous bindings in >>> the NAT that prevent succesful hole punching. >>> Obviously there are a lot of details that need to be fleshed out (e.g., >>> which TTL to use, double NAT etc.) but hopefully some additional >>> cases could result in a P2P connection. >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >> --000000000000a3ba770572bb6925 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, hit send prematurely.

On Sun, Aug 5, 2018 at 7:48 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:
On Sun, Aug 5, 2018 at 6:12 PM Justin Uberti <juberti@google.com> wrote:
On Fri, Aug 3, 2018 at 10:12 PM Dima= Kogan <dkog= an@cs.stanford.edu> wrote:
<= div dir=3D"ltr">
While= experimenting with ICE NAT traversal, I came across a class
of n= etwork configurations that currently does not result in a
direct = P2P connection (but rather falls back to TURN), yet I
believe it = could be in principle. I wanted to ask whether the
limitation for= this kind of configurations is ''known to the ICE
commun= ity'', and how do you view the trade-off of supporting it.

Specifically, the configuration is where both peers = are behind a
NAT which implements
* endpoint-independen= t mappings,
* endpoint-dependent filtering, and
* does = not drop all unsolicited incoming packets, but rather generated
= =C2=A0 ICMP unreachable replies.

An example for su= ch a configuration is Linux Iptables with a MASQUERADE
rule on th= e FORWARD chain, yet without a DROP rule on the INPUT chain.

=
In this configuration the following scenario can happen:

1. Both peers learn their external IP address and port fr= om a
STUN server.=C2=A0 Assume that Peer1 binds local
a= ddress/port (X1,x1), which gets mapped by NAT1 to (Y1,y1),
and fo= r Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2).

=
2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of th= e
hole punching), and this packet reaches NAT2 *before* Peer 2
sends an outgoing packet to (Y1,y1). In this case, since NAT2
=
implements endpoint-dependent filtering, NAT2 does not forward
the packet to Peer2 (this is expected). However, if NAT2 does not
<= div>drop the incoming packet, but rather generates an ICMP packet in
<= div>reply, the flow
(Y1,y1)<-->(Y2,y2) gets allocated (I be= lieve this is called a
Null Binding in Netfilter terminology).

OK. Since Y2:y2 has already been allocat= ed as the endpoint-independent mapping for X2:x2 (by virtue of sending a pa= cket from X2:x2 to a STUN server), this is simply an application of endpoin= t-dependent filtering (rejecting the packet from Y1:y1).
<= div dir=3D"ltr">

=

3. Subsequently, when Peer2 sends its UDP packet (as pa= rt of the
hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies t= he
external port of this packet to y3, since y2 is already alloca= ted
due to the previous unsolicited packet.

This is surprising. If the mapping is truly endpoint-indep= endent, it shouldn't matter if X2:x2 is sending to Y1:y1, it should use= the existing (endpoint-independent) Y2:y2 mapping.

How prevalent is this situation?

<= /div>
=C2=A0
I think the reason= is that Linux IPTables/Netfilter implements endpoing-independent mapping= =C2=A0
that conforms with the following descriptions from RFC7857= :

         If destination addresse=
s and ports are different for outgoing
         connections started by local clients, a NAT MAY assign the same
         external port as the source ports for the connections.  The
         port overlapping mechanism manages mappings between external
         packets and internal packets by looking at and storing their
         5-tuple (protocol, source address, source port, destination
         address, and destination port).

As a re= sult, when the packet from (Y1,y1) reaches NAT2, even though (Y2,y2) is all= ocated for (X2,x2),
it can still be shared at this point since th= e remote addresses differ (STUN for the first flow, (Y1,y1) for the second = one).
However, when (X2,x2) subsequently sends a packet to (Y1,y1= ), it no longer can be shared as there's a collision
on the e= ntire tuple.

It's hard for me to know how prev= alent this is, but to me the fact that is (a) described in the RFC, and (b)= is sort of the default
behavior on Linux, suggest this might be = not too rare.

=C2=A0
=C2=A0=
When this packet reach= es
NAT1, it cannot traverse it since the source port y3, is
=
different than the port for which the hole in NAT1 has been
= punched.=C2=A0 Note that had the unsolicited packet not be previously
=
received, the external port would not be modified, since the NAT
=
implements endpoint-independent mappings.

Thi= s prevents direct P2P connectivity.

I believe one = semi-standard solution to this approach is to begin
the hole punc= hing by sending packets with short TTL numbers,
which would guara= ntee that a hole in each peer's NAT is punched
before any inc= oming packets arrive. This would prevent the above
scenario of un= solicited packets creating erroneous bindings in
the NAT that pre= vent succesful hole punching.
Obviously there are a lot of d= etails that need to be fleshed out (e.g.,=C2=A0
which TTL to use,= double NAT etc.) but hopefully some additional=C2=A0
cases could= result in a P2P connection.

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--000000000000a3ba770572bb6925-- From nobody Sun Aug 5 21:09:46 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5C6130E8F for ; Sun, 5 Aug 2018 21:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raZI4m7jH8WU for ; Sun, 5 Aug 2018 21:09:41 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68C7130DE3 for ; Sun, 5 Aug 2018 21:09:41 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id y4-v6so5589132pgp.9 for ; Sun, 05 Aug 2018 21:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mcIgvYiZz6D4jjJfPM2jxLajqVhs0yD9OLRMUlgOOmY=; b=Af5J71YUUK9uCrcPD0rluVGuKIWcqsVV+xKdosVi6tH1WNRO08LBtEwqkXRo+m1Gs3 XJ0BLE4cSPnid+zi9aP6PL3jo99xjO+2PSMI3shIeLTkn+RS7V3yaFCDgNv72O98OtDv LRXQ+2bCFO6cw4Gr5TenEk0lQuvlpw797jGI4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mcIgvYiZz6D4jjJfPM2jxLajqVhs0yD9OLRMUlgOOmY=; b=gvW4Nx9LV7QNlhgoR6kOIJQyc6YeihweGIDNq4ctguch6YurixHkePriyZW9MqJy5o hF0NScoOA3BxWp/XLitVntM9iUy4//rj9qR8VR3sAU2+SD+kiuRQHwC0VyaltbyGbC0o nbxKLJVBggaAFruW264ZHehxmhOlzSXVFYkqjEJs/9+qedA4lrhr8SlwVZZHVPC9upLi 41e3gLtYR7CaDfB3lCEAPKyiMN+uCzLCnog3/8rhMF5RM5bbJS6ZG0AAGN6mQjdiLhTJ wk+lrvY5lyQmA/ufA5vbJ47nDywaCVCci6+WcGiK/+hx267olG0i46u8NwB4bpPqqWzg DDYg== X-Gm-Message-State: AOUpUlED4d9hagfKab+Xsy0RXw6UgDshdsh25cSBjckQaYR2Tm0RjuTl ZjKI/sxG+OdBOMWBTey6ZtsoZA== X-Google-Smtp-Source: AAOMgpfAaV/8VBRuZWQla789aKwQrn3OmfCXAlyNY7miJ3HzjMck0psbtptR4Qc8l3+GQ0GMNGz52g== X-Received: by 2002:a63:de10:: with SMTP id f16-v6mr12781366pgg.97.1533528580996; Sun, 05 Aug 2018 21:09:40 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:6da2:bad9:36c8:f9c6? ([2601:647:4600:3f31:6da2:bad9:36c8:f9c6]) by smtp.gmail.com with ESMTPSA id x4-v6sm13696821pfm.119.2018.08.05.21.09.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Aug 2018 21:09:39 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_77394DBD-1D14-4CCC-8198-28CABC94BF7D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 5 Aug 2018 21:09:37 -0700 In-Reply-To: Cc: ice@ietf.org To: Dima Kogan References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 04:09:45 -0000 --Apple-Mail=_77394DBD-1D14-4CCC-8198-28CABC94BF7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 3, 2018, at 22:10, Dima Kogan wrote: >=20 > While experimenting with ICE NAT traversal, I came across a class > of network configurations that currently does not result in a > direct P2P connection (but rather falls back to TURN), yet I > believe it could be in principle. I wanted to ask whether the > limitation for this kind of configurations is ''known to the ICE > community'', and how do you view the trade-off of supporting it. >=20 > Specifically, the configuration is where both peers are behind a > NAT which implements > * endpoint-independent mappings, > * endpoint-dependent filtering, and > * does not drop all unsolicited incoming packets, but rather generated > ICMP unreachable replies. >=20 > An example for such a configuration is Linux Iptables with a = MASQUERADE > rule on the FORWARD chain, yet without a DROP rule on the INPUT chain. Let me start with a clarifying question: are the two ICE endpoints in = this scenario are physically separated boxes from the Linux Iptables = machine? Or are the ICE endpoints running on the same machine? I=E2=80=99m asking, because I haven=E2=80=99t see Linux generating ICMP = responses on the wire. But if you have for example a DROP rule in the = local Iptables rules the local socket will behave as if an ICMP error = was received. Which can be really annoying when you are trying to test = something by setting up local DROP rules. Because it=E2=80=99s no longer = behaving like a DROP rule but like a REJECT rule. But I=E2=80=99m only = aware of this when everything runs locally on the same machine. > In this configuration the following scenario can happen: >=20 > 1. Both peers learn their external IP address and port from a > STUN server. Assume that Peer1 binds local > address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), > and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). >=20 > 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the > hole punching), and this packet reaches NAT2 *before* Peer 2 > sends an outgoing packet to (Y1,y1). In this case, since NAT2 > implements endpoint-dependent filtering, NAT2 does not forward > the packet to Peer2 (this is expected). However, if NAT2 does not > drop the incoming packet, but rather generates an ICMP packet in > reply, the flow > (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a > Null Binding in Netfilter terminology). >=20 > 3. Subsequently, when Peer2 sends its UDP packet (as part of the > hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the > external port of this packet to y3, since y2 is already allocated > due to the previous unsolicited packet. When this packet reaches > NAT1, it cannot traverse it since the source port y3, is > different than the port for which the hole in NAT1 has been > punched. Note that had the unsolicited packet not be previously > received, the external port would not be modified, since the NAT > implements endpoint-independent mappings. >=20 > This prevents direct P2P connectivity. >=20 > I believe one semi-standard solution to this approach is to begin > the hole punching by sending packets with short TTL numbers, > which would guarantee that a hole in each peer's NAT is punched > before any incoming packets arrive. This would prevent the above > scenario of unsolicited packets creating erroneous bindings in > the NAT that prevent succesful hole punching. > Obviously there are a lot of details that need to be fleshed out = (e.g., > which TTL to use, double NAT etc.) but hopefully some additional > cases could result in a P2P connection. My biggest concern would be that sending with increasing TTL=E2=80=99s = will slow things down. Especially if the two endpoints are lots of hops = apart, e.g. opposite sides of the world. Further more I would be concerned about packet loss of the TTL packets. = The only way I can think of right now to ensure that your TTL trick = worked would be to wait for ICMP responses. But that obviously = introduces another round trip waiting for ICMP. Plus the risk of the = ICMP error not getting back to the ICE endpoint at all. Best regards Nils Ohlmeier --Apple-Mail=_77394DBD-1D14-4CCC-8198-28CABC94BF7D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAltnygEACgkQY2o/VmzJ +KGCFBAAhbY1VDWbId8JINkuUNbPXZflrvbLCePjdDLtGrQC805EqxNxOhH7mSjW am3Dr2OTNbHHn86ld3pfSoMgRVRJvapkSdC6/DQIs1HDFVl+uBcNY+jL6mMPdics THckFo0X7u7g84QOu2J8J2Ceo6Tdc4QqS/uurDOolDax6QGJUT+URIBnjvoxVhuG xYhXbXZSeof13bwdcnnAIVmV+8QvJ590k/Z13AYr/mFYQ/kA4LMR9ol0DIcYeSs4 23D0I6k+FX6uKNJrqTYvaP1bZvNQbBUkRtm01CINEAf2Onfph2a9j55LZly3ddmz 4Pr6B7aek0HJVJu4AddgJOpmcQh5Jw7C1A6VF5KTTeTlVFoHQQPdpuyatZE3DxL7 VF5MYJC3wjX/XSg7MOwPTHFC/3aIyDGbBC2zkYlSJ6Np1b6ll8xLLJS0eQxIAlNn 4KcErviM4hVt9vgmMnvdyO14FYnkOVJuOdpzy7qRHw+QqbTW10GmufPb0rhWyPxV ClbPDNXClwNR2IVqZwaJdtTHZkKT6ve/DcYRoDdbkzRi6yqmWwEJ8Md1M4m0tJ+h F3aYtzmMW9hj8iSgJovH4GbinC7I2WMhug4pCRNf0GpPuuVpRwRpcelkBHZoMsXd xbmB5DjZaoopmdHnDRm1jZh41jzK/lwYb9ncG7x3/qRvvuLBOL8= =6pml -----END PGP SIGNATURE----- --Apple-Mail=_77394DBD-1D14-4CCC-8198-28CABC94BF7D-- From nobody Sun Aug 5 22:05:07 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE13130DBE for ; Sun, 5 Aug 2018 22:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_D6ks4YuNi6 for ; Sun, 5 Aug 2018 22:05:02 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DE5130DD1 for ; Sun, 5 Aug 2018 22:05:01 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id j81-v6so14013806ite.0 for ; Sun, 05 Aug 2018 22:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uOjt8i52Z0fQ/cwst7emmfoAQ98XPMUs0nIJnmMa08Q=; b=nmt8yIOS4zeMmobFXgmbDsznX2yqJbm5yDdOKqvjPt0Salh6SyFybsYqzVi/fdRLxs QxvyjzjHSwo7o6TzMFxqDR1baKfZxmKk577g0YJ6qEA3wSIrPloDOJxxcMTQyKaOXO10 HqNcXYrzu+SaEubBTZEOFTSZkfENGbfUiktPnle+oBQzMUDkOxuzpsPEdePnaKiLrwqe Xh01yYrBW8bDRdXM+I7DxAF47EsZXN8W29DgVKG5CECma7R60q9Egj2O3ucViVV7Szd5 VzH/jf8w3KxSsl371B4f+fpYV28m3p74NmGyFA0KYPvtUXwWkX1tp9WKtcC4lpEUeJp6 RR1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uOjt8i52Z0fQ/cwst7emmfoAQ98XPMUs0nIJnmMa08Q=; b=Y9w/ia+qz/S/lD8uevqsjMABSMlmJsQ4XKN5c++fCnsNyz8rBS6qm7zfDXCjBysqsO HmCuUeMRXNxL1Ejnn4jpOtovne+P5YgLK5oWkujiTEKCWNplQeS1s4lojHYuWYt0ukiD MRSLvBNH/yiGqqoKamzMnauek7zn9Fw8H4Y2DiDJQBsn6tgKMJguny73UI+aGMynL6E7 sVByYv+LShXEAOUKwXEydA7W2yB1MHO/Wh+Mq4bR+m9gSXZ7CcUokZaaBZJXH6UhBE2u 92LYve200/KqigpdBv56efEIN/mmmZVeoMWCuA3JRwMt8g5dPLzJvu2TCNvp+KhwxtL6 oHng== X-Gm-Message-State: AOUpUlEF1BPrMCqBSJTnkI7zrzj3qU+q5FVZlvTK2P4Jy/ENTf6mJNBB pfkcmiEb2zEG1rYcRVXmiWbX3bf5qfIi+3KQlO+mKQ== X-Google-Smtp-Source: AAOMgpfAEy46V2FpHCMDGdBA+bV2d2CTTG1TDQq5iw8Naxtfm41ReHzBaIUxXpKtzTuXqXKENMXTGTNOhJgtLdCdFEw= X-Received: by 2002:a02:125b:: with SMTP id i88-v6mr11690819jad.121.1533531900568; Sun, 05 Aug 2018 22:05:00 -0700 (PDT) MIME-Version: 1.0 References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> In-Reply-To: From: Justin Uberti Date: Sun, 5 Aug 2018 22:04:48 -0700 Message-ID: To: dkogan@cs.stanford.edu Cc: ice@ietf.org Content-Type: multipart/alternative; boundary="0000000000003008130572bd3875" Archived-At: Subject: Re: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 05:05:06 -0000 --0000000000003008130572bd3875 Content-Type: text/plain; charset="UTF-8" The section in that RFC refers to port preservation for local (internal) clients, and doesn't say anything about packets from external addresses. Generally, I think that the packet inbound from Y1:y1 to Y2:y2 will simply be discarded by the endpoint-specific filtering behavior. This packet shouldn't cause any change to the existing mapping or cause one to be created (or else this technique could be used from the outside to exhaust ports on the NAT). On Sun, Aug 5, 2018 at 7:55 PM Dima Kogan wrote: > Sorry, hit send prematurely. > > On Sun, Aug 5, 2018 at 7:48 PM Dima Kogan wrote: > >> On Sun, Aug 5, 2018 at 6:12 PM Justin Uberti wrote: >> >>> On Fri, Aug 3, 2018 at 10:12 PM Dima Kogan >>> wrote: >>> >>>> While experimenting with ICE NAT traversal, I came across a class >>>> of network configurations that currently does not result in a >>>> direct P2P connection (but rather falls back to TURN), yet I >>>> believe it could be in principle. I wanted to ask whether the >>>> limitation for this kind of configurations is ''known to the ICE >>>> community'', and how do you view the trade-off of supporting it. >>>> >>>> Specifically, the configuration is where both peers are behind a >>>> NAT which implements >>>> * endpoint-independent mappings, >>>> * endpoint-dependent filtering, and >>>> * does not drop all unsolicited incoming packets, but rather generated >>>> ICMP unreachable replies. >>>> >>>> An example for such a configuration is Linux Iptables with a MASQUERADE >>>> rule on the FORWARD chain, yet without a DROP rule on the INPUT chain. >>>> >>>> In this configuration the following scenario can happen: >>>> >>>> 1. Both peers learn their external IP address and port from a >>>> STUN server. Assume that Peer1 binds local >>>> address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), >>>> and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). >>>> >>>> 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the >>>> hole punching), and this packet reaches NAT2 *before* Peer 2 >>>> sends an outgoing packet to (Y1,y1). In this case, since NAT2 >>>> implements endpoint-dependent filtering, NAT2 does not forward >>>> the packet to Peer2 (this is expected). However, if NAT2 does not >>>> drop the incoming packet, but rather generates an ICMP packet in >>>> reply, the flow >>>> (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a >>>> Null Binding in Netfilter terminology). >>>> >>> >>> OK. Since Y2:y2 has already been allocated as the endpoint-independent >>> mapping for X2:x2 (by virtue of sending a packet from X2:x2 to a STUN >>> server), this is simply an application of endpoint-dependent filtering >>> (rejecting the packet from Y1:y1). >>> >>> >>>> 3. Subsequently, when Peer2 sends its UDP packet (as part of the >>>> hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the >>>> external port of this packet to y3, since y2 is already allocated >>>> due to the previous unsolicited packet. >>>> >>> >>> This is surprising. If the mapping is truly endpoint-independent, it >>> shouldn't matter if X2:x2 is sending to Y1:y1, it should use the existing >>> (endpoint-independent) Y2:y2 mapping. >>> >>> How prevalent is this situation? >>> >> >> > I think the reason is that Linux IPTables/Netfilter implements > endpoing-independent mapping > that conforms with the following descriptions from RFC7857: > > If destination addresses and ports are different for outgoing > connections started by local clients, a NAT MAY assign the same > external port as the source ports for the connections. The > port overlapping mechanism manages mappings between external > packets and internal packets by looking at and storing their > 5-tuple (protocol, source address, source port, destination > address, and destination port). > > > As a result, when the packet from (Y1,y1) reaches NAT2, even though > (Y2,y2) is allocated for (X2,x2), > it can still be shared at this point since the remote addresses differ > (STUN for the first flow, (Y1,y1) for the second one). > However, when (X2,x2) subsequently sends a packet to (Y1,y1), it no longer > can be shared as there's a collision > on the entire tuple. > > It's hard for me to know how prevalent this is, but to me the fact that is > (a) described in the RFC, and (b) is sort of the default > behavior on Linux, suggest this might be not too rare. > > >> >>> >>> >>>> When this packet reaches >>>> NAT1, it cannot traverse it since the source port y3, is >>>> different than the port for which the hole in NAT1 has been >>>> punched. Note that had the unsolicited packet not be previously >>>> received, the external port would not be modified, since the NAT >>>> implements endpoint-independent mappings. >>>> >>>> This prevents direct P2P connectivity. >>>> >>>> I believe one semi-standard solution to this approach is to begin >>>> the hole punching by sending packets with short TTL numbers, >>>> which would guarantee that a hole in each peer's NAT is punched >>>> before any incoming packets arrive. This would prevent the above >>>> scenario of unsolicited packets creating erroneous bindings in >>>> the NAT that prevent succesful hole punching. >>>> Obviously there are a lot of details that need to be fleshed out (e.g., >>>> which TTL to use, double NAT etc.) but hopefully some additional >>>> cases could result in a P2P connection. >>>> >>>> _______________________________________________ >>>> Ice mailing list >>>> Ice@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ice >>>> >>> --0000000000003008130572bd3875 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The section in that RFC refers to port preservation for lo= cal (internal) clients, and doesn't say anything about packets from ext= ernal addresses.

Generally, I think that the packet inbo= und from Y1:y1 to Y2:y2 will simply be discarded by the endpoint-specific f= iltering behavior. This packet shouldn't cause any change to the existi= ng mapping or cause one to be created (or else this technique could be used= from the outside to exhaust ports on the NAT).


On Sun, Aug 5, 2018 at 7= :55 PM Dima Kogan <dkogan@cs.s= tanford.edu> wrote:
Sorry, hit send prematurely.

On Sun, Aug 5, 2018 at 7:48 PM Dima Kogan <dkogan@cs.stanford.edu>= wrote:
On Sun, Aug 5, 2018 at 6:12 PM Justin Ube= rti <juberti@goo= gle.com> wrote:
On Fri, Aug 3, 2018 at 10:= 12 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:
=
While experimenting with ICE NAT traversal, I came across a class
of network configurations that currently does not result in a
direct P2P connection (but rather falls back to TURN), yet I
b= elieve it could be in principle. I wanted to ask whether the
limi= tation for this kind of configurations is ''known to the ICE
<= div>community'', and how do you view the trade-off of supporting it= .

Specifically, the configuration is where b= oth peers are behind a
NAT which implements
* endpoint-= independent mappings,
* endpoint-dependent filtering, and
* does not drop all unsolicited incoming packets, but rather generated
=C2=A0 ICMP unreachable replies.

An examp= le for such a configuration is Linux Iptables with a MASQUERADE
r= ule on the FORWARD chain, yet without a DROP rule on the INPUT chain.
=

In this configuration the following scenario can happen= :

1. Both peers learn their external IP address an= d port from a
STUN server.=C2=A0 Assume that Peer1 binds local
address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1),
and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2).
=

2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as p= art of the
hole punching), and this packet reaches NAT2 *before* = Peer 2
sends an outgoing packet to (Y1,y1). In this case, since N= AT2
implements endpoint-dependent filtering, NAT2 does not forwar= d
the packet to Peer2 (this is expected). However, if NAT2 does n= ot
drop the incoming packet, but rather generates an ICMP packet = in
reply, the flow
(Y1,y1)<-->(Y2,y2) gets alloca= ted (I believe this is called a
Null Binding in Netfilter termino= logy).

OK. Since Y2:y2 has already bee= n allocated as the endpoint-independent mapping for X2:x2 (by virtue of sen= ding a packet from X2:x2 to a STUN server), this is simply an application o= f endpoint-dependent filtering (rejecting the packet from Y1:y1).


3. Subsequently, when Peer2 sends its UDP pack= et (as part of the
hole punching) from (X2,x2) to (Y1,y1), NAT2 m= odifies the
external port of this packet to y3, since y2 is alrea= dy allocated
due to the previous unsolicited packet.
=

This is surprising. If the mapping is truly endpo= int-independent, it shouldn't matter if X2:x2 is sending to Y1:y1, it s= hould use the existing (endpoint-independent) Y2:y2 mapping.

=
How prevalent is this situation?
<= div>
=C2=A0
I think t= he reason is that Linux IPTables/Netfilter implements endpoing-independent = mapping=C2=A0
that conforms with the following descriptions from = RFC7857:

If destination addresses and ports are different = for outgoing connections started by local clients, a NAT MAY assign the same external port as the source ports for the connections. The port overlapping mechanism manages mappings between external packets and internal packets by looking at and storing their 5-tuple (protocol, source address, source port, destination address, and destination port).

As a result, when the packet from (Y1,y1) reaches NAT2, even = though (Y2,y2) is allocated for (X2,x2),
it can still be shared a= t this point since the remote addresses differ (STUN for the first flow, (Y= 1,y1) for the second one).
However, when (X2,x2) subsequently sen= ds a packet to (Y1,y1), it no longer can be shared as there's a collisi= on
on the entire tuple.

It's hard fo= r me to know how prevalent this is, but to me the fact that is (a) describe= d in the RFC, and (b) is sort of the default
behavior on Linux, s= uggest this might be not too rare.

=C2= =A0
=C2=A0
Wh= en this packet reaches
NAT1, it cannot traverse it since the sour= ce port y3, is
different than the port for which the hole in NAT1= has been
punched.=C2=A0 Note that had the unsolicited packet not= be previously
received, the external port would not be modified,= since the NAT
implements endpoint-independent mappings.

This prevents direct P2P connectivity.

I believe one semi-standard solution to this approach is to begin
the hole punching by sending packets with short TTL numbers,
which would guarantee that a hole in each peer's NAT is punched
before any incoming packets arrive. This would prevent the above
scenario of unsolicited packets creating erroneous bindings in
<= div>the NAT that prevent succesful hole punching.
Obviously = there are a lot of details that need to be fleshed out (e.g.,=C2=A0
which TTL to use, double NAT etc.) but hopefully some additional=C2=A0
cases could result in a P2P connection.

=
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--0000000000003008130572bd3875-- From nobody Sun Aug 5 22:14:24 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80B1130EA1 for ; Sun, 5 Aug 2018 22:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYDBpz2j2eum for ; Sun, 5 Aug 2018 22:14:19 -0700 (PDT) Received: from smtp2.cs.Stanford.EDU (smtp2.cs.stanford.edu [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60450130DBE for ; Sun, 5 Aug 2018 22:14:19 -0700 (PDT) Received: from mail-lf1-f45.google.com ([209.85.167.45]:36796) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fmXqS-0003Pa-My for ice@ietf.org; Sun, 05 Aug 2018 22:14:19 -0700 Received: by mail-lf1-f45.google.com with SMTP id b22-v6so8112757lfa.3 for ; Sun, 05 Aug 2018 22:14:16 -0700 (PDT) X-Gm-Message-State: AOUpUlHcRaeNz79z0ew2eBXRWZ8A92/gpmVyky113v/cN3kui0JyL+K2 Jab2OK4yY+EhVElWz5aRV8K8aX1tcJhke4r+jBc= X-Google-Smtp-Source: AAOMgpcCCzZLDf8hb4WVH4J3ZUSQ2L6HNbXv3zAJpJ0OC06h9LPwSItajwMRQn2PO/NQiCLW7fO+KC25ozJY4J2mokQ= X-Received: by 2002:a19:dedb:: with SMTP id i88-v6mr10671634lfl.26.1533532455014; Sun, 05 Aug 2018 22:14:15 -0700 (PDT) MIME-Version: 1.0 References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> In-Reply-To: From: Dima Kogan Date: Sun, 5 Aug 2018 22:14:03 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "nohlmeier@mozilla.com" Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003b980e0572bd59ac" X-Scan-Signature: 72cc6419352afccb56ba2f5c238b7af8 Archived-At: Subject: Re: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 05:14:24 -0000 --0000000000003b980e0572bd59ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 5, 2018 at 9:09 PM Nils Ohlmeier wrote: > > > > On Aug 3, 2018, at 22:10, Dima Kogan wrote: > > > > While experimenting with ICE NAT traversal, I came across a class > > of network configurations that currently does not result in a > > direct P2P connection (but rather falls back to TURN), yet I > > believe it could be in principle. I wanted to ask whether the > > limitation for this kind of configurations is ''known to the ICE > > community'', and how do you view the trade-off of supporting it. > > > > Specifically, the configuration is where both peers are behind a > > NAT which implements > > * endpoint-independent mappings, > > * endpoint-dependent filtering, and > > * does not drop all unsolicited incoming packets, but rather generated > > ICMP unreachable replies. > > > > An example for such a configuration is Linux Iptables with a MASQUERADE > > rule on the FORWARD chain, yet without a DROP rule on the INPUT chain. > > Let me start with a clarifying question: are the two ICE endpoints in thi= s > scenario are physically separated boxes from the Linux Iptables machine? > Or are the ICE endpoints running on the same machine? > > I=E2=80=99m asking, because I haven=E2=80=99t see Linux generating ICMP r= esponses on the > wire. But if you have for example a DROP rule in the local Iptables rules > the local socket will behave as if an ICMP error was received. Which can = be > really annoying when you are trying to test something by setting up local > DROP rules. Because it=E2=80=99s no longer behaving like a DROP rule but = like a > REJECT rule. But I=E2=80=99m only aware of this when everything runs loca= lly on the > same machine. > As far as the the scenario I'm describing, I've reproduced it both when the NAT is on a physically separate box, and when setting up a test environment on a single machine (using ip namespaces). To reproduce this on a single machine, I've been using the script below (slightly adapted from a version someone posted on a discussion on the netfilter list: https://www.spinics.net/lists/netfilter/msg58226.html). Just to understand your question, are you concerned with hole punching failing in the local scenario even if the local NAT is setup to DROP? If ICMP errors cause local sockets to behave badly, it's possible to artificially drop incoming ICMP packets on the "hosts" (again thanks to Adel Belhouane for pointing this out on a past netfilter thread): iptables -A INPUT -p icmp -j DROP > > > In this configuration the following scenario can happen: > > > > 1. Both peers learn their external IP address and port from a > > STUN server. Assume that Peer1 binds local > > address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), > > and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). > > > > 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the > > hole punching), and this packet reaches NAT2 *before* Peer 2 > > sends an outgoing packet to (Y1,y1). In this case, since NAT2 > > implements endpoint-dependent filtering, NAT2 does not forward > > the packet to Peer2 (this is expected). However, if NAT2 does not > > drop the incoming packet, but rather generates an ICMP packet in > > reply, the flow > > (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a > > Null Binding in Netfilter terminology). > > > > 3. Subsequently, when Peer2 sends its UDP packet (as part of the > > hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the > > external port of this packet to y3, since y2 is already allocated > > due to the previous unsolicited packet. When this packet reaches > > NAT1, it cannot traverse it since the source port y3, is > > different than the port for which the hole in NAT1 has been > > punched. Note that had the unsolicited packet not be previously > > received, the external port would not be modified, since the NAT > > implements endpoint-independent mappings. > > > > This prevents direct P2P connectivity. > > > > I believe one semi-standard solution to this approach is to begin > > the hole punching by sending packets with short TTL numbers, > > which would guarantee that a hole in each peer's NAT is punched > > before any incoming packets arrive. This would prevent the above > > scenario of unsolicited packets creating erroneous bindings in > > the NAT that prevent succesful hole punching. > > Obviously there are a lot of details that need to be fleshed out (e.g., > > which TTL to use, double NAT etc.) but hopefully some additional > > cases could result in a P2P connection. > > My biggest concern would be that sending with increasing TTL=E2=80=99s wi= ll slow > things down. Especially if the two endpoints are lots of hops apart, e.g. > opposite sides of the world. > I agree that incrementing all the way from 1 until connectivity is established (especially if waiting for responses) could be slow. Since in most cases, the local NAT (which is the actual target of these packets) is at distance 1-3 probably, I wonder whether some heuristic could be a good compromise (say even something stupid as only incrementing the TTL from 1 to 3 and then going straight to 255). I'm not an ICE expert, so I don't know all the design considerations that would go into a change like this, but I could imaging this only being used if both peers think they are behind an endpoint-independent NAT (which should theoretically allow P2P) yet the direct connection method fails. The alternative being TURN, maybe it's worth for them to try. > > Further more I would be concerned about packet loss of the TTL packets. > The only way I can think of right now to ensure that your TTL trick worke= d > would be to wait for ICMP responses. But that obviously introduces anothe= r > round trip waiting for ICMP. Plus the risk of the ICMP error not getting > back to the ICE endpoint at all. > > Best regards > Nils Ohlmeier > > (run everything as root) ############################################################# #!/bin/sh for i in s1 r1 in r2 s2; do ip netns del "$i" 2>/dev/null || : ; done ip netns add s1 ip netns add r1 ip netns add in ip netns add r2 ip netns add s2 ip -n s1 link add eth0 type veth peer name lan0 netns r1 ip -n r1 link add wan0 type veth peer name left0 netns in ip -n in link add right0 type veth peer name wan0 netns r2 ip -n r2 link add lan0 type veth peer name eth0 netns s2 # Uncomment the next line to fix hole punching #ip netns exec r1 iptables -P INPUT DROP ip netns exec r1 iptables -P FORWARD DROP ip netns exec r1 iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT ip netns exec r1 iptables -A FORWARD -i lan0 -j ACCEPT ip netns exec r1 iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE # Uncomment the next line to fix hole punching #ip netns exec r2 iptables -P INPUT DROP ip netns exec r2 iptables -P FORWARD DROP ip netns exec r2 iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT ip netns exec r2 iptables -A FORWARD -i lan0 -j ACCEPT ip netns exec r2 iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE ip -n s1 address add 192.0.2.2/24 dev eth0 ip -n r1 address add 192.0.2.1/24 dev lan0 ip -n r1 address add 198.51.100.11/24 dev wan0 ip -n in address add 198.51.100.1/24 dev left0 ip -n in address add 203.0.113.1/24 dev right0 ip -n r2 address add 203.0.113.12/24 dev wan0 ip -n r2 address add 192.0.2.1/24 dev lan0 ip -n s2 address add 192.0.2.2/24 dev eth0 ip -n in route add unreachable 192.0.2.0/24 # enforce routers' NAT for i in s1 r1 in r2 s2; do ip -n "$i" link set lo up; done ip -n s1 link set eth0 up ip -n s1 route add default via 192.0.2.1 ip -n r1 link set lan0 up ip -n r1 link set wan0 up ip -n r1 route add default via 198.51.100.1 ip -n in link set left0 up ip -n in link set right0 up ip -n r2 link set wan0 up ip -n r2 route add default via 203.0.113.1 ip -n r2 link set lan0 up ip -n s2 link set eth0 up ip -n s2 route add default via 192.0.2.1 ######################################### Then run in multiple terminals: # terminal 1: to setup inspection of the NAT on r1 ip netns exec r1 conntrack -E # terminal 2: to setup a "STUN server" on "the internet" ip netns exec in nc -u -l 2222 # terminal 3: Peer 1 ip netns exec s1 nc 198.51.100.1 2222 -u -p 1111 # enter some text on terminal 3 and on terminal 2. You should see the data going both ways. # you should see the following entries in terminal 1 # [NEW] udp 17 30 src=3D192.0.2.2 dst=3D198.51.100.1 sport=3D1111 dport=3D2222 [UNREPLIED] src=3D198.51.100.1 dst=3D198.51.100.11 sport=3D22= 22 dport=3D1111 # [UPDATE] udp 17 30 src=3D192.0.2.2 dst=3D198.51.100.1 sport=3D1111 dport=3D2222 src=3D198.51.100.1 dst=3D198.51.100.11 sport=3D2222 dport=3D11= 11 # [UPDATE] udp 17 180 src=3D192.0.2.2 dst=3D198.51.100.1 sport=3D1111 dport=3D2222 src=3D198.51.100.1 dst=3D198.51.100.11 sport=3D2222 dport=3D11= 11 [ASSURED] # terminal 4: start punching a hole from Peer 2 to Peer 1 ip netns exec s2 nc -u -p 2222 198.51.100.11 1111 # enter some text. Nothing should appear on Peer 1(terminal 3) # The following entry should appear in terminal 1 # [NEW] udp 17 30 src=3D203.0.113.12 dst=3D198.51.100.11 sport=3D2222 dport=3D1111 [UNREPLIED] src=3D198.51.100.11 dst=3D203.0.113.12 sport=3D111= 1 dport=3D2222 # back to terminal 3 (you can kill the netcat running there): now try punching the hole from Peer 1 to Peer 2 ip netns exec s1 nc 203.0.113.12 2222 -u -p 1111 # You should see nothing reaching peer 2 and the problematic entry appearing in terminal 1 # [NEW] udp 17 30 src=3D192.0.2.2 dst=3D203.0.113.12 sport=3D1111 dpor= t=3D2222 [UNREPLIED] src=3D203.0.113.12 dst=3D198.51.100.11 sport=3D2222 dport=3D102= 4 Note the last port number that gets allocated (1024) which is different from the source port 1111. --0000000000003b980e0572bd59ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Aug 5, 2018 at 9:09 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:


> On Aug 3, 2018, at 22:10, Dima Kogan <dkogan@cs.stanford.edu> wrote:
>
> While experimenting with ICE NAT traversal, I came across a class
> of network configurations that currently does not result in a
> direct P2P connection (but rather falls back to TURN), yet I
> believe it could be in principle. I wanted to ask whether the
> limitation for this kind of configurations is ''known to the I= CE
> community'', and how do you view the trade-off of supporting i= t.
>
> Specifically, the configuration is where both peers are behind a
> NAT which implements
> * endpoint-independent mappings,
> * endpoint-dependent filtering, and
> * does not drop all unsolicited incoming packets, but rather generated=
>=C2=A0 =C2=A0ICMP unreachable replies.
>
> An example for such a configuration is Linux Iptables with a MASQUERAD= E
> rule on the FORWARD chain, yet without a DROP rule on the INPUT chain.=

Let me start with a clarifying question: are the two ICE endpoints in this = scenario are physically separated boxes from the Linux Iptables machine? Or are the ICE endpoints running on the same machine?

I=E2=80=99m asking, because I haven=E2=80=99t see Linux generating ICMP res= ponses on the wire. But if you have for example a DROP rule in the local Ip= tables rules the local socket will behave as if an ICMP error was received.= Which can be really annoying when you are trying to test something by sett= ing up local DROP rules. Because it=E2=80=99s no longer behaving like a DRO= P rule but like a REJECT rule. But I=E2=80=99m only aware of this when ever= ything runs locally on the same machine.

As far as the the scenario I'm describing, I've reproduced it bot= h when the NAT is on a physically separate box, and when setting up a test = environment on a single machine (using ip namespaces).=C2=A0
To r= eproduce this on a single machine, I've been using the script below (sl= ightly adapted from a version someone posted on a discussion on the netfilt= er list:=C2=A0https://www.spinics.net/lists/netfilter/msg58226.html).
<= div>
Just to understand your question, are you concerned with= hole punching failing in the local scenario even if the local NAT is setup= to DROP? If ICMP errors cause local sockets to behave badly, it's poss= ible to artificially drop incoming ICMP packets on the "hosts" (a= gain thanks to Adel Belhouane for pointing this out on a past netfilter thr= ead):
iptables -A INPUT -p icmp -j DROP

= =C2=A0

> In this configuration the following scenario can happen:
>
> 1. Both peers learn their external IP address and port from a
> STUN server.=C2=A0 Assume that Peer1 binds local
> address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1),
> and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2).
>
> 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the
> hole punching), and this packet reaches NAT2 *before* Peer 2
> sends an outgoing packet to (Y1,y1). In this case, since NAT2
> implements endpoint-dependent filtering, NAT2 does not forward
> the packet to Peer2 (this is expected). However, if NAT2 does not
> drop the incoming packet, but rather generates an ICMP packet in
> reply, the flow
> (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a > Null Binding in Netfilter terminology).
>
> 3. Subsequently, when Peer2 sends its UDP packet (as part of the
> hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the
> external port of this packet to y3, since y2 is already allocated
> due to the previous unsolicited packet. When this packet reaches
> NAT1, it cannot traverse it since the source port y3, is
> different than the port for which the hole in NAT1 has been
> punched.=C2=A0 Note that had the unsolicited packet not be previously<= br> > received, the external port would not be modified, since the NAT
> implements endpoint-independent mappings.
>
> This prevents direct P2P connectivity.
>
> I believe one semi-standard solution to this approach is to begin
> the hole punching by sending packets with short TTL numbers,
> which would guarantee that a hole in each peer's NAT is punched > before any incoming packets arrive. This would prevent the above
> scenario of unsolicited packets creating erroneous bindings in
> the NAT that prevent succesful hole punching.
> Obviously there are a lot of details that need to be fleshed out (e.g.= ,
> which TTL to use, double NAT etc.) but hopefully some additional
> cases could result in a P2P connection.

My biggest concern would be that sending with increasing TTL=E2=80=99s will= slow things down. Especially if the two endpoints are lots of hops apart, = e.g. opposite sides of the world.

I agr= ee that incrementing all the way from 1 until connectivity is established (= especially if waiting for responses) could be slow.
Since in most= cases, the local NAT (which is the actual target of these packets) is at d= istance 1-3 probably, I wonder whether some heuristic could be a good compr= omise (say even something stupid as only incrementing the TTL=C2=A0from 1 t= o 3 and then going straight to 255).

I'm not a= n ICE expert, so I don't know all the design considerations that would = go into a change like this, but I could imaging this only being used
<= div>if both peers think they are behind an endpoint-independent NAT (which = should theoretically allow P2P) yet the direct connection method fails. The= alternative being TURN, maybe it's worth for them to try.
=C2=A0

Further more I would be concerned about packet loss of the TTL packets. The= only way I can think of right now to ensure that your TTL trick worked wou= ld be to wait for ICMP responses. But that obviously introduces another rou= nd trip waiting for ICMP. Plus the risk of the ICMP error not getting back = to the ICE endpoint at all.

Best regards
=C2=A0 Nils Ohlmeier



(run everything as root)
#############################################################<= /div>
#!/bin/sh

for i in s1 r1 in r2 s2; = do ip netns del "$i" 2>/dev/null || : ; done

ip netns add s1
ip netns add r1
ip netns add in=
ip netns add r2
ip netns add s2

ip -n s1 link add eth0 type veth peer name lan0 netns r1
ip -n= r1 link add wan0 type veth peer name left0 netns in
ip -n in lin= k add right0 type veth peer name wan0 netns r2
ip -n r2 link add = lan0 type veth peer name eth0 netns s2

# Uncomment= the next line to fix hole punching
#ip netns exec r1 iptables -P= INPUT DROP
ip netns exec r1 iptables -P FORWARD DROP
i= p netns exec r1 iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLIS= HED -j ACCEPT
ip netns exec r1 iptables -A FORWARD -i lan0 -j ACC= EPT
ip netns exec r1 iptables -t nat -A POSTROUTING -o wan0 -j MA= SQUERADE

# Uncomment the next line to fix hole pun= ching
#ip netns exec r2 iptables -P INPUT DROP
ip netns= exec r2 iptables -P FORWARD DROP
ip netns exec r2 iptables -A FO= RWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip net= ns exec r2 iptables -A FORWARD -i lan0 -j ACCEPT
ip netns exec r2= iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE

<= div>ip -n s1 address add 192.0.2.2/24 d= ev eth0
ip -n r1 address add 192.= 0.2.1/24 dev lan0
ip -n r1 address add 198.51.100.11/24 dev wan0
ip -n in address add = 198.51.100.1/24 dev left0
= ip -n in address add 203.0.113.1/24 d= ev right0
ip -n r2 address add 203.0.113.12/24 dev wan0
ip -n r2 address add 192.0.2.1/24 dev lan0
ip -n s2 address add = 192.0.2.2/24 dev eth0

ip -n in route add unreachable 192.= 0.2.0/24 # enforce routers' NAT

for i in s= 1 r1 in r2 s2; do ip -n "$i" link set lo up; done
ip -n= s1 link set eth0 up
ip -n s1 route add default via 192.0.2.1
ip -n r1 link set lan0 up
ip -n r1 link set wan0 up
<= div>ip -n r1 route add default via 198.51.100.1
ip -n in link set= left0 up
ip -n in link set right0 up
ip -n r2 link set= wan0 up
ip -n r2 route add default via 203.0.113.1
ip = -n r2 link set lan0 up
ip -n s2 link set eth0 up
ip -n = s2 route add default via 192.0.2.1

#########= ################################

Then run in multi= ple terminals:

# terminal 1: to setup inspection o= f the NAT on r1
ip netns exec r1 conntrack -E
<= br>
# terminal 2: to setup a "STUN server" on "the= internet"
ip netns exec in nc -u -l 2222

=
# terminal 3: Peer 1
ip netns exec s1 nc 198.51.100.1 = 2222 -u -p 1111

# enter some text on terminal = 3 and on terminal 2. You should see the data going both ways.
# y= ou should see the following entries in terminal 1
# [NEW] udp=C2= =A0 =C2=A0 =C2=A0 17 30 src=3D192.0.2.2 dst=3D198.51.100.1 sport=3D1111 dpo= rt=3D2222=C2=A0 [UNREPLIED] src=3D198.51.100.1 dst=3D198.51.100.11 sport=3D= 2222 dport=3D1111=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0
# [UPDATE] udp=C2=A0 =C2=A0 =C2=A0 17 30 src=3D192.0.2= .2 dst=3D198.51.100.1 sport=3D1111 dport=3D2222 src=3D198.51.100.1 dst=3D19= 8.51.100.11 sport=3D2222 dport=3D1111=C2=A0
# [UPDATE] udp=C2=A0 = =C2=A0 =C2=A0 17 180 src=3D192.0.2.2 dst=3D198.51.100.1 sport=3D1111 dport= =3D2222 src=3D198.51.100.1 dst=3D198.51.100.11 sport=3D2222 dport=3D1111 [A= SSURED]=C2=A0=C2=A0

# terminal 4: start punching a= hole from Peer 2 to Peer 1
ip netns exec s2 nc -u -p 2222 198.51= .100.11 1111
# enter some text. Nothing should appear on Peer= 1(terminal 3)
# The following entry should appear in termina= l 1
#=C2=A0[NEW] udp=C2=A0 =C2=A0 =C2=A0 17 30 src=3D203.0.113.12= dst=3D198.51.100.11 sport=3D2222 dport=3D1111 [UNREPLIED] src=3D198.51.100= .11 dst=3D203.0.113.12 sport=3D1111 dport=3D2222

#= back to terminal 3 (you can kill the netcat running there): now try punchi= ng the hole from Peer 1 to Peer 2
ip netns exec s1 nc 203.0.113.1= 2 2222 -u -p 1111=C2=A0
# You should see nothing reaching pee= r 2 and the problematic entry appearing in terminal 1
# [NEW] udp= =C2=A0 =C2=A0 =C2=A0 17 30 src=3D192.0.2.2 dst=3D203.0.113.12 sport=3D1111 = dport=3D2222 [UNREPLIED] src=3D203.0.113.12 dst=3D198.51.100.11 sport=3D222= 2 dport=3D1024

Note the last port number that = gets allocated (1024) which is different from the source port 1111.
=C2=A0
--0000000000003b980e0572bd59ac-- From nobody Sun Aug 5 22:44:30 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E551130EA8 for ; Sun, 5 Aug 2018 22:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn2e_TZx-6FD for ; Sun, 5 Aug 2018 22:44:13 -0700 (PDT) Received: from smtp2.cs.Stanford.EDU (smtp2.cs.stanford.edu [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC45130DBE for ; Sun, 5 Aug 2018 22:44:13 -0700 (PDT) Received: from mail-lf1-f46.google.com ([209.85.167.46]:37165) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fmYJP-000704-Mc for ice@ietf.org; Sun, 05 Aug 2018 22:44:13 -0700 Received: by mail-lf1-f46.google.com with SMTP id j8-v6so8129373lfb.4 for ; Sun, 05 Aug 2018 22:44:11 -0700 (PDT) X-Gm-Message-State: AOUpUlFHo8vKSK3YbvTnytzmV5ub0OxOs7e50DsRoHNfHwltAkwQ9rLo 9cjI3m4NugEP4ClclGcyfz20wa5I8/DVAjH2tdY= X-Google-Smtp-Source: AAOMgpeYKEc3X3/xiFtxV2Yl6uGNpi3Ej1/FesLlnG5dEmrOBB6h6oKqAmYCuoowXq2Zl9EJO1w0xAUNX1IVinRedPY= X-Received: by 2002:a19:6b03:: with SMTP id d3-v6mr9707423lfa.81.1533534249979; Sun, 05 Aug 2018 22:44:09 -0700 (PDT) MIME-Version: 1.0 References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> In-Reply-To: From: Dima Kogan Date: Sun, 5 Aug 2018 22:43:58 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003899420572bdc48f" X-Scan-Signature: b18bfb97b6ee282caf2c82162b965e52 Archived-At: Subject: Re: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 05:44:17 -0000 --0000000000003899420572bdc48f Content-Type: text/plain; charset="UTF-8" On Sun, Aug 5, 2018 at 10:05 PM Justin Uberti wrote: > The section in that RFC refers to port preservation for local (internal) > clients, and doesn't say anything about packets from external addresses. > > Generally, I think that the packet inbound from Y1:y1 to Y2:y2 will simply > be discarded by the endpoint-specific filtering behavior. This packet > shouldn't cause any change to the existing mapping or cause one to be > created (or else this technique could be used from the outside to exhaust > ports on the NAT). > Thank you for taking the time to answer my questions. I'm not 100% sure but maybe the creation of the mapping is triggered by the outgoing ICMP error. I've first asked this question on the netfilter forum, and a few people have confirmed this behavior ( https://www.spinics.net/lists/netfilter/msg58234.html). (I've also attached a script reproducing it in my other message). I agree that it looks like the Linux behavior here could cause other trouble as well (like the port exhaustion), and perhaps this is why the good way to configure a NAT is to add the DROP rule on the incoming packets (which would solve all trouble). I guess I'm curios what's the right way to look at this scenario in which a DROP rule is not present, and this behavior appears: A) This is a corner case which, similarly to probably dozen other weird NAT behaviors, not worth the effort for ICE. B) Iptables should be changed to behave differently even without the DROP rule. C) It's worth working around it in ICE I don't know who would have such data, but are there stats about how often peers that are classified by STUN as being endpoint-independent still fail to create a P2P connection? > > > On Sun, Aug 5, 2018 at 7:55 PM Dima Kogan wrote: > >> Sorry, hit send prematurely. >> >> On Sun, Aug 5, 2018 at 7:48 PM Dima Kogan wrote: >> >>> On Sun, Aug 5, 2018 at 6:12 PM Justin Uberti wrote: >>> >>>> On Fri, Aug 3, 2018 at 10:12 PM Dima Kogan >>>> wrote: >>>> >>>>> While experimenting with ICE NAT traversal, I came across a class >>>>> of network configurations that currently does not result in a >>>>> direct P2P connection (but rather falls back to TURN), yet I >>>>> believe it could be in principle. I wanted to ask whether the >>>>> limitation for this kind of configurations is ''known to the ICE >>>>> community'', and how do you view the trade-off of supporting it. >>>>> >>>>> Specifically, the configuration is where both peers are behind a >>>>> NAT which implements >>>>> * endpoint-independent mappings, >>>>> * endpoint-dependent filtering, and >>>>> * does not drop all unsolicited incoming packets, but rather generated >>>>> ICMP unreachable replies. >>>>> >>>>> An example for such a configuration is Linux Iptables with a MASQUERADE >>>>> rule on the FORWARD chain, yet without a DROP rule on the INPUT chain. >>>>> >>>>> In this configuration the following scenario can happen: >>>>> >>>>> 1. Both peers learn their external IP address and port from a >>>>> STUN server. Assume that Peer1 binds local >>>>> address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), >>>>> and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). >>>>> >>>>> 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the >>>>> hole punching), and this packet reaches NAT2 *before* Peer 2 >>>>> sends an outgoing packet to (Y1,y1). In this case, since NAT2 >>>>> implements endpoint-dependent filtering, NAT2 does not forward >>>>> the packet to Peer2 (this is expected). However, if NAT2 does not >>>>> drop the incoming packet, but rather generates an ICMP packet in >>>>> reply, the flow >>>>> (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a >>>>> Null Binding in Netfilter terminology). >>>>> >>>> >>>> OK. Since Y2:y2 has already been allocated as the endpoint-independent >>>> mapping for X2:x2 (by virtue of sending a packet from X2:x2 to a STUN >>>> server), this is simply an application of endpoint-dependent filtering >>>> (rejecting the packet from Y1:y1). >>>> >>>> >>>>> 3. Subsequently, when Peer2 sends its UDP packet (as part of the >>>>> hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the >>>>> external port of this packet to y3, since y2 is already allocated >>>>> due to the previous unsolicited packet. >>>>> >>>> >>>> This is surprising. If the mapping is truly endpoint-independent, it >>>> shouldn't matter if X2:x2 is sending to Y1:y1, it should use the existing >>>> (endpoint-independent) Y2:y2 mapping. >>>> >>>> How prevalent is this situation? >>>> >>> >>> >> I think the reason is that Linux IPTables/Netfilter implements >> endpoing-independent mapping >> that conforms with the following descriptions from RFC7857: >> >> If destination addresses and ports are different for outgoing >> connections started by local clients, a NAT MAY assign the same >> external port as the source ports for the connections. The >> port overlapping mechanism manages mappings between external >> packets and internal packets by looking at and storing their >> 5-tuple (protocol, source address, source port, destination >> address, and destination port). >> >> >> As a result, when the packet from (Y1,y1) reaches NAT2, even though >> (Y2,y2) is allocated for (X2,x2), >> it can still be shared at this point since the remote addresses differ >> (STUN for the first flow, (Y1,y1) for the second one). >> However, when (X2,x2) subsequently sends a packet to (Y1,y1), it no >> longer can be shared as there's a collision >> on the entire tuple. >> >> It's hard for me to know how prevalent this is, but to me the fact that >> is (a) described in the RFC, and (b) is sort of the default >> behavior on Linux, suggest this might be not too rare. >> >> >>> >>>> >>>> >>>>> When this packet reaches >>>>> NAT1, it cannot traverse it since the source port y3, is >>>>> different than the port for which the hole in NAT1 has been >>>>> punched. Note that had the unsolicited packet not be previously >>>>> received, the external port would not be modified, since the NAT >>>>> implements endpoint-independent mappings. >>>>> >>>>> This prevents direct P2P connectivity. >>>>> >>>>> I believe one semi-standard solution to this approach is to begin >>>>> the hole punching by sending packets with short TTL numbers, >>>>> which would guarantee that a hole in each peer's NAT is punched >>>>> before any incoming packets arrive. This would prevent the above >>>>> scenario of unsolicited packets creating erroneous bindings in >>>>> the NAT that prevent succesful hole punching. >>>>> Obviously there are a lot of details that need to be fleshed out >>>>> (e.g., >>>>> which TTL to use, double NAT etc.) but hopefully some additional >>>>> cases could result in a P2P connection. >>>>> >>>>> _______________________________________________ >>>>> Ice mailing list >>>>> Ice@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ice >>>>> >>>> --0000000000003899420572bdc48f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Aug 5, 2018 at 10:05 PM Justin Uberti <juberti@google.com> wrote:
The section in that RFC refers to port preservation = for local (internal) clients, and doesn't say anything about packets fr= om external addresses.

Generally, I think that the packe= t inbound from Y1:y1 to Y2:y2 will simply be discarded by the endpoint-spec= ific filtering behavior. This packet shouldn't cause any change to the = existing mapping or cause one to be created (or else this technique could b= e used from the outside to exhaust ports on the NAT).

Thank you for taking the time to answer my quest= ions.=C2=A0
=C2=A0
I'm not 100% sure but maybe = the creation of the mapping is triggered by the outgoing ICMP error.
<= div>I've first asked this question on the netfilter forum, and a few pe= ople have confirmed this behavior (https://www.spinics.net/lists/netfilter/msg58234.= html). (I've also attached a script reproducing it in my other mess= age).

I agree that it looks like the Linux beh= avior here could cause other trouble as well (like the port exhaustion), an= d perhaps this is why the good way to configure a NAT is to add the DROP ru= le on the incoming packets (which would solve all trouble).
I gue= ss I'm curios what's the right way to look at this scenario in whic= h a DROP rule is not present, and this behavior appears:
A) This = is a corner case which, similarly to probably dozen other weird NAT behavio= rs, not worth the effort for ICE.
B) Iptables should be changed t= o behave differently even without the DROP rule.=C2=A0
C) It'= s worth working around it in ICE

I don't know = who would have such data, but are there stats about how often peers that ar= e classified by STUN as being endpoint-independent still fail to create a P= 2P connection?


=C2=A0

On Sun, Aug 5, 2018 at 7:55 PM= Dima Kogan <dkogan@cs.stanford.edu> wrote:
Sorry, hit send prematurely.

On Sun, Aug 5, 2018 at 7:48 PM Dima Kogan <dkogan@cs.stanford= .edu> wrote:
On Sun, Aug 5, 2018 at 6:12 P= M Justin Uberti <juberti@google.com> wrote:
=
On Fri, Aug 3,= 2018 at 10:12 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:
While experimenting with ICE NAT traversal, I came acros= s a class
of network configurations that currently does not resul= t in a
direct P2P connection (but rather falls back to TURN), yet= I
believe it could be in principle. I wanted to ask whether the<= /div>
limitation for this kind of configurations is ''known to = the ICE
community'', and how do you view the trade-off of= supporting it.

Specifically, the configurat= ion is where both peers are behind a
NAT which implements
* endpoint-independent mappings,
* endpoint-dependent filterin= g, and
* does not drop all unsolicited incoming packets, but rath= er generated
=C2=A0 ICMP unreachable replies.

An example for such a configuration is Linux Iptables with a MASQUERA= DE
rule on the FORWARD chain, yet without a DROP rule on the INPU= T chain.

In this configuration the following scena= rio can happen:

1. Both peers learn their external= IP address and port from a
STUN server.=C2=A0 Assume that Peer1 = binds local
address/port (X1,x1), which gets mapped by NAT1 to (Y= 1,y1),
and for Peer2 binds (X2,x2), which gets mapped by NAT2 to = (Y2,y2).

2. Peer 1 sends an outgoing UDP packet to= (Y2,y2) (as part of the
hole punching), and this packet reaches = NAT2 *before* Peer 2
sends an outgoing packet to (Y1,y1). In this= case, since NAT2
implements endpoint-dependent filtering, NAT2 d= oes not forward
the packet to Peer2 (this is expected). However, = if NAT2 does not
drop the incoming packet, but rather generates a= n ICMP packet in
reply, the flow
(Y1,y1)<-->(Y2,y= 2) gets allocated (I believe this is called a
Null Binding in Net= filter terminology).

OK. Since Y2:y2 h= as already been allocated as the endpoint-independent mapping for X2:x2 (by= virtue of sending a packet from X2:x2 to a STUN server), this is simply an= application of endpoint-dependent filtering (rejecting the packet from Y1:= y1).

=

3. Subsequently, when Peer2 send= s its UDP packet (as part of the
hole punching) from (X2,x2) to (= Y1,y1), NAT2 modifies the
external port of this packet to y3, sin= ce y2 is already allocated
due to the previous unsolicited packet= .

This is surprising. If the mapping= is truly endpoint-independent, it shouldn't matter if X2:x2 is sending= to Y1:y1, it should use the existing (endpoint-independent) Y2:y2 mapping.=

How prevalent is this situation?

=C2=A0
I think the reason is that Linux IPTables/Netfilter implements endpoi= ng-independent mapping=C2=A0
that conforms with the following des= criptions from RFC7857:

         If destination addresses and ports are different for outgoing
         connections started by local clients, a NAT MAY assign the same
         external port as the source ports for the connections.  The
         port overlapping mechanism manages mappings between external
         packets and internal packets by looking at and storing their
         5-tuple (protocol, source address, source port, destination
         address, and destination port).

As a result, when the packet from (Y1,y1= ) reaches NAT2, even though (Y2,y2) is allocated for (X2,x2),
it = can still be shared at this point since the remote addresses differ (STUN f= or the first flow, (Y1,y1) for the second one).
However, when (X2= ,x2) subsequently sends a packet to (Y1,y1), it no longer can be shared as = there's a collision
on the entire tuple.

=
It's hard for me to know how prevalent this is, but to me the fact= that is (a) described in the RFC, and (b) is sort of the default
behavior on Linux, suggest this might be not too rare.

=C2=A0
=C2=A0
When this packet reaches
NAT1, it cannot traver= se it since the source port y3, is
different than the port for wh= ich the hole in NAT1 has been
punched.=C2=A0 Note that had the un= solicited packet not be previously
received, the external port wo= uld not be modified, since the NAT
implements endpoint-independen= t mappings.

This prevents direct P2P connectivity.=

I believe one semi-standard solution to this appr= oach is to begin
the hole punching by sending packets with short = TTL numbers,
which would guarantee that a hole in each peer's= NAT is punched
before any incoming packets arrive. This would pr= event the above
scenario of unsolicited packets creating erroneou= s bindings in
the NAT that prevent succesful hole punching.
=
Obviously there are a lot of details that need to be fleshed out = (e.g.,=C2=A0
which TTL to use, double NAT etc.) but hopefully som= e additional=C2=A0
cases could result in a P2P connection.
<= /div>

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--0000000000003899420572bdc48f-- From nobody Sun Aug 5 23:04:22 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5EF130DE6 for ; Sun, 5 Aug 2018 23:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH7J0Wi4hbwA for ; Sun, 5 Aug 2018 23:04:16 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC942126DBF for ; Sun, 5 Aug 2018 23:04:16 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 72-v6so15899536itw.3 for ; Sun, 05 Aug 2018 23:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IgrsQ8SVUsHQQW6zlUqdN2qYXAGi1U8c4D69AdV1Auo=; b=SW6aw9n6AynE/VMkG5AfrIw8vCCxko1o5UMPFaHUBhJ34aWfXPpQGAaZUnim+3lIw+ lJDtD16l+LPUxFk/HiY5sgd3uxGS6MJmL97QWhkclhw3YnyLq71J1Vt+ZFRePR8cA9xh 6ts+5CWYr/OXPxNIV+FfrmMVvpolWnq55u/xLNC9pZZAJm1cJuZla8/mblrs/ud1c2Oj sIt1Fo75EPKlHhyTYnQoUW/CHWUIVMwvcue40hwfksmvWeRZHvHHEG05DMbt8R6Vbnix IRZVrkEIqWjHURon9WPdB9ESLLEde+s8eV+XWq401bXB1/dnM8pyGZUqg295En2FiBKB jqEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IgrsQ8SVUsHQQW6zlUqdN2qYXAGi1U8c4D69AdV1Auo=; b=CvzoH6MPrf1iSpOTq4UdUnQAHyRUJKUXakA7ZUh/tYz3rULulel4HqZdXC5Q2VqLaq nXsxsxYRJ0QZBqzdgJoU3tNiQ6BWVusWvV6ODEIUrRaUEI08qeQq3hjSLTkDfloaltQj LoIIhb604ZMqd+EZb5VU+WHXDW9UKmOJ3K+oHD5+AWDkF/OHCE9GlBbuHOg8mFDWisz9 hnUy4VWDs9qbpCiP35Aw6bCxTnkW8laoU6cfXRjpS+qhoOI1gEJYl2JH3AEexbnXEdxh FN8TQ+qplO9CgH0+jPDcZFrWlaZxd5k1g6k/bFhejs3Oy6FZQD8qPL0sppM7Sb3alvnw SVgg== X-Gm-Message-State: AOUpUlH0t1nCaXvjcsJYKsneJ5eUTnvjFNYUcSJK5uXhJ3dM7KPMEk+b 9pftuM7PCC6rIR9wrsfkdwBjVdNdM5RZhSQ47PtAIw== X-Google-Smtp-Source: AAOMgpfiguIt8YEqmahaiVLP0pPh1Kq+YzMIBi5yEVpqXiZzrcs1H4BRO9hZWloeKgYMw6YGCLilYPbyXj8z5Yr8k7U= X-Received: by 2002:a24:ce81:: with SMTP id v123-v6mr13602547itg.119.1533535455466; Sun, 05 Aug 2018 23:04:15 -0700 (PDT) MIME-Version: 1.0 References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> In-Reply-To: From: Justin Uberti Date: Sun, 5 Aug 2018 23:04:03 -0700 Message-ID: To: dkogan@cs.stanford.edu Cc: ice@ietf.org Content-Type: multipart/alternative; boundary="0000000000001395c80572be0cb5" Archived-At: Subject: Re: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 06:04:20 -0000 --0000000000001395c80572be0cb5 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 5, 2018 at 10:44 PM Dima Kogan wrote: > > > On Sun, Aug 5, 2018 at 10:05 PM Justin Uberti wrote: > >> The section in that RFC refers to port preservation for local (internal) >> clients, and doesn't say anything about packets from external addresses. >> >> Generally, I think that the packet inbound from Y1:y1 to Y2:y2 will >> simply be discarded by the endpoint-specific filtering behavior. This >> packet shouldn't cause any change to the existing mapping or cause one to >> be created (or else this technique could be used from the outside to >> exhaust ports on the NAT). >> > > Thank you for taking the time to answer my questions. > > I'm not 100% sure but maybe the creation of the mapping is triggered by > the outgoing ICMP error. > I've first asked this question on the netfilter forum, and a few people > have confirmed this behavior ( > https://www.spinics.net/lists/netfilter/msg58234.html). (I've also > attached a script reproducing it in my other message). > Interesting. So, once the remote STUN message has been received by the NAT, and the ICMP error sent, future STUN messages sent from X2:x2 to the STUN server will yield the port Y2:y3? > I agree that it looks like the Linux behavior here could cause other > trouble as well (like the port exhaustion), and perhaps this is why the > good way to configure a NAT is to add the DROP rule on the incoming packets > (which would solve all trouble). > I guess I'm curios what's the right way to look at this scenario in which > a DROP rule is not present, and this behavior appears: > A) This is a corner case which, similarly to probably dozen other weird > NAT behaviors, not worth the effort for ICE. > B) Iptables should be changed to behave differently even without the DROP > rule. > C) It's worth working around it in ICE > In the absence of data indicating this is a widespread issue, I'm inclined to file this under a). > > I don't know who would have such data, but are there stats about how often > peers that are classified by STUN as being endpoint-independent still fail > to create a P2P connection? > This data would indeed be hard to come by, since classification is fairly flaky (as noted in the specs), and ICE success depends on the interaction between the two NATs, so attribution of errors would be challenging. That said, you might be able to use the inconsistent STUN address mentioned above to test for this specific behavior. > > > > >> >> >> On Sun, Aug 5, 2018 at 7:55 PM Dima Kogan wrote: >> >>> Sorry, hit send prematurely. >>> >>> On Sun, Aug 5, 2018 at 7:48 PM Dima Kogan >>> wrote: >>> >>>> On Sun, Aug 5, 2018 at 6:12 PM Justin Uberti >>>> wrote: >>>> >>>>> On Fri, Aug 3, 2018 at 10:12 PM Dima Kogan >>>>> wrote: >>>>> >>>>>> While experimenting with ICE NAT traversal, I came across a class >>>>>> of network configurations that currently does not result in a >>>>>> direct P2P connection (but rather falls back to TURN), yet I >>>>>> believe it could be in principle. I wanted to ask whether the >>>>>> limitation for this kind of configurations is ''known to the ICE >>>>>> community'', and how do you view the trade-off of supporting it. >>>>>> >>>>>> Specifically, the configuration is where both peers are behind a >>>>>> NAT which implements >>>>>> * endpoint-independent mappings, >>>>>> * endpoint-dependent filtering, and >>>>>> * does not drop all unsolicited incoming packets, but rather generated >>>>>> ICMP unreachable replies. >>>>>> >>>>>> An example for such a configuration is Linux Iptables with a >>>>>> MASQUERADE >>>>>> rule on the FORWARD chain, yet without a DROP rule on the INPUT chain. >>>>>> >>>>>> In this configuration the following scenario can happen: >>>>>> >>>>>> 1. Both peers learn their external IP address and port from a >>>>>> STUN server. Assume that Peer1 binds local >>>>>> address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), >>>>>> and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). >>>>>> >>>>>> 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the >>>>>> hole punching), and this packet reaches NAT2 *before* Peer 2 >>>>>> sends an outgoing packet to (Y1,y1). In this case, since NAT2 >>>>>> implements endpoint-dependent filtering, NAT2 does not forward >>>>>> the packet to Peer2 (this is expected). However, if NAT2 does not >>>>>> drop the incoming packet, but rather generates an ICMP packet in >>>>>> reply, the flow >>>>>> (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a >>>>>> Null Binding in Netfilter terminology). >>>>>> >>>>> >>>>> OK. Since Y2:y2 has already been allocated as the endpoint-independent >>>>> mapping for X2:x2 (by virtue of sending a packet from X2:x2 to a STUN >>>>> server), this is simply an application of endpoint-dependent filtering >>>>> (rejecting the packet from Y1:y1). >>>>> >>>>> >>>>>> 3. Subsequently, when Peer2 sends its UDP packet (as part of the >>>>>> hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the >>>>>> external port of this packet to y3, since y2 is already allocated >>>>>> due to the previous unsolicited packet. >>>>>> >>>>> >>>>> This is surprising. If the mapping is truly endpoint-independent, it >>>>> shouldn't matter if X2:x2 is sending to Y1:y1, it should use the existing >>>>> (endpoint-independent) Y2:y2 mapping. >>>>> >>>>> How prevalent is this situation? >>>>> >>>> >>>> >>> I think the reason is that Linux IPTables/Netfilter implements >>> endpoing-independent mapping >>> that conforms with the following descriptions from RFC7857: >>> >>> If destination addresses and ports are different for outgoing >>> connections started by local clients, a NAT MAY assign the same >>> external port as the source ports for the connections. The >>> port overlapping mechanism manages mappings between external >>> packets and internal packets by looking at and storing their >>> 5-tuple (protocol, source address, source port, destination >>> address, and destination port). >>> >>> >>> As a result, when the packet from (Y1,y1) reaches NAT2, even though >>> (Y2,y2) is allocated for (X2,x2), >>> it can still be shared at this point since the remote addresses differ >>> (STUN for the first flow, (Y1,y1) for the second one). >>> However, when (X2,x2) subsequently sends a packet to (Y1,y1), it no >>> longer can be shared as there's a collision >>> on the entire tuple. >>> >>> It's hard for me to know how prevalent this is, but to me the fact that >>> is (a) described in the RFC, and (b) is sort of the default >>> behavior on Linux, suggest this might be not too rare. >>> >>> >>>> >>>>> >>>>> >>>>>> When this packet reaches >>>>>> NAT1, it cannot traverse it since the source port y3, is >>>>>> different than the port for which the hole in NAT1 has been >>>>>> punched. Note that had the unsolicited packet not be previously >>>>>> received, the external port would not be modified, since the NAT >>>>>> implements endpoint-independent mappings. >>>>>> >>>>>> This prevents direct P2P connectivity. >>>>>> >>>>>> I believe one semi-standard solution to this approach is to begin >>>>>> the hole punching by sending packets with short TTL numbers, >>>>>> which would guarantee that a hole in each peer's NAT is punched >>>>>> before any incoming packets arrive. This would prevent the above >>>>>> scenario of unsolicited packets creating erroneous bindings in >>>>>> the NAT that prevent succesful hole punching. >>>>>> Obviously there are a lot of details that need to be fleshed out >>>>>> (e.g., >>>>>> which TTL to use, double NAT etc.) but hopefully some additional >>>>>> cases could result in a P2P connection. >>>>>> >>>>>> _______________________________________________ >>>>>> Ice mailing list >>>>>> Ice@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ice >>>>>> >>>>> --0000000000001395c80572be0cb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Aug 5, 2018 at 10:44 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:


On Sun, Aug 5, 2018 at 10:05 PM Justin Uberti <juberti@google.com> wrote:
The section in that RFC= refers to port preservation for local (internal) clients, and doesn't = say anything about packets from external addresses.

Gene= rally, I think that the packet inbound from Y1:y1 to Y2:y2 will simply be d= iscarded by the endpoint-specific filtering behavior. This packet shouldn&#= 39;t cause any change to the existing mapping or cause one to be created (o= r else this technique could be used from the outside to exhaust ports on th= e NAT).

Thank you for takin= g the time to answer my questions.=C2=A0
=C2=A0
I&#= 39;m not 100% sure but maybe the creation of the mapping is triggered by th= e outgoing ICMP error.
I've first asked this question on the = netfilter forum, and a few people have confirmed this behavior (ht= tps://www.spinics.net/lists/netfilter/msg58234.html). (I've also at= tached a script reproducing it in my other message).=C2=A0

Interesting. So, once the remote STUN mes= sage has been received by the NAT, and the ICMP error sent, future STUN mes= sages sent from X2:x2 to the STUN server will yield the port Y2:y3?
=C2=A0
I agree that it looks like the Linux behav= ior here could cause other trouble as well (like the port exhaustion), and = perhaps this is why the good way to configure a NAT is to add the DROP rule= on the incoming packets (which would solve all trouble).
I guess= I'm curios what's the right way to look at this scenario in which = a DROP rule is not present, and this behavior appears:
A) This is= a corner case which, similarly to probably dozen other weird NAT behaviors= , not worth the effort for ICE.
B) Iptables should be changed to = behave differently even without the DROP rule.=C2=A0
C) It's = worth working around it in ICE

In the absence of data indicating this is a widespread issue, I'm= inclined to file this under a).=C2=A0
=

I don't= know who would have such data, but are there stats about how often peers t= hat are classified by STUN as being endpoint-independent still fail to crea= te a P2P connection?

This= data would indeed be hard to come by, since classification is fairly flaky= (as noted in the specs), and ICE success depends on the interaction betwee= n the two NATs, so attribution of errors would be challenging. That said, y= ou might be able to use the inconsistent STUN address mentioned above to te= st for this specific behavior.


=C2= =A0


On Sun, Aug 5= , 2018 at 7:55 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:
Sorry, hit send prematurely.

<= div class=3D"gmail_quote">
On Sun, Aug 5, 2018 at 7:48 PM D= ima Kogan <d= kogan@cs.stanford.edu> wrote:
On Sun, Aug = 5, 2018 at 6:12 PM Justin Uberti <juberti@google.com> wrote:
On Fri, Aug 3, 2018 at 10:12 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:
While experimenting with ICE NAT traversa= l, I came across a class
of network configurations that currently= does not result in a
direct P2P connection (but rather falls bac= k to TURN), yet I
believe it could be in principle. I wanted to a= sk whether the
limitation for this kind of configurations is '= ;'known to the ICE
community'', and how do you view t= he trade-off of supporting it.

Specifically,= the configuration is where both peers are behind a
NAT which imp= lements
* endpoint-independent mappings,
* endpoint-dep= endent filtering, and
* does not drop all unsolicited incoming pa= ckets, but rather generated
=C2=A0 ICMP unreachable replies.

An example for such a configuration is Linux Iptables = with a MASQUERADE
rule on the FORWARD chain, yet without a DROP r= ule on the INPUT chain.

In this configuration the = following scenario can happen:

1. Both peers learn= their external IP address and port from a
STUN server.=C2=A0 Ass= ume that Peer1 binds local
address/port (X1,x1), which gets mappe= d by NAT1 to (Y1,y1),
and for Peer2 binds (X2,x2), which gets map= ped by NAT2 to (Y2,y2).

2. Peer 1 sends an outgoin= g UDP packet to (Y2,y2) (as part of the
hole punching), and this = packet reaches NAT2 *before* Peer 2
sends an outgoing packet to (= Y1,y1). In this case, since NAT2
implements endpoint-dependent fi= ltering, NAT2 does not forward
the packet to Peer2 (this is expec= ted). However, if NAT2 does not
drop the incoming packet, but rat= her generates an ICMP packet in
reply, the flow
(Y1,y1)= <-->(Y2,y2) gets allocated (I believe this is called a
Null= Binding in Netfilter terminology).

OK= . Since Y2:y2 has already been allocated as the endpoint-independent mappin= g for X2:x2 (by virtue of sending a packet from X2:x2 to a STUN server), th= is is simply an application of endpoint-dependent filtering (rejecting the = packet from Y1:y1).


3. Subsequently, = when Peer2 sends its UDP packet (as part of the
hole punching) fr= om (X2,x2) to (Y1,y1), NAT2 modifies the
external port of this pa= cket to y3, since y2 is already allocated
due to the previous uns= olicited packet.

=
This is surprising. = If the mapping is truly endpoint-independent, it shouldn't matter if X2= :x2 is sending to Y1:y1, it should use the existing (endpoint-independent) = Y2:y2 mapping.

How prevalent is this situation?

= =C2=A0
I think the reason is that Linux IPTables/Netfilter i= mplements endpoing-independent mapping=C2=A0
that conforms with t= he following descriptions from RFC7857:

         If destin=
ation addresses and ports are different for outgoing
         connections started by local clients, a NAT MAY assign the same
         external port as the source ports for the connections.  The
         port overlapping mechanism manages mappings between external
         packets and internal packets by looking at and storing their
         5-tuple (protocol, source address, source port, destination
         address, and destination port).

As a result, when t= he packet from (Y1,y1) reaches NAT2, even though (Y2,y2) is allocated for (= X2,x2),
it can still be shared at this point since the remote add= resses differ (STUN for the first flow, (Y1,y1) for the second one).
<= div>However, when (X2,x2) subsequently sends a packet to (Y1,y1), it no lon= ger can be shared as there's a collision
on the entire tuple.=

It's hard for me to know how prevalent this i= s, but to me the fact that is (a) described in the RFC, and (b) is sort of = the default
behavior on Linux, suggest this might be not too rare= .

=C2=A0
=C2=A0
When this packet reaches
N= AT1, it cannot traverse it since the source port y3, is
different= than the port for which the hole in NAT1 has been
punched.=C2=A0= Note that had the unsolicited packet not be previously
received,= the external port would not be modified, since the NAT
implement= s endpoint-independent mappings.

This prevents dir= ect P2P connectivity.

I believe one semi-standard = solution to this approach is to begin
the hole punching by sendin= g packets with short TTL numbers,
which would guarantee that a ho= le in each peer's NAT is punched
before any incoming packets = arrive. This would prevent the above
scenario of unsolicited pack= ets creating erroneous bindings in
the NAT that prevent succesful= hole punching.
Obviously there are a lot of details that ne= ed to be fleshed out (e.g.,=C2=A0
which TTL to use, double NAT et= c.) but hopefully some additional=C2=A0
cases could result in a P= 2P connection.

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--0000000000001395c80572be0cb5-- From nobody Mon Aug 6 00:28:54 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A339E130DD6 for ; Mon, 6 Aug 2018 00:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4ecJHbmbg_9 for ; Mon, 6 Aug 2018 00:28:48 -0700 (PDT) Received: from smtp1.cs.Stanford.EDU (smtp1.cs.stanford.edu [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD40130DFF for ; Mon, 6 Aug 2018 00:28:48 -0700 (PDT) Received: from mail-lj1-f181.google.com ([209.85.208.181]:36536) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fmZwa-0006wq-Su for ice@ietf.org; Mon, 06 Aug 2018 00:28:47 -0700 Received: by mail-lj1-f181.google.com with SMTP id u7-v6so9762166lji.3 for ; Mon, 06 Aug 2018 00:28:44 -0700 (PDT) X-Gm-Message-State: AOUpUlE3MRJ9bwGGPYmaRfzXQtLUTr82t194jsgzpVPJxl/Rd5FNk+Yi G1BDRTrnyGHKV16G6GH5cQ0Zs619zeP2rLLmWVI= X-Google-Smtp-Source: AAOMgpe5oyswg349osSsUXn0yYHTm8jYvtCXw/4jEBF6SH+zJim1MHSz7Z60iqNd6/uV24Qt1iIYaWAhHZddkxrdWIU= X-Received: by 2002:a2e:1dc8:: with SMTP id w69-v6mr12541783lje.110.1533540523140; Mon, 06 Aug 2018 00:28:43 -0700 (PDT) MIME-Version: 1.0 References: <10550970-d233-4a3a-95f5-02f0af7778a5@googlegroups.com> In-Reply-To: From: Dima Kogan Date: Mon, 6 Aug 2018 00:28:31 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: ice@ietf.org Content-Type: multipart/alternative; boundary="000000000000216d320572bf3a7c" X-Scan-Signature: 8bc6f13ecd31f193cde6200ee3b4b62b Archived-At: Subject: Re: [Ice] NAT UDP Hole punching - question about a particular configuration X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 07:28:51 -0000 --000000000000216d320572bf3a7c Content-Type: text/plain; charset="UTF-8" On Sun, Aug 5, 2018 at 11:04 PM Justin Uberti wrote: > On Sun, Aug 5, 2018 at 10:44 PM Dima Kogan wrote: > >> >> >> On Sun, Aug 5, 2018 at 10:05 PM Justin Uberti wrote: >> >>> The section in that RFC refers to port preservation for local (internal) >>> clients, and doesn't say anything about packets from external addresses. >>> >>> Generally, I think that the packet inbound from Y1:y1 to Y2:y2 will >>> simply be discarded by the endpoint-specific filtering behavior. This >>> packet shouldn't cause any change to the existing mapping or cause one to >>> be created (or else this technique could be used from the outside to >>> exhaust ports on the NAT). >>> >> >> Thank you for taking the time to answer my questions. >> >> I'm not 100% sure but maybe the creation of the mapping is triggered by >> the outgoing ICMP error. >> I've first asked this question on the netfilter forum, and a few people >> have confirmed this behavior ( >> https://www.spinics.net/lists/netfilter/msg58234.html). (I've also >> attached a script reproducing it in my other message). >> > > Interesting. So, once the remote STUN message has been received by the > NAT, and the ICMP error sent, future STUN messages sent from X2:x2 to the > STUN server will yield the port Y2:y3? > Yes, that's a good way to confirm this. Here's a trace of my STUN execution: >>>> STUN test 1 to 217.10.68.152:3478 gets the port 50000 preserved [NEW] udp 17 30 src=100.64.0.2 dst=217.10.68.152 sport=50000 dport=3478 [UNREPLIED] src=217.10.68.152 dst=172.31.6.83 sport=3478 dport=50000 mark=29512 [UPDATE] udp 17 29 src=100.64.0.2 dst=217.10.68.152 sport=50000 dport=3478 src=217.10.68.152 dst=172.31.6.83 sport=3478 dport=50000 mark=29512 >>>> STUN test 2 begins (same destination, but STUN request now has change_address =1, change_port=1) [UPDATE] udp 17 180 src=100.64.0.2 dst=217.10.68.152 sport=50000 dport=3478 src=217.10.68.152 dst=172.31.6.83 sport=3478 dport=50000 [ASSURED] mark=29512 >>>> the reply comes back from a different address, get filtered, but creates the overloaded mapping on port 50000 [NEW] udp 17 30 src=217.116.122.137 dst=172.31.6.83 sport=3479 dport=50000 [UNREPLIED] src=172.31.6.83 dst=217.116.122.137 sport=50000 dport=3479 >>>> STUN test 3 sends to the second address, and gets a new port (1024) due to the collision [NEW] udp 17 30 src=100.64.0.2 dst=217.116.122.137 sport=50000 dport=3479 [UNREPLIED] src=217.116.122.137 dst=172.31.6.83 sport=3479 dport=1024 mark=29512 > > >> I agree that it looks like the Linux behavior here could cause other >> trouble as well (like the port exhaustion), and perhaps this is why the >> good way to configure a NAT is to add the DROP rule on the incoming packets >> (which would solve all trouble). >> I guess I'm curios what's the right way to look at this scenario in which >> a DROP rule is not present, and this behavior appears: >> A) This is a corner case which, similarly to probably dozen other weird >> NAT behaviors, not worth the effort for ICE. >> B) Iptables should be changed to behave differently even without the DROP >> rule. >> C) It's worth working around it in ICE >> > > In the absence of data indicating this is a widespread issue, I'm inclined > to file this under a). > >> >> I don't know who would have such data, but are there stats about how >> often peers that are classified by STUN as being endpoint-independent still >> fail to create a P2P connection? >> > > This data would indeed be hard to come by, since classification is fairly > flaky (as noted in the specs), and ICE success depends on the interaction > between the two NATs, so attribution of errors would be challenging. That > said, you might be able to use the inconsistent STUN address mentioned > above to test for this specific behavior. > Yes, I guess that a reasonable heuristic is if the local port gets preserved when talking to the first STUN server, and then gets modified when talking to the second server (though to handle the case when the first port is modified (but would have remained consistent for outgoing connections), one should probably use 3 remote STUN addresses). > >> >> >> >>> >>> >>> On Sun, Aug 5, 2018 at 7:55 PM Dima Kogan >>> wrote: >>> >>>> Sorry, hit send prematurely. >>>> >>>> On Sun, Aug 5, 2018 at 7:48 PM Dima Kogan >>>> wrote: >>>> >>>>> On Sun, Aug 5, 2018 at 6:12 PM Justin Uberti >>>>> wrote: >>>>> >>>>>> On Fri, Aug 3, 2018 at 10:12 PM Dima Kogan >>>>>> wrote: >>>>>> >>>>>>> While experimenting with ICE NAT traversal, I came across a class >>>>>>> of network configurations that currently does not result in a >>>>>>> direct P2P connection (but rather falls back to TURN), yet I >>>>>>> believe it could be in principle. I wanted to ask whether the >>>>>>> limitation for this kind of configurations is ''known to the ICE >>>>>>> community'', and how do you view the trade-off of supporting it. >>>>>>> >>>>>>> Specifically, the configuration is where both peers are behind a >>>>>>> NAT which implements >>>>>>> * endpoint-independent mappings, >>>>>>> * endpoint-dependent filtering, and >>>>>>> * does not drop all unsolicited incoming packets, but rather >>>>>>> generated >>>>>>> ICMP unreachable replies. >>>>>>> >>>>>>> An example for such a configuration is Linux Iptables with a >>>>>>> MASQUERADE >>>>>>> rule on the FORWARD chain, yet without a DROP rule on the INPUT >>>>>>> chain. >>>>>>> >>>>>>> In this configuration the following scenario can happen: >>>>>>> >>>>>>> 1. Both peers learn their external IP address and port from a >>>>>>> STUN server. Assume that Peer1 binds local >>>>>>> address/port (X1,x1), which gets mapped by NAT1 to (Y1,y1), >>>>>>> and for Peer2 binds (X2,x2), which gets mapped by NAT2 to (Y2,y2). >>>>>>> >>>>>>> 2. Peer 1 sends an outgoing UDP packet to (Y2,y2) (as part of the >>>>>>> hole punching), and this packet reaches NAT2 *before* Peer 2 >>>>>>> sends an outgoing packet to (Y1,y1). In this case, since NAT2 >>>>>>> implements endpoint-dependent filtering, NAT2 does not forward >>>>>>> the packet to Peer2 (this is expected). However, if NAT2 does not >>>>>>> drop the incoming packet, but rather generates an ICMP packet in >>>>>>> reply, the flow >>>>>>> (Y1,y1)<-->(Y2,y2) gets allocated (I believe this is called a >>>>>>> Null Binding in Netfilter terminology). >>>>>>> >>>>>> >>>>>> OK. Since Y2:y2 has already been allocated as the >>>>>> endpoint-independent mapping for X2:x2 (by virtue of sending a packet from >>>>>> X2:x2 to a STUN server), this is simply an application of >>>>>> endpoint-dependent filtering (rejecting the packet from Y1:y1). >>>>>> >>>>>> >>>>>>> 3. Subsequently, when Peer2 sends its UDP packet (as part of the >>>>>>> hole punching) from (X2,x2) to (Y1,y1), NAT2 modifies the >>>>>>> external port of this packet to y3, since y2 is already allocated >>>>>>> due to the previous unsolicited packet. >>>>>>> >>>>>> >>>>>> This is surprising. If the mapping is truly endpoint-independent, it >>>>>> shouldn't matter if X2:x2 is sending to Y1:y1, it should use the existing >>>>>> (endpoint-independent) Y2:y2 mapping. >>>>>> >>>>>> How prevalent is this situation? >>>>>> >>>>> >>>>> >>>> I think the reason is that Linux IPTables/Netfilter implements >>>> endpoing-independent mapping >>>> that conforms with the following descriptions from RFC7857: >>>> >>>> If destination addresses and ports are different for outgoing >>>> connections started by local clients, a NAT MAY assign the same >>>> external port as the source ports for the connections. The >>>> port overlapping mechanism manages mappings between external >>>> packets and internal packets by looking at and storing their >>>> 5-tuple (protocol, source address, source port, destination >>>> address, and destination port). >>>> >>>> >>>> As a result, when the packet from (Y1,y1) reaches NAT2, even though >>>> (Y2,y2) is allocated for (X2,x2), >>>> it can still be shared at this point since the remote addresses differ >>>> (STUN for the first flow, (Y1,y1) for the second one). >>>> However, when (X2,x2) subsequently sends a packet to (Y1,y1), it no >>>> longer can be shared as there's a collision >>>> on the entire tuple. >>>> >>>> It's hard for me to know how prevalent this is, but to me the fact that >>>> is (a) described in the RFC, and (b) is sort of the default >>>> behavior on Linux, suggest this might be not too rare. >>>> >>>> >>>>> >>>>>> >>>>>> >>>>>>> When this packet reaches >>>>>>> NAT1, it cannot traverse it since the source port y3, is >>>>>>> different than the port for which the hole in NAT1 has been >>>>>>> punched. Note that had the unsolicited packet not be previously >>>>>>> received, the external port would not be modified, since the NAT >>>>>>> implements endpoint-independent mappings. >>>>>>> >>>>>>> This prevents direct P2P connectivity. >>>>>>> >>>>>>> I believe one semi-standard solution to this approach is to begin >>>>>>> the hole punching by sending packets with short TTL numbers, >>>>>>> which would guarantee that a hole in each peer's NAT is punched >>>>>>> before any incoming packets arrive. This would prevent the above >>>>>>> scenario of unsolicited packets creating erroneous bindings in >>>>>>> the NAT that prevent succesful hole punching. >>>>>>> Obviously there are a lot of details that need to be fleshed out >>>>>>> (e.g., >>>>>>> which TTL to use, double NAT etc.) but hopefully some additional >>>>>>> cases could result in a P2P connection. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ice mailing list >>>>>>> Ice@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ice >>>>>>> >>>>>> --000000000000216d320572bf3a7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Aug 5, 2018 at 11:04 PM Justin Uberti <juberti@google.com> wrote:
On Sun, = Aug 5, 2018 at 10:44 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:


On Sun, Aug 5, 2018 at 10:05 PM Justin Uberti <juberti@google.com&= gt; wrote:
The sec= tion in that RFC refers to port preservation for local (internal) clients, = and doesn't say anything about packets from external addresses.
Generally, I think that the packet inbound from Y1:y1 to Y2:y2 = will simply be discarded by the endpoint-specific filtering behavior. This = packet shouldn't cause any change to the existing mapping or cause one = to be created (or else this technique could be used from the outside to exh= aust ports on the NAT).

Tha= nk you for taking the time to answer my questions.=C2=A0
=C2=A0
I'm not 100% sure but maybe the creation of the mapping is= triggered by the outgoing ICMP error.
I've first asked this = question on the netfilter forum, and a few people have confirmed this behav= ior (https://www.spinics.net/lists/netfilter/msg58234.html). (= I've also attached a script reproducing it in my other message).=C2=A0<= /div>

<= div class=3D"gmail_quote">
Interesting. So, once the remote STUN messag= e has been received by the NAT, and the ICMP error sent, future STUN messag= es sent from X2:x2 to the STUN server will yield the port Y2:y3?

Yes, that's a good way to confi= rm this. Here's a trace of my STUN execution:

= >>>> STUN test 1 to 217.1= 0.68.152:3478 gets the port 50000 preserved

[N= EW] udp=C2=A0 =C2=A0 =C2=A0 17 30 src=3D100.64.0.2 dst=3D217.10.68.152 spor= t=3D50000 dport=3D3478 [UNREPLIED] src=3D217.10.68.152 dst=3D172.31.6.83 sp= ort=3D3478 dport=3D50000 mark=3D29512=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
[UPDATE] udp=C2=A0 =C2= =A0 =C2=A0 17 29 src=3D100.64.0.2 dst=3D217.10.68.152 sport=3D50000 dport= =3D3478 src=3D217.10.68.152 dst=3D172.31.6.83 sport=3D3478 dport=3D50000 ma= rk=3D29512

>>>> STUN test 2 begins (sa= me destination, but STUN request now has change_address =3D1, change_port= =3D1)

[UPDATE] udp=C2=A0 =C2=A0 =C2=A0 17 180 src= =3D100.64.0.2 dst=3D217.10.68.152 sport=3D50000 dport=3D3478 src=3D217.10.6= 8.152 dst=3D172.31.6.83 sport=3D3478 dport=3D50000 [ASSURED] mark=3D29512= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0

>>>> the reply comes back f= rom a different address, get filtered, but creates the overloaded mapping o= n port 50000

[NEW] udp=C2=A0 =C2=A0 =C2=A0 17 30 s= rc=3D217.116.122.137 dst=3D172.31.6.83 sport=3D3479 dport=3D50000 [UNREPLIE= D] src=3D172.31.6.83 dst=3D217.116.122.137 sport=3D50000 dport=3D3479
=

>>>> STUN test 3 sends to the second addres= s, and gets a new port (1024) due to the collision=C2=A0 =C2=A0 =C2=A0 =C2= =A0
[NEW] udp=C2=A0 =C2=A0 =C2=A0 17 30 src=3D100.64.0.2 dst=3D21= 7.116.122.137 sport=3D50000 dport=3D3479 [UNREPLIED] src=3D217.116.122.137 = dst=3D172.31.6.83 sport=3D3479 dport=3D1024 mark=3D29512=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

= =C2=A0
=C2=A0
I agree that it looks like the= Linux behavior here could cause other trouble as well (like the port exhau= stion), and perhaps this is why the good way to configure a NAT is to add t= he DROP rule on the incoming packets (which would solve all trouble).
=
I guess I'm curios what's the right way to look at this scenar= io in which a DROP rule is not present, and this behavior appears:
A) This is a corner case which, similarly to probably dozen other weird N= AT behaviors, not worth the effort for ICE.
B) Iptables should be= changed to behave differently even without the DROP rule.=C2=A0
= C) It's worth working around it in ICE

I= n the absence of data indicating this is a widespread issue, I'm inclin= ed to file this under a).=C2=A0

I don't know who would have such = data, but are there stats about how often peers that are classified by STUN= as being endpoint-independent still fail to create a P2P connection?
=

This data would indeed be hard to come by, since = classification is fairly flaky (as noted in the specs), and ICE success dep= ends on the interaction between the two NATs, so attribution of errors woul= d be challenging. That said, you might be able to use the inconsistent STUN= address mentioned above to test for this specific behavior.

Yes, I guess that a reasonable heuristi= c is if the local port gets preserved when talking to the first STUN server= , and then gets modified when talking to the second server (though to handl= e the case when the first port is modified (but would have remained consist= ent for outgoing connections), one should probably use 3 remote STUN addres= ses).
=C2=A0


=C2=A0
=

<= /div>
On Sun, Aug 5, 2018 at= 7:55 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:
Sorry, hit send prematurely.

On Sun, Aug 5, 2018 at 7:48 PM Dima Kog= an <dkogan@c= s.stanford.edu> wrote:
On Sun, Aug 5, 2018= at 6:12 PM Justin Uberti <juberti@google.com> wrote:
On = Fri, Aug 3, 2018 at 10:12 PM Dima Kogan <dkogan@cs.stanford.edu> wrote:
While experimenting with ICE NAT traversal, I c= ame across a class
of network configurations that currently does = not result in a
direct P2P connection (but rather falls back to T= URN), yet I
believe it could be in principle. I wanted to ask whe= ther the
limitation for this kind of configurations is ''= known to the ICE
community'', and how do you view the tra= de-off of supporting it.

Specifically, the c= onfiguration is where both peers are behind a
NAT which implement= s
* endpoint-independent mappings,
* endpoint-dependent= filtering, and
* does not drop all unsolicited incoming packets,= but rather generated
=C2=A0 ICMP unreachable replies.
=
An example for such a configuration is Linux Iptables with a= MASQUERADE
rule on the FORWARD chain, yet without a DROP rule on= the INPUT chain.

In this configuration the follow= ing scenario can happen:

1. Both peers learn their= external IP address and port from a
STUN server.=C2=A0 Assume th= at Peer1 binds local
address/port (X1,x1), which gets mapped by N= AT1 to (Y1,y1),
and for Peer2 binds (X2,x2), which gets mapped by= NAT2 to (Y2,y2).

2. Peer 1 sends an outgoing UDP = packet to (Y2,y2) (as part of the
hole punching), and this packet= reaches NAT2 *before* Peer 2
sends an outgoing packet to (Y1,y1)= . In this case, since NAT2
implements endpoint-dependent filterin= g, NAT2 does not forward
the packet to Peer2 (this is expected). = However, if NAT2 does not
drop the incoming packet, but rather ge= nerates an ICMP packet in
reply, the flow
(Y1,y1)<--= >(Y2,y2) gets allocated (I believe this is called a
Null Bindi= ng in Netfilter terminology).

=
OK. Sinc= e Y2:y2 has already been allocated as the endpoint-independent mapping for = X2:x2 (by virtue of sending a packet from X2:x2 to a STUN server), this is = simply an application of endpoint-dependent filtering (rejecting the packet= from Y1:y1).
=


3. Subsequently, when= Peer2 sends its UDP packet (as part of the
hole punching) from (= X2,x2) to (Y1,y1), NAT2 modifies the
external port of this packet= to y3, since y2 is already allocated
due to the previous unsolic= ited packet.

This is surprising. If t= he mapping is truly endpoint-independent, it shouldn't matter if X2:x2 = is sending to Y1:y1, it should use the existing (endpoint-independent) Y2:y= 2 mapping.

How prevalent is this situation?
<= /div>

=C2=A0=
I think the reason is that Linux IPTables/Netfilter impleme= nts endpoing-independent mapping=C2=A0
that conforms with the fol= lowing descriptions from RFC7857:

         If destination addresses and ports are differe=
nt for outgoing
         connections started by local clients, a NAT MAY assign the same
         external port as the source ports for the connections.  The
         port overlapping mechanism manages mappings between external
         packets and internal packets by looking at and storing their
         5-tuple (protocol, source address, source port, destination
         address, and destination port).

As a result, when the packet from (Y1,y1) reaches NAT2, even though (Y2,= y2) is allocated for (X2,x2),
it can still be shared at this poin= t since the remote addresses differ (STUN for the first flow, (Y1,y1) for t= he second one).
However, when (X2,x2) subsequently sends a packet= to (Y1,y1), it no longer can be shared as there's a collision
on the entire tuple.

It's hard for me to kno= w how prevalent this is, but to me the fact that is (a) described in the RF= C, and (b) is sort of the default
behavior on Linux, suggest this= might be not too rare.

=
=C2=A0
=C2=A0
When this pack= et reaches
NAT1, it cannot traverse it since the source port y3, = is
different than the port for which the hole in NAT1 has been
punched.=C2=A0 Note that had the unsolicited packet not be previous= ly
received, the external port would not be modified, since the N= AT
implements endpoint-independent mappings.

=
This prevents direct P2P connectivity.

I beli= eve one semi-standard solution to this approach is to begin
the h= ole punching by sending packets with short TTL numbers,
which wou= ld guarantee that a hole in each peer's NAT is punched
before= any incoming packets arrive. This would prevent the above
scenar= io of unsolicited packets creating erroneous bindings in
the NAT = that prevent succesful hole punching.
Obviously there are a = lot of details that need to be fleshed out (e.g.,=C2=A0
which TTL= to use, double NAT etc.) but hopefully some additional=C2=A0
cas= es could result in a P2P connection.

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--000000000000216d320572bf3a7c-- From nobody Wed Aug 22 10:59:14 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2597130DBE; Wed, 22 Aug 2018 10:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx8eKgY6Uw9Q; Wed, 22 Aug 2018 10:59:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338B1130E01; Wed, 22 Aug 2018 10:59:08 -0700 (PDT) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7MHwxF3079673 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Aug 2018 12:59:01 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at From: Adam Roach To: Applications and Real-Time Area Discussion Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" , "clue@ietf.org" Reply-To: Applications and Real-Time Area Discussion Message-ID: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> Date: Wed, 22 Aug 2018 12:58:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------25F6808114B810D3242F1D07" Content-Language: en-US Archived-At: Subject: [Ice] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 17:59:12 -0000 This is a multi-part message in MIME format. --------------25F6808114B810D3242F1D07 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Members of the ART community interested in real-time communications: Cluster 238 [1] is a set of inter-related documents dealing with real-time communications. The bulk of these documents relate to WebRTC, either directly or indirectly. They also form the underpinnings of CLUE. As of now, there are 34 documents in the cluster that are not yet published, with 25 of these already in the RFC Editor's queue. The dependency graph among these documents is such that the bulk of them can be published as soon as a specific six of them are handed off to the RFC editor, and we expect this to happen in the upcoming few months. One long-running complication for this cluster of documents is that each of the documents were developed over the course of seven years, in concert with implementations, while the ICE protocol itself was undergoing significant revision. As a consequence, some documents rely (directly or indirectly) on the older ICE specification (RFC 5245), while some rely on the newer one (RFC 8445). In some cases, documents refer directly to the old version and transitively to the new version. It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the mechanism described in RFC 8445 has some  changes that break backwards compatibility with the mechanism defined in RFC 5245 (with such behavioral changes controlled by an SDP attribute, allowing clients to transition from one to the other). Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol in the IETF) refers to directly to RFC 5245, while relying on the behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a practical consideration that acknowledges that current deployments of WebRTC implement the older version of ICE. At the same time, these deployed implementations use a somewhat older version of draft-ietf-ice-trickle in concert with the older ICE implementation. In order to get Cluster 238 published, we need to find some way to rationalize its references to ICE. At a basic level, the ART Area Directors do not believe that it makes sense to publish new documents that refer to an already obsoleted RFC. At the same time, we recognize that there is value in our specifications being informed by running code. For WebRTC, the complexity of the system has led us to a point that we must choose between these principles. Our proposal is to choose the first, while acknowledging the second. This would result in a request to the RFC editor to update all references to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445. Documents not yet in the RFC editor queue would be updated prior to IESG review. We would further request that the RFC editor add the following text to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep: > While this specification formally relies on [RFC8445], at the time of > its publication, the majority of WebRTC implementations support the > version of ICE described in [RFC5245], and use a pre-standard version > of the trickle ice mechanism described in [RFCXXXX]. The use of the > "ice2" attribute defined in [RFC8445] can be used to detect the > version in use by a remote endpoint and to provide a smooth transition > from the older specification to the newer one. RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative. There is one more minor complication, in that draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245) is intended to be an exhaustive list of the SDP attributes defined in the documents it lists, and RFC 8445 adds a new "ice2" attribute that was not present in RFC 5245. For this reason, we would also ask the RFC Editor to add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows: > +-------------------+---------------------------+-------+-----------+ > | Name | Notes | Level | Mux | > | | | | Category | > +-------------------+---------------------------+-------+-----------+ > | ice2 | Not Impacted | S | NORMAL | > | | | | | > +-------------------+---------------------------+-------+-----------+ For clarity, the affected documents are as follows. The following documents would be updated to reference RFC 8445 prior to IESG evaluation: * draft-ietf-clue-datachannel * draft-ietf-clue-signaling * draft-ietf-rtcweb-security * draft-ietf-rtcweb-security-arch The following documents would be updated to reference RFC 8445 by the RFC Editor: * draft-ietf-mmusic-mux-exclusive * draft-ietf-mmusic-sctp-sdp * draft-ietf-rtcweb-alpn * draft-ietf-rtcweb-data-channel * draft-ietf-rtcweb-rtp-usage The following documents would be updated to reference RFC 8445 and have the text proposed above added to them: * draft-ietf-rtcweb-jsep * draft-ietf-rtcweb-overview The following document would be updated to reference RFC 8445 by the RFC Editor, and include a new row for "ice2" in its Section 5.12, as described above: * draft-ietf-mmusic-sdp-mux-attributes This message is cross-posted to the affected working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on . Thank you. /Adam on behalf of the ART Area Directors ____ [1] https://www.rfc-editor.org/cluster_info.php?cid=C238 --------------25F6808114B810D3242F1D07 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Members of the ART community interested in real-time communications:

Cluster 238 [1] is a set of inter-related documents dealing with real-time communications. The bulk of these documents relate to WebRTC, either directly or indirectly. They also form the underpinnings of CLUE. As of now, there are 34 documents in the cluster that are not yet published, with 25 of these already in the RFC Editor's queue. The dependency graph among these documents is such that the bulk of them can be published as soon as a specific six of them are handed off to the RFC editor, and we expect this to happen in the upcoming few months.

One long-running complication for this cluster of documents is that each of the documents were developed over the course of seven years, in concert with implementations, while the ICE protocol itself was undergoing significant revision. As a consequence, some documents rely (directly or indirectly) on the older ICE specification (RFC 5245), while some rely on the newer one (RFC 8445). In some cases, documents refer directly to the old version and transitively to the new version.

It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the mechanism described in RFC 8445 has some  changes that break backwards compatibility with the mechanism defined in RFC 5245 (with such behavioral changes controlled by an SDP attribute, allowing clients to transition from one to the other).

Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol in the IETF) refers to directly to RFC 5245, while relying on the behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a practical consideration that acknowledges that current deployments of WebRTC implement the older version of ICE. At the same time, these deployed implementations use a somewhat older version of draft-ietf-ice-trickle in concert with the older ICE implementation.

In order to get Cluster 238 published, we need to find some way to rationalize its references to ICE. At a basic level, the ART Area Directors do not believe that it makes sense to publish new documents that refer to an already obsoleted RFC. At the same time, we recognize that there is value in our specifications being informed by running code. For WebRTC, the complexity of the system has led us to a point that we must choose between these principles. Our proposal is to choose the first, while acknowledging the second.

This would result in a request to the RFC editor to update all references to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445. Documents not yet in the RFC editor queue would be updated prior to IESG review. We would further request that the RFC editor add the following text to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep:

While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245], and use a pre-standard version of the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one.
RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative.

There is one more minor complication, in that draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245) is intended to be an exhaustive list of the SDP attributes defined in the documents it lists, and RFC 8445 adds a new "ice2" attribute that was not present in RFC 5245. For this reason, we would also ask the RFC Editor to add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows:

   +-------------------+---------------------------+-------+-----------+
   | Name              | Notes                     | Level | Mux       |
   |                   |                           |       | Category  |
   +-------------------+---------------------------+-------+-----------+
   | ice2              | Not Impacted              | S     | NORMAL    |
   |                   |                           |       |           |
   +-------------------+---------------------------+-------+-----------+

For clarity, the affected documents are as follows.

The following documents would be updated to reference RFC 8445 prior to IESG evaluation:

  • draft-ietf-clue-datachannel
  • draft-ietf-clue-signaling
  • draft-ietf-rtcweb-security
  • draft-ietf-rtcweb-security-arch


The following documents would be updated to reference RFC 8445 by the RFC Editor:

  • draft-ietf-mmusic-mux-exclusive
  • draft-ietf-mmusic-sctp-sdp
  • draft-ietf-rtcweb-alpn
  • draft-ietf-rtcweb-data-channel
  • draft-ietf-rtcweb-rtp-usage


The following documents would be updated to reference RFC 8445 and have the text proposed above added to them:

  • draft-ietf-rtcweb-jsep
  • draft-ietf-rtcweb-overview


The following document would be updated to reference RFC 8445 by the RFC Editor, and include a new row for "ice2" in its Section 5.12, as described above:

  • draft-ietf-mmusic-sdp-mux-attributes


This message is cross-posted to the affected working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on <art@ietf.org>. Thank you.

/Adam on behalf of the ART Area Directors

____
[1] https://www.rfc-editor.org/cluster_info.php?cid=C238

--------------25F6808114B810D3242F1D07-- From nobody Wed Aug 22 11:09:39 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6F8130EAA for ; Wed, 22 Aug 2018 11:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icuE4MdLgHi2 for ; Wed, 22 Aug 2018 11:09:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BF0130E40 for ; Wed, 22 Aug 2018 11:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1534961346; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XQzeC61P2ByisU+XG5pi4txz6yVLiLPUq8e5PMMjifc=; b=aqvDb/m9DZn418+lrVNX30CbGu0KBfybyrag8/SFlDNneWDuZ23p9a/9saEmsMQt nlfBFgLa6cf96gaiIqc4igW9SB6Ao1DvWu4MbfnEVBPGve2l8dtA4OmSnPJ18KjQ d3lsBIWQWA9ntAmwCqIJ50aIK6Jr3eyTFHupuUq8298=; X-AuditID: c1b4fb25-8ffff700000013ad-73-5b7da6c2bb14 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 52.8D.05037.2C6AD7B5; Wed, 22 Aug 2018 20:09:06 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 22 Aug 2018 20:09:05 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Wed, 22 Aug 2018 20:09:05 +0200 From: Christer Holmberg To: Applications and Real-Time Area Discussion CC: "clue@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" Thread-Topic: [Ice] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHUOkHZKzXpeI8yL0SodzGYYjp6aKTMEXEw Date: Wed, 22 Aug 2018 18:09:05 +0000 Message-ID: References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> In-Reply-To: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: multipart/alternative; boundary="_000_e9512339a5884c83b66bd9880d939845ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2J7me6hZbXRBo+mslusuOthsf/UZWaL bxdqLaYuf8xisfZfO7sDq8eSJT+ZAhijuGxSUnMyy1KL9O0SuDKar+1lLXi1lali4619TA2M d9YydTFyckgImEh8W38MyObiEBI4yihxdtdtNgjnG6PEh6Yl7BDOMkaJP617GLsYOTjYBCwk uv9pg3SLCNhK3Lq6GayBWaCPUeLguycsIDXCAgYSyzd6gpgiAoYSX7ZWQ5hGEmf2+IF0sgio Sqw5d40dxOYVsJb4POsGmC0kYCexv+M92G2cAvYSy559AoszCohJfD+1BizOLCAucevJfKj7 BSSW7DnPDGGLSrx8/I8VwlaS2HvsOgtEfbLEv3lbWCF2CUqcnPmEZQKj6Cwko2YhKZuFpGwW 0NXMApoS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcVJuupGxXmpRZnJxcX6eXl5q ySZGYPwd3PJbdQfj5TeOhxgFOBiVeHiXzqmNFmJNLCuuzD3EKMHBrCTC+3xzTbQQb0piZVVq UX58UWlOavEhRmkOFiVx3ofmm6OEBNITS1KzU1MLUotgskwcnFINjMZcqz813ChadPq9knD1 vJ1zM5c4fytYrNsr/3XGR/4luse2XdpdmJV85PUVgykCyyoWfzu3hW1OMbdVwMuIKZ7bj2jc btz6qX6rSsFhDQUuC4bGOYu/6DTff22Y9Vdlpghns+y9P1xWmgeXnXy06YG288t+dtmWjI8S Um1Hi+8vTlYy32WXlqHEUpyRaKjFXFScCABPkhwyuwIAAA== Archived-At: Subject: Re: [Ice] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 18:09:27 -0000 --_000_e9512339a5884c83b66bd9880d939845ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZ3Vlc3MgdGhhdCBpdCBzaG91bGRu4oCZdCBjb21lIGFzIGEgc3VycHJpc2UgdGhh dCBJIHN1cHBvcnQgQWRhbeKAmXMgc3VnZ2VzdGlvbiwgdG8gdXBkYXRlIGFsbCByZWZlcmVuY2Vz IHRvIFJGQyA4NDQ1Lg0KDQpJbiBhZGRpdGlvbiB0byB0aGUgZHJhZnRzIGxpc3RlZCBieSBBZGFt LCB0aGUgZXhhbXBsZXMgaW4gdGhlIHJ0Y3dlYi1zZHAtZXhhbXBsZXMgZHJhZnQgd291bGQgYWxz byBoYXZlIHRvIGJlIHVwZGF0ZWQgKEkgc2VudCBhbiBlLW1haWwgYWJvdXQgdGhhdCBub3QgdG9v IGxvbmcgYWdvKS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogSWNlIFttYWlsdG86 aWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIFJvYWNoDQpTZW50OiAyMiBB dWd1c3QgMjAxOCAyMDo1OQ0KVG86IEFwcGxpY2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWEgRGlz Y3Vzc2lvbiA8YXJ0QGlldGYub3JnPg0KQ2M6IGNsdWVAaWV0Zi5vcmc7IHJ0Y3dlYkBpZXRmLm9y ZzsgbW11c2ljQGlldGYub3JnOyBpY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFtJY2VdIElDRSwgSUNF LWJpcywgYW5kIENsdXN0ZXIgMjM4DQoNCk1lbWJlcnMgb2YgdGhlIEFSVCBjb21tdW5pdHkgaW50 ZXJlc3RlZCBpbiByZWFsLXRpbWUgY29tbXVuaWNhdGlvbnM6DQoNCkNsdXN0ZXIgMjM4IFsxXSBp cyBhIHNldCBvZiBpbnRlci1yZWxhdGVkIGRvY3VtZW50cyBkZWFsaW5nIHdpdGggcmVhbC10aW1l IGNvbW11bmljYXRpb25zLiBUaGUgYnVsayBvZiB0aGVzZSBkb2N1bWVudHMgcmVsYXRlIHRvIFdl YlJUQywgZWl0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkuIFRoZXkgYWxzbyBmb3JtIHRoZSB1 bmRlcnBpbm5pbmdzIG9mIENMVUUuIEFzIG9mIG5vdywgdGhlcmUgYXJlIDM0IGRvY3VtZW50cyBp biB0aGUgY2x1c3RlciB0aGF0IGFyZSBub3QgeWV0IHB1Ymxpc2hlZCwgd2l0aCAyNSBvZiB0aGVz ZSBhbHJlYWR5IGluIHRoZSBSRkMgRWRpdG9yJ3MgcXVldWUuIFRoZSBkZXBlbmRlbmN5IGdyYXBo IGFtb25nIHRoZXNlIGRvY3VtZW50cyBpcyBzdWNoIHRoYXQgdGhlIGJ1bGsgb2YgdGhlbSBjYW4g YmUgcHVibGlzaGVkIGFzIHNvb24gYXMgYSBzcGVjaWZpYyBzaXggb2YgdGhlbSBhcmUgaGFuZGVk IG9mZiB0byB0aGUgUkZDIGVkaXRvciwgYW5kIHdlIGV4cGVjdCB0aGlzIHRvIGhhcHBlbiBpbiB0 aGUgdXBjb21pbmcgZmV3IG1vbnRocy4NCg0KT25lIGxvbmctcnVubmluZyBjb21wbGljYXRpb24g Zm9yIHRoaXMgY2x1c3RlciBvZiBkb2N1bWVudHMgaXMgdGhhdCBlYWNoIG9mIHRoZSBkb2N1bWVu dHMgd2VyZSBkZXZlbG9wZWQgb3ZlciB0aGUgY291cnNlIG9mIHNldmVuIHllYXJzLCBpbiBjb25j ZXJ0IHdpdGggaW1wbGVtZW50YXRpb25zLCB3aGlsZSB0aGUgSUNFIHByb3RvY29sIGl0c2VsZiB3 YXMgdW5kZXJnb2luZyBzaWduaWZpY2FudCByZXZpc2lvbi4gQXMgYSBjb25zZXF1ZW5jZSwgc29t ZSBkb2N1bWVudHMgcmVseSAoZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgb24gdGhlIG9sZGVyIElD RSBzcGVjaWZpY2F0aW9uIChSRkMgNTI0NSksIHdoaWxlIHNvbWUgcmVseSBvbiB0aGUgbmV3ZXIg b25lIChSRkMgODQ0NSkuIEluIHNvbWUgY2FzZXMsIGRvY3VtZW50cyByZWZlciBkaXJlY3RseSB0 byB0aGUgb2xkIHZlcnNpb24gYW5kIHRyYW5zaXRpdmVseSB0byB0aGUgbmV3IHZlcnNpb24uDQoN Ckl0IGlzIG5vdGV3b3J0aHkgdGhhdCBSRkMgODQ0NSBvYnNvbGV0ZXMgUkZDIDUyNDU7IGFuZCB0 aGF0IHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFJGQyA4NDQ1IGhhcyBzb21lICBjaGFuZ2Vz IHRoYXQgYnJlYWsgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgbWVjaGFuaXNtIGRl ZmluZWQgaW4gUkZDIDUyNDUgKHdpdGggc3VjaCBiZWhhdmlvcmFsIGNoYW5nZXMgY29udHJvbGxl ZCBieSBhbiBTRFAgYXR0cmlidXRlLCBhbGxvd2luZyBjbGllbnRzIHRvIHRyYW5zaXRpb24gZnJv bSBvbmUgdG8gdGhlIG90aGVyKS4NCg0KTW9zdCBub3RhYmx5LCBkcmFmdC1pZXRmLXJ0Y3dlYi1q c2VwICh3aGljaCBpcyB0aGUgY29yZSBXZWJSVEMgcHJvdG9jb2wgaW4gdGhlIElFVEYpIHJlZmVy cyB0byBkaXJlY3RseSB0byBSRkMgNTI0NSwgd2hpbGUgcmVseWluZyBvbiB0aGUgYmVoYXZpb3Ig ZGVmaW5lZCBpbiBkcmFmdC1pZXRmLWljZS10cmlja2xlOyBkcmFmdC1pZXRmLWljZS10cmlja2xl LCBpbiB0dXJuLCBpcyBiYXNlZCBvbiB0aGUgbmV3ZXIgUkZDIDg0NDUgaGFuZGxpbmcuIEpTRVAn cyByZWZlcmVuY2UgdG8gUkZDIDUyNDUgaXMgYSBwcmFjdGljYWwgY29uc2lkZXJhdGlvbiB0aGF0 IGFja25vd2xlZGdlcyB0aGF0IGN1cnJlbnQgZGVwbG95bWVudHMgb2YgV2ViUlRDIGltcGxlbWVu dCB0aGUgb2xkZXIgdmVyc2lvbiBvZiBJQ0UuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXNlIGRlcGxv eWVkIGltcGxlbWVudGF0aW9ucyB1c2UgYSBzb21ld2hhdCBvbGRlciB2ZXJzaW9uIG9mIGRyYWZ0 LWlldGYtaWNlLXRyaWNrbGUgaW4gY29uY2VydCB3aXRoIHRoZSBvbGRlciBJQ0UgaW1wbGVtZW50 YXRpb24uDQoNCkluIG9yZGVyIHRvIGdldCBDbHVzdGVyIDIzOCBwdWJsaXNoZWQsIHdlIG5lZWQg dG8gZmluZCBzb21lIHdheSB0byByYXRpb25hbGl6ZSBpdHMgcmVmZXJlbmNlcyB0byBJQ0UuIEF0 IGEgYmFzaWMgbGV2ZWwsIHRoZSBBUlQgQXJlYSBEaXJlY3RvcnMgZG8gbm90IGJlbGlldmUgdGhh dCBpdCBtYWtlcyBzZW5zZSB0byBwdWJsaXNoIG5ldyBkb2N1bWVudHMgdGhhdCByZWZlciB0byBh biBhbHJlYWR5IG9ic29sZXRlZCBSRkMuIEF0IHRoZSBzYW1lIHRpbWUsIHdlIHJlY29nbml6ZSB0 aGF0IHRoZXJlIGlzIHZhbHVlIGluIG91ciBzcGVjaWZpY2F0aW9ucyBiZWluZyBpbmZvcm1lZCBi eSBydW5uaW5nIGNvZGUuIEZvciBXZWJSVEMsIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBzeXN0ZW0g aGFzIGxlZCB1cyB0byBhIHBvaW50IHRoYXQgd2UgbXVzdCBjaG9vc2UgYmV0d2VlbiB0aGVzZSBw cmluY2lwbGVzLiBPdXIgcHJvcG9zYWwgaXMgdG8gY2hvb3NlIHRoZSBmaXJzdCwgd2hpbGUgYWNr bm93bGVkZ2luZyB0aGUgc2Vjb25kLg0KDQpUaGlzIHdvdWxkIHJlc3VsdCBpbiBhIHJlcXVlc3Qg dG8gdGhlIFJGQyBlZGl0b3IgdG8gdXBkYXRlIGFsbCByZWZlcmVuY2VzIHRvIFJGQyA1MjQ1IGlu IHRoZSBDbHVzdGVyIDIzOCBkb2N1bWVudHMgdG8gaW5zdGVhZCBwb2ludCB0byBSRkMgODQ0NS4g RG9jdW1lbnRzIG5vdCB5ZXQgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUgd291bGQgYmUgdXBkYXRl ZCBwcmlvciB0byBJRVNHIHJldmlldy4gV2Ugd291bGQgZnVydGhlciByZXF1ZXN0IHRoYXQgdGhl IFJGQyBlZGl0b3IgYWRkIHRoZSBmb2xsb3dpbmcgdGV4dCB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1v dmVydmlldyBhbmQgZHJhZnQtaWV0Zi1ydGN3ZWItanNlcDoNCldoaWxlIHRoaXMgc3BlY2lmaWNh dGlvbiBmb3JtYWxseSByZWxpZXMgb24gW1JGQzg0NDVdLCBhdCB0aGUgdGltZSBvZiBpdHMgcHVi bGljYXRpb24sIHRoZSBtYWpvcml0eSBvZiBXZWJSVEMgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQg dGhlIHZlcnNpb24gb2YgSUNFIGRlc2NyaWJlZCBpbiBbUkZDNTI0NV0sIGFuZCB1c2UgYSBwcmUt c3RhbmRhcmQgdmVyc2lvbiBvZiB0aGUgdHJpY2tsZSBpY2UgbWVjaGFuaXNtIGRlc2NyaWJlZCBp biBbUkZDWFhYWF0uIFRoZSB1c2Ugb2YgdGhlICJpY2UyIiBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBb UkZDODQ0NV0gY2FuIGJlIHVzZWQgdG8gZGV0ZWN0IHRoZSB2ZXJzaW9uIGluIHVzZSBieSBhIHJl bW90ZSBlbmRwb2ludCBhbmQgdG8gcHJvdmlkZSBhIHNtb290aCB0cmFuc2l0aW9uIGZyb20gdGhl IG9sZGVyIHNwZWNpZmljYXRpb24gdG8gdGhlIG5ld2VyIG9uZS4NClJGQyA4NDQ1IHdvdWxkIGJl IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBmb3IgYm90aCBkb2N1bWVudHMsIHdoaWxlIFJGQyA1MjQ1 IHdvdWxkIGJlIGluZm9ybWF0aXZlLg0KDQpUaGVyZSBpcyBvbmUgbW9yZSBtaW5vciBjb21wbGlj YXRpb24sIGluIHRoYXQgZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzICh3aGlj aCBjdXJyZW50bHkgcG9pbnRzIHRvIFJGQyA1MjQ1KSBpcyBpbnRlbmRlZCB0byBiZSBhbiBleGhh dXN0aXZlIGxpc3Qgb2YgdGhlIFNEUCBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gdGhlIGRvY3VtZW50 cyBpdCBsaXN0cywgYW5kIFJGQyA4NDQ1IGFkZHMgYSBuZXcgImljZTIiIGF0dHJpYnV0ZSB0aGF0 IHdhcyBub3QgcHJlc2VudCBpbiBSRkMgNTI0NS4gRm9yIHRoaXMgcmVhc29uLCB3ZSB3b3VsZCBh bHNvIGFzayB0aGUgUkZDIEVkaXRvciB0byBhZGQgYSBuZXcgcm93IHRvIHRoZSB0YWJsZSBpbiBk cmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMgc2VjdGlvbiA1LjEyLCBhcyBmb2xs b3dzOg0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLSstLS0tLS0tLS0tLSsNCg0KICAgfCBOYW1lICAgICAgICAgICAgICB8IE5vdGVz ICAgICAgICAgICAgICAgICAgICAgfCBMZXZlbCB8IE11eCAgICAgICB8DQoNCiAgIHwgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCBDYXRlZ29y eSAgfA0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLSstLS0tLS0tLS0tLSsNCg0KICAgfCBpY2UyICAgICAgICAgICAgICB8IE5vdCBJ bXBhY3RlZCAgICAgICAgICAgICAgfCBTICAgICB8IE5PUk1BTCAgICB8DQoNCiAgIHwgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAg ICAgfA0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLSstLS0tLS0tLS0tLSsNCg0KDQpGb3IgY2xhcml0eSwgdGhlIGFmZmVjdGVkIGRv Y3VtZW50cyBhcmUgYXMgZm9sbG93cy4NCg0KVGhlIGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQg YmUgdXBkYXRlZCB0byByZWZlcmVuY2UgUkZDIDg0NDUgcHJpb3IgdG8gSUVTRyBldmFsdWF0aW9u Og0KDQogICogICBkcmFmdC1pZXRmLWNsdWUtZGF0YWNoYW5uZWwNCiAgKiAgIGRyYWZ0LWlldGYt Y2x1ZS1zaWduYWxpbmcNCiAgKiAgIGRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5DQogICogICBk cmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoDQoNCg0KDQpUaGUgZm9sbG93aW5nIGRvY3Vt ZW50cyB3b3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBieSB0aGUgUkZDIEVk aXRvcjoNCg0KICAqICAgZHJhZnQtaWV0Zi1tbXVzaWMtbXV4LWV4Y2x1c2l2ZQ0KICAqICAgZHJh ZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHANCiAgKiAgIGRyYWZ0LWlldGYtcnRjd2ViLWFscG4NCiAg KiAgIGRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5lbA0KICAqICAgZHJhZnQtaWV0Zi1ydGN3 ZWItcnRwLXVzYWdlDQoNCg0KDQpUaGUgZm9sbG93aW5nIGRvY3VtZW50cyB3b3VsZCBiZSB1cGRh dGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBhbmQgaGF2ZSB0aGUgdGV4dCBwcm9wb3NlZCBhYm92 ZSBhZGRlZCB0byB0aGVtOg0KDQogICogICBkcmFmdC1pZXRmLXJ0Y3dlYi1qc2VwDQogICogICBk cmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldw0KDQoNCg0KVGhlIGZvbGxvd2luZyBkb2N1bWVudCB3 b3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBieSB0aGUgUkZDIEVkaXRvciwg YW5kIGluY2x1ZGUgYSBuZXcgcm93IGZvciAiaWNlMiIgaW4gaXRzIFNlY3Rpb24gNS4xMiwgYXMg ZGVzY3JpYmVkIGFib3ZlOg0KDQogICogICBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJp YnV0ZXMNCg0KDQoNClRoaXMgbWVzc2FnZSBpcyBjcm9zcy1wb3N0ZWQgdG8gdGhlIGFmZmVjdGVk IHdvcmtpbmcgZ3JvdXBzLiBCZWNhdXNlIHRoZSBpc3N1ZSBhdCBoYW5kIGhhcyBpbXBhY3QgYWNy b3NzIHNldmVyYWwgZGlmZmVyZW50IGdyb3Vwcywgd2UgYXNrIHRoYXQgYWxsIGZvbGxvdy11cCBk aXNjdXNzaW9uIHRha2UgcGxhY2Ugb24gPGFydEBpZXRmLm9yZz48bWFpbHRvOmFydEBpZXRmLm9y Zz4uIFRoYW5rIHlvdS4NCg0KL0FkYW0gb24gYmVoYWxmIG9mIHRoZSBBUlQgQXJlYSBEaXJlY3Rv cnMNCg0KX19fXw0KWzFdIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2NsdXN0ZXJfaW5mby5w aHA/Y2lkPUMyMzgNCg== --_000_e9512339a5884c83b66bd9880d939845ericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6Ymxh Y2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6OTUwMjg0NTQ2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTI5Njk1NDY0 ODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MQ0KCXttc28tbGlzdC1pZDo5Nzk3NjU2NDM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5NjEz ODcyNDI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDINCgl7bXNvLWxpc3QtaWQ6MTcwMzU1ODIyMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MjA1MjM0Mjg0Njt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNzE4NTgzMDk3Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotNDAxNTkxNTY4O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz MjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNt O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SSBndWVzcyB0aGF0IGl0IHNob3VsZG7igJl0IGNvbWUgYXMgYSBzdXJwcmlzZSB0aGF0IEkg c3VwcG9ydCBBZGFt4oCZcyBzdWdnZXN0aW9uLCB0byB1cGRhdGUgYWxsIHJlZmVyZW5jZXMgdG8g UkZDIDg0NDUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JbiBhZGRp dGlvbiB0byB0aGUgZHJhZnRzIGxpc3RlZCBieSBBZGFtLCB0aGUgZXhhbXBsZXMgaW4gdGhlIHJ0 Y3dlYi1zZHAtZXhhbXBsZXMgZHJhZnQgd291bGQgYWxzbyBoYXZlIHRvIGJlIHVwZGF0ZWQgKEkg c2VudCBhbiBlLW1haWwNCiBhYm91dCB0aGF0IG5vdCB0b28gbG9uZyBhZ28pLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPiBJY2UgW21haWx0bzppY2UtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+QWRhbSBSb2FjaDxicj4NCjxiPlNlbnQ6PC9iPiAyMiBBdWd1c3Qg MjAxOCAyMDo1OTxicj4NCjxiPlRvOjwvYj4gQXBwbGljYXRpb25zIGFuZCBSZWFsLVRpbWUgQXJl YSBEaXNjdXNzaW9uICZsdDthcnRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBjbHVlQGll dGYub3JnOyBydGN3ZWJAaWV0Zi5vcmc7IG1tdXNpY0BpZXRmLm9yZzsgaWNlQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtJY2VdIElDRSwgSUNFLWJpcywgYW5kIENsdXN0ZXIgMjM4PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWVtYmVycyBvZiB0 aGUgQVJUIGNvbW11bml0eSBpbnRlcmVzdGVkIGluIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uczoN CjxvOnA+PC9vOnA+PC9wPg0KPHA+Q2x1c3RlciAyMzggWzFdIGlzIGEgc2V0IG9mIGludGVyLXJl bGF0ZWQgZG9jdW1lbnRzIGRlYWxpbmcgd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbnMuIFRo ZSBidWxrIG9mIHRoZXNlIGRvY3VtZW50cyByZWxhdGUgdG8gV2ViUlRDLCBlaXRoZXIgZGlyZWN0 bHkgb3IgaW5kaXJlY3RseS4gVGhleSBhbHNvIGZvcm0gdGhlIHVuZGVycGlubmluZ3Mgb2YgQ0xV RS4gQXMgb2Ygbm93LCB0aGVyZSBhcmUgMzQgZG9jdW1lbnRzIGluIHRoZSBjbHVzdGVyDQogdGhh dCBhcmUgbm90IHlldCBwdWJsaXNoZWQsIHdpdGggMjUgb2YgdGhlc2UgYWxyZWFkeSBpbiB0aGUg UkZDIEVkaXRvcidzIHF1ZXVlLiBUaGUgZGVwZW5kZW5jeSBncmFwaCBhbW9uZyB0aGVzZSBkb2N1 bWVudHMgaXMgc3VjaCB0aGF0IHRoZSBidWxrIG9mIHRoZW0gY2FuIGJlIHB1Ymxpc2hlZCBhcyBz b29uIGFzIGEgc3BlY2lmaWMgc2l4IG9mIHRoZW0gYXJlIGhhbmRlZCBvZmYgdG8gdGhlIFJGQyBl ZGl0b3IsIGFuZCB3ZSBleHBlY3QgdGhpcw0KIHRvIGhhcHBlbiBpbiB0aGUgdXBjb21pbmcgZmV3 IG1vbnRocy48bzpwPjwvbzpwPjwvcD4NCjxwPk9uZSBsb25nLXJ1bm5pbmcgY29tcGxpY2F0aW9u IGZvciB0aGlzIGNsdXN0ZXIgb2YgZG9jdW1lbnRzIGlzIHRoYXQgZWFjaCBvZiB0aGUgZG9jdW1l bnRzIHdlcmUgZGV2ZWxvcGVkIG92ZXIgdGhlIGNvdXJzZSBvZiBzZXZlbiB5ZWFycywgaW4gY29u Y2VydCB3aXRoIGltcGxlbWVudGF0aW9ucywgd2hpbGUgdGhlIElDRSBwcm90b2NvbCBpdHNlbGYg d2FzIHVuZGVyZ29pbmcgc2lnbmlmaWNhbnQgcmV2aXNpb24uIEFzIGEgY29uc2VxdWVuY2UsDQog c29tZSBkb2N1bWVudHMgcmVseSAoZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgb24gdGhlIG9sZGVy IElDRSBzcGVjaWZpY2F0aW9uIChSRkMgNTI0NSksIHdoaWxlIHNvbWUgcmVseSBvbiB0aGUgbmV3 ZXIgb25lIChSRkMgODQ0NSkuIEluIHNvbWUgY2FzZXMsIGRvY3VtZW50cyByZWZlciBkaXJlY3Rs eSB0byB0aGUgb2xkIHZlcnNpb24gYW5kIHRyYW5zaXRpdmVseSB0byB0aGUgbmV3IHZlcnNpb24u PG86cD48L286cD48L3A+DQo8cD5JdCBpcyBub3Rld29ydGh5IHRoYXQgUkZDIDg0NDUgb2Jzb2xl dGVzIFJGQyA1MjQ1OyBhbmQgdGhhdCB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBSRkMgODQ0 NSBoYXMgc29tZSZuYnNwOyBjaGFuZ2VzIHRoYXQgYnJlYWsgYmFja3dhcmRzIGNvbXBhdGliaWxp dHkgd2l0aCB0aGUgbWVjaGFuaXNtIGRlZmluZWQgaW4gUkZDIDUyNDUgKHdpdGggc3VjaCBiZWhh dmlvcmFsIGNoYW5nZXMgY29udHJvbGxlZCBieSBhbiBTRFAgYXR0cmlidXRlLCBhbGxvd2luZw0K IGNsaWVudHMgdG8gdHJhbnNpdGlvbiBmcm9tIG9uZSB0byB0aGUgb3RoZXIpLjxvOnA+PC9vOnA+ PC9wPg0KPHA+TW9zdCBub3RhYmx5LCBkcmFmdC1pZXRmLXJ0Y3dlYi1qc2VwICh3aGljaCBpcyB0 aGUgY29yZSBXZWJSVEMgcHJvdG9jb2wgaW4gdGhlIElFVEYpIHJlZmVycyB0byBkaXJlY3RseSB0 byBSRkMgNTI0NSwgd2hpbGUgcmVseWluZyBvbiB0aGUgYmVoYXZpb3IgZGVmaW5lZCBpbiBkcmFm dC1pZXRmLWljZS10cmlja2xlOyBkcmFmdC1pZXRmLWljZS10cmlja2xlLCBpbiB0dXJuLCBpcyBi YXNlZCBvbiB0aGUgbmV3ZXIgUkZDIDg0NDUgaGFuZGxpbmcuDQogSlNFUCdzIHJlZmVyZW5jZSB0 byBSRkMgNTI0NSBpcyBhIHByYWN0aWNhbCBjb25zaWRlcmF0aW9uIHRoYXQgYWNrbm93bGVkZ2Vz IHRoYXQgY3VycmVudCBkZXBsb3ltZW50cyBvZiBXZWJSVEMgaW1wbGVtZW50IHRoZSBvbGRlciB2 ZXJzaW9uIG9mIElDRS4gQXQgdGhlIHNhbWUgdGltZSwgdGhlc2UgZGVwbG95ZWQgaW1wbGVtZW50 YXRpb25zIHVzZSBhIHNvbWV3aGF0IG9sZGVyIHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1pY2UtdHJp Y2tsZSBpbiBjb25jZXJ0DQogd2l0aCB0aGUgb2xkZXIgSUNFIGltcGxlbWVudGF0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPHA+SW4gb3JkZXIgdG8gZ2V0IENsdXN0ZXIgMjM4IHB1Ymxpc2hlZCwgd2Ug bmVlZCB0byBmaW5kIHNvbWUgd2F5IHRvIHJhdGlvbmFsaXplIGl0cyByZWZlcmVuY2VzIHRvIElD RS4gQXQgYSBiYXNpYyBsZXZlbCwgdGhlIEFSVCBBcmVhIERpcmVjdG9ycyBkbyBub3QgYmVsaWV2 ZSB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHB1Ymxpc2ggbmV3IGRvY3VtZW50cyB0aGF0IHJlZmVy IHRvIGFuIGFscmVhZHkgb2Jzb2xldGVkIFJGQy4gQXQgdGhlIHNhbWUNCiB0aW1lLCB3ZSByZWNv Z25pemUgdGhhdCB0aGVyZSBpcyB2YWx1ZSBpbiBvdXIgc3BlY2lmaWNhdGlvbnMgYmVpbmcgaW5m b3JtZWQgYnkgcnVubmluZyBjb2RlLiBGb3IgV2ViUlRDLCB0aGUgY29tcGxleGl0eSBvZiB0aGUg c3lzdGVtIGhhcyBsZWQgdXMgdG8gYSBwb2ludCB0aGF0IHdlIG11c3QgY2hvb3NlIGJldHdlZW4g dGhlc2UgcHJpbmNpcGxlcy4gT3VyIHByb3Bvc2FsIGlzIHRvIGNob29zZSB0aGUgZmlyc3QsIHdo aWxlIGFja25vd2xlZGdpbmcNCiB0aGUgc2Vjb25kLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyB3 b3VsZCByZXN1bHQgaW4gYSByZXF1ZXN0IHRvIHRoZSBSRkMgZWRpdG9yIHRvIHVwZGF0ZSBhbGwg cmVmZXJlbmNlcyB0byBSRkMgNTI0NSBpbiB0aGUgQ2x1c3RlciAyMzggZG9jdW1lbnRzIHRvIGlu c3RlYWQgcG9pbnQgdG8gUkZDIDg0NDUuIERvY3VtZW50cyBub3QgeWV0IGluIHRoZSBSRkMgZWRp dG9yIHF1ZXVlIHdvdWxkIGJlIHVwZGF0ZWQgcHJpb3IgdG8gSUVTRyByZXZpZXcuIFdlIHdvdWxk IGZ1cnRoZXIgcmVxdWVzdCB0aGF0DQogdGhlIFJGQyBlZGl0b3IgYWRkIHRoZSBmb2xsb3dpbmcg dGV4dCB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldyBhbmQgZHJhZnQtaWV0Zi1ydGN3ZWIt anNlcDo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgdGhpcyBz cGVjaWZpY2F0aW9uIGZvcm1hbGx5IHJlbGllcyBvbiBbUkZDODQ0NV0sIGF0IHRoZSB0aW1lIG9m IGl0cyBwdWJsaWNhdGlvbiwgdGhlIG1ham9yaXR5IG9mIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMg c3VwcG9ydCB0aGUgdmVyc2lvbiBvZiBJQ0UgZGVzY3JpYmVkIGluIFtSRkM1MjQ1XSwgYW5kIHVz ZSBhIHByZS1zdGFuZGFyZCB2ZXJzaW9uIG9mIHRoZSB0cmlja2xlIGljZSBtZWNoYW5pc20NCiBk ZXNjcmliZWQgaW4gW1JGQ1hYWFhdLiBUaGUgdXNlIG9mIHRoZSAmcXVvdDtpY2UyJnF1b3Q7IGF0 dHJpYnV0ZSBkZWZpbmVkIGluIFtSRkM4NDQ1XSBjYW4gYmUgdXNlZCB0byBkZXRlY3QgdGhlIHZl cnNpb24gaW4gdXNlIGJ5IGEgcmVtb3RlIGVuZHBvaW50IGFuZCB0byBwcm92aWRlIGEgc21vb3Ro IHRyYW5zaXRpb24gZnJvbSB0aGUgb2xkZXIgc3BlY2lmaWNhdGlvbiB0byB0aGUgbmV3ZXIgb25l Lg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S RkMgODQ0NSB3b3VsZCBiZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgZm9yIGJvdGggZG9jdW1lbnRz LCB3aGlsZSBSRkMgNTI0NSB3b3VsZCBiZSBpbmZvcm1hdGl2ZS4NCjxvOnA+PC9vOnA+PC9wPg0K PHA+VGhlcmUgaXMgb25lIG1vcmUgbWlub3IgY29tcGxpY2F0aW9uLCBpbiB0aGF0IGRyYWZ0LWll dGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcyAod2hpY2ggY3VycmVudGx5IHBvaW50cyB0byBS RkMgNTI0NSkgaXMgaW50ZW5kZWQgdG8gYmUgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIHRoZSBTRFAg YXR0cmlidXRlcyBkZWZpbmVkIGluIHRoZSBkb2N1bWVudHMgaXQgbGlzdHMsIGFuZCBSRkMgODQ0 NSBhZGRzIGEgbmV3ICZxdW90O2ljZTImcXVvdDsgYXR0cmlidXRlDQogdGhhdCB3YXMgbm90IHBy ZXNlbnQgaW4gUkZDIDUyNDUuIEZvciB0aGlzIHJlYXNvbiwgd2Ugd291bGQgYWxzbyBhc2sgdGhl IFJGQyBFZGl0b3IgdG8gYWRkIGEgbmV3IHJvdyB0byB0aGUgdGFibGUgaW4gZHJhZnQtaWV0Zi1t bXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzIHNlY3Rpb24gNS4xMiwgYXMgZm9sbG93czo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHByZT4mbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tJiM0 MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLS0t JiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgfCBOYW1lJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgTm90ZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBMZXZlbCB8IE11eCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgQ2F0ZWdvcnkmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB8IGljZTImbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCBOb3QgSW1wYWN0ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBTJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwgTk9STUFMJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7 PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+Rm9yIGNsYXJpdHksIHRoZSBhZmZlY3RlZCBkb2N1bWVu dHMgYXJlIGFzIGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8cD5UaGUgZm9sbG93aW5nIGRvY3Vt ZW50cyB3b3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBwcmlvciB0byBJRVNH IGV2YWx1YXRpb246PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCmRyYWZ0LWlldGYtY2x1ZS1k YXRhY2hhbm5lbDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwyIGxldmVsMSBsZm8xIj4NCmRyYWZ0LWlldGYtY2x1ZS1zaWduYWxpbmc8bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQpkcmFm dC1pZXRmLXJ0Y3dlYi1zZWN1cml0eTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCmRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5 LWFyY2g8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+ VGhlIGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRlZCB0byByZWZlcmVuY2UgUkZD IDg0NDUgYnkgdGhlIFJGQyBFZGl0b3I6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCmRyYWZ0 LWlldGYtbW11c2ljLW11eC1leGNsdXNpdmU8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpkcmFmdC1pZXRmLW1tdXNpYy1zY3Rw LXNkcDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl dmVsMSBsZm8yIj4NCmRyYWZ0LWlldGYtcnRjd2ViLWFscG48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpkcmFmdC1pZXRmLXJ0 Y3dlYi1kYXRhLWNoYW5uZWw8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2U8bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+VGhlIGZvbGxv d2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRlZCB0byByZWZlcmVuY2UgUkZDIDg0NDUgYW5k IGhhdmUgdGhlIHRleHQgcHJvcG9zZWQgYWJvdmUgYWRkZWQgdG8gdGhlbTo8bzpwPjwvbzpwPjwv cD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMg bGV2ZWwxIGxmbzMiPg0KZHJhZnQtaWV0Zi1ydGN3ZWItanNlcDxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj4NCmRyYWZ0LWlldGYt cnRjd2ViLW92ZXJ2aWV3PG86cD48L286cD48L2xpPjwvdWw+DQo8cD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwPlRoZSBmb2xsb3dpbmcgZG9jdW1lbnQgd291bGQgYmUgdXBkYXRlZCB0byByZWZl cmVuY2UgUkZDIDg0NDUgYnkgdGhlIFJGQyBFZGl0b3IsIGFuZCBpbmNsdWRlIGEgbmV3IHJvdyBm b3IgJnF1b3Q7aWNlMiZxdW90OyBpbiBpdHMgU2VjdGlvbiA1LjEyLCBhcyBkZXNjcmliZWQgYWJv dmU6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NCmRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgt YXR0cmlidXRlczxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cD5UaGlzIG1lc3NhZ2UgaXMgY3Jvc3MtcG9zdGVkIHRvIHRoZSBhZmZlY3RlZCB3b3JraW5n IGdyb3Vwcy4gQmVjYXVzZSB0aGUgaXNzdWUgYXQgaGFuZCBoYXMgaW1wYWN0IGFjcm9zcyBzZXZl cmFsIGRpZmZlcmVudCBncm91cHMsIHdlIGFzayB0aGF0IGFsbCBmb2xsb3ctdXAgZGlzY3Vzc2lv biB0YWtlIHBsYWNlIG9uDQo8YSBocmVmPSJtYWlsdG86YXJ0QGlldGYub3JnIj4mbHQ7YXJ0QGll dGYub3JnJmd0OzwvYT4uIFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjxwPi9BZGFtIG9uIGJl aGFsZiBvZiB0aGUgQVJUIEFyZWEgRGlyZWN0b3JzPG86cD48L286cD48L3A+DQo8cD5fX19fPGJy Pg0KWzFdIDxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2NsdXN0ZXJfaW5mby5w aHA/Y2lkPUMyMzgiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2NsdXN0ZXJfaW5mby5waHA/ Y2lkPUMyMzg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e9512339a5884c83b66bd9880d939845ericssoncom_-- From nobody Wed Aug 22 13:53:51 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2E91277C8; Wed, 22 Aug 2018 13:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbWC69YGP4dv; Wed, 22 Aug 2018 13:53:29 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D7D130DF3; Wed, 22 Aug 2018 13:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43822; q=dns/txt; s=iport; t=1534971196; x=1536180796; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9TGLPehF18EvDC+S2AE80fCVDOBWl6Gkg+rEm/DKu0M=; b=b15dOX7Z1afQRdPz7Ga60P8EgdhhsPQvCByiH6v7pDz1JoYpuq0tdxxv i1Ws2IgsmeQPGAhm5KQXTvts1wRq+ZQ8yJQSchIdcj0ur24k2oMFtJ7ej Mpr2akAmdvOssOmjhhj0cMWOSIDkgzwoBt2FascowEYpUclkPciwE2JIy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAABkzH1b/5NdJa1AGhkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCV0kvZX8oCoNliA2MJYINlh6BegsjhEkCF4JvITQYAQI?= =?us-ascii?q?BAQIBAQJtHAyFNwEBAQQjCkwQAgEIEQMBAiEBBgMCAgIwFAkIAgQOBRSDDgG?= =?us-ascii?q?BHWQPNKNrgS6KWgWJHBeCAIESJx+CTIMbAQECAReBZxaCSzGCJgKIDYR0E44?= =?us-ascii?q?ACQKGLIJ2hkQXgT6MfogxgmSIAAIRFIEkHTgSgSkPCHAVOyoBgj6CJReIWYU?= =?us-ascii?q?+bwGNZIEcAQE?= X-IronPort-AV: E=Sophos;i="5.53,275,1531785600"; d="scan'208,217";a="444948265" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2018 20:53:14 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w7MKrEEO008407 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Aug 2018 20:53:14 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 22 Aug 2018 15:53:13 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1320.000; Wed, 22 Aug 2018 15:53:13 -0500 From: "Charles Eckel (eckelcu)" To: Applications and Real-Time Area Discussion CC: "clue@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" , "bfcpbis@ietf.org" Thread-Topic: [art] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHUOkHp2qtJc/guzkqO2Y1jG5WZJaTMHj2A Date: Wed, 22 Aug 2018 20:53:13 +0000 Message-ID: <1362A84F-A635-4E8A-8741-B42336940180@cisco.com> References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> In-Reply-To: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.182.35] Content-Type: multipart/alternative; boundary="_000_1362A84FA6354E8A8741B42336940180ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.29, xch-rcd-019.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Ice] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 20:53:32 -0000 --_000_1362A84FA6354E8A8741B42336940180ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgSSB1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCBjb3JyZWN0bHksIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpcy0xNiNyZWYtMTcgc2hvdWxk IGJlIGFkZGVkIHRvIHRoZSBsaXN0IG9mIGRyYWZ0cyB0byBiZSB1cGRhdGVkIGFzIHdlbGwuDQoN CkNoZWVycywNCkNoYXJsZXMNCg0KRnJvbTogYXJ0IDxhcnQtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+DQpSZXBseS1UbzogQXBwbGlj YXRpb25zIGFuZCBSZWFsLVRpbWUgQXJlYSBEaXNjdXNzaW9uIDxhcnRAaWV0Zi5vcmc+DQpEYXRl OiBXZWRuZXNkYXksIEF1Z3VzdCAyMiwgMjAxOCBhdCAxMDo1OSBBTQ0KVG86IEFwcGxpY2F0aW9u cyBhbmQgUmVhbC1UaW1lIEFyZWEgRGlzY3Vzc2lvbiA8YXJ0QGlldGYub3JnPg0KQ2M6ICJjbHVl QGlldGYub3JnIiA8Y2x1ZUBpZXRmLm9yZz4sICJydGN3ZWJAaWV0Zi5vcmciIDxydGN3ZWJAaWV0 Zi5vcmc+LCAibW11c2ljQGlldGYub3JnIiA8bW11c2ljQGlldGYub3JnPiwgImljZUBpZXRmLm9y ZyIgPGljZUBpZXRmLm9yZz4NClN1YmplY3Q6IFthcnRdIElDRSwgSUNFLWJpcywgYW5kIENsdXN0 ZXIgMjM4DQoNCk1lbWJlcnMgb2YgdGhlIEFSVCBjb21tdW5pdHkgaW50ZXJlc3RlZCBpbiByZWFs LXRpbWUgY29tbXVuaWNhdGlvbnM6DQoNCkNsdXN0ZXIgMjM4IFsxXSBpcyBhIHNldCBvZiBpbnRl ci1yZWxhdGVkIGRvY3VtZW50cyBkZWFsaW5nIHdpdGggcmVhbC10aW1lIGNvbW11bmljYXRpb25z LiBUaGUgYnVsayBvZiB0aGVzZSBkb2N1bWVudHMgcmVsYXRlIHRvIFdlYlJUQywgZWl0aGVyIGRp cmVjdGx5IG9yIGluZGlyZWN0bHkuIFRoZXkgYWxzbyBmb3JtIHRoZSB1bmRlcnBpbm5pbmdzIG9m IENMVUUuIEFzIG9mIG5vdywgdGhlcmUgYXJlIDM0IGRvY3VtZW50cyBpbiB0aGUgY2x1c3RlciB0 aGF0IGFyZSBub3QgeWV0IHB1Ymxpc2hlZCwgd2l0aCAyNSBvZiB0aGVzZSBhbHJlYWR5IGluIHRo ZSBSRkMgRWRpdG9yJ3MgcXVldWUuIFRoZSBkZXBlbmRlbmN5IGdyYXBoIGFtb25nIHRoZXNlIGRv Y3VtZW50cyBpcyBzdWNoIHRoYXQgdGhlIGJ1bGsgb2YgdGhlbSBjYW4gYmUgcHVibGlzaGVkIGFz IHNvb24gYXMgYSBzcGVjaWZpYyBzaXggb2YgdGhlbSBhcmUgaGFuZGVkIG9mZiB0byB0aGUgUkZD IGVkaXRvciwgYW5kIHdlIGV4cGVjdCB0aGlzIHRvIGhhcHBlbiBpbiB0aGUgdXBjb21pbmcgZmV3 IG1vbnRocy4NCg0KT25lIGxvbmctcnVubmluZyBjb21wbGljYXRpb24gZm9yIHRoaXMgY2x1c3Rl ciBvZiBkb2N1bWVudHMgaXMgdGhhdCBlYWNoIG9mIHRoZSBkb2N1bWVudHMgd2VyZSBkZXZlbG9w ZWQgb3ZlciB0aGUgY291cnNlIG9mIHNldmVuIHllYXJzLCBpbiBjb25jZXJ0IHdpdGggaW1wbGVt ZW50YXRpb25zLCB3aGlsZSB0aGUgSUNFIHByb3RvY29sIGl0c2VsZiB3YXMgdW5kZXJnb2luZyBz aWduaWZpY2FudCByZXZpc2lvbi4gQXMgYSBjb25zZXF1ZW5jZSwgc29tZSBkb2N1bWVudHMgcmVs eSAoZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgb24gdGhlIG9sZGVyIElDRSBzcGVjaWZpY2F0aW9u IChSRkMgNTI0NSksIHdoaWxlIHNvbWUgcmVseSBvbiB0aGUgbmV3ZXIgb25lIChSRkMgODQ0NSku IEluIHNvbWUgY2FzZXMsIGRvY3VtZW50cyByZWZlciBkaXJlY3RseSB0byB0aGUgb2xkIHZlcnNp b24gYW5kIHRyYW5zaXRpdmVseSB0byB0aGUgbmV3IHZlcnNpb24uDQoNCkl0IGlzIG5vdGV3b3J0 aHkgdGhhdCBSRkMgODQ0NSBvYnNvbGV0ZXMgUkZDIDUyNDU7IGFuZCB0aGF0IHRoZSBtZWNoYW5p c20gZGVzY3JpYmVkIGluIFJGQyA4NDQ1IGhhcyBzb21lICBjaGFuZ2VzIHRoYXQgYnJlYWsgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgbWVjaGFuaXNtIGRlZmluZWQgaW4gUkZDIDUy NDUgKHdpdGggc3VjaCBiZWhhdmlvcmFsIGNoYW5nZXMgY29udHJvbGxlZCBieSBhbiBTRFAgYXR0 cmlidXRlLCBhbGxvd2luZyBjbGllbnRzIHRvIHRyYW5zaXRpb24gZnJvbSBvbmUgdG8gdGhlIG90 aGVyKS4NCg0KTW9zdCBub3RhYmx5LCBkcmFmdC1pZXRmLXJ0Y3dlYi1qc2VwICh3aGljaCBpcyB0 aGUgY29yZSBXZWJSVEMgcHJvdG9jb2wgaW4gdGhlIElFVEYpIHJlZmVycyB0byBkaXJlY3RseSB0 byBSRkMgNTI0NSwgd2hpbGUgcmVseWluZyBvbiB0aGUgYmVoYXZpb3IgZGVmaW5lZCBpbiBkcmFm dC1pZXRmLWljZS10cmlja2xlOyBkcmFmdC1pZXRmLWljZS10cmlja2xlLCBpbiB0dXJuLCBpcyBi YXNlZCBvbiB0aGUgbmV3ZXIgUkZDIDg0NDUgaGFuZGxpbmcuIEpTRVAncyByZWZlcmVuY2UgdG8g UkZDIDUyNDUgaXMgYSBwcmFjdGljYWwgY29uc2lkZXJhdGlvbiB0aGF0IGFja25vd2xlZGdlcyB0 aGF0IGN1cnJlbnQgZGVwbG95bWVudHMgb2YgV2ViUlRDIGltcGxlbWVudCB0aGUgb2xkZXIgdmVy c2lvbiBvZiBJQ0UuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXNlIGRlcGxveWVkIGltcGxlbWVudGF0 aW9ucyB1c2UgYSBzb21ld2hhdCBvbGRlciB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtaWNlLXRyaWNr bGUgaW4gY29uY2VydCB3aXRoIHRoZSBvbGRlciBJQ0UgaW1wbGVtZW50YXRpb24uDQoNCkluIG9y ZGVyIHRvIGdldCBDbHVzdGVyIDIzOCBwdWJsaXNoZWQsIHdlIG5lZWQgdG8gZmluZCBzb21lIHdh eSB0byByYXRpb25hbGl6ZSBpdHMgcmVmZXJlbmNlcyB0byBJQ0UuIEF0IGEgYmFzaWMgbGV2ZWws IHRoZSBBUlQgQXJlYSBEaXJlY3RvcnMgZG8gbm90IGJlbGlldmUgdGhhdCBpdCBtYWtlcyBzZW5z ZSB0byBwdWJsaXNoIG5ldyBkb2N1bWVudHMgdGhhdCByZWZlciB0byBhbiBhbHJlYWR5IG9ic29s ZXRlZCBSRkMuIEF0IHRoZSBzYW1lIHRpbWUsIHdlIHJlY29nbml6ZSB0aGF0IHRoZXJlIGlzIHZh bHVlIGluIG91ciBzcGVjaWZpY2F0aW9ucyBiZWluZyBpbmZvcm1lZCBieSBydW5uaW5nIGNvZGUu IEZvciBXZWJSVEMsIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBzeXN0ZW0gaGFzIGxlZCB1cyB0byBh IHBvaW50IHRoYXQgd2UgbXVzdCBjaG9vc2UgYmV0d2VlbiB0aGVzZSBwcmluY2lwbGVzLiBPdXIg cHJvcG9zYWwgaXMgdG8gY2hvb3NlIHRoZSBmaXJzdCwgd2hpbGUgYWNrbm93bGVkZ2luZyB0aGUg c2Vjb25kLg0KDQpUaGlzIHdvdWxkIHJlc3VsdCBpbiBhIHJlcXVlc3QgdG8gdGhlIFJGQyBlZGl0 b3IgdG8gdXBkYXRlIGFsbCByZWZlcmVuY2VzIHRvIFJGQyA1MjQ1IGluIHRoZSBDbHVzdGVyIDIz OCBkb2N1bWVudHMgdG8gaW5zdGVhZCBwb2ludCB0byBSRkMgODQ0NS4gRG9jdW1lbnRzIG5vdCB5 ZXQgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUgd291bGQgYmUgdXBkYXRlZCBwcmlvciB0byBJRVNH IHJldmlldy4gV2Ugd291bGQgZnVydGhlciByZXF1ZXN0IHRoYXQgdGhlIFJGQyBlZGl0b3IgYWRk IHRoZSBmb2xsb3dpbmcgdGV4dCB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldyBhbmQgZHJh ZnQtaWV0Zi1ydGN3ZWItanNlcDoNCldoaWxlIHRoaXMgc3BlY2lmaWNhdGlvbiBmb3JtYWxseSBy ZWxpZXMgb24gW1JGQzg0NDVdLCBhdCB0aGUgdGltZSBvZiBpdHMgcHVibGljYXRpb24sIHRoZSBt YWpvcml0eSBvZiBXZWJSVEMgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgdGhlIHZlcnNpb24gb2Yg SUNFIGRlc2NyaWJlZCBpbiBbUkZDNTI0NV0sIGFuZCB1c2UgYSBwcmUtc3RhbmRhcmQgdmVyc2lv biBvZiB0aGUgdHJpY2tsZSBpY2UgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBbUkZDWFhYWF0uIFRo ZSB1c2Ugb2YgdGhlICJpY2UyIiBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBbUkZDODQ0NV0gY2FuIGJl IHVzZWQgdG8gZGV0ZWN0IHRoZSB2ZXJzaW9uIGluIHVzZSBieSBhIHJlbW90ZSBlbmRwb2ludCBh bmQgdG8gcHJvdmlkZSBhIHNtb290aCB0cmFuc2l0aW9uIGZyb20gdGhlIG9sZGVyIHNwZWNpZmlj YXRpb24gdG8gdGhlIG5ld2VyIG9uZS4NClJGQyA4NDQ1IHdvdWxkIGJlIGEgbm9ybWF0aXZlIHJl ZmVyZW5jZSBmb3IgYm90aCBkb2N1bWVudHMsIHdoaWxlIFJGQyA1MjQ1IHdvdWxkIGJlIGluZm9y bWF0aXZlLg0KDQpUaGVyZSBpcyBvbmUgbW9yZSBtaW5vciBjb21wbGljYXRpb24sIGluIHRoYXQg ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzICh3aGljaCBjdXJyZW50bHkgcG9p bnRzIHRvIFJGQyA1MjQ1KSBpcyBpbnRlbmRlZCB0byBiZSBhbiBleGhhdXN0aXZlIGxpc3Qgb2Yg dGhlIFNEUCBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gdGhlIGRvY3VtZW50cyBpdCBsaXN0cywgYW5k IFJGQyA4NDQ1IGFkZHMgYSBuZXcgImljZTIiIGF0dHJpYnV0ZSB0aGF0IHdhcyBub3QgcHJlc2Vu dCBpbiBSRkMgNTI0NS4gRm9yIHRoaXMgcmVhc29uLCB3ZSB3b3VsZCBhbHNvIGFzayB0aGUgUkZD IEVkaXRvciB0byBhZGQgYSBuZXcgcm93IHRvIHRoZSB0YWJsZSBpbiBkcmFmdC1pZXRmLW1tdXNp Yy1zZHAtbXV4LWF0dHJpYnV0ZXMgc2VjdGlvbiA1LjEyLCBhcyBmb2xsb3dzOg0KDQogICArLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0t LS0tLS0tLSsNCg0KICAgfCBOYW1lICAgICAgICAgICAgICB8IE5vdGVzICAgICAgICAgICAgICAg ICAgICAgfCBMZXZlbCB8IE11eCAgICAgICB8DQoNCiAgIHwgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCBDYXRlZ29yeSAgfA0KDQogICArLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0t LS0tLS0tLSsNCg0KICAgfCBpY2UyICAgICAgICAgICAgICB8IE5vdCBJbXBhY3RlZCAgICAgICAg ICAgICAgfCBTICAgICB8IE5PUk1BTCAgICB8DQoNCiAgIHwgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgfA0KDQogICArLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0t LS0tLS0tLSsNCg0KDQpGb3IgY2xhcml0eSwgdGhlIGFmZmVjdGVkIGRvY3VtZW50cyBhcmUgYXMg Zm9sbG93cy4NCg0KVGhlIGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRlZCB0byBy ZWZlcmVuY2UgUkZDIDg0NDUgcHJpb3IgdG8gSUVTRyBldmFsdWF0aW9uOg0KwrcgICAgICAgICBk cmFmdC1pZXRmLWNsdWUtZGF0YWNoYW5uZWwNCsK3ICAgICAgICAgZHJhZnQtaWV0Zi1jbHVlLXNp Z25hbGluZw0KwrcgICAgICAgICBkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eQ0KwrcgICAgICAg ICBkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoDQoNCg0KDQpUaGUgZm9sbG93aW5nIGRv Y3VtZW50cyB3b3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBieSB0aGUgUkZD IEVkaXRvcjoNCsK3ICAgICAgICAgZHJhZnQtaWV0Zi1tbXVzaWMtbXV4LWV4Y2x1c2l2ZQ0Kwrcg ICAgICAgICBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcA0KwrcgICAgICAgICBkcmFmdC1pZXRm LXJ0Y3dlYi1hbHBuDQrCtyAgICAgICAgIGRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5lbA0K wrcgICAgICAgICBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UNCg0KDQoNClRoZSBmb2xsb3dp bmcgZG9jdW1lbnRzIHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNlIFJGQyA4NDQ1IGFuZCBo YXZlIHRoZSB0ZXh0IHByb3Bvc2VkIGFib3ZlIGFkZGVkIHRvIHRoZW06DQrCtyAgICAgICAgIGRy YWZ0LWlldGYtcnRjd2ViLWpzZXANCsK3ICAgICAgICAgZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZp ZXcNCg0KDQoNClRoZSBmb2xsb3dpbmcgZG9jdW1lbnQgd291bGQgYmUgdXBkYXRlZCB0byByZWZl cmVuY2UgUkZDIDg0NDUgYnkgdGhlIFJGQyBFZGl0b3IsIGFuZCBpbmNsdWRlIGEgbmV3IHJvdyBm b3IgImljZTIiIGluIGl0cyBTZWN0aW9uIDUuMTIsIGFzIGRlc2NyaWJlZCBhYm92ZToNCsK3ICAg ICAgICAgZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzDQoNCg0KDQpUaGlzIG1l c3NhZ2UgaXMgY3Jvc3MtcG9zdGVkIHRvIHRoZSBhZmZlY3RlZCB3b3JraW5nIGdyb3Vwcy4gQmVj YXVzZSB0aGUgaXNzdWUgYXQgaGFuZCBoYXMgaW1wYWN0IGFjcm9zcyBzZXZlcmFsIGRpZmZlcmVu dCBncm91cHMsIHdlIGFzayB0aGF0IGFsbCBmb2xsb3ctdXAgZGlzY3Vzc2lvbiB0YWtlIHBsYWNl IG9uIDxhcnRAaWV0Zi5vcmc+PG1haWx0bzphcnRAaWV0Zi5vcmc+LiBUaGFuayB5b3UuDQoNCi9B ZGFtIG9uIGJlaGFsZiBvZiB0aGUgQVJUIEFyZWEgRGlyZWN0b3JzDQoNCl9fX18NClsxXSBodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9jbHVzdGVyX2luZm8ucGhwP2NpZD1DMjM4DQo= --_000_1362A84FA6354E8A8741B42336940180ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <45C27A895F58C447BD8BDA439B3E88F2@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyOTk2NDgzNzg7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwODk2NTU1NjI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGww OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1ODUxMzkzNzY7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjMzMDc5MzkyO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1p ZDoxNjIyNjg4MjY2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNTc4NDE2Nzc2O30NCkBsaXN0 IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxODY0MDUxMjU0Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo0MDI0MzEyNDI7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPklmIEkgdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWwgY29ycmVjdGx5LA0KPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgyYmlzLTE2 I3JlZi0xNyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1y ZmM0NTgyYmlzLTE2I3JlZi0xNzwvYT4gc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBsaXN0IG9mIGRy YWZ0cyB0byBiZSB1cGRhdGVkIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkNoZWVycyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPkNoYXJsZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPmFydCAmbHQ7YXJ0LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBBZGFtIFJv YWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0Ozxicj4NCjxiPlJlcGx5LVRvOiA8L2I+QXBwbGlj YXRpb25zIGFuZCBSZWFsLVRpbWUgQXJlYSBEaXNjdXNzaW9uICZsdDthcnRAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgQXVndXN0IDIyLCAyMDE4IGF0IDEwOjU5IEFN PGJyPg0KPGI+VG86IDwvYj5BcHBsaWNhdGlvbnMgYW5kIFJlYWwtVGltZSBBcmVhIERpc2N1c3Np b24gJmx0O2FydEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2NsdWVAaWV0Zi5v cmcmcXVvdDsgJmx0O2NsdWVAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtydGN3ZWJAaWV0Zi5vcmcmcXVv dDsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDssICZxdW90O21tdXNpY0BpZXRmLm9yZyZxdW90OyAm bHQ7bW11c2ljQGlldGYub3JnJmd0OywgJnF1b3Q7aWNlQGlldGYub3JnJnF1b3Q7ICZsdDtpY2VA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlthcnRdIElDRSwgSUNFLWJpcywgYW5k IENsdXN0ZXIgMjM4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+TWVtYmVycyBvZiB0aGUgQVJUIGNvbW11bml0eSBpbnRlcmVzdGVkIGluIHJlYWwtdGltZSBj b21tdW5pY2F0aW9uczoNCjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPkNsdXN0ZXIgMjM4IFsxXSBpcyBhIHNldCBvZiBpbnRlci1yZWxhdGVkIGRvY3VtZW50cyBk ZWFsaW5nIHdpdGggcmVhbC10aW1lIGNvbW11bmljYXRpb25zLiBUaGUgYnVsayBvZiB0aGVzZSBk b2N1bWVudHMgcmVsYXRlIHRvIFdlYlJUQywgZWl0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0bHku IFRoZXkgYWxzbyBmb3JtIHRoZSB1bmRlcnBpbm5pbmdzIG9mIENMVUUuIEFzIG9mIG5vdywgdGhl cmUgYXJlDQogMzQgZG9jdW1lbnRzIGluIHRoZSBjbHVzdGVyIHRoYXQgYXJlIG5vdCB5ZXQgcHVi bGlzaGVkLCB3aXRoIDI1IG9mIHRoZXNlIGFscmVhZHkgaW4gdGhlIFJGQyBFZGl0b3IncyBxdWV1 ZS4gVGhlIGRlcGVuZGVuY3kgZ3JhcGggYW1vbmcgdGhlc2UgZG9jdW1lbnRzIGlzIHN1Y2ggdGhh dCB0aGUgYnVsayBvZiB0aGVtIGNhbiBiZSBwdWJsaXNoZWQgYXMgc29vbiBhcyBhIHNwZWNpZmlj IHNpeCBvZiB0aGVtIGFyZSBoYW5kZWQgb2ZmIHRvIHRoZSBSRkMNCiBlZGl0b3IsIGFuZCB3ZSBl eHBlY3QgdGhpcyB0byBoYXBwZW4gaW4gdGhlIHVwY29taW5nIGZldyBtb250aHMuPG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T25lIGxvbmctcnVubmluZyBjb21w bGljYXRpb24gZm9yIHRoaXMgY2x1c3RlciBvZiBkb2N1bWVudHMgaXMgdGhhdCBlYWNoIG9mIHRo ZSBkb2N1bWVudHMgd2VyZSBkZXZlbG9wZWQgb3ZlciB0aGUgY291cnNlIG9mIHNldmVuIHllYXJz LCBpbiBjb25jZXJ0IHdpdGggaW1wbGVtZW50YXRpb25zLCB3aGlsZSB0aGUgSUNFIHByb3RvY29s IGl0c2VsZiB3YXMgdW5kZXJnb2luZyBzaWduaWZpY2FudCByZXZpc2lvbi4NCiBBcyBhIGNvbnNl cXVlbmNlLCBzb21lIGRvY3VtZW50cyByZWx5IChkaXJlY3RseSBvciBpbmRpcmVjdGx5KSBvbiB0 aGUgb2xkZXIgSUNFIHNwZWNpZmljYXRpb24gKFJGQyA1MjQ1KSwgd2hpbGUgc29tZSByZWx5IG9u IHRoZSBuZXdlciBvbmUgKFJGQyA4NDQ1KS4gSW4gc29tZSBjYXNlcywgZG9jdW1lbnRzIHJlZmVy IGRpcmVjdGx5IHRvIHRoZSBvbGQgdmVyc2lvbiBhbmQgdHJhbnNpdGl2ZWx5IHRvIHRoZSBuZXcg dmVyc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JdCBp cyBub3Rld29ydGh5IHRoYXQgUkZDIDg0NDUgb2Jzb2xldGVzIFJGQyA1MjQ1OyBhbmQgdGhhdCB0 aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBSRkMgODQ0NSBoYXMgc29tZSZuYnNwOyBjaGFuZ2Vz IHRoYXQgYnJlYWsgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgbWVjaGFuaXNtIGRl ZmluZWQgaW4gUkZDIDUyNDUgKHdpdGggc3VjaCBiZWhhdmlvcmFsIGNoYW5nZXMgY29udHJvbGxl ZA0KIGJ5IGFuIFNEUCBhdHRyaWJ1dGUsIGFsbG93aW5nIGNsaWVudHMgdG8gdHJhbnNpdGlvbiBm cm9tIG9uZSB0byB0aGUgb3RoZXIpLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPk1vc3Qgbm90YWJseSwgZHJhZnQtaWV0Zi1ydGN3ZWItanNlcCAod2hpY2ggaXMg dGhlIGNvcmUgV2ViUlRDIHByb3RvY29sIGluIHRoZSBJRVRGKSByZWZlcnMgdG8gZGlyZWN0bHkg dG8gUkZDIDUyNDUsIHdoaWxlIHJlbHlpbmcgb24gdGhlIGJlaGF2aW9yIGRlZmluZWQgaW4gZHJh ZnQtaWV0Zi1pY2UtdHJpY2tsZTsgZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZSwgaW4gdHVybiwgaXMg YmFzZWQgb24gdGhlDQogbmV3ZXIgUkZDIDg0NDUgaGFuZGxpbmcuIEpTRVAncyByZWZlcmVuY2Ug dG8gUkZDIDUyNDUgaXMgYSBwcmFjdGljYWwgY29uc2lkZXJhdGlvbiB0aGF0IGFja25vd2xlZGdl cyB0aGF0IGN1cnJlbnQgZGVwbG95bWVudHMgb2YgV2ViUlRDIGltcGxlbWVudCB0aGUgb2xkZXIg dmVyc2lvbiBvZiBJQ0UuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXNlIGRlcGxveWVkIGltcGxlbWVu dGF0aW9ucyB1c2UgYSBzb21ld2hhdCBvbGRlciB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtaWNlLXRy aWNrbGUNCiBpbiBjb25jZXJ0IHdpdGggdGhlIG9sZGVyIElDRSBpbXBsZW1lbnRhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JbiBvcmRlciB0byBnZXQg Q2x1c3RlciAyMzggcHVibGlzaGVkLCB3ZSBuZWVkIHRvIGZpbmQgc29tZSB3YXkgdG8gcmF0aW9u YWxpemUgaXRzIHJlZmVyZW5jZXMgdG8gSUNFLiBBdCBhIGJhc2ljIGxldmVsLCB0aGUgQVJUIEFy ZWEgRGlyZWN0b3JzIGRvIG5vdCBiZWxpZXZlIHRoYXQgaXQgbWFrZXMgc2Vuc2UgdG8gcHVibGlz aCBuZXcgZG9jdW1lbnRzIHRoYXQgcmVmZXIgdG8gYW4gYWxyZWFkeSBvYnNvbGV0ZWQNCiBSRkMu IEF0IHRoZSBzYW1lIHRpbWUsIHdlIHJlY29nbml6ZSB0aGF0IHRoZXJlIGlzIHZhbHVlIGluIG91 ciBzcGVjaWZpY2F0aW9ucyBiZWluZyBpbmZvcm1lZCBieSBydW5uaW5nIGNvZGUuIEZvciBXZWJS VEMsIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBzeXN0ZW0gaGFzIGxlZCB1cyB0byBhIHBvaW50IHRo YXQgd2UgbXVzdCBjaG9vc2UgYmV0d2VlbiB0aGVzZSBwcmluY2lwbGVzLiBPdXIgcHJvcG9zYWwg aXMgdG8gY2hvb3NlIHRoZSBmaXJzdCwNCiB3aGlsZSBhY2tub3dsZWRnaW5nIHRoZSBzZWNvbmQu PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhpcyB3b3VsZCBy ZXN1bHQgaW4gYSByZXF1ZXN0IHRvIHRoZSBSRkMgZWRpdG9yIHRvIHVwZGF0ZSBhbGwgcmVmZXJl bmNlcyB0byBSRkMgNTI0NSBpbiB0aGUgQ2x1c3RlciAyMzggZG9jdW1lbnRzIHRvIGluc3RlYWQg cG9pbnQgdG8gUkZDIDg0NDUuIERvY3VtZW50cyBub3QgeWV0IGluIHRoZSBSRkMgZWRpdG9yIHF1 ZXVlIHdvdWxkIGJlIHVwZGF0ZWQgcHJpb3IgdG8gSUVTRyByZXZpZXcuIFdlDQogd291bGQgZnVy dGhlciByZXF1ZXN0IHRoYXQgdGhlIFJGQyBlZGl0b3IgYWRkIHRoZSBmb2xsb3dpbmcgdGV4dCB0 byBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldyBhbmQgZHJhZnQtaWV0Zi1ydGN3ZWItanNlcDo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPldoaWxlIHRoaXMgc3BlY2lmaWNhdGlvbiBmb3JtYWxseSByZWxpZXMgb24gW1JGQzg0 NDVdLCBhdCB0aGUgdGltZSBvZiBpdHMgcHVibGljYXRpb24sIHRoZSBtYWpvcml0eSBvZiBXZWJS VEMgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgdGhlIHZlcnNpb24gb2YgSUNFIGRlc2NyaWJlZCBp biBbUkZDNTI0NV0sIGFuZCB1c2UgYSBwcmUtc3RhbmRhcmQgdmVyc2lvbiBvZg0KIHRoZSB0cmlj a2xlIGljZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFtSRkNYWFhYXS4gVGhlIHVzZSBvZiB0aGUg JnF1b3Q7aWNlMiZxdW90OyBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBbUkZDODQ0NV0gY2FuIGJlIHVz ZWQgdG8gZGV0ZWN0IHRoZSB2ZXJzaW9uIGluIHVzZSBieSBhIHJlbW90ZSBlbmRwb2ludCBhbmQg dG8gcHJvdmlkZSBhIHNtb290aCB0cmFuc2l0aW9uIGZyb20gdGhlIG9sZGVyIHNwZWNpZmljYXRp b24gdG8gdGhlIG5ld2VyIG9uZS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlJGQyA4NDQ1IHdvdWxk IGJlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBmb3IgYm90aCBkb2N1bWVudHMsIHdoaWxlIFJGQyA1 MjQ1IHdvdWxkIGJlIGluZm9ybWF0aXZlLg0KPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VGhlcmUgaXMgb25lIG1vcmUgbWlub3IgY29tcGxpY2F0aW9uLCBpbiB0 aGF0IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcyAod2hpY2ggY3VycmVudGx5 IHBvaW50cyB0byBSRkMgNTI0NSkgaXMgaW50ZW5kZWQgdG8gYmUgYW4gZXhoYXVzdGl2ZSBsaXN0 IG9mIHRoZSBTRFAgYXR0cmlidXRlcyBkZWZpbmVkIGluIHRoZSBkb2N1bWVudHMgaXQgbGlzdHMs IGFuZCBSRkMgODQ0NSBhZGRzDQogYSBuZXcgJnF1b3Q7aWNlMiZxdW90OyBhdHRyaWJ1dGUgdGhh dCB3YXMgbm90IHByZXNlbnQgaW4gUkZDIDUyNDUuIEZvciB0aGlzIHJlYXNvbiwgd2Ugd291bGQg YWxzbyBhc2sgdGhlIFJGQyBFZGl0b3IgdG8gYWRkIGEgbmV3IHJvdyB0byB0aGUgdGFibGUgaW4g ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzIHNlY3Rpb24gNS4xMiwgYXMgZm9s bG93czo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyB8IE5hbWUmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCBOb3RlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IExldmVsIHwgTXV4Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgQ2F0 ZWdvcnkmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7IHwg aWNlMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE5vdCBJbXBhY3RlZCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8IFMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBOT1JNQUwmbmJzcDsmbmJzcDsmbmJz cDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0t LS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7 LS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Rm9yIGNsYXJpdHksIHRoZSBhZmZlY3Rl ZCBkb2N1bWVudHMgYXJlIGFzIGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VGhlIGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRlZCB0 byByZWZlcmVuY2UgUkZDIDg0NDUgcHJpb3IgdG8gSUVTRyBldmFsdWF0aW9uOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5kcmFmdC1pZXRmLWNs dWUtZGF0YWNoYW5uZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+ZHJhZnQtaWV0Zi1jbHVlLXNpZ25hbGluZyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ZHJhZnQtaWV0Zi1ydGN3ZWItc2Vj dXJpdHkgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPmRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2ggPG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRl ZCB0byByZWZlcmVuY2UgUkZDIDg0NDUgYnkgdGhlIFJGQyBFZGl0b3I6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwzIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmRyYWZ0LWlldGYtbW11c2lj LW11eC1leGNsdXNpdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+ZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwzIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmRyYWZ0LWlldGYtcnRjd2ViLWFs cG4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4w aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwzIGxldmVsMSBsZm8yIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PmRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5lbCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDMgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdl IDxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBmb2xsb3dpbmcgZG9j dW1lbnRzIHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNlIFJGQyA4NDQ1IGFuZCBoYXZlIHRo ZSB0ZXh0IHByb3Bvc2VkIGFib3ZlIGFkZGVkIHRvIHRoZW06PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmRyYWZ0LWlldGYtcnRjd2ViLWpzZXAg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmRy YWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3IDxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPlRoZSBmb2xsb3dpbmcgZG9jdW1lbnQgd291bGQgYmUgdXBkYXRlZCB0byByZWZlcmVu Y2UgUkZDIDg0NDUgYnkgdGhlIFJGQyBFZGl0b3IsIGFuZCBpbmNsdWRlIGEgbmV3IHJvdyBmb3Ig JnF1b3Q7aWNlMiZxdW90OyBpbiBpdHMgU2VjdGlvbiA1LjEyLCBhcyBkZXNjcmliZWQgYWJvdmU6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmRy YWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcyA8bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5UaGlzIG1lc3NhZ2UgaXMgY3Jvc3MtcG9zdGVkIHRvIHRoZSBhZmZl Y3RlZCB3b3JraW5nIGdyb3Vwcy4gQmVjYXVzZSB0aGUgaXNzdWUgYXQgaGFuZCBoYXMgaW1wYWN0 IGFjcm9zcyBzZXZlcmFsIGRpZmZlcmVudCBncm91cHMsIHdlIGFzayB0aGF0IGFsbCBmb2xsb3ct dXAgZGlzY3Vzc2lvbiB0YWtlIHBsYWNlIG9uDQo8YSBocmVmPSJtYWlsdG86YXJ0QGlldGYub3Jn Ij4mbHQ7YXJ0QGlldGYub3JnJmd0OzwvYT4uIFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4vQWRhbSBvbiBiZWhhbGYgb2YgdGhlIEFSVCBBcmVh IERpcmVjdG9yczxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPl9f X188YnI+DQpbMV0gPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvY2x1c3Rlcl9p bmZvLnBocD9jaWQ9QzIzOCI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvY2x1c3Rlcl9pbmZv LnBocD9jaWQ9QzIzODwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_1362A84FA6354E8A8741B42336940180ciscocom_-- From nobody Sat Aug 25 09:43:05 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86563128CB7; Sat, 25 Aug 2018 09:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0G49OSGpBmm; Sat, 25 Aug 2018 09:42:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72244127B92; Sat, 25 Aug 2018 09:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EF7E97C0A0F; Sat, 25 Aug 2018 18:42:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlg6HuqcfXSM; Sat, 25 Aug 2018 18:42:40 +0200 (CEST) Received: from [IPv6:2a02:8084:d6c1:c900:f5a2:5c42:d981:8721] (unknown [IPv6:2a02:8084:d6c1:c900:f5a2:5c42:d981:8721]) by mork.alvestrand.no (Postfix) with ESMTPSA id 171147C09FC; Sat, 25 Aug 2018 18:42:39 +0200 (CEST) To: Applications and Real-Time Area Discussion Cc: "clue@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: Date: Sat, 25 Aug 2018 18:42:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> Content-Type: multipart/alternative; boundary="------------9E7BF54127F14ED93C7AED73" Content-Language: en-GB Archived-At: Subject: Re: [Ice] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 16:42:50 -0000 This is a multi-part message in MIME format. --------------9E7BF54127F14ED93C7AED73 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Speaking as editor of -overview and -transport, I support this approach. (-transport already references ice-bis, now 8445). On 08/22/2018 07:58 PM, Adam Roach wrote: > Members of the ART community interested in real-time communications: > > Cluster 238 [1] is a set of inter-related documents dealing with > real-time communications. The bulk of these documents relate to > WebRTC, either directly or indirectly. They also form the > underpinnings of CLUE. As of now, there are 34 documents in the > cluster that are not yet published, with 25 of these already in the > RFC Editor's queue. The dependency graph among these documents is such > that the bulk of them can be published as soon as a specific six of > them are handed off to the RFC editor, and we expect this to happen in > the upcoming few months. > > One long-running complication for this cluster of documents is that > each of the documents were developed over the course of seven years, > in concert with implementations, while the ICE protocol itself was > undergoing significant revision. As a consequence, some documents rely > (directly or indirectly) on the older ICE specification (RFC 5245), > while some rely on the newer one (RFC 8445). In some cases, documents > refer directly to the old version and transitively to the new version. > > It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the > mechanism described in RFC 8445 has some  changes that break backwards > compatibility with the mechanism defined in RFC 5245 (with such > behavioral changes controlled by an SDP attribute, allowing clients to > transition from one to the other). > > Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC > protocol in the IETF) refers to directly to RFC 5245, while relying on > the behavior defined in draft-ietf-ice-trickle; > draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 > handling. JSEP's reference to RFC 5245 is a practical consideration > that acknowledges that current deployments of WebRTC implement the > older version of ICE. At the same time, these deployed implementations > use a somewhat older version of draft-ietf-ice-trickle in concert with > the older ICE implementation. > > In order to get Cluster 238 published, we need to find some way to > rationalize its references to ICE. At a basic level, the ART Area > Directors do not believe that it makes sense to publish new documents > that refer to an already obsoleted RFC. At the same time, we recognize > that there is value in our specifications being informed by running > code. For WebRTC, the complexity of the system has led us to a point > that we must choose between these principles. Our proposal is to > choose the first, while acknowledging the second. > > This would result in a request to the RFC editor to update all > references to RFC 5245 in the Cluster 238 documents to instead point > to RFC 8445. Documents not yet in the RFC editor queue would be > updated prior to IESG review. We would further request that the RFC > editor add the following text to draft-ietf-rtcweb-overview and > draft-ietf-rtcweb-jsep: > >> While this specification formally relies on [RFC8445], at the time of >> its publication, the majority of WebRTC implementations support the >> version of ICE described in [RFC5245], and use a pre-standard version >> of the trickle ice mechanism described in [RFCXXXX]. The use of the >> "ice2" attribute defined in [RFC8445] can be used to detect the >> version in use by a remote endpoint and to provide a smooth >> transition from the older specification to the newer one. > RFC 8445 would be a normative reference for both documents, while RFC > 5245 would be informative. > > There is one more minor complication, in that > draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC > 5245) is intended to be an exhaustive list of the SDP attributes > defined in the documents it lists, and RFC 8445 adds a new "ice2" > attribute that was not present in RFC 5245. For this reason, we would > also ask the RFC Editor to add a new row to the table in > draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows: > >> +-------------------+---------------------------+-------+-----------+ >> | Name | Notes | Level | Mux | >> | | | | Category | >> +-------------------+---------------------------+-------+-----------+ >> | ice2 | Not Impacted | S | NORMAL | >> | | | | | >> +-------------------+---------------------------+-------+-----------+ > > For clarity, the affected documents are as follows. > > The following documents would be updated to reference RFC 8445 prior > to IESG evaluation: > > * draft-ietf-clue-datachannel > * draft-ietf-clue-signaling > * draft-ietf-rtcweb-security > * draft-ietf-rtcweb-security-arch > > > The following documents would be updated to reference RFC 8445 by the > RFC Editor: > > * draft-ietf-mmusic-mux-exclusive > * draft-ietf-mmusic-sctp-sdp > * draft-ietf-rtcweb-alpn > * draft-ietf-rtcweb-data-channel > * draft-ietf-rtcweb-rtp-usage > > > The following documents would be updated to reference RFC 8445 and > have the text proposed above added to them: > > * draft-ietf-rtcweb-jsep > * draft-ietf-rtcweb-overview > > > The following document would be updated to reference RFC 8445 by the > RFC Editor, and include a new row for "ice2" in its Section 5.12, as > described above: > > * draft-ietf-mmusic-sdp-mux-attributes > > > This message is cross-posted to the affected working groups. Because > the issue at hand has impact across several different groups, we ask > that all follow-up discussion take place on . Thank you. > > /Adam on behalf of the ART Area Directors > > ____ > [1] https://www.rfc-editor.org/cluster_info.php?cid=C238 > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue -- Surveillance is pervasive. Go Dark. --------------9E7BF54127F14ED93C7AED73 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Speaking as editor of -overview and -transport, I support this approach.

(-transport already references ice-bis, now 8445).

On 08/22/2018 07:58 PM, Adam Roach wrote:
Members of the ART community interested in real-time communications:

Cluster 238 [1] is a set of inter-related documents dealing with real-time communications. The bulk of these documents relate to WebRTC, either directly or indirectly. They also form the underpinnings of CLUE. As of now, there are 34 documents in the cluster that are not yet published, with 25 of these already in the RFC Editor's queue. The dependency graph among these documents is such that the bulk of them can be published as soon as a specific six of them are handed off to the RFC editor, and we expect this to happen in the upcoming few months.

One long-running complication for this cluster of documents is that each of the documents were developed over the course of seven years, in concert with implementations, while the ICE protocol itself was undergoing significant revision. As a consequence, some documents rely (directly or indirectly) on the older ICE specification (RFC 5245), while some rely on the newer one (RFC 8445). In some cases, documents refer directly to the old version and transitively to the new version.

It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the mechanism described in RFC 8445 has some  changes that break backwards compatibility with the mechanism defined in RFC 5245 (with such behavioral changes controlled by an SDP attribute, allowing clients to transition from one to the other).

Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol in the IETF) refers to directly to RFC 5245, while relying on the behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a practical consideration that acknowledges that current deployments of WebRTC implement the older version of ICE. At the same time, these deployed implementations use a somewhat older version of draft-ietf-ice-trickle in concert with the older ICE implementation.

In order to get Cluster 238 published, we need to find some way to rationalize its references to ICE. At a basic level, the ART Area Directors do not believe that it makes sense to publish new documents that refer to an already obsoleted RFC. At the same time, we recognize that there is value in our specifications being informed by running code. For WebRTC, the complexity of the system has led us to a point that we must choose between these principles. Our proposal is to choose the first, while acknowledging the second.

This would result in a request to the RFC editor to update all references to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445. Documents not yet in the RFC editor queue would be updated prior to IESG review. We would further request that the RFC editor add the following text to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep:

While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245], and use a pre-standard version of the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one.
RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative.

There is one more minor complication, in that draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245) is intended to be an exhaustive list of the SDP attributes defined in the documents it lists, and RFC 8445 adds a new "ice2" attribute that was not present in RFC 5245. For this reason, we would also ask the RFC Editor to add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows:

   +-------------------+---------------------------+-------+-----------+
   | Name              | Notes                     | Level | Mux       |
   |                   |                           |       | Category  |
   +-------------------+---------------------------+-------+-----------+
   | ice2              | Not Impacted              | S     | NORMAL    |
   |                   |                           |       |           |
   +-------------------+---------------------------+-------+-----------+

For clarity, the affected documents are as follows.

The following documents would be updated to reference RFC 8445 prior to IESG evaluation:

  • draft-ietf-clue-datachannel
  • draft-ietf-clue-signaling
  • draft-ietf-rtcweb-security
  • draft-ietf-rtcweb-security-arch


The following documents would be updated to reference RFC 8445 by the RFC Editor:

  • draft-ietf-mmusic-mux-exclusive
  • draft-ietf-mmusic-sctp-sdp
  • draft-ietf-rtcweb-alpn
  • draft-ietf-rtcweb-data-channel
  • draft-ietf-rtcweb-rtp-usage


The following documents would be updated to reference RFC 8445 and have the text proposed above added to them:

  • draft-ietf-rtcweb-jsep
  • draft-ietf-rtcweb-overview


The following document would be updated to reference RFC 8445 by the RFC Editor, and include a new row for "ice2" in its Section 5.12, as described above:

  • draft-ietf-mmusic-sdp-mux-attributes


This message is cross-posted to the affected working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on <art@ietf.org>. Thank you.

/Adam on behalf of the ART Area Directors

____
[1] https://www.rfc-editor.org/cluster_info.php?cid=C238



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



-- 
Surveillance is pervasive. Go Dark.
--------------9E7BF54127F14ED93C7AED73-- From nobody Wed Aug 29 11:12:58 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6B1130E06; Wed, 29 Aug 2018 11:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXkf9bv-QaSC; Wed, 29 Aug 2018 11:12:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3E6130DFE; Wed, 29 Aug 2018 11:12:39 -0700 (PDT) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7TICaAY027071 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 Aug 2018 13:12:37 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at From: Adam Roach To: Applications and Real-Time Area Discussion Cc: "clue@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" Reply-To: Applications and Real-Time Area Discussion References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> Message-ID: <0e4f9505-5d96-f0c1-afbc-f493d1097b65@nostrum.com> Date: Wed, 29 Aug 2018 13:12:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> Content-Type: multipart/alternative; boundary="------------84E9B8C7F63D2A840F7E6A6E" Content-Language: en-US Archived-At: Subject: Re: [Ice] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 18:12:42 -0000 This is a multi-part message in MIME format. --------------84E9B8C7F63D2A840F7E6A6E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit It's been a week; so far there have been no objections to this plan, and several messages in support. I plan to consult with the other ART ADs to evaluate consensus on this proposal next week, and take appropriate action. If you have thoughts to share, please send them to the ART mailing list before September 5th. Thanks! /a On 8/22/18 12:58 PM, Adam Roach wrote: > Members of the ART community interested in real-time communications: > > Cluster 238 [1] is a set of inter-related documents dealing with > real-time communications. The bulk of these documents relate to > WebRTC, either directly or indirectly. They also form the > underpinnings of CLUE. As of now, there are 34 documents in the > cluster that are not yet published, with 25 of these already in the > RFC Editor's queue. The dependency graph among these documents is such > that the bulk of them can be published as soon as a specific six of > them are handed off to the RFC editor, and we expect this to happen in > the upcoming few months. > > One long-running complication for this cluster of documents is that > each of the documents were developed over the course of seven years, > in concert with implementations, while the ICE protocol itself was > undergoing significant revision. As a consequence, some documents rely > (directly or indirectly) on the older ICE specification (RFC 5245), > while some rely on the newer one (RFC 8445). In some cases, documents > refer directly to the old version and transitively to the new version. > > It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the > mechanism described in RFC 8445 has some  changes that break backwards > compatibility with the mechanism defined in RFC 5245 (with such > behavioral changes controlled by an SDP attribute, allowing clients to > transition from one to the other). > > Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC > protocol in the IETF) refers to directly to RFC 5245, while relying on > the behavior defined in draft-ietf-ice-trickle; > draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 > handling. JSEP's reference to RFC 5245 is a practical consideration > that acknowledges that current deployments of WebRTC implement the > older version of ICE. At the same time, these deployed implementations > use a somewhat older version of draft-ietf-ice-trickle in concert with > the older ICE implementation. > > In order to get Cluster 238 published, we need to find some way to > rationalize its references to ICE. At a basic level, the ART Area > Directors do not believe that it makes sense to publish new documents > that refer to an already obsoleted RFC. At the same time, we recognize > that there is value in our specifications being informed by running > code. For WebRTC, the complexity of the system has led us to a point > that we must choose between these principles. Our proposal is to > choose the first, while acknowledging the second. > > This would result in a request to the RFC editor to update all > references to RFC 5245 in the Cluster 238 documents to instead point > to RFC 8445. Documents not yet in the RFC editor queue would be > updated prior to IESG review. We would further request that the RFC > editor add the following text to draft-ietf-rtcweb-overview and > draft-ietf-rtcweb-jsep: > >> While this specification formally relies on [RFC8445], at the time of >> its publication, the majority of WebRTC implementations support the >> version of ICE described in [RFC5245], and use a pre-standard version >> of the trickle ice mechanism described in [RFCXXXX]. The use of the >> "ice2" attribute defined in [RFC8445] can be used to detect the >> version in use by a remote endpoint and to provide a smooth >> transition from the older specification to the newer one. > RFC 8445 would be a normative reference for both documents, while RFC > 5245 would be informative. > > There is one more minor complication, in that > draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC > 5245) is intended to be an exhaustive list of the SDP attributes > defined in the documents it lists, and RFC 8445 adds a new "ice2" > attribute that was not present in RFC 5245. For this reason, we would > also ask the RFC Editor to add a new row to the table in > draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows: > >> +-------------------+---------------------------+-------+-----------+ >> | Name | Notes | Level | Mux | >> | | | | Category | >> +-------------------+---------------------------+-------+-----------+ >> | ice2 | Not Impacted | S | NORMAL | >> | | | | | >> +-------------------+---------------------------+-------+-----------+ > > For clarity, the affected documents are as follows. > > The following documents would be updated to reference RFC 8445 prior > to IESG evaluation: > > * draft-ietf-clue-datachannel > * draft-ietf-clue-signaling > * draft-ietf-rtcweb-security > * draft-ietf-rtcweb-security-arch > > > The following documents would be updated to reference RFC 8445 by the > RFC Editor: > > * draft-ietf-mmusic-mux-exclusive > * draft-ietf-mmusic-sctp-sdp > * draft-ietf-rtcweb-alpn > * draft-ietf-rtcweb-data-channel > * draft-ietf-rtcweb-rtp-usage > > > The following documents would be updated to reference RFC 8445 and > have the text proposed above added to them: > > * draft-ietf-rtcweb-jsep > * draft-ietf-rtcweb-overview > > > The following document would be updated to reference RFC 8445 by the > RFC Editor, and include a new row for "ice2" in its Section 5.12, as > described above: > > * draft-ietf-mmusic-sdp-mux-attributes > > > This message is cross-posted to the affected working groups. Because > the issue at hand has impact across several different groups, we ask > that all follow-up discussion take place on . Thank you. > > /Adam on behalf of the ART Area Directors > > ____ > [1] https://www.rfc-editor.org/cluster_info.php?cid=C238 > --------------84E9B8C7F63D2A840F7E6A6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
It's been a week; so far there have been no objections to this plan, and several messages in support. I plan to consult with the other ART ADs to evaluate consensus on this proposal next week, and take appropriate action. If you have thoughts to share, please send them to the ART mailing list before September 5th.

Thanks!

/a

On 8/22/18 12:58 PM, Adam Roach wrote:
Members of the ART community interested in real-time communications:

Cluster 238 [1] is a set of inter-related documents dealing with real-time communications. The bulk of these documents relate to WebRTC, either directly or indirectly. They also form the underpinnings of CLUE. As of now, there are 34 documents in the cluster that are not yet published, with 25 of these already in the RFC Editor's queue. The dependency graph among these documents is such that the bulk of them can be published as soon as a specific six of them are handed off to the RFC editor, and we expect this to happen in the upcoming few months.

One long-running complication for this cluster of documents is that each of the documents were developed over the course of seven years, in concert with implementations, while the ICE protocol itself was undergoing significant revision. As a consequence, some documents rely (directly or indirectly) on the older ICE specification (RFC 5245), while some rely on the newer one (RFC 8445). In some cases, documents refer directly to the old version and transitively to the new version.

It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the mechanism described in RFC 8445 has some  changes that break backwards compatibility with the mechanism defined in RFC 5245 (with such behavioral changes controlled by an SDP attribute, allowing clients to transition from one to the other).

Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol in the IETF) refers to directly to RFC 5245, while relying on the behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a practical consideration that acknowledges that current deployments of WebRTC implement the older version of ICE. At the same time, these deployed implementations use a somewhat older version of draft-ietf-ice-trickle in concert with the older ICE implementation.

In order to get Cluster 238 published, we need to find some way to rationalize its references to ICE. At a basic level, the ART Area Directors do not believe that it makes sense to publish new documents that refer to an already obsoleted RFC. At the same time, we recognize that there is value in our specifications being informed by running code. For WebRTC, the complexity of the system has led us to a point that we must choose between these principles. Our proposal is to choose the first, while acknowledging the second.

This would result in a request to the RFC editor to update all references to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445. Documents not yet in the RFC editor queue would be updated prior to IESG review. We would further request that the RFC editor add the following text to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep:

While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245], and use a pre-standard version of the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one.
RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative.

There is one more minor complication, in that draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245) is intended to be an exhaustive list of the SDP attributes defined in the documents it lists, and RFC 8445 adds a new "ice2" attribute that was not present in RFC 5245. For this reason, we would also ask the RFC Editor to add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows:

   +-------------------+---------------------------+-------+-----------+
   | Name              | Notes                     | Level | Mux       |
   |                   |                           |       | Category  |
   +-------------------+---------------------------+-------+-----------+
   | ice2              | Not Impacted              | S     | NORMAL    |
   |                   |                           |       |           |
   +-------------------+---------------------------+-------+-----------+

For clarity, the affected documents are as follows.

The following documents would be updated to reference RFC 8445 prior to IESG evaluation:

  • draft-ietf-clue-datachannel
  • draft-ietf-clue-signaling
  • draft-ietf-rtcweb-security
  • draft-ietf-rtcweb-security-arch


The following documents would be updated to reference RFC 8445 by the RFC Editor:

  • draft-ietf-mmusic-mux-exclusive
  • draft-ietf-mmusic-sctp-sdp
  • draft-ietf-rtcweb-alpn
  • draft-ietf-rtcweb-data-channel
  • draft-ietf-rtcweb-rtp-usage


The following documents would be updated to reference RFC 8445 and have the text proposed above added to them:

  • draft-ietf-rtcweb-jsep
  • draft-ietf-rtcweb-overview


The following document would be updated to reference RFC 8445 by the RFC Editor, and include a new row for "ice2" in its Section 5.12, as described above:

  • draft-ietf-mmusic-sdp-mux-attributes


This message is cross-posted to the affected working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on <art@ietf.org>. Thank you.

/Adam on behalf of the ART Area Directors

____
[1] https://www.rfc-editor.org/cluster_info.php?cid=C238


--------------84E9B8C7F63D2A840F7E6A6E--